Blog

The retiring mainframe work force issue has proven to be a slow erosion over time rather than some type of drastic drop off. No matter where your company sits in that continuum, here are three simple steps you can take to help reduce the impact moving forward:

1. Get Current

“When is the best time to buy a Kirby vacuum cleaner? When the Kirby vacuum cleaner salesman is here!” That was the last ditch effort sales line of a door-to-door salesman to my Mom when I was eight, and it stuck with me to this day. The demographics of mainframe systems programmers is the same as that of application programmers; sure they may be grumpy but they won’t be here forever. Take this time to get as current as you dare with your operating systems and subsystems. As likely as not your company runs one level, two levels or even three levels back.  And if you’re not careful, your company could drift into unsupported territory without the safety net of experienced, proficient systems programming.

2. Exploit your ISVs

Anyone who has spent time as a starving college student knows the value of loose change in the sofa cushions. Your third party software providers have likely been adding features release after release to specifically assist with the retiring work force. If not – demand that they do! However, a product feature is only as useful as the use you get out it. If you continue to run the product the way you did the day you purchased it, then it doesn’t matter how many new features the ISV provider provides. I see this first hand in my work with Abend-AID. The single most powerful feature of the product (to correlate dump information with COBOL source) is consistently under-utilized. Long-time mainframe developers could stumble ahead without that feature, but next-generation mainframe developers should demand it. It’s there, it’s free and it’s waiting for you. Go ahead and use it! So check the release notes of your ISV products; there is some valuable loose change lurking there.

3. Processes are your friend.

Why do schools practice fire drills? So if a fire should ever occur the muscle memory of process takes over. Take this time, while your mainframe knowledge base is still mostly intact, to tighten up your processes. How do you decide what programming changes to make? How do those changes make it from development to production? How do bugs get fixed? A close examination of these processes may expose internal short cuts that have evolved over the years to become a standard right of way. And shortcuts only work when everyone knows where the potholes are. Tightening those processes today will pay dividends tomorrow as less experienced people begin to assume positions of authority.

Now are these the do-all and end-all to ensure a safe transition? Hardly. But they are the very low hanging fruit to kick off your mainframe transition strategy. Truthfully, these are three best practices that would be beneficial above and beyond any retiring workforce issue.