m204wiki - Recent changes [en]

Internal Developing Model 204 from WSL

Tthoresen — Fri, 13 Nov 2026 20:34:31 GMT

Document em204 alias and em204.jsonc fallback (GM204-30)

← Older revision		Revision as of 20:34, 13 November 2026
Line 78:		Line 78:

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

			The package still installs <code>em204</code> as an alias for <code>emu204</code>, so existing scripts keep working.

	This installation procedure was verified on WSL on 5 November 2026 with <code>@rocket/m204-tools</code> 1.1.167. Updating the nvm installation put <code>make204</code>, <code>emu204</code>, <code>testM204Qa</code>, Imagine, and the ZAP utilities under the same npm prefix. Older copies under <code>/usr/local/bin</code> remained present but no longer took precedence.		This installation procedure was verified on WSL on 5 November 2026 with <code>@rocket/m204-tools</code> 1.1.167. Updating the nvm installation put <code>make204</code>, <code>emu204</code>, <code>testM204Qa</code>, Imagine, and the ZAP utilities under the same npm prefix. Older copies under <code>/usr/local/bin</code> remained present but no longer took precedence.
Line 227:		Line 229:

	With no <code>--config</code>, <code>emu204</code> reads <code>emu204.jsonc</code> in the current directory. Relative paths in the configuration are resolved against the directory containing the configuration, not against the shell's current directory. This makes the case directory movable.		With no <code>--config</code>, <code>emu204</code> reads <code>emu204.jsonc</code> in the current directory. Relative paths in the configuration are resolved against the directory containing the configuration, not against the shell's current directory. This makes the case directory movable.

			If <code>emu204.jsonc</code> is not present but <code>em204.jsonc</code> is, <code>emu204</code> reads <code>em204.jsonc</code>, so case directories written against the old name still load.

	The complete reference is:		The complete reference is:

Siraudreport.wiki

Tom — Wed, 11 Nov 2026 13:25:36 GMT

Show changes

Siraudreport.wiki

Tom — Mon, 09 Nov 2026 20:57:58 GMT

Created page with "__TOC__ '''SIRAUD report''' (Sirius audit report, generated from <code>AUDREP.XML</code>). Preview page; layout is a first draft. == Overview == {| class="wikitable" ! Item !! Value |- | Interval start || 2026-11-09 15:18:20 |- | Interval end || 2026-11-09 15:24:55 |- | Duration || 0:06:35 |- | Site || ROCKET |- | Version || 8.0.78 2 |- | Buffers || 0 + 100000 |- | Cpuid || FF379B789175 |} == Interval statistics == {| class="wikitable sortable" ! Statistic !! Value |-..."

Show changes

Internal Developing Model 204 from WSL

Tom — Fri, 06 Nov 2026 17:38:48 GMT

Show changes

Internal Developing Model 204 from WSL

Tom — Wed, 04 Nov 2026 15:00:13 GMT

Created page with "__NOINDEX__ __NOTOC__ <div style="border:1px solid #c00; padding:6px;">'''Internal use only.''' This page is intentionally not linked from the main page or any category. Do not link it from customer-facing pages.</div> = Developing Model 204 from WSL (internal) = The <code>@rocket/m204-tools</code> package makes it possible to edit, assemble, link, patch, and test Model 204 from a WSL Linux environment. The main commands are: {| class="wikitable" ! Command !! Purpose..."

New page

__NOINDEX__
__NOTOC__
<div style="border:1px solid #c00; padding:6px;">'''Internal use only.''' This page is intentionally not linked from the main page or any category. Do not link it from customer-facing pages.</div>

= Developing Model 204 from WSL (internal) =

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

