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 or macOS (internal)

The @rocket/m204-tools package makes it possible to edit, assemble, link, patch, and test Model 204 from WSL or macOS. 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	Upload a linked CMS module and map for mainframe testing
putmodzos	Upload the z/OS object deck that the z/OS binder uses to create the test load module

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.

Workstation setup

The published tools support:

• WSL 2 or another x86-64 Linux environment; and
• macOS on Apple silicon.

The npm package does not currently include an Intel macOS emulator binary.

WSL

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.

Install Git and Node.js/npm, and make sure npm has access to Rocket's registry.

macOS

Install Git and Node.js/npm. The command-line developer tools supplied by Xcode are sufficient for Git. Homebrew or nvm can be used for Node.js; use one installation consistently so an old global npm prefix does not remain earlier on PATH.

The CMS and z/OS passwords are stored in the macOS Keychain. No Linux keyring setup is needed.

The upload commands invoke an ftp command-line client. Modern macOS does not supply one, so verify command -v ftp. If it is absent, install a compatible client such as tnftp with Homebrew.

Install the tools

On either platform, 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 the shell finds a mixture of commands under /usr/local/bin, an nvm directory, a Homebrew prefix, 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 workstation 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. On macOS, they use the system Keychain.

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, upload the ZAP-build object deck:

putmodzos --zap

Run the z/OS bind described below, 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

Testing on z/OS

The workstation linker produces a concatenated, fixed-80-byte z/OS object deck:

• baseline: obj/M204ONLN.ZOSMOD
• ZAP build: zapobj/M204ONLN.ZOSMOD

putmodzos uploads that object deck to the PDSE member named by zos.jsonc. It does not create the executable z/OS load module by itself. The gitzosl job on the Builder runs the z/OS binder and creates the test load module.

Configuration

The Model 204 tree needs zos.jsonc containing the z/OS FTP host, userid, object library, and member:

{
  "host": "...",
  "user": "...",
  "objlib": "...",
  "member": "..."
}

Do not put the password in this file. putmodzos obtains it from the workstation credential store, prompting on first use.

Build and upload

For an unpatched baseline test:

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

For a ZAP-maintenance test:

make204 --zap
putmodzos --zap

The upload is binary into an FB 80 PDSE member. If putmodzos says the object deck is missing, run make204 first and confirm that the selected obj/ or zapobj/ directory contains M204ONLN.ZOSMOD.

Bind on z/OS

On the Builder, run:

gitzosl

The submitted job deletes the prior test load module, compresses the test load library, binds M204ONLN with IEWL, and applies the required ZAPs. Its output returns to the Builder's virtual reader through RSCS/NJE.

Use rl (RDRLIST), then PF11 to inspect the job output. A successful bind includes:

$HASP395 ONLINE ENDED - RC=0000

Do not start the test Online if the bind failed or if the expected object deck was not used.

Select the z/OS Online

On the Online's CMS console:

EOJ
xedit setup names a

Change:

:opsys.CMS

to:

:opsys.MVS

The XEDIT command is:

c/:opsys.CMS/:opsys.MVS/ *
file

Leave :tester. set to the builder userid. It still selects the test version of M204ONLN.

Start and test

Start with either a full CMS IPL or the configuration nickname:

IPL CMS

PROFILE EXEC builds and submits the startup JCL. The JES messages include receipt of the job and completion of the submission step with MAXCC=0000. Unlike a CMS Online, Model 204 is now running as a z/OS batch job; the CMS console returns to VM read instead of displaying the local ONLINE message.

Connect from the normal user session:

M204F suffix
LOGIN
OPEN QAPROC
I QARUN pattern

Run the same reproducer used for the baseline. For a ZAP fix, keep evidence that the baseline failed and the ZAP build passed.

Return to CMS testing

Shut down the z/OS Online, edit SETUP NAMES, and change:

c/:opsys.MVS/:opsys.CMS/ *
file

Then IPL CMS or start the configuration nickname again.

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 platform package is missing	Reinstall without --no-optional or --ignore-scripts; check for an older command earlier on PATH. Published binaries support x86-64 Linux and Apple-silicon macOS.
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
• m204-80/.github/skills/zos-crossbuild.md