An Interview with Watts Humphrey, Part 15: The SHARE Meeting, the MVS Review, Release 15/16, and the Compatibility Letter
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The SHARE Meeting
Booch: Can I go back to a question? You
mentioned something about COBOL. It occurred to me we hadn’t talked about when
that hit on the scene. Did you ever have any contact with the CODASYL committee
or Grace Murray Hopper and those folks, as COBOL was evolving?
Humphrey: Actually, I never
met Grace Hopper in those days. I met her later at SEI. But I had a lot of
involvement with the SHARE and the GUIDE committees. I remember multiple
meetings with them. As a matter of fact, the first talk I made to the -- was it
the SHARE committee? -- it was a big meeting in
Booch: SHARE used to be a really big
meeting.
Humphrey: Yes, I think it was
the SHARE meeting. It was a great big crowd. There must have been 2,000 people
there. So I was the keynote speaker. The thing they pumped me up to talk about
was the PL/1 language. I did talk about PL/1. It basically almost caused a
riot. The COBOL people were up in arms. The Fortran
people were up in arms that we were going to kill their languages. I basically
went through what we were going to do. We weren’t going to kill any of those
languages. We were moving to PL/1, which never took off, as you know. It was a
nice language, but either it wasn’t far enough or it went too far.
The MFT System
So it didn’t permit
[an] easy move from Fortran or COBOL. I basically approached
the programming guys -- the PL/1 guys -- to put together a manual so they’d
have a Fortran users’ PL/1 manual and a COBOL users’
PL/1 manual that would actually write in a better language. But they never did.
One other thing that happened was the MVS system. Was it MVS? No. MFT. This was a multiple programming system that was our
biggest version of the 360. The original OS/360 came in three versions. It was
a single string program or it could multi-program in two ways.
Booch: Do you think that was the MVS,
the multiple virtual system?
Humphrey: No, that’s not what
it was. It was a multiple one with fixed partitions or something. It was MF or
something like that.
Booch: The OS they called OS-360 MFT. What
that stood for, I don’t know, but I’ll look it up.
Humphrey: It was basically for
programs with fixed memory partitions, and MVS was with variable memory
partitions. MFT was a very fixed way to run a fixed number of jobs that were
rather limited in size.
Booch: Here we go. Multiple
programming with a fixed number of tasks. MFT. That’s
what it stood for.
Humphrey: MFT. We originally
announced it, but when we later re-announced, we dropped it. MFT wasn’t
terribly attractive versus MVS. So I got into battles about that. The marketing
people were up in arms. We had to have MFT, and they were going to give us
added money for it. We had to do it, etc. So I agreed and we took the money. I
had the guys put together a plan.
I had to start with
the requirements -- exactly what we wanted to do. They couldn’t agree on the
requirements. The developers had a limited amount of time and money. It had to
be ready in November, or it wasn’t going to beat the window before MVS, which
was the following June. So they had to get that done. They were having these
big arguments and they came to me, “How do we do this?” I said, “Well, that’s
fine. You either agree with marketing on the requirements by the end of the
month or we’re not going to do it.” I gave them a deadline.
So they agreed by the
end of the month. Everybody compromised. They built the system. It was, in
fact, ready in November and nobody bought it. While they agreed on the
requirements, it turned out that nobody wanted what they had agreed on. So
building what they wanted I’m sure would have been a lot closer to MVS. But we
wasted a bunch of money and time on that, but we did it. So I learned from that
that you’ve got to be awfully careful when you lower the boom on requirements. And
that is not a good move. You could meet the schedule but miss the market and
lose a pot load of money.
The MVS Review
The MVS system, which
was delivered on schedule in -- I think it was June 1967. We were coming out
with it in the spring. It was like March-April for early testing. They were
really nailing it down. I had been pushing them almost, because of the MFT
experience, to really get people in from the field, experienced competent
people, and I wanted to have some reviews to go through and to tell us what
they wanted. We could not afford to screw it up. The development guys said,
“Great. Sure. We’ll do that.”
The marketing people
said they were happy to do it, but we had to send senior system engineers. They
weren’t willing to have customers come. So we were going to get senior systems
engineers to come in. Everybody agreed, but the development guys said, “We’re
not ready yet.” So every couple of weeks I’d call them and say, “Are you ready
yet?” They’d say, “No, we’re not ready.” Then one week they said, “It’s too
late.” I said, “You lose.” So we had it anyway. I remember the meeting. We were
in
There must have been
a dozen really top flight systems engineers out of major high end accounts. They
were listening to this. Every so often they’d ask a question. With few
exceptions, the managers couldn’t answer the questions. They’d have to call the
programmers. I remember one particular question somebody asked. It concerned
the restart mechanism. I’ve got to come back and tell you about the check point
restart in a minute. But it concerned a restart mechanism. It was restarting
the printer. It was a very limited restart. It was a printer restart. The
problem was that a very frequent mistake was a JCL error. I don’t know if Fred
[Brooks] mentioned it when you interviewed him, but he concluded that JCL was
the worst programming language ever invented and he invented it.
Booch: He, in fact, admitted to that
mistake. He went on to say that the reason that he believed it failed is that
they only accidentally developed it and never really treated it as a full
language. As a result, there was no intentionality for it at all. So yes, Fred
took responsibility for that one.
Humphrey: It was extremely
hard to program [in JCL]. People made lots of errors. A very common error was
in printing. People would write the JCL in such a way that it would skip a page
every line of print, instead of a line every line of print, which wasted a lot
of paper and they had to kill the printing. The printer restart was supposed to
solve that problem. The systems engineers said, “What happens under these
conditions now that you’ve got the restart?” They had a way to do it now that
they were using – a work-around. So they wanted to know what would the whole
MVS system do under these conditions? It turned out
the MVS system would basically run right through it and start printing all over
again, skipping a page every line of print. Everybody concluded that. There
were about three or four or five things in the MVS that the system engineers
pointed out that would be totally unacceptable. If the system would have been
shipped, it would have been a disaster. So the MVS guys agreed, “Yes, we’ve got
to fix all of them,” and they did. They fixed them all and they got it out in
time.
But the real lesson
of the story isn’t that. The real lesson of the story is that they never did
that again, calling in an expert team like that to review a system or a product
before its release. They never did it. I pushed them to do it. I would have had
to lower the boom and make that a big issue, to set up a whole procedure, which
I did not do. I probably should have. But I was amazed. The laboratory view was
that the marketing stuff was an annoyance. “We’ll build it. We’ll build our
system and we’ll do it right.” I was just astounded. We really didn’t have any
reasonable kind of requirements review system at all. Another thing I was going
to mention, we had lots of problems with the quality assurance community. This
is again in the 1966-67 timeframe. We were putting out like about nine releases
in the first year in 1966 and something like that, a similar rate in 1967.
Release 15/16
The quality assurance
guys nonconcurred with every release. They’d come in.
I’d have to go to meet with the group executive to overcome their nonconcurrence. And we did. They’d come up with a list of
defects that you had to fix, and there were these 50 problems here and all of that.
So we’d agree to go through the list with them, identify which ones were truly
critical and get them fixed. So we went through that every time until we got to
release 15/16. And in 15/16 was the new version of COBOL. We were replacing the
old COBOL with a new up-to-date COBOL. So as we put out that, for the first
time the quality assurance people concurred with the release. It looked great. So
we shipped it out and it was an absolute disaster.
It turned out the new
COBOL was a complete replacement for the old COBOL, and they had not gone
through the release to test the new version against all the defect reports and
test cases for what they called APARS, which is the programming fixes for the
prior version of COBOL. They had not gone through and corrected it and tested
it to make sure it would work on all of them. So the new COBOL had all the
problems that had been defects in the old one.
Booch: Were these primarily problems in
the language or problems in the compiler that IBM offered?
Humphrey: It wasn’t language
problems. They were in the compiler. They were essentially defects in the
system, and it was kind of amazing that they would get repeated, but as I
discovered by looking at defects, people tend to make similar errors all the
time. And programmers do, in particular. So pretty much
identical errors show up all the time. But in any event, they had not
done that. And as a consequence, whether you know it or not, but when people
install new programs, the rate of installation varies enormously. For instance,
operating systems go in very slowly and communication systems do as well and
file systems are very slow. But new language compilers typically just snap in. So
they get put in instantly. So thousands of people had just installed this new
COBOL right away and it blew up on them. So we had an absolute disaster. In any
event, we basically shut down our Time-Life laboratory to go fix that one. It
was interesting; the whole issue of determining the quality of programs, the
typical testing didn’t do it. You really had to do something well beyond that. That
was a severe problem.
The Compatibility Letter
Booch: You had some issues on
compatibility and the story about Gartner that you wanted to cover as well.
Humphrey: Yes, I was very
concerned about compatibility. This was in 1970 when I was in Endicott. So I
put together a letter to Spike Beitzel, and I think I
mentioned it before. It turned out the letter or excerpts from the letter were
picked up in a book. The book was called Big
Blue: IBM’s Use and Abuse of Power. The author is Richard Thomas Delamarter, published by Dodd Mead in 1986. Appendix 1 is
called A Voice Crying in the Wilderness.
They say right at the top where he says, “The most important problem at IBM
that its customers face today is how to enable its diverse and incompatible
product line to communicate easily.” Remember, this is 1986 now that the book
was published.
Booch: And if I recall, if I’m not
mistaken, looking at this, wasn’t he on the government side on the anti-trust
case? So he had a little bit of an axe to grind, did he not?
Humphrey: I don’t know who he
was. I don’t. That’s very likely true. In any event, he said, “One who saw it
all coming in 1970,” (That’s an overstatement. I’ll talk about that a little
bit more.) “and vainly tried to stop this
proliferation of incompatibility was IBM’s W.S. Humphrey of the Systems
Development Division,
Booch: Sure, please. That will be
great.
Humphrey: “…whether a
compatible product line should be our data processing group objective.” That’s
the one that I’m addressing. “This is such a fundamental issue that I have
taken some time to prepare an answer.” Now remember, this letter was from me in
1970 to our IBM’s group executive running all of our development groups. “Compatibility
is a major and growing requirement of our customers.” This is in 1970. “Compatibility
is most essential for the advanced and highest potential applications
environment. I strongly recommend that the DP group adopt as its strategic goal
the achievement of an operationally compatible product line. Each of our
systems and product strategies should be measured against this goal. Our
planning and testing should be so directed, and our organization and management
systems should be established toward this end.” I did elsewhere define
operationally compatible. I wasn’t just talking about using data or compatible
programs. I was talking about an entire compatible operation where the whole
installation was able to move stuff around and that sort of thing.
IBM’s concern was
that even then, IBM’s product line had too many layers of incompatible systems.
And it goes on. “In any case, where growth is blocked by an incompatible
barrier we find that the customers are either slow to move or reassess their
IBM decision versus competition. In the first case, the growth of 360 Model 20
customers into the DOS environment has been almost completely stopped by the incompatible
nature of these two systems. Similarly, the customer growth out of the 360
Model 40 marketplace. It is clear that smooth growth—“ Oh, I see. This is talking about the growth out of the 360
marketplace, that’s from DOS to MVS. “It is clear that smooth growth is an
absolute requirement that is growth within a product line and growth between
generations of a product line. In each case, our customer is concerned with the
ability to install new systems, preferably without extensive conversion.” He goes
on to say, “Humphrey could see what was coming, that these systems would soon
be hooked together into large networks.”
So the next paragraph
says, “I believe that interconnected systems, as well as interconnected
networks of systems, will be of growing importance in the 1970s and a major
factor in the 1980s. This being the case, we should recognize this requirement
for 370 and the system 3 Extension. It is an absolute requirement for
FS,”--I’ve just talked about FS--“which would be introduced in the late ‘70s
and would be operational in the marketplace through much of the 1980s. Operational
compatibility in that timeframe will be required across the complete product
line. For growth, for instance, it will be completely unacceptable to introduce
a system like the 360 Model 20.
Similarly, the
introduction of a System 3 with an incompatible architecture would preclude any
significant upward growth, would be recognized as limited to the small single
installation customer but unacceptable to a large customer with many small
operations. By the end of the 1970s and into the 1980s, we must offer a
completely compatible line from the terminal and device to the smallest and the
very largest of our processors.” So that was what I thought and the letter
didn’t even get answered, which I thought was interesting. So some of us could
see what direction the market would be moving in the future, but IBM management
didn’t pay any attention. In any event, so that was that.