Seeing the World Via the Mainframe
Reg Harbeck: Hi, I'm Reg Harbeck, and today I'm here with my colleague and co-author Karl-Erik Stenfors, who has been in the mainframe space for a very good long time. Well Karl-Erik, let's start by telling us about how did you end up on the mainframe?
Karl-Erik Stenfors: Well, a bit of a point. I tried very hard to become a mechanical engineer by the end of the 60s—you know, cars and gearboxes and so on—and then it just happened. At my university they had this big thing sitting there called the System/360 Model 75. During my first starters, we used some advanced HP—you would call them advanced calculators. So the idea of IT had come to me but then when I saw this thing and started talking to the people operating it, they were modifying the operating system and doing things. I said this sounds like something I'd like to do. So when I finally got myself together and quit the mechanical engineering, I got employed by a relatively big Danish company who was running in about 45 countries across the world. They were seeking some hopeful that would be given a course—a one-year course with salary paid, of course—because there was no formal education for information technology at the moment. So I went to this educational testing that they called IT programmer or IT assistant or whatever you want, but it was basically a programming class. One of the things we did was that we were taught Assembler language and that just got me, you know. I said… to the 360 guys at the university, I'd like to do that. So when I got back from education, I specifically asked in the company if I could join what they called the system programming department as a junior assistant programmer and got that. We had a fabulous 360 Model 40 that had 128K of memory.
Reg: Wow.
Karl-Erik: It was absolutely gorgeous and we were running OS/360 MFT and HASP, so that's how it all started. Then you know at the time you could basically write your own paycheck if you were a good systems programmer. So the three senior people ahead of me just left, almost from one day to the other, so I was thrown out on the deep water as a very, very young and very junior systems programmer. So that's how it all started.
Reg: Now a couple of things you've said so far make me think that maybe you got to make some changes to the operating system, because this is back when the source code was still available.
Karl-Erik: Sure. That's what we did, you know. In my first job, it was mostly around just HASP. HASP was source code you know and it was so easy to do, because they gave you the source code and you basically just fixed it up. So what you could do but of course with you know, microfiche, where you had a film. So we had all the OS/360 also in source code—
Reg: Nice.
Karl-Erik: So that was one of the things that got me and still thinking about guys at university, you know. University people run very short ops, you know, compile LINGO—
Reg: Right.
Karl-Erik: In fact almost 95% of the time was spent on allocation, the allocation and changing SEPS. So these guys had developed once a procedure where they modified things and that inspired me a lot. Then of course the CBT-A, that was absolutely fabulous, so that's what we did. Then I went off to an assignment in Nigeria to do something completely different and then coming back again, we heavily modified the operating system, and then at that time JES-2 too, to actually fit into our schedule. An interesting point was that we were SOUS bureau, so we didn't have a lot of money. We didn't buy RACF and we didn't buy Top Secret or ACF2. We came up with the idea, "why don't we write our own using the SAF interface that everybody uses?"
Reg: SAF is pretty solid and everybody uses it.
Karl-Erik: Oh yeah. So what we did was that we basically wrote our mini standard into that with our own SFCs, etc., etc. So based on that we built the first security system written by ourselves—of course in Assembler language—so that was pretty good. Then from the CBT-A there were a couple of things that were very interesting. Before it got to DS2 at HASP, we made what we called HASP to HASP, which was a modification from Triangle Universities where you basically did what network job entry did in DS2. And we wrote that—well we took that from the CBT-A and then modified to fulfill our requirements.
Reg: Now you say HASP to HASP, but that makes me think of something in the SHARE songbook. I'm going to look that up while you keep going and see if I can find it, because I remember the phrase "HASP to HASP" actually being in the SHARE songbook. I don't know if you—HASPY days are here again, so let me see if I can find that.
Karl-Erik: Ahh. I didn't know that but it was a pretty nice thing coming. I think it was Triangle Universities that had developed it and it was just, you know, Assemble ops HASP with a new processor, and you connected HASP from all over the world sending—it was a job thing, you know. You sent your ops across the network—you know 4800 BPS or something like that—but it worked wonders. The other thing we did—you know HASP and DS2 is what you would call processor-oriented. It was written by Tom Simpson, who worked out in Houston, and he documented this processor thing. So we made a display processor all on our own that would run and display on 7270 screens the status of the system for our operators so they could at any point—they didn't have to go and take any commands because we ran this screen, you know, with your jobs and waiting jobs, executing jobs, printing jobs, etc. Very, very interesting because the design of that, the HASP processor design, was absolutely fabulous. Tom Simpson was a genius on that—later John Amdahl, as a matter of fact.
Reg: So I've just been looking through, the SHARE songbook, as you have been telling me about this and I discovered about 20 references to HASP to HASP, and the very first one is one based on the tune "Yellow Submarine":
It begins in the town where SHARE is held
People come to skids and chat
And then down further on it says:
From our operating steps
Strain VM was hard to grasp
So we took a week and wrote HASP to HASP to HASP to HASP.
Karl-Erik: That's it. We did that.
Reg: Cool.
Karl-Erik: That was an amazing thing to do and then we did a lot to the operating system itself because we had a very special operation. All the current tapes were next to the tape station, so we didn't have to run to the vault. We could then—we changed the way that the system assigned the next available tape station so that we could actually go and mount the tapes in advance, because we knew that the requests would come to that particular station.
Reg: Nice.
Karl-Erik: Oh, we did a lot of stuff to the operating system, really, and we sold the solution to people in Sweden and Holland, in the U.K. This was out of Denmark and Norway, so we have customers you know—
Reg: So now other than Nigeria to this point, you've been basically working in Denmark. Is that right?
Karl-Erik: Denmark, Norway. Denmark in the beginning and then after Nigeria, I went to work in Oslo because that's where this company, another company had started modifying and the basic idea if you look at it was we wanted to go to—this was SOUS bureau. So we want to go to small IBM customers—you know, lower-end 360s—and replace their machine with a remote terminal. And the challenge we had was these remote terminals, the low-end ones, the 2780s. Once something was printing, you couldn't enter the ops or send commands. So we actually modified the protocol from in binary synchronous for the 2780 so that the customer could put a deck in the card reader, commands or the op, and push the start button. It would then interrupt the print, take a checkpoint, read the command and continue printing.
Reg: So basically the card reader was interacting in real time with the printing.
Karl-Erik: Absolutely. We used some very strange product—I think it was called a Remcom 2780—and of course we knew the binary synchronous: you know start sending, etc. etc. So the only thing we actually had to do was to say "well, somebody is pushing the button on the card reader." But the thing is printing, so we just go and interrupt the print, check the card reader, and continue printing, you know, without skipping anything.
Reg: So the card reader and the printer were basically acting like a keyboard and tape console for you by running two jobs in parallel.
Karl-Erik: Absolutely. Sure, sure. It was almost like—you know the low-end System/360, the Model 20 and also System/3, could actually load a program that would run as an intelligent terminal. You could actually send commands, etc. So we copied that down to a much lower-cost 2780, and this was a huge success. We had lots and lots of customers who came onto that.
Reg: Cool.
Karl-Erik: They could skip completely having their own machine with operating and other things. The other interesting thing we did, which you probably won't do today, was in my first job, we had our own interactive transactional system written in BTAM… It was for one customer who would enter transactions during the day, and then at the end of the day, he would run you know, overnight batch. But then we got a pre-release of CICS on the 2314 package—
Reg: This would have been 1968?
Karl-Erik: This was—no, this was just after 1970.
Reg: Okay so this is—CICS was also GA, but this was a pre-release of the next release then.
Karl-Erik: Yeah. And so what we wanted to do was that we want to take our BTAM monitor and introduce into CICS which we had—which we were right doing.
Reg: Now you're saying BTAM, not VTAM: Right basic terminal access method.
Karl-Erik: BTAM, oh yeah. This was very, very old stuff you know, running on 1200, 2400, and in the end, 4800 BPS modems, you know, over telephone lines.
Reg: Wow.
Karl-Erik: Oh and with this small machine, it was still good.
Reg: That is so cool. So now so you worked for this company in Norway, but eventually you moved on.
Karl-Erik: Yes because what happened when I got back from Nigeria, I had been working [for] a customer of my later employer in Norway, and they had a guy who was leaving. He was actually mentioned in the thank you notes of our book—
Reg: Oh.
Karl-Erik: So he was going somewhere else and couldn't you come and take his place? Here's an interesting thing. He later joined IBM and when he went on his first assignment, I got this very interesting telephone call between Christmas and New Year's Eve [asking] if I could come to IBM and take his job. Of course I said yes, I would love to. Then later on, he actually replaced me and I replaced him again. That's why he was in the book. We had worked together since 1974.
Reg: Wow. That is cool.
Karl-Erik: So I worked a couple of years for the Amdahl Company. Also when they introduced the 5860 with MDF—you know the partitioning of the Amdahl machine, which was a little bit earlier than LPAR.
Reg: This would have been late 70s now.
Karl-Erik: No, early 80s.
Reg: Early 80s, okay.
Karl-Erik: I think the 5860 came out in '84 or something. Then what happens is the other part of the interesting telephone call from IBM was we understand that you've done this MDF thing, so I went on to write the first Redbook for LPAR.
Reg: Oh wow.
Karl-Erik: 3090E LPAR, it must have been '87. You know it's night shift because the machine was used for anything else and the console was locked into a room where we had to sign in, sign out—
Reg: Physical security [laughs].
Karl-Erik: To get locked in so that we could access the console… Because at that time you had two modes: You had basic mode and you had LPAR mode. So in basic mode, you ran the old way, right? And LPAR mode, you could create—was it two or five LPARs? Two LPARs, three LPARs in the beginning, and we were not allowed to take that out of the room, if you will. So we had some very interesting discussions on what you would call micro-marketing between what MDF presented and what LPAR presented.
Reg: Now just to put this in context: Was PR/SM introduced concurrent with LPAR, or was it a later innovation?
Karl-Erik: No, it was the same thing you know, and this was one of these, again, discussions about the naming because we couldn't call it Prism because somebody had that. So it was called PR/SM for process and resource system management.
Reg: But everybody calls it PR/SM.
Karl-Erik: PR/SM and of course you were told you can't say that. Like you know everybody said you can say MIPS but everybody says MIPS, so LPAR was the PR/SM but of course the base for all of that was the SIE—the start interpretive execution that had been announced a little bit before—which was a way of scheduling a virtual machine in system mode, right? That's what SIE does.
Reg: Is SIE an instruction or is it a SVC or what is it?
Karl-Erik: No, it's an instruction. Start interpretive execution has a huge control block on the side so that architecturally you would say SIE and you would then give the opportunity to this LPAR, or in the second point to the VM operating system to actually execute in supervisor mode so that you wouldn't be interrupted whenever you did a frequent instruction—you know, previous instruction you would be able to do that. There were only a very, very few rarely used instructions that would actually interrupt the SI. So the beauty of SIE was that you were not interrupted when you did something you were not supposed to do. There were lots of assistants in the system which there still are so that you would have very, very nice performance. Of course—
Reg: So this is the original hardware instruction for enabling a hypervisor.
Karl-Erik: Yes.
Reg: Wow.
Karl-Erik: Absolutely and there's a very, very, very nice system journal article about that written by the guy who invented that. The name escapes me but he was in the group of processor design. Beautiful, beautiful written piece that explains how this came about because you know in the beginning, VM running two or three MVT or MFT images would die because of the overhead, right? So SIE took—because the overhead, the interruption, every time you did a previous instruction, a first level intra-op handler would say you don't have the right to do that. And then somebody would pick and execute for you, then come back, and if you had a few of those just wouldn't happen, right? So the next thing that happens is that I go on assignments, like all the times I went to London on an assignment to run what is known as early support programs. You know you contacted the customer, told him about the next machine or the next version of VM or the next version of then z/OS and asked would he be willing to help us make sure that this thing flies, that it could be maintained, that it could be installed, that it would cooperate? Then he would of course have access to that for a number of weeks, a number of months without paying for it, right? Then at the end of that program, he could say, "well, I don't want this."
Reg: Now this is going to be late 80s, early 90s?
Karl-Erik: Yes, beginning of the 90s where we were just in this thing seeing that the bipolar technology was getting close to end of life, you know. So the last one—I did the 9121s, you know, the air-cooled machines, and I did the years 9000. The last one was the 10-way processor that we installed for some customers beginning of the 90s, right?
Reg: So this would the MPSEA moving into OS/390 era, I guess.
Karl-Erik: Yes, yes, absolutely. Lots of name changes and most of the thing was the delivery methods, you know. You know SMP is a great tool but it takes awhile to get into that, right? So they changed the packaging to make things easier for customers: easier to migrate, easier to install, etc. etc. Then what happens after that is well-known. The second bet your business from IBM changing to CMOS technology.
Reg: That was such a big deal. You know people have forgotten about—I mean these days you know if you talk about bipolar, you're not talking computing [laughs].
Karl-Erik: And the thing was that we already had, you know—the internal names of the last big machine was the DH5 and we had DH8 ready to go. Well ready to go but like in 1964 when you had the 8000s system that had a next machine that didn't ship and this H8 didn't ship either, right, because Nick Donofrio and Linda Sanford—my two biggest IBM heroes—convinced [Lou] Gerstner that this was the time to go with this, right?
Reg: This was a big, big deal. I mean you know bipolar was IBM's unique advantage because it was a physical computing paradigm that was just absolutely outstripping CMOS and always had—
Karl-Erik: Oh yeah.
Reg: And for them to, like you say, bet the company and move across to complementary metal oxide for their architecture.
Karl-Erik: Well you know the big thing about the last part of the bipolar was when they invented the TCM, the 3081 [at] the beginning of the 80s. You know this module that would carry 111 chips. That was a very stable way of giving resources—water-cooled and with a very specific process to fix the chips on the module and that followed up until the C12. Only on the C13 they actually changed the packaging so that was part of that success. You know when they changed to CMOS, they opened the door wide open for Hitachi and Fujitsu, who continued with the Skyline for instance. So using bipolar and then that forced, if you will, the parallel sysplex, right? Because the old bipolar processor would give something about 60-65 MIPS, and the first CMOS was 15, right? So you see the big thing, the CMOS the physical, right? You replace, you know, a full house with something that looked like an American fridge. It was very dramatic and of course what Nick Donofrio and Linda Sanford used to convince Gerstner was that it will take a little bit of time and then we'll beat the 60 MIPS. It took 4-5 years, also helped by the fact another IBM first, using copper inside the chip instead of aluminum. That came out about 1998. They tried it very, very early on—late 80s, beginning of the 90s—but they couldn't get the copper to fix on the silicon. But then 1998 they announced that and less than 12 months later than that announcement the first mainframe, the first copper chip in the world was for the mainframe of course.
Reg: Wow.
Karl-Erik: Where else would it go? It opened the door for some increases in technology. The other thing I'd like to roll back to: When I came back from my first assignment, I went back to Norway in 1993. I was asked to go and run the capacity and the performance of the mainframe for the Lillehammer Winter Olympics.
Reg: Oh nice.
Karl-Erik: That is a very, very special project because you know when it starts and if IT is not ready, it starts anyway, right?
Reg: Yeah.
Karl-Erik: It starts anyway and you know when it ends, and when it ends, you pack up everything and move somewhere else, right? So a lot of testing goes into that. We had something called—I think it was called the TPNS, where you could record things and replay them, right? So when we tested for Lillehammer, we ran the events that had happened next to where I live now in Auvergne. I live in Chambery; Auvergne was just down the road. So we could run, say, the men's 30 kilometer cross country from Auvergne to test our system. You just saw it. I don't know if you saw it in Beijing right now. Sometimes it is too cold in the morning to start the cross country, right? That's in the rules and that was a panic for us because then they would push it by 2-3 hours later, and that meant that that would run into what happened in the afternoon. So we got a very compressed way of doing computing here, and we had to have the resources so we could do that, right?
Reg: Hmm. Cool.
Karl-Erik: So a lot of testing and then this is one—you know I spent a lot of time on performance, on performance management and there were basically four things in the Lillehammer Olympics. Of course the results system was the most important one, but during the first days, people would arrive all the time and having their photos taken and printing their papers—you know, the thing they put around the neck. That was run by a CICS transaction.
Reg: Oh neat.
Karl-Erik: That would fire off a batch job, right? So our task was to make sure regardless of the result system that we could give this batch job just enough to print the picture, because otherwise the queue would be long.
Reg: Right.
Karl-Erik: So we used SRM—you know SRM you can use what is called periods, and we ran 10-15 periods to measure the resources needed for this batch job. Then we reduced that to just the minimum and we said this is priority one, but only for, you know, so many units of work so it could finish. And so that worked nicely; that worked very nicely. They also—well they forced the Olympic Committee to take a 9121 and they would usually not do that because this was too young to—this is like the space program, right? You don't take the last technology. IBM was pushing very, very hard for that. We had just got Gerstner on board and he brought in a magazine manager who pushed for that. So somebody had to sign with this block the paper. This machine will do good enough and you can guess who that was right? Interesting thought. Now then fast forward. Second assignment: Montpellier, France. Parallel sysplex, right? Because parallel sysplex was a new thing.
Reg: It was building on all this other virtualization multi-parallel system running stuff you've already been involved in.
Karl-Erik: Yeah so explaining to customers how they could use this and of course the last year's 9000 could play in that so that would be one way of kind of moving over there. So a small group of people came to Montpellier, people from the field like myself, people from the lab, you know Db2, IMS, CICS, the hardware lab, etc. came together to actually travel to see customers and try to explain to them what this was and you know, of course, helping them. They said well we're going to try this and helping them to get this one up and flying, so that was pretty good. Then my second part there came back to doing early support programs—again with a very different way of doing things because the message was so small now, right? You know when we did a big ES9000, parts would come from all over the world—you know from Chicago, from New York and what have you—and we had a lot of people around to actually put the machine together. Now we just basically shipped an American fridge you know, so things changed here, right? The other—probably one of the most interesting things I did at the time, early 2000, there was a team called the zAtlas. I don't know if you've heard about it. It was famous, or infamous. It was a team of about 15 people from around the world that would meet with the lab about two times a year—
Reg: How do you spell their name? I just want to make sure I got this right for the transcript.
Karl-Erik: zAtlas like-
Reg: S-E-A space A-T-L-A-S.
Karl-Erik: Yeah. We—z minuscule, you know, small zed, small z Atlas.
Reg: Oh, oh, oh. Zed Atlas.
Karl-Erik: Atlas. You know? The god who carries the globe on his back.
Reg: So capital A Atlas-
Karl-Erik: Yes.
Reg: And a small zed.
Karl-Erik: Yes.
Reg: Ahh. Is there a slash in there?
Karl-Erik: Nope.
Reg: No slash.
Karl-Erik: Just that but it was one of these things that—it was a love and hate relationship because what happens is that we go see the lab and they basically talk to us. All of the designers came to talk to us and they say because you know, a z machine today takes 5-6 years to develop from scratch up to and they ship every 2-3 years, right? So there's always 2-3 in the coming. So what these guys told us was they said two years from now we have this thing out and four years, five years from now we have this thing out. We have this list of things that we think we can do. Go talk to the customer and ask them to give you the 10 most important ones, which we did, and then came back and discuss. And so we helped them, if you will. We assisted them in making decisions about what to implement later on, you know. I don't—
Reg: So this is really deep customer focus.
Karl-Erik: Oh yeah, yeah, yeah. And on the back of that, I think one of the first thing in the field that was allowed to be—a customer technical advocate for a very, very large customer in Norway. You basically put everything out of all—no salespeople, only me, the customer and the lab.
Reg: Nice.
Karl-Erik: Then you basically open up because we were then authorized to go and say anything about the future to the customer, and the customer would feedback, feedback, and feedback. So when I resigned, this customer actually was not very happy with IBM that they let me [know]. They said this because this is one of these things, you know. Not even my salesmen knew what we talked about, not even the people in between me and the lab knew what we talked about. And I'm not much into awards but I got one from Nick Donofrio because of that work.
Reg: Very nice.
Karl-Erik: Because we actually managed to save a million dollars a year for that customer, so sales group didn't like that particularly. It was just one of those things, you know. So that was—these two things there you know, the lab contact with the customer inside and then of course I wrote Redbooks almost every year. All the hardware Redbooks up until the z12 I think I wrote—yeah because I resigned just after having written that. So I wrote a lot of Redbooks, mostly on hardware also a bit on WebCN and z/VM Linux, of course.
Reg: Now although we're at 30 minutes, I'm not going to stop you because—
Karl-Erik: Oh we're at 30 minutes?
Reg: Yeah, this is—I know, the time is just flying. It's wonderful but let me just bring another thread that I hinted at the very beginning of our conversation. Of course you've written a lot more than Redbooks. I've had the wonderful privilege and pleasure of co-writing a mainframe introductory textbook with you, Dr. Cameron Seay, and David Boies, and I know my experience of it is wonderful. You guys are great people to work with and it's so exciting to have it out there, and I'll read the URL out in a moment just so that anybody wants to grabs a copy can find it.
Karl-Erik: Sure.
Reg: That is he.kedallhunt.com/product/introduction-enterprise-systems-0. I will put that into the transcript, but I'm really interested in both your reflections on the experience of writing this and all that led up to it. Because you just had so much of value and you know you would give us like these succinct observations and insights, and they would bring so much to the book, you know, in addition to what you wrote and just having the conversations. So tell me what your experience was. What led you to be involved in the book and all of that?
Karl-Erik: Well you know, I'm not that young. So I'm actually retired, but I'm teaching. I'm teaching a lot at the moment, mainframe of course. It's not officially mainframe classes, but I use mainframe in all my classes. So when Cameron asked me, I say "oh yeah, wow. That would be great." But I was a little bit taken by that because this is my first experience in writing for the academics, but you and David and Cam assured me that the way I've been writing for the Redbooks would match pretty well—
Reg: And it did.
Karl-Erik: And the experience was formidable. I mean I've had so much fun talking to you guys and writing up this and you know, taking my memory and seeing. I don't know if you noticed that I have the book here on the side.
Reg: Oh cool.
Karl-Erik: Selective on the front page. On the cover at the bottom left is my first commercial machine, the 360/140—
Reg: Oh neat.
Karl-Erik: I put it there because I thought that would be a nice story to tell later on. No, sir. I really, really, really enjoyed writing that. It was because it brought back so much and—
Reg: Oh yeah.
Karl-Erik: And again discussing with you guys and turning around and getting the ideas. I think the experience is excellent and of course my wife said "oh yeah, go do that" you know because we have been living a retired life in France and I just teach these classes. But I should say that I'm teaching Linux, virtualization, and Assembler. In Linux, I teach on the small platform and then I use the LinuxONE system in Marist for free access. So all of my students for the last six years have had the virtual machine on LinuxONE where they build the most wonderful things from music to painting to whatever.
Reg: And they don't know and care they're on a mainframe.
Karl-Erik: No, no, no. I give them a small presentation of this and you know, they just sit there and can't believe. Then I say "have you talked to your mainframe today?" and they say no. Then I say have you got a Visa card? They say yes. So you have talked to the mainframe today because when you took our your 20 Euros, you know where that was? That was on a Db2 database sitting behind z/OS and probably run by a COBOL program and they say "oh." Then of course, virtualization. We can't really do virtualization on a LinuxONE system, but at least you can show them. And of course, Assembler. It's 360 Assembler. What else is there, right? They are using—the other side of the Marist system you know, you have access where you can actually run Assembler code, COBOL. I think it's the same piece that Cam uses for his COBOL classes.
Reg: Neat.
Karl-Erik: And then of course, being a retiree, I started for four years scientific politics. What do you call that in—?
Reg: Political science.
Karl-Erik: Political science. Yeah, I've done that for four years because I want to understand this new country that I live in, which is very different from where I come from.
Reg: Now this is something that our audience sort of started to pick up as you talked, because you're originally from Denmark and you've lived in Nigeria, Liberia, Norway, and currently you're living in France. How many languages do you speak?
Karl-Erik: Well if I can keep—the three Scandinavian ones are easy—like you know, Norwegian, Swedish and Danish. But then I speak—of course I speak—you can't live in France if you don't speak French. It's not possible. Then I speak English of course, and you have a little bit of German from school but not too much. But I mean you know I lived in London for three years. I've been working the U.S. a lot and you know in Denmark, from second grade or third grade they teach you English because you know in Denmark we have less than six million people and not a lot of people around the world speak Danish. So it's kind of you know, you take that. Then of course it has helped a lot and that has reflected on my kids as well because I've taken them everywhere, so they are tri-lingual, all three of them, right?
Reg: Well plus you have that sort of basic Nordic language that you all speak, that is sort of the common language. But I have to say I've been really impressed. Nordic English speakers speak better English than most English speakers I know. You guys really learn the language well.
Karl-Erik: Well this is because of the tradition, you know. It starts very, very early on and when you get a little bit older they very often offer, you know, three weeks' schooling in the U.K. where you're basically equipped with a family that doesn't speak any other thing than English. So it's a cultural thing with Denmark, I think. Then of course when you come to France. I had three years in Montpellier and I'm now married to a French woman. I have two French kids.
Reg: Nice.
Karl-Erik: I have three teachers at the house for the French language so—
Reg: Well and you're absorbing the French culture is such a delight when we're on our calls together, because it will be like mid-morning North American time and it will be after suppertime your time and you'll have this wonderful glass of red wine in your hand while we're chatting. It's always a new one. I'm always just so impressed with how you've totally absorbed all aspects of the rich culture.
Karl-Erik: Well this is a part of the culture. And the other thing, you know, privately—I grew up in a restaurant kitchen. My parents ran a restaurant hotel in the countryside in Denmark, so all of my homework, all social work, all social life was in the kitchen. A big, nice restaurant kitchen. And here's the interesting thing: My French wife, her grandmother, was also running a restaurant in France. So we have cooking competitions here, but she beats me out of my socks.
Reg: Hmm. What a great way to lose.
Karl-Erik: Right. Right. Absolutely. Absolutely.
Reg: Well we've gone about 40 minutes. This is great. I never go this long but I don't want to stop until we've got…. Do you have anything else you had in mind… because you've got such a wonderful depth and breadth of experience?
Karl-Erik: Well, back to our book. I think this is important. This is important. Get the kids onto this because we have a big problem and it's getting bigger.
Reg: Yes.
Karl-Erik: Just an anecdote: A week ago I was contacted by a headhunter working for a very, very, very big French bank that has about 65 LPARs running z/OS, and 40-year experienced guy is leaving and they have now hired a young guy—well, 40 years old—with two months to pick up 40 years of experience.
Reg: Wow.
Karl-Erik: So as I told you, I'm not quite young but they actually offered me a three-year job doing that. I said no, no, won't do that.
Reg: Well you know what we need?
Karl-Erik: It was just out of—yeah, go on.
Reg: You and Cam and David and I, I think need to make sure the world knows that we are available to help people connect up with mentors, but also to appreciate that a mainframe mentor is not somebody you hire for a miscellaneous task and just pay them, you know, for their time. You know we need to make sure that people understand that you're getting the depth of experience that comes with, you know, everything since 1964 or even longer and to value it that way. Because that's the only way we're going to encourage other people who are at or beyond retirement age on the mainframe to be available for this ongoing mentoring in a manner that actually affirms it rather than uses them and treats them with less value than they have.
Karl-Erik: Yeah, that's what I told the guy. I said I'm perfectly willing to take a coaching role or a mentor role if you want me to and that could—I mean I'm not going back to working five days a week. You know I teach about one, two, sometimes even four days a week but only for a few hours, so I told him that. I can do that. I can put you in the right direction. I can coach if you will and kind of get people up and running a little bit faster, and of course I'll hand them the book, our book, as the first thing, right? And then there's a lot of stuff: Redbooks, I mean Redbooks is absolutely incredible what is in there, like APCL Systems programming.
Reg: Oh, what a wonderful resource.
Karl-Erik: That is absolutely incredible and with just one thing that a lot of people forget. When I started this special education for one year, we used Donald Kruth's "The Art of Computer Programming." That is just—
Reg: Oh, that old treasure.
Karl-Erik: Smashing. That is fantastic.
Reg: I mean that's—what is that, 1970 or—?
Karl-Erik: Oh yeah. He thought he would write 14 books, I think. He ended with four but one thing he did that I—that made at university later was the MIX 1009 machine. I don't know if you ever heard of that. Do you know 1009 is MIX in Roman letters? This was and here's the story. Apparently he was a big fan of Tom Mix, the famous—
Reg: Oh cowboy, yeah.
Karl-Erik: What I read some—we didn't read it from end to end but we read it for the MIX machine. And then when I got to university a few years later, while I was working, I took a bachelor degree. They had implemented the MIX 1009 on a CDC 6600 I think, so I got to program the MIX machine.
Reg: Oh fun.
Karl-Erik: Oh that was absolutely smashing because it was Assembler language of course, but it was pretty well documented and you could make things. I think we made a program that would cut the newspaper front pages—you know, cut it into what do you call, columns running on the MIX machine.
Reg: Wow.
Karl-Erik: That was—I'd forgotten to talk about that but that's one of the founding things also. But apart from that the Redbooks is—I mean I have customers you know when you present a new processor, they said "is the Redbook out?" I said no. "Well come back when it is." So what happens when we write Redbooks is that they are usually made publicly available on announcement day, right, so people can see this new machine. They have the manual, the official manual and then they have the Redbook that basically tells you every minor little screw or table or whatever is inside the box is described there. The customers starts from one side to the other, right?
Reg: Nice.
Karl-Erik: So Redbooks, Redbooks, and Redbooks.
Reg: Obviously the name is appropriate because they should be read, but I'm thinking we perhaps should have put more red on our cover.
Karl-Erik: Well you know in the beginning the books were orange, coming from Washington System Centers. Those are orange books, right?
Reg: Ahh. Interesting.
Karl-Erik: The other thing—can I say one last thing about Linux and the mainframe?
Reg: Sure, sure, sure.
Karl-Erik: There's a gentleman called Michael McIssac who now no longer works for IBM, but he went ahead and made something that he called the cookbooks. So that would be a cookbook for Red Hat on the mainframe, cookbook for SUSE on the mainframe, and this was an amazing piece to take to the customer. Here we are with Linux. The customer is new. We take the Redbook and you start on Page 1 and when you're done, the customer has CVN Linux up and running—
Reg: Awesome.
Karl-Erik: Absolutely fabulous, and he came back very recently and made a new one. Mike McIssac, great guy.
Reg: Cool.
Karl-Erik: What else is there? Well of course there's the mainframe on the PC—you know, the set PC which I've been using a lot. Excellent. Excellent.
Reg: Well now IBM is now offering a virtualized mainframe on the internet. We'll see what happens with that. That's kind of cool.
Karl-Erik: You know what happens there? They didn't say it but it's actually VM running z/OS. That is just—
Reg: Nice, very nice.
Karl-Erik: Everybody does that, but now IBM actually says this is a good idea. Absolutely fabulous.
Reg: It's so lovely to see IBM embracing z/VM.
Karl-Erik: Yes, oh yes. You know what? I think the customer with 65 LPARs, some of these LPARs should be virtual machines because they are there just to be there. My customer where I was the advocate, he had between 700-800 instances of CICS. and some of these would wake up you know to run a transaction here and there. So he actually—one of the customer personnel actually went to Poughkeepsie to write a Redbook about that, about when would you run a z/OS image on VM? When would you run it on an LPAR, right? You know now that VM can do light guest migration for Linux, right?
Reg: You know I had the opportunity to interview a Quebec government-owned outsourcer back in the early 2000s because they had won a prize from SHARE for what they were doing with Linux. And one of the questions—I interviewed them for almost two hours—and one of the questions I asked them, I said, "well how do you decide whether to put Linux on the mainframe or on Intel?" They said "that's easy. If it's well-behaved." I said "well what do you mean by that?" He says "well, you know if it sits there and chews up all the CPU it can get a hold of, then I put it into a little Intel cage and it doesn't bother anybody else. But if it's well-behaved, it wakes up, does the task and goes back to sleep. I can put that stacked in with all the other Linuxes in a single box, and we get that wonderful wave cancellation effect and we maximize the value." So it sounds like you've done the exact same thing with CICS under z/OS under VM.
Karl-Erik: Yeah. I agree totally with what you're saying. This is absolutely excellent. There's something else I would say but I've forgotten.
Reg: Well you and I have lots more conversations that we're going to have to find more opportunities for this.
Karl-Erik: Sure. Sure. Anytime.
Reg: Well so Karl-Erik, any last thoughts you have before I finish up with my little blurb?
Karl-Erik: Back to education. This is why I do this. We have to keep doing this, like Cam says. Otherwise we'll be in a big do very, very soon if people don't wake up. I mean—
Reg: We need new mainframers, yes.
Karl-Erik: Yes, yes, yes, yes, young ones. Not so young ones but people with a—
Reg: People under retirement age if possible.
Karl-Erik: That would be preferable, I think—
Reg: Although not necessary [laughs].
Karl-Erik: No, but that would a good idea, absolutely. Just one more thought: I'm teaching at the moment. You know I have usual students but then I also have some classes that are run by the unemployment office and the local companies and the school. So I right now have a class of 12 where two of the people are very close to 60.
Reg: Hmm, cool.
Karl-Erik: I teach them Linux, right? They just love it and they are very good, you know, because they are mature. They have another way of looking at things but it works very, very nicely.
Reg: Well that's an important thing to keep in mind as you educate new mainframers is there are actually some things that people who have been around for a long time learned in other parts of their lives that are compatible with how the mainframe thinks because it was invented back then [laughs].
Karl-Erik: Absolutely. Absolutely and that's what I keep seeing here, so yeah. So education, education, education for the mainframe is what I'm doing right now and maybe one day we'll write another book.
Reg: Oh I think so.
Karl-Erik: And maybe another one, right?
Reg: Yes.
Karl-Erik: Time will show.
Reg: Time indeed will show. Okay. Anything else, or shall I finish up?
Karl-Erik: No. Thanks a lot. It's been nice to walk back memory lane because it makes up a lot of things, a lot of good things that have happened. So I started this more than 50 years ago you know, so I could probably talk for hours.
Reg: Okay, awesome. Well let me see here. I'll be back with another podcast next month but in the meantime, check out the other content on TechChannel. You can also subscribe to their weekly newsletters, webinars, e-books, Solutions Directory and more on the subscription page. I'm Reg Harbeck.