{| class="wikitable"
! Command !! Purpose
|-
| <code>make204</code> || Incrementally assemble Model 204 and link CMS and z/OS modules
|-
| <code>emu204</code> || Run the real linked Model 204 module on the workstation
|-
| <code>testM204Qa</code> || Start Model 204 under <code>emu204</code> and run a QA smoke test
|-
| <code>prezap</code> || Create the header for a new maintenance ZAP
|-
| <code>scanzap</code> || Find the next available local and <code>PTCH$</code> patch offsets
|-
| <code>bldzap</code> || Compare two object decks and generate VER/REP statements
|-
| <code>putmod</code> / <code>putmodzos</code> || 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 <code>~/gitm204</code> and <code>~/m204-80</code>, rather than under <code>/mnt/c</code>. 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:

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

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

Verify the installation:

<pre>
make204 --help
emu204 --help
testM204Qa --help
type -a make204 emu204 testM204Qa prezap scanzap
</pre>

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

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

== Repositories ==

The two repositories have different purposes:

* <code>~/gitm204</code> contains the build tools, assembler, linker, emulator, and their tests.
* <code>~/m204-80</code> 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 <code>m204-80</code>, because the tools derive the release and CMS disk names from it.

Before beginning a change:

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

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

== First build and CMS libraries ==

From the Model 204 repository root:

<pre>
cd ~/m204-80
make204 --no-zap
</pre>

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

On WSL, the tools can offer to install and configure <code>gnome-keyring</code> and <code>libsecret-tools</code> 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 <code>.m204libs</code>. If a fetch was interrupted, <code>make204</code> 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 <code>src/</code>. Build outputs are ignored by Git:

{| class="wikitable"
! Directory !! Contents
|-
| <code>obj/</code> || Baseline object decks and linked modules
|-
| <code>lst/</code> || Baseline assembly listings
|-
| <code>ref/</code> || Baseline dependency information
|-
| <code>zapobj/</code> || ZAP-build objects, per-module ZAPs, and linked modules
|-
| <code>zaplst/</code> || ZAP-build listings
|-
| <code>zapref/</code> || ZAP-build dependency information
|}

A typical edit/build loop is:

<pre>
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
</pre>

Useful options:

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

<code>make204 MODULE</code> 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:

<pre>
less lst/MODULE.LST80
</pre>

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

== Testing a normal module under emu204 ==

<code>emu204</code> 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:

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

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

Run the <code>make204 --no-zap</code> 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. <code>testM204Qa</code> 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:

<pre>
emu204 --config=/path/to/emu204.jsonc
emu204 --help
emu204 --help=config
emu204 --help=em
</pre>

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 <code>#</code> is an emulator command. A bare <code>#</code> stops the guest at the <code>EM></code> prompt; <code>BEGIN</code> resumes it.

== ZAP-maintenance workflow ==

=== 1. Refresh the unmodified baseline ===

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

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

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 <code><release>Z<PDS-number></code>:

<pre>
git switch -c 80Z9206
prezap
</pre>

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

=== 3. Check whether the target can be generated automatically ===

<code>SIRE2</code> and <code>EWDP</code> 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 <code>PTCH$</code>:

<pre>
scanzap SCOMP
scanzap SCOMP OTHERMOD
</pre>

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

=== 5. Build the ZAP ===

Use a clean ZAP directory for the first build:

<pre>
make204 --clear
</pre>

Subsequent builds can be incremental:

<pre>
make204
</pre>

In ZAP mode, <code>make204</code>:

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

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 <code>m204.jsonc</code>.

Review all three forms of the result:

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

=== 6. Prove the test and test the patched module ===

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

<pre>
putmod --no-zap
</pre>

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

Then upload the ZAP-applied build:

<pre>
make204 --zap
putmod --zap
</pre>

For z/OS:

<pre>
putmodzos --zap
</pre>

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

<pre>
putmod --no-zap
putmodzos --no-zap
</pre>

The standard <code>testM204Qa</code> command reads the normal object directory from <code>hlasm.jsonc</code> and therefore tests <code>obj/M204ONLN.MODULE</code>, not <code>zapobj/M204ONLN.MODULE</code>. 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 <code>emu204</code> configuration whose <code>module</code> 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 <code>git status --short</code> and stage source paths explicitly. Do not stage build output or unrelated files.

== Testing on CMS ==

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

The normal recycle is:

<pre>
EOJ
IPL CMS
</pre>

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:

<pre>
gitproc push qaproc
gitproc push m204proc
</pre>

== Working on the tools themselves ==

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

<pre>
cd ~/gitm204
npm install
npx make
npm test
</pre>

Useful narrower checks are:

<pre>
npm run testci
npm run testmake
npm run testm204
npm run testm204qa
</pre>

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

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

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

== Troubleshooting ==

{| class="wikitable"
! Symptom !! Action
|-
| <code>make204</code> is not found || Reinstall <code>@rocket/m204-tools</code>, run <code>hash -r</code>, and inspect <code>type -a make204</code>.
|-
| <code>emu204</code> says its Linux platform package is missing || Reinstall without <code>--no-optional</code> or <code>--ignore-scripts</code>; check for an older command earlier on PATH.
|-
| Hundreds of unknown assembler operations || The macro libraries are probably absent or half-fetched. Run <code>getmaclib --direct</code>, then rebuild.
|-
| Linker reports unresolved LE symbols || Fetch the required object library with <code>getobjlib --direct</code>.
|-
| 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 <code>make204 --no-zap</code>.
|-
| QA run has a nonzero return code || Read the <code>testM204Qa</code> verdict. The Model 204 return code is not the pass/fail result.
|-
| Need more emulator detail || Use <code>emu204 --help</code>, <code>emu204 --help=config</code>, and <code>emu204 --help=em</code>.
|}

== Source references ==

* <code>gitm204/BUILD.md</code>
* <code>gitm204/em204/README.md</code>
* <code>m204-80/DEVELOPMENT.md</code>
* <code>m204-80/ZAP-WORKFLOW.md</code>
* <code>m204-80/.github/skills/building.md</code>
* <code>m204-80/.github/skills/testing.md</code>

Internal:Creating authorization keys

Tom — Tue, 03 Nov 2026 22:21:01 GMT

← Older revision		Revision as of 22:21, 3 November 2026
Line 15:		Line 15:

	== Step 1: Get the CPU ID from the customer ==		== Step 1: Get the CPU ID from the customer ==
	~~Only~~ the '''~~rightmost~~ 8 ~~or 10 hexadecimal characters~~''' of the ~~CPU ID are used~~.		The authorization code uses only the '''8-hex-digit CPU serial number'''. The surrounding bytes are ignored: the leading <code>FF</code>/<code>00</code> flag, the following LPAR byte (for example <code>04</code>), and the trailing four digits. The LPAR is not inspected by the authorization code.

	{\| class="wikitable"		{\| class="wikitable"
	! System !! Command !! Example response !! Value to use		! System !! Command !! Example response !! Value to use
	\|-		\|-
	\| z/VM \|\| <code>CP Q CPUID</code> (from the virtual machine that will run the products) \|\| <code>CPUID = FF04686420030000</code> \|\| <code>~~6420030000~~</code> or <code>~~20030000~~</code>		\| z/VM \|\| <code>CP Q CPUID</code> (from the virtual machine that will run the products) \|\| <code>CPUID = FF04686420030000</code> \|\| <code>68642003</code> (<code>FF</code> flag, <code>04</code> LPAR, serial, <code>0000</code>)
	\|-		\|-
	\| z/OS (MVS, OS/390) \|\| <code>D M=CPU</code> (operator or SDSF console with command authority) \|\| SERIAL column: <code>0468642003</code> \|\| <code>~~0468642003~~</code>		\| z/OS (MVS, OS/390) \|\| <code>D M=CPU</code> (operator or SDSF console with command authority) \|\| SERIAL column: <code>0468642003</code> \|\| <code>68642003</code> (the leading <code>04</code> LPAR prefix may be omitted)
			\|-
			\| z/VSE \|\| <code>SIR</code> command \|\| <code>AR 0015 CPUID VM = 00379B7891758000 VSE = FF379B7891758000</code> \|\| <code>9B789175</code> (use either the VM or VSE value; <code>37</code> is the LPAR)
	\|}		\|}

	~~CPU IDs must be~~ 8 or 10 hex digits. A 10-digit ID is compared to existing customers using its rightmost 8 digits.		The maintenance site accepts 8 or 10 hex digits. A 10-digit value (LPAR byte plus serial, as z/OS shows it) is compared to existing customers using its rightmost 8 digits, so entering the 8-digit serial is simplest.

	== Step 2: Find or add the customer ==		== Step 2: Find or add the customer ==

Internal:Creating authorization keys

Tom — Tue, 03 Nov 2026 22:12:12 GMT

Created page with "__NOINDEX__ __NOTOC__ <div style="border:1px solid #c00; padding:6px;">'''Internal use only.''' This page is intentionally not linked from the main page or any category. Do not link it from customer-facing pages.</div> = Creating Model 204 authorization keys (internal) = Model 204 products are licensed per CPU. An authorization key (also called an ''authorization zap'' or ''AUTH zap'') is generated on demand by the Rocket maintenance subsystem (the <code>maint</code> p..."

New page

__NOINDEX__
__NOTOC__
<div style="border:1px solid #c00; padding:6px;">'''Internal use only.''' This page is intentionally not linked from the main page or any category. Do not link it from customer-facing pages.</div>

= Creating Model 204 authorization keys (internal) =

Model 204 products are licensed per CPU. An authorization key (also called an ''authorization zap'' or ''AUTH zap'') is generated on demand by the Rocket maintenance subsystem (the <code>maint</code> procedures) and identifies the CPU serial number(s), the start and end dates, the products, and, for thread-based products, the maximum thread count.

Keys are not created by hand. They are built by the maintenance subsystem when an authorized user requests one, either from the web or by e-mail.

== Before you start ==
* You need a maintenance-site login (userid) with access to the customer. Access is checked against the customer nickname; a user who is not authorized for the nickname receives a "401 Unauthorized" response.
* The customer must already exist in the maintenance database (customer record, type ''C'') with its licensed products. To add a new customer, use the ''Add a Customer / Provide CPU IDs'' page (<code>cust1</code>).
* You need the customer's CPU ID(s).

== Step 1: Get the CPU ID from the customer ==
Only the '''rightmost 8 or 10 hexadecimal characters''' of the CPU ID are used.

{| class="wikitable"
! System !! Command !! Example response !! Value to use
|-
| z/VM || <code>CP Q CPUID</code> (from the virtual machine that will run the products) || <code>CPUID = FF04686420030000</code> || <code>6420030000</code> or <code>20030000</code>
|-
| z/OS (MVS, OS/390) || <code>D M=CPU</code> (operator or SDSF console with command authority) || SERIAL column: <code>0468642003</code> || <code>0468642003</code>
|}

CPU IDs must be 8 or 10 hex digits. A 10-digit ID is compared to existing customers using its rightmost 8 digits.

== Step 2: Find or add the customer ==
# Sign on to the maintenance site.
# To check whether a CPU already belongs to a customer, use ''Add a Customer / Provide CPU IDs'' and enter the CPU ID. If it matches an existing customer, you are redirected to that customer's page (<code>dlist?nickname=...</code>); otherwise you can add a new customer.
# Confirm the customer record: nickname, company, operating system, distributor, and the CPU list. Mark test or inactive customers with ''Inactive or Test Client?''.

== Step 3: Request the key ==
# From the customer's page (<code>dlist</code>), choose ''Download authorization keys'' (<code>authlist?nickname=<i>nickname</i></code>).
# Select the key to build:
#* '''All Authorized Products''' (prefix <code>ALL</code>), which is the normal choice, or
#* a single product, if the customer needs only that one.
# Enter the TCP/IP address (<code>tcpaddr</code>) or e-mail address that should receive the key. ''Email'' links send the key to the address on the customer record.
# Click the download or e-mail link.

Behind the scenes, the web procedure (<code>MAINTP_DOWNLOAD</code>, action <code>GETAUTH</code>) submits a background request of the form:

<pre>AUTH <i>procname</i> <i>prefix</i>AUTH <i>nickname</i> FOR <i>userid</i> [DR <i>cpu</i>[,<i>cpu</i>...]] [DRSTART <i>yyyymmdd</i>]</pre>

The background job builds a temporary procedure named <code>AUTH<i>userid</i>.<i>time</i></code>, and the web procedure waits (up to about 100 seconds) for it, then sends it back. The temporary procedures are deleted on the next request by the same user.

== Disaster Recovery (DR) keys ==
A DR key adds temporary authorization for additional CPUs, on top of the CPUs already licensed.
* Enter one or more CPU IDs (8 to 10 hex digits each, separated by commas or blanks) and a start date.
* The start date must be valid, not more than 30 days in the past, and not more than one year in the future. The key is valid for the DR window starting on that date.
* Each customer has a '''DR zap limit''' (<code>DRLIMIT</code>) and a running count (<code>DRCOUNT</code>). If the count would exceed the limit, the request is rejected with "DR ZAP limit ... has been reached, contact Rocket support." To grant more, raise ''Maximum number of DR zaps allowed'' on the customer page.
* The customer page records the start date and CPUs of the most recent DR zap.

== Troubleshooting ==
{| class="wikitable"
! Message !! Meaning / action
|-
| Unauthorized - User ''x'' / Customer ''x'' is not authorized || The userid has no access to that customer nickname. Fix the userid's access.
|-
| CPU ID (...) must be between 8 and 10 hex digits || Bad DR CPU ID. Re-enter it.
|-
| Disaster Recovery test start date is invalid / too old / too far in the future || Correct the DR start date.
|-
| DR ZAP limit ... has been reached || See Disaster Recovery above.
|-
| Not found - No authorization zaps called ... || The key procedure is missing for that product prefix.
|-
| Internal server error - can't build authorization zap || The background build did not finish or returned a result smaller than 500 bytes. Check the maintenance daemon and retry; otherwise escalate.
|}

== Source reference ==
Repository <code>gitm204/maint</code>:
* <code>MAINTP_OBJLIST</code>: the ''Download authorization keys'' page (<code>authlist</code>)
* <code>MAINTP_DOWNLOAD</code>: request validation, DR checks, and the <code>AUTH</code> background request (<code>authSend</code>)
* <code>MAINTP_CUST1</code>: customer maintenance, CPU entry and matching, DR limit fields
* <code>MAINTN_START</code>: routing of the <code>authlist</code> image

M204wiki:Database download

Tom — Mon, 02 Nov 2026 16:47:34 GMT

Show changes

M204.2020

JDamon — Thu, 29 Oct 2026 16:26:49 GMT

← Older revision		Revision as of 16:26, 29 October 2026
Line 1:		Line 1:
	{{Template:M204.2020 skeleton}}		{{Template:M204.2020 skeleton}}

			<p class="code">
			The two possible forms of the message are:

			M204.2020: FILE filename; DDNAME not found, OPEN command rejected
			M204.2020: FILE filename; Unsupported device type, OPEN command rejected

			</p>
	<P>		<P>
	The Model 204 file could not be opened due to the condition indicated in the message.</P>		The Model 204 file could not be opened due to the condition indicated in the message.</P>

Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)

