Jun 17 ’12
IBM mainframe Assembler feels like bare metal COBOL, with all the business data intensity that made the mainframe great, but none of the training wheels that can keep you from getting excessively creative in COBOL.
A review of some of the local customized Assembler programs in use at mainframe shops today would lead you to conclude that the history of the mainframe is rife with creative geniuses, capable of fitting a megabyte's worth of functionality into less than a kilobyte. However, that assumes you could figure out what it does and how—a task rarely facilitated by much, if any, documentation. And that's a problem.
Often, these programs were written when there wasn’t enough storage, CPU capacity, or available functionality to enable a needed outcome. So, they were written to solve apparently unsolvable problems—and did it so well they became part of the fabric of mainframe environments.
Every so often, it became necessary to update these programs or build something on top of them to modify how they worked. This was a minor annoyance as long as the original author was still around. However, it became a major headache when some other brave soul had to figure out how to add one more block without toppling the whole stack. That's a problem, too.
Meanwhile, the mainframe grew up, got faster, incorporated more memory, and added more built-in functionality. Mainframe applications and utilities came with functionality that could overlap with and exceed what homemade Assembler programs did. But everyone who cared was too busy updating the Assembler programs to replace them with out-of-the-box features in software they already were paying for. That's also a problem.
As you may have noticed by now, we're clearly in problem state, and could perhaps benefit from some work in supervisor state. Here’s a list of problems that come with Assembler programs:
• They're hard to understand if you didn't write them (and sometimes even if you did).
• They can be hard to maintain, even if you have appropriate skills and understand what they do and how they do it.
• They're impossible to maintain if you don’t have the skills.
• Generations of patched-on tweaks, features, and data size increases can eventually cause them to unexpectedly implode.
• The most experienced people who are really good at Assembler aren’t going to be around forever.
• Upgrading to a new release of the operating system sometimes means that some Assembler exits need updating or testing.
• Code must be stored and managed, but since Assembler code is often systems code and exits rather than application code, the source can be scattered all over the place, and can be challenging to locate, especially when there are multiple versions in different places.
• It's hard to audit Assembler programs and consequently much too easy for them to contain security exposures.
• It takes time and effort to maintain them when they're often no longer needed or easily replaceable with out-of-the box functionality.
There's much to be said for getting rid of unnecessary Assembler programs. But how?
Assign enthusiastic new mainframers the tasks of:
• Identifying Assembler programs that are obsolete because what they do can be handled by the operating system or packaged software, or omitted
• Migrating to the new features as appropriate
• Retiring the old Assembler programs.
This is a great way to help your new mainframers become familiar with the mainframe and with your specific context, and even improve their Assembler skills. Here’s an approach to consider:
1. Identify all the experienced Assembler programmers in your shop.
2. Assign one or more new mainframers the task of working with your experienced programmers to create a list of all in-house Assembler programs in use, where the source is kept, where the load modules are, how they’re used, by whom, and what business benefits they provide.
3. Next, have the new mainframers put together a list of all mainframe features and packaged software that might offer some or all the functionalities and business benefits of these in-house Assembler programs.
4. Meet with your experienced Assembler programmers and new mainframers and prioritize which Assembler programs should be removed or replaced.
Now your new mainframers get a first-hand learning experience of all the business practices that keep a mainframe environment functional, from creating test versions of the alternative configurations, to testing them, to change control, and production. Initially, it may be optimal to do this for one program at a time to discover the local “gotchas” in your environment.
If these steps seem onerous given the workload your staff already faces, hiring an experienced mainframe consultant to act as a facilitator can help.
Benefits of this approach include:
• Less obscure, obsolete, and challenging Assembler software to maintain
• Leveraging current out-of-the-box functionality that requires little or no regular attention
• A great learning experience for your new mainframers, plus a chance for them to get to know your experienced people and establish mentoring relationships.
That’s not a bad return for eliminating extraneous Assembler. Of course, you could also spruce up your CLISTS and REXX execs, too, and maybe even programs and exits in other languages. After you’ve dealt with the Assembler programs, there are several ways you can renew your mainframe to ensure maximum value as a new generation inherits it. But that's another article.
Acknowledgement: Special thanks to my colleague Kikis Orphanos for providing excellent input for this article.