After much deliberation, agonising over strategy, considering the views from diametrically opposed technicians, you have finally decided to proceed with a Legacy Modernisation project. Your business case makes it a no-brainer. Millions saved in licensing costs in year one alone.
Your old COBOL applications, a mixture of time-consuming batch and archaic CICS screens, will be rehosted onto a distributed platform. You might decide to use the hugely successful Microfocus Enterprise suite of software, or you may use any one of a number of migration partners. You may even decide that you don’t like COBOL any more, and that you are going to convert the lot into Java, C# or who knows what else.
Most of these are well trodden paths, with varying degrees of success. I would always recommend baby steps to achieve your goal; the more complex the migration is, the more likely it is to fail without proper planning and an achievable migration strategy.
However, your enthusiasm can soon be tempered by something lurking in the shadows. It has not been touched for more than ten years, but it is the glue that holds your applications together. No one understands it any more, and if it ever stopped working you have no idea what you would do. Fortunately, it is stable and has remained so since Bob retired a decade ago.
Most mainframe estates will have some. A few, even today, actively develop business applications in it, but it primarily hides out of sight of developers, analysts and anyone else who casts an eye over the application landscape. It is, of course, Assembler. That language which is today unfathomable to all but the dedicated advocates.
“It’s only code,” I hear you cry, but if you study the application code, and refer each instruction back to the IBM manual, without expert assistance from someone who has lived and breathed Assembler for a number of years, you will be none the wiser as to what it is actually doing. Assembler programmers, more than any other breed, delight in exercising every instruction imaginable “just because they can”.
Often, the language itself can impose restrictions that introduce complexity. My particular favourite is the paired register usage of the MVCL instruction (replaced, in most cases, by a simple COBOL MOVE statement). In the search for simplicity I have never seen the need to code a BXLE instruction, though I have encountered quite a few! Throw in a few macros, the lack of any listings, and you really are staring into the guts of the machine without the surgical knowledge of how to extract this troublesome organ.
However, help is at hand. Legacy IT Consultants Limited appreciate that you are not likely to need an Assembler developer in the near future, but you may need Assembler expertise. We have more years than we care to remember dealing with Assembler and its associated complexities. We have written pseudo-code to enable it to be rewritten in COBOL (or more modern languages), and we have been involved in a number of Assembler conversions. Whether it is just a few isolated but vital utilities, or a whole application built around Assembler, help is at hand. For more information email enquiries@legacyit.co.uk.
