# Retiring Mainframe Programmers: Should I Care?

| Posted by Don Denoncourt 2 Followers , reviewed by Shane Hastie 12 Followers on Oct 11, 2017. Estimated reading time: 14 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

## Key Takeaways

• Mainframe developers are not just retiring, they are expiring -- and young developers have little interest in mainframe careers.
• Mainframe programmers have be treated like bus drivers whose only job is to consistently move huge amounts of data.
• It’s not the mainframes that are aging; mainframes out compete Microsoft and Linux on features like performance, scalability, security, and reliability.
• Refactor code into reusable modules, with tests, and adopt agile practices.
• There is no ROI for modernizing mainframe applications in terms of quarterly results.

We take Uber, browse Pinterest, send tweets, and update Facebook. We hear every day about instant millionaires and the growing number of billionaires that built the latest gadgets in our high-tech world. But we ignore the fact that over 70% of all business transactions are processed on mainframes. Our visual and audio world is presented with tools hastily slapped together by young hotshots yet the reality is that the chairs we sit on, the paychecks we cash, the health care we utilize are available through data managed by mainframes. That’s right, over 80% of manufacturing, banking, and healthcare industries are on mainframes.

We hear so much hype about monetization of new markets that we fail to acknowledge the importance of mainframe code. Well, there’s this little issue… most mainframe developers are baby boomers who are approaching or past retirement. The harsher side to this reality is that the aren’t just retiring, they are expiring. (Short prayer for Jim Stanicki and John Stalher who were two exemplary mainframe developer friends of mine that died in the last few years.)

### I Smell Rewrite

Shouldn’t those old mainframe applications just be rewritten? It ain’t that easy. Yeah, I know, you’ve heard about rewrites for years. But the reason why most of those Visual Basic, dBase III, and PHP apps (that’s right, I’m saying they weren’t mainframe apps) were rewritten every 5 years is because they weren't written that well to begin with. Meanwhile, the mainframe apps have been running well for decades. The Return On Investment (ROI) for rewrites of mainframe applications just hasn’t been there. Case in point: In the mid ‘80s I wrote a traffic system for Hanover Brands Inc. that is still in use today.

But then there’s this retiring and expiring thing. Why not just bite the bullet and do the rewrite?

Rewrites are never easy and, for huge applications, they are often failures. Just a few weeks ago, I did a rewrite of a little, itty, bitty, PHP application to Ruby and Rails. Now, I’m pretty good with Ruby and OK with PHP but, even though it was just over a thousand lines, I still missed stuff. Mainframe Cobol and RPG applications are a wee bit more complex. It is common for an RPG program to be ten, and Cobol to be twenty, thousand lines long. Multiply that by hundreds and hundreds of programs and you have an application that has a mega-million lines. Worse that that, many of those programs were written before modular programming techniques became available. Typically, all variables in one of these behemoths are global. I remember, dozen years or so ago, I had a jest-quest in articles and seminars of a Diogenes-like search for a local variable in mainframe code. Diogenes never found an honest man and I had problems finding local variables in circa-70s code.

RPG specifically can be crazy hard to read and understand. For years RPG could only use six character variable names. Actually, its was worse than that. RPG had a bug where if you used the same column name in two different tables, they would share the same memory space. So RPGers used two to four of those precious six character column names to identify the system and table they were associated with. The bug was fixed decades ago and today the variable and database column name length supports at least thirty two characters. But six character variable names are still prevalent in RPG programs.

Somewhere around 1992 I gave a presentation on Cobol modularizing techniques to the team of Circuit City coders of which I was a member. After the presentation, one of Circuit City’s best Cobol programmers said she didn't see the benefit of modularizing Cobol.

Understand that I can get in a fist fight with other Ruby developers over a discussion on whether a method should be no more than 6 or 9 lines long. In Ruby development, wanton use of global variables might get you fired. So I kind of chuckle when I recall working on these 10-20,000 line programs. Maintaining Cobol and RPG monstrosities is often more voodoo than mastery. You try something that you have a gut feel will work and you light incense, sprinkle holy water, and pray to a variety of gods that your change will work.

The prevalent development practices of Cobol and RPG propagates use of outdated syntax. We are talking ugly code. Often thousands of lines of code in one program have been commented out. Many sections are completely unused. Looking at some of this code is like walking into a hoarder's house -- it's full of useless junk. To push the analogy perhaps too far -- the more junk that piles up the more chance of rot and, yeah, stench (and we talk of code smells.) The thing is: processes and materials you use everyday flow through this old rotting code the maintainers of which are retiring and expiring.