Snehal — Mon, 19 Oct 2026 16:06:02 GMT

AUDIT204 utility

← Older revision		Revision as of 16:06, 19 October 2026
Line 1,138:		Line 1,138:
	</tr>		</tr>
	</table>		</table>

			===AUDIT204 And Journal Version Compatibility===

			* The AUDIT204 utility can process only journals that were created by its own release or by a limited range of earlier releases.
			* The Model 204 V7.9 AUDIT204 utility is backward compatible only to V7.8. It can process journals and audit trails created by V7.8 and V7.9. It cannot process those created by V7.7 or earlier, and it rejects them with a message that the journal version is not supported.
			* To report on a journal or audit trail created by an earlier release, use the AUDIT204 utility from the release that created it. For example, use the V7.7 AUDIT204 utility to process V7.7 journals.

			'''Note:''' After you upgrade, keep the previous release's Model 204 libraries until you no longer need to analyze journals created under that release. Alternatively, produce and save the audit reports for those journals before you retire the previous release.

	===Input to AUDIT204===		===Input to AUDIT204===
	<p>		<p>

Release notes for Model 204 version 8.0

JDamon — Thu, 15 Oct 2026 22:43:52 GMT

SUBSYSMGMT and DICTADMIN without preauthorization

← Older revision		Revision as of 22:43, 15 October 2026
(One intermediate revision by the same user not shown)
Line 141:		Line 141:

	===SUBSYSMGMT and DICTADMIN without preauthorization===		===SUBSYSMGMT and DICTADMIN without preauthorization===
	System managers can now use the <var>SUBSYSMGMT</var> and <var>DICTADMIN</var> subsystems without being separately preauthorized for them.		System managers can now use the <var>SUBSYSMGMT</var> and <var>DICTADMIN</var> subsystems without being separately preauthorized for them. This feature requires APSYSEC=1 be set in CCAIN during initialization.

	==Performance enhancements==		==Performance enhancements==