This document is intended to set down my experiences as an original member of the IBM Poughkeepsie OS/360 development project, from 1963 to 1967. This will necessarily include how I got there in the first place. There exist some writings from the mountaintop - E.G. Fred Brooks, Gene Amdahl, Watts Humphries, Dick Case, Bob Evans, etc; yet I thought that the recollections of someone in the trenches should be captured. I built my career on these experiences, ultimately leading to a job as CEO of Boole and Babbage, a pioneering supplier of IBM OS/360 software products. I have been retired now for 21 years, the last 15 living the good life in Seattle with Audrey, my wife of 43 years.

Please bear with me, as these are recollections after almost 55 years and not based on any recorded history. I do not intend to tell any tales out of school or denigrate anyone, merely to relate my experiences both technical and non technical as best as I can recall after all these years. I will do my best with names and dates, but again bear with me, please.

Also, be forewarned, I want to have some fun with this narrative as well. And for those, technically challenged, I do not intend to get deep into technical details - as if I could remember them after all this time anyway. I can't even remember what I had for dinner last night!

Chapter One: The Path to IBM

On a gray day in April 1963, with the Hudson River at my back, I drove my Jaguar XK150 Drop Head Coupe up a steep hill into downtown Poughkeepsie New York. I will never forget the feeling that I had at the time. I was 26 years old and joining the ivory tower of computing - the IBM Systems Development Division (SDD)! Me, the skinny kid from the Petworth neighborhood of Washington D.C. The kid with a C+ average in Electrical Engineering from the University of Maryland four years before. The kid who had just experienced two corporations attempts that failed while attempting to enter the Computer industry - Philco and ITT. Me - I was entering Computing Valhalla!

University of Maryland

I had started in E.E. at Maryland in September of 1955 with about 2000 freshman erstwhile Engineers and graduated four years later with maybe 170, half of whom had been there longer than four years. Why Electrical Engineering? Well, at that time there was a space race creating a large demand and good money. Electrical as the specific Engineering discipline was a process of elimination; mostly based on my being good at math. My C+ average placed me in the middle of the class, but I did it in four years! I flunked just one class - a semester of ROTC! I had cut the twice a week uniformed drill just too many times. When I met with my advisor in the following semester and he looked at my grades, he was shocked.

Text Box: Calculus - A
Intro to EE. - A
Physics - B
Econ - C
English - D
Gym - D ROTC - F

OK, maybe I have this only 90% accurate after 55 years, but you get the point. My advisor asked me how I could get such a lop sided result. I answered - priorities!

I had pledged the premier jock and party fraternity on campus and lived at the Frat house for six weeks until almost the entire pledge class was blackballed - including me. At the time I was devastated, but in retrospect I do not believe that I would have graduated as a member of that fraternity. The fraternity was ultimately suspended because of a cheating scandal and none of my friends who pledged there ever graduated.

I averaged 20 credits per semester and taken just one elective course - an Introduction to Digital Computers. It was a Wednesday night and Saturday morning course. More times than not I had attended the Saturday morning class with little sleep. As I remember it seemed to be mostly a drafting class. I had not been able to find a summer job in the recession of 1958, so I went to summer school to get two history courses out of the way for my senior year. When I registered in the fall, I couldn't just take 17 credits! Thus, the elective computing course was added.

For years after my graduation I had a recurring nightmare. I am in line for my diploma and someone runs up and tells me I had forgotten to take a three credit English course! I was so glad it was all over, that and of course the nightmare was about the idea that maybe it wasn't! What did I get out of my University experience? Not much. Closed book tests convinced me memorization was not the answer; rather that organization would get me what I need, I have been over organized ever since. As to the E.E. degree? Your average TV repairman knew more about electronics than I did. Did that affect my career in computing? Not in the slightest as my career was based on the logic capabilities of Digital Computing, not the Electronics. The logic part I learned on the job at Philco.

Philco

In the Spring of 1959, I had three job offers - Philco in Philadelphia, Northop and Lockheed in Los Angeles. I had no idea what I would be working on at Philco and the Aerospace companies offered their Tech-Rep division. Tech-Rep was kind of a body shop tech support service. I had the same girl friend for three years, so I decided to take the Philco job as it was only 90 miles away. We broke up before I graduated by the way! I didn't know what I would be doing at Philco. All I knew was that I would be making $114 per week, in an era when cigarettes cost $0.25 per pack, Sirloin steak was a $1.19 per pound, and the most expensive Jaguar cost $5,000. When I graduated, I was 22 years old going on 16!

My father drove me to Philadelphia the day after graduation to get me started. We found a room in a classic 19th century North Philadelphia house . It had a restaurant on the first floor and about five rooms for let on the second, and it was located in the Germantown section of Philadelphia; within walking distance to Philco. The plant was located in the old Atwater Kent radio manufacturing facility (he produced radios here in the 1920s). The rooming house was men only and we shared one bathroom. I was lucky and got a nice large front street facing room. Room and board in the first floor restaurant for $85 per month (remember steak was only a $1.19 per pound). The only people I ever saw eat in this restaurant were the residents. The building was managed by this wonderful black woman, who for some reason really, looked out for me. She really took care of this skinny little kid away from home for the first time.

I remember this Sunday experience with my father as one of the rare moments we actually communicated. Later my mother said that my father remarked on his return I seemed to be a nice guy! If you want to know why I have such an independent streak in me, that tells it all.

After my father left, I decided to find a drugstore to buy a few things. To my amazement, Philadelphia blue laws did not allow commercial activities such as drugstores to be open on Sunday. Welcome to the outside world, Jack!

When I reported to work on Monday, I discovered I had been hired into the Philco computer division, specifically the product test department. Our job was to debug the Philco mainframe systems after they had been built in manufacturing. Of course there was no manufacturing at the time as the first model (the Philco Transac S2000 model 210) was still being designed and prototyped. The job was what I expected of a job - boring! But, what the heck, I was making $114 per week!

Through a number of unintelligent career decisions I had literally fallen into the very earliest stages of the maturation process of the defining industry of the second half of the 20th century! Was it just luck or divine intervention?

I believe that Philco hired me because of that single Digital Computer elective course I had taken. There was no such thing as a Computer Science degree and minimal digital computing experience available. The first Computer Science department hadn't appear until 1962 at Purdue, and such departments didn't begin to proliferate until the 1970s.

I enrolled in Penn's E.E. graduate program, went to one class and then resigned. - so much for my academic career.

Extra curricular activity consisted of a visit to a dentist (yes, I have to describe this dentist). He was down the street from my digs, and so primitive that he used a squeeze bulb for air! Cost was $4 per filling, so the price was right! The highlight of my social life was Saturday night at a Polish American club down the street, which I promptly joined. I don't quite remember how I qualified, but I think I was sponsored by someone I had met. Philadelphia blue laws required drink serving to stop at Midnight on Saturday night. However, if you lined up several drinks at Midnight you were allowed to finish them - no matter how long it took! I don't know if this privilege was generally available in Philadelphia, but at least this private club got away with it. Needless to say, I remember nothing else of note about my experiences at this club.

After about three months at Philco, I was assigned to a machine used to test printed circuit boards for the Input Output Processor (IOP) component of the system. I would plug each board in, use the machine to generate electronic input pulses, and use an oscilloscope on the output pins to verify if the required output was produced by the board. Not as straightforward as you might think. First of all, there was no guarantee the discrete components on the board worked, that the board was wired correctly, that the board actually was wired to match the circuit drawing that I was using, and that the damned design was correct in the first place! And finally, that I was far enough up the learning curve as to Boolean Logic to understand any of this in the first place!

I was fascinated. For the first time this wasn't work, it was fun! And don't forget I was making $114 per week to boot! I couldn't wait to get to work every day. This experience was mind boggling and an incredible learning experience for me.

The Philco Transac S2000 model 210/211/212 was the first ever large scale all transistorized computer in the world and outclassed the IBM competition of the day - the 7090/7094. It had a ten micro second main memory, 90KC 1 inch tape drives, a 2000 card per minute card reader, and a 900 line per minute printer. The CPU was asynchronous, not driven by a clock, which meant that progression to the next cycle would happen when all the work was done, rather than have to wait for the next clock pulse to appear. The comparable specs for the 7090 paled in comparison. The model 211 added a two micro second memory, and the 212 redesigned the CPU for even faster performance.

A few months later, the first full model 210 system showed up, and I was assigned to debug the IOP component. It was entirely engrossing. I couldn't wait to get to work. All the problems I described above with the printed circuit cards were multiplied because now we are talking about probably 50 cards and all the peripherals as well. I worked about twelve hours per day, seven days a week and couldn't get enough of it. A second and third system showed up, and since we were spread pretty thin I volunteered to take a grave shift on one of the systems so I could have an entire system to myself.

About that time the Philco Computer Division opened its new facilities in Willow Grove, north of Philadelphia off route 611. I joined five other guys from the test floor in renting an entire floor of a new garden apartment building in Hatboro (they made hats there during the revolutionary war!). The six of us had some real interesting times, but that is another story for another time.

I continued to work on that system twelve hours per day seven days a week for three months without a day off. Remember the $114 per week? Now it is more like $250 per week with overtime. I was so flush I decided to buy a new 1959 fire engine red Plymouth Sports Fury convertible! My father borrowed the money and I paid him back in about six months because of all the overtime.

