1967-1968: A complete life insurance package in 16KB--programmed in Assembler

My first real assignment at IBM was as a programmer and junior IBM SE at Canadian Order of Foresters (COF), a small fraternal insurance company in Brantford. Richard (Dick) Haeberlin was the senior SE on the account, and he became my first technical mentor. I could have done a lot worse--Dick seemed to know everything there was to know about programming, and especially /360 Assembler language. COF was small potatoes to him; he was also the main SE at Dominion Life, a much larger customer.

The first day I was there, Dick introduced me to Shirley Lawrence, the COF person to whom the whole project reported. Looking back, it must have been unusual for a woman to fill that role, but I don't think that occurred to me at the rime, and Shirley was well respected by everyone on the project.

Anyway, Shirley immediately sent me to speak to John Gribben, SDL's lead developer. She said he would bring me up to speed, and, oh, he had a few technical questions for me (the IBM expert).

John was from Scotland, and he had quite a strong accent. He started talking, I listened intently, and understood maybe every third word. I knew I was green, and had never dealt with a real customer before, and I knew better than anyone how little of an expert I was, but, even so, I was dismayed at how bad I was at this!

Then I glanced back at Shirley and the rest of the team and saw that they were all laughing uncontrollably, while trying to stay quiet. Apparently this was a standard initiation rite, sending the new guy to talk to JG. Once I caught on, John's speech became much easier to follow, and in time we got to be good friends. But (obviously) I never forgot that.

COF had a Model 20, the smallest of the 360s. The Model 20 was quite common in the Kitchener area, but this particular machine was unusual, in that it had 4 tape drives in addition to the standard card reader, card punch and printer. At that time, no Model 20 customers in the Kitchener area had disks in their configuration. Guelph Hydro was the first to get them, and, actually, they weren't called "disks", but Direct Access Storage Devices--DASD--at least within IBM.

The operating system (such as it was) was named TPS (Tape Programming System). I am probably one of the last people to remember it. I know I was one of a very few to use it.

The COF account was also unusual because it had been infiltrated by a dreaded consultant--a company called SDL (I forget what that stood for). The consultants were being paid to design and program a "Policy Master System" for COF. The idea was that COF would keep all of its policy files on a "master" tape, and every day all of the new application, premium payments, claims, changes of address, and other standard insurance policy events would be keypunched as they arrived in the mail, and loaded onto a "transaction" tape. Every night, a large batch process would be run to sort the transaction tape into sequence by policy number and transaction type. A hugely complicated program would then apply the transactions to the records on the latest policy master tape, and create a new master tape, reflecting all the events of the day.

At the time we figured this was quite reasonable on a machine that allowed no multiprogramming, had 16K bytes of memory. and generally limited the programmers to overnight compile/test cycles. Programs were hand-written onto coding sheets and passed to a team of keypunchers. We submitted our decks at the end of the day, and came in the next morning to see the results. Way too frequently the only result was a one or two page listing that pointed out an error in our Job Control cards, or a syntax error in the code. If the program DID compile and execute, the most likely result was a 3-inch-thick core dump listing produced when the program crashed.

The core dump was just about the only debugging tool available, unless you could convince management that your test was so important you should be allowed dedicated, hands-on access to the complete machine. In that case, you could stand at the console, set a break point, or step the program through the code, one instruction at a time. I should point out that the console wasn't a keyboard and typewriter--it was 6 hex-valued rotary knobs on the front of the machine, a couple of hex-valued switches, and 4 small light displays that each showed a single hexadecimal digit. There was enough room on the top of the machine to put your program listing, so you could follow it along.

To set a breakpoint, you used the knobs and switches to replace the instruction of interest with a "STOP" instruction. Of course, you had to know the exact memory location of each instruction. When the stop happened, you restored the original instruction into core and took the next step. Whenever the machine stopped, you could also use the control panel to check the contents of any memory location (1 byte at a time).

I worked at COF for about a year, and got quite good at /360 Assembler (at least the half-assed Model 20 subset), debugging other people's programs, and figuring out the idiosyncrasies of the Model 20 hardware, the O/S and utilities.

I also learned how to work as part of a team, how to deal with customers, a little about system software, and a bit about the insurance industry. Not a bad start.

