John Eells on his Journey to the Mainframe
Reg Harbeck talks with John Eells, a longtime IBMer, about his life before the mainframe, his journey with IBM and how he ended up at SHARE. Listen to the interview via the orange play button or read the transcript below.
Reg: Hello. This is Reg Harbeck here and I'm here today with John Eells from IBM, a well-known mainframe and SHARE participant. John, welcome. Could you tell us a bit about yourself and your mainframe journey? How did you end up on the mainframe? How did you end up at IBM and how did you end up at SHARE?
John: Wow. That's a lot of questions, but how did I wind up at IBM and mainframes? I was selling stereo equipment for a company that no longer exists called “Stereo Magic,” and a guy who was an IBM customer engineer walked in and bought a stereo from me. After a great deal of discussion about how stereos worked, he thought that I was a good candidate to go work for IBM doing what he did. So I went up to the local branch office and I applied for a job. In due course I was extended an offer, and since it was six-times as much money as I was making, of course I said yes.
Reg: Very nice.
John: Right, so I wound up in what was at the time the large system FE division. I worked on large processors from the 155 to the 158, 165, 168 and 303X family. Then I, in the internal IBM account that I was assigned to, I became friends with many of the people on the system programming staff. They said, “You know you ought to come over to software.” I hemmed and I hawed because I did not have any software training, but after awhile I decided to make the jump and went into system programming. I don't know what anyone else says but I’ll tell anybody who is thinking about changing jobs that the first time is the hardest, so it was with a great deal of trepidation that I went into system programming, but I turned out to be kind of OK at it and in fact became the MVS team leader for the data center.
Reg: Cool.
John: At IBM East Fishkill for manufacturing. So how did I wind up at SHARE? Well, when I was still in that role as a lead system programmer, I went to SHARE as though I were a customer, although I was an internal IBM customer. At the time, SHARE had an installation code printed on the badge instead of an actual company name, and most of the IBMers wandering around had an installation code of IBM, but we had our own—IEF, which stood for IBM East Fishkill—so we could hide. Anyway, I went to SHARE and it was overwhelming; the number of sessions, the level of expertise, were just amazing to me. Many, many years later I came back to present when I was in a different job role that was pretty far removed from day-to-day system programming.
Reg: Cool. Now of course as a mainframer I immediately think of IEFUPDTE and stuff like that. I'm wondering if there’s a connection between that system code and-?
John: None at all.
Reg: Nothing?
John: No. IEF for schedule or allocation is a three-letter prefix. We have a number of them and we use them to prevent element naming collisions between different parts of the operating system.
Reg: Now having worked on the IBM mainframe hardware and then been a system programmer, at a certain point you moved into other roles at IBM that allowed you to get to know the mainframe and be involved in moving forward in a lot of interesting ways as well, as I understand it.
John: Well yes, in the years between then and now I worked in what used to be called the gateway group and we handled all of the customer requirements going into Poughkeepsie. That was very educational for me. I got to work with Peter Relson for the first time along with a number of other people whose name you would probably recognize, many retired now. I worked also in the build group so I was one of the packagers for MVS/ESA version 4 where my claim to fame was standardizing the way we expressed space requirements in the program directories so that when you added them together it actually worked.
Reg: Cool.
John: And eventually I wound up in ServerPac design and 11 years I was in the organization that prioritizes and funds z/OS development. I recently moved over to system tasks but I've kept the z/OS platform installations strategy.
Reg: Wow, neat. So basically for one or two decades now you have sort of been the person who decides how z/OS and its predecessors were installed.
John: Well I wouldn't say I got to decide how to do it because-
Reg: Because the customers do in some ways right?
John: As a ServerPac designer, I certainly had some influence over what people see on the panels today. As the owner of the installation strategy, I have a great deal of influence over what you’re going to see and over what you’ve seen recently.
Reg: Now of course you were talking about just dealing with customers from pretty early on. You must have had some really interesting requirements that have been real “Aha!” experiences in terms of changing how you did things because of important feedback from customers.
John: I would say so, and the other thing that’s interesting is many times customers ask for something without the knowledge that they have it already in a form other than the one that they asked for. It was always a win for me when I could reject a requirement with a phone call to the customer saying “Did you know you could already do this way?” In every case, they withdrew the requirement and they were delighted.
Reg: Excellent.
John: So it was a win for both of us. They learned that they could do it right now and we didn't have to invest in another solution to a problem we had solved already.
Reg: Do you have any specific examples of really interesting either on the one-hand, things that you were already doing, or on the other hand, things that you introduced as a result of this kind of interaction?
John: Well I think one of the most interesting things was actually a strong vendor requirement for a non-SMP installer to be made part of z/OS and in fact we've done that in z/OSMF software management. We’ll be building on that whole strategy and if people are curious about that, they can look up my SHARE session from earlier today, and if they have SHARE live access, they can actually listen to me prattle on for an hour or they can just go download the charts from the SHARE website.
Reg: I guess you might claim yourself to be if not the, certainly an, owner of z/OSMF.
John: No, no, no. I'm not an owner of z/OSMF.
Reg: No?
John: Nope, not at all. I do put into plan some of the things that you’ll see in software management and I try to influence the people that own the other pieces of it that I interact with so that I can get the infrastructure that I need to pull this stuff off.
Reg: Now of course one of the neat things about SHARE and IBM is really that they've collaborated to create so much goodness including the mainframe. If you take a look, SHARE existed nine years before the mainframe. I’m just curious of your thoughts of how the SHARE requirements process and other interaction at SHARE has really been a significant part of your journey and how you've been a part of IBM producing better and better quality goods.
John: Well I think the SHARE requirements process is great because it represents a consensus of a number of customers so it’s not a single customer with a single requirement. There’s some discussion of alternatives. There’s voting that goes on so that the things that we get from SHARE are pretty reasonably thought out right and I think that’s a big help to us. Some of them are surprises frankly. I was astonished when the number one requirement that SHARE had against TSO/E was for eight character user ids. Why stop at eight?
Reg: That's such a good point. I'll admit I hadn't thought of that either. For me I always thought, “Why is it seven?” It never occurred to me, you’re right. Why stop at eight?
John: Well the reason turns out to be that we pervasively have a limit of eight for things like address space names and commands, and they wanted consistency across that. They also wanted consistency across the minimum length user ID supported for everything that they did so they didn't have auditing exceptions for z/OS, so it was an odd thing out but the reason for the limitation of seven is historical-
Reg: Right.
John: And it has to do with the use of a partitioned data set (PDS) to store user attributes in the most space efficient way possible in 1970. Right? So in order to save every byte that they could, they used a partition dataset to store the user ID entries called the user attribute data set UADS, and if you exceeded the number of attributes that could be stored in a single block you got a second number in UADS.
Reg: Oh, that's why there’s a number there. I didn’t know that’s why there’s a digit there.
John: That's exactly why there’s a digit there. So user ID zero is your first one and if you have enough attributes, you got a user ID 1. Historically you could go optimize the space utilization for UADS by examining the entries to see how many people had user one, two or three entries instead of just user ID zeros and adjust the box size to reduce the amount of space required for the dataset. There was a time when storage was very expensive.
Reg: Oh, yes. I joined the mainframe when that was still the case. One of the things that comes up in this discussion that I've always really found remarkable is how frequently the number eight shows up. Of course as computer people you know eight bits in a byte or the fact that there are eight bars in the old IBM logo, the eight blue bars. There must be a number of other really interesting places where eight and its multiples, obviously 16 and 24 are really big ones, in the history of the mainframe. Any of those occur to you just sort of as an interesting observation about how these numbers sort of show up so much?
John: I don't. You caught me by surprise.
Reg: I just thought it would be an interesting tangent. That said, any other thoughts about IBM, about the mainframe or about SHARE? Anything else that is worth sharing about, that you’d like people to know?
John: Well I'm very excited by the cross-vendor project we have going on for installation uniformity. I think that holds great promise. I think if we can stay the course and IBM can do its part, that we can get fairly wide buy-in across the industry and maybe—I can dream right?—maybe we can all get to a common installer over the next several years.
Reg: Wow. It would take some wizard to do that, but we have a good number of them.
John: There we go.
Reg: Excellent. Well John, thank you very much. I really appreciate you taking the time for this. This has been really enjoyable and I learned a lot from this one too so thanks a lot. You have a great day.
John: You too.