Mainframes to Minicomputers (1973-1981)

In February, 1973, Miller McCarthy, the salesperson I had worked with at IBM called me and asked if I had had enough partying. He recruited me to come back to Cleveland and help him with a contract his new company had with Chrysler Corporation. He thought he had contracted to build a real-time data acquisition system for a Chrysler plant in Syracuse, NY. As I looked at it, I realized he had committed to build an on-line transaction processing system to support close to 40 terminals using a DEC PDP-11/05 minicomputer. He had sold them a computer that could not possibly do the job and committed to building a system that was far beyond anything that currently existed. What is it with sales guys?

Minicomputers emerged in the 1970’s because departments of large corporations were frustrated with the keepers of the mainframes. They purchased their own computers to solve their own problems. This battle between central and distributed computing has been one of the most common themes I have seen over my lifetime in the trenches of technology.


Digital Equipment Corporation (DEC) had created the term “PDP” which stood for “Peripheral Data Processor” and came from DEC’s attempts to bypass the strangle hold that IBM and Univac had on US Government purchasing processes. And it worked. I knew a little bit about DEC PDP 11 systems because my roommate (Tom DeFanti) had used a PDP 11/45 on which to develop his doctoral thesis. He loved its flexibility and robustness and reminded me repeatedly about the thunderstorm that had drenched the building that housed the library system and his PDP 11. The library system took several days to restart, but his PDP 11 came back up without even a hiccup.

The Chrysler job was not a done deal. We (Miller and his team) needed to convince them to upgrade the hardware and increase their budget. Miller scheduled a meeting with the Chrysler management team to review the project. I was to join him and Pete Kosinski (also from Miller’s team at IBM) on the call.

True to form, Miller held a big party at his house the night before the sales call. Again, the steaks sizzled and the booze flowed heavily. Miller’s father, a retired MD somehow convinced me that streaking the party would be a good idea. Imagine a man in his seventies and a twenty-something flashing past the living room window stark naked, laughing like a couple of fools. It was fun, though!

I awoke the next morning in a panic. Our flight from Cleveland to Detroit was leaving Burke Lakefront Airport in 20 minutes and I lived 30 minutes away. There was no way I could make that flight. I shaved and threw on my suit and rushed to the airport with the horrible feeling in my stomach that I had let my team down. I blurted my story to the fellow at the counter and asked if there was any way he could get me to Detroit in time for my meeting. He must have felt some compassion for the idiot on the other side of the counter because he got on the radio and managed to reroute a small plane that was shuffling film between Cleveland, Toledo and Detroit. I boarded the single engine plane, sat in the co-pilot’s seat and watched Lake Erie float by beneath us. The pilot radioed ahead and lined up a rental car for me and got me directions from Detroit City Airport to Chrysler’s headquarters in Highland Park. As soon as the plane’s propellers stopped, I ran from the plane to the Hertz counter, signed whatever they put in front of me and jumped in my rental car to begin the final leg of the mad dash across town. I arrived barely a minute before the meeting started. As I tried to catch my breath, Pete reached into his pocket and took out a $100 bill and without a word handed it to Miller. Miller had bet on me.


PDP 1145

Although the Chrysler project started out with a PDP 11/05, we were able to convince them to upgrade to a PDP 11/45 running RSTS/E with a bit more disk. We managed to get two RK05 disks that each supported 2.5MB of data. Each disk looked like an overgrown pizza. We also had two DECtape drives that stored a whopping 184K of data on each 3/4 inch wide magnetic tape. It may not have been much, but we made it dance.

1974 [078]Chrysler ultimately backed out of the contract with Miller’s company in Cleveland, but asked me to come on board their staff. Little did they know that they were hiring their own token hippy. Within a few months of joining their staff, I ditched my suit, grew my hair and started looking like Rasputin. And I started building what I look back on as a vision ahead of its time.

Over the next three years, I built TPS: an Online Transaction Processing System. I had worked on implementing IBM’s CICS at Ohio State so I knew what a transaction processing system had to do but outside IBM and Univac, there were no other examples to draw on. So I built one.

TPS had multiple cooperating processes, a database engine, both dynamic and resident transactions, a transaction definition language and a compiler that produced RSTS/E Basic code, a monitoring console and an event logger. It had load balancing capabilities and it could support dozens of concurrent transactions. The database engine supported field-level access and was capable of 20ms response time. And everything was written in Basic-Plus which supported jobs of up to 32KB in size, and TPS could not fit in 32KB.

