Internal Developing Model 204 from WSL

Internal use only. This page is intentionally not linked from the main page or any category. Do not link it from customer-facing pages.

Developing Model 204 from WSL (internal)

The @rocket/m204-tools package makes it possible to edit, assemble, link, patch, and test Model 204 from a WSL Linux environment. The main commands are:

Command	Purpose
make204	Incrementally assemble Model 204 and link CMS and z/OS modules
emu204	Run the real linked Model 204 module on the workstation
testM204Qa	Start Model 204 under emu204 and run a QA smoke test
prezap	Create the header for a new maintenance ZAP
scanzap	Find the next available local and PTCH$ patch offsets
bldzap	Compare two object decks and generate VER/REP statements
putmod / putmodzos	Upload a linked CMS or z/OS module for mainframe testing

This page describes the Model 204 8.0 workflow. Release 8.0 is under ZAP maintenance, so the baseline objects and the ZAP objects must be kept separate.

WSL setup

Use WSL 2 with a current Ubuntu distribution. Keep the Git repositories in the Linux filesystem, for example under ~/gitm204 and ~/m204-80, rather than under /mnt/c. Linux builds and Git operations are faster there and do not inherit Windows filename and permission behavior.

The tools require Git, Node.js/npm, and access to Rocket's npm registry. Install or update the complete tool suite:

npm install -g @rocket/m204-tools@latest
hash -r

The single package supplies make204, hlasm, cmslink, zapobj, emu204, testM204Qa, the ZAP utilities, and the Imagine JavaScript runtime.

Verify the installation:

make204 --help
emu204 --help
testM204Qa --help
type -a make204 emu204 testM204Qa prezap scanzap

All commands should normally come from the same npm installation. If WSL finds a mixture of commands under /usr/local/bin, an nvm directory, or another npm prefix, remove or update the obsolete installation. A split installation can make make204 use one package version while emu204 uses another.

If emu204 reports that @rocket/em204-linux-x64 is not installed, reinstall @rocket/m204-tools without --no-optional or --ignore-scripts.

Repositories

The two repositories have different purposes:

• ~/gitm204 contains the build tools, assembler, linker, emulator, and their tests.
• ~/m204-80 contains the Model 204 source and is where normal Model 204 coding and ZAP work is done.

The Model 204 directory name matters. It must end in the two-digit release, such as m204-80, because the tools derive the release and CMS disk names from it.

Before beginning a change:

cd ~/m204-80
git status --short --branch
git switch master
git pull

Do not discard uncommitted work. Resolve or preserve it before changing branches.

First build and CMS libraries

From the Model 204 repository root:

cd ~/m204-80
make204 --no-zap

On the first build, make204 downloads the macro and object libraries it needs from CMS. You need a CMS userid with FTP access. The userid defaults from $USER, truncated to eight characters. If the WSL login name is not the CMS userid, set M204_FTPVM_USERID in the shell.

On WSL, the tools can offer to install and configure gnome-keyring and libsecret-tools so the CMS password can be saved. If the keyring is not configured, the tools can still run but may ask for the password again.

Library fetches are recorded in .m204libs. If a fetch was interrupted, make204 recognizes the half-fetched library and downloads it again. A large number of unknown assembler operations usually means that the macro library is incomplete.

Normal coding and build cycle

Model 204 assembler source, copy members, macros, and ZAP files are under src/. Build outputs are ignored by Git:

Directory	Contents
obj/	Baseline object decks and linked modules
lst/	Baseline assembly listings
ref/	Baseline dependency information
zapobj/	ZAP-build objects, per-module ZAPs, and linked modules
zaplst/	ZAP-build listings
zapref/	ZAP-build dependency information

A typical edit/build loop is:

cd ~/m204-80

# Edit src/MODULE.ASSEMBLE, a COPY member, or a MACRO.

make204 MODULE       # assemble the named source and link if needed
make204              # assemble everything that changed and link if needed

