LMR Load Module Repository

built on your existing load module libraries

"The truth only exists in the code that goes into production every night"

Analysis of Load Module Libraries
with Edge Portfolio Analyzer EPA
(more details see below)

Effective management requires a big picture view of the portfolio. The concerns at this level are with the entire portfolio

• Enterprise Management Perspective

• Application Portfolio Management

• Program Management

Enterprise Management Perspective

Managers can plan the most effective way to migrate to a new technology or implement a set of standards

• How many programs are there ?

• What languages and technologies are employed ?

• Are appropriate quality standards being met ?

• How fast is migration to a new technology
   taking place ?

Application Portfolio Management

Portfolio management looks at a single application or possibly a family of programs

• What programs will be affected by a change to a subroutine ?

• What programs are dependent on specific vendor run-time routine ?

• Which programs are "easy to migrate" and which contain specific migration inhibitors ?

Program Management

Developers migrating or modifying particular programs also need portfolio information

• What components make up a particular program ?

• What level of the compiler was used for each component ?

• What compiler options were specified when the program was last compiled ?

• Exist several compiled CSECTs from a program source with different compile dates and attributes ?
  These CSECTs might have different functionality !

• Which compiler run-time routines and run-time option overrides are included as part of the application load module ?

• What is the release level of the runtime routines used or link edited into the application?

• Do the routines need to be refreshed to the latest level to migrate the application?

• Does the COBOL module use ACCEPT FROM DATE, or the PL/I module use DATE or DATETIME Built-in Functions to request the system date?

• Similar questions might be asked about the use of SORT, DB2, IMS, CICS or other LE or system functions if those components or subsystems are being upgraded

• Does the application make use of some Language Environment Callable Service that has changed in the latest release of LE ?
   This happened in OS/390 V2.9 and V2.10

• Does a COBOL program use dynamic CALLs to load an independently linked module for execution ?

• Does an Assembler routine issue a LINK or LOAD macro to dynamically invoke a separately link edited module ?

• Do Assembler routines use other SVCs that may require attention when this application is modified ?

• Are there some components in a load module that require updating or relinking to allow the program to run with LE or to run above the 16MB line ?

• and many more attributes . . .

Conclusion of Load Module Repository

Having the right information readily available makes the developer more productive.
 Problem areas can be addressed immediately, avoiding a lengthy trial-and-error process.

For example LMR can be used for following tasks:

o Application Development and Computer Center Administration are supported with a comprehensive Configuration Management System

o Redesign and Renovation of existing applications

o Interactive query or reporting of all types of
 cross references for all technical attributes,
 internal structure, and  included
 modules/CSECTs over all load modules

o Reports instances of the same module/CSECT name with multiple compile dates or sizes. This inconsistency check can indicate a flaw in the process used for change control, especially when there is only one source program to create the module/CSECT

o Doing quality assurance QA with finding
 e. g. not allowed attributes, compiler and run-time options, compiler and module versions, etc.
 that means verification of z/OS and programming standards

o Verification over all load module libraries with its load modules for LE/390 conformity

o Support for error diagnosis
with tracking of the usage of all Load Modul Libraries with its load modules with included programs and subprograms and their options and attributes

o Compiler Migrations, e. g. for
 IBM Enterprise Cobol and
 IBM Enterprise PL/I

o and still a lot of things more

License and Demonstration:

For LMR we offer to you use licenses and also complete analyses of load module libraries as professional service. 

We also can perform for you complete LE/390, programming language, database and system platform migrations with project management.

We hope, to have gained your interest and would be pleased with being allowed to demonstrate you this tool. You can request further detailed information and examples from us by eMail . For questions we are available with pleasure.

Edge Portfolio Analyzer EPA:

The Edge Portfolio Analyzer is a load module analysis tool for LE, middleware and IBM z/OS® migrations, and for on-going problem source identification, problem determination and for managing an application inventory. The EPA is a unique tool that provides a complete and comprehensive inventory of production level executable objects. This inventory can be used for migration and upgrade planning for new releases of compilers, LE, middleware and operating systems.

The Edge Portfolio Analyzer [EPA] extracts the necessary information about each component of an application load module to assist in planning and management when migrating applications to new compilers, to new levels of LE, new levels of CICS, IBM DB2® and IMS and to new levels of the associated operating system. The EPA is also a valuable tool for managing application assets, problem source identification and problem determination. It can be used to load software configuration management systems (e. g. the SIBRA Load Module Repository LMR) with the information vital to maintain the components.

The EPA can determine the language used to write the application, the compiler used to compile it and critical compiler and run time options applied to the application. In addition, it is possible to determine many of the language and system functions used by the application that may impact the operation of the application. The extraction of this information is done directly from the production executable code. Because of this, the EPA does not rely on external documentation to determine potential migration issues. The EPA provides a basic profile of each CSECT in a load module and performs additional exception reporting based on these characteristics.