I don't remember what state the application was in when I left COF, but I remember 2 things: (1) it wasn't finished, by a long shot and (2) I had to leave because IBM started charging for the services of its Systems Engineers, and COF didn't want to pay for my time. Actually, I think it was more that IBM couldn't see sticking a good potential sales-support guy into a services engagement at an hourly rate. Selling hardware was much more profitable, and that's what I should be focused on, along with everyone else.

Like so much else going on at that time, the decision to charge for services was driven by the consent decree; it seems consultant organizations felt it was unfair for IBM to provide services for free in order to subsidize hardware sales. So back to the office I went, looking for another assignment.

1968-1970: Model 20 RPG Guru

As a Systems Engineer, I provided technical (mostly program debugging) support to a couple of dozen IBM customers in southwestern Ontario, all of whom were using RPG on /360 Model 20 card-based systems. I also set up a weekly evening event where these customers would meet with me over a Model 20, I'd help them do some testing, and I'd give a bit of a tutorial on some technical subject or other.

I learned everything there was to learn about RPG and the Model 20, and a lot about customer support. This was also my first experience with anything like teaching, and I seemed to have a knack for it.

Kitchener was the largest IBM city in the Southwestern Ontario (SWO) territory, which included several other locales like Cambridge, Preston, Brantford and Stratford. The main commerce was manufacturing, but there were also quite a few small and mid-size life insurance companies headquartered there. I got involved in 2 big initiatives of the time. One was to get the smallest accounts, of which there were dozens, to move away from unit record technology (keypunches, card sorters, and plug-board calculators the name of which I seem to have forgotten) to real computers. The second imperative was to push those who had already made this move to adopt the latest IBM line--the System /360. There were a lot of accounts in SWO who were using IBM 1401's, 1410's an 1440's, and the fact was they were mostly happy with what they had. So all of us "technical types" made a lot of customer calls with salesmen, lending the authority of our deep knowledge of technology to the marketing spiel.

The most common programming language in the area was RPG (Report Program Generator), and the favoured platform was the /360 Model 20. In 1968, the only peripherals on these machines (except for the freak at COF) were a card reader, a card punch, and a printer. All applications had to be designed around these devices, with all data stored in boxes (and boxes and boxes and bins) of 80-column punched cards. Most of the applications had to do with bookkeeping, and most of the programmers working in the customer companies were accountants by training. Everyone figured that if you could figure out double-entry bookkeeping, you could probably learn a programming language, and we still didn't realize there was anything more to building systems than that.

Most of these ex-accountants had to teach themselves how to program, and all they had to work with was IBM reference manuals, which were pretty much impenetrable. So IBM tried to provide some training; some of it was available in Toronto, at the Education Centre where I attended Basic Training, and there was also a "Customer Support Centre" where you could bring your troublesome programs and get some advice from IBM experts. But this was pretty inconvenient for our SWO customers, and someone (maybe it was me) got the idea that we could set up a facility and provide some local support. So the salesmen all sent out letters to their customers saying that if they had any programming problems, they should call the expert, Roger Tessier, and he'd take care of it. I can't remember how we reconciled the price for this service ($0) with the consent decree, but somehow we convinced ourselves it was sales support rather than programming services, and away we went.

Shortly after that, I started to get calls from customers who couldn't figure out why their programs wouldn't compile, or wouldn't behave correctly when they did. The first call I got was from the Samsonite company, in Stratford. Out I went, and they showed me the RPG program listing, the partial (incorrect) report it printed, the (incorrect) card data it had spit out, and a very large core dump listing. "What's wrong?" they asked. And they looked at me, all expectant and trusting of the big IBM guru.

The only trouble was, I hadn't seen or thought of RPG since the 1-week introduction we got at BST, and I hadn't paid that much attention even then. I couldn't even ask an intelligent question. So I turned a few pages over and scowled, looked at my watch and said "Tell you what, let me take this back to the office and I'll call you tomorrow morning." Fine with them I grabbed all the materials, drove back to the office, picked up every RPG manual I could find, and went home to work it out. It took me almost all night, but I learned RPG from the manuals, pored over every line of the program listing like it was written in a foreign language, consulted my IBM dictionaries, and eventually found what looked to me like the bug. They had misunderstood some feature of the language, and coded it wrongly. I called them the next morning from the office and said casually, "Just took a look at your program--I think you used the wrong indicator on the third line of the Calc sheet. Just change that and it should be fine." Summbitch if it didn't work! I spent a lot of time at Samsonite over the next year, and driving around from customer to customer working what looked to them like magic. The fact was, I saw the same patterns so often I could generally fix in 5 minutes what the poor programmer had been struggling with for days. The customers loved me, and I got a huge ego boost.

