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

Find the Db2 unloads and what it would take to run them on the base utility

Recipe IDio.moderne.mainframe.db2.FindHpuUsage

Artifactio.moderne.recipe:recipes-mainframe

Report every Db2 unload the portfolio runs and mark the EXEC card each is reached from with what moving it off the High Performance Unload product would take. The classification is by the dialect the control cards are written in and never by PGM=: a shop may alias DSNUTILB to the product's compatibility entry point INZUTILC, and the product reads three vendors' dialects through one program name of its own, so the row says what in the deck proved the engine. Each unload lands in one of four: ALREADY_THE_TARGET for a deck already written in the base utility's language, MAPS_KEYWORD_FOR_KEYWORD where IBM's own option table covers every keyword — OUTDDN to UNLDDN, LOADDDN to PUNCHDDN, LOCK YES QUIESCE YES to SHRLEVEL REFERENCE — NEEDS_REDESIGN where the deck reads a table space once and writes several files, orders rows, joins tables, unloads an image copy or calls an exit, and NOT_DECIDABLE where a name in the job was not followed or the deck leaves what it writes to the site parmlib. The findings beside them are the changes that would alter the bytes downstream readers get without anybody noticing: the access mode, a lock and quiesce pair no SHRLEVEL matches, output DDs the base utility would default elsewhere, and a deck carrying both JES symbols and the product's own template variables. AnalyzeHpuUsage answers the same question 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 FindHpuUsage

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

Db2 unloads

io.moderne.mainframe.analysis.table.Db2Unloads

Every unload a job runs, the dialect its control cards are written in, what it unloads and where it writes it, and what it would take to run the same unload on the base Db2 utility.

Export after a run

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

Column	Description
Job	The job name, empty for a member with no JOB card.
Member	The JCL member the job was read from.
Source path	The file the job was read from, which is the file to open at the line below.
Line	The one-based line of the EXEC card written in that member. A step a procedure supplies has no line in the job, so it is the calling card that is given — the card a transformation would be applied to.
Step	The step name, qualified by the step that called its procedure — UNLHST.UNL.
Program	The program the step names on PGM=, with its symbols filled in. It does not say which engine runs: the unload product reads three vendors' dialects through one program name of its own, and a shop may alias the base utility's program to the product's compatibility entry point.
Dialect	The language the control cards are written in: HIGH_PERFORMANCE_UNLOAD for the unload product's own, BASE_UTILITY for the one the Db2 utilities read. This, and not the program name, is what says which engine runs.
Proven by	What in the deck settled the dialect — the SELECT and OUTDDN of the product, the FROM TABLE or SHRLEVEL of the base utility — and, where the program name says otherwise, that it does.
Deck	The control card member the cards are written in, or the JCL member for a deck written in the job stream.
Deck path	The file that member was read from, empty where the member was named but not supplied.
Deck line	The one-based line of that file the UNLOAD statement is written on.
Cards	Where the cards are written: IN_STREAM in this member's own job stream, PROCEDURE in the stream of the procedure the step calls, MEMBER in the library member the DD names.
Table space	The table space unloaded, empty where the deck leaves it to be worked out from the tables the SELECTs name — which an image copy unload does.
Tables	The tables the rows come from, separated by , : one per SELECT in the product's dialect, one per FROM TABLE in the base utility's.
Selects	How many SELECT or FROM TABLE blocks the unload writes. More than one is one pass over the table space fanned out to several files, and the base utility needs a statement and a pass each.
Output DDs	Every DD the rows are written to. The product has no default and every deck names its own; the base utility defaults to SYSREC, so these names are written twice — once here and once in the JCL — and a change to either has to be a change to both.
Load card DDs	Every DD the generated LOAD cards are written to. The base utility defaults this one to SYSPUNCH. A name here may be a TEMPLATE of the deck rather than a DD of the job.
Copy DD	The DD an image copy is read from instead of the table space, empty where the unload reads the table space. LAST_IC or a negative number is a catalog search the base utility does not do.
Formats	The layout each SELECT writes. A SELECT that codes none is not listed, because what it writes is then a site setting rather than something the deck says.
Access	How the rows are read: NO off the data sets outside Db2, FORCE through a dynamic cursor, YES for either as the SQL allows. The bytes written are not the same across the three. Empty where the deck leaves it to the site parmlib.
Consistency	What the deck says about reading a table space somebody else may be writing — LOCK YES QUIESCE YES in the product's dialect, SHRLEVEL REFERENCE in the base utility's. The two are not one for one: only LOCK YES QUIESCE YES, and LOCK YES under DB2 FORCE, are documented as ensuring consistency.
Verdict	How far the step reads, from FindExecutionPaths: RESOLVED, INHERITED where a keyword comes from the site parmlib, UNRESOLVED where a name was not followed at all.
Migration	What it would take to run this unload on the base utility: ALREADY_THE_TARGET for a deck already written in its language, MAPS_KEYWORD_FOR_KEYWORD where IBM's own option table covers every keyword, NEEDS_REDESIGN where it does not, NOT_DECIDABLE where the source does not say enough to judge.
Evidence	Why that verdict, separated by ; — the keywords the mapping covers, the constructs it does not, or the reasons the path could not be read. A verdict nobody can check is a verdict nobody will act on.