In order to get around this limitation, I had to break the system into multiple cooperating processes that talked with each other, but no such capability existed in RSTS/E until the most recent release which added a feature that allowed one process to send 20 bytes of information to another process.

It took me many months to enhance this capability so that I could send strings of any length from any process to any other process and wait for a reply.

I did all of this work in an old munitions factory that overlooked Detroit City Airport, the same airport I landed at in my mad dash from Cleveland to make the sales meeting. Downstairs was Chrysler’s Warranty Materials Return Center. Every day, fleets of trucks would arrive carrying parts that were being returned by dealers around the world. And whenever they would run their giant trash compactor, my PDP 11 would crash.

One day, an old worker from downstairs came staggering up the stairs carrying a beat-to-shit box. He held it out and asked, “Anybody here know anything about this here dig-it-all?” It was a replacement Digital PDP 11/05 we thought had gone lost.

Those were amazing days. I was smoking lots of pot and writing massive amounts of code. I had no fear of being fired because I was very clear with Chrysler management that I had no intention of staying on after the project was complete. If they fired me, that was fine with me because I hated Detroit. I had no family and no friends there. All I had was my code and my dig-it-alls. And then I met Donna.

1974 Donna at OSUIt was on September 22nd, 1974. I went to a folk and blue-grass concert in Rochester, Michigan. I had a date with me who was pretty, but not the brightest bulb in the pack. We shared a birthday, but that was all we had in common. I was sitting on the grass listening to Hickory Wind, smoking a joint and enjoying the beautiful but briskly cold day. I looked around at one point and noticed a beautiful blonde sitting nearby. I held up the joint I was smoking and nodded and she smiled and nodded back. I tossed it to her. She was so cute that I found myself forgetting my “date” and looking for a way to get to know the beautiful blonde better. I rolled her a fresh one and flashing her a big smile, I tossed it her way. She smiled back at me, looked at the fellow she was sitting with and said to him, “Let’s go sit with that guy.” We were married the following April.

Chrysler New Process GearBy late summer, 1975, TPS was ready to be installed in the Chrysler New Process Gear plant in Syracuse, NY. I asked my boss, Dave Long how he planned to support the system after it was installed. He drew a blank on that one, so I offered to support it for one year if he sold me the rights to the code for $1.00. He countered with three years and we settled on two. I now owned TPS and it was time to leave Detroit.

I hooked up with Interactive Information Systems (IIS), a company in Cincinnati, Ohio that ran a big DEC PDP/11 RSTS/E shop. Donna and I moved to Cincinnati in July and I commuted to Syracuse until about October. Donna was pregnant with Travis during this time, so this move was very hard on her. She was alone in our apartment in Fairfield. I was gone from Monday through Friday and she had no friends or relatives nearby.

Code BugFortunately, I managed to wrap up the Chrysler job before Travis arrived, but during that time I had another battle with an obscure code bug. This time it turned out to be a mis-named variable. I had defined $d1 but referenced $b1. Now you might (wisely) ask, “Who in their right mind would name a variable $d1?” It turns out that RSTS Basic only supported two character (one letter + one digit) variable names. The “$” meant that it was a string variable.

Lesson learned: Use meaningful variable names.

Robert H Jones IV [08]I continued to work on TPS while in Cincinnati and I made numerous calls on DEC. I wanted to sell TPS to DEC, but it was an up hill slog. That I looked like a hippy was not to my advantage, and I had been quite a pain in the ass at several of the DECUS (DEC User Society) conferences. In one session, Armen Varteressian, one of the DEC managers opened his session with, “Good morning ladies and gentlemen… and Bob Jones.” He got a good laugh because I still hadn’t learned the importance of good relationship skills.

DEC was developing their own transaction processing system and they did want one thing from me: the name “TPS”. I told them to make me an offer, but their answer was that I should be delighted just to give it to them. They didn’t have very good relationship skills either. They named their system “TRAX” and it was an utter disaster.

I stayed with the company in Cincinnati until late spring of 1978 when we discovered that the manager in charge of our money hadn’t balanced the bank statement in several years. Whoops! There is another lesson learned here, but I don’t think I need to spell it out. I saw this as an opportunity to escape from Cincinnati where we had just endured a text-book blizzard followed by 18 inches of solid ice on every street in the county in January and had experienced the previous year’s January without the thermostat rising above zero for the entire month. I had gone to California for several DECUS conferences and decided that it might be a good idea to live there.