One Friday night I felt ill and decided to drive home to D.C. for the weekend and have my Physician father work his magic. I left a note telling the circumstances. When I returned on Monday, my boss fired me! I was devastated. I walked around in a fog for three days. What was I going to do? What about the car payment commitment to my father? Then my boss's boss overruled the action and I went back to work. Good old Art Walburg! Needless to say, my relationship with my boss was strained from there on out. He was ultimately fired himself a year or so later.

The first installation was at Philco's western development lab on Fabian way in Palo Alto, California. I was selected to join the twelve man installation team, which left Philadelphia in February, 1960. We took over the first class section of a recently introduced Boeing 707 jet, then a Western Airlines champagne flight from LA to San Francisco after three hours of drinking at LAX. Four brand new Chevy rental cars got us to Ricky's hotel in Palo Alto. It was three degrees below zero when we left Philadelphia and 70 degrees when we got to Palo Alto. For a 23 year old kid who had never been west of the Shenandoah Valley, it was all mind-boggling. I spent a month there and thought this area had to be heaven on earth. A lot has changed in the ensuing 50 years.

The leader of our team was a wonderful refugee from the Soviet invasion of Hungary in 1956 - Steve Zemko. One evening he organized a poker game and provided some Jack Daniels. I showed up with my six pack of 7up and he almost threw me out of the room. I have been drinking Jack Daniels on the rocks ever since.

In March Philco sent me to Schenectady for three weeks on grave shift where it snowed every night when we went out for a 4:00 AM meal. It was quite a change after Palo Alto. I had to agree with what W.C Fields had placed on his tombstone , "I would rather be in Philadelphia" (He hated Philadelphia).

Among the first Philco installations was the Israel Defense Forces (IDF) headquarters outside Tel Aviv Israel. Philco could not get the system accepted and it was costing $1000 per day in penalties. Several "hot shots" were sent over and failed. Finally on December 31, 1961 Philco sent me. It turned out that I was the first to actually work hard at getting the job done. I went third shift through the whole process and succeeded. The IDF gave me an autographed IDF history book (which a treasure to this day) and offered me a jeep with a driver to tour the country. I was too tired and turned them down (stupid, stupid me) and went straight to Paris for four days to relax.

After my return home, I ultimately became an "engineer from the home office" sent out to bail out troubled installations when the local support team didn't know what to do. I never failed.

At an installation at United Aircraft, I noticed a pair of IBM 7090s and asked where the IBM support team was. "They show up every Thursday morning for their maintenance" was the reply! And Philco had two guys per shift and a guy in charge at every installation! I knew we were in trouble. You see our asynchronous CPU was difficult to keep reliable because of "race conditions", the 90KC tape drives got too many errors, the 2000 card per minute card reader couldn't get through 2000 cards without a jam, the 900 line per minute printer printed wavy lines, and the paper wouldn't stack right at that speed. The 7090, though slower on paper, had none of these problems. Besides that Philco only had six world wide salesmen and IBM had 100s, if not 1000s. We were doomed.

In 1961, I had moved Back to D.C. to become an Engineer in Charge of a Philco installation at the Defense Communication Agency (DCA). I was 24 and had six guys working for me, all older than me - one a retired Air Force Colonel. I liked being in charge. I also purchased my first foreign car - a 1961 Jaguar XK150 Drop Head Coupe. A wonderful car, when it was actually running! For example, the distributor hung off the right side of the engine block near the right front tire. It had plastic caps that did not seal the distributor housing. If I hit a big enough puddle with the right front tire, it would flood the distributor and the car would stop. It would do the same thing in a car wash! I put American style rubber nipples on top of the caps and solved that problem. It was only one of many such annoyances caused by Jaguar's use of Lucas for its electrical system.

In 1962, I moved back to Philadelphia to become the "engineer from the home office" mentioned above.

By this time I had married my first wife, Nancy and we had two children - Susan and Jon. By the way, both Susan and Jon joined us in the move to the Pacific Northwest. In 1997, I had moved to Seattle to live out the golden years with Audrey.

By 1962 I had become interested in programming and transferred to the Philco software development department. I am sure that this experience was very helpful on my resume'.

ITT

Late in 1962, Philco was purchased by Ford, the computer division was shut down, and the engineers transferred to Ford's Tech-Rep division. About 10 of us left and formed a support department for ITT's new computer system product. The system was called the ADX 7300 and was built on a DEC PDP-1 (yes Virginia, there really was a PDP-1) with message switching software developed by the ITT Computer Division. DEC started in Maynard, Massachusetts as a company producing printed circuit boards. In the early 1960s it decided it might be profitable to actually build and sell computers using these circuit boards. The PDP-1, PDP-5, PDP-8, PDP-11, etc, fueled the mini-computer era. ITT contracted with DEC for the PDP-1 and designed and built a message switching application for telecom organizations.

DEC was in an old woolen mill and was using about half the first floor of the multistory building when I visited them in 1962. Soon they overflowed the building and grew far beyond that old woolen mill. On the way to the visit, I stopped in a gas station for directions and was told that Maynard was on the other side of the river and "I could not get there from here"! Hard to believe but he really said that. I continued on and found a bridge across and made my visit.

The most memorial installation was in the US Embassy on the Place Concorde in Paris. One of these excursions was a memorable two week trip to Paris in the Fall of 1962. My role again was as an "Engineer from the home office". The highlight was a night out on the town in which I was in a packed car that was pulled over at 2:00 AM by a group of plain clothes police. The fall of 1962 was the height of the Algerian crisis in France and we happened to be in the Algerian section of Paris. These guys did not like packed cars driving around in this section at 2:00 AM! Having had too much to drink I do not remember much about the incident!

One night I was at the bar in the US Officer's Club off the Champs Elysees and struck up a conversation with a short man next to me. He handed me his business card (half size, by the way) which read - "Clifford W. Gotaas, Director European Military Affairs, TWA, The biggest Little Airline in the World". Don't ask me why I remember this detail, but I do, after 50 years! He asked me what airline I was going home with and I said Air France. He offered me a free first Class upgrade on TWA with a car to pick me up at my hotel. I jumped at the offer. The hard part was talking Air France into letting me do the ticket transfer. It seems taking money away from the French in those days was not easy at all. I finally got it done, and Clifford was as good as his word, The car picked me up and I flew First Class sitting next to the Director of the Budget for the Defense department, who drank too much and fell asleep. I suspect that Clifford did this kind of soliciting every night at the Officer's Club.

As to the problem that brought me over in the first place, an intermittent failure after many hours of running, I came to the conclusion that it was caused by an application software failure. I told ITT that we needed the application's key designer. He was sent over and quickly found and fixed the software problem.

After a year of exciting experiences (support trip to Paris, programming experience, first involvement with online systems), history was repeated - the division was shut down and we were transferred to ITT's Tech-Rep division. I started looking for another job.

My head hunter said that IBM wanted to talk to me, and I said it had to wait as I had a commitment to get an ITT system through a 30 day acceptance in the hole at Offutt Air Force base in Omaha. The contract required a support team of seven guys be on site with top secret clearance during the acceptance test. Since I was the only Computer guy with top secret clearance, they took six radar technicians, put them through two weeks of classes and sent the seven of us out. Besides seeing that the test progressed successfully, I started reading manuals from the IBM 7090 installed in the hole. I was hooked. The test was going fine until some contract problem stopped it after about three weeks. I took my IBM interviews, but more about that later. I came back and resigned. ITT brought up my commitment, I brought up the restart and we compromised on two weeks. Let me sum up Omaha in 1962: That is where I bought my bowling ball! The motel was downwind from the stock yards, and the 18 wheelers involved stayed at this motel. The stench from their trucks and the stock yards was overwhelming. I remember stuffing newspapers under the door.

IBM

I took four interviews at IBM, and they all offered me a job; all at the same title and salary - $10,500 per year, my first five figure job! I had my choice:

1. Bethesda Maryland - SLANG, a compiler of compilers for differing machine architectures.

a. Pro - near my home in D.C.

b. Con - I didn't know what the heck the guy was talking about!

2. Product Test in Poughkeepsie - I would get to work on all the current generation IBM product lines.

3. SABRE in Poughkeepsie - the online reservation system for American Airlines. Exciting stuff.

4. Poughkeepsie SDD - The interviewer (Jack Garrity) was 15 minutes late, only had 15 minutes to talk to me, and couldn't tell me what he was working on.

Wow, what a choice. I decided that maybe the last guy was working on next generation stuff so I decided to take a chance and accepted his offer. I walked into the initial startup group of about 30 people, mostly from the Stretch project that had wrapped up working on the design for the next generation operating system for the New Product Line (NPL). Later to be known as the System/360. I subsequently found out that it was IBM's normal practice to force competition in their decision making, and as a result, there was at least one competing project to the System/360. Fortunately for me, I guess, the other projects were not interviewing in March of 1963.

Recap

So, let me review how I had arrived at this point:

1. I chose Electrical engineering at Maryland not for interest but for money.

2. A big break was being blackballed from a fraternity my Freshman year.

3. The 1958 Recession and resultant lack of a summer job allowed me to reduce my senior year load by going to summer school and getting a couple of history courses out of the way. The resultant 17 credit load (after 20+ for three years) caused me to take my only elective - the only digital computer course (three credits) at Maryland.

4. The Philco offer probably was based on the above computer course,

5. I chose Philco over California due to a girlfriend in D,C. - we broke up before I graduated.

