Find what each load module is built from
io.moderne.mainframe.linkedit.FindLoadModuleCompositionio.moderne.recipe:recipes-mainframeUsage
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.
mod run . --recipe FindLoadModuleComposition
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
- LATEST
- Pinned version
mod config recipes jar install io.moderne.recipe:recipes-mainframe:RELEASE
mod config recipes jar install io.moderne.recipe:recipes-mainframe:LATEST
mod config recipes jar install io.moderne.recipe:recipes-mainframe:0.1.0
Data tables
Load module composition
io.moderne.mainframe.analysis.table.LoadModuleCompositionWhat 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.
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.SourcesFileResultsSource files that were modified by the recipe 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.SearchResultsSearch results that were found during the recipe 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.SourcesFileErrorsThe details of all errors produced by a recipe 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.RecipeRunStatsStatistics used in analyzing the performance of recipes.
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. |