Skip to main content

‘Mainframe Mike Myers’ on IBM Z System Programming

Reg Harbeck: Hi, this is Reg Harbeck and today I'm here with Mike Myers, the mainframe Mike Myers, who has been involved with the mainframe basically since the very beginning. Mike, maybe if you could introduce yourself to us and tell us, how did you end up on the mainframe?
Mike Myers: Well it's kind of—again it's a long story I suppose but I started—I was in the Air Force and was trained in electronics. I was working on equipment which was cryptographic processes which is very specialized computer at the time. I got out of the Air Force as an electronic technician and IBM hired me as a field engineer so starting as a field engineer, I did the standard stuff at that point in time which was maintaining key punches and other punch card devices which I did for about a year and a half or so. The division wound up picking up responsibility for the maintenance of the OS/360 and they gave a programmer's aptitude test to everybody, every field engineer in the country and apparently I did quite well, enough to draw their attention. I was offered the opportunity to go to Poughkeepsie for a two-year assignment where I would learn OS/360. I would learn Assembler programming and all of the facets and things, utilities and so forth involved with OS/360 with the intent—also then get involved in some kind of a project which would entail detailing with people who were the OS/360 developers and that would give me the advantage of knowing a lot of them personally so I came back to the field, was calling in for some sort of a problem with OS/360 that I could perhaps point to Charlie or Bill or whoever it might happen to be that I'd worked with before and remind him of our—and therefore you know have a quick path in to being able to deal with it. So I started school in—actually, it was the day before OS/360 release 1 was actually released to the public.
Reg: Cool.
Mike: And I started as a computer programmer. I learn—I sat I think for at least six months going through what was then either system programmer education or basic programmer education again designed to give me the ability to support OS/360 so I wound up on a couple of projects that were quite entertaining that involved Assembler programming, that involved some internals of the operating system and then that was one project. The other project was – involved actually the development of a system for maintaining card images on disk drive. What a concept. Yeah for a few months that was going on like several of the people that I worked with around—we kept card decks just as a backup of all of our—of all of our source code and the like but that was the early days. My two years was about up when my fuel engineering branch manager called me back and said, well we're looking forward to having you come back to Nebraska where I entered from and then have you support OS/360. I said that's great because that's what I've been trying to learn how to do here. He said well we do have one problem. We only have one OS/360 client in town.
Reg: Mutual of Omaha?
Mike: I'm sorry?
Reg: Was that Mutual of Omaha or is that not information that I'm allowed to know?
Mike: It probably was Mutual of Omaha. I don't—I don't really know that. I've never looked back to find out. I supported Mutual of Omaha key punches before so I knew where they were and had some contacts in the building but I said well this is a fairly complex thing. That’s probably good. I'll have an awful lot of time to do a lot more studying and a lot more work to be really prepared. He said well I don't think we can really do that. We're after all training on current devices and key punches still break down and we probably have to have you support those. I said, I didn't come here for two years to go back there and support key punches. I said the guy I'm working for right now is in desperate need of serious Assembler programmers which he thinks I am because I wrote it a couple of times since I've been here and I believe that if I were to quit the company, he would be willing to hire me back. What do you think about that? He said well we've been paying for this whole thing including your promotions for the last two years and we'd really like to get something back out of that. I said, well, see what you can do so a few days later he called me back and said field engineering education is located in Poughkeepsie and what we've set up for you is an interview with them to see if they would be interested in having you work for them and that way we would benefit and you would still be able to stay in the area and continue your work with the operating system. I said okay, that sounds like a worthwhile thing. So I went over, was interviewed, and was offered the position as an assistant—as an instructor in field engineering education which I took and that began my education involvement. I taught internal logic and maintenance of the ISAM. I don't remember if you heard of that.
Reg: Indexed Sequential Access Method.
Mike: Yeah, Indexed Sequential Access Method which is—there were some very interesting things about processes within that but also Basic Direct Access Method, also Graphic Access Method and of course OS/360 itself so that sort of started the whole thing. I taught course, I taught program support reps both the internals of the operating system and those three access methods for about two, two and a half years and in the process also got more adept with programming. I did some side stuff while I was working in field engineering education. In fact I actually wrote a full screen editing device, editing system using a 2250 graphics access device which we used to then develop course material for the courses that we did for the training of the OS/360 people. We taught, actually it was a six-week course which the primary intention of this basic OS/360 course was to get the program support rep to be able to look at a problem and determine whether, from the dump, whether it was a system problem or perhaps was a hardware problem or a software problem. If it was software problem, then he was charged with going ahead and fixing it. If it was a hardware problem, we called in somebody from somewhere to come and deal with the computing mix up. So that went on for a period of time and I was getting ready to think about moving on about the time the same fella I said would have hired me if I left the company called me and said we're getting started on a new project right now, a pretty big one and we'd like you to be involved in working with it. It's called Multiple Virtual Memories, MVM, which was eventually changed. It turns out around that time there was a movie called Colossus: The Forbin Project which made people think that computers were thinking devices and made them a little bit concerned because the US computer found the connection to the Russian computer and the two of them decided to overtake the planet and get rid of this carbon-based stuff that was getting in the way. So people were suspicious of things—of computers having that capability and IBM, believe it or not, decided to change the name from Multiple Virtual Memories which was quite accurate to Multiple Virtual Storage which sounds more like Mason Jars and Ziploc bags I guess and therefore sounds pretty safe. So I wound up on the design team for MVS. My initial responsibility was to design the master scheduler. Because of my interest in the access methods and the like and my exposure there when it came down to development time I was actually asked to be the technical team leader for the development of the paging subsystem so I had responsibility for real storage management and virtual storage management.
Reg: Cool.
Mike: That was pretty cool because that added to the storage knowledge that I had built up and so that went on for another couple of years. Then I had to get involved in auxiliary storage management when we finally started to put all the stuff together because ASF had done some stuff that being primarily developed in PL/S at the time. Most of the stuff that we did for the efficiency’s sake was done in Assembler as you might guess. I was responsible for the design, development of QUICKCELL, responsible for the design and development of the paging subsystems, page fix, page frees and the front end for those and the like and then actually the GETMAIN and FREEMAIN access methods so that was kind of cool. That went on for several years and when that was over and MVS was released, the first release of MVS, I wound up—because of my education interest I wound up in the education department in the Poughkeepsie lab where I was responsible of the development of the MVS courses that were needed at the time and I wrote most and taught all of the MVS courses up to and including performance tuning and debugging and the like.
Reg: So you were probably involved in the creation of the IPS as an ICS in the first place.
Mike: Yup, yup, a bit. So that went on for a while and eventually I got promoted a couple of times again in education. I wound up leaving education to go back to the design group where I got involved in actually a couple of measurement projects, a large system effect study which was intended to try to figure out where most of the time in the operating system was spent and we—we used a method of doing that using a version of VM probably few have ever run into that actually virtualized time. The idea was that with faster computers, we would have the need to figure out where time was being spent in the system and therefore areas that needed to be improved for performance reasons.
Reg: It's like Tai Chi.
Mike: Yeah, right, right. So this time virtualization thing basically was able to be given a representation of how long an I/O operation to a particular device was supposed to take which was actually a lot faster than it was really taking but they used—it was being used as a measure when an I/O operation would start to determine the advancement of time. It was interesting to watch the time showing up on an MVS console start, not to go backwards, but to slow relative to the advancing wall clock time that we saw but it was taking these measurements and it was finding out where we were spending all of our time and then that was used to go ahead and work on the enhancement of those areas of the system. It turns out that GETMAIN and FREEMAIN were heavily involved, but we used that as performance tuning and measurement and redesign of existing functions there. That was one interesting project. Another one I got involved in at the time, the Poughkeepsie lab was responsible for the maintenance of both OS –  MVS now –  and VM. They were charged with the maintenance of versions of the system when it came to the hardware so they were looking for a way to get around that to do faster maintenance or less of it and one of the things we projected was the existence of a virtual machine environment inside MVS. So four of us got together and developed a working virtual machine in the TSO address space. My involvement in that was the development of the file system which kind of got interesting because I believe that the work done there was actually underlying—because we used VSAM to do it, which actually underlies the concept of both the PDS/E and the VM Unix address space, Unix access methods because they were just another method of doing the same thing that I proved could be done and so that sort of went on and on. I got involved in the VM design area for a while and that led to what I call the project from hell. I was responsible for the design of the storage management functions within VM, the VM/XA and had responsibility to keep several different IBM divisions and organizations on track that were doing their individual components of that overall project.
I wound up spending an awful lot of time traveling back and forth when they would agree. They would change the design and I'd have to go back and try to get them to go back to some way that would work with the other seven divisions that were doing other stuff and it was very much like—I don't know if you go back far enough to ever have seen the Ed Sullivan Show but one of the things they had on there was a character who had a table with just the sticks that stuck up from the table and he would put a platter, a plate on top of one of the sticks and then start to spin it and keep the plate balanced on top of the stick. Then he would do that across other sticks and this would run across his table of like nine or ten sticks and would have to run back and forth as he saw one slowing down to speed it back up again. That's kind of the operating state that I was dealing with. I would fly out to Santa Teresa and get them to come back to where we had started out or fly to Denver and/or drive to Endicott and/or work with the folks down in Yorktown Heights. Again it got to the point where I wasn't really getting anything personally done. I guess going to be a manager I didn't really want to be and around that time there was a lot of advertising in the New York Times and others looking for consultants in the MVS and VM arenas. I was totally comfortable with that idea when I was in the education department. I didn't mention that but I was a one man system programming shop for MVS and VM so I had done everything: install to debug, maintenance of those and the subsystems in those and done that for several years while I was in the process of writing and teaching classes at the same time so I figured I kind of knew what I was dealing with and I wound up applying for a consulting position, and wound up getting one. I had a few others I turned down. I got one with the Morgan Bank in New York City, started doing the commute down to New York City for that. I was there for what was it, a six-month assignment with the possibility of renewal. I took myself out after three and half years because there was nothing much new to do. Then I did a one-year assignment for the Bank of Tokyo converting DOS/VSE to MVS and again using VM as the tool. This was in the early days pretty much before the availability of—
Reg: LPAR?
Mike: LPARs. Yup, before the LPARs so the LPARs we were simulated there by having a virtual machine as a piece of the system and it was a matter of running DOS/VSE as a production system as MVS was becoming a production system and taking functions out of DOS and adding them into MVS with eventually bringing up the whole MVS system and shutting DOS down entirely.
Reg: Cool.
Mike: That and kicking around doing a lot of other consulting kinds of assignments. One of the more interesting ones was for GE Capital Corporation. They were among the first System-Managed Storage heavy users. In fact one of the two of the first ones that were actually trying to run it in a multiple machine environment. The other one was GE. No, I went with GE. The other one was the phone company and between the two of us we seemed to be racing to see who could get the next severity one APAR before the other. So that was an interesting experience to do something. Again, it was one of these things that I had not—no one had done it before so it was just a project: well, here it is and do what you've got to do. That sort of motivated my interest in training even more, the idea that through the consulting experiences I was learning new things and in the process of learning new things learning how to learn to do new things. I think that was something that I could do. I could write a course and I could teach other people the same steps that I had gone through so three other consultants and I started a consulting company. I was going to be in charge of the education division. Unfortunately in the late 80s we had a recession which sort of broke us up but I joined up with one of our sales persons and established a partnership where she had found it was easier to sell education than it was to sell consulting because there were a lot of other consultant people running around competing with us and so we started this little education company which we started and formally incorporated in New York in 1991. So I spent several years running around the country. I did some consulting intermixed with it and would learn something new from that, write a course about it, offer the course to people around the country and had several thousand students from Fortune 500 companies as students for various things ranging from Assembler programming to Rexx programming to system automation to performance tuning to debugging, dump reading, ISPF and all of that sort of stuff. I've written about 35 courses in the process of doing that and things have sort of settled down a little bit now and so I'm at some other interesting things I’m trying to work on which again sort of speak to my pleasure in teaching and training people so I'm looking to do more in the mentoring and/or consulting areas in either operating system although the z/OS is probably still the preferred one but I can do—I've done some stuff with z/VM as well as a systems programmer in both.
Reg: Very cool. Now and I want to thank you because you're already started mentoring me as well and I'm benefiting greatly and also that you're actually going to be helping me with some of the content of my master's thesis for which I'm really grateful. If people want to reach out to you and get you to consult with them, teach them, mentor them, how can they contact you?
Mike: Well right now they could use this. I still have—Mentor Services Corporations still has a web page and I can be reached at or at the telephone number that you called me on here. I haven't established a new company or new organization yet but I'm in the process of doing that so it's—I can't say much more than what I told you with regard to being able to get ahold of me. I can also be found on LinkedIn and Facebook.
Reg: Now that said, obviously you have a couple of famous name sakes, one of them in the world of fiction and one of them in the world of Hollywood so to find you as the mainframe Mike Myers, do you mind if I share your phone number on this podcast? I can read it out right now.
Mike: Go right ahead.
Reg: Okay so it's 919-922-1532 and are you like you know Michael.Myers and some number on LinkedIn or how do people distinguish you from the other Michael Myers?
Mike: Well I hadn't really considered the others so much but I'm in under Michael Myers. My son is a Michael Myers, Jr. by the way and we've had some fun with that name. Now this is a real aside but he is a chef and when he was going to the Culinary School of America he got kidded about his name from the younger folks that he worked with and so the first Halloween that he was there, I went out and bought him the mask and his toolbox along with the butcher knives and meat cleavers. It becomes a little quieter after that point but yeah, I've had fun with the name. So Michael Myers is how I wind up showing up so I got Mike Myers. Let's see. I'm Michael Myers on Facebook and I think I probably am in LinkedIn. I'm pretty sure I am so maybe I should put in a Mike Myers but then there's that Hollywood guy there too, so.
Reg: Well what I'll do is anybody who wants to find you and has any trouble finding you, you're one of my connections on LinkedIn as well and you're the only Mike Myers I'm connected to on LinkedIn.
Mike: OK.
Reg: And I have a somewhat more unique name, Reg Harbeck. So far I'm the only Reg Harbeck on LinkedIn as far as I know so they can go through me to you.
Mike: OK.
Reg: If they need to.
Mike: OK.
Reg: Great, well this has been absolutely wonderful Mike and usually we have a much shorter thing but I didn’t want to stop you anywhere because it was all just absolutely wonderful content and in fact we want to give you another minute or two if you want if there is anything else you wanted to share with everybody.
Mike: Well yes, one of the more recent things I got involved with was with the North Carolina A&T University.
Reg: That's where Dr. Cameron Seay worked.
Mike: Yeah, Dr. Cameron Seay. I've had the delight of calling him my star student.
Reg: Awesome.
Mike: It exactly fits and he knows that but especially he's got a PhD in information technology. He's been my student of course in z/OS and z/VM when we were actually managing the NCA&T system.
Reg: Cool.
Mike: Which I was the remote systems programmer for and so he has picked up a number of things—he picked up some personal experience with the system itself with some assistance from me and some training. I've had a lot of fun. He's now at Eastern Carolina University. We were involved with him—the Mentor Services was involved with him with the project that the Department of Labor had set up trying to get apprentices, an apprenticeship program going for mainframes which unfortunately fell through and he's gotten—continues to be involved with the idea and I'll do anything I can to support him because I think he's a great guy.
Reg: Yeah.
Mike: I love the direction of what he's trying to do and it fits right in with one of my personal goals now which is again just—I love this—I love this mainframe system so much I feel like you know I'm one of its parents. I like to call it MVS Mike's Virtual System because it's something that is super important and it's just—it shouldn't go away. It won't go away I'm pretty sure but I do see another one on the internet some place in Montana just shutting down. It's another one of those things. I was—I did one at the local hospital and I was with them for actually consulting full and part time for seven years as their systems man and ultimately shut their system down. It took a lot longer than they thought it was going to but they went to the distributed world. It was not the smooth sunny road, gold road that they sort of hoped for; they had a lot of bumps.
Reg: Yeah, that's typical.
Mike: And a lot of nasty steps but it was doable but they were not intense users either.
Reg: Yeah.
Mike: They were not a bank or insurance company or somebody has millions of transactions a second.
Reg: Right. OK. Are there any other things—thoughts you wanted to share about the future of the mainframe or things that you would like people to be bearing in mind as they look forward to the next 55+ years of the mainframe running the world economy?
Mike: Well I mean as we've seen, it's an extraordinarily adaptable beast. I mean if it weren't it would have gone you know to the death that was promised sometime in the 80s when switching to OS/390 all of a sudden and making it a server, a very powerful transaction and data server was a great solution for being able to keep it relevant and also getting into the real network by adding in TCP/IP and things like that so I just I see it constantly changing to add new things. More recently more of the look and feel of the environment – the distributed people in the distributed world seem to see, but they also did that in order to be able—to make the distributed interface to IMS, Db2, CICS and the whole like so that a lot of people today I think the mainframe is actually very well hidden from them because they deal with it on a regular basis but don't know that for the most part.
Reg: Yeah.
Mike: Because it looks like they're dealing with a PC or a server.
Reg: Sort of the original aspirations of Systems Application Architecture.
Mike: I have no particular thought—no particular thoughts or plans along that line but it would be something I would definitely enjoy doing. As I said I've done a few things in the past before that would you know say that I actually have some architectural experience in the redesign and reworking of a number of parts of it.
Reg: Well thank you very much for this Mike. This has been outstanding and really informative and really insightful. I appreciate you taking the time.
Mike: My delight – my pleasure. I really enjoyed it myself.