6. I had no idea what I would be assigned to. They placed me in their new computer division at Philco offering great opportunities for learning about what large scale computers in detail.

7. I was the only person I know among the hardware guys at Philco or ITT that had any interest in programming.

8. I had three brushes with Techrep divisions, all of which could have taken me in an entirely different direction.

9. Fortunately Philco and ITT failed at their computer efforts, thus inspiring me to want to join a company that might have staying power - IBM.

10. IBM's competing projects to the System/360 not interviewing?

11. I took a flyer on the guy who couldn't tell me what he was working on and walked into the beginning of OS/360!

No strategy, no plan, perfect result! Somebody up there sure is looking out for me!

Chapter Two: Early days at IBM

Initiation

I joined what at the time was called the NPL Operating System development group in April 1963, one full year before the announcement of the System/360, and four years before the multiprogramming version (MVT) was initially delivered. We were situated on the second floor of the 705 building, the System Development Division (SDD) laboratory. It wasn't until the announcement on April 7, 1964 that we knew that the product line would be called the System/360 and the operating system OS/360. I will refer to it as OS/360 for the remainder of this document. There were maybe 30 people in the department at the time, most from the recently concluded Stretch development project and a few from England's Hursley labs. I guess because of my I/O background at Philco I was placed in the Data management group, at the time consisting of four guys from Hursley and me. They seemed more interested in sophisticated things like "buffering" and "formats", etc and not interested in the hardware so I naturally migrated to the hardware I/O requirements of data management.

In the 705 building was the biggest data center I had ever seen, as it contained at least one of every second generation product line in order to provide the second generation software groups test capability. And there in is an example of fundamentally why IBM needed the System/360. IBM was dominant in an industry known as IBM and the seven dwarfs - GE, RCA, Honeywell, Univac, Burroughs, CDC, and NCR. IBM's second generation products were very broad, very successful - and incompatible. The 7070/7080s for commercial Cobol customers. The 7040/ 7044/ 7090/ 7090/ 7094 for scientific Fortran customers. And Stretch for the really heavy customers. The 1401/ 1410/ 7010 lower end systems for unit record and "online". All of these systems were fragmented at IBM as they, in general, had their own software/ hardware/ peripherals/ documentation/ sales/ support organizations. Even though IBM had doubled its revenues every five years, since the first world war, internal costs were growing at an even faster rate. IBM decided that they needed a common product line that would satisfy all these customers - commercial or scientific and large or small. Thus the System/360, OS/360, and PL/1. The System/360 name was designed to imply support for all points of the computing compass. It was fundamentally a defensive move by IBM initially that turned out to be brilliant for the customer base - and, obviously for IBM. The concept of such scalability and compatibility revolutionized the industry thinking at the time, even though the resultant development fell a little short of the concept. At the time around $4B per year in revenue, it put IBM on the growth path towards $100B per year.

But did they ever underestimate the size of the Programming effort. I have heard that it went from an estimated $125 million to $500 million. In today's dollars the $500 million is more like $4B! I don't know first hand the numbers, all I know is it was seriously underestimated!

IBM was a great place to work. They had never had a layoff nor had a union gained a foothold anywhere in the company. They treated their employees so well, a union never had a chance. Now I cannot speak to the troubled IBM of the post 1980s as I left in 1967. IBM had a golf club in Poughkeepsie (and other major sites as well). All employees could join for a $1 fee. Of course, there was no alcohol allowed in these clubs. I had played a little golf over the years, never mastering it in the least but it was fun to get out. The IBM golf course was very hilly. Almost every hole on the front nine had elevated tees and greens. To make matters worse, after nine holes of climbing these things, you were at the far point from the club house. If you wanted to quit at this point, you still had to traverse a tenth hole that had a green that was only about 100 yards away (horizontally), but maybe 50 yards above the tee on a massive hill. After that, you had to continue climbing up the hill to get to the clubhouse. Where of course there was no Alcohol! My father visited once and played the course, and I believe came close to a heart attack. He had never seen a course like it. Needless to say, my Golfing career did not advance while I was in Poughkeepsie.

IBM hosted major events at the club on a regular basis for a very reasonable price. I remember seeing Godfrey Cambridge (who was an hour late), the Hague Philharmonic, and the Kingston Trio at the club. Poughkeepsie was close to the Berkshires in Massachusetts and Lime Rock in Connecticut. We saw Dave Brubeck one time and Theodore Bikel another time at the Berkshires. Also the Boston Pops with Arthur Feidler. All sitting outside at a table drinking, eating, and enjoying the entertainment. We also used to go to the Lime Rock race track to see SCCA sports car races. Sit on the side of a hill, nibble on goodies, and drink wine. Great memories.

Early associates at IBM

As other second generation projects wrapped up (1410/7010, 7040/7044, etc), the Control Program organization grew. I ended up working for a Project Coordinator named Bill Clark - probably the single most brilliant man I have ever known. After listening to him for a couple of weeks, I was convinced that I would not make it at IBM. They were just too smart. I understood about half of what he was saying, and only after a struggle at that. It turned out that I was ahead of everybody else who understood almost nothing! Bill and I became very good friends. An example of his capabilities: His wife was going for a PHD in Math, but was almost legally blind. So Bill attended classes with her, took notes, and probably was as knowledgeable about the subject as she was, but without the pre-requisite training! Brilliant man. Bill spent most of his time lobbying hardware engineers to get the necessary features in the I/O channel and control unit designs so that the I/O Control program could be effective. By the way, I will refer to this as the Input/Output Supervisor (IOS for short) henceforth. There wasn't anything that Bill couldn't do, and do well. For example he wanted an A frame house, so He bought a piece of property and personally built an A frame house. And, I mean personally! I am sure he had some help where one man couldn't do certain things, but basically he built the house himself. Amazing! We used to shoot pool together, and he introduced me to a new upscale beer - Michelob! Those were the days!

Bill and Harry Reinstein used to throw a frisby around in the IBM parking lot in front of the 705 building. I was watching them one day and I saw Bill leap in the air ala Baryshnikoff and proceed to disappear. He had gone off the edge of a grassy knoll and down a hill. Very quickly he reappeared doing his best Peewee Herman impression - "I meant to do that"! It was very funny, and fortunately no one was hurt. Harry and I met at a coffee machine one day. I forget what transpired but I (having been to Israel) was in the habit of instead of saying "thank you", I would say "Toda Raba". Harry responded with "Bavakasha", and the rest is history. We are great friends to this day. I used to say that I knew the five foot eight inch Harry when he weighed 125 pounds. In later life he weighed in at greater than 250.

Mike Saranga was my first cubicle mate at IBM. He designed and implemented Program Fetch. He went on to head up DB2 and IMS development organizations at IBM. Later he was a Senior VP at Informix.

Other friends to grow out of this project were Al Kolwicz, Larry Cohn, George Mealy, Carl Reynolds, Bill Vermillion, Paul Bouche, Jerry Friedman, Jack Frey, and Don Ludlow. Al, Mike, Bill, Larry, and Carl and I remained friends over after the Poughkeepsie days in spite of us scattering across the country. There were others, but I believe I have listed the most important. Please excuse me if I have forgotten anyone after all these years.

The OS/360 project sucked up all available manpower. From 30, it grew to almost 1200. Since IBM Field Engineering was going to take on OS/360 maintenance in addition to the hardware, several of their best people were moved to Poughkeepsie to work on development. Of course the Sales division had to have trained System Engineers in order to support their customers, so they provided high quality SEs to the project. And in addition, people like me were hired from the outside as well. The entire OS/360 project could be characterized in this manner, a bunch of kids taking on the biggest project of its kind ever, and not knowing what it is they couldn't do. The management positions were, however, filled by experienced people from the various 2nd generation control program projects. I don't remember anybody anywhere saying "this can't be done!". But of course, the magnitude of the project was seriously underestimated from the beginning.

As the project grew, senior management decided that there were just too many meetings going on and not enough real productive work. So they decreed that everyone must work an extra hour per day (paid OT of course). The problem was that many of us were already working more than eight hours per day (without paid OT of course), The edict caused people to watch the clock and leave after nine hours. The edict was quickly rescinded. Early in the project senior management also decreed that all managers should spend one hour per week looking at code from someone in their organization. Since I was the only one with any significant amount of code, Fred Brooks picked me in the first week. We met, he glazed over, and we spent the hour talking about design rather than code. I don't remember any manager actually spending an hour each week reviewing code, other than that one meeting.

Over time Bill Clark moved on to other areas of the project, and I reported to another man (forgot his name) who was more hardware oriented and responsible for interfacing with the hardware engineers.

Early Development activity

As I worked through the design for IOS I felt overwhelmed by the sheer magnitude of the new approach to Input Output. Instead of having tape channels dedicated to tapes, Disk channels dedicated to Disks, etc, there were channels dedicated to being just that - channels. A standard architecture against which all devices could be designed. In addition there was a multiplexor channel that was designed for slower speed devices such as card readers and printers. The interface was the same basically, but more restrictive. My job, as I saw it, was not to have tape support, disk support, unit record support, etc; but to be a channel scheduler. The only exception was in the area of device error routines, which required device specific procedures. Halfdan (Dan) Storm did a great job creating these error routines.

