Preserving Valuable IT and Mainframe Practices

1/7/2019 9:25:55 AM | By Reg Harbeck

A legacy is something of value passed down from previous generations. We have a lot of that on the mainframe—sometimes more than we need.

But we do have a lot that’s worth preserving, understanding and building on, even if these things are well hidden, or poorly documented: business and technical practices, cultural attitudes, tricks and techniques, in-house utilities, local configurations, documented processes and procedures, and local history.

Business and Technical Practices 

There are outstanding examples of professionalism in the world of mainframe computing. They entail a culture of scrupulous responsibility that helps make the mainframe great. If you were mentored and trained into the world of mainframe at the beginning of your career, you were inheriting some of that. If you’ve been in a mainframe career for over a decade, then chances are you’ve not only immersed yourself in such practices, you’ve probably even adapted or developed some of your own, which you employ so habitually you may have even forgotten you’re doing things a better way than you did the first time you tried.

Since computing is not yet a profession, there’s no body of knowledge and practices that is standard across the board, so all of these good habits are not only substantially invisible, but they could be lost if not deliberately documented and passed along.

Cultural Attitudes 

If good habits qualify as invisible, attitudes are often even more hidden. When those are destructive attitudes, it can be a good thing if they leave with those who hold them. However, there are also attitudes that count as hidden treasures, and while they are often founded in character and integrity, the ones of particular relevance here pertain to the mainframe environment.

Memories of positive and negative experiences are often key in the refining of these attitudes, and those experiences are increasingly rare—particularly as we apply them to avoiding the negative and encouraging the positive. And saying, “I told you so!” to a new colleague who’s just learning the ropes doesn’t always have desirable effects if we didn’t successfully pass those attitudes along before they were immediately relevant.

Tricks and Techniques 

“Have you tried typing this?” or, “I find putting it in its own library saves grief,” or, “I usually wait until after midnight to begin testing changes to this system.” These are too fiddly, specific and concrete to count as practices or attitudes, but they are survival behaviors that can save hours or days doing it the hard way.

Watch newbies get their hard knocks as they learn the ropes may be fun, but when you have to compress decades of that kind of knowledge into getting an apprentice spun up during the few months of overlap before their mentor retires, such a pummelling of hard knocks could do some lasting harm.

In-House Utilities (subhead)

I love having a PDS for my personal REXX utilities and ISPF EDIT macros. While they’re probably similar to what other experienced people have, they each are specific to my personal style. And unlike gems that are more generally available, if not as widely known, such as ISRDDN or the contents of the CBT Tape, these personal utilities tend to have been put together by each individual who wants to use them.

It’s common for people to share these programs with their colleagues so they can copy and modify them for their own purposes, and sometimes even document and put them in shared libraries.

Unfortunately, it’s also common to forget about them until they’re needed, and then remember and search for them when the opportunity arises.

Five years after you’ve retired, when everyone decides it may finally be safe to delete your personal datasets, anything that wasn’t salvaged will be lost. If people don’t know how to use it, it’s as good as gone.

Local Configurations 

There’s a word for out-of-date configuration settings that have been superseded by new options and are no longer supported: deprecated. Such functions often only get replaced by new functionality when the product stops supporting the old settings or is replaced by a competing vendor’s products resulting in reversion to supported configuration values.

But some settings never get deprecated. That can be a good thing, especially if the people who originally installed, configured and trouble-shot the product figured out that a particular setting would save a lot of grief in your environment.

Today, you take them for granted without even realizing that the values are different from the default settings, let alone why. But if the day comes that you (or your successor) have to upgrade or replace the product, you may find that things don’t quite work as well as you expected because the new default settings make it behave differently.

Documented Processes and Procedures 

I love automation, and find few things as rewarding as writing a REXX automation procedure (thanks, Mike Cowlishaw). I’ll never forget the wonderful feeling I had after the first time I automated an IPL and reduced the total time from start to finish by more than two orders of magnitude. Of course, drawing on well-written, up-to-date operator procedures made a big difference in my success.

 

Did my documentation in my REXX EXECs reflect what they were doing as accurately as those procedures? Maybe. Did it also explicitly describe the tribal knowledge the operators brought to properly following those procedures? I hope so. Did it get correctly updated every time a change was made to the REXX EXECs by my successors? What do you think?

Whether automated or manual, this documentation is a description of how your organization functions, and the more accurate and complete it is, the more readily you can move forward as new cohorts arrive on the mainframe.

Local History 

Even if your naming standards and your configuration and tuning values are documented and consistent, there will still be many ways that people’s personalities can surreptitiously become the unspoken rationale for how your environment is set up and run.

Of course, if you don’t know why you don’t do something, it can be an intimidating prospect to be at the receiving end of a “we don’t do that here” correction.

When responding to an urgent need, knowing why things have a particular character can save a lot of grief—both technical and cultural.

How to Find and Keep These Legacies

Ask! I know: This is one of the hardest things to do when dealing with a very busy mainframer, especially if they haven’t been assigned to mentor you.

On the other hand, if you’re in charge of some newbies and you want to have some fun without sending them out to look for sky hooks or snipes, this can be a great way to build your mainframe and IT culture forward, even if it may occasionally require conflict resolution skills.

The truth is out there, and there’s no better time to start asking and documenting the answers than the present. It’s a present you won’t regret giving to the future of your organization.