v0.3.0

Format unchanged: cics-crucible/1 (SPEC.md). The additions are additive and every v0.2.0 file still validates. 15 cases (was 10) and 74 scenarios (was 44). No log was corrected: no file under an existing case changed.

Five condition-handling cases cover the terminal-RECEIVE conditions and the handler forms that gitgalaxy #4413 and #4414 (with #4502) asked for. Each expected log was written by hand from IBM's documentation before it was run against any implementation. Every citation, and every ambiguity the scenarios were built to avoid, is in the case's NOTES.md. All 15 cases pass tools/validate.py.

Added, by trap

All five are in condition-handling. No other trap changed.

• hc-terminal-receive (HCTERM, 7 scenarios, gitgalaxy#4413). Covers unformatted terminal RECEIVE and SEND CONTROL.
  • lengerr-resp, lengerr-handled and lengerr-default: LENGTH in/out, with LENGERR caught by RESP, by HANDLE CONDITION, or by default (AEIV).
  • handler-unused: a HANDLE CONDITION that is set but never fires.
  • in-pieces: MAXLENGTH NOTRUNCATE keeps the rest of the input for the next RECEIVE.
  • set-address: SET(ADDRESS OF).
  • device-controls: SEND CONTROL with CURSOR.
• hc-terminal-eoc (HCEOC, 3 scenarios, gitgalaxy#4413). The RECEIVE on an LUTYPE2 terminal raises EOC.
  • eoc-resp: caught by RESP.
  • eoc-handled: caught by HANDLE CONDITION.
  • eoc-default: ignored by default.
• hc-handle-aid (HCAID, 9 scenarios, gitgalaxy#4414). Covers HANDLE AID after a terminal RECEIVE.
  • own-label: a key's own label.
  • anykey-not-enter and anykey-pf: ANYKEY, which does not take ENTER.
  • deactivated: a key deactivated by a HANDLE AID that has no label.
  • resp-no-aid: RESP ignores the AID.
  • push-suspends and pop-restores: PUSH HANDLE and POP HANDLE.
  • clear-no-data and pa1-anykey: CLEAR or PA1 starts a task whose first RECEIVE returns no data.
• hc-ignore-error (HCIGN, 9 scenarios, gitgalaxy#4414 / #4502)
  • ignored: one LENGERR under IGNORE CONDITION.
  • error-label: HANDLE CONDITION ERROR.
  • own-before-error and ignore-before-error: a condition's own HANDLE or IGNORE takes precedence over ERROR.
  • ignore-overrides-handle: IGNORE overrides HANDLE.
  • push-suspends-ignore and push-suspends-error: PUSH HANDLE suspends IGNORE and ERROR (AEIV).
  • pop-restores-ignore: POP HANDLE restores them.
  • pop-nothing-pushed: POP HANDLE with nothing pushed raises INVREQ, which goes to ERROR.
• hc-eoc-error (HCEOE, 2 scenarios, LUTYPE2 terminal, gitgalaxy#4414)
  • eoc-not-error: HANDLE CONDITION ERROR does not take EOC, whose default action is to ignore it.
  • eoc-own-label: EOC's own label does take it.

Format additions (still cics-crucible/1)

• SPEC section 2, Terminal. The reference terminal is a 3270 logical unit (DEVICE(3270)), whose RECEIVE raises no EOC. A case CSD may define the terminal as DEVICE(LUTYPE2) instead. On that device an input message is one chain, and the RECEIVE that returns its last byte raises EOC. This follows IBM, EXEC CICS RECEIVE (3270 logical) vs RECEIVE (LUTYPE2/LUTYPE3).
• SPEC section 6, SEND-CONTROL. options is a sorted subset of ERASE ERASEAUP FREEKB ALARM FRSET CURSOR. With CURSOR, the event carries cursor: {"offset": n}. schema/expected.schema.json and tools/validate.py check both rules, and validate.py also rejects any TYPETERM DEVICE other than 3270 or LUTYPE2.

Log corrections

None.

Lower-confidence statement added (README)

Case / scenario	Statement	What IBM says
hc-terminal-eoc (all)	An LUTYPE2 input message of a few bytes is a single-RU chain, so the RECEIVE that returns it raises EOC.	RECEIVE (LUTYPE2/LUTYPE3) lists EOC; RECEIVE (3270 logical) does not. That an inbound 3270 message is one chain comes from SNA, not from a CICS sentence.

Downstream (gitgalaxy)

gitgalaxy re-baselined at this commit (f8aaf95) with tests/tools/cics_crucible.py --update-baseline. That adds 130 cells.

• 40 pass: engine-facts and forge-compile for each new case, and cobol-stub for each of the 30 new scenarios.
• 90 are ledgered expected failures:
  • 30 on the java side: the generated runTask is still the unported stub.
  • 30 on java-ported and 30 on java-facade: the new cases have no committed ports yet.

No cell of any v0.2.0 case moved, and no coverage record of a v0.2.0 program moved. The pin bump is the gitgalaxy PR "chore: pin cics-crucible v0.3.0 (#4413, #4414 cases)".

One coverage note for a future scenario: HCEOE's GOT-ERROR label is never entered. hc-eoc-error shows that ERROR does not take EOC, so no scenario reaches that paragraph. A scenario that raises some other condition under ERROR would reach it.