The System/360 I/O configuration possibilities were endless because device control units could connect to multiple channels. IOS had to be able to test each unique path for a device until an available path could be found. A path could be blocked by a busy channel, or a busy control unit, or a busy device. If all possible paths were busy (and the flexibility provided to the purchaser of the hardware was extensive), the request had to be queued and restarted when a path came available. There were various asynchronous interrupts that could appear - channel end, device end, and control unit end to add to the complexity. While I/O requests were queued up and processed, the requester was free to continue processing. At some point later when the request was complete, a posting operation would respond via control block that the requestor could "Wait" on when it pleased him.

Anyway, the combinations were endless. Since IOS had to impose the minimum overhead possible, I decided that when the user installed his system he would Sysgen an IOS custom tailored for his unique IO configuration. In other words the generated code would "know" the configuration and thus not have to search tables in order to find out. This enormously complicated the Sysgen process. A field engineer assigned to my group named Jack Frey was assigned the Sysgen responsibility for IOS and was magnificent.

As I studied and designed, I came to believe that I needed to build a prototype to test out my design ideas. There were, however, no System/360s as yet. At the time there was a System/360 assembler running on Stretch as well as a System/360 emulator. I lobbied my boss to let me build a Prototype IOS, and after much debate he said OK. So I went to work on it in the second half of 1963. More about that later.

In November, I was fortunate enough to be invited to a five day seminar presented by Fred Brooks (Chief System/360 Architect) on the System/360 CPU product line. It was an unbelievable experience. He was spellbinding. The architecture he presented consisted of five compatible systems as follows:

1. Models 30, 40, 50, 60, 62, and 70 totally upward and downward compatible.

2. Each system was individually designed with technology and techniques focused on its design point.

3. The model 30 was a low end system with technology that would allow it to compete with the Honeywell 200, which with its 1401 liberator was causing problems for IBM's 1401 system.

4. The model 70 was a high end system with high speed technology that was targeting the CDC 6600 and Univac 1108 competition.

5. All systems had the same instruction sets and channel architecture with the idea that a common operating system would be developed for all.

Each system was designed by a separate dedicated Engineering teams around the world and was to utilize technology consistent with its cost and performance design point. All systems were to adhere to the same external architecture regardless of its design point. For example, the model 30 would use micro code to save cost to implement the instruction set, while the model 70 would use high speed component technology in order to achieve the required performance.

Let me just say here and now, this last goal was not possible at all. Upward and downward compatibility and a common OS were not feasible. The model 30 had be a compromise that carried model 70 like features and thus became overpriced. The model 70 was restricted to what the model 30 could provide, thus restricting its feature set in its competition against the competitor's heavyweights. The idea of a multitasking operating system that could run in 16K on a model 30 was out of the question. I won't go any further with this at this time, but these limitations led to a proliferation of incompatible CPUs and operating systems. More on this later.

Fred Brooks

By Friday afternoon I was burned out, and took the afternoon off. I went to a HIFI store in Newburg N.Y. to listen to a Sherwood FM tuner that I was lusting over. It was Friday November 22, 1963, a couple of hours after lunch. And yes, while I was listening, they interrupted the broadcast to announce Kennedy had been shot. I heard later that someone had come on stage and handed Fred a note. He read it, put it in his pocket, and continued lecturing until he reached a break point. He then reached in his pocket and read the note concerning Kennedy to the audience. I do not know whether they continued after that or not.

At one point early in the project there was a general meeting at which Carl Reynolds, head of all Programming Systems, addressed the entire OS/360 Programming Organization. I do not remember anything about the meeting except the joke he told to start his presentation. It seemed that an IBM salesman and a programmer went on a hunting trip. At the end of the day they entered a cabin at which time the Salesman said he would go get them something to eat. A while later, he opened the door and a large Tiger ran into the room. The salesman shouted to the programmer - "you skin that one, and I will go find another"! Of course, in our case he was talking about OS/360.

Some fun Activities

In 1963, I decided that as a family man, I needed two cars instead of the Jaguar and sold it to a VP from Macy's in New York City. I remember coming back on the train from New York City to Poughkeepsie with a $3,000 check - the biggest check I had ever seen in my life. I bought a used 1961 Oldsmobile convertible as a "family car", and a used 1960 bug eyed Austin Healey Sprite to commute the 1.2 miles to IBM from the apartment on route nine, and I put a few hundred dollars in the bank.

The two door Sprite had no hood lid, no trunk lid, no rollup windows, no door handles, and of course no locks. It had sliding plastic horizontal curtains for windows. It was nicknamed "bugeye" because it had two huge protruding headlights. The entire front end lifted up to get at the motor, and there was a storage space behind the two seats. I was told that in the winter the window curtains would freeze and I would not be able to reach the inside door handle to open the door. I purchased a dog leash, a shower curtain ring and a pulley. I attached the pulley via the shower curtain ring to the lower part of the inside door panel, the dog leash to the door handle, ran it down through the pulley and up and outside under the window curtain. From the outside, I could yank down on the dog leash, which pulled down on the door handle and open the door. I spent the next three years driving around with a dog leash flapping on the outside of the car. The windows did freeze up every winter - but I could get in to the car! I would drive the entire winter with the choke fully on all the time and still got 25 MPG! I would install the hard top for the winter and remove in the spring. I never put the soft top up in the entire time I owned the car. If it rained, I could attach one button of the tonneau to the top of the windshield over me, and drive the 1.2 miles hunched over, but dry! One time coming back from our Tuesday bowling league, having had too much beer and light snow coming down, I spun out. My friend Al Kolwicz was following and watched my 360 and I was laughing through the whole process. A couple of blocks later he watched me drive down a one way street in the wrong direction and get stopped by a cop walking his beat. The cop asked me if I knew I was going the wrong way and I said no. He then proceeded to helpfully point me in the right direction and walked away! Al had expected to have to follow me to the local police station. I purchased a 1965 Sprite that actually had rollup windows, door handles, locks, and trunk and hood lids! I sold the bugeye to Mike Saranga who drove it back and forth to Columbia University twice a week while he got a Masters degree. He ultimately put his foot through the floor as the bottom of the car had rusted out!

My friends decided to have a backyard barbecue at George Mealy's house late that summer of 1964. It was catered and quite an affair. Carl Reynolds was there and introduced himself to me. He said something like - "I hear you are the guy with all the code running". I was quite flattered that he knew that. Then I noticed that Harry Reinstein was steering Carl around the back yard with anecdotes such as this, so Carl could be aware of individuals. Anyway, I knew Carl well socially thereafter and he became a mentor after IBM - he hired me to Hughes Aircraft, and ultimately recommended me as CEO of Boole and Babbage. Later that winter we had a similar party at a house up in the mountains. At one point I was outside having a snow ball fight with Bill Clark when someone stuck his head out the door. I flipped a snowball behind my back and hit him up the side of the head and he immediately retreated into the house. It turned out to be Fred Brooks! I was appalled. When I went in later I asked Larry Cohn what had happened when he returned and was told he was very happy and said - "All I did was stick my head out and ….". He felt like one of the boys, which by his nature was not his normal style.

George Mealy, Harry Reinstein, Larry Cohn, Al Kolwicz, Bill Clark, and I used to regularly get together for a boys night out at George's house. We would cook steaks, drink beer, and play the stereo loud.

Bill Vermilion was another of the characters around. He used to come over the apartment to watch "Man From Uncle". He was the only person I ever knew who actually worked the Sunday New York Times crossword successfully. He used to have a phone conversation every Sunday with his father to discuss the crossword. Bill was a really smart man. Unfortunately he died young I understand.

At one of our parties, a guy I worked with tried to pick up my wife, and she said "can't you tell I am pregnant?". He exclaimed "are you Jack's wife?" She had a ski sweater on and didn't show much even though she was eight months along. About two weeks later her water broke at the NY world's Fair in Long Island, and my son was born.

One time several of us went to Madison Square Garden to see an NBA doubleheader. Yes, they used to have such things to drum up interest. The Knicks and Lakers in one game, and the Celtics versus ? in the other. I don't remember much accept the Lakers were dog tired and only had six or seven players. Jerry West had something like 40 points in a losing effort.

The author, seated, with Bernie Witt, circa 1965, look at the thin ties!

Chapter Three: Prototype IOS (PROTIOS)

I develop the Prototype

I started work on the prototype IOS (PROTIOS) in the second half of 1963. Since there was no System/360 hardware yet, this work had to be done on an IBM 7030 stretch which had an assembler and an emulator for the creation and testing of System/360 code. The IBM 7030 Stretch system was in the 701 building, the main manufacturing building for IBM's large mainframe systems. Stretch was the most powerful computer in the world, used for weather forecasting, and anything that required major CPU processing power. It had government applications as well. The process consisted of the keypunching of source code, assembling it with the assembler, basic tests via the emulator, and then ultimately punching out a binary deck load module for execution on a System/360 itself. Initially, there was no such System/360 available. The first one (a model 40) didn't show up until sometime in 1964 as I recall. So I spent several months going back and forth from the 705 building to the 701 building for test shots.

My idea for the project was to write code as close as possible to my preliminary IOS design spec. To test it I would write a series of "apps" that would - "GetNextCard", "PunchNextCard", "PrintNextLine", Write to the Console, Operator Interrupt routine, and Write/Read/Rewind Tapes. Also an app that would access the disk support, although I couldn't test that on Stretch. In addition, I needed an IPL (boot) process, a dump program, and an event trace so I could debug the very interrupt driven asynchronous nature of the System/360 I/O. In other words, I could rely on the availability of absolutely no debug tools on the System/360 when a system finally showed up in the Data Center.

