What is a legacy system? A simple definition would be "an application that is currently active in a production environment". Legacy systems typically comprise on-line and batch components, access many application or system databases, have complex rules regarding how, when and where programs should be run and are generally written in a combination of 2nd, 3rd and 4th generation languages. It is quite usual, for example, to find systems that are over 30 years old still being actively maintained and enhanced with this week's hot application generation methodology.
While it may seem blindingly obvious that holding a central store of accurate information about a legacy system is desirable, even essential, it is an unfortunate fact of life that many computer installations rely on SMEs--subject matter experts--application folk lore and the fervent hope that nothing will go wrong (especially on my shift!). There are a number of reasons why this lamentable state of affairs occurs, but perhaps the main reason is the lack of an accurate and automatic way of documenting diverse systems elements into a homogeneous format that is easy to access and use.
The bottom line is that a typical software portfolio comprises many components, written over a long period of time with differing standards and with indifferent documentation. The major problem for sites trying to understand such complex portfolios is the sheer volume of different programming languages, databases, TP monitors, Job Schedulers, naming standards and the like that need to be supported; and that is where the issues begin.
The only way of extracting meaningful information from existing systems is by parsing the application objects. There are basically two ways of building code parsers:
The major problem with the first approach is that it is necessary you have to re-invent the compiler for each language, database or TP monitor. There are many disadvantages to this approach, most of which revolve around the need to take account of different versions of the compiler and the need to document everything found in the source code. The approach is slow, error prone and unwieldy. If preprocessors are used, (such as for DB2 or CICS), a further program has to be written to take account of the code within the EXEC-SQL and EXEC-CICS code. If a company has their own pre-compilers, further code has to be written, and so forth.
With the second approach, rules can be added quickly to take account of local conditions. Adding rules to a table is quicker than writing code: Legacy Software's SQL parser was written, tested and implemented in under two days, and is easy to modify to accommodate changes to the SQL standard.
The legacy Directory parsing technology has been built from the ground up with two key principles in mind; Speed and flexibility. Speed is needed due to the immense volumes of metadata currently found in large IT installations. Legacy is fast: a few years ago, on a heavily loaded z/OS test machine, The Legacy Directory parsed and processed 500,000 lines of code in under four minutes elapsed. Flexibility is required because of almost limitless number of different application components that are found in mature shops.
With its 100 pre-built rules tables covering 2nd, 3rd and 4th generation languages, current and obsolete langauges (including BAL, COBOL, PL/1, IDEAL, MANTIS, NATURAL, EASYTRIEVE), databases, (such as IMS, DB2/SQL, Datacom, Adabas, IDMS, SUPRA), systems components, (for example, JCL, CICS CSD,) and the ability to generate bespoke solutions quickly on-site, The Legacy Directory is the complete solution to systems understanding and documentation.
For more information on The legacy Directory, contact us today