Find every screen field and the COBOL behind it
io.moderne.mainframe.screen.FindScreenFieldsio.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 FindScreenFields
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
Screen fields
io.moderne.mainframe.analysis.table.ScreenFieldsEvery field of every screen, where it is drawn and which COBOL data item reaches it. CICS generates a symbolic map the program moves values into, and IMS supplies an area the program lays a copybook over, so the two halves are joined differently and both are here.
mod study . --last-recipe-run \
--data-table io.moderne.mainframe.analysis.table.ScreenFields
| Column | Description |
|---|---|
| Technology | BMS for a CICS map set, MFS for an IMS format set. |
| Map set or format set | The DFHMSD for BMS, the FMT for MFS. |
| Map or page | The DFHMDI for BMS, the DPAGE for MFS. A format set with two device pages carries the same labels twice at different positions, which is why the page is part of what names a field. |
| Message or record | For MFS, the MSG that carries the field — the MID it arrives on or the MOD it goes out on. For BMS, the symbolic map record the program's item is declared in. Empty for a field no message and no program reaches. |
| Field | The label the map set or format set gives the field. Empty for a literal written straight onto the screen, which no program can name. |
| Row | The line the field starts on, counted from one. Zero where the definition gives no position, which is what a message field carrying a literal does. |
| Column | The column the field starts at, counted from one. BMS counts the attribute byte here and paints the data from the next column; MFS counts the first byte of the data itself. |
| Length | How many characters the field occupies on the screen, or how many bytes it occupies in the message where it is only in the message. |
| Attributes | How the field is drawn and whether it can be typed into, space separated and as the definition writes them: ASKIP NORM for BMS, PROT HI for MFS. |
| Initial value or literal | The text the field is drawn with whatever the program does, from BMS INITIAL= or the MFS literal. Padding is kept, because it is what decides how wide the field is. |
| Program | The COBOL program that reaches the field. Empty where nothing analysed does, which for a labelled field is worth reading twice. |
| Data item | What the program calls the field. For BMS this is the generated item the program names — TITLEO and TITLEL are the same field. For MFS the program names nothing, so this is the copybook item lying at the field's displacement, matched by order and length and never by name. |
| Subfield or offset | For BMS which part of the field the item is: OUTPUT carries the value, LENGTH says how much the operator typed, COLOR how it is drawn. For MFS the field's displacement in the message area, counted from zero and past the four byte prefix IMS supplies and no MFLD describes. |
| Source path | The map set or format set the field is defined in. |
| Line | The one-based line of the DFHMDF or DFLD. |
Screen lines
io.moderne.mainframe.analysis.table.ScreenLinesEach screen as the terminal paints it, one row per line: the literals where they are written and an underscore for every character the program supplies. This is what a green screen viewer draws, and what makes a map set readable without a terminal.
mod study . --last-recipe-run \
--data-table io.moderne.mainframe.analysis.table.ScreenLines
| Column | Description |
|---|---|
| Technology | BMS for a CICS map set, MFS for an IMS format set. |
| Map set or format set | The DFHMSD for BMS, the FMT for MFS. |
| Map or page | The DFHMDI for BMS, the DPAGE for MFS. |
| Device | What the screen is drawn on: the BMS TERM=, or the MFS DEV TYPE= with its model. A printer is laid out the same way and is not a screen anybody types into. |
| Rows | How many lines the screen holds: 12 for a model 1, 24 for a model 2, or the BMS SIZE=. Where the device says nothing, the last line a field is on. |
| Columns | How many characters wide the screen is, which is what a BMS POS=n displacement is counted against. |
| Row | Which line of the screen this is, counted from one. |
| Text | The line as it is painted: literals in place, an underscore for every character a field supplies, and a blank everywhere the map writes nothing. Trailing blanks are kept so the columns line up. |
| Source path | The map set or format set the screen is defined in. |
Findings
io.moderne.mainframe.analysis.table.FindingsEverything the mainframe analyses found wrong, ranked, with the evidence for each and the line it is on. Sort on priority.
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.CobolRelationshipsRelationships between different COBOL resources.
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.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. |