Moderne OnlyThis recipe is proprietary to Moderne and runs on the Moderne platform or CLI — it isn’t part of the open-source catalog. Available with a Moderne subscription.Contact Sales

Join each load module to the programs bound into it

Recipe IDio.moderne.mainframe.linkedit.AnalyzeLoadModuleComposition

Artifactio.moderne.recipe:recipes-mainframe

Record what the binder puts in each load module: the program the module is named for, the subroutines and map sets bound in with it, where control enters, the other names it answers to, the step that links it and the steps that run it. The link-edit deck and the module listing are reconciled against each other, so a module that has drifted from its deck is told apart from one whose listing is older than the last build. FindLoadModuleComposition answers the same question and marks each deck and listing in the source; this one produces the table and changes nothing.

Single recipeOpenRewriteModerne Proprietary License

Try in PlatformTry this recipe in the Moderne platform. Not a user yet? You’ll get a no-setup demo environment, with nothing to install or configure.

Usage

Run this recipe

This recipe has no required configuration options. Users of Moderne can run it via the Moderne CLI.

You will need to have configured the Moderne CLI on your machine before you can run the following command.

shell

mod run . --recipe AnalyzeLoadModuleComposition

If the recipe is not available locally, then you can install it using:

RELEASE resolves to the newest release and LATEST to the newest build of any kind, including snapshots. Either one lets mod config recipes upgrade pull in later versions without editing this command; a pinned version stays where you put it.

RELEASE

mod config recipes jar install io.moderne.recipe:recipes-mainframe:RELEASE

LATEST

mod config recipes jar install io.moderne.recipe:recipes-mainframe:LATEST

Pinned version

mod config recipes jar install io.moderne.recipe:recipes-mainframe:0.1.0

Data tables

Load module composition

io.moderne.mainframe.analysis.table.LoadModuleComposition

What each load module is built from, one row per program, map set or external routine bound into it, read from the link-edit deck that declares the module and from the listing that reports the module as built. Neither the COBOL nor the JCL says which programs share a module: a step names a module and runs whatever the binder last put in it, so a change to a statically bound subroutine is felt by every module holding a copy and by nothing else.

Export after a run

mod study . --last-recipe-run \
  --data-table io.moderne.mainframe.analysis.table.LoadModuleComposition

Column	Description
Module	The load module, which is the name a step, a CALL or a CICS program definition asks for.
Library	The load library the module is written to, from the SYSLMOD of the step that links it or from the listing. Which library a module is in is what tells a batch module from a CICS one where both carry the program's name.
Part	A program, map set or external routine the module holds. Every module holds the program of its own name; a statically called subroutine is a second part of every module that includes it.
Part kind	PROGRAM, ASSEMBLER or MAPSET where the part was read, STUB for a language interface known by name, EXTERNAL for an object nobody supplied. Runtime sections the binder's autocall pulls in are not parts and get no row.
Part path	The part's file, empty for a stub or an external routine. A module built from a program no ingestion holds is how a gap shows.
Reconciliation	BOTH where the deck declares the part and the listing reports it, DECLARED_ONLY where the module has not been listed since the deck was written, OBSERVED_ONLY where the module holds something no deck asked for — the module in the library and the deck in the library have drifted apart — and BUILT_ONLY where a job writes the module and neither describes it.
Inferred	True where no card names the part. The compile hands the binder its object on SYSLIN without naming it, so the program a module is named for is a part of it that the deck does not write down; every other part is on a card of its own.
Entry point	Where control enters the module: the program's own section, or a label in it such as the DLITCBL a DL/I batch program declares.
Aliases	The module's other directory entries, space separated. An alias is a second name the same module answers to, which is how a renamed program goes on being called by its old name.
Deck	The link-edit deck that declares the module, empty where none was read. A deck written in a job stream is that job.
Deck line	The line of the deck the part's INCLUDE card is on, or of the NAME card for the program the module is named for. Zero where no deck declares the part.
Listing	The listing the module was read from, empty where none covers it. A listing is what was printed on the day it last ran, so a module built since is missing from it rather than absent from the library.
Listing line	The line of the listing the part's control section is reported on. Zero where no listing covers the module.
Linked by job	The job whose step reads the deck, empty where no job read here does.
Linked by step	The step of that job, which is what has to be rerun to rebuild the module.
Loaded by job	A job whose step runs this module, empty where none does. Four cards say so: PGM=, the PARM an IMS region takes its program in, the RUN PROGRAM of a DSN deck the step reads, and the APPLCTN of a stage 1 deck — which is not a job at all, and names the stage 1 member instead. A module several steps run has a row for each.
Loaded by step	The step that runs it, named as the job writes it rather than as the procedure does, or APPLCTN for a module the IMS message region loads.

Source files that had results

org.openrewrite.table.SourcesFileResults

Source files that were modified by the recipe run.

Export after a run

mod study . --last-recipe-run \
  --data-table org.openrewrite.table.SourcesFileResults

Column	Description
Source path before the run	The source path of the file before the run. null when a source file was created during the run.
Source path after the run	A recipe may modify the source path. This is the path after the run. null when a source file was deleted during the run.
Parent of the recipe that made changes	In a hierarchical recipe, the parent of the recipe that made a change. Empty if this is the root of a hierarchy or if the recipe is not hierarchical at all.
Recipe that made changes	The specific recipe that made a change.
Estimated time saving	An estimated effort that a developer to fix manually instead of using this recipe, in unit of seconds.
Cycle	The recipe cycle in which the change was made.

Source files that had search results

org.openrewrite.table.SearchResults

Search results that were found during the recipe run.

Export after a run

mod study . --last-recipe-run \
  --data-table org.openrewrite.table.SearchResults

Column	Description
Source path of search result before the run	The source path of the file with the search result markers present.
Source path of search result after run the run	A recipe may modify the source path. This is the path after the run. null when a source file was deleted during the run.
Result	The trimmed printed tree of the LST element that the marker is attached to.
Description	The content of the description of the marker.
Recipe that added the search marker	The specific recipe that added the Search marker.

Source files that errored on a recipe

org.openrewrite.table.SourcesFileErrors

The details of all errors produced by a recipe run.

Export after a run

mod study . --last-recipe-run \
  --data-table org.openrewrite.table.SourcesFileErrors

Column	Description
Source path	The file that failed to parse.
Recipe that made changes	The specific recipe that made a change.
Stack trace	The stack trace of the failure.

Recipe performance

org.openrewrite.table.RecipeRunStats

Statistics used in analyzing the performance of recipes.

Export after a run

mod study . --last-recipe-run \
  --data-table org.openrewrite.table.RecipeRunStats

Column	Description
The recipe	The recipe whose stats are being measured both individually and cumulatively.
Source file count	The number of source files the recipe ran over.
Source file changed count	The number of source files which were changed in the recipe run. Includes files created, deleted, and edited.
Cumulative scanning time (ns)	The total time spent across the scanning phase of this recipe.
Max scanning time (ns)	The max time scanning any one source file.
Cumulative edit time (ns)	The total time spent across the editing phase of this recipe.
Max edit time (ns)	The max time editing any one source file.