### Agility

Let me be honest… The reason I migrated my career away from the mainframe development workspace is velocity -- or the lack thereof. Development practices and toolsets for RPG and Cobol have languished. Test driven development, source control, modern editors, refactoring, agility… for years I proselytized such concepts in articles and seminars and not only was I, for the most part, ignored, but I couldn’t find projects to work on that followed such practices.

The essential word in my last paragraph was agility. Because mainframe application development practices lack agility they are slow to adapt to market demands. Often, the tarnishing of these old apps and the impending retirement of support staff cause new hot-shot C-level executives to suggest the procurement of costly ERP systems or complete rewrites. And we’ve all heard horror stories about such projects.

### Modern Machines

Understand that the mainframes are not antiquated. They are not the System 360 and AS/400 of yesteryear but the IBM z/OS and IBM i 64-bit operating systems with reliability and scalability that Linux and Windows can’t approach. They also have a lower total cost of ownership for complex data centers. You scale mainframes horizontally, rather than vertically. Those mainframes can run the latest software as well. Case in point: you can run thousands of Docker images on one mainframe. DB2 for i is arguably the best database on the planet. As to hot technology, A few years ago I was on a team the moved Ruby and Rails to the the native IBMi operating system. Banking applications run on mainframes primarily for security reasons. And it was a banker that funded the Rails port to the IBM i platform. There are huge advantages to mainframes: ranging from huge horizontal growth to the ultimate in security and very close to 100% reliability. It may be true that IBM is selling less mainframes but they are doing quite well upgrading and expanding the existing machines as they have astronomical horizontal scalability.

What is aging is not the machines but mainframe applications and application programmers.

## So, We Are Screwed?

Absolutely, just like we were when we hit year 2000 and everything crashed. It didn’t. We were just fine. We were fine because management finally started taking the two-digit to four-digit year thing seriously. If management begins to take the mainframer skills loss thing seriously, we will be fine.

Let me summarize my solution to the retiring and expiring mainframe coders thing before going into more detail:

• Modernize the database
• Refactor application code
• Train existing mainframers on agile and as trainers
• Coerce smart people into a career in mainframe development
• Convert existing code into APIs

### Modernize the Database

Modernizing the database is step one. A wealth of data kept in the world’s best database and operating systems is hidden behind applications that are twenty to forty years old. Many of the mainframe databases were created before today's well known database normalization and optimization techniques were created. At little as ten years ago I put a web front end on a table that was clearly housed, at one point, in a card deck. There are tools and available techniques that allow you to mock the old database schema’s structure so legacy programs may continue to run with little or no modification. From experience I know that refactoring the database is not that difficult to do.

### Refactor Application Code

I made a big stink earlier about the state of mainframe code. Know that mainframe code can be refactored to the point that development can be much more agile. Understand that I am not talking rewrite. Refactoring is the process of restructuring existing code without changing its behavior. The C-level executives should not have fear of the downtime that would be probable with a massive rewrite.

The first step to refactoring is to put code under source control. I highly recommend git. Perhaps the mainframe code is already managed by a source control package but my experience with mainframe source control packages is that they propagate sluggish development and dissuade common refactoring strategies. As soon as the code is in git, remove the commented out code -- it’s source control’s job to retain old versions of code.

The second step to refactoring is updating the development environments. Many mainframers still use green-screen editors even though powerful IDEs have been available for at least two decades. These modern IDE are bundled with refactoring tools.

