Millions of lines of code, thousands of programs and hundreds of tables and files—this is a typical legacy mainframe application environment. The rewards of modernizing these complex applications are well understood, so why does it take so long to reap the rewards? Legacy application knowledge transfer is the reason.
Legacy application knowledge transfer, or lack of it, has a significant impact on the man-hours devoted to analyzing, coding, testing and implementing new modernization functionality. One assumes that mainframe application knowledge can easily be transferred from the development and support team to the modernization team. This assumption is wrong because no one understands how their mainframe applications really work—not even those who develop, maintain and support the application.
Key issues include:
• Application knowledge erosion: Time is the problem. Ask any programmer to describe the code logic they used to create a COBOL subroutine a month ago, six months ago or years ago. Application knowledge erodes over time.
• Limited application specifications and documentation: Theory is one thing, practice is another. Specifications and documentation, if available, may not contain the application knowledge needed to support the modernization effort.
• Shrinking mainframe skills: This is a well-known problem, with no easy remedy. The application knowledge void left behind by retiring baby boomers is very difficult to fill for remaining staff, let alone newcomers. Newcomers are being prepared as a result of the IBM Academic Initiative program, but more is needed.
The Right Code
The analyst needs to understand, then modify or enhance, the right code in order to facilitate knowledge transfer and application modernization. But first, the analyst needs to understand how the application really works in order to find the right code. The traditional approaches all involve looking at static source code and playing computer. All are time-consuming and error-prone, yet form the historical foundation of application analysis, such as:
• Examining source code
• Source code analysis tools
• Relational database repositories of source code
• Source code debugging tools
The Thread of Application Processing
Analysts who look at static source code and simulate application execution are attempting to identify the conditional logic path of the application as it executes. This logic path contains input/output screens, programs called, call statements issued, tables/files accessed (i.e., Creates, Reads, Updates and Deletes to Tables) and conditional logic followed. Only in this execution-based subset of overall application code will the right code be found.
The application analysis effort related to discovering the cause of a payment posting error in an accounts receivable application is not nearly as complex as embarking upon an application modernization project. The application landscape related to this analysis effort, however, illustrates how challenging it is to find the thread of application processing, let alone the right code. A fictional application landscape related to our payment posting problem illustrates the point. In it:
• Overall Application Code: 75 COBOL programs comprising 470,000 lines of code.
• Total Tables: 150 DB2 tables.
• Payment Posting Code: 200 lines of COBOL code contained in 15 programs and touching 20 DB2 tables. This subset of overall application code contains the thread of application processing code which was executed. This is where the right code will be found. How do we find it?
A New Approach is Needed
An execution-based approach is needed—one that captures the thread of application processing followed by business transactions of interest. Application knowledge acquired and transferred as a result of this approach will provide the key to successful mainframe application modernization projects.
Bob Buchanan is vice president for marketing and sales with PathPoint Software.