Those were heady days--I learned how great it is to be skilled, useful, and recognized as such by a whole bunch of people.

1968: 1401 Emulation on a /360

One customer, Savage Shoe, had acquired a /360 (model 30 I think), but they were still doing all their programming in 1401 Autocoder, and using an unsupported and heavily modified 1401 emulator to execute them on the 360. From the time they installed the 360, they had several times got IBM to modify the emulator program to allow things that no 1401 had ever done, and their Autocoder programs were dependent on these features.

The customer was quite happy with the status quo, since everything ran faster on the newer hardware, but we wanted to get them back into the /360 mainstream. Specifically, we recommended a move to the new Disk Operating System (DOS--which coincidentally required a 4KB memory upgrade). But the emulator program they were using wouldn't run under DOS, and the one provided by DOS of course emulated a real 1401, not the souped up version they had become used to. The customer wouldn't move to DOS, or buy more memory, unless we could give them an emulator program that would execute all their Autocoder programs.

So I went in and made the modifications. To my amazement, I got it to work pretty quickly, and everyone was happy. As it turned out, it still took the Board of Directors several months to approve the expenditure for the memory, but the sale was eventually made, and the stage was set to sell a whole bunch more hardware over the next few years. People were already starting to talk about software and services as sources of revenue, but the fact was no salesman actually cared a hoot about that--they were paid to move iron, and nothing else mattered, unless it helped them do that.

I came away with more /360 Assembler experience, an introduction to the 1401, and an appreciation for emulators, and the difficulties of writing and testing low-level system software. This was also the first time I provided services at hourly rate--the customer actually paid IBM for my time.

The big move to disk

I helped Guelph Hydro upgrade their 360 Model 20 by adding 2 IBM 2311 disk drives, so they could take advantage of "job streaming" using a disk-based operating system (DPS: Disk Processing System). The 2311 used removable "disk packs", each of which held 7.5 MB of data spread over several platters.

I think the DP Manager at Guelph Hydro was Jim House (something like that). One Saturday, after the CE's had installed the disk drive, Jim and I went in and tried it out. Jim had a large pile of punched cards that represented multiple jobs. Normally, these would need to be separated into individual decks, each defining a single job, but today we started the machine, put the entire stack into a card reader hopper, and pressed a "Start" button. We watched the first couple of jobs run, and then went out to get some lunch.

Some time later we came back to the office and were thrilled (really, it was exciting!) to see that many jobs had been executed, and the work was still going on!

However, the good mood was somewhat tempered by the fact that the disk drive had moved to the opposite side of the room! I guess it hadn't been levelled or secured quite well enough, and the vibrations of the spinning platters had caused the whole thing to "walk" across the floor. We put in a call for sipport, and the CE's soon had that sorted out.

Working with Guelph Hydro and other customers who made the move to disk, I completely mastered a simple operating system.

I move up to DOS