I contacted a couple head-hunters and told them I wanted a job in the south bay of San Francisco. After a couple weeks of saying, “No, not Dallas” and “No, not Memphis”, I heard from one who said he had a nibble from a company called “Tandem”.

Tandem LogoI got a phone call a couple days later from Jerry Held who was the manager of the database development team at Tandem and he told me there were plane tickets waiting for me. When I arrived in San Jose early the following week, I had the strangest interview I have ever had. In the room were Mike Greene (one of the four founders of Tandem), Jerry Held, Dennis McEvoy, Glenn Peterson and Robert Shaw. They drilled me on TPS and the database engine and all the other code I had written for several hours until finally Glenn Peterson said, “You have the right concepts but you are using all the wrong terminology. You came up with all these ideas in a vacuum, didn’t you?” I looked at him and shrugged, “Guess so.”

Mike Green said, “I am not going to make you an offer until you have already accepted it.” I thought about it for a moment and said, “OK, I accept.” I started at Tandem a month later.

Tandem NonStop Computers

Tandem NonStop IITandem computers were build to be fault tolerant. They were the brain child of Jimmy Treybig, the lead founder of Tandem. Jimmy was a very charismatic leader who was well respected and much loved by his employees. My Tandem years (1978-1983) were happy times. I was part of a brilliant team of designers and thinkers and worked on challenging projects. For the first few years, Tandem’s stock was rising and I was earning more on the appreciation of my stock than from my salary. My fellow developers and I learned that we could “borrow against the margin” and buy toys while we still held our stock. And it was going nowhere but up. Those were the golden days.

Then in early 1982, the pressures to meet Wall Street’s expectations resulted in claiming to have sold and shipped more systems than they really had. Overnight, Tandem’s stock dropped by 2/3. Several executives almost went to jail. The stock drop resulted in many margin calls. I got off easy. I only lost almost all of my remaining stock. One fellow who was sailing across the Pacific in the sailboat he purchased on the margin was greeted by the sheriff at the dock when he landed and had his boat repossessed. The golden days of Tandem had passed.

There are many lessons here, but one of the biggest is Stock margin accounts are not for idiots. I am an idiot in recovery. Or maybe I am still just an idiot.

Tandem DDL

Tandem PathwayI wrote Tandem’s DDL (Data Definition Language) Compiler. It was based on Mike Greene’s LALR Parser Generator which ate a BNF language definition and spit out the parser tables. Wrapper that with a scanner to tokenize the input stream and decorate the parser stack appropriately and voila, you have a language processor. Tandem’s DDL took a COBOL-ish structure definition as its input and generated equivalent TAL, COBOL, SCOBOL and FORTRAN statements.

Once I had DDL working, I stripped it to the bone and wrote up, “How to Build a Language Processor In 60 Minutes or Less”. A developer could feed his BNF language definition into the LALR Parser Generator, feed the output of that into the code I provided, then provide some samples in the language just defined and you could see it working in as little as 15 minutes. It was quite the hit.

One problem I saw with DDL was that it was passive. You could describe a data structure and couple that with a disk or tape file and, if your definition was accurate, you could process the data effectively. But there was no solid linkage between the data and its definition (meta-data). I realized that we (Tandem) controlled all of the parts so that it should be possible to point the COBOL compiler to a DDL definition and have it generate the corresponding Data Division statements. And we should be able to link that code with an Environment Division statement that hooked the code to the actual file. This meant that we should be able to ask questions like, “Where is Customer Number used?” and be able to identify the specific files and programs that referenced Customer Number… or any other field. I pursued this idea and called it “Describe” which was a pun on our data management product called “Enscribe”. Describe introduced the notion of an object as

Jim GrayAt this same time, Tandem was working on its next generation of computer designs and managed to hire Jim Gray away from IBM. Jim was “an American computer scientist who received the Turing Award in 1998 for ‘seminal contributions to database and transaction processing research…'” This was quite a coup, but interestingly, Jim decided he would rather work on Describe with me than on the new computer design. We worked together for a couple years on this project, but it wound up being crushed under the weight of internal politics and I became bedazzled by the newly emerging microcomputers like the Apple ][ and the IBM PC.

Sadly, Jim Gray disappeared on January 28, 2007 during a short sailing trip to the Farallon Islands to scatter his mother’s ashes.

Go To:

Print Friendly