In 1967 (Canada's Centennial year) I finished school, got married, and joined IBM as a very green "Systems Engineer" in a medium sized sales branch in Kitchener-Waterloo, Ontario. I spent a wild 5 years "in the field", as IBM underwent phenomenal growth and computer technology was establishing its place in the corporate world. All my experience with computers in university had been bad, but IBM overcame my reluctance to ever touch a keypunch again by offering me a huge bag of money--$585 a month. To start! Done deal.

I got off to a good start in Kitchener, but in the last couple of years I got in way over my head and was ready to quit.

But then I got moved to Toronto, as an Instructor in an IBM Education Centre, where I spent 5 very productive and enjoyable years, learned a ton of stuff, and built a bit of a reputation as a hotshot. After that, I spent a couple of years in the Toronto Field Support Centre, where all the hotshots lived, and eventually got myself invited to join the IBM Software Lab in Toronto. At first the work there was more of the same, but in a couple of years I got swept up in my first serious software development project, as team leader. The work we did over the next couple of years may have been the best stuff I've ever done.

Scene 1: July-August 1967: Basic Systems Training

I walked into the IBM Kitchener office early one July morning, and it seemed pretty clear that no one was expecting me, or the other couple of guys who arrived around the same time. But they found places for us to sit, passed out stacks of IBM reference manuals, and we all spent a rather odd day flipping through them. I expect the others understood little more than I did.

All I remember about the days that followed was that one salesman, whose sales territory included the local bank branches, told me he was trying to sell some kind of cheque-handling unit record devices, but did not have a good understanding of what machines the banks were currently using, or what they liked / disliked about them. I don't know what he expected me to do, but I walked up and down King St, went into every bank, and asked a bunch of questions about their cheque-proofing [?] machines. At least one of the people I talked to called the IBM branch to verify my credentials, which made me feel very grown-up and business-like. I took detailed notes and presented them to the salesman a couple of days later. He seemed quite stunned. I wonder if that was helpful at all. Unlikely, but I tried.

After a couple of weeks, I went off to Toronto for a 6-week employee orientation: "BST"--Basic Systems Training. There were about 20 people in my "class", and IBM put us up at the Muir Park hotel at Bayview and Eglinton. A few of the people had cars, and we'd drive downtown to the Royal Trust Tower (I think) where the IBM Education Centre was.

BST topics were taught by a team of instructors, but the lead guy was Bob Delaney, and I remember being very impressed by how easily he seemed to do what looked to me to be a damn difficult job.

They taught us computer concepts (e.g., binary notation, EBCDIC coding) how to program (in Assembler, RPG and PL/I), how to draw flowcharts (I still have flowcharting templates kicking around, but I haven't seen any of the huge flowchart paper we used, with regularly spaced rectangles arranged for a neat diagram), some stuff about the IBM product line (unit record equipment, the second generation workhorses like the 1401, and the relatively new /360 line).

There was also a fair amount of indoctrination in the IBM way of doing things, but it was pretty easy to take (at 22) because it made us all out to be an elite group who would generally know a lot more about our customers' business than they would. I looked forward for a long to the day that would happen for me, but it never did.

They also drilled into us a code of behaviour that was rooted in the consent decree IBM had signed in 1956, prohibiting us from disparaging the competition or "unhooking" their orders. But there was no need to fear the competition: Their products were clearly inferior to ours. As I recall, I had no trouble buying that. The consent decree was on the books till 1996.

As I recall, there were only two groups held in lower regard than competitors like Honeywell and Univac--leasors and 3rd party consultants. One intent and result of the consent decree was to allow someone to purchase any piece of IBM equipment and then lease it to a company that would otherwise have leased it from IBM. This was bad for a couple of reasons: (1) The customer was paying the leasor instead of IBM and (2) IBM had to treat the "customer" just as well as someone who was actually paying us. It was dirty pool. And consultants! Don't get me started. They were like Systems Engineers, but they didn't work for IBM! Customers would actually pay them to do programming and for their advice, both of which should always come from IBM, in the natural order of things. But that's how it was, and they told us all about it.

When BST ended, I spent about a week in the Kitchener office, before getting married and taking a week off. Then Rosemary went to work in the library at the University of Waterloo, and I started carrying a briefcase. 1967 was a big year for us.

Scene 2: In the field as a Systems Engineer (SE)

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.
Scene 3: 1972-1976: Teaching in the IBM Education Centre

I spent 5 years in the Toronto Education Centre, which largely restored my self-confidence.

In Kitchener I had become somewhat of an expert in IBM's operating system for small and intermediate /360 mainframes, so that's primarily what I taught. IBM Canada had 2 regional Ed. Centres (Ottawa and Toronto), but Toronto was the big one, and I quickly got to be "the" expert (except for one guy in Ottawa, Howard Smith, who gave me a run for my money). The Education Centres provided training for both IBM and customer personnel, and we would receive advance documentation and training on the latest technology as it was being developed, which I enjoyed immensely, and which allowed me to stay out on the edge of things.

I wound up defining and largely developing huge chunks of the IBM Canada curriculum for DOS, and then DOS/VS, which introduced "virtual memory" to IBM's smaller systems. And one memorable year I was sent to Mexico to help IBM in that country work out their own training strategies. Great fun.

At one point I was the lead instructor for a 6-week Basic System Training class, which I quite enjoyed. That year, IBM had decided they had more Customer Engineers (field guys--always guys--who serviced mainframe hardware and system software) than they needed, and they re-trained a bunch of them to be System Engineers. So, for an interesting few days, I gave lectures on the intricacies of /360 microcode to an audience that included several people who had actually written the stuff, which I certainly had not. They were quite kind to me.

Although I focused mainly on DOS/VS and DOS/VSE, I also wound up teaching in some other things, like a 5-day System Design and Project Management, for which I was stunningly unqualified. Fortunately, I had some good horror stories to tell (see Hard Knocks above); that and a sense of humour carried me through.

In addition to teaching, I did quite a bit of training development. I even developed a self-study course for IBM US, "Operator Control of DOS/VS", which was delivered on audio tapes. This was funded by IBM US Education, and the recordings were made in Poughkeepsie New York. I spent a week there making the tapes for a pilot, which we ran in Toronto. It went very well, but the students all complained about sibilance in the reader's voice. None of them believed it was actually voice on the tape, but it was decided that for the real product release we'd need a professional voice. So I went back down for another week while the tapes were re-recorded by a real "talent".

I think it was in this period that I learned to program in APL, and even taught a course in it. But I may have that wrong . . . maybe I picked it up in Kitchener?

For about a year I moved from the classroom to a manager's office, which was a bit unusual in those days for someone who had never been a sales rep. That's when I got to be good friends with Bill Hardacre. He ran several management-oriented courses, and he taught me a LOT about managing time and people, especially how to avoid taking an employee's problem as my own. "Don't let the monkey jump from his back to yours", he'd tell me.

But I found I missed the technical stuff, and, despite Bill's advice, I made a mistake or two that suggested to me I didn't really have a future in management, so I moved back into the technical stream. Even so, Bill's lessons stuck with me and helped me many times in the rest of my career. I miss him.

Scene 4: 1977-1978: Supporting the field from the FSC
My primary role was to take over the "DOS/VS Installation Productivity Option" from its inventor, Ken Harvey (KPH), one of the hottest of the hotshots in the FSC.

Round about this time, a major problem that IBM and its customers faced was the incredible number of individual software products that were needed to run even one of the smaller mainframes. IBM had software labs all over the world, and there was surprisingly little cooperation among them: Each lab would spit out new releases on its own schedule, with little or no consideration for what other changes the IBM customers were facing. So a new version of CICS (networking software) would be published and sent to customers, but no one at IBM would have bothered to test it with the latest version of the operating system, or DL/I (database software). And while the customers were wrestling with that, the O/S would get upgraded, and you could be damn sure that hadn't been tested with anything else.

So one of the hottest hotshots in the FSC (one KPH) decided that he would solve the problem. Ken knew and was known to just about every DOS/VS customer and IBM technical guy, so he simply told them all to stop installing updates until he (KPH) had tested them out. In fact, Ken would gather up a few month's worth of changes, install them all together, debug the mess, report all the problems he found to the appropriate labs, gather up the fixes, install them, test the whole thing all over again, and continue until he had a reasonably stable collection of cooperating pieces. Then he'd put it all on a tape and announce to Canadian customers that the latest DOS/VS Installation Productivity Option (IPO) was available, and they could order it from him. It was brilliant, but it had to annoy a lot of people, like the whole distribution chain for IBM software, who saw KPH taking over their job. It was incredibly impertinent, but it worked and made Ken a hero, because (a) he solved the customers' problems, and so (b) they were willing to install the latest IBM software, as soon as Ken said it was safe. The sales reps loved him for that, because customers didn't fall too far behind, and they had fewer complaints, so they could be sold more and bigger hardware (nobody really cared about software revenues yet).

So I moved into the FSC and became Ken's understudy, and then took over the job when he moved on to bigger things. I didn't do half the job Ken did, and it soon became apparent that this wasn't really a 1-man job, and the whole thing was getting so important that IBM decided to move it into a software lab. Toronto was closest, and they took over this integration, testing and packaging job, with me as the lead technical guy.
Scene 5: 1978-1980: IBM Software Lab

The IPO Succeeds and Moves South

In 1979, the IBM Toronto Lab was not very big, and it was buried in a basement corner of the Canadian headquarters building, at 1150 Eglinton Ave. The Lab had yet to find its "mission"--that is, none of the stuff developed in the Lab was considered very "strategic" to IBM. There was some optimism that the IPO concept might help with that problem, but it didn't. In a couple of years it got stolen by the Poughkeepsie or Endicott Lab (I forget which, who cares). The fact that the US labs absconded with any good ideas was just a fact of life.

Don Myles Issues a Challenge

Sometime in 1978, Don Myles, a major force in IBM Canada, who headed a group called Product Line Marketing, approached the Lab with a challenge. He said that IBM was about to announce a new line of mid-range /360 machines (the 4300's) that would be much cheaper than current models of similar power and capacity. The problem for IBM was in that "cheaper" attribute.

IBM's profit margins on even the smallest mainframes were always very healthy (read 'obscene'), but these new systems were going to be so inexpensive that IBM would need to sell a LOT of them to make acceptable money. That meant customers would need to find new uses and applications for the machines, fill them up quickly and upgrade often. These computers would need to be useful for, and usable by, people who didn't know shit about computers--people we called "end users". But how would THAT happen?

The fact was, developing mainframe applications was difficult and slow, and the results were almost always hard to use. There needed to be a whole new approach, and a whole new set of uses at which these systems could be directed. Don asked if we (the Lab) could come up with something.

Sidebar about "Millions for Myles"

Gary and I Search for an Answer

Gary Helander and I had worked together on the DOS/VS IPO, and Lab management (Jack Dawson and Clancy Marchak) passed the challenge to us. We brainstormed for some time, but the only real insight we came up with was that, if relatively unsophisticated customers were going to be our prime target, the operating environment had to be VM/370 and CMS, rather than DOS/VS and CICS, or MVS and TSO. (Sidebar needed to clarify and expound.)

Then, one day, someone suggested we talk to Ron Holt, a senior lab guy, about something called the "Screen Formatter". The name didn't sound very promising, but we dutifully went to take a look, and were completely blown away by what we saw.

What Ron showed us was a toolkit for making rapid prototypes of mainframe applications. To use it, you needed to think of an application as a collection of "screens" displayed on an IBM 3270 terminal, linked together by user actions. For each screen, you listed the actions the user could take--such as the buttons s/he could hit, the menu items s/he might select, or the text she might touch with a light-pen. For each possible action you made a row in a "flow table". Each flow table entry specified (a) the next screen that should be displayed, and (b) optionally, a program to be executed before the next screen appeared.

That might not sound like much, but, at the time, it was revolutionary. The standard way we designed applications was as a more-or-less monolithic program. The application program would start, display a 3270 panel, read input from the user, and do whatever processing was necessary. The notion that the screens were actually the heart of the application, and that design should start there, was a complete reversal of the normal approach.

Much later I would see this as a clear example of the Single Responsibility Principle at work, but I don't think that had yet been formulated. All Gary and I knew was that it felt RIGHT.

The stuff Ron showed us had been built by a team that included one Art Benjamin, who had left IBM and started his own business, at least in part because IBM was uninterested in turning the work into a product.

The toolkit Ron showed us was based on MVS and TSO, which meant we could not use the existing code in our solution, but the concepts were entirely portable to VM/CMS, and that's what we decided to do. We put together a presentation for our management and then for Don, which was good enough that PLM provided funding to build a product, which we set about doing.

Product Development

We established a core team of about 5 people, with me as Team Leader, Gary as Chief Programmer ("Chief Programmer" was big at the time), Rob Dunn, Sue Williams and Marty Marchyshyn as developers. It was a great team.

Gary and Rob wrote the engine for the product (basically an interpreter) in PL/S, a language used inside IBM; the rest of us wrote the inter-screen code modules in EXEC and EXEC2. We had decided that all the product documentation would be provided on-line, using the product itself to display tutorial and help screens, and I wound up writing the text for most of those.

One of the most difficult programing tasks on IBM mainframes was to display and manage terminal screens by which the user interacted with the application. We knew our target users could never cope with the standard tools for such work, so we looked for another way, and we found it in an IBM-internal tool named IOS3270, also known as Display Input/Output Facility. This had been developed at the IBM Lab in Uithoorn, the Netherlands, (by one Theo Alkeema, who I only recently discovered was very famous in the VM/370 world) and it made out job much easier--if it hadn't existed, Gary would have had to build something like it from scratch. We liked this better.

At some point in the development phase, we managed to convince management that we should attend an application development course delivered by a Toronto company named Art Benjamin Associates. IBM didn't much like paying someone else for such things, but an exception was made in this case, and those of us who attended found it very helpful. Art Benjamin taught most of the course, and that was our first introduction. Although I didn't know it, in a few years I would be teaching that course.

The team worked pretty much flat out for a year, and we shipped it. Personally, although I loved the work, it just about killed me. Then I realized we needed to do it all again, because there had to be a second release! I wasn't sure I was up to that. I felt pretty much fried, and I got inappropriately drunk at our celebratory party. Thanks to Clancy for driving me home and trying to soothe Rosemary. Thanks to the rest of the team for never needling me about it.

Losing the Battle to ISPF

The original name we had for our product was Dialogs, but the lawyers told us we couldn't use that, and the best substitute we could come up with was Information Dialogues for End-User Applications (although they also told us we could not make an acronym from it). Later, the package got renamed to IXF: Interactive Extension Facilities. I think we were better at product development than product naming. We certainly weren't unique in IBM in this regard.

Our product was initially released only for the Canadian market (although I think a couple of European geographies picked it up at some point). But the problems we tried to address existed all over IBM, and that included the U.S. The Data Processing Marketing Group (DPMG) struck an initiative to find a solution, which they saw as allowing easier application development and in particular support for office automation applications. We felt our product was the answer, and DPMG sent a delegation to hear our pitch.

To cut a long andvery painful story short, we lost that competition to ISPF: Interactive System Productivity Family, which had its roots in a TSO programmer's tool called SPF: Structured Programming Facility.

In our opinion, IXF was a far better choice than ISPF, but that opinion did not prevail. At the time it was a tremendous personal disappointment, and no doubt contributed to my decision to leave IBM.

Many years later, I met one of the people from DPMG who had been on the decision-making team. I didn't remember him, but he recognized me and apologized, saying that they had no idea what they were doing, and eventually realized they had made a big mistake. Ah well.

IBM and I part ways

Despite the DPMG disappointment, I was very proud of the work we had done, and was pumped when Clancy recommended me for a promotion to Senior Development Analyst. I was bummed, however, when the Lab Director, John Leppik, said no.

When I got the news, I developed an immediate snit, went out to the parking lot, and bought a copy of the Globe and Mail, which always had a good careers section. I found an Amdahl ad for System Engineers, and gave them a call. To my surprise (I had no large mainframe experience) they were very interested, flew me to California to see their primary facility and meet some important people, and ultimately made ma a very flattering offer.

But Amdahl had apparently asked Ken Harvey (by then working for Art Benjamin) if he knew me; Ken said some nice things about me, but also declared that I belonged with him and Art. He gave me a call, I went to see Art, and that was that. I do remember clearly that, when Amdahl asked me to visit them in California, I told them I had already made up my mind, and they were wasting their money. They flew me out there anyway, I was flattered, and I had the best orange juice I ever tasted.