|
|
| Line 1: |
Line 1: |
| __NOINDEX__ | | __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> | | <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> |
|
| |
|
| __TOC__
| | = Creating Model 204 authorization keys (internal) = |
|
| |
|
| = Developing Model 204 from WSL or macOS (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. |
|
| |
|
| The <code>@rocket/m204-tools</code> package makes it possible to edit, assemble, link, patch, and test Model 204 from WSL or macOS. The main commands are:
| | 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. |
|
| |
|
| {| class="wikitable"
| | == Before you start == |
| ! Command !! Purpose
| | * 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>). |
| | [[#Building with make204|<code>make204</code>]] || Incrementally assemble Model 204 and link CMS and z/OS modules
| | * You need the customer's CPU ID(s). |
| |-
| |
| | [[#Running and testing under emu204|<code>emu204</code>]] || Run the real linked Model 204 module on the workstation
| |
| |-
| |
| | [[#Automated smoke test with testM204Qa|<code>testM204Qa</code>]] || Start Model 204 under <code>emu204</code> and run a QA smoke test
| |
| |-
| |
| | [[#Create the maintenance branch with prezap|<code>prezap</code>]] || Create the header for a new maintenance ZAP
| |
| |-
| |
| | [[#Find patch space with scanzap|<code>scanzap</code>]] || Find the next available local and <code>PTCH$</code> patch offsets
| |
| |-
| |
| | [[#Build the ZAP with make204 and bldzap|<code>bldzap</code>]] || Compare two object decks and generate VER/REP statements
| |
| |-
| |
| | [[#Testing on CMS with putmod|<code>putmod</code>]] || Upload a linked CMS module and map for mainframe testing
| |
| |-
| |
| | [[#Testing on z/OS with putmodzos and gitzosl|<code>putmodzos</code>]] || Upload the z/OS object deck that the z/OS binder uses to create the test load module
| |
| |-
| |
| | [[#Running a local Online with Janus TNSERV|<code>c3270</code> / <code>s3270</code>]] || Connect directly to a Janus Telnet Server running under <code>emu204</code>
| |
| |}
| |
| | |
| This page describes the Model 204 8.0 and 8.1 workflows. Release 8.0 is under '''ZAP maintenance''', so its baseline and ZAP objects must be kept separate. Release 8.1 is under normal development and currently builds directly into <code>obj/</code>.
| |
| | |
| == 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 <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.
| |
| | |
| 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 <code>PATH</code>.
| |
| | |
| The CMS and z/OS passwords are stored in the macOS Keychain. No Linux keyring setup is needed.
| |
| | |
| The upload commands invoke an <code>ftp</code> command-line client. Modern macOS does not supply one, so verify <code>command -v ftp</code>. If it is absent, install a compatible client such as <code>tnftp</code> with Homebrew.
| |
| | |
| === Install the tools ===
| |
| | |
| On either platform, 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 the shell finds a mixture of commands under <code>/usr/local/bin</code>, an nvm directory, a Homebrew prefix, 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>.
| |
| | |
| 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.
| |
| | |
| == 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 ZAP-maintained Model 204 8.0 source.
| |
| * <code>~/m204-81</code> contains the Model 204 8.1 development source. | |
| | |
| The Model 204 directory name matters. It must end in the two-digit release, such as <code>m204-80</code> or <code>m204-81</code>, because the tools derive the release and CMS disk names from it. | |
| | |
| Before beginning a change:
| |
| | |
| <pre>
| |
| cd ~/m204-81
| |
| 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-81
| |
| make204 --force
| |
| </pre>
| |
| | |
| For 8.0, use <code>make204 --no-zap</code> to create the baseline instead. 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 workstation 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. On macOS, they use the system Keychain.
| |
| | |
| 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. An older tree that already has populated libraries but no note is accepted as-is. A large number of unknown assembler operations usually means that the macro library is incomplete.
| |
| | |
| == Building with make204 ==
| |
| | |
| 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:
| | == Step 1: Get the CPU ID from the customer == |
| | | 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. |
| <pre> | |
| cd ~/m204-81
| |
| | |
| # 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" | | {| class="wikitable" |
| ! Option !! Meaning | | ! System !! Command !! Example response !! Value to use |
| |-
| |
| | <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 | | | 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>) |
| |- | | |- |
| | <code>--errMax=0</code> || Continue after assembly failures instead of stopping at the first one | | | 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) |
| |- | | |- |
| | <code>--clear</code> || Empty the selected build directories before building | | | 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) |
| |} | | |} |
|
| |
|
| <code>make204 MODULE</code> names an input source, not necessarily an output object. For example, one input may produce more than one output module.
| | 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. |
| | |
| Review the corresponding listing after an assembly:
| |
| | |
| <pre>
| |
| less lst/MODULE.LST80
| |
| </pre>
| |
| | |
| The default is controlled by <code>m204.jsonc</code>: | |
| | |
| * 8.0 has <code>"zap": true</code>. A bare <code>make204</code> builds under <code>zapobj/</code>; use <code>--no-zap</code> for the baseline.
| |
| * 8.1 has <code>"zap": false</code>. A bare <code>make204</code> builds normally under <code>obj/</code>.
| |
| | |
| On the WSL test machine, <code>make204 --force</code> for 8.1 assembled the complete tree with no assembler warnings or errors and linked both <code>M204ONLN.MODULE</code> and <code>M204ONLN.ZOSMOD</code>. A second bare <code>make204</code> correctly reported every module up to date and skipped the link.
| |
| | |
| The current 8.1 link prints warnings that no object was found for EVCP and that RSQL was not found in the search path. The link still succeeds. Treat additional missing objects or unresolved externals as errors rather than assuming every linker warning is expected.
| |
| | |
| == Running and testing under emu204 ==
| |
| | |
| <code>emu204</code> runs the real z/OS Model 204 module locally. It is not a source-level reimplementation of Model 204.
| |
| | |
| === Automated smoke test with testM204Qa ===
| |
| | |
| The simplest supported baseline smoke test is:
| |
| | |
| <pre>
| |
| cd ~/m204-81
| |
| make204
| |
| testM204Qa --tree="$HOME/m204-81"
| |
| </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.
| |
| | |
| For 8.0, substitute <code>m204-80</code> and build the unmodified baseline with <code>make204 --no-zap</code>. Do not run <code>--no-zap</code> on an 8.0 ZAP branch: it would replace the baseline objects with 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.
| |
| | |
| The 8.1 run on 5 November 2026 completed successfully with 647 tests reported passed. Model 204 ended with return code 32, which <code>testM204Qa</code> correctly identified as expected.
| |
| | |
| Two messages from that run were informational:
| |
| | |
| * <code>MSIR.1097</code> reported that DFLTCC hardware compression was unavailable under the emulator.
| |
| * Two <code>m204proc</code> filenames differed only in case and both folded to procedure <code>CA_DIGICERTGLOBALROOTCA</code>; <code>emu204</code> reported the collision and ignored the second.
| |
| | |
| When run from an installed tool package, <code>testM204Qa</code> creates <code>m204qa/out/</code> beside the Model 204 tree. In the current 8.1 tree the containing <code>m204qa/</code> directory is not ignored, so <code>git status</code> shows it as untracked after the test. Remove it after preserving any print, audit, or SNAP files needed for diagnosis.
| |
| | |
| === Building an emu204 case ===
| |
| | |
| For an interactive or specialized run, create a directory containing an <code>emu204.jsonc</code> configuration, CCAIN, and any files used by the run:
| |
| | |
| <pre>
| |
| mkdir -p ~/em204-cases/mycase/{files,out}
| |
| cd ~/em204-cases/mycase
| |
| vi emu204.jsonc
| |
| vi ccain.txt
| |
| emu204
| |
| </pre>
| |
| | |
| 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.
| |
| | |
| The complete reference is:
| |
| | |
| <pre>
| |
| emu204 --help
| |
| emu204 --help=config
| |
| emu204 --help=em
| |
| </pre>
| |
| | |
| A useful starting configuration is:
| |
| | |
| <pre>
| |
| {
| |
| "module": "/home/user/m204-81/obj/M204ONLN.MODULE",
| |
| "lst": "/home/user/m204-81/lst",
| |
| "cpuid": "FF379B789175",
| |
| "jobName": "EMU204ON",
| |
| "parm": "SYSOPT=X'A0',LIBUFF=3072,LOBUFF=7168,SIRFUNC=X'01',SIRTUNE=0",
| |
| "storage": "2G",
| |
| | |
| "dd": {
| |
| "SITEPARM": {"path": "siteparm.txt"},
| |
| "CCAIN": {"path": "ccain.txt"},
| |
| "CCAPRINT": {"path": "out/ccaprint.txt"},
| |
| "CCAAUDIT": {"path": "out/ccaaudit.txt"},
| |
| "CCASNAP": {
| |
| "path": "out/ccasnap.txt",
| |
| "sequence": true,
| |
| "cc": true
| |
| },
| |
| "CCASTAT": {
| |
| "path": "out/ccastat.binary",
| |
| "blocked": true
| |
| }
| |
| },
| |
| | |
| "ddDirs": [
| |
| {"path": "files", "suffix": "M204FILE", "m204file": true}
| |
| ]
| |
| }
| |
| </pre>
| |
| | |
| Change the module path to <code>zapobj/M204ONLN.MODULE</code> when the purpose of the case is to test a ZAP-linked module.
| |
| | |
| === Identity and authorization ===
| |
| | |
| <code>cpuid</code> is the twelve hexadecimal digits reported by the emulated machine. Model 204 checks it against the authorization in the module, so it must be a CPU ID authorized by the development key.
| |
| | |
| <code>jobName</code> becomes the name in the TIOT header. A bare <code>LOGIN</code> is trusted as this user, so the name must exist in CCASTAT. If the configured CCASTAT path does not exist, <code>emu204</code> creates a minimal table containing the configured job name. This is normally simpler than copying a password table from a mainframe.
| |
| | |
| If a real CCASTAT is used, download it with FTP block-mode framing intact and specify <code>"blocked": true</code>. A plain binary byte stream cannot preserve the record boundaries of its undefined-format records.
| |
| | |
| === EXEC PARM, SYSOPT, and CCAIN ===
| |
| | |
| The configuration's <code>parm</code> value is the EXEC PARM presented when Model 204 is entered. It is where user-zero parameters such as SYSOPT, LIBUFF, and LOBUFF are normally supplied:
| |
| | |
| <pre>
| |
| "parm": "SYSOPT=X'A0',LIBUFF=3072,LOBUFF=7168,SIRFUNC=X'01',SIRTUNE=0"
| |
| </pre>
| |
| | |
| For the development cases:
| |
| | |
| * SYSOPT <code>X'80'</code> enables the audit trail.
| |
| * SYSOPT <code>X'20'</code> includes RK lines in the audit trail.
| |
| * <code>X'A0'</code> enables both.
| |
| * Do not add <code>X'02'</code> unless CCAGRP is allocated.
| |
| * Do not add <code>X'01'</code> unless CCASYS is already available during initialization.
| |
| * A security configuration requiring login must agree with the supplied CCASTAT and CCAIN login commands.
| |
| | |
| CCAIN is ordinary workstation text. <code>emu204</code> translates it to EBCDIC and pads it to 80-byte card images. Model 204 reads only through column 72; a continued parameter line ends with a dash '''in column 72''', after padding with blanks. A dash that follows the last comma directly, or that sits earlier in the line, is not recognized as a continuation: Model 204 fails with <code>M204.1122: Invalid parameter = -</code>.
| |
| | |
| A small CCAIN might be (each line ending in a dash is padded so that the dash is in column 72):
| |
| | |
| <pre>
| |
| HDRCTL=3,LVTBL=60000,LNTBL=18000,LSTBL=480000, -
| |
| NFILES=200,NDCBS=200,NDIR=200,PAGESZ=6184,SPCORE=120000, -
| |
| TEMPPAGE=20000,OUTMRL=80,NSERVS=8,SERVSIZE=5000000
| |
| LOGIN
| |
| OPEN M204PROC
| |
| OPEN QAPROC
| |
| I QARUN MYTEST*
| |
| EOJ
| |
| </pre>
| |
| | |
| Use <code>TEMPPAGE</code> when an in-memory CCATEMP is sufficient. If the test specifically needs a disk-backed CCATEMP, allocate it as an <code>m204file</code> with <code>new</code> and <code>pages</code> instead.
| |
| | |
| === Allocating existing Model 204 files ===
| |
| | |
| An <code>m204file</code> is a flat, untranslated sequence of 6184-byte Model 204 pages. For one file:
| |
| | |
| <pre>
| |
| "PAYROLL": {
| |
| "path": "files/PAYROLL.M204FILE",
| |
| "m204file": true
| |
| }
| |
| </pre>
| |
| | |
| The DDNAME is the JSON key (<code>PAYROLL</code>). For an existing file, omit <code>pages</code>; the allocated size is inferred from the number of pages in the host file.
| |
| | |
| To allocate every appropriately named file in a directory:
| |
| | |
| <pre>
| |
| "ddDirs": [
| |
| {
| |
| "path": "files",
| |
| "suffix": "M204FILE",
| |
| "m204file": true
| |
| }
| |
| ]
| |
| </pre>
| |
| | |
| With this form, <code>files/PAYROLL.M204FILE</code> becomes DDNAME <code>PAYROLL</code>. The portion before the suffix must be a valid one-to-eight-character DDNAME. Files with the wrong suffix case or invalid DDNAMEs are reported rather than silently used.
| |
| | |
| The maximum number of pages available to an existing file is its host-file size divided by 6184. Verify a transferred page image before running:
| |
| | |
| <pre>
| |
| bytes=$(wc -c < files/PAYROLL.M204FILE)
| |
| test $((bytes % 6184)) -eq 0 && echo "$((bytes / 6184)) pages" ||
| |
| echo "not a whole number of Model 204 pages"
| |
| </pre>
| |
| | |
| === Creating a new or scratch Model 204 file ===
| |
| | |
| For a persistent file that does not exist yet, provide its extent with <code>pages</code>:
| |
| | |
| <pre>
| |
| "NEWDATA": {
| |
| "path": "files/NEWDATA.M204FILE",
| |
| "m204file": true,
| |
| "pages": 1000
| |
| }
| |
| </pre>
| |
| | |
| The host file is created when Model 204 opens it. CCAIN must still issue the normal Model 204 CREATE, OPEN, and INITIALIZE commands. Do not specify <code>new</code> for a persistent database file: <code>new</code> empties the host file at the first open of every emulator run.
| |
| | |
| For deliberately disposable storage:
| |
| | |
| <pre>
| |
| "CCATEMP": {
| |
| "path": "out/ccatemp.pages",
| |
| "m204file": true,
| |
| "new": true,
| |
| "pages": 5000
| |
| }
| |
| </pre>
| |
| | |
| This is suitable for CCATEMP or a test file that must start empty on every run.
| |
| | |
| === Getting files from CMS or z/OS ===
| |
| | |
| <code>emu204</code> does not log on to CMS or z/OS and fetch database files itself. Put the required files in the case directory before starting it.
| |
| | |
| For a physical z/OS Model 204 data set, download it in binary mode with no character translation. The resulting workstation file must be only the concatenated 6184-byte pages:
| |
| | |
| <pre>
| |
| ftp zos-host
| |
| binary
| |
| get 'HLQ.PAYROLL' files/PAYROLL.M204FILE
| |
| quit
| |
| </pre>
| |
| | |
| FTP command syntax and quoting vary by client. After the transfer, verify that the byte count is a multiple of 6184. Do not mark a page image <code>blocked</code>; <code>blocked</code> is for record-oriented files transferred with FTP block-mode framing, not Model 204 database pages.
| |
| | |
| CMS Model 204 files may be on direct-access minidisks rather than represented as ordinary CMS files. Such a file cannot simply be fetched by CMS filename. Use the site's normal utility to make either:
| |
| | |
| * a physical sequential page image that can be downloaded without translation; or
| |
| * a Model 204 DUMP data set, which can be restored into a newly allocated local <code>m204file</code>.
| |
| | |
| The same dump-and-restore method works when direct access to a z/OS data set is unavailable.
| |
| | |
| If the dump data set was downloaded with FTP <code>MODE B</code>, preserve its record framing:
| |
| | |
| <pre>
| |
| "PAYDUMP": {
| |
| "path": "files/PAYROLL.DUMP",
| |
| "blocked": true
| |
| },
| |
| "PAYROLL": {
| |
| "path": "files/PAYROLL.M204FILE",
| |
| "m204file": true,
| |
| "pages": 10000
| |
| }
| |
| </pre>
| |
| | |
| The target extent must be large enough for the restored file. The CCAIN stream can then create and initialize the target and restore the dump DD:
| |
| | |
| <pre>
| |
| CREATE FILE (NOFORMAT) PAYROLL
| |
| END
| |
| OPEN FILE PAYROLL
| |
| IN FILE PAYROLL INITIALIZE
| |
| OPEN PAYROLL
| |
| IN FILE PAYROLL RESTORE 192 FROM PAYDUMP
| |
| </pre>
| |
| | |
| Use the site's established DUMP options and restore page size; <code>192</code> above is the value used by current Model 204 QA restore procedures, not a universal replacement for the source environment's dump procedure.
| |
| | |
| === Using procedure directories ===
| |
|
| |
|
| Source-controlled procedure directories can be presented as read-only Model 204 procedure files without exporting a binary procedure file:
| | == 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?''. |
|
| |
|
| <pre> | | == Step 3: Request the key == |
| "M204PROC": {
| | # From the customer's page (<code>dlist</code>), choose ''Download authorization keys'' (<code>authlist?nickname=<i>nickname</i></code>). |
| "path": "/home/user/m204-81/m204proc",
| | # Select the key to build: |
| "procDir": true
| | #* '''All Authorized Products''' (prefix <code>ALL</code>), which is the normal choice, or |
| },
| | #* a single product, if the customer needs only that one. |
| "QAPROC": {
| | # 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. |
| "path": "/home/user/m204-81/qaproc",
| | # Click the download or e-mail link. |
| "procDir": true
| |
| }
| |
| </pre>
| |
|
| |
|
| Each host file becomes one procedure, with its filename folded to upper case. Subdirectories are searched and flattened. Duplicate procedure names are reported. The procedure image is rebuilt when Model 204 opens the file, so host edits are seen after every user has closed the procedure file and it is opened again.
| | Behind the scenes, the web procedure (<code>MAINTP_DOWNLOAD</code>, action <code>GETAUTH</code>) submits a background request of the form: |
|
| |
|
| === Output files and interactive control ===
| | <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> |
|
| |
|
| Text DDs such as CCAPRINT and CCAAUDIT are written as readable workstation text. Use <code>"sequence": true</code> for CCASNAP so that each open produces <code>ccasnap1.txt</code>, <code>ccasnap2.txt</code>, and so on instead of replacing the preceding dump.
| | 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. |
|
| |
|
| 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. Use <code>#HELP</code> or <code>emu204 --help=em</code> for display, traceback, trap, trace, and profiling commands.
| | == Disaster Recovery (DR) keys == |
| | | A DR key adds temporary authorization for additional CPUs, on top of the CPUs already licensed. |
| == ZAP-maintenance workflow == | | * 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. |
| === Refresh the unmodified baseline ===
| | * 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. |
| 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.
| |
| | |
| === Create the maintenance branch with prezap ===
| |
| | |
| 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.
| |
| | |
| === 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.
| |
| | |
| === Find patch space with scanzap ===
| |
| | |
| 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>.
| |
| | |
| === Build the ZAP with make204 and bldzap ===
| |
| | |
| 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>
| |
| | |
| === 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, upload the ZAP-build object deck:
| |
| | |
| <pre>
| |
| putmodzos --zap
| |
| </pre>
| |
| | |
| Run the z/OS bind described below, 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. | |
| | |
| === 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 with putmod ==
| |
| | |
| <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>
| |
| | |
| == Testing on z/OS with putmodzos and gitzosl ==
| |
| | |
| The workstation linker produces a concatenated, fixed-80-byte z/OS object deck:
| |
| | |
| * baseline: <code>obj/M204ONLN.ZOSMOD</code>
| |
| * ZAP build: <code>zapobj/M204ONLN.ZOSMOD</code> | |
| | |
| <code>putmodzos</code> uploads that object deck to the PDSE member named by <code>zos.jsonc</code>. It does '''not''' create the executable z/OS load module by itself. The <code>gitzosl</code> job on the Builder runs the z/OS binder and creates the test load module.
| |
| | |
| === Configuration ===
| |
| | |
| The Model 204 tree needs <code>zos.jsonc</code> containing the z/OS FTP host, userid, object library, and member:
| |
| | |
| <pre>
| |
| {
| |
| "host": "...",
| |
| "user": "...",
| |
| "objlib": "...",
| |
| "member": "..."
| |
| }
| |
| </pre>
| |
| | |
| Do not put the password in this file. <code>putmodzos</code> obtains it from the workstation credential store, prompting on first use.
| |
| | |
| === Build and upload ===
| |
| | |
| For an unpatched baseline test:
| |
| | |
| <pre>
| |
| cd ~/m204-80
| |
| make204 --no-zap
| |
| putmodzos --no-zap
| |
| </pre>
| |
| | |
| For a ZAP-maintenance test:
| |
| | |
| <pre>
| |
| make204 --zap
| |
| putmodzos --zap
| |
| </pre>
| |
| | |
| The upload is binary into an FB 80 PDSE member. If <code>putmodzos</code> says the object deck is missing, run <code>make204</code> first and confirm that the selected <code>obj/</code> or <code>zapobj/</code> directory contains <code>M204ONLN.ZOSMOD</code>.
| |
| | |
| === Bind on z/OS ===
| |
| | |
| On the Builder, run:
| |
| | |
| <pre>
| |
| gitzosl
| |
| </pre>
| |
| | |
| The submitted job deletes the prior test load module, compresses the test load library, binds <code>M204ONLN</code> with IEWL, and applies the required ZAPs. Its output returns to the Builder's virtual reader through RSCS/NJE.
| |
| | |
| Use <code>rl</code> (RDRLIST), then PF11 to inspect the job output. A successful bind includes:
| |
| | |
| <pre>
| |
| $HASP395 ONLINE ENDED - RC=0000
| |
| </pre>
| |
| | |
| 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:
| |
| | |
| <pre>
| |
| EOJ
| |
| xedit setup names a
| |
| </pre>
| |
| | |
| Change:
| |
| | |
| <pre>
| |
| :opsys.CMS
| |
| </pre>
| |
| | |
| to:
| |
| | |
| <pre>
| |
| :opsys.MVS
| |
| </pre>
| |
| | |
| The XEDIT command is:
| |
| | |
| <pre>
| |
| c/:opsys.CMS/:opsys.MVS/ *
| |
| file
| |
| </pre>
| |
| | |
| Leave <code>:tester.</code> set to the builder userid. It still selects the test version of <code>M204ONLN</code>.
| |
| | |
| === Start and test ===
| |
| | |
| Start with either a full CMS IPL or the configuration nickname:
| |
| | |
| <pre>
| |
| IPL CMS
| |
| </pre>
| |
| | |
| PROFILE EXEC builds and submits the startup JCL. The JES messages include receipt of the job and completion of the submission step with <code>MAXCC=0000</code>. 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 <code>ONLINE</code> message.
| |
| | |
| Connect from the normal user session:
| |
| | |
| <pre>
| |
| M204F suffix
| |
| LOGIN
| |
| OPEN QAPROC
| |
| I QARUN pattern
| |
| </pre>
| |
| | |
| 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 <code>SETUP NAMES</code>, and change:
| |
| | |
| <pre>
| |
| c/:opsys.MVS/:opsys.CMS/ *
| |
| file
| |
| </pre>
| |
| | |
| Then IPL CMS or start the configuration nickname again.
| |
| | |
| == Running a local Online with Janus TNSERV ==
| |
| | |
| A Janus port of type <code>TNSERV</code> supplies direct TN3270 access to a Model 204 Online. It does not use OMNI, SDS, OPENSERV, VTAM, or <code>IODEV=7</code>:
| |
| | |
| <pre>
| |
| c3270 or s3270
| |
| |
| |
| v
| |
| localhost:7777
| |
| |
| |
| v
| |
| Janus TNSERV in Model 204 under emu204
| |
| </pre>
| |
| | |
| The emulator's IUCV TCP/IP service turns the guest listener into a real workstation socket. The test described below was run successfully against the 8.1 module: <code>s3270</code> connected to port 7777, logged in, and <code>VIEW TNDEV</code> returned <code>TNDEV 21</code>.
| |
| | |
| === Install a TN3270 client ===
| |
| | |
| On Ubuntu or WSL:
| |
| | |
| <pre>
| |
| sudo apt update
| |
| sudo apt install c3270 s3270
| |
| </pre>
| |
| | |
| On macOS:
| |
| | |
| <pre>
| |
| brew install x3270
| |
| </pre>
| |
| | |
| Homebrew itself must be installed first; the macOS command-line tools do not provide it.
| |
| | |
| <code>c3270</code> is interactive. <code>s3270</code> accepts commands on standard input and is useful for repeatable tests. A plain line-oriented <code>telnet</code> client is not sufficient because TNSERV supports the TN3270 subset of Telnet.
| |
| | |
| === Build the local case ===
| |
| | |
| Create the case directory. It is not part of the repository or the npm package, so the files below are the complete case:
| |
| | |
| <pre>
| |
| mkdir -p ~/em204-cases/m204-81-tnserv/out
| |
| cd ~/em204-cases/m204-81-tnserv
| |
| </pre>
| |
| | |
| Its <code>emu204.jsonc</code> names the 8.1 module, sets <code>tcpVm</code> to the same <code>TCPIP</code> service-machine name used by Model 204, and supplies CCAIN, CCASTAT, audit, print, and snap DDs:
| |
| | |
| <pre>
| |
| {
| |
| "module": "/home/user/m204-81/obj/M204ONLN.MODULE",
| |
| "lst": "/home/user/m204-81/lst",
| |
| "cpuid": "FF379B789175",
| |
| "jobName": "ULSPFQA",
| |
| "tcpVm": "TCPIP",
| |
| "parm": "SYSOPT=X'A0',LIBUFF=3072,LOBUFF=7168,SIRFUNC=X'01',SIRTUNE=0",
| |
| "storage": "2G",
| |
| "dd": {
| |
| "CCAIN": {"path": "ccain.txt"},
| |
| "CCAPRINT": {"path": "out/ccaprint.txt"},
| |
| "CCAAUDIT": {"path": "out/ccaaudit.txt"},
| |
| "CCASTAT": {"path": "out/ccastat.binary", "blocked": true},
| |
| "CCASNAP": {"path": "out/ccasnap.txt", "sequence": true}
| |
| }
| |
| }
| |
| </pre>
| |
| | |
| On macOS use <code>/Users/<var>name</var>/m204-81</code> in the two paths. The <code>ccain.txt</code> is below. Each line ending in a dash must have that dash in column 72 (see above):
| |
| | |
| <pre>
| |
| HDRCTL=3,LVTBL=60000,LNTBL=18000,LSTBL=480000, -
| |
| NFILES=200,NDCBS=200,NDIR=200,PAGESZ=6184,SPCORE=120000, -
| |
| TEMPPAGE=20000,OUTMRL=80, -
| |
| NUSERS=8,SDAEMDEV=15,NSUBTKS=12,NSERVS=8, -
| |
| SIRTERM=3,TNDEV=21,SERVSIZE=5000000,MAXDAEM=5
| |
| IODEV=15,NOTERM=7,DUPTERM=6,LINEND=X'0D'
| |
| LOGIN
| |
| LOGCTL A TNUSER NOEXPIRE
| |
| M204TEST1,X'FF',HIGH
| |
| M204TEST1
| |
| ALL
| |
| JANUS DEFINE TNSERV 7777 TNSERV 5 WSFQUERY TCPKEEPALIVE -
| |
| BINDADDR 127.0.0.1
| |
| JANUS START TNSERV
| |
| HALT 48,MODEL 204 JANUS TELNET SERVER READY ON PORT 7777,3,EOD
| |
| EOD
| |
| HALT 33,ON-LINE USERS REQUESTED TO LOGOFF,3,EOJ
| |
| EOJ
| |
| </pre>
| |
| | |
| <code>TNDEV=21</code> enables Janus Telnet sessions. <code>SIRTERM</code> and <code>WSFQUERY</code> support terminal screen geometry. <code>TCPKEEPALIVE</code> is appropriate for long-lived terminal connections. <code>BINDADDR 127.0.0.1</code> keeps this known-password development port local to the workstation.
| |
| | |
| The <code>LOGCTL</code> dialogue creates a disposable local account because the minimal CCASTAT synthesized by <code>emu204</code> gives its automatic account an intentionally unknowable password. Change the example password if the case is used anywhere except an isolated development workstation.
| |
| | |
| The numbers before the two HALT messages are exact message lengths, not timeouts. An incorrect count causes User 0 to continue reading CCAIN and can immediately reach <code>EOJ</code>.
| |
| | |
| === Start the Online ===
| |
| | |
| The case's <code>run.sh</code> removes the generated CCASTAT so that <code>LOGCTL A TNUSER</code> can recreate the test account on every run:
| |
| | |
| <pre>
| |
| #!/bin/sh
| |
| cd "$(dirname "$0")" || exit 1
| |
| rm -f out/ccastat.binary
| |
| exec emu204
| |
| </pre>
| |
| | |
| <pre>
| |
| chmod +x run.sh
| |
| ./run.sh
| |
| </pre>
| |
| | |
| Keep standard input attached to the terminal: the operator replies to the HALT messages (see below) are read from it. Without a terminal, for example under <code>nohup</code>, give it a pipe that stays open, such as <code>sleep 600 | ./run.sh</code>.
| |
| | |
| Wait for:
| |
| | |
| <pre>
| |
| MODEL 204 JANUS TELNET SERVER READY ON PORT 7777
| |
| </pre>
| |
| | |
| From another terminal, confirm that the listener exists:
| |
| | |
| <pre>
| |
| nc -vz 127.0.0.1 7777
| |
| </pre>
| |
| | |
| === Connect and test ===
| |
| | |
| For an interactive session:
| |
| | |
| <pre>
| |
| c3270 127.0.0.1:7777
| |
| </pre>
| |
| | |
| At the Model 204 prompt, log in with the disposable account created by CCAIN and run a test command:
| |
| | |
| <pre>
| |
| LOGIN TNUSER
| |
| M204TEST1
| |
| VIEW TNDEV
| |
| </pre>
| |
| | |
| The password is entered in response to <code>M204.0347</code> and is not displayed. The expected result includes: | |
| | |
| <pre>
| |
| M204.0353: TNUSER ... login
| |
| TNDEV 21 IODEV number for TNSERV threads
| |
| </pre>
| |
| | |
| To automate the same check, pipe <code>Connect</code>, <code>String</code>, <code>Enter</code>, <code>Wait</code>, and <code>Ascii</code> actions to <code>s3270 -script</code>. Do not put a real password in a committed script or shell history.
| |
| | |
| === Shut down cleanly ===
| |
| | |
| For the quickest tested shutdown, issue <code>EOJ</code> from the privileged <code>TNUSER</code> session and answer <code>Y</code> when Model 204 asks for confirmation. The TN3270 connection closes and <code>emu204</code> reports normal Online termination.
| |
| | |
| Alternatively, log out and quit the TN3270 client. At the <code>emu204</code> operator terminal, reply to the first HALT with:
| |
| | |
| <pre>
| |
| EOD
| |
| </pre>
| |
| | |
| After users have disconnected, reply to the second HALT with:
| |
| | |
| <pre>
| |
| EOJ
| |
| </pre>
| |
| | |
| Model 204 should report that all users are logged out and begin normal Online termination.
| |
| | |
| == 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 == | | == Troubleshooting == |
|
| |
| {| class="wikitable" | | {| class="wikitable" |
| ! Symptom !! Action | | ! Message !! Meaning / 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 platform package is missing || Reinstall without <code>--no-optional</code> or <code>--ignore-scripts</code>; 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 <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.
| |
| |-
| |
| | <code>m204qa/</code> appears as untracked after a test || The installed QA driver writes its case and output beside the Model 204 tree. Preserve anything needed from <code>m204qa/out/</code>, then remove the generated directory.
| |
| |- | | |- |
| | <code>MSIR.1097</code> says hardware compression is unavailable || Expected under the current emulator; it does not by itself fail the QA run. | | | Unauthorized - User ''x'' / Customer ''x'' is not authorized || The userid has no access to that customer nickname. Fix the userid's access. |
| |- | | |- |
| | Need more emulator detail || Use <code>emu204 --help</code>, <code>emu204 --help=config</code>, and <code>emu204 --help=em</code>. | | | CPU ID (...) must be between 8 and 10 hex digits || Bad DR CPU ID. Re-enter it. |
| |- | | |- |
| | <code>M204.1122: Invalid parameter = -</code> at startup || A continuation dash is not in column 72. Pad the line with blanks so that the dash is the 72nd character. | | | Disaster Recovery test start date is invalid / too old / too far in the future || Correct the DR start date. |
| |- | | |- |
| | Port 7777 closes immediately after startup || Check the HALT message lengths in CCAIN. They must exactly match the message text or User 0 can continue to <code>EOJ</code>. | | | DR ZAP limit ... has been reached || See Disaster Recovery above. |
| |- | | |- |
| | TNSERV prompts for a password but the generated account cannot log in || Expected for the automatic CCASTAT account. Create a disposable account with <code>LOGCTL</code>, or provide an appropriate development CCASTAT. | | | Not found - No authorization zaps called ... || The key procedure is missing for that product prefix. |
| |- | | |- |
| | A plain <code>telnet</code> client connects but does not produce a usable screen || Use a TN3270 client such as <code>c3270</code>; TNSERV requires TN3270 negotiation. | | | 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 references == | | == 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 |
|
| |
|
| * <code>gitm204/BUILD.md</code>
| | <!-- Not documented here: the code that actually computes the encrypted key lives in the background AUTH program, which is not in this repository. --> |
| * <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>
| |
| * <code>m204-80/.github/skills/zos-crossbuild.md</code>
| |
| * <code>m204-81/DEVELOPMENT.md</code>
| |
| * <code>m204-81/.github/skills/building.md</code>
| |
| * <code>m204-81/.github/skills/testing.md</code>
| |