The third step is to set up a unit testing strategy. Unit tests typically have very specific and detailed tests for program behavior. We don’t have time for that. What I recommend is to follow the Approvals Testing strategy developed by Llewellyn Falco (http://llewellynfalco.blogspot.com/). The basic concept of Approvals Testing is that you take snapshots of state before and after execution of a routine. That snapshot could be anything from a database query result, to a PDF, to a CSV. Be creative.  With the snapshot stored, you modify the routine and use the before and after images to verify that the refactoring did not change behavior. You may end up using a testing infrastructure that uses Java or Ruby or Python to invoke the mainframe routines but this layer will not be complex.

With a unit testing strategy constructed, the refactoring should begin with making variable names readable and understandable. Then start to whack away at reducing the use of global variables as you move into modularization. Duplicate code is rampant in mainframe code so use tools to find that duplicate code and then create common modules for them.

### Empower Existing Developers

The golden key to a refactoring strategy is your best mainframe developer(s). And now I’m going to get a bit nasty:  Mainframe developers have been treated by their employers like bus drivers. Management feels it is the programmer’s job to move data from point to point and, when something breaks, they are expected to twiddle with the engine until they can get back on the bus and begin moving data again. From my personal experience, they are often underappreciated and underpaid. Many of these mainframers have no degree and deal with C-level executives with Ivy-league MBAs that seem to lack the ability to consider the ROI for more than this next quarter.

These mainframers need to be empowered. The will need retraining on agile development practices and they also need to become trainers themselves. They will need assistance in the refactoring and the later creation of modular APIs. And then there’s the issue of retiring and expiring so it will be part of the empowered mainframer’s job to manage the training of new developers.

If one of your existing mainframers doesn’t stand-out as a project lead, go out and get one. The problem is that many of the folks out there that have more than enough ability to help have moved on. They’ve moved on to management, or training or, like me, they’ve moved on to other programming languages and platforms. The problematic thing with these people is that, decades ago,  they grew tired of the revolving door of C-level executives who turned down their recommendations for modernization. Many of these ex-mainframers may simply tell you to buy an ERP,  give Oracle a call, or do a complete rewrite (which they know from experience will probably be a failure.) So be prepared to wheel and deal with these guys.

Where might you find these ex-mainframers? Troll Linkedin for those folks that are attempting to hide mainframe experience yet have excellent communication skills and experience with new technologies and agile. Go to Java, Ruby, JavaScript conferences and talk to the folks that are over 50. Based on their age, they probably are ex-mainframers but they are also well versed in new tech and, more importantly, agile development.

Once you know what you are looking for you might not have to look too far. This paragraph may be cut because my editor is an ex-mainframer and an Agile coach. He probably will cut this paragraph because he left his mainframe bus driver job years ago. Go find a person like him to manage your mainframe modernization project. [EDITOR: No - I left it in because I agree]

### Coerce Smart People Into Becoming Mainframers

Colleges aren't teaching Cobol and RPG. There are blog posts and articles on Skill Loss that suggest colleges need to add mainframe course and otherwise attract millennials to careers in mainframes.

I don’t think millennials are the solution. I would not suggest a career in mainframe development to any youngster. There are far less jobs available and the slow development velocity makes for a less satisfying career.  My suggestion is 1) retrain existing non-IT staff and 2) coerce folks in their 30s and 40s into a mainframe career. Both of those suggestions sound crazy but I question the capabilities of a young IT graduate that is willing to begin their career on a mainframe.

The technical knowledge required to be a mainframe developer is more focused than the polyglot, multi-platform, programmer of today’s vogue developer. What companies need is not someone with NodeJS and functional programming skills but business acumen, a desire to learn, and, quite simply, smarts. There are plenty of smart people with non-IT mid-career blues that would be willing to have the opportunity to potentially double their salary after a year of on the job retraining. One area to tap would be retired military.

### Convert Code into APIs

The final step in a mainframe modernization process is to turn your refactored code into APIs. The will them be reusable software components. Often the parameter list of mainframe code will be so complex that it might seem that creating an API for it would be impossible. For those you create one or more wrapper programs (which can be written with Cobol or RPG or your new language of choice.) One technique I liked to use was to create SQL Stored Procedures that wrapped the legacy modules. With SQL Stored Procedures available, anybody with an SQL interface (JDBC-, ODBC-driver or whatever) can use those routines.

With legacy code available via an API (SOAP, REST, or otherwise) and unit tests for everything, development can be fully agile. New code can be written in whatever language you choose. And, yeah, you can hire millennials.

The more sensitive and complex programs that show up high on your churn reports can then be slated for conversion to a new language.

## Mainframe Agility

Mainframe applications, while being crazy reliable for all but half-a-century, are brittle with little, if any, automated tests, and the mainframe workforce either does not know about refactoring strategies or hasn’t had the C-Level management backing to start it. In short the code is not adaptable to changing business requirements. Existing mainframe programmers are retiring at an alarming rate and the workforce is not being replenished.

Moving off the mainframe is far from the most optimal solution. Complete rewrites or converting to an ERP is costly and fraught with peril. The mainframe boxes themselves are not aging. In fact they outcompete Microsoft and Linux on features like performance, scalability, security, and reliability. It’s not the machines but applications and programmers that are aging.

Modernize that database, refactor that code, become agile, shore up programming staff with internal training. And finally, where it shows benefit, start to move your newly modularized code into a new language.

The thing is: these solutions are dependent on C-level executive buy in. For them to do that they need to look past quarterly results and think about what the next two to five years will bring as they lose their undervalued mainframe developers.

