LMR Load Module Repository
built on your
existing load module libraries
"The truth only exists in the code that goes into production every
your Application Development, Program Quality and Performance
Analysis of currently running Load Module
Libraries for Enterprise, Application Portfolio,
and Program Management
Building up a DB2 based Load Module Repository LMR from currently running Load Module Libraries for the usage as a
Configuration Management System
LMR does not let unanswered any question about your applications stored
in the load module libraries,
it offers an up to now not achieved analysis and repository quality
LMR supports you in every
modification, further development and migration of your software,
considerably time and money,
reduces the project risk and increases the quality
is available on z/OS Mainframe and on Windows PC and Server (On UNIX on
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
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 ?
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
Do the routines need to be refreshed to the latest level to migrate the
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 . . .
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.
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
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
. 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.