Derek Britton on the Language and Application of COBOL
Reg Harbeck: Hi, this is Reg Harbeck and today I'm here with my colleague Derek Britton who is a very active member of the enterprise computing community and especially the COBOL community. Derek, maybe if I can get you to start by tell us how did you end up being such an aficionado of both COBOL and enterprise computing?
Derek Britton: Hi Reg. Yes, well, thank you for having me here and thanks for the question. It's a good question, actually. My hope is that I'm not a complete stranger to some of your listeners as I've been working with TechChannel, for example. I'm been published by TechChannel, Systems Magazine as it was before that. Plus, I’ve written for and presented at places like SHARE, GSE in the U.K. and Europe and perhaps more recently, more notably on the Open Mainframe Project where you and I have spent some time together, Reg, but if you look me up on LinkedIn or Twitter today, it says something like tech marketing guy so you perhaps think well, that's not really an aficionado of enterprise computing perhaps and the role I have today I'm not going to lie about that but my story with technology and enterprise systems well it starts quite a long time ago when I joined a company called Micro Focus as an intern. Well, it was last century, 1989, I joined as an intern and I was in the middle of a bachelor's degree in computer science and Micro Focus had an internship program at the time. When I got there, the first order of the day, of course, was to set me up with machinery; nothing really changes and of course it took longer than they thought it would so nothing does change. What they presented me with was this nice shiny new IBM XT PC. It had 5.25" floppies running MS-DOS as I recall.
Reg: I remember those.
Derek: Yeah, fantastic bit of kit that was and you also couldn't steal it because it was too heavy—
Reg: Never trust a computer you can carry, right?
Derek: Precisely, precisely and it also served of course as a terminal to connect to their mainframe at the time which is where they housed their email system, their print service and a variety of other applications and such like so from the word go and kind of without realizing it actually I was the full mainframe user guy that didn't realize that was what was happening to him at the time. But the reason I took that job, the reason Micro Focus offered it to me in the first place as an intern and then a couple of years later as a grad was because I knew a bit about this thing called COBOL. Of course, I knew it at the same level that I knew C or Pascal or whatever else I'd learned at the time at university. Even though I had used Micro Focus COBOL products to learn it on my degree course because Micro Focus was among the vendors who could supply that kind of learning—training program at the time, I hadn't really joined the dots that I was actually joining the organization that actually built the COBOL products, the people who actually wrote the compliers were in the same building as me; of course a COBOL complier in written in COBOL as you would expect and I think probably from that very point when I realized that fact and I spoke to some of the people responsible that COBOL kind of got under my skin. I think if you cut me in half now—let's not run this experiment by the way—if you cut me in half now, I think it might say COBOL through the middle, so I was lucky enough to work on said complier for awhile when I returned as a graduate. Then I ended up helping the team that was building complier products for a range of what would be called in today's terms anyway emerging new platforms so this is where the manufacturers of the day—and of course this was around the early and mid 90's—where the manufacturers of the day were building machines as fast as you could come up with a new chip architecture or a new operating system variant and so the pervasiveness of COBOL is that's kind of where that started out. Now COBOL is a highly portable language and it was designated as requiring to be, way back when they designed in the 50's, but actually the availability of such diversity of machinery and operating systems, that really didn't take off in quite the same way until the mid 90's when there came along dozens of variants of UNIX and something called OSF/1 from Digital and later something very strange looking called OS/2, even more curious still this thing called a Windows environment. I remember seeing what was it version 3.0a when it was supplied to us by various vendors.
Reg: Well, the immediately pre networking version.
Derek: Yes, and it really was a bit of a challenge to get anything working on it, let alone COBOL. Now so remember back there was effectively a pitched battle between these manufacturers about who was going to emerge on the desktop as the machinery of choice and UNIX or something version of it was a big bet for many but there were literally dozens of options, Reg. You know chip sets, variants of whatever it was: System V, UnixWare. So you have people like Texas Instruments. You had SGI, Olivetti, Toshiba, Sequent, Sun Microsystems, HP. There was this thing called AIX as well, which I rather liked. It was quite good. It was quite robust by comparison. Now, but each manufacturer would ship their new box almost fresh from the factory, paint still wet if you like with a BIOS manual and we'd have to start tweaking the product almost reverse engineering it based on the BIOS to figure out how it would work on that OS and chip against the BIOS, the printers and the screen and whatever have you. You should have seen my desk at work. It was like an Aladdin’s cave. I mean you couldn't find me but you could find a lot of machinery and it was from all over the world, from Europe, US, and Japan and as you could probably gather from the way I am describing it, it was you know they were halcyon days. It was a very exciting time for the IT world in general but just for making what was already a very established technology available on as broad an array of machinery as the market was demanding at the time. So, sort of that's how it all started out and that's what Micro Focus, that's what its business was back then: building portable COBOL products that worked across all of these environments and it's interesting—
Reg: That's so interesting. Yeah, I guess we both agree that it's interesting but as you're talking about that and it is so parallel to the journey of UNIX because I remember back in the early 90's, UNIX was basically write once, compile anywhere except it was actually write once, debug everywhere and then of course, there was other products that rode on top of UNIX that were complied according to the same theory. You know I was working with a few of those and to be reminded that in fact COBOL was one of the first things that was really designed to be multiplatform, and I have to admit I didn't know the complier for COBOL was written in COBOL but it makes sense. I mean the C compiler is written in C, so continue on.
Derek: Right. Okay well some of the OS specifics that you would use you know under UNIX you would use C to call the OS to do certain things. Some of those lower level functions and on DOS based systems, you would use 8086 Assembler to do the same thing. But fundamentally the guts of the compilation process is a single descent pass written in COBOL. It compiles itself. It bootstraps itself in order to get the compiler to work and yeah, you're right. Very few technologies can claim that level of portability or compatibility across – well, what they wanted to call standard environments but as you've rightly suggested, it was anything but a standard environment at the time. It was people vying for, jostling for position to create what was to become an emerging standard and no one really did it as well as COBOL did back then. Remember there was no Java at the time so there wasn't even that comparison so the inherent portability which is actually to be honest one of the facets of the language isn't that widely known especially outside the mainframe environment because COBOL is known as a bedfellow of the mainframe. COBOL—
Reg: Yeah.
Derek: COBOL, CICS, and the mainframe: kind of that's the holy trinity to be honest and so it's a fairly well-kept secret in the mainframe world that COBOL could actually happily coexist alongside and of course there are some use cases where that would make sense. It was a big part of how it became so pervasive, and I mean perhaps one of the interesting elements of that is that of course COBOL doesn't really sit on its own at all. No language is an island—
Reg: Yeah.
Derek: And as I've said like JCL is the driving engine and CICS is the traffic cop. Without those stable mates, it's not really as meaningful in terms of building enterprise class applications.
Reg: Right.
Derek: So versions of all of that came along at a similar time to provide a fuller experience so no surprise at all and I thought it was worth mentioning here that there was an awful lot of collaboration between the people in our labs when we were working on the COBOL compiler products and folks like the guys down at Hursley Park at IBM and other IBM labs to ensure that the COBOL that we were building was consistent and compatible with what was going on then on the mainframe and indeed what might be happening on AIX and elsewhere hence things like AD/Cycle to effectively unify the overall approach with how things were being built and delivered and so we collaborated a heck of a lot on a lot of products that ended up on other IBM platforms and the mainframe compatibility of a lot of those things simply exist because of the collaboration between the various divisions and very, very smart technicians on both sides.
Reg: Well, it sounds like you had the chance to hang out with the good folks in Hursley a little bit yourself.
Derek: Well of course it's just down the road from our HQ here in the UK so I mean it's a car ride away if things needed doing so there were I think regular kind of tech, I can't remember the name they used but anyway there was a sort of a formalized program of technology swaps and preview sessions that we were able to do for each other when it's appropriate to do so of course. And, depending on who was coming out with what feature first or what because, remember: the COBOL standard is itself an open standard so you apply to the standards body and then they decide what's sensible and what's not. Sometimes you go ahead and implement things yourselves anyway and see what the market penetration is. All of that was going on over the last three or four decades so—
Reg: And you've been right in the middle of all of this so your career has sort of grown up in parallel to this. So, we have you in the 90's now and then of course Y2K comes along. That must have been a really interesting experience for you personally.
Derek: Well, I think it was an interesting time for everybody wasn't it?
Reg: Well, it was for me.
Derek: Because I think there was, and I'm going to touch on this again in a short while where we talk about you know COBOL’s enduring pervasiveness and viability as a language gets tested on a regular basis. When I do some presentations about the COBOL language which I do from time to time, I—my favorite quote is one from 1960. 1960 was before the first COBOL complier had even been released and someone—
Reg: Because that was in the fall of '60 that it actually came out on GA right?
Derek: That's correct. They didn't have a working complier until towards the back end of 1960 and earlier that year someone—it's anonymized but it can only be one of about a dozen people said, “I don't see this lasting out the rest of the decade.” They hadn't even released the first version so people were – there was a small number of people paddling frantically with COBOL but there was plenty of people throwing rocks from the shore and the Y2K was another such instance of that where, depending on who you read, the sky was falling or it was simply a straightforward engineering problem that had to be resolved for a number of applications provided you could identify them in time. Of course, many people ignored the signals and therefore there was a rush, and people made a lot of money doing a relatively straightforward task for a number of organizations because people had maybe forgotten or overlooked the importance of those things. But it was actually a relatively straightforward fix.
Reg: That said, I mean you know you want to talk about “windows crashes.” We've got some of those coming up with a lot of these applications that were stop-gap fixed for Y2K assuming they would eventually go away before the window ended.
Derek: That's right and the window ends depending on how you've done it maybe in less than a decade or so—
Reg: Yeah.
Derek: Or depending on how you've done that but you know it wasn't an insurmountable problem then. It's not an insurmountable problem in the future. It just needs planning and of course the technology availability which – and my organization along with many others had technology and consultancy to help solve that problem. The technology is so advanced now that you can have a find and fix exercise which I think in most cases would be relatively straightforward—
Reg: Nice.
Derek: At least as long as you plan it carefully. So, I guess fast forward beyond the Y2K because it was exciting, but it was somewhat anomalous. Everyone made a ton of money for a short space of time and then actually from the Y2—from 2001-2002 onwards a lot of people did look around because of course that was the time of the new dawn of ecommerce and everyone was getting fairly excited about the internet. Finally, people were figuring that you could actually do quite a lot of these things using your internet connection in a way that perhaps only the mainframe world had really understood in terms of connectivity. You know the rest of the technical world was catching up with that. So fast forward a few years beyond that. Micro Focus then says well, we need to be looking at, more seriously, what some of these COBOL applications are needing to do in the future and so I'm now spending time listening to mainframe users. In the US, I listened to big banks or insurers or health care providers—
Reg: Now just for positioning, how had your career gone to this point? You had your sort of change, you obviously weren't an intern anymore and it sounds like you'd gained quite a bit of experience with the same company so your roles must have sort of reflected a lot of this.
Derek: Yeah so, I'd moved out of a purely technical role at this stage into what's termed certainly where I work as product management so it's kind of looking after the product, the product owner if you like in today's terms without actually having to write the code. I think there's certainly a reasonable number of people at Micro Focus are very happy that I moved out of coding. It stopped them having to go back and sort of fix the bugs I would imagine so yeah it was a product management function so it was actually more front of house than a tech role, pure tech role would have been. So, I'm getting to hear, first-hand, from IT leaders in these huge organizations and even back then which is—this is still over 15 years ago I'm hearing about the requirements for automation, improved delivery processes, better collaboration across teams, between the teams that happen to use this kind of environment, that teams that happen to use that kind of environment so it doesn't quite predate the agile manifesto but it certainly predates DevOps and so those things definitely arrived at the right time as I think did a more open approach to technology so bring it forward a few more years. The mainframe delivery tool chain might have something liked Endevor or Changeman. I would recommend Changeman every time of course but my company happens to sell it so that might be the mother ship driving the whole thing but of course nowadays it might be using Git almost certainly, might be using Jenkins but using a modern IDE for the Dev side. It might have a distributed collaborative testing process, might be using Cloud facility to provide some resources. It might be using containers as the delivery model. Well, it might; it might not. It doesn't matter. It's all possible. It's all plug and play. It's all connectible now and it's all adding value quickly to what are core cherished critical systems that are still being delivered to the mainframe. That's a huge step forward. It's a great step forward and it's the fact that everything is more connected now and enterprise computing is genuinely—that's all that stuff at the back end including now whatever you term as the Cloud including the mainframe. So, yes, I'm lucky enough to be able to spend time I think in the modern era talking about the fulfillment of a number of requirements that clients have been having for years if not decades Reg. None of these problems were new when I heard them. This wasn't a eureka moment in 2005. This has been the desire to deliver more with the resources that you had, the skills that you had and the applications you were working on. That's been a constant need—
Reg: Oh yeah.
Derek: And that need has been largely fulfilled by the advances of certainly the last decade. I mean I'm constantly astonished by the range of and the scale of the COBOL applications that continue to be built and delivered and the things that they are doing. If I can give you an example of that, the most enduring statement to me that I think I heard during that period and I kind of remember like it was yesterday simply because of the person in question. It was one IT director who put me very straight on something. You'll like this. I asked him about his plans for and these are exactly the words I used: “for his legacy systems” and he threw me what could only be described as a fairly withering glance and he said very quietly, very quietly and not very loudly which is obviously the worst kind. He said "Derek, these are not my legacy systems. They are our core business." When you consider the value of these applications, it helps you get a very clear level of expectation about how to treat them in terms of skills, in terms of investment, and in terms of attitude to change. I think that was the moment I truly realized the profound and enduring value of COBOL technology and how vital it was to some of these organizations so that throw away statement about COBOL powering the economy if you like and everyone uses it sort of liberally sprinkle around statements about COBOL being the bedrock of the economy. Well at that time, you know that client was using COBOL to process – I check this later on and they were adamant. They were using COBOL systems to process a third of the country's entire healthcare claims.
Reg: Wow. Wow.
Derek: So, you don't really want to try to count up how many that is on a given day but I mean this is a huge, huge IT undertaking and they were using COBOL to drive that; there I was saying so what are you going to do with all this dusty old legacy stuff. He put me very clear on that very quickly and it was at that point that I realized this is enterprise computing is and COBOL, that's the stuff the grown-ups do.
Reg: Well, this is so important.
Derek: This is significant.
Reg: I mean just even the word “legacy,” you know: I'm one of the many people who have sort of taken part in the battle of not even redeeming the word “legacy” so much as recognizing that it is merely a word that is being tarred by – you know – people who were flashes in the pan and who were going to go away, and the legacy stuff is still going to be there because that's of the very essence of what it means to be legacy. The legacies are the things that make us who we are.
Derek: That’s right. Yes.
Reg: Those are the things that are still there from a time when we were a kid until when we're grown up and retiring and still keeping the world running. COBOL and that type of enterprise computing have really become a legacy in a way that computing is such a new thing and yet we already have legacies and COBOL is one of them.
Derek: Absolutely right and well I mean you look it up in Webster’s or whatever it says something like a benign gift from the past. I think in COBOL's case, those applications, cases I would add an extra clause on that. It's a benign gift from the past and the present because actually the point of COBOL is that it isn't a 1959 language at all. It's a 2021 language that was invented in 1959 and the same way the motorcar is not a 1923 technology unless you have a Model T and no one does. It's a 2021 technology. It's how much investment you choose to continue to make that dictates its continued viability.
Reg: You could say it's “the present from the past.”
Derek: It is and I know I could rely on you to come up with a pithy one liner.
Reg: So that said, now meanwhile you've been living a whole life parallel to all of this stuff, and you probably have some really interesting things happening that are complimentary to your career in COBOL and computing journey maybe involvement with user groups, that sort of thing. How has that all sort of played together to get you to where you are today?
Derek: Well it's interesting when you consider the technology that we've been talking about and as exciting as it is, I've been talking about customers of course but there are a silent majority let's call that of the enterprise computing crowd are relatively comfortable with COBOL as a concept but pretty much anyone coming into an organization, if they're not lucky enough to have the experiences I had, they'll happily go through more or less their entire career without really understanding the profound value of COBOL. So, the importance of the reminding organizations or communities or any other stake holder of that enduring importance is very clear but this is the benefit of hindsight I'm afraid. I'm looking back from 2021 backwards knowing that it was hugely important to have a community that understood and was evangelizing the value of COBOL but I think a couple of things have drawn me towards that. I mean the good news is COBOL has always had its fans; it's always had its detractors; it's always had its fans and you would find those guy at SHARE. You would find those guys as GSE and Micro Focus and along side some of our vendor buddies, we've been attending those community events – let’s call them that – for years if not decades but actually the thing that happened over the last couple of years I think which has brought it into sort of fairly sharp relief is first of all, the anniversary of COBOL's, the 60th birthday of COBOL came up in 2019. I marked the anniversary in September when they came up with the name which was the only thing they actually could agree on in that particular month so I think that that's the one we stuck with so you know in marking that 60th anniversary, I wrote a white paper to mark the occasion and I spoke at SHARE that year with Tom Ross – “Captain COBOL” – of IBM to help me with that, possibly the highlight of my career until today, that is, of course. Well, that's what it says to say here on this cue card anyway, Reg. I got a slot on Frank and Jeff's Terminal Talk to talk about the COBOL anniversary, dizzying heights, I know, as you can imagine.
Reg: Those are good, really good guys. Those Terminal Talk podcasts are excellent.
Derek: Yeah, they are but I mean that's one thing and there was a notable amount of outpouring of interest and I think relief in some cases from some of our customers to see just how much—how vibrant the discussions were about COBOL, a lot of very positive press but then less than a year later what excited me then was the news stories around when various IT leaders. They can go unmentioned here talking about the heart of the problem of why you know they couldn't process unemployment checks just for the sake of argument. They couldn't do that quickly enough and apparently COBOL was to blame. Now of course excited is not quite the verb I might have used in private, but I think you get the point about my reaction to that news. I find myself blogging fairly feverishly about this to put across my view and I wanted to say “Look guys, COBOL is still in the top 30 popular languages according to the TIOBE index which you can look up yourselves.” I also wanted to say COBOL is strategic in nine out of ten cases according to a survey that we'd run only that year. I wanted to put the record straight, but I also noticed there were a number of other people who were blogging to try and put the record straight at exactly the same time. There was this sort of almost outpouring of emotion about: well, wait a minute. No, no, that's not right about COBOL. You've got to get this in perspective. You've got to hear the truth here and so a few of us got in touch with each other, almost like one of those support groups that you set up, Hi I'm Derek and I love COBOL. It's nice to meet you all and that sort of thing but we decided to do something about it so I spoke to a few people. Cam especially I spoke to and we both—
Reg: Dr. Cameron Seay.
Derek: Yup. I spoke to John, John at the Open Mainframe Project, John Mertic—
Reg: Yes.
Derek: I said look. Can we set something up here? I think there's enough of us that want to just get together, and tell a story here and to set the record straight on COBOL? John loved the idea, immediately thought it was great idea and you'll remember the idea, Reg, because you jumped right on in as well and we've gotten a lot of support since and in fact that Open Mainframe Project support of COBOL has proven to be a fresh impetus I'd say in terms of getting attention, getting that community reenergized and reengaged which is absolutely great for the language but good for the community at large as well so I think looking ahead if you consider those couple of things: The anniversary, the – shall we say – the naysayers that caused that sort of backlash and the generation of the new community spirit, I think as well as being a Micro Focus employee which I still am but as a member of the OMP, both of those roles kind of together allow me to continue to tell that story of COBOL through social media, through SHARE, through OMP itself, through GSE and elsewhere, through TechChannel of course because for me core enterprise systems need enterprise-class technology to last and COBOL is a key ingredient in building robust enterprise technology systems. You know it's a key part of that stack. It's portable. It's good for business. It's pervasive. It's very easy to learn. That's why I fell in love with it in the first place because I could get it far more easily than I could get C and it's constantly being updated so it's kind of the best in the business. That's another pithy one liner you can use there.
Reg: You could almost call it the Rolls Royce or perhaps more accurately Bentley of computing programming languages.
Derek: Well I think B for Bentley make a lot more sense doesn't it so we can go with that. Yeah. I think Bentley will be delighted.
Reg: Great. Hey, any closing thoughts or maybe a vision for the future of enterprise computing and COBOL?
Derek: Well, I mean given what I've just said, I'm talking about an uptick of interest and usage and usefulness, viability, and understanding and appreciation and all of those exciting happy things going to happen in the future. I think what we have to just do a check on is whether or not that's true or whether that's just Derek's—what would you call it? Triumph of hope over expectation or whether indeed we're just on a down slope with COBOL. Our worry is that quiet belief born out of that ignorance. People don't understand it, so they just assume it's going away, that it's been phased out. Well, we and by we I mean the Open Mainframe Project but the COBOL community at large, we want to know the truth. We really want to know the truth, so we have a baseline. We have a level set so that we can actually tell the world once and for all exactly what are we talking about here so we've surveyed the market. We've asked a bunch of people as many as we could to get a sense of how much COBOL there is. I'm not going to give anything away on this podcast but I'm sure that people will want to tune in for the time that it gets revealed and why wouldn't you do it here, Reg? I think it's a great idea, but I know the results are coming and what I can say is it looks like it hasn't gone anywhere. It looks like it's as much in use today as it ever was or as it ever was being projected. But also, I think in terms of skills, not just how much there is but how many people there are, I think it—there's a lot to do, a lot left to do to remind folk how useful it is and how easy it is to learn. So the OMP is building, and you know, a number of organizations to help with that as well, building a program of evangelism but also training. You have to remind those CIOs that COBOL is viable because it might not be their background. They might not already know so they need reminding. I think people like Misty Decker, who is also on our COBOL working group. She's even talking to legislators about government initiatives around legacy systems to make sure that training question is front-and-centre for the future as well. So, there's a lot of value out there, Reg, is my final thought, but it's a lot of value that still needs to be measured and still needs to be explained. I think we have to remind everyone of that and I still see that as my role in all of this: to continue to bang the drum and to tell the story. I think all joking aside when I talked with the Terminal Talk guys at the COBOL 60 session I did—was that 18 months ago or so? I said, “You know what guys? I'm so confident of this let's pencil time to talk again at the 70th anniversary!” So, and that's only eight years away Reg so shall—
Reg: Yes.
Derek: Shall we pencil something in now?
Reg: Well pencil it for 70 but you know I'm really interested in our conversation for the 75th anniversary.
Derek: 75 would be great too. Yeah—
Reg: Because here's the thing. That's 13 years from now. Our colleagues who are our age have 20+ years left on their careers. That's one of the beauties of being a mainframer is you can just keep going and it's amenable to developing that depth and that experience and it doesn't, you know, break you down exactly, you know, like some more physically intensive jobs do. And so I have a lot of colleagues who are in their even 80's still working on the mainframe. You and I aren't going to be quite there yet in 12-13 years for now so, 70, sure but 75 and maybe even 100.
Derek: 75, why not? Do you mind if I dial in from the beach?
Reg: Yeah, hey by that time you're probably going to have your hands free, just permanently attached to your ear, powered by your body's energy and you'll just be able to talk to whoever you want to whenever you want to from wherever so sure what the heck?
Derek: What the heck?
Reg: Yeah, so let's pencil both of those in. I think that we've got a spectacular future and I think part of our job I know for me, I mean I wrote a white paper in 2004 about the need to get a new generation on the mainframe. That was the 17 years ago and we're finally doing it but part of that is the incredibly slow realization, 21 years after Y2K, that the mainframe really isn't going away and COBOL really isn't going away you know. It's time for us to wake up and start thinking you know big positive thoughts about: Okay, so we've got this ultimate circumstance, this ultimate legacy that has so much potential to build on, now that it's proven itself like nothing else in the history of computing so let's do that. Let's you know open this engine up and see where it will take us?
Derek: Absolutely.
Reg: So that said, well thank you so much Derek. Any last thoughts before I sort of close off the interview for today?
Derek: Well, it's been a pleasure for everyone involved in the community on COBOL, the mainframe COBOL in particular, but anyone who cares about COBOL, the support we've had since—especially since the 60th anniversary has been phenomenal. 20,000 members on that Facebook COBOL community now.
Reg: Wow.
Derek: Growing membership on the OMP. Pretty much every barometer you look at, things are looking good for COBOL. The important thing is: understand that, recognize that, and get out to the people who don't yet understand because the more of us who are telling that story, the easier it's going to be and the bigger the party will be on the 75th.
Reg: Oh yes. Let's start looking for a good venue for that one.
Derek: Absolutely. Great to be with you Reg. Thanks for the time.
Reg: You bet. So 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.