Don Denoncourt is a developer for simplethread.com. He has been coding since before Windows and Linux, much less the Internet. In the early nineties, Don moved from RPG and Cobol to C and C++. He adopted Java before it was real: 1996. After coding his way through the proliferation of Java frameworks (including Struts, Spring, and EJB) Don pined for the Convention-over-Configuration framework of Ruby and Rails. Don did Groovy and Grails before finally moving to Rails in 2011. Don enjoys writing and has published a couple of books and hundreds of technical articles. Don has been working from home since last century. When Don is not working, he loves spending time with his 3 grandchildren. To keep his mind young, Don reads and listens to novels in Italian. And, to keep his body young, Don is an avid off-road and street unicyclist.

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Unit Testing

I might suggest that unit/acceptance testing be a first step before refactoring.

Of course, some amount of refactoring is probably needed to unit test.

How do you learn it?

How would one go about getting trained in COBOL. Any courses? How do you learn it?

Bug? Seriously ?

I agree with a lot of the comments in your piece Don but saying "RPG had a bug where if you used the same column name in two different tables, they would share the same memory space." betrays a fundamental misunderstanding of the original nature of RPG. It was always a designed-in _feature_ not a bug. It was designed to enable the programmer to avoid having to code hundreds of move x to print-x type instructions. And while the modern RPG language has many options that allow you to bypass the feature it still remains - it has not been "fixed" because there was nothing to fix!

Re: How do you learn it?

www.mainframes.com/Schools.html

Udemy.com has 2 courses on COBOL

Here's where you can find modern tools for the working with the Mainframe

To the author - you really should checkout the tools that Compuware.com offers. An eclipse based IDE with lots of mainframe focused tools makes working on mainframe code similar to working with Java. And they go beyond what's available for languages like Java. Want to view whats actually happening when a batch file/JCL runs in a visual flowchart like graph? Want to view the logic of a COBOL application in a visual flow chart like graph? Want help refactoring (Code Splitting) a large COBOL application? How about help creating Unit tests? How about test data with privacy rules applied pulled from real data? And how about a version control system that has the optimal lockless checkout ala git with the ability to "promote" code through various levels (dev, qa, test, production), integrate with lots of modern tools: Splunk, Atlassian, SonarSource, AppDynamics and Jenkins, etc.

Re: How do you learn it?

It's not a difficult language. It's different. You have to forget about "user defined types." But you can do classes, objects, instances. But that's where you hit the real social problems: Doing object-oriented programming in COBOL requires that you write a "program" for every "class." But your coworkers and the CxO's mentioned above are probably all stuck in using only (or mostly) COBOL-68 constructs and syntax. Use of later COBOL features to enable a different style of work ... Well, "We Just Don't Do That Around Here." is often the most difficult issue to fix.

Younger workers for mainframes-

If a mainframe shop seriously considered quality-of-life issues, decent pay, respect, and giving their employees a decent toolset, I'm sure they could attract enough younger workers. There's a lot of criticism of the prevalent developer brat-boy culture, and female CS graduates especially might rate hours and pay as more important than a trough of Lucky Charms in the breakroom.

Re: Unit Testing

I certainly agree with your assessment. Figuring out how to automate tests of your monolithic programs is going to take some forethought and research that probably should start on day one (actually, it should have been started decades ago). As I mentioned in the article , the ability to run those tests will take additional infrastructure. That infrastructure may come with the IDE you selected.

Re: Here's where you can find modern tools for the working with the Mainfra

Jim:
On your recommendation, I did check out Compuware. They certainly some great tools and strategies. A fellow from Compuware reached out to me to yesterday and we will be speaking in more detail about what Compuware has to offer.

Re: How do you learn it?

Online courses abound and are searchable on Google. Several other folks have posted links to courses. I have to recommend www.mantatech.com courses as I actually wrote (actually, rewrote Pascal) their Java-based e-learning software. The have more on RPG than Cobol but their learning strategy with constant assessment tests is excellent. Many companies use their (RPG specifically) assessment tests to qualify candidates and to award position increases.

Re: Younger workers for mainframes-

Thank you Paul. Good point. I've worked with and in the brat-boy culture and understand your sentiment. That culture also expects late-night work, which dissuades females who society dictates must take point on child rearing. Mainframe shops will have a much more stable work environment with better work-life balance.

Re: Bug? Seriously ?

Hey, Jon!
For anyone reading this, Jon is not only an RPG Programmer, he was a programmer of RPG. He was on the IBM team that worked on the IBM RPG compiler. He and his partner Susan Gantner continue to travel the world training RPG programmers on modern programming techniques. Their RPG and DB2 Summit (www.systemideveloper.com/summit/conferences.html) is always well attended. I doubt that there are any IBM i (AS/400) RPG programmers that do not know Jon Paris.

