BMS Painter: Why a Screen Field, COBOL Copybook, and Load Mapset Are Separate Outputs
The BMS Painter turns visual screen definitions into BMS macros, program copybooks, and loadable mapsets; the build options and a save-and-close requirement determine what actually gets generated. [1] [2] [3]
Read the full briefing
Scope: Rocket Enterprise Developer 12.0 for Eclipse on Windows, using the Windows user-guide bundle. This lesson concerns the BMS Painter development workflow for CICS-style screen maps, not a claim about Linux-hosted painter availability.
The BMS Painter addresses a subtle but important distinction: the visible terminal screen, the program's data layout, and the executable mapset are different build outputs. A painter field becomes a DFHMDF macro, a map becomes DFHMDI, and the containing mapset becomes DFHMSD. The painter lets developers arrange fields and specify attributes and properties visually rather than manually composing each macro. Using the BMS Painter
Consider Rocket's documented example of placing the literal label Name: on a map. The painter emits it as a five-character, display-only, autoskip field with a constant value. If the adjacent area should accept data, however, it must be explicitly defined as a field. That creates a protected or unprotected field in the BMS macro and a corresponding variable in the generated copybook. This is why merely drawing text on a screen does not create a program-addressable input field. Using the BMS Painter
The build pipeline has distinct artifacts:
- Saving the painted definition creates the BMS macro source (
.bms). - Compiling with
TYPE=DSECT, or the appropriateSYSPARMsetting, generates a copybook (.cpyfor COBOL or.macfor Assembler). - Compiling with
TYPE=MAP, or the appropriateSYSPARMsetting, generates the mapset load module (.mod). - Enterprise Developer also maintains a
.bmsxfile recording generated files and their locations. Generating Output from the BMS Painter
The LANG operand on DFHMSD determines the generated copybook language. The Mapset Properties Type selection chooses DSECT, MAP, or &&SYSPARM; with the latter, the BMS file's build settings must specify whether to generate the copybook, load module, or both. Output normally lands in the project's copylib and loadlib folders respectively. Copybooks and Load Modules
For repeatable builds, set the BMS file properties in Enterprise Developer before invoking the painter. The IDE passes these build settings into the painter; they can select output types, COBOL data-item levels, alignment, additional directives, and—on individual files—override generated filenames. Build Settings for the BMS Painter
Operational limitation: You cannot compile a BMS file in Enterprise Developer while that file remains open in the painter. Save and close it first, then compile from the IDE. Rocket also explicitly states that generation of C DSECT include files is unsupported. Copybooks and Load Modules
Takeaway: Validate all three layers separately—screen fields, generated copybook, and mapset load module—and close the painter before compilation. Copybooks and Load Modules