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

LongEx Mainframe Quarterly - February 2014

At a customer site a while ago, I used an internal tool to analyse a couple of their load module libraries. And the customer was surprised at the results. I found some OS/VS COBOL and COBOL/MVS modules, a few COBOL modules with poor compile options costing CPU, and some modules compiled but not bound as re-entrant. I even found some very old FORTRAN modules they didn't know they had. Not the first time I've surprised a client like this.

Managing load modules is a thankless task. No-one will applaud you for doing it, and the only things you will find are problems, and hard ones at that. So most of the sites I've seen do it rarely, if at all. But here's where the engineer in me comes out. I hate having uncontrolled load libraries. I don't like old modules, modules that are unused, or modules that have no corresponding source. I really don't like where there are a few different copies of the same load module in different libraries (often concatenated together), but the reason why has been lost in time. I hate old software product modules in application load libraries. And I really detest those load modules that no-one knows about: no source, no idea what it does, and no clue as to whether it is used or not. Double the importance for APF authorised libraries.

But am I just making work? These sites are running comfortably with few problems, and the modules I find aren't hurting anything for the time being. So why not just let them be?

As a systems programmer, I'm only too aware of the potential for problems. And some of the possibilities are downright scary. So rather than take a passive approach and let the problems come to me, I prefer to hunt down any potential problems, and fix them then and there. Result: smooth running system and a lot less stress. This also sits well with security audit and compliance.

So this means that I always recommend that sites take a strong hand to each and every production load module. Ideally, this would mean:

• Regularly running a load module analysis tool such as Edge Portfolio Analyzer or IBM Debug Tool LMA through every library to look for issues. These products are sensational: reporting on dates compiled, compilers used, and even compiler options specified. Regular maintenance will not only help you control your modules, but will probably pay off with code that is more efficient. I've seen many sites where poor COBOL compile options costs CPU
• Strongly securing production load libraries, and using source code control for every module and its corresponding source. So every production load module is only created via source code control, and has corresponding source. Sounds trivial, but I've seen one site that only recently started using source control software for their applications. Goodness knows how they controlled their programs before
• Using software such as IBM TADz or UBS Hainer P-Tracker to continuously (or regularly) track load module usage. If a load module is no longer used, lose it
• Eliminating duplicate modules in different libraries. Every module should have a unique name in a system, and ideally across all systems
• And finally, one that many may disagree with particularly because of the work involved. I believe that no module should be more than 10 years old. If it is, it should be recompiled and re-tested. This does a couple of things:
  • Make it run faster. Improvements in compiler and mainframe technology will undoubtedly result in a faster program using less CPU - helping to cost-justify the effort
  • Ensure that the source code will still compile (not relying on missing modules or copybooks, or out-of-date compiler features or options)
  • Ensure that the source code still works and is relevant.
  I've arbitrarily used a 10 year line in the sand, but you get the point.

So let's list the advantages of my recommendations:

• Source code is accurate, and can be re-compiled whenever needed. And you know it
• No load modules that cannot be recreated or modified
• Load modules are more efficient, using less CPU
• No problems mixing up duplicate modules, or using old or obsolete modules
• No old program products hidden in production libraries, potentially running without licensing or support
• Minimise the number of load modules to manage

Year 2000 and OS/VS COBOL removal projects have already put sites on the right path and removed some of the load module problems lurking. Finishing the job will, in my opinion, more than pay for the costs.

David Stephens