Thank you for clarifying that Jon. My point was more on the prevalence of 6 character variable names and the use of a 2-4 character prefix. I have heard other IBM i RPG luminanries call that feature a bug [names withheld to protect the guilty] but none of them were on the IBM development team.

Several Colleges are Teaching COBOL by Ed Gould

But you are correct, but no one (AFAIK) teaches RPG. RPG was a disgrace to IBM and should not have ever been written. But there are colleges that still teach COBOL.
One of the reasons why applications are not rewritten is that CPU's have become faster and faster, so there is no incentive to do so.
Or, the operating system has dramatically improved performance. One example, I won't name names as it would embarrass a few companies. Several of us were brought in to a company to upgrade their operating system. At the time it was running an older IBM OS called VS1. One of the reasons why the company needed the upgrade as they were barely making the window they had, which if I recall correctly was 6 AM. If they didn't make that window, several markets would not have been able to open at their normal time, and fines would be levied. Also, the people who made a really poor decision to use ancient technology to do file transfers. The night they choose to convert, mind you there was zero change in source programs. The processing started, and they were finished at 3 AM rather than the 6 AM mandatory deadline. They couldn't believe it, they went back and double checked everything and it was correct. So, just by changing the OS the company saved 3 hours. The next task was to change their communication systems to the then latest SNA. All the companies that we communicated with already had the necessary framework and the conversion was done painlessly (except for a wire in an elevator shaft that was not shielded). The companies we were sending data to every day were happy as our old system was an anachronism, that should never have seen the light of day. We shaved another hour (or more) off the transmission times (total), and there was no manual intervention like mounting tapes, etc., etc..

Mainframe programmers DO unit test

Any mainframe programmer who does not use live data (masked as needed and required by law) to test both production and new-change code and compare ALL of the output files listing all field-level record differences found and verifying that all field-level record differences (or none) are the desired result of the change is just not doing their job. You have to know (and prove) that the change produces difference(s) where you expect it and does NOT produce any changes anywhere else.

This testing requirement has been standard practice in every mainframe shop I have ever worked for 45 years now.

And we do that for ALL client data that is used in production, not just a select few pieces of it.

"Unit testing" isn't new, it just looks new and shiny in the IDE clothing it has now. Those who are ignorant of history are doomed to repeat it.

It takes a bit more time to do this testing properly, but it saves your bacon and your manager's and the VP's and the CxO's bacon as well.

TANSTAAFL

Peter

Thank you for writing this article. All in all it summarizes the decisions C-level execs are facing today. The only issue is is that they are not prepared for reading this long articles, I am afraid.

Re: How do you learn it?

I love the other answers on this topic - literally laughing my @ss off. I took a COBOL course in college and the school had to let people drop the class mid-semester because the compiler they used was no longer available for free on Windows-based platforms. Those of us comfortable with Linux were allowed to stay. Needless to say, COBOL is a primitive language. No modern developer would choose to use it. Frankly, mainframe applications need to be modernized to use modern software practices and frameworks. I'm sure these graybeards disagree; but as someone who took COBOL in school (2008) and works in modern languages (Scala, Node.js, etc.), I'd rather have my nuts crushed in a vice than work with the language on a mainframe.

Re: How do you learn it? by Ed Gould

Richard Clayton said:
"Frankly, mainframe applications need to be modernized to use modern software practices and frameworks"

To which I reply, WHY? The only issue I can see is that people with the skills may not be around. However, at least 20 colleges (maybe more) teach COBOL. You have a pool of fresh programmers every year. And again WHY do you need modern software practices? The idea of changing just to change has little or no merit. If a COBOL program was written to create a report there is no real need for "modern software practices". It is a simple but useful program why does it need to be rewritten just to use "modern software practices" It has a job to do and it does it, IOW there is no need to change it, of course, if you are talking about changing a header on a report why completely rewrite a program when one or two lines of code have to be changed.

The problem with major changes like "modern software practices" become interesting and I think it has to be on a program by program basis, there is no universal answer. Then there comes in a secondary issue of maintainability. I have seen horrendous programs in my 45+ years in IT. Some defy change. I have seen a JOB that literally lasts for a week, It was CPU bound the entire time. and of course produced many many reports and other types of data. It was written in assembler and was multi-tasking as well. I would suggest a job like that could *NEVER* be run on a '86 platform.

