An Interview with Watts Humphrey, Part 15: The SHARE Meeting, the MVS Review, Release 15/16, and the Compatibility Letter
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
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.
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
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.