Useful options:

Option	Meaning
--force	Reassemble everything, ignoring dependency timestamps
--link	Force a link even when no object appears to have changed
--no-link	Assemble without linking
--stdout	Show assembler output
--errLines=N	Show the first N diagnostic lines for each failed module
--errMax=0	Continue after assembly failures instead of stopping at the first one
--clear	Empty the selected build directories before building

make204 MODULE names an input source, not necessarily an output object. For example, one input may produce more than one output module.

Review the corresponding listing after an assembly:

less lst/MODULE.LST80

In the 8.0 repository, a bare make204 defaults to ZAP mode because m204.jsonc contains "zap": true. Use --no-zap explicitly when you intend to build the baseline in obj/.

Testing a normal module under emu204

emu204 runs the real z/OS Model 204 module locally. It is not a source-level reimplementation of Model 204.

The simplest supported baseline smoke test is:

cd ~/m204-80
make204 --no-zap
testM204Qa --tree="$HOME/m204-80"

testM204Qa starts obj/M204ONLN.MODULE under emu204 and runs the UL*, REGEX*, and CMD* QA patterns. It takes roughly half a minute. Results are written under m204qa/out/ beside the Model 204 tree.

Run the make204 --no-zap command above only when intentionally building the baseline, normally on unmodified master. On a ZAP branch it would replace the baseline objects with the changed source and destroy the comparison that generates the ZAP.

Do not judge this run by the emulator return code. Tests deliberately provoke Model 204 errors, so a successful run can have a nonzero Model 204 return code. testM204Qa reads QARUN's output and checks that every pattern finished, ran tests, reported no failures, and produced no SNAP.

For an interactive or specialized run, use an emulator configuration:

emu204 --config=/path/to/emu204.jsonc
emu204 --help
emu204 --help=config
emu204 --help=em

A configuration identifies the linked module, CPU ID, Model 204 parameters, and DDs such as CCAIN, CCAPRINT, CCAAUDIT, CCASNAP, procedure directories, and database files. While Model 204 runs, a console line beginning with # is an emulator command. A bare # stops the guest at the EM> prompt; BEGIN resumes it.

ZAP-maintenance workflow

1. Refresh the unmodified baseline

Every generated ZAP is a comparison against the baseline objects in obj/. Build those objects from current, unmodified master:

cd ~/m204-80
git switch master
git pull
make204 --no-zap

This step is mandatory. A stale baseline can produce ZAPs for modules that were not changed. Rebuild it after master moves or after a change to the assembler, pinned build date, version settings, or other build configuration.

2. Create the maintenance branch

The branch name must match <release>Z<PDS-number>:

git switch -c 80Z9206
prezap

prezap creates src/80Z9206.ZAP. Edit its header to describe the symptom, fix, prerequisites, and any genuinely necessary special instructions. Leave the 80Zxxx placeholder in the header; the distribution build assigns the sequence.

3. Check whether the target can be generated automatically

SIRE2 and EWDP are excluded from automatic object comparison in the current 8.0 configuration. A source change in either module can assemble and link successfully while being absent from the branch ZAP. Such a fix must be cut by hand on CMS or shipped in a relinked module.

Check the target module before doing the implementation.

4. Find patch space and make the source change

For a change that uses a module's local patch area or PTCH$:

scanzap SCOMP
scanzap SCOMP OTHERMOD

The output reports the next PTCH offset and the next local offset for each named module. Then edit the source under src/.

5. Build the ZAP

Use a clean ZAP directory for the first build:

make204 --clear

Subsequent builds can be incremental:

make204

In ZAP mode, make204:

1. assembles into zapobj/, zaplst/, and zapref/;
2. compares each changed object with the baseline object in obj/;
3. invokes bldzap to create per-module NAME/VER/REP statements;
4. links zapobj/M204ONLN.MODULE and zapobj/M204ONLN.ZOSMOD; and
5. appends the generated statements to src/<branch>.ZAP.