The System/360 had a hardware service call function called an SVC call. It was the fundamental way that an app could invoke various control program functions. IOS had one such call - the Execute Channel Program call (EXCP). The OS/360 task supervisor had calls for Waiting (WAIT), Posting (POST), and Exiting (EXIT). All of these would ultimately be implemented via SVC calls to the supervisor. But the SVC numbers of course at that time were not assigned. So I went ahead and assigned my own in PROTIOS, naturally starting with zero!

SVC 0 - EXCP

SVC 1 - WAIT

SVC 2 - POST

SVC 3 - EXIT

These assignments became the spec and became standard for decades to come, to this day I would expect! So you can blame it all on PROTIOS!

I implemented the design spec then in existence for all these calls in PROTIOS.

While I am over at the 701 building, I had a sense that what I was doing was being watched. In any event, the manager of the system tools group was there. he was responsible for creating the initial test bed so that compilers, job scheduler, and a myriad of components could be tested. His efforts involved a small System/360 OS that had been created in Hursley, England called - wait for it - the Hursley Monitor! It had no resemblance at all to the design of OS/360, but the plan was to somehow use it in the test center as the base for testing. It was Al Kolwicz's job to get that done. Al and I met in the Stretch data center in 1964 and have been life long friends ever since.

Al began to realize that basing the test system on a prototype of basic I/O calls to OS/360 was preferable to using the Hursley Monitor. So we started collaborating. Al had two guys working for him, Hernan and Duane as programmers. Over time we specified a minimum job scheduler so that jobs could actually be loaded and terminated and a series of support routines that assisted operations and developers.

Every Wed night my wife had a dance class and Al's wife had a bridge club. He would come over and help me baby sit so we could think up new ideas for Duane and Hernan. Al would drive them crazy every Thursday morning with our ideas!

Originally IBM believed that after moving the second generation support from the 705 to another plant, they would free up the required office and the data center real estate for the OS/360 development effort. They planned on four model 40s for the development staff to use for testing. They couldn't have been more wrong. They ended up building a new building (the 706) next door with a data center the size of a couple of football fields and System/360s of various size along with all the peripheral devices as far as the eye could see.

So sometime in the first half of 1964, the first System/360 (a model 40) shows up in the newly built 706 data center, so I finally had a real system to work on. Around this time, we all moved to the 706 building as well. The Model 40 sat in one corner of this humongous raised floor and looked very lonely.

The first thing I had to do was debug my IPL process, so I could at least load binary decks into the system. I couldn't load anything, including debug tools, until that worked. Once that was done, I needed to get the dump program working. I quickly realized that the second generation printer attached to this system was not very fast or reliable. So I wrote three versions of the dump program - one to the printer, one to the 1052 console, and one to the card punch. I could take the punched out deck to a 407 off line EAM printer and print the dump there. More times than not this is the route I took. Along the way I had to help debug the CPU instruction set, as I remember, the Move immediate instruction was malfunctioning. Also, since every test session had to be preceded by a run on Stretch to make source changes and create a new binary deck, the process was cumbersome. I ended up using a manual card punch (example displayed below) to actually punch individual holes in the binary deck and used tape to plug up holes in the cards I didn't want. This process saved many trips to Stretch for minor changes. When the first Winchester Disk Drive showed up, I wrote an app that just did a bunch of sequential seeks to the disk. When I ran the test it stopped half way through. The trace showed a command hung out with no interrupt indicating completion. The next debug session did the same thing, so I went over and banged the drive, and it suddenly continued on! The arm was hanging up halfway across the drive! All in all, a really challenging but very satisfying time.

PROTIOS runs the Data Center

PROTIOS began to take shape, we had a full blown user manual, Al's guys were really moving along on PROTIOS based tools, and more systems and test tools were appearing on the raised floor from IBM development, so the data center got much more interested in what we were doing with PROTIOS.

PROTIOS became the operating system for all the systems in the 706 data center and also in other IBM development centers around the world until the first version of OS/360 came available.

The OS/360 development plan included using a 7080 based system called ATP for managing the source code, assembling, and linking the binary load modules. It would provide massive disk storage, backups and versioning support for the millions of lines of code to be developed. Since I was the only one with any large amount of OS/360 code, by now almost a full tray of about two feet of punch cards, they were very interested in my using the system as a guinea pig. Since I didn't trust anything I couldn't put my hands on and take away (I had never even seen a disk before), I demanded that I take their backup tape with a copy of PROTIOS with me after every run. They were not happy about that, but acquiesced to my paranoia. So now my source would be assembled and binary output created (a bootable tape using my bootstrap code) on the ATP system, and trips to Stretch were no longer necessary. It all worked out.

A few years ago I was at a Seattle Mariners baseball game and met a guy who said he was an old timer in the System/360 universe. I said "so was I, what did you do"? He said he had worked at IBM's center in the Time/Life building in NYC. He said that he was so early in the game that he actually had used "PROTOS" (no typo here, that is what he said!). I said " no it was PROTIOS and I wrote it!". He was floored!

At one point Arthur K. Watson, Thomas Watson Jr's brother, came to take a tour of the lab. He was President of IBM World Trade at the time. Management wanted some one to be doing something active on a system for the tour, so I was selected to represent the development group. Watson asked me what I was doing, and I told him I was debugging a problem with my code. I had the sense that Carl Reynolds, who was nervously conducting the tour, was very concerned about what I might say about the development effort under way.

Every Friday night, a bunch of us used to go to the Treasure Chest, a cocktail lounge and restaurant in an 18th century house (I do not believe they claimed that George Washington slept there) and drink Mai Tais. Marty Belsky used to entertain us by reciting "Casey at the Bat", word for word from memory. Enough said about that. One evening Al and I were called over from the Treasure Chest to handle some problem in the data center, and being a little worse for the Mai Tais we made a slight change to PROTIOS. When it came up it would pronounce itself ready by typing a message along the lines of "PROTIOS Ready". We changed it to "PROTIOS Fnurling!". Nobody knew what it meant and I am not sure we did, but it was a term out of the Science Fiction books we were all reading at the time.

In later years my boss Larry Cohn tried to have authorized an IBM Outstanding Contribution Award (OCA) for PROTIOS, but for some reason it was denied. Maybe they did not want to encourage people to work outside the box they were assigned to, I don't know. Anyway I was in the first group of 25 who received an OCA for System/360 contributions. It was for my work on IOS. OCAs were much coveted at IBM and only the best of the best received one. Money, a dinner ceremony, gold cuff links (which were later stolen from me), a silver nut bowl for the wife and a framed certificate (not printed in time for the ceremony) signed by Thomas Watson Jr. were involved. I left IBM a short time later and before the certificate had been delivered. I joined a small consulting company founded by ex IBMers. My immediate boss was Bill Debs who had been a documentation manager at IBM Kingston. One day Bill said that John Haanstra, a very senior executive at IBM, was coming to see me. It turned out that he hand delivered my OCA certificate from IBM to me in a little ceremony in my boss's office. That was the way IBM operated. Haanstra, who later was GM of GE's computer division and killed in a plane crash, had driven the 25 miles to downtown D.C. to personally deliver the certificate even though I was no longer an IBM employee. Amazing! I still have the framed certificate.

Chapter Four: IOS Implementation

At this point I had the prototype IOS running and was very happy with my design. I had learned a lot, and proved a lot. Now it was time for Alpha test.

The reader is surely familiar with the term Beta test as it is used in the technology world. At IBM we had a process called Alpha test. This test consisted of the Product Test department reviewing the complete set of specifications in order to ascertain feasibility of the design. Every OS/360 component had test personnel assigned by Product Test to the task. Discovered problems were assigned Defcon like codes for severity. Type one total failure, type two serious, type three minor, type four documentation, etc. I can't remember all the codes but you get the point.

I had written a full specification of the IOS design, probably 100+ pages including detailed flow charts. Since I had a prototype running, there was never any doubt about the pass/fail rating of IOS. It certainly was feasible. Actually, I caught a lot of errors in the spec and alerted the tester so he could fill up his quota with type three and four errors. There never were any serious or failure type errors. IOS passed Alpha test with flying colors.

Speaking of specifications. IBM had something they called the development workbook, with sections assigned to each component - IOS was section 14.90. Everybody had a copy. At its peak, the end to end length of the workbook was at least five feet! Thousands of pages. Every day updates were distributed to everybody. It was a real painstaking process to go through the workbook and keep it up to date on a daily basis. I remember Al Kolwicz studiously reading every page of every update every day, in order to keep up with what was changing. On the other hand, Don Ludlow refused to update his or to throw the updates away. One day I saw his stack of updates had risen past the five foot high partition separating our offices!

Speaking of partitions, the noise level on the second floor of the 705 building was incredible since the partitions separating offices did not go all the way to the ceiling. Conferences, telephones, meetings, conversations made concentration difficult. We complained and complained but nothing was done. Don came up with the idea of acquiring a pair of those headsets that you see airport tarmac workers wearing. He ordered one for me as well. For several weeks people would see us working away with these headsets on. IBM get the point and added transparent plastic that filled in the partitions to the ceiling!

After passing Alpha Test, I decided that IOS should be completely rewritten. In fact it was, and was the only component of OS/360 that had two complete implementations prior to release to the public. And even if I do say so myself, the quality showed across all aspects of the component. When OS/360 was finally released, not one line of code was written by me. I went from possibly having more code running on the System/360 than anyone in the world to none. There are people from that era who I am sure would not believe that.