I worked at a large book/magazine company that really counted its pennies and yes we had the largest CPU's IBM put out as well as rooms of DISK/TAPE and printers. We got the company more bang for its buck than any '86 type of machine(s) that have ever been produced.
They also treated their people fairly up until the last year when internal politics took hold and the place essentially broke up into different parts (like it was 40 years ago). They also stopped treating their people as family and it was a messy divorce.

Re: How do you learn it?

The only constant in life is "change", and this is no different for mainframes. You guys are literally asking students to learn decades-old languages to support machines that these students are unlikely to have at home to tinker with, with the realistic possibility that this specialty will be extinct in 20-30 years. Or, they can learn FPGA programming and Tensorflow and join the revolution occurring in AI.

I don't have to argue whether mainframe programming is inferior to modern languages and hardware - the point is moot. The stigma alone drives students away from mainframes. So my point is that if companies want to preserve the existing functionality they receive from mainframes, they might want to consider moving those features to newer platforms or accept that they won't have anyone to maintain them in the future.

Re: How do you learn it? by Ed Gould

There are quite a few COBOL programs out there that do very little, move field1 to printlin2, mover field 2 to printlin3 etc etc and may keep totals as well. This is almost as simple as it gets for COBOL. There is no need whatsoever to rewrite programs like this having said that when you get into a fairly easy say payroll system it very well may need rewriting but to rewrite just because will go nowhere with good management. Plus almost all of the time that rewrite will add on additional  for a side product which you will have to purchase as well. The total cost has to be considered as well.
You don't need a super-duper-screw-driver for a simple project. Hell, the super-duper-screwdriver will cost you say $1000 (or more). Why spend the$1000 when an .89 item will fix the problem?
*IF* you can come up with a scenario where you can justify spending \$1000 go for it, but any decent manager will kick you out on your bum.

Re: How do you learn it?

Sure - but that still doesn't resolve the fact that if that application needs to be improved, or if the company changes mainframe platforms, etc. someone's got to be responsible for that code. As the article alludes, there are not many people signing up to work on mainframes. The consequences for not doing a refactor to a newer platform can also be dire. Case in point,
DFAS (Defense Finance and Accounting Service) (US military). They literally are exempt from being audited because their aging mainframe system cannot be maintained:

Wallace, the Army assistant deputy chief of staff, says the system has "seven million lines of Cobol code that hasn't been updated" in more than a dozen years, and significant parts of the code have been "corrupted." The older it gets, the harder it is to maintain. As DFAS itself said: "As time passes, the pool of Cobol expertise dwindles."

Further, the system is nearly impossible to update because the documentation for it - explaining how it was built, what was in it, and how it works - disappeared long ago, according to Kevin McGraw. He retired recently after working 30 years in DFAS's Cleveland office, most of that time responsible for maintaining the part of DJMS that handles Navy pay. "It's hard to make a change to a program if you don't know what's in there," McGraw says.

www.reuters.com/investigates/pentagon/#article/...

I'd argue that in many cases the risk of not migrating the platform could be worse than the financial costs of paying for said migration.

Re: How do you learn it? by Ed Gould

Well, let's see. Driving is a decades-old "job," I wouldn't waste my time waiting for self-driving cars and certainly nothing that has MS on the hood. Last year when the company I worked for put an ad (for COBOL programmers) in the local papers, it got 24 answers. After reviewing the resume's for the 24, there were a solid 15 that seemed to meet our needs. We scheduled interviews with the 15. Out of the 15, we got eight decent people. We did another round of the eight by different people. We needed five, so then the group(s) that did the interviews talked it over, and they agreed that all eight were worthy, we hired 5 and sent a letter saying that if we need more people, we would call on them.
Every one of the 5 worked out well, 5 of them got decent raises after the first six months. The age ranges were from 24 to 40. The people are out there if you want them.

Richard said: I don't have to argue whether mainframe programming is inferior to modern languages and hardware - the point is moot.

Yes, you do need to argue that point. Yes, there are languages that can't run on the MF, but on the other hand, we have languages that can't run on PCs.
The current hot trend is JAVA, yes we can do JAVA, can we do C yes we can do C. Can we do any of the MS "stuff" I don't know if you can properly call them languages as such. You are comparing apples to oranges there is a right language for each platform. COBOL is good for the MF and whatever language you want to use you can do it on the PC.
The right language is whatever it is the platform you are using.
I will in no way ever say RPG was a good language, in my mind, it is not a language it is more of a report generator. Having said that it should have been killed off years ago as the platform(s), it was used on have essentially died. BTW I have not ever heard of RPG for Zos, but if it does exist, I hope it finds an empty bit bucket in the cloud somewhere.
As for which language you choose it should be what is available on the platform, you are coding for, that is a business decision. If you think most (all) is on the PC platform, then write for that. If it is for the MF, there are at least 3++ languages you can choose from. All have good and bad points to each, it is *you* the business manager that has to make and live with that decision.

