Repository navigation
det: NUMVAL / NUMVAL-C in a fixed-point COMPUTE as long HFP, its store checked (Fixes #4741) - #4759
Merged
Merged
Conversation
…g HFP, its store checked (Fixes #4741) IBM evaluates an arithmetic statement with a numeric-function operand in floating point (6.4 Programming Guide SC27-8714-03, "Floating-point evaluations", p. 62), and NUMVAL / NUMVAL-C return long floating point (p. 115; Language Reference SC27-8713-03, p. 605). The det translator now makes such a statement a long HFP one (Hfp.numval: the same refusals as #4742 for more than 18 digits and more than 15 significant digits). IBM documents the float-to-fixed MOVE (rounded) but not an arithmetic statement's store, so Hfp.fixedStore refuses by name a value the documented and the assumed (truncated unless ROUNDED) rules store differently, e.g. NUMVAL('0.10') = 0.0999... into 9V99; values exact at the receiver's scale store as they are and agree with the oracle (NUMVALX, in three modes). A proven case with such values declares "numval_fixed_store": "oracle" (a declared difference of its evidence record, #4051): CardDemo COTRN02C (carddemo-tranadd) needs it for an amount like 123.45 and a 16-digit card number. Register C6 records the semantics, the refusals and the oracle difference. Census: 108 / 179 programs whole before and after. Also fixes det_survey's NameError (ispf_screens) when an estate fails to generate. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D
squid-protocol
added
enhancement
squid-protocol
added this to the
Training Montage 🏋️ — Prepping to one-shot our 4th CICS to Java translation attempt milestone
Contributor
…res the NUMVAL store, #4741) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D
Owner
Author
|
Owner decision (2026-10-09): option 3. NUMVAL / NUMVAL-C in a fixed-point arithmetic statement is evaluated in long HFP (as IBM documents), and the store into the fixed-point receiver rounds, following IBM's documented floating-point-to-fixed-point MOVE rule ("Conversions and precision"). This is marked ASSUMED in register C6 until z/OS calibration (#4702 part 2). Remove the per-case 🤖 Generated with Claude Code |
…-case oracle switch (#4741) Owner decision (option 3): the store of a NUMVAL-only long-HFP result into a fixed-point receiver rounds to the receiver's scale, IBM's float-to-fixed MOVE rule ("Conversions and precision"), ASSUMED in register C6 pending z/OS calibration (#4702). The >18-digit and >15-significant-digit refusals and ARITH(EXTEND)'s stay. The numval_fixed_store case switch, Hfp.swapNumvalStore, with_numval_oracle and the option difference are removed: the port never follows GnuCOBOL. Merges origin/main. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D
…-prove the record and ledger (#4741) NUMVAL of 9999999999999999 (16 significant digits) is undefined on z/OS (long HFP keeps 15) and refused by name; the scenario's card is now 0999999999999999, still absent from the cross-reference (same 18/18 paragraphs, 72/75 branches). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D
…merging main (#4741) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D
…dence and reports Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D
…ster/C6.md (#4793), main's evidence report and ledger taken Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…merge Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…dger re-applied from the sweep, carddemo-tranadd re-proved Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…the sweep Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
squid-protocol
marked this pull request as ready for review
October 9, 2026 19:51
squid-protocol
added a commit
that referenced
this pull request
Oct 9, 2026
…-all re-run Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
squid-protocol
added a commit
that referenced
this pull request
Oct 9, 2026
…uivalence_cics: terminal facts + URIMAPs / case clock kept together Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
squid-protocol
added a commit
that referenced
this pull request
Oct 9, 2026
…nces) (#4823) * fix main: re-render carddemo-tranadd's evidence page; ci_digest fetches job logs with ANSI escapes Main's ground-truth / full-suite went red at #4820: the evidence-refresh bot's refresh was computed on a main before #4759 (which re-proved carddemo-tranadd), then squash-merged on top of it, leaving the record (CI oracle image d7e387df360c) and its rendered page (local image 42d04bb08a2a) out of step. `evidence.py render` from the record; no record changed. Every open PR inherited the failure (test_the_rendered_pages_are_current). ci_digest: `gh api` refuses to print a job log holding terminal escapes unless passed --allow-escape-sequences, so every log came back "unavailable"; clean() already strips them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci_digest: registry / Docker Hub rate limits and network resets are infra (rerun once), not real #4821's muninn failed on Docker Hub's 429 Too Many Requests while building a third-party action's image; the digest called it real and the shepherd only posted a note. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci_shepherd: an infra failure is rerun up to 3 times, 15 min apart (a flake once) Docker Hub's 429 / auth 504 on 2026-10-09 failed muninn on every PR for over an hour; one rerun was not enough. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4741 (part of #4270).
IBM. An operand that is "a reference to a numeric intrinsic function results in floating-point arithmetic when ... the function is a floating-point function" (6.4 Programming Guide SC27-8714-03, "Floating-point evaluations", p. 62); NUMVAL / NUMVAL-C "return long (64-bit) floating-point values in compatibility mode" (p. 115; Language Reference SC27-8713-03, NUMVAL, p. 605). So an arithmetic statement with a NUMVAL operand is a long-HFP statement even when every item is fixed point.
Change (owner decision, option 3).
float_modemakes such a statement long; the operand isHfp.numval(refusals kept: more than 18 digits, more than 15 significant digits; ARITH(EXTEND) refused). The store into a fixed-point receiver (Hfp.fixedStore) ROUNDS half away from zero to the receiver's scale, IBM's documented float-to-fixed MOVE rule ("Conversions and precision"), ASSUMED for an arithmetic store in register C6 pending z/OS calibration (#4702).NUMVAL('0.10')(0.0999... in long HFP) stores 0.10. The port never follows GnuCOBOL: the per-casenumval_fixed_storeswitch from the earlier revision is removed.Oracle differences (C6). GnuCOBOL truncates the exact decimal where the argument has more decimals than the receiver; a NUMVAL of more than 15 significant digits is refused where GnuCOBOL answers. Still exact decimal and noted: NUMVAL in a comparison, MOVE, subscript, another function's argument.
carddemo-tranadd proves with no switch (46 scenarios, 18/18 paragraphs, 72/75 branches). One scenario's "unknown card" input 9999999999999999 (16 significant digits, undefined on z/OS, refused) became 0999999999999999; same coverage. Record re-proved, ledger and page refreshed.
Evidence. test_det_hfp, test_det_programs NUMVALX / NUMVALF vs cobc (bytes/typed/groups);
det_port.py checkvs origin/main changed 5 ports (acctupdate, cotrtupc, report, tranadd, mortgage-mpmt);proof_sweep --det-onlyon them: 4 proved, mpmt as before; pr_gates --fast 5/5, --ratchets 7/7. Census earlier: 108 / 179 whole before and after (refusals are run time).🤖 Generated with Claude Code
https://claude.ai/code/session_01MQNoe4wPJgr7dbUvs3DG6D