One of my reasons for the rewrite, besides the obvious benefit of a redo, was that I wanted to get into technical management as a career path. I was already a Project Coordinator, but that did not include any real human resource responsibilities. IBM had two parallel career paths available. One was staff technical and the other was management. Both had parallel titles and pay grades, so that either path offered good opportunities. In fact one could bounce back and forth on the way up as opportunities presented themselves. I wanted to manage the activities of my little team so that I could progress up the management chain.

Following is a description of Scott Locken's day as an example of what interested me. Scott was the third line manager responsible for the entire Control program, as opposed to Compilers etc. His day consisted of end to end meetings in his office from 8:00 AM through to the end of the day, day after day. In these meetings, he would listen to those involved in the debate or disagreement and finally end the meeting by opening up his Engineering notebook, giving out instructions for whatever follow up or decision he had made, documenting them in his notebook and then ending the meeting. This went on meeting after meeting on all kinds of subjects. At the end of the day, he would meet with his secretary (Charlene I believe was her name) and dictate follow up documentation and assignments to her. I am not commenting on the quality of his decisions, but the process, but every meeting ended with a decision or assignments . I learned a lot from him, although no way was I interested in end to end meetings. The more technically competent in the fundamentals of the subject the more effective this kind of decisive decision making becomes. I wanted to be in a position to make such decisions and direct activities.

On the other hand, I believe that remaining technical competent, but consistent with your management level is important. If you don't, then it becomes more difficult to make good decisions. More decision making of necessity by consensus, more time wasted in committee action. Some of Scott's activities were influenced by this problem, as he had not been personally active in the design process. I believe that examples today are the differences between Bill Gates and Steve Ballmer at Microsoft and Steve Jobs and Tim Cook at Apple. Microsoft has definitely suffered, and I believe that Apple will.

With all the code I had written many thought that it would be impossible for me to delegate and leave people alone. They believed that I would not be able to handle their inadequacies. I responded with - the leverage that a group of 4 would give me. For example, if they were half as productive as I was they could get twice as much done as I could get done alone. In fact my group was significantly more productive than that - significantly more.

My little group of four people had no one who would be viewed as an experienced system development designer or programmer. Our major strength going in? We didn't know what we didn't know!

Jack van Kinsbergen (me) - basically non IBM hardware field engineering

Don Ludlow - Chemical Engineer

Bill Bautz - no more experienced than the rest of us

Dan Storm - Swedish hardware field Engineer, the wickedist Chess Player I ever saw!

Jack Frey - hardware field Engineer

I called my group together and carved up the development effort as follows:

EXCP Supervisor - Bill Bautz

Interrupt Supervisor - Don Ludlow

Error routines - Dan Storm

System Generation - Jack Frey

I told them that I wanted them to completely rewrite what I had done. I handed over my specs, flowchart, and code, and turned them loose. After a while, Bill came in and complained that Don would work late into the night and sometimes change Bill's code in the EXCP Supervisor. I looked at what Don was doing and he seemed to be correct in the changes he was making. I asked Bill if he wanted to take responsibility for the Program Logic Manual (PLM), which is the detailed documentation of the design and to be used by those who will follow us to maintain IOS. He jumped at the chance, he really wanted to do it. He did an excellent, excellent job. I believe that IOS was the only component that had a full time programmer responsible for the PLM who worked closely with the Tech Writer assigned to the group. In most (if not all) groups the tech writer had to dig out the information. The result of this collaboration on IOS produced the best PLM I believe that came out of the original OS/360 effort. Don was happy to have total control of the code, and he as well was magnificent and went on to a significant career at IBM, ultimately in Raleigh. Dan's error routines were flawless and Jack Frey's efforts with Sysgen produced exactly what I wanted. That is, operational code that knew exactly what the configuration was and thus was not table driven. This design saved precious microseconds not only at the critical Interrupt processing time, but throughout all IOS processing.

An aside here about OS/360 design focus. I believe that most designers focused on creating the best design they could, but ignored the messy cleanup things like Abend, Security, Boot time, Checkpoint/Restart, Rollout/Rollin, and System Generation. These were cleanup type items and the responsibility of other groups. The problem is that these functions needed to be included in the basic mainstream design and without that, they become difficult to patch on after the fact. I was an example with my attitude to Sysgen. I did not care what impact my design had on the Sysgen process, the purity of my design trumped all such considerations! Jack Frey did a magnificent job under these conditions. A modern day example might be all the after the fact patching required to deal with Internet Security. I wonder how much effort the original designers put into that subject?

One of the objectives of OS/360 was to have a version that would run in 16K of RAM as part of a 32K system. And I am not talking about Megabytes or Gigabytes, but Kilobytes. Towards the end of this impossible task I remember being in one of Scott's famous meetings to help decide the future of that effort. I was told that the IOS in that version was going to be 1000 bytes, how big was mine going to be. I said "1500 bytes". They said, "no, no, it is going to be 1000 bytes". I said "no, 1500". They ultimately realized that OS/360 could not be squeezed down into 16K bytes and gave up trying. This is why the Disk Operating System out of Kingston (DOS/360) became so wide spread on the Model 30. It was simpler and small enough to fit. It also was incompatible with OS/360, a large chink in the idea of upward and downward compatibility of the System/360 product line.

Speaking of the size of OS/360 in general. One of the things that they wanted to take out was my internal trace. This trace showed program, task, and I/O flow and was indispensable to debugging such an asynchronous system. It was usually about 100 entries that wrapped around so it only contained the latest entries, but that was usually enough. Of course it was out of the question in the 16K system, but Scott called me in one day and said he was going to eliminate it in the final release of the full OS/360 as well. I told him not to send any problem dumps to me or anyone else if he did that. He finally agreed to make it a Sysgen option for the customer. I believed that every customer must have, of necessity, included a trace table!

Regularly, various departments would come to me with requests for unique code to be included in IOS for their special needs. I maintained that IOS was an independent service that was requestor independent as well as device independent (except for error routines, and disk support). It managed requests for activity on System/360 channels and that was it. I had to admit though that these groups did have legitimate issues, so I invented what I called Appendages. Following is the current Webster definition of an appendage, giving you an idea of my thought process: "an adjunct to something larger or more important”. I included this definition in the specification in the development workbook! I always tried to have some fun in my work! Basically I defined specific points at which I would interface with snippets of OS code that would be loaded when the user issued an Open command and deleted when it went away. As I remember, there were interfaces at Pre Start I/O, Post Start I/O, PCI interrupt, Channel End, Device Error, and Device End. There were just a few controlled things that Os/360 components could do with these snippets. To handle the table lookup overhead, the load address of such routines was inserted into a user control block (DEB) by the OPEN routine. If there was no such routine, an address that pointed right back to IOS was inserted. So the interface was one branch instruction and no added lookup.

Appendages were an elegant solution that maintained the purity of my design. And of course that was paramount to we elitist designers! Speaking of such things, we regularly said such things as "refusing to prostitute ourselves", and we "Groked". This is a term created by Robert Heinlein in his 1961 Science Fiction book "Strangers in a Strange Land". Definition from Wikipedia - "Grok means to understand so thoroughly that the observer becomes a part of the observed—to merge, blend, intermarry, lose identity in group experience. It means almost everything that we mean by religion, philosophy, and science." When you Groked, you understood in fullness! Remember I said that we were into Science Fiction at this time.

The result of all this is that IOS was a shining star in the universe created by the early releases of OS/360.

Chapter Five: PCP versus MVT

System/360 Delivery problems

IBM had announced the System/360 product line, powered by OS/360. It was to come in 3 flavors:

1. OS/360 PCP - A single task system running one single tasked application at a time.

2. OS/360 MFT - A partitioned system that could run multiple single tasked applications at a time.

3. OS/360 MVT - A Multi tasked, non partitioned system that could run multiple multi tasked applications at a time. This was the true OS/360 as envisioned in the original Concepts and Facilities manual.

However, as time went by, management realized it had bitten off more than it could chew with the OS/360 architecture. Hardware was coming together and becoming deliverable, but the Operating System software was not. If revenue goals for 1966 were to be met, something had to change. The answer was DOS/360 and its cousins.

The following is from Wikipedia, the free encyclopedia.

IBM was forced to quickly develop four additional systems:

BPS/360 for machines with at least 8KB of core memory and a punched card reader,

BOS/360 for machines with at least 8KB memory and a disk drive,

DOS/360 for machines with at least 16KB memory and a disk drive,

TOS/360 for machines with at least 16KB memory and a tape drive.

When OS/360 was finally released, a year late, it required at least 64KB of memory. DOS was designed to use little memory, and could run on 16kB machines, a configuration available on the low-end S/360 model 30. Unlike OS/360, DOS/360 was initially a single-job system which did not support multitasking. A version with multitasking, supporting up to three memory partitions, requiring 32kB of memory was later released. Despite its limitations, DOS/360 became the most widely used operating system for processors with less than 256KB of memory, because DOS/360 ran well on System/360 processors which medium-sized organizations could afford; and it was better than the "operating systems" these customers had before.

DOS/360 was the operating system which filled the time gap between the announcement of the System/360 and the availability of the intended operating system, OS/360. As a result of the delay, a number of customers implemented DOS systems and committed significant investments to run them. IBM expected that DOS/360 users would soon upgrade to OS/360, but as a result of those investments, they were reluctant to commit to such conversion. IBM then needed to continue to offer DOS/360 as an additional operating system.

