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.

2 Pages