Three quick steps to prepare for the mainframe retiring work force
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.
Image attribution: stevendepolo
Latest posts by James Liebert (see all)
- Failure Ain’t Nothing but a Learning Thing: An Agile Perspective - December 5, 2017
- DevOps and the Mainframe: The Ultimate Win-win - August 29, 2017
- How Do You Define DevOps? Six Interpretations to Help - June 29, 2017