Findings

io.moderne.mainframe.analysis.table.Findings

Everything the mainframe analyses found wrong, ranked, with the evidence for each and the line it is on. Sort on priority.

Export after a run

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

Column	Description
Priority	1 for CRITICAL down to 4 for LOW, so the table sorts.
Severity	CRITICAL for code that cannot do what it was written to do, HIGH for what will break a migration if not decided deliberately, MEDIUM for what is worth knowing first, LOW for cleanup.
Category	What kind of problem it is, which is what groups the report into sections: DEAD_RULE, UNREACHABLE_CODE, COPYBOOK_DRIFT, MIGRATION_BLOCKER, RANGE_PATHOLOGY, DEAD_DATA, COMPLEXITY, LAYOUT_DRIFT, IMS_PCB_MISMATCH, IMS_SEGMENT_NOT_SENSITIVE, IMS_IO_AREA_MISMATCH, MFS_MESSAGE_LENGTH, SCREEN_ITEM_UNREACHED, SCREEN_FIELD_UNREACHED, PARSE_FAILURE, UNDOCUMENTED, STALE_DOCUMENTATION, STALE_REFERENCE, UNENFORCED_BUILD_ORDER, UNSCHEDULED_JOB, AUTOCALL_RESOLVED_REFERENCE, UNRESOLVED_EXECUTION_PATH, INHERITED_SETTING, UNLOAD_NEEDS_REDESIGN, UNLOAD_ACCESS_MODE, UNLOAD_CONSISTENCY, UNLOAD_OUTPUT_WIRING, MIXED_SUBSTITUTION.
Program	The COBOL program, or the copybook where the finding is about one.
Summary	The finding in one sentence, written to be read on its own.
Evidence	Why this is claimed — the conditions that conflict, the two declarations that differ, the caller that made the paragraph unreachable. A finding nobody can check is a finding nobody will act on.
Where	The paragraph, section or data item the finding is in.
Source path	The file, so the finding can be opened.

COBOL relationships

org.openrewrite.mainframe.cobol.table.CobolRelationships

Relationships between different COBOL resources.

Export after a run

mod study . --last-recipe-run \
  --data-table org.openrewrite.mainframe.cobol.table.CobolRelationships

Column	Description
Dependent	The resource that defines the relationship.
Dependent type	The resource type of the resource that defines the relationship.
Action	The action that links the dependent and dependency.
Dependency	The resource that is exercised or linked to.
Dependency type	The resource type of the resource that is exercised or linked to.
Dependency missing	Indicates whether the dependency is a known resource.
Action metadata	Additional data about the action.
Dependent path	The source file the dependent's statement was written in, or null when the dependent is a name that has no source here.
Dependent line	The one-based line the dependent's statement was written on, or null when it has no source here.
Dependency path	The source file the dependency was written in, or null when the dependency is a name that has no source here, such as a vendor copybook.
Dependency line	The one-based line the dependency's statement was written on, or null when the dependency is a whole file rather than a statement within one.

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.