At Dominion Life (Dick Haeberlin's main account), I modified ALIS, a large IBM insurance software package, to use the newest disk technology (the 2314, a bank of 11 disks in a single cabinet, each disk holding a whopping 30MB of data). The standard ALIS package used an incredible Rube Goldberg tape/drum device, the IBM 2321 "Data Cell", because they could hold much more data that 2311 devices, but the Data Cell was pretty slow. The 2314's were much faster, and had enough data capacity to make it all work.

I remember I was pretty pumped to be allowed to mess with serious software written by real professionals from an IBM Lab, and at first I wondered if I would be able to manage, but it all went pretty well, and my code was got into production, and, I assume, into the official product. Mind you, ALIS never did get much market penetration, but still, . . .

I can't rememner if Dominion Life paid for my time. Maybe not--it might have been charged to the ALIS development project.

1970-1971: Hard knocks

To this point in my career, I had succeeded at everything I tried. In fact, I was one of 3 SE's in the office selected to attend the 1970 "SE Symposium" in Mexico City. Every year, IBM held a "100% Club" at some resort location for all salesmen who achieved their quota the year before. The SE Symposium was a smaller, less lavish, event for the top SE's in each office, as selected by management. By 1970, these events were commonly combined, and the SE's got to share in the big festivities. It was quite an event, with big production numbers and celebrity performers (although I forget who was there in 1970).

Anyway, I was cruising along pretty well, until Stan Jasinski made a sale at Zehrs Markets, a regional chain of grocery stores. The Kitchener office included a "Service Bureau" (later renamed the "Data Centre"), where customers could buy computer time and services, when they weren't ready to set up their own in-house operations. Stan convinced Zehrs that they could save a bunch of money by implementing a common, partly automated procedure for the weekly orders placed from each store. The deal was that the store managers would fill out their orders by making pencil marks on special "mark-sense" cards. These would then be picked up and brought to the IBM Service Bureau, where they would be run through a machine that read the marks and spit out punched cards. The punched cards would then be fed into a program that would generate printed orders, to be dispatched to the central distribution point. Pretty good idea, no doubt.

As the resident expert on Model 20 programming, I was put in charge of implementation. As was quite typical of the time, we considered this to be a programming task; we were pretty much oblivious to the implications for business processes, and the magnitude of the change we were introducing to the Zehrs organization. So away we went, and we scheduled the first order under the new system to be processed on the first business day of the new year (1971).

Just before Christmas, we brought all the store managers together in the IBM office, gave them instructions on how to fill in orders, and explained how the whole thing would work. We gave them each a binder that contained the first cards for them to mark up in January for their first order. I thought the session went very well.

Comes the big day, the Friday before the New Year break. The store managers dutifully mark their orders onto the cards, and send them to the IBM Data Centre. I'm there, along with Stan and the Zehrs' DP Manager. We fire up the mark sense reader, drop in the first deck, and push the Start button. Disaster! Instead of quietly reading the marked cards and punching equivalents, the machine simply shredded the input cards. Almost every one was mangled and chewed, ripped into pieces within the machine! Panic!

For the rest of the (fortunately) long weekend, the three of us and our wives pieced together these shards, trying desperately to figure out what each manager had ordered. Then we'd manually key punch the data into cards, a hideously difficult and slow job. Somehow we got it all done, and produced the printed orders in time to get the products out to the stores.

What we realized then was that, when the training session ended, the store managers had tossed the books we'd given them into their car trunks, until after Christmas when they were needed. So the cards had been outside for a couple of winter weeks, and had absorbed a whole bunch of moisture. They were swollen and misshapen, and way beyond the tolerances of the mark sense reader. We quickly passed along to everyone that it was important to keep the cards warm and dry, and the next week's orders went much better. We had a few programming problems, but the whole thing was really pretty simple, and we muddled through. But that was my first really bad work experience, and my first indication that I could indeed screw things up. I didn't need to wait long for the next one.

Not long after that, Stan sold an in-house computer, one of the new-fangled System /3's, to a local construction firm, and foolishly accepted me as the technical lead. I was to train the customer's programmer (Jim Brezini, an accountant by trade) and between us we would build the system. The point was to keep track of the life cycle of each piece of heavy machinery, recording every project it worked on, the hours of use, its current location and so on. Efficient deployment and maintenance of these monsters was the key to the customer's profitability, so they (and we) were pretty excited by the prospects.

But in fact the problem was much more difficult than we realized, and the software got very complicated. I suspect my "design" was pretty poor, and debugging was an endless task. Every time I thought we had things straightened out, something else would go wrong. We went into production long before we should have, and the business became dependent on the system, but the system wasn't working for beans. We fell into a desperate routine where I would work all day on fixing the problems that had surfaced in the overnight run; Stan would come in for the night shift, and operate the computer to get the reports for the next day. He would document all the problems he had overnight, so that I could come in the next morning and "fix" them. As a vicious cycle, this was pretty vicious, as we both became exhausted and it seemed like things just kept getting worse. Needless to say, the customer was not very happy.

I guess we eventually got it going (the company is still in business today) but not before I got sick as hell, almost certainly from the stress, and my self-confidence was shot. For the first time, I received a not-so-good performance evaluation, and I decided this job was too damn tough. I started looking around for another job, but word got back to my management, and (bless their souls) they decided I could be salvaged as an employee. Someone had the idea that I might be a decent teacher, and I got transferred to Toronto, into the regional education centre there. Good move.