A successful run reports a header and one or more generated ZAPs. Header only (no ZAPs) means that no object difference was found. The usual causes are an unchanged source, a baseline that already contains the fix, or a target excluded by m204.jsonc.

Review all three forms of the result:

less src/80Z9206.ZAP
less zaplst/MODULE.LST80
git diff -- src/80Z9206.ZAP src/MODULE.ASSEMBLE

6. Prove the test and test the patched module

First prove that the test exposes the bug in the unpatched baseline:

putmod --no-zap

Recycle the CMS Online and run the test. It should fail or reproduce the reported BUG/SNAP.

Then upload the ZAP-applied build:

make204 --zap
putmod --zap

For z/OS:

putmodzos --zap

Recycle the Online and run the same test. To switch back:

putmod --no-zap
putmodzos --no-zap

The standard testM204Qa command reads the normal object directory from hlasm.jsonc and therefore tests obj/M204ONLN.MODULE, not zapobj/M204ONLN.MODULE. Do not cite that smoke test as evidence that the generated ZAP was applied. Test the ZAP build explicitly on CMS/z/OS, or create a separate emu204 configuration whose module names the ZAP-linked module.

7. Final review

Before committing:

• Verify that the branch ZAP names only the modules expected for the fix.
• Verify every VER and REP block and the correct patch offsets.
• Check the prerequisite ZAP line; remove it if there is no prerequisite.
• Remove the template's special-instructions block unless it is required.
• Make sure the instructions name every load module that must be patched.
• Run git status --short and stage source paths explicitly. Do not stage build output or unrelated files.

Testing on CMS

putmod uploads the linked CMS MODULE and map to the build disk derived from the release and userid. In the Online's SETUP NAMES, set :tester. to the builder userid so the Online loads that user's module.

The normal recycle is:

EOJ
IPL CMS

At the CMS Ready prompt, PROFILE EXEC normally starts the Online. Run the reproducing QA procedure after the Online is ready.

Procedure changes are separate from the module upload. Push modified procedure directories with:

gitproc push qaproc
gitproc push m204proc

Working on the tools themselves

Use ~/gitm204 only when changing make204, emu204, the assembler/linker, or another tool:

cd ~/gitm204
npm install
npx make
npm test

Useful narrower checks are:

npm run testci
npm run testmake
npm run testm204
npm run testm204qa

To prove the working-tree tools can build and run Model 204:

npx make
npx testM204Build --tree="$HOME/m204-80"
npx testM204Qa --tree="$HOME/m204-80"

testM204Build empties obj/ and ref/ in the tree it is given. Do not point it at a working tree whose current build output must be preserved.

Troubleshooting

Symptom	Action
make204 is not found	Reinstall @rocket/m204-tools, run hash -r, and inspect type -a make204.
emu204 says its Linux platform package is missing	Reinstall without --no-optional or --ignore-scripts; check for an older command earlier on PATH.
Hundreds of unknown assembler operations	The macro libraries are probably absent or half-fetched. Run getmaclib --direct, then rebuild.
Linker reports unresolved LE symbols	Fetch the required object library with getobjlib --direct.
ZAP file has only its header	Confirm the source really differs from the baseline, refresh the baseline from unmodified master, and check whether the module is excluded from automatic ZAP generation.
ZAP unexpectedly contains many modules	The baseline or a pinned build setting is stale. Return to master and rebuild with make204 --no-zap.
QA run has a nonzero return code	Read the testM204Qa verdict. The Model 204 return code is not the pass/fail result.
Need more emulator detail	Use emu204 --help, emu204 --help=config, and emu204 --help=em.

Source references

• gitm204/BUILD.md
• gitm204/em204/README.md
• m204-80/DEVELOPMENT.md
• m204-80/ZAP-WORKFLOW.md
• m204-80/.github/skills/building.md
• m204-80/.github/skills/testing.md