Robert’s Background in IT

Robert Garrett started his IT career in the mid-1970s after graduating from West Texas State University with degrees in mathematics, physics, and computer science. He went on to work for the Plains Cotton Cooperative Association (PCCA) in Texas.

Why a Cotton Co-operative Needed IT

PCCA brought cotton farmers together to improve their access to markets and negotiate better prices.

That created an interesting technical problem: how do you connect farmers, cotton gins, warehouses, and buyers across large distances and allow them to trade cotton efficiently?

In the late 1970s, the answer involved an IBM mainframe, leased telephone lines, terminals, and quite a lot of software.

IBM DOS, but Not That DOS

By the late 1970s, Robert was working with an IBM 3031 processor running DOS/VS Release 34.

This wasn’t the DOS that would later become familiar on personal computers. It was IBM’s mainframe Disk Operating System, descended from the System/360 era.

DOS had been around for years by this point and remained in use by customers who had built their systems and applications around it.

And PCCA had built something rather interesting on top of it.

An Online Cotton Auction in 1978

Robert participated in developing what may have been one of the world’s earliest online cotton auction systems.

The system connected cotton gins, compresses, warehouses, and buyers using IBM 3270 terminals and leased telephone lines. Cotton could be offered for sale and buyers across the network could place bids remotely in real time.

No web browsers. No cloud. Just terminals, telephone lines, and a mainframe in Texas.

From Binary Synchronous to SNA

The network initially used binary synchronous communications and later moved to IBM’s Systems Network Architecture (SNA).

That migration brought its own technical challenges — and apparently enough material for a few more IT horror stories.

When UNPK Broke

After IBM engineers performed an upgrade on the 3031, the machine didn’t come back properly. During the IPL, Robert noticed that a device address was being corrupted before the system dropped into a hard wait.

That meant finding out exactly where things were going wrong.

Debugging the UNPK Instruction

By single-cycling the processor through the failing code, Robert eventually narrowed the problem down to an UNPK instruction.

UNPK — short for Unpack — converts packed decimal data into an unpacked format. The input was correct. The instruction was correct.

The output wasn’t.

Robert had reached the rather unusual conclusion that the software wasn’t broken.

UNPK itself was broken.

“Unpacks broke,” I declared to the engineers, who initially met my statement with disbelief.

The Problem Was in the TCM

Once the IBM engineers reproduced the problem themselves, they traced the failure to a TCM — a Thermal Conduction Module inside the processor.

These modules were expensive, liquid-cooled components containing part of the processor logic. Replacing one wasn’t something you did casually.

As Robert explains, removing the TCM involved a mechanism that permanently marked the module so it couldn’t simply be reinstalled and used again.

At this point there wasn’t much left to debate.

The instruction was broken, the hardware was responsible, and the TCM had to be replaced.

Conclusion: Sometimes It Really Is the Hardware

When software produces the wrong result, you normally assume the problem is somewhere in the software.

Robert kept debugging until there wasn’t much software left to blame.

The input was correct. The instruction was correct. The output was wrong. And eventually the IBM engineers standing beside the machine had to agree.

UNPK was broke.

Sometimes the hardware really is the bug.

---