Web Page Updates
Personal Recollections of the
Development of IBM's OS/360 - 1963 to 1967
How I got There and What Happened.
by Jack van Kinsbergen - December
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.
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.
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!
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!
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
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!
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.
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
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.
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!
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.
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.
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!
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!
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?
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.
enrolled in Penn's E.E. graduate program, went to one class and then resigned.
- so much for my academic career.
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.
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!
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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
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.
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
1962, I moved back to Philadelphia to become the "engineer from the home
office" mentioned above.
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
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'.
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.
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.
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
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
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.
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.
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.
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:
Bethesda Maryland - SLANG, a compiler of compilers for differing
- near my home in D.C.
- I didn't know what the heck the guy was talking about!
Product Test in Poughkeepsie - I would get to work on all the current
generation IBM product lines.
SABRE in Poughkeepsie - the online reservation system for American
Airlines. Exciting stuff.
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
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.
let me review how I had arrived at this point:
I chose Electrical engineering at Maryland not for interest but for
A big break was being blackballed from a fraternity my Freshman year.
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.
The Philco offer probably was based on the above computer course,
I chose Philco over California due to a girlfriend in D,C. - we broke
up before I graduated.
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.
I was the only person I know among the hardware guys at Philco or ITT
that had any interest in programming.
I had three brushes with Techrep divisions, all of which could have
taken me in an entirely different direction.
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
strategy, no plan, perfect result! Somebody up there sure is looking out for
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
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
5. All systems had the same
instruction sets and channel architecture with the idea that a common
operating system would be developed for all.
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.
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.
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.
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.
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!
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.
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.
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.
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
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.
author, seated, with Bernie Witt, circa 1965, look at the thin ties!
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.
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.
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
SVC 0 - EXCP
SVC 1 - WAIT
SVC 2 - POST
SVC 3 - EXIT
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!
implemented the design spec then in existence for all these calls in PROTIOS.
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.
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.
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
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.
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.
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.
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.
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.
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.
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!
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
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.
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
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.
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.
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.
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!
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!
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.
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.
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.
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
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.
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
called my group together and carved up the development effort as follows:
EXCP Supervisor - Bill Bautz
Interrupt Supervisor - Don Ludlow
Error routines - Dan
System Generation - Jack
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.
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?
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
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!
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.
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.
result of all this is that IOS was a shining star in the universe created by
the early releases of OS/360.
had announced the System/360 product line, powered by OS/360.
It was to come in 3 flavors:
OS/360 PCP - A single task system running one single tasked application
at a time.
OS/360 MFT - A partitioned system that could run multiple single tasked
applications at a time.
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
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.
following is from Wikipedia, the
was forced to quickly develop four additional systems:
for machines with at least 8KB of core memory and a punched card reader,
for machines with at least 8KB memory and a disk drive,
for machines with at least 16KB memory and a disk drive,
for machines with at least 16KB memory and a tape drive.
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
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
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
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.
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.
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
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
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.
effect of all this on IBM's Revenues and Profits was:
Year 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.
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.
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.
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.
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
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.
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
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.
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:
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.
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.
approach worked great. The programmers were more productive, the operators
loved the challenge, and we produced a quality product.
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
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!"
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.
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.
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!
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.
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.
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
1. Hardware Device Independence - the idea of a standard
channel architecture for all I/O devices was a major component of the
Abstracted from the original 1964 System/360 Architecture
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.
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.
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).
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
"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
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.
- 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
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
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 ….
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.
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.
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.
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!
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:
Senior Associate Programmer
Project (Programmer or Manager)
Development (Programmer or Manager)
Senior Programmer (common title regardless of staff versus management)
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.
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
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.
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.
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.
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.
I chose Electrical engineering at Maryland not for interest but for
A big break was being blackballed from a fraternity my Freshman year.
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.
The Philco offer probably was based on the above computer course,
I chose Philco over California due to a girlfriend in D,C. - we broke
up before I graduated.
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.
I was the only person I know among the hardware guys at Philco or ITT
that had any interest in programming.
I had three brushes with Techrep divisions, all of which could have
taken me in an entirely different direction.
Fortunately Philco and ITT failed at their computer efforts, thus
inspiring me to want to join a company that might have staying power - IBM.
IBM's competing projects to the System/360 not interviewing?
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!
strategy, no plan, perfect result! Somebody up there is looking out for me!
was at this spot through no strategy on my part, just pure dumb luck - or as I
believe, blessed. In fact, the
experience of my four+ years in Poughkeepsie was beyond anything I could have
imagined or prepared for. I
couldn't have had a more satisfying experience, at the same time positioning
myself for the pursuit of the rest of my career.
I proved that I "belonged" and could keep up with these very
smart people and exited IBM with a resume that was fundamental to the rest of
1966, my first wife and I separated, one of many that came out of the all
consuming OS/360 effort. Since divorce in New York state was possible only on
the grounds of adultery, I wanted to move back to Maryland where an 18 month
legal separation was enough. I
approached IBM about a transfer to FSD and a project that would take two model
65s, attach them to a common main memory running a common copy of OS/360-MVT,
and produce a multiprocessing version of the System/360 - the Model 65MP.
The project was headed up by Bernie Witt who had written the original
Concepts and Facilities manual for OS/360.
Arrangements were made and I reported to Gaithersburg, coincidentally,
the very first day of the opening of the new FSD facility.
This facility, by the way, was nick named the "Rust Bucket".
Some unfortunate engineering choice caused the exterior to streak and turn
brown - thus the "Rust Bucket".
moved back in with my parents in Glen Echo, Maryland for a year and hired the
family lawyer to handle the divorce. It
took 3 years to get the divorce because the lawyer, Stan Dietz, who had been
through many of his own failed marriages, dragged his heels on it.
It turned out he viewed legal separation as protection for me from
making another marital mistake. He
had some experience in this regard as he had been married 8 times! He was
absolutely correct, it easily could have happened as I went through a string
of girl friends. After the divorce, I was married within a few months to
Audrey. That marriage has been
great as we are now in our 43rd year. I
did have some pragmatic criteria to go along with all the other attributes one
desires in these relationships. I wanted my next wife to have some
understanding of my business commitments and that she be flexible enough to
not be an impediment to my career opportunities.
Audrey was my administrative assistant at Programming Sciences
Corporation (see below) and has been a real trooper because she understood.
did well at FSD, but I was not as totally committed as I was in Poughkeepsie.
I had a lot of vacation backed up and decided to take every Wednesday
off for months. This gave me two
weekends per week and allowed me to roam free in D.C. as an "almost
eligible" 30 year old.
friend Al Kolwicz had interviewed with a software company named Programming
Sciences Corporation (PSC) started by his good friend Al Loring,
John Gunther, and Bill Debs - three ex IBM development managers from
Kingston. I went with Al on one
visit he made and so the PSC guys got to know me.
Al turned them down. A few
months later, they opened a Washington D.C. office and tried to get me to
join. I told them that I felt
that it took two decisions to make such a move - that I wanted to leave IBM,
and that I wanted to join PSC. I wanted to join them, but I had not decided to
leave IBM. That took another 6 months.
six months allowed me to think through, for the first time, just exactly how
to manage the rest of my career. The
biggest thing I came up with was that I should always take jobs that allowed
me to build on the very unique experience I had at IBM. It was unique and thus had real value to my career and
the industry. And it wasn't like
I was limiting myself in anyway with such a strategy. After all, it was IBM and the seven dwarfs!
By the way, soon to be IBM, period. The competition represented by the
dwarfs having melted away because of the System/360 product line.
Other than some limited success that the plug compatible space had
achieved, not until the advent of mini computers and the PC did real
final boss at IBM FSD was a retiree from the Army whose biggest claim to fame
was that he had run the largest dump in England during WWII!
At one point he got mad at me and said "God damn it van
Kinsbergen, you don't tell me what to do, you advise me!"
I picked up the phone, called PSC and joined the company as Technical
Director of their Washington D.C. office.
must remember that FSD had been formed very simply to deal with the
government, and not just to focus the requisite specialized resources. It was
necessary because the government demanded that they be able to look at IBM's
books. IBM formed FSD so that the books that the government looked at where
just FSD books and not the entirety of IBM's business.
It no doubt was not as simple as all that, but that was my
understanding of the origin of FSD.
As such, FSD was not run with the same élan as the rest of IBM.
No bureaucracy created to deal with the US government could.
I don't want to accuse IBM of anything,
but the largest WWII dump in England?
thus, ended my career with IBM, six months short of five years.
spent almost four years with PSC before they went bankrupt in
February 1971 in the midst of one of our cyclical economic recessions.
quickly, I was offered a job at the CIA as staff to John Iams, Director of
Data Processing for the CIA in Langley, Virginia. I accepted, but they needed
to clear me at a level even higher than Top Secret. This was going to take six weeks, and besides the background
vetting involved three days taking tests including a polygraph.
Another of these tests involved the invention of a language and then
testing my capabilities to translate into and out of the language from
waiting for the clearance, we put money down on a house near my parents and I
took a six week consulting job with Planning Research Corp.
turned out not to be quite that easy.
In looking around for another job, I had sent a letter to Carl Reynolds
and the letter had been forwarded to California, where Carl now heading up
Data Processing at Hughes Aircraft in Los Angeles.
He called me and invited me out to L.A.
I said why not, a free 48 hour trip to California? What is not to like!
I went with just an attaché case and was recruited by Carl and CUC's
Cuthbert Hurd - another industry legend.
I called Audrey the next day and said we are moving to California,
cancel the house and I will be back tomorrow.
She had no problem with the idea of moving to California.
joined Hughes in June of 1971 in time to head a project that centralized all
of Hughes Computers in Fullerton, California. I spent seven years there, the
last several of which I was Manager of the Corporate Data Center. We started
with IBM System 370/165s and ended with 100% plug compatible Amdahl 470
systems. Audrey and I have been
on the left coast since. I remember my mother, who had never been west of New
Orleans (on a visit) and spent her life in the East Coast saying I would never
be back. She was correct, except
author (right) and Carl Reynolds at serial #37 Amdahl 470 at Hughes Aircraft
in 1975, note an IBM blue system to the left, soon to be replaced by another
Amdahl 470. We were the first
multi CPU center to go to 100% Amdahl CPUs.
1978 I approached Amdahl for a job as I was interested in returning to a
developer of systems and ended up manager of Product Planning.
was later recruited to a staff job at Citibank working for John Reed, head of
the Consumer Services Division. I
was an in house consultant to the worldwide IBM based data center network at
Citibank. Lots of great travel
and a real education into how finance works, an interest that has stayed with
me every since. Especially useful
given the debacle of the last 5 years!
in 1980, Carl Reynolds called and asked me if I wanted to be CEO of my own
company! He was on the board of Boole and Babbage, a pioneering third party
software product company. I was
floored as Boole was a widely known marquee name in the industry. They were
almost bankrupt, in dire need of a turnaround and a new CEO. We were at Santa Monica airport the next evening, waiting for
Pitch Johnson, Boole Board Chairman to fly in with his private plane, when
Carl asked me if I had my resume. I
laughed and said no as I thought they were talking to hundreds of guys, but I
really appreciated the thought! It turned out that they talked to no one else,
and put a full court press on me and Audrey.
joined, we turned around, were profitable for three years and went public in
Feb 1984, the second software product company to ever do it. I was there for
the last eleven years of my career, until retirement in 1991.
the impact of fate or a higher hand on my career. If I had not joined Al Kolwicz
when he visited Al Loring, and if I had not moved back to D.C., and if I had
not taken a boondoggle weekend trip to L.A. - I probably would never have
ended up with the opportunities that presented itself in the last twenty years
of my career. In other words, I
have not been in control of anything except the basic strategy of building on
my Poughkeepsie experiences.
1997, we have lived on the downtown waterfront in the Emerald City - Seattle,
Washington. The events that
finally got us to Seattle, again were fortuitous, and not preplanned. But that
is another story for another time.
face the sunsets, walk everywhere (10,000 miles in auto miles over the last
ten years), the famous Pike Place Market is right behind us as is all of
downtown. We walk to the theater, the Seattle Mariners baseball games, and the
Seattle Seahawks football games. We eat lunch out every day in one of downtown
Seattle's very special restaurants. I have a spreadsheet that has a list of
214 restaurants we have walked to in the fifteen years we have been here!
And I mean three star and up restaurants. In many cases we are greeted
as almost family in these restaurants. After
all there are a few we have visited over 600 times each in the last fifteen
have maintained a web site that documents our life in the emerald city, mostly
photos, that I have updated a couple of times per year since 1998.
For more information the reader is directed to www.vankinsbergen.com .
point of all this in the epilogue is that every job I had was fundamentally
based on OS/360, and every offer I received had at its core my IBM
Poughkeepsie OS/360 background. This
was a direct result of finally having a career strategy.
was clear that I could have worked on anybody's non IBM system and been
competent, however, the Poughkeepsie experience was one of a kind and unique.
This propelled my career to another level, in my opinion.
started my period at IBM as a rudderless 26 year old, and ended with the last
25 years of my career dictated by a clear strategy - build on my Poughkeepsie
experience. Notice, I
didn't say anything about strategic goals, just strategy. I do not believe in
strategic goals, other than maybe to set a strategic direction. If you attain your goal, you probably set it too low. You
always accomplish objectives, but goals are there to set direction only, in my
opinion. If you are driven by
such a goal, you might take shortcuts that cause you to fail.
It is better to have a strategy and let it take you as far as it can
take you. For example, if I had a
goal to be CEO of a software development company, I might have taken self
defeating shortcuts. I had never
in my wildest dreams ever thought I would be CEO of such a well known company
in the computer industry as Boole and Babbage.
Yet it happened through no effort on my part, other than my
capabilities, my commitment, my strategy, and maybe a higher hand.
Headed up all Programming systems at IBM
Carl Reynolds Predecessor
Scott Locken - Headed
up OS/360 control program development (3rd
- Headed up Compiler development (3rd Line)
- Software Architect, wrote Concepts and Facilities Manual
- Early Architect, could recite "Casey at the Bat" in full,
and often did.
- Design Control, later MVT development Manager (2nd Line)
- PCP development Manager (3rd Line)
Ran the Development data center (2nd Line)
Christianson - Job Scheduler
Manager (2nd Line)
- Link Editor Manager
- Test tools manager, later MVT Supervisor manager
- Early Data Management Manager.
Reinstein - Design
- Early Architect, later Design Control
- Design Control
- Architect and early OS/360 manager (4th Line)
- Replaced Brooks as OS/360 manager (4th Line)
Designed Program Fetch
- Designed BDAM, my learner Chess partner. We failed at it!
McCallister - Systems
Programmer, single handed kept MFT alive.
- Staff to the project, understood more than anyone else
& Duane - Worked for Al
Ludlow, Bill Bautz, Halfdan Storm, Jack Frey
- My team that implemented release version of IOS
initially announced a series of six computers and forty common peripherals.
IBM eventually delivered fourteen models, including rare one-off models for
NASA. The least expensive model was the Model 20 with as little as 4 K of core
memory, eight 16-bit registers instead of the sixteen 32-bit registers of real
360s, and an instruction set that was a subset of that used by the rest of the
initial announcement in 1964 included Models 30, 40, 50, 60, 62, and 70. The
first three were low- to middle-range systems aimed at the IBM 1400 series
market. All three were sold first during mid-1965. The last three, intended to
replace the 7000 series machines, were never sold and were replaced by the 65
and 75, which were first delivered during November 1965, and January 1966,
additions to the low-end included models 20 (1966, mentioned above), 22
(1971), and 25 (1968). The Model 22 was a recycled Model 30 with minor
limitations: a smaller maximum memory configuration, and slower I/O channels
which limited it to slower and lower-capacity disk and tape devices than on
Model 44 (1966) was a specialized model, designed for scientific computing and
for real-time computing and process control, featuring some additional
succession of high-end machines included the Model 67 (1966, mentioned below,
briefly anticipated as the 64 and 66), 85 (1969), 91 (1967, anticipated as the
92), 95 (1968), and 195 (1971). The 85 design was intermediate between the
System/360 line and the follow-on System/370 and was the basis for the
370/165. There was a System/370 version of the 195, but it did not include
Dynamic Address Translation.
implementations differed substantially, using different native data path
widths, presence or absence of micro code, yet were extremely compatible.
Except where specifically documented, the models were architecturally
compatible. The 91, for example, was designed for scientific computing and
provided out-of-order instruction execution (and could yield "imprecise
interrupts" if a program trap occurred while several instructions were
being read), but lacked the decimal instruction set used in commercial
applications. New features could be added without violating architectural
definitions: the 65 had a dual-processor version (M65MP) with extensions for
inter-CPU signals; the 85 introduced cache memory. Models 44, 75, 91, 95, and
195 were implemented with hardwired logic, rather than micro coded as all
Model 67, announced in August 1965, was the first production IBM system to
offer dynamic address translation hardware to support time-sharing.
"DAT" is now more commonly referred to as an MMU. An experimental
one-off unit was built based on a model 40. Before the 67, IBM had announced
models 64 and 66, DAT versions of the 60 and 62, but they were almost
immediately replaced by the 67 at the same time that the 60 and 62 were
replaced by the 65. Like the 65 to which it was closely related, the 67 also
had a dual-CPU implementation.
System/360 models were withdrawn from marketing by the end of 1977.