‘Captain COBOL’ Tom Ross on the Evolution of COBOL on Z
Reg Harbeck: Hi, this is Reg Harbeck and today I'm here with Tom Ross whose nickname is Captain COBOL and he has been working at IBM on COBOL since the early 1980s. Well Tom before I describe you to the world, why don’t you tell us, how did you end up working at IBM on COBOL?
Tom Ross: I wish I could say that I was a brilliant prognosticator and knew that the future world would depend on COBOL and I'd have great career in it but I actually didn't even know that COBOL was a programming language! I knew PL/I and FORTRAN. I heard people talking in college about it and I thought they were saying Cobalt but IBM had an opening in the COBOL compiler development and I took it. My first thought was you already have a COBOL compiler why do you need developers but then I got a huge education about changing to the 1985 COBOL standard and AMODE 31 and more. COBOL has not been static for one day in my whole 36 years.
Reg: Cool. Now so you started in IBM I guess in the early 1980s. At that point COBOL had already grown a fair amount from when Grace Hopper first brought it into existence with the team she was working with in 1959. How much had COBOL advanced by the time that you first encountered it?
Tom: Well my first project was writing the new COBOL compiler that was called the VS COBOL II to support the 1985 COBOL standard which had been—we'd seen bits and pieces of it in the very early 80s but it was finally approved in '85. The previous compiler supported the 1968 and '74 standards, which were fairly outdated but the world was already running all the business processes on this old COBOL so the newer COBOL was welcomed by thousands and thousands of Z customers.
Reg: Now of course anybody who was around at the time of COBOL II will remember there were some important challenges including a fair amount of recompiling and testing. What did you find to be the biggest issues that customers had to deal with as they moved to COBOL II?
Tom: Probably testing but a lot of it was education. That's where I got my start was talking to customers about COBOL migration. We had a tool that could convert the '74 standard source to '85. We helped give advice about how to run testing, but nowadays we have a bunch of really cool tools to help with testing. We didn't really have those back then but that was probably the biggest issue for customers was the amount of time running tests and analyzing the results. It was a bit expensive for some customers.
Reg: Now since you then helped implement the COBOL II standard, COBOL as you pointed out continues to enhance and advance. What are some of the important advancements you've seen during the 36 years when you've been right in the middle of the world of COBOL?
Tom: Well one of them was when we consolidated the run times between COBOL, PL/I and C so that they were all sharing the same run time. There was a common problem in the customer world; if a PL/I program mixed with COBOL, if the PL/I stopped, it would close all the files that were being used because it figured it was—the application was done but PL/I was actually called by COBOL and it wasn't done so we coordinated the run times in 1990 with language environment. That was a huge deal. Then about the same time we added support for the intrinsic functions amendment to the COBOL '85 standard. That came out in 1989 so we added things like standard deviation, and MIN and MAX and really cool useful functions that customers could use.
Reg: Now you remind me when you talk about—sorry. Go ahead.
Tom: I was going to say then there was the 2002 standard. We started adding those features and we added object oriented COBOL to enable direct integration of Java into COBOL applications. Then the 2014 standard so it's just been a nonstop—Oh, then XML and JSON were also big new features that got adopted quickly.
Reg: Cool. Now before I ask you about some of the most recent enhancements because I know there's some pretty impressive stuff in the latest release of COBOL. I have to say you talked about the PL/I closing files and I am remembered of the-reminded of the old COBOL STOP RUN issue under CICS. Were you there when that one had to get resolved or they had already fixed that by your time?
Tom: I had heard about that but it's not a problem anymore but I have heard people refer to it. I think that was before my time, before we started coordinating everything. VS COBOL-II—one of the advantages of VS COBOL II is it’s super well integrated into CICS. In fact the old compiler couldn't even generate reentrant code. It couldn't do AMODE 31. VS COBOL II was truly re-entrant which is what CICS requires and we tied all of the system calls into using CICS facilities directly so that CICS could prevent things like shutting down a region with a STOP RUN.
Reg: Now I understand that IBM takes COBOL so seriously that they've actually changed the mainframe hardware to make COBOL perform better and some absolutely amazing things have happened recently as a result of that.
Tom: Yes, that's super exciting to me. In 2017, we announced the z14 hardware which had a facility among other things but the one that I liked being a COBOL guy was the vector decimal facility which allows—we can have a COBOL program do math in some cases 97% faster, 97% less CPU to do the same arithmetic using z14 instructions.
Reg: Wow.
Tom: As anything previous, even decimal floating point is nowhere close to that and of course way better than the packed decimal instructions that COBOL has been doing math with for 50 years so the vector decimal facility for COBOL version 6.2 and z14 is super exciting for COBOL.
Reg: Now do you have to change your program at all to take advantage of that?
Tom: Nope. You just take the same source and recompile it and then run tests. Now here's where my migration talks come in. The source is compatible. Everything will recompile with COBOL version 6.2 but sometimes when customers get new better instructions generated, we get a revelation that these programs have been processing invalid data for years at run time.
Reg: Whoops.
Tom: So they've had—whatever garbage in they were having, they liked the garbage out that they got but then with COBOL 6.2 they can get different garbage out and then that's a failed migration so there is some initial validation to be done. The new instructions don't always do exactly what we want. If the data is valid, which in COBOL means it matches the PICTURE clause and USAGE, then we guarantee results and most customers have no problems with this at all but some of my customers have a bunch of problems and so there is some testing involved but I usually say about three quarters of the customers have been processing valid data and they get—so they recompile and run some cursory tests, go into production and enjoy the improved performance with no migration problems. That's the more typical scenario.
Reg: Very nice. Very nice. Now you know one of the main things about COBOL is, there is so much about it which for people who don't know about it is unexpected, but for those of who know we practically take for granted. You know there is nothing really humdrum about it even though it might seem that way. Well it seems to me that the same is also true of a career in COBOL for somebody like yourself while at the same time as remaining a techie all the way through it sounds to me like you've also had the opportunity to teach, to travel the world and meet customers all over the world. Is that about right?
Tom: Ahh yeah. It's been quite a ride. It's really been amazing to see Australia, Japan, Denmark, you name it. They're running their governments, their utilities and businesses on COBOL on Z.
Reg: So just like Bob Rogers says that the world runs on System Z, I guess also the world runs on IBM mainframe and COBOL.
Tom: Yeah, the language of System Z pretty much. The most commonly used language is COBOL and Z processes all the world's businesses or at least all the big ones. Also it is Z and COBOL together, great partners.
Reg: And what's the most out of the way place you've been able to get to as part of working on the mainframe and COBOL?
Tom: Well I would guess—the first thing that pops to my mind is like I visited a couple of banks in Istanbul but my favorite trip was the to the Guide Share Europe Nordic division had a meeting in Iceland.
Reg: Nice.
Tom: And that was really interesting.
Reg: All right. The one place I have not been able to find a mainframe yet is Antarctica and I was sort of sad about that because being able to travel wherever I've found mainframes. I don't suppose you have found any there have you?
Tom: No. I don't even think there's buildings in Antarctica or electrical power.
Reg: Fair enough. So now tell me, I understand also your whole career has been lived not actually in but near Silicon Valley. Is that right?
Tom: That's true. Born and raised in Silicon Valley.
Reg: So you must have seen interesting things come and go you know working for IBM with COBOL in this place where all these other technologies turn out to be much more ephemeral than we expected. What's it been like having this whole career of just kind of keeping the world economy running with the technology that actually works while dealing with – as you pointed out to me in a discussion earlier – programming languages that can't even handle dollars and cents so they literally don't make sense?
Tom: Yup. Yeah, it's been kind of interesting. It's scary sometimes when these sort of, I don't know, I was going to say crack pot but that might be too mean but these new ideas come along and everyone thinks they're going to change everything and move to something else. Then they tend to come and go and COBOL is still there chugging away running everything. It's kind of satisfying.
Reg: Now as you look around at the world of mainframe, obviously we're sort of right in the middle of a long slow glacial change to the future of the mainframe. We've got new people in the workforce and the technology continues to move forward. If you were to think about your expectations and hopes for the future of the mainframe, COBOL and otherwise, where would you like to see it go over the next few decades and maybe centuries?
Tom: Well that's a good question. One thing that comes to mind is I wish our universities and colleges would recognize what's going on in the world of programming instead of trying to chase the very latest ideas and you know Node.js and Swift and things like that. They are wonderful and interesting but there's not a recognition in colleges’ curriculums that there is a need for COBOL programmers out there. Now on the other hand, I think COBOL is the easiest language to learn. It is very readable and it was designed that way. I have a heck of a time reading C and Java sometimes but COBOL is easy to learn and so I hope there is a recognition that we don't—in both like a dual prong approach. One is I wish the universities would—more of them would teach COBOL. We have a bunch of them. The IBM Academic Initiative is working with universities to help produce COBOL knowledgeable people. There was a Texas university that added COBOL and they found that their graduates with COBOL as well as Java made $30,000 more per year than graduates who only had Java so that's a huge thing. That kind of thing needs to get out there so I wish universities would get on board with realizing what the need is for from graduates. I know they don't want to think of themselves as training for jobs but a lot of people think that college is just that so it's a practical matter. The other thing is I wish that companies wouldn't worry about whether colleges teach COBOL or not because you can hire someone who doesn't know it and they can learn it in no time. When I first joined IBM, I didn't know COBOL so my first week I wrote a program to process my weekly running mileage and draw a graph of the output. It was fairly simple. No one helped me. I just looked at the manual and wrote the program. It was processing files and reading and writing and all this stuff so it's quite easy to learn. That's another thing I hope that my customers will realize that just because the students are being taught programming language X, Y, Z today doesn't mean they can't be hired and work on COBOL tomorrow.
Reg: You know that's such a good point. So much of the mainframe does get learned on the job and I likewise, my first experience with COBOL was actually on a job programming and then I took a course on it after actually spending a summer working on it, which of course was part of what Grace Hopper wanted when she worked on the design of COBOL, is something that was as close to self-documenting as you can get and I guess there was a fair amount of success in that.
Tom: Absolutely. I think she scored on that one.
Reg: Any closing thoughts about COBOL or your career on COBOL or the mainframe that you'd like to share with everybody?
Tom: I don't know. It's been a great ride. I really enjoy it. It's so very relevant. If we screw up and cause a problem for customers by doing something wrong in the COBOL product, we hear from so many people. It's really amazing how important it is for us to do things right because there's so many people relying on it. I'll never forget. I was at a very large retailer, probably the largest retailer in the country and I had my screen on the wall you know being displayed giving a presentation. I asked a question about something and so I went into my email and was looking at all these folders. I had a folder for each of the customers I'd been corresponding with, which is hundreds, and they were shocked to see all of the these huge names. Basically it's the who is who of business in the world and they're wanting to talk about COBOL. They were really happy about that because they were completely dedicated to COBOL and some of the airline magazines say you shouldn't do that. It's not the latest thing, blah, blah, blah so they were very reassured to see that everyone else is doing it too so that was kind of fun.
Reg: Well thank you so much Tom. This has been a real treat. Thank you Captain COBOL.
Tom: You're very welcome.