This is the end of the message (or maybe not)

In the 1980s, I was the Regional Network Manager for SITA in Harare in Zimbabwe. SITA stands for “Societe Internationale de Télécommunications Aéronautiques” and was (and still is to a large extent) the Airlines Data Network, which connects the reservation terminals in airline offices to their host mainframes on the other side of the world.

In those days a 9600 BPS international data circuit was pretty high-tech, and in spite of the low speeds and satellite circuits (with their attendant half-second round trip delay) we could usually offer a response time in the order of 3 seconds from any airline terminal anywhere in the world to its host system and back. It was a great company to work for, with lots of travel and good training. I had a lot of fun there, got myself a name as a roving troubleshooter, and consequently got sent to some fairly exotic places chasing obstinate communications problems.

Early protocols
The TCP-IP protocols were in their infancy in those days and airline reservation systems used their own proprietary protocols. The vast majority of the host systems were either IBM or Unisys. IBM invented a protocol called IPARS, designed to squeeze the maximum throughput from the 2400 BPS lines that we used for local links. Character size was 6 bits (saving 25% of the usual ASCII 8 bits) but IBM being IBM (I always think it stands for Inherently Bloody-Minded) they reversed the bit order and the bit sense as well.

British Airways used IPARS, and their office in Lusaka in Zambia had a new printer that obstinately refused to print. Everything else in the office worked fine. BA were getting pretty huffy about this and I was dispatched to go and persuade their printer (or our network) of the error of its ways.

I had at my disposal a Tektronix 834 (below), one of the early protocol analyzers.



It was (like all Tektronix equipment) a great little bit of gear, very portable and with a facility for plugging in a custom ROM pack which could make it understand and decode IPARS pretty well. However it only had a 1-line by 16-character fluorescent display (the now ubiquitous LCDs were still in their infancy too). So on a busy line it was not the easiest thing to use to chase fleeting problems.

Character study
Now IPARS had four different End-of-Message characters. EOMi (the I stood for Incomplete) was used in the middle of a message if more than one message was being sent in the same block of data. EOMc (c for complete) meant that that was the end of the whole message and it was followed by a Cyclic Check Character (CCC) worked out by the usual algorithm half a mile long.

The Tek 834 was clever enough to work out the CCC of a message it was displaying and let you know if it was good or not. So when I first connected it on the line to the BA office, I could see the usual polls and responses going back and forth and see that the CCCs looked good, and all the blocks were being properly acknowledged. So we did not seem to have a line quality problem.

I had a phone line to the BA office, to get them try and print for me, and was in touch with my technical boss in Paris via the then equivalent of an instant messaging system. He very thoughtfully told me to get on with looking at the problem and get back to him if I needed any help (how good a boss is that??). I captured a few blocks and soon saw that although most of the blocks we were sending) had perfect CCCs going out from us, the blocks to the printer had wrong CCCs every time.

The IPARS challenge
The IPARS blocks were encapsulated in a different (ASCII-based) protocol for transport over our network. The 6-bit IPARS characters were padded out to 8-bits for this, and the IBM convention of reversing the bit order and sense made it fiendishly difficult to decode when it was in this format. A friend in the Paris head office had kindly provided me with a conversion table which did make life easier. And it was when I looked at the encapsulated data that I noticed something strange. Most of the messages had BA’s EOMc before our encapsulating ASCII EOM character, but messages to the printer had BA’s IPARS EOMc character and then a couple of extra characters before our protocol envelope took over. (Our equipment regenerated the CCC locally when we sent the block on). Hmmmm…worth checking further.

The Tek 834, when looking at the BA line, helpfully defaulted to displaying the EOMc and the CCC and then suppressed any other data until it got the next start of message sequence. And it was only when I made it display everything that I saw what was happening. The outgoing printer block had extra characters after the EOMc. and only then our CCC.

Junk characters
The block we got from BA into our network had got an EOMc plus (wrongly) a couple of extra junk characters on it. Our network dutifully spat it out the other end, tacked our usual CCC onto it AFTER the junk characters, and sent it to the BA terminal system. The BA terminal system, however, saw the EOMc, took the next character (the first of the junk characters on the end of the BA message) as the CCC and found it was wrong (as had my trusty Tek 834). The CCC that our equipment blindly tacked onto the message it got from BA was just ignored.

It was with some glee (albeit fairly well disguised) that my boss advised the huffy BA people that the problem was on their side. But hey, at the end of the day it’s about making it work for the customer, and that’s what we did.

Years later, I had a similar printer problem in another exotic location during an adventure highlighted by some good Calvados.