All of this DOS activity was primarily happening in the IBM labs at Kingston N.Y. This was a direct fallout of the inability of Poughkeepsie to squeeze out a 16Kb version of OS/360 to fit in a 32KB system/360 model 30. TOS/360 was used on System/360 model 30s circa 1965. DOS/360 was delivered in 1966 and due to the availability of 2311 and 2314 disks quickly became the dominant Operating System for the model 30.

From a tactical point of view, that is IBM making money in 1965 and 1966, DOS/360 was a requirement. From a strategic point of view, it fragmented the System/360 market internally and externally in much the same manner as the second generation systems had.

The reader is encouraged check out Appendix two to see how this fragmentation continued with the System/360 over the years.

If, in fact, IBM had realized all this from the start, IBM might have:

1. Not constricted the Model 70 to be downward compatible with the model 30.

2. Had a faster head start in Kingston on the DOS/360 system

3. Not diverted resources to try to squeeze OS/360 down to 16K.

As it turned out, the System/360 model 30 was a success against the Honeywell 200, and DOS/360 allowed IBM to sell System/360 hardware in 1965 and 1966. The problem was how far up the food chain was DOS/360 going to go? IBM really needed OS/360 to sell more powerful models of the System/360.

Fortune ran a lead article on IBM in this time period calling the System/360 IBM's $5,000,000,000B gamble, and it was. The success was dependent on a few of us in Poughkeepsie, for without OS/360 it was in big trouble.

Once things settled down after OS/360 delivery and improvement, IBM then entered a predictable life cycle pattern based on an eight year life Cycle, with a midlife kicker dictated by the depreciation cycle of the base technology investment. See appendix four for an analysis I did of this in 1979, remembering that I have no idea whether this still holds for the period after I retired in 1991.

OS/360 PCP becomes the overwhelming Priority in SDD

And, in fact, any OS/360 would do! So, in 1965 and 1966, the vast majority of resources of SDD in Poughkeepsie went into the development of PCP, to the immense detriment of MFT and MVT. MFT was killed altogether, and MVT reduced in manpower and computing resource allocation. Also, a major design change was approved in MVT and is described as follows.

The System/360 did not have appropriate hardware support for the support of relocation until Virtual System support was introduced in the System/370, and then MVT became MVS. Initially MVT allowed all applications to intermingle in memory. Page Faults would occur and be handled as required. However, jobs that might run one day, might not run the next due to a different mix of jobs in the system. Rogue applications could clog everything up. Also, the Abend, Rollout/ Rollin, and Checkpoint/ Restart functions were next to impossible to implement. The change was to create dynamic partitions assigned at job startup. Once a job acquired its partition, it had not only a guaranteed amount, but a maximum on its usage of memory. Thus MVT introduced dynamic partitions, with multitasking within each partition. This was as opposed to the MFT design which was fixed partitions each with single tasking. And PCP, which was a single partition, with a single task.

PCP was first delivered in mid 1966, but the genie was already out of the bottle with the various flavors of DOS/360 populating the low end of the System/360 product line.

When OS/360 PCP finished Beta test, Product test declined to approve its release. Given all the above, IBM said thanked Product test for their effort and released OS/360 PCP version 1.0 anyway!

In addition, in spite of being canceled, Tom McCallister single handedly kept MFT alive in Kingston. IBM ultimately relented and introduced MFT towards the end of 1966.

Because of the PCP resource focus, MVT was not delivered until late in 1967. It took a few releases and a few years to get the bugs out of all these products.

The effect of all this on IBM's Revenues and Profits was:

Year Revenue % Growth Profit % Growth

1963 2.86B .364B

1964 3.23B 13% .431B 18%

1965 3.57B 10% .477B 11%

1966 4.24B 19% .526B 10%

1967 5.34B 26% .651B 24%

1968 6.88B 29% .871B 34%

Revenue and profit growth for IBM slowed in 1964 and 1965 as they struggled to keep the backlog of second generation orders in the face of the announced but undeliverable and System/360. In 1967, as OS/360 PCP, MFT, and MVT were delivered in late 1966 and 1967, revenue and profitability growth improved significantly.

Since customers had to rewrite their applications to take advantage of the System/360, why didn't customers migrate to the seven dwarfs? I think that there were a couple of prime reasons. First OS/360 had the promise of emulators that would run most second generation software on selected System/360 models, albeit somewhat degraded in performance. This was an interesting transition hook for the customer. Second, I believe that the overwhelming nature of this revolutionary approach of a family of systems with compatible upward scalability really was of significant value to the customers, in spite of the delivery delays and early release trials and tribulations.

The most interesting approach to competing was taken by RCA. They introduced their own family of System/360 "compatible" systems - the Spectra 70. The systems were only compatible with non privileged instructions of the System/360. It ran its own operating system, with a totally different API. They set up shop in a Poughkeepsie Motel and contacted the manager and key developer of almost all OS/360 departments. They hired exactly one programmer from that effort. I guess they were trying to be a second source to IBM? It didn't work out for RCA.

I make Manager

Sometime in 1965, Al Kolwicz transferred to the IBM lab in Boulder, Colorado. He had been manager of the MVT Supervisor development group of about 8 people and had reported to Larry Cohn. Larry, as second line manager responsible for MVT development overall, reported to Scott Locken. When Al left I was promoted into his spot, but with the additional responsibility for IOS and Program Fetch. In other words the development of all the resident supervisor functions of the MVT operating system was now my responsibility.

Since we were well into the implementation stage, the design was complete. As a good manager should, I realized that my primary responsibility now was not to lead a design team, but to ensure that my group had the resources necessary to implement their code and to "have their backs". So I spent a lot of time thinking about how to get them the resources they needed in a time when MVT resources were being squeezed by the major thrust to get PCP out the door. As much as anything this really was a fight for machine resources and a reality that making the available machine resources as productive as possible was a priority.

Making Development Programmers More Productive

My group would get test shots as available from the 706 Data Center managed by Nelson Barnett. Since we were testing resident nucleus code, we could not utilize the normal batch oriented PROTIOS job flow of the data center. We needed stand alone testing time, and in the rush to get PCP out the door that was very difficult to obtain. I would constantly pester Nelson Barnett to get whatever scraps of time we could. Finally I suggested that he give me one of his model 40s and four operators of my choosing and I would get out of his hair. I guess I was enough of a pest that he thought one model 40 for all of the MVT testing was a good deal and he agreed. Nelson was totally committed and laser focused on the support of PCP.

When a development programmer made changes, he followed this process.

1. Write changes on coding sheet, keypunch, insert into the ATP database, assemble and create an object module.

2. link the module into the base nucleus (for example memory management). IPL the test nucleus would into a System/360 and. Output would then need to be picked up in the data center.

Why should programmers be personally be involved in the second step? So we created a service with the model 40 and 4 operators (24x7 coverage) as follows:

1. A war room that housed a library of tests created to test PCP components, listings of the MVT nucleus, an area to store output, and some workspace. Obviously a crowded room.

2. We trained the operators to link changes into the base, run a set of tests, create debugging output, and recognize known failures to bypass as required.

2. The programmer would insert code changes and create object modules.

3. He would call for a test run, specifying the object modules to be linked, the test cases to be run, and any rudimentary failures to be bypassed.

4. The output would be stored in the war room for the programmer.

5. About every 10 days a couple of us would generate the latest "current" base which consisted of our latest nucleus and a PCP Job scheduler that could run tests. Other components were added as they came available, e.g., 360 assemblers, compilers. Then we could run their test cases as well to exercise the system. A full regression library was run after every rebuild to ensure that we did not regress the base with the new released nucleus.

This approach worked great. The programmers were more productive, the operators loved the challenge, and we produced a quality product.

I had a goal that programmers be able to call an operator and have them implement the changes to their source code, but we never actually got that far.

One of my fondest memories was one day working with George Bean, whom I had the utmost respect for, who told me I was a very good manager. I asked "why do you say that?" He replied "because you make things happen". I have never forgotten that comment on good management. "Make things happen!"

As another comment about Management, one of the appraisals I received from Larry Cohn (another for whom I had the utmost respect), while excellent contained a comment I have never forgotten. "Sometimes lets lower priority items slip unnecessarily". I have never forgotten that and try hard to at least pay some attention to such items. In reality there is no excuse for letting them slip.

Later on

Somewhere along the way, Scott Locken approached me and asked me to take over the Job Scheduler group. Even though Scott was a real charmer and liberally praised my contributions, I turned him down. I explained that regardless of how good I was at my job, the problems were beyond my ability to correct without a restart. Besides I was committed to MVT and Larry Cohn's MVT team. I am not sure that Scott ever really forgave me for turning him down.

Later in my IBM career I transferred to IBM FSD in Bethesda Maryland with responsibility for the integration of software on a project to build a multiprocessing version of OS/360 on a pair of model 65s. Having been successful with the "war room" in Poughkeepsie, I convinced FSD that we should recruit non technical personnel at FSD (secretaries, etc) and create a technician capability that offloaded mundane activities from the development programmers. We would train these people and create a cadre of operator/technicians. It worked very well and was very productive. John Haanstra, FSD wouldn't move forward with an expansion as he believed that all we were doing was training people who would quit and move down the road to CDC!

When I later ran the Corporate data center at Hughes Aircraft, I did exactly the same thing with several of our operators. We had a man dedicated to running a training course and created these technicians to be integrated into the various groups in my organization. Again it worked out great.

