At the end of every month, Saigon would send all the Vietnam Communications Centers a report ranking them by error rate. Let me tell you about that….
To understand this story, you need to know that DSTE‘s a computer terminal; in this context, it’s basically a fast teletype. I’ll tell you more about it some other day.
A typical workday at the Pleiku Army Communications Center
An Army headquarters has similarities to other offices: People spend the day doing whatever they do. At the end of the day, they clear off their desk and pass the day’s work to the next desk. If that next desk was not in Pleiku, it landed in our CommCenter on its way around the world. As you might guess, we got busy around supper time, as both outgoing and incoming message traffic tended to pick up around 1530 Vietnam time; the rush would queue up, and would typically end (in both directions) several hours later.
The Day I Screwed Things Up
On the day after my twenty-second birthday, my Trick Chief (TC) left me in charge of the DSTE. Sometime that day, our sister operation in Nha Trang went down with equipment difficulties; since they were off line, the network transferred their traffic (which basically duplicated ours) to our station. (Our direct teletype connection with the Nha Trang CommCenter was the backup circuit for both stations.) This doubled the workload at the DSTE, and radically increased the relay workload in the teletype room. We adjusted assignments, and I spent several hours tearing paper tape and deciding whether it was for PKU, or NHA.
I’d been in-country a month, and this was the first day I’d worked DSTE alone. By the time the shift changed, I was exhausted. Shortly before shift change, things improved somewhat: Nha Trang’s DSTE came back on-line. Since DSTE was far faster than the teletype line, we stopped the relay operation and someone returned the tapes to me. I slapped ’em in DSTE, & was finishing the cleanup just as the night trick arrived. I briefed my relief on the situation, went back to the barracks, and fell asleep.
TC woke me up, and chewed me out: Seems that as the traffic stopped, twenty-eight error messages came through. I’d forgotten that several of the messages originated on punch cards, not paper tape, and thus had improper headers and footers for paper tape transmission. The night TC noticed; he woke the Chief Warrant Officer to report it. The CWO woke my TC, who woke me. After some discussion, TC dragged me to the CommCenter, where I re-sent the messages with proper headers and footers. Then he bought me a drink at the NCO club and we returned to bed….
Truth told, neither the CWO nor my TC cared a lot about the errors, except they looked bad in our reports. Both superiors knew I’d made one error and repeated it fourteen times (the double-count was a reporting artifact). They also knew that it would show as 28 errors on the computerized reports, and (near as any of us could tell) those reports were the main method Saigon used to evaluate CommCenter operations. They issued performance rankings based on those counts….
You need to understand my 28 errors. All messages were technically freeform (I’m ignoring some human-readable formatting), except that they had standard headers and footers. The header was formatted to fit a Hollerith card. The first 80 characters had to fit a specific format, and perhaps a dozen of those characters had to meet accuracy checks. End of Message was indicated by one or four “N’s”, depending on the medium used to create the message.
- My first error for each message was generated on the second character in the header: It was “C” (for CARD), but since I was using a TAPE drive to (re)send the message it should have been “T”.
- I generated a second error on each message for an incorrect End of Message indicator: EOM for card-generated messages was a single “N”, while tapes were expected to end “NNNN”.
Side note: The system’s programmers had actually anticipated this error. Since my messages were marked as flash (high) priority, they were delivered to NHA; the error messages were more like courtesy reminders than real errors. Didn’t show that way on the reports, though.
At the end of every month, USARV HQ in Long Binh would send all the Vietnam CommCenters a report ranking them by error rate. Presumably, communications careers rode on these reports, as we received no other messages which compared the CommCenters. This was stupid. Basically, the brass was using the 80-character header as a proxy for the message, and judging the quality of our messages by the error rates of our message headers. This, of course, made checking the header a significant part of my job (32 years later I can still read Baudot code, though I can no longer do so quickly).
But that wasn’t a good proxy. After traffic dropped off, night shift would spend a couple hours handling problem messages received from other CommCenters. These all had good headers. But it was clear that specific CommCenters couldn’t get the freeform part of the message right. We saw no evidence that headquarters attempted to measure that part of our communications system.
The computer can count it. Why use a method which requires analysis of real messages?
It was a bad measure in another way. Except for one CommCenter, we all had error rates around one percent. On a bad month, someone would approach 1.5 percent. Except that Long Binh–headquarters, and by far the busiest message generator–was evidently exempt, and lived with a 3% error rate.
I’d have told this story anyway, but it’s partially a response to a note by David Weinberger/Joho the Blog.
Beware what you measure.