Bilbo

The blockchain is the one that is going to kill the mainframe actually.

Re: How do you learn it?

You're killing me, Ed! Would you really recommend driving trucks as an occupation of the future to your kids? I feel like we could argue this point ad nauseam, but frankly, I think the numbers are on my side. What "mainframe people" forget is that there is a surplus of jobs in non-mainframe IT/software development. So while there may be a bunch of mainframe jobs, there's no real incentive for new engineers to learn mainframes; it's actually the opposite - they risk having their skillsets become irrelevant.

More importantly, you have to consider the cost-benefit analysis of purchasing/developing on mainframes vs. using commodity hardware and open source distributed frameworks like Spark and Hadoop. Frankly, I think the numbers have already answered that question for us. On top of that, consider the fact that the next 20-30 years of software will be dominated by AI/Machine Learning. I don't see anyone porting Tensorflow over to mainframes.

Re: How do you learn it? by Ed Gould

Recommend, no. But that is what you are advocating here. One size does not fit all. A programmer has multiple paths to a career. Small is good for some applications; big is good for other. *IF* all you want to do is number crunch, then *maybe* an array of 32K PC's is the right way to go. I will warn you though that the array is all it's good for. For general computing, I suggest that an MF is a solid answer. IOW if you want to play poker or other game, a PC is a good option. For work that has a lot of data and needs a fair amount of power and is easily understood by many, an MF is a way to go. For home use perhaps a PC is the way to go. As far as the future, it looks like the '86 is limited and will need a giant rethink when the next gen comes along. I am not a prognosticator, and I could be wrong. Look, there are programs running every day on the MF that haven't been touched in 30 years. No, it's not a large program but does simple things. Can the same thing be said of the PC world, I would suggest NOT. Practically everytime a new WIindows version comes out it obsoletes 90+ percent of the programs and they have to:
a. rewrite from scratch
b. Use some new function that doesn't have anything to do with the original function and makes the program twice as hard to debug as before.
c: Write an emulator that will run the program as it ran before the needlessly complicated new OS.
On the MF you only need to rewrite programs (generally) that need to use a new function, that is not the case on the PC.
Over the years I have been exposed to emulators on the MF. They are more of a pain, and they are gotten rid of ASAP.
Take a program written in DOS (Disk Operating System) (precursor to MVS); the conversion was
a. easy,
b. difficult. They were easy unless they were depended on an OS dependent feature.
The new Windows programs are almost always tied to some new feature in the OS and are a bear to convert.
The hallmark of IBM is that in 90++ percent of the cases no compile is needed for any new release of the OS. The 10 or so percent are using some function that needed to be rethought and implemented some other way. I am talking releases of the OS not CICS or IMS. Those two are pretty unique and have to be considered the exception to the rule.
The programmer of the future will always be challenged as to which OS to write for, as I said before there is a good platform for each type of program.
BTW: *Never* trust a WINDOWS based Driverless car.

Thank you

Very nice article. Thank you for writing this. I've worked with one of these expiring mainframers before and I think it's very sad.

Typo

There appears to be a typo in the Key Takeaway section:
Mainframe programmers have be treated like bus drivers whose only job is to consistently move huge amounts of data.
should be
Mainframe programmers have been treated like bus drivers whose only job is to consistently move huge amounts of data.

You try something that you have a gut feel will work and you light incense, sprinkle holy water, and pray to a variety of gods that your change will work. by Max Max

That was I was doing when I wrote RPG programs. H**C use tons of RPG program to support back end processes. I have fed up with their default green screen

Re: Here's where you can find modern tools for the working with the Mainfra by Ed Gould