I received my OCA for the IOS effort in the second half of 1966 after my transfer to FSD. I stayed at FSD for about a year.

Chapter Six: Epilogue

The original capabilities of OS/360

In addition to the family of hardware products representing enormous capability, OS/360 was in its own right an enormously capable system. The "plumbing" provided a capability that was impressive for that era and, in fact, almost any era. This was the foundation for major systems development for years to come. Remember we are talking about the 1960s here. I will list just a few (and not in priority order):

1. Hardware Device Independence - the idea of a standard channel architecture for all I/O devices was a major component of the System/360.

Abstracted from the original 1964 System/360 Architecture Announcement:

An input/output system offering new degrees of concurrent operation, compatible channel operation, data rates approaching 5,000,000 characters/ second, integrated design of hardware and software, a new low-cost, multiple-channel package sharing main-frame hardware, new provisions for device status information, and a standard channel interface between central processing unit and input/output devices.

This allowed all peripheral devices to work across the entire range of System/360 models and the commands and the status indications were consistent. This created a compatible architecture for the entire OS/360 based Hardware that made the creation of a common I/O System (IOS) possible. The design of IOS then became the design of a channel scheduler that was consistent across the System/360 product line. Any of the Tapes, Disks, Unit record equipment, or Telecommunications devices could be attached to any of the System/360 models. Anything to anything, an elegant concept, that today we take for granted; but in 1963 was revolutionary. This also allowed, in later years, a robust plug compatible industry to emerge, thus producing significant gains in price/performance for the user community.

The System/360 introduced an architecture of channel programs that could execute sequences of I/O operations independent of a CPU. The channel was directed to a channel program in main memory and the required device. The channel program comprised of commands containing addresses to which to transfer data (in or out) and other control commands (e.g. tape rewind).

A control unit is used to synchronize I/O operations between the channel and an I/O device, handle routine error recovery, translate channel program protocol to device protocol, and handle path connections. The System/360 channel interface to the control unit is an open, well documented hardware protocol originally documented in the 1964 OEMI (Original Equipment Manufacturing Interface) and documents both the physical and logical interface.

Fred Brooks stated in 2002:

"The crucial software innovation corresponding to the standard hardware I/O interface was a single system of I/O control and data management for all kinds of I/O devices. This was a radical departure from earlier operating systems. I consider it the most important innovation in OS/360."

2. Application Device Independence - the user of the system did not have to know or care whether his data file was on a disk or a tape. The Application program just Opened it and assuming the correct JCL the system was directed to the correct tape or disk file. This is a capability we take for granted today, but was revolutionary in the day. And with generation data groups, the application did not have to keep track of archived versions of the same data file, a great convenience for jobs, e.g., like say a daily inventory job, that needed the latest version of a file. At Hughes Aircraft, for example, we had 50,000 tapes in our library, the vast majority members of generation data groups.

3. Multitasking - provides the ability to take advantage of the fact that CPUs are much faster than I/O. I am talking about true dynamic multitasking, where anything can be run while other tasks await the results of I/O requests. The potential conflicts, lockups, and overhead represent significant bottlenecks to be overcome in such a free flowing environment. Some other "attempts" at multitasking would have special patched on system functions running in the background (such as spooling). With OS/360 we are talking about full free flowing multitasking that allows any user task to compete for resources both within its structure and with other multitasked jobs.

4. Multijobbing - provides the ability to run jobs simultaneously, while managing the competitive access to serial CPU, Memory, and I/O resources.

5. Multiprocessing - the ability to manage multiple jobs using multiple tasks across two CPUs sharing a common memory, a common OS/360, and common I/O devices.

6. Scalability - the ability to upgrade to more powerful System/360s without having to undergo a rewrite of the investment in customer application software.

7. Emulators - a combination of hardware and software that allowed the running of object modules created by second generation systems, such as the 1401, in the OS/360 job stream transparently with native OS/360 modules. This was an enormous tool for the second generation customer base in its transition to the System/360. It is very dangerous for a vendor to introduce an upgrade option that obsoletes the years of development by the customer base. These emulators helped IBM immensely in moving its customer base to the System/360 and helped minimize defections to the 7 dwarfs. At Hughes we had job streams that included modules that had been "fargoed" from EAM equipment in order to run on the 1401, and now where emulated in order to run on the System/360. Of course a lot of this kind of stuff was eliminated in the conversion required to get past the Y2K issue, but that was after 35 years of emulation in some cases!

Much of this may seem mundane to the modern system programmer, but trust me it was not in 1963. I will say that a lot of this is being ignored in the current rush to the consumer mobile world. I do believe that the introduction of Windows 8 into this new world is bringing back some of the plumbing I am describing and will result in real robust killer apps in the future of the mobile world. Just an opinion ….

Now some may argue with the implementation of some of this. JCL and PL/1 are for example, controversial subjects. And then the number of releases before stability was achieved. But there can be no argument with the foundation it ultimately provided for the enormous expansion of mainframe data processing in the world to this very day. Once it truly worked, which admittedly took years, its impact was significant on the evolution of data processing. Without the System/360 and OS/360 family of compatible products, the evolution of computing in this world certainly would have been hampered, fragmented, and diminished.

Examples of major development projects that extended the base capability:

1. NASA projects processing tons of real time data from outer space.

2. Loosely coupled Multiprocessing as represented by the ASP system.

3. Time sharing as developed with TSO.

4. DBDC capabilities with IMS, CICS, and DB2.

The people side of the IBM OS/360 Project

As indicated in chapter one, I approached IBM's SDD development laboratory as if I was entering the Valhalla of all development labs. My early experiences with Bill Clark supported that vision. I was out of my depth, I thought, because these guys were just too smart for me. As time went by, I realized that the core of leadership certainly was smart and experienced in the development of Operating Systems, but the vast majority of developers were just like me - talented, good at what they took on, but inexperienced in the development of Operating Systems. They had been gathered from all over - Federal System Division, DP Division, Field Engineering Division, World Trade, and from the Computing industry near and far. I discovered that I could more than hold my own with the movers and shakers of this project, although in most cases I was still awed by them.

I recall that everybody was self motivated in this effort. I do not remember anybody who wasn't. Not that there weren’t mistakes, and bad design, and general incompetence, however it was not from lack of effort. Everybody was totally committed to this project. Everybody realized that this was the project of the industry for the company and IBM's Poughkeepsie SDD programming labs was the place to be. Nobody wanted to fail, everybody did everything they could. In fact, Failure was not an option!

IBM did a very good job of exerting subliminal motivation on the developers. An example was the IBM career path. The programmers clearly understood the advancement structure:

Junior Programmer

Associate Programmer

Senior Associate Programmer

Project (Programmer or Manager)

Development (Programmer or Manager)

Senior Programmer (common title regardless of staff versus management)

I might not have these entirely correct, but you get the point. In any event, everybody understood the hierarchy. Everybody understood what it meant to make Project (you got your own office). Everybody understood what it meant to make Development (you got a bigger office and wooden furniture). Everybody understood what it meant to make Senior Programmer. Everybody understood what it meant to have an OCA on your wall (or more than one). The movers and shakers walked tall, as everybody knew who they were, kind of like the guys in “Top Gun” – the best of the best. Everybody was well taken care of, the movers and shakers just a little more so.

And everybody in the project understood the pressure that management above exerted on the developers to deliver. It was a kind of squeaky wheel environment. If you demonstrated competence and reliable product delivery, you were left alone. This, for example, allowed me to work with Al Kolwicz to expand PROTIOS to satisfy the testing requirements of the data center even though it was not my assignment to do such a thing. I had demonstrated that I was on top of my game and nobody needed to worry about my core assignment. If you needed help, you got much more management attention. In other words, lots of micro management if you were in trouble; no love, if you were not. You had to be self motivated, and it really helped if you were successful.

I remember Nelson Barnett once admonishing me with – “don’t tell me how to do what you need, just tell me what you need”. He was absolutely right. The lines were drawn between departments, between, groups, etc. As long as you delivered, you were not micro managed, but if you didn’t deliver ………… This is exactly how organizations should function.

In general most of the project was made up of twenty-somethings who did not know what they did not know. We were, in general, a very young but supremely confident bunch. A bunch of competitive artists in an environment that ultimately needed disciplined engineers. But until then, it was really fun.

In this analysis, realize that I left Poughkeepsie in June of 1966. This was before the project became, of necessity, much more disciplined and procedural. In other words, the discipline of the hardware side of IBM was brought to bear on the software side. While this was absolutely necessary to evolve a reliable and consistent set of product releases, I am glad I was not there to see it.

I guess an analogue might be seen in the attitudes of the original seven Mercury Astronauts. Most, if not all, were successful hot shot test pilots. They were artists pushing the envelope who chaffed at any sort of administrivia that got in the way. Hard charging, hard playing over achievers. I don't want to really compare the OS/360 movers and shakers to the Mercury seven astronauts, but I you get the point.

Let me reprint the recap from the end of Chapter one.

1. I chose Electrical engineering at Maryland not for interest but for money.

2. A big break was being blackballed from a fraternity my Freshman year.

3. The 1958 Recession and resultant lack of a summer job allowed me to reduce my senior year load by going to summer school and getting a couple of history courses out of the way. The resultant 17 credit load (after 20+ for 3 years) caused me to take my only elective - the only digital computer course (three credits) at Maryland.