longpelaexpertise.com.au/ezine/LostSource.php?ezinemode=printfriend

LongEx Mainframe Quarterly - August 2012

Most mainframe managers will wake up in a cold sweat from nightmares of losing their source code. In some cases, they already have. So what can you do when you don't have source code for your modules?

Most mainframe sites, or in fact any site developing software, spends a lot of time and money on source code control. They control who can update source code, and keep several different versions to see what was changed and when.

They will have cast iron rules so that only programs managed by the source control system can be compiled and used. These systems are designed to enable sites to match a module with its source code with confidence. But like everything, these systems can fail.

You may have an obscure assembler routine that was developed years ago, or some source control information was lost. Or you may not be sure which source version was used to create a source module. Whatever the reason, you have a problem. You have a load module without source. You cannot change it, fix problems, or make it more efficient. You cannot modify it to work with newer applications, and you may not even know what exactly it does. So what can you do?

Option 1: Do nothing

The most common option is simple – do nothing. And this isn't a bad solution.

One of the strengths of the System z platform is backwards compatibility. The odds are that your orphan module will continue to do its job for many years to come. So it's easy to ignore the problem, and deal with it when it becomes an issue.

Most problems will come from some sort of change. An upgrade of z/OS or other system software would be the odds–on favourite. A change in some other application or system wouldn't be too far behind. So if there is a problem, you can backout the change, and then deal with the problem. Of course Murphy's Law would argue that when the problem does occur, it will be when the change is critical, and has to happen immediately.

Leaving the problem may well be the best solution for simple routines that don't use too many external modules or services. For example, that assembler routine created by the genius who left ten years ago, taking the source with him. COBOL modules may be more of a problem. Your old OS/VS modules are now getting more difficult to use, particularly within CICS. And there have been other changes or modifications to COBOL and runtime libraries that add risk to using that old module.

Of course, all this assumes that when the orphan module fails, you'll see it. Hopefully, something obvious will happen such as an abend or error message. But what if the problem is more sinister? For example, a date routine that starts to output incorrect dates?. Or a hash table that outputs invalid values?

Another issue could be performance. There is a good chance that your old module is costing you CPU seconds. Or minutes, or even hours. I've seen one example of a discontinued product costing the customer tens of thousands of dollars every year. Such high costs can make fixing the problem a cost–effective option.

So, if you can't ignore the problem, what options do you have?

Option 2: Write a Wrapper

If your module stops working, it may be possible to write a wrapper routine as a middle man. For example, a wrapper routine could be called from XPLINK, LE or Java routines, convert parameters to something the legacy module can handle, then call that module. Similarly output from the old module can be translated back to something more palatable to your more modern routines. This approach can also increase the life of an orphan module, or buy you time while you look at the real problem. In many cases, writing such a routine may be a lot quicker and easier than replacing or fixing the original module.

Option 3: Replace the Module

If you're lucky enough to know what goes in, and what comes out of the module, then the answer is simple. Rewrite the routine.

The problem here is that it is never as simple as this. I've seen one example where an old module occasionally output incorrect values. Over the years, callers of the module changed their processing to handle these incorrect values. So any replacement module needed to replicate these incorrect values.

This also becomes a problem if the routine does some magic, and no–one can figure out how it does it. Mystical assembler routines written by geniuses that have long since moved on are a classic case. For these gremlins, you need someone equally smart to figure out what needs to be done, and do it. Insert marketing for Longpela Expertise here.

Option 4: Reverse Engineer

Wouldn't it be nice if you could take a load module, run it through a utility, and get the source code? Well, this is possible in a very small number of cases where the source code is stored with the module. Compiled REXX sometimes falls into this category. However for almost all of your modules, this is difficult. Difficult, but not impossible.

There are several disassemblers available that will take a load module, and return corresponding assembler code. Assembler coders can then take this code and run with it. Another Longpela Expertise marketing opportunity. We look more at some of these disassemblers in this issue's technical article.

However the chances are that code in the original language is required, which almost always means PL/1 or COBOL. Creating such code from the output of a disassembler utility is very difficult. But again, not impossible. The Source Recovery Company based in Georgia, USA advertises such a service. Send the module, get COBOL back. The code won't be perfect, and copybooks and coding standards won't make it. However it can give something to work with.

Such disassembly is in effect reverse engineering. This is fine for the code that you have developed. However using this option for a current or past software product may violate copyright or contract clauses.

Option 5: Stop Calling the Module

The other option is to simply stop using the module. There may be several ways to do this, including using other services to achieve the result, or living without the functionality that the module provided. In fact, there are probably more options that you think. Existing software products may do something similar, or there may be new language functions or features that will work. If you're very lucky, there may even be some freeware or new z/OS facility that neatly slots in.

Conclusion

If you've lost the source code, all is not lost. There are options, and it may be far easier and cheaper than it appears. However any such project should not be taken lightly. It will generally need highly skilled and experience people to analyse the problem, determine the options, and then implement the solution.

Even discussing this problem highlights the need and importance of good source code management. If you don't have it, get it.

David Stephens