Just remember, that Compuware software is on the expensive side. We were told to drop all COMPUWARE products (saving 100's of thousands of dollars) after our CIO saw their ad on a Superbowl program and was mad as the company I was working for were paying high prices to have COMPUWARE put ads on TV.
There are cheaper replacements out that (even free) on the flip side Compuware offers good support, the others not so much.

Re: Mainframe programmers DO unit test

And you are delivering the best example why the mainframe community is in such a problem because what you describe is no unit testing at all.

You throw around words you don't really understand and think that it means the same thing you have done for years or decades and it is just a new word from the youngsters. But you are totally wrong. Look it up and start learning again.

Re: How do you learn it?

Read what you wrote back to yourself. What are you trying to accomplish with such an arrogant and unprofessional tone? Are we all supposed to be convinced into pouring hundreds of millions in to replacing mainframes because nodejs is now here?

I wont make assumptions but I suspect you work nowhere near mainframes. As someone who integrates these with modern "big data" warehouses I can guarantee you many of these mainframes arent going anywhere. They are often housed by federal government or direct contractors or large organizations tied to legacy protocols such as 3270 DDE or EDI which pertain to industry standard formats. Do you understand the inertia and complexity here? These machines are often housed in a place with armed guards sitting out front 24/7. These mainframe owners would rather pour massive amounts of money into keeping these legacy systems quietly running than face the risk of interrupting continuity. Imagine the work effort of switching well-entrenched immensely complex systems getting the job done just to update for more programmer convenient mechanisms. Pointless. Several times I've seen well-intentioned java devs try and fail to replace them. For this same reason cobol programmers can esaily pull 250K/year or more because of their valuable knowledge of the inner workings.

There will always be a better tool. 30 years from now someone will be mocking the languages/frameworks you consider to be modern today saying they want their balls in a vice grip etc but the wiser view is just to view it at a higher level as just another system with strengths and weaknesses.

Re: How do you learn it?

Peter, I was trying to be funny, particularly to show the general attitude younger generations have towards mainframe development.

However, you clearly have lost the point. "Mainframers" are losing the battle in recruiting new developers. If everything was going well, you wouldn't have articles like the one we addressing today.

"There will always be a better tool." I can't agree more. The problem, I suspect, is that there is so much inertia to change with mainframe systems, that you've never had to rearchitect large portions of your system on a regular basis. This is why you are so uncomfortable with the idea. A lot of us have had to learn the hard way about the necessity of changing with the technological landscape (I will point you to "Sacrificial Architecture" by Martin Fowler - martinfowler.com/bliki/SacrificialArchitecture....).

"They are often housed by federal government or direct contractors or large organizations tied to legacy protocols such as 3270 DDE or EDI which pertain to industry standard formats. Do you understand the inertia and complexity here? These machines are often housed in a place with armed guards sitting out front 24/7"

I was in the USMC and worked as a Defense Contractor for 4 years. Yes, I know the complexity. I also know that aging systems like DFAS are causing insane amounts of pain and anguish because they are never migrated or improved.

Stop being so thin-skinned. Your generation is attempting to pitch the idea that my generation should give up on Single Page Applications, Distributed Computing, Deep Learning, etc. because there are tons of legacy systems that need people to maintain them. I'm trying to tell you that you're not convincing us.

Re: How do you learn it?

Re: Bug? Seriously ?

I remember when I began coding RPG the nasty surprises I got due this feature. An innocent chain to some new file and suddenly you had new values everywhere. You really have to be very careful about it. Luckily newer RPG ILE added de PREFIX keyword greatly reducing the risk of messing up a program when you add a new file. When dealing with some old RPG program you become a sort of surgeon. Delicate stuff. I liked the article very much, felt reflected in many ways.

Refactoring, modernisation and Quarterly ROI

Great article Don.

Agreement on most but not all. Refactoring code into API's is applicable in some instances, but in practice is impractical from an ROI perspective. That's why it doesn't show in quarterly results.

A consumer driven mobile/web app Resource(the fundamental building block of modern apps and development) rarely corresponds to a piece of code in any form that already exists on a legacy system. I spent the better part of 20 years digging for them on thousands of systems. I gave up. But building new REST API's over globally critical databases(MainFrame and MidRange) that meet the current or new Resource requirements for quarterly business, does show in quarterly results. Refactoring existing code to be called by, or used in those new RPG REST API's is a long term potential deliverable, but can also be hooked up in smaller chunks to quarterly deliverables.

Training youngsters with short attention spans to write pure REST API's in RPG (not wrappered, JDBC DB calls or stored procedures) on IBMi or COBOL on MF is a good short and long term investment. Thats because of the data on these platforms you mention AND that it gets mention in the quarterly results, but also because REST and Resource development is driven by an Agile (short term/simplified) philosophy, just like the youngsters. Its not a coincidence.

The MF and MR do have a future but not if one clings to the legacy code. Start new and pick out the goodies(using the methods you talk about) as you need them. A last gem that will set tongues wagging: For most cases from a business point of view - DB Modernisation IBMi is almost irrelevant, certainly this quarter.
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

34 Discuss

Login to InfoQ to interact with what matters most to you.