CSI baseline CSI-CARD-2026-10-22 · 22 October 2026. Limited to the registered source set. Application execution and proposed tests were not run; source findings do not establish runtime behaviour.

CardDemo: verification plan

Assessment baseline: 22 October 2026. All five tasks are not run. The procedures below describe the evidence to collect. They contain no test-pass claim, observed failure or approved expected-result assertion. The public C13 scenarios remain candidates until their authority is established for the selected executable. CARD-SRC-01 CARD-SRC-07 CARD-SRC-09

Verification status

CARD-TEST-01: Response versus subsequent IMS failure

Finding: CARD-FIND-01. Candidate: C13-13. Question: what does the requester receive, and what authorisation state remains, when the IMS write after the response fails?

The retained source sends its correlated reply before the later database write and selects MQ no-syncpoint options. That supplies the reason for this check, but not its outcome. CARD-SRC-02 CARD-SRC-10 CARD-SRC-11

Prerequisites. Bind the deployed COPAUA0C executable and relevant source; confirm that the optional extension is enabled. Record installed MQ/CICS/IMS identities, request/reply definitions, persistence policy and transaction integration settings. Establish scenario authority through CARD-TEST-05. Use an authorised isolated environment with controlled fixtures. CARD-SRC-01 CARD-SRC-06 CARD-SRC-07

Procedure to adapt. Prepare a valid authorisation request with sufficient available credit. Run a normal control. For the failure case, arrange a controlled failure of the later IMS write and observe the complete request/reply/database sequence. The mechanism must be chosen for the selected environment; this report does not claim a tested fault-injection method. CARD-SRC-09

Required observations. Capture request consumption, request/reply identifiers and correlation, reply content, actual receipt by the requester, IMS summary and detail state, transaction outcome and error logs. Preserve the before/after values and enough timing information to establish the observed order. CARD-SRC-02 CARD-SRC-08 CARD-SRC-09

Interpretation. Compare the externally received decision with recorded state and the selected requirements. Do not treat the source's send call as proof of receipt. Do not assume that a later rollback retracts an outside-syncpoint reply. Record actual results before proposing a change. CARD-SRC-10

CARD-TEST-02: Installed recoverability and paired update

Finding: CARD-FIND-02. Candidate: C13-03, preceded by configuration review. Question: do the account and customer records retain a consistent outcome when the second rewrite fails?

The source rewrites the account before the customer and requests rollback following a failed customer rewrite. The sample FILE settings are documented, but catalog attributes can alter effective recovery. CARD-SRC-03 CARD-SRC-04 CARD-SRC-12 CARD-SRC-13

Prerequisites. Bind the COACTUPC load module and selected source/build. Obtain installed ACCTDAT and CUSTDAT FILE definitions, ICF catalog LOG settings and the relevant transaction/runtime configuration. Record the effective recovery interpretation. Complete the scenario-authority decision. CARD-SRC-03 CARD-SRC-04 CARD-SRC-07

Procedure to adapt. Capture both records before a valid paired update and observe its normal completion. In a controlled failure case, allow the account rewrite to succeed and cause the subsequent customer rewrite to fail. Observe the rollback request and actual outcome for both resources. CARD-SRC-03 CARD-SRC-09

Required observations. Retain both original records, intended changes, returned statuses, the rollback/transaction outcome, logs and final record values. Include the no-change and unchanged-field observations proposed by C13-03. CARD-SRC-09

Interpretation. Determine the observed paired outcome from the records and transaction evidence. RECOVERY(NONE) in the retained sample is not the result oracle. A rollback request alone is not evidence that either record was restored. CARD-SRC-04 CARD-SRC-12 CARD-SRC-13

CARD-TEST-03: Concurrent account/customer modification

Finding: CARD-FIND-02. Candidate: C13-04. Question: how does the selected build handle a record changed between the initial read and the submitted update?

The retained source compares original values, and the public candidate proposes concurrent modification. Their correspondence makes this a useful characterisation target, while the source-to-edition binding remains unresolved. CARD-SRC-03 CARD-SRC-09

Prerequisites. Bind the executable, fixtures and chosen expected-result authority. Make the before/after records and the concurrent change attributable to the test case. CARD-SRC-01 CARD-SRC-07 CARD-SRC-09

Procedure to adapt. Read an account/customer pair for update. Modify one of the records through the controlled concurrent action before submitting the original update. Observe whether the stale submission is rejected and what follows. Retain the related no-change and unchanged-field observations from C13-03. CARD-SRC-09

Required observations. Capture original values, the intervening values, the submitted values, the actual user message, any reread behaviour and the final stored values. Record the result separately for each scenario exercised. CARD-SRC-03 CARD-SRC-09

Interpretation. Compare observed handling with the chosen requirement or record it as characterisation where no authoritative requirement exists. Do not report successful concurrency protection from the presence of an original-value comparison alone.

CARD-TEST-04: Bind installed runtime identities

Finding: CARD-FIND-03. Basis: proposed evidence collection. Question: which exact installed components and conditions can a vendor notice be evaluated against?

Collect product names and editions, platform, installed releases, maintenance/fix levels, enabled optional modules, support arrangements and the source/build identity. Cover the relevant MQ, CICS, IMS, Db2, COBOL compiler and z/OS dependencies. Attach collection dates and supporting records. The inspected material currently provides technology names without those installed values. CARD-SRC-01 CARD-SRC-05 CARD-SRC-06

Record the application-to-runtime mapping and effective settings needed for the two paths. Keep missing values as unknown. Match a notice only after its affected range and conditions can be evaluated against this inventory. A project badge or vendor documentation version must not become an installed runtime value. CARD-SRC-05 CARD-SRC-10 CARD-SRC-12

Completion evidence. A reviewer should be able to trace each populated inventory field to its dated evidence and identify which optional path is deployed. No CVE or lifecycle match is a prerequisite for completing the inventory itself.

CARD-TEST-05: Confirm the authority of each test baseline

Finding: CARD-FIND-04. Basis: proposed evidence reconciliation. Question: which source and expected results govern each scenario for the chosen executable?

The retained archive and the public PDF edition have separate identities. The public edition's analysed upstream commit is unverified, and older retained specification material has not been adopted as current requirements. CARD-SRC-01 CARD-SRC-07 CARD-SRC-14

Obtain a source-to-PDF analysis binding or compare the programs and dependencies relevant to C13-03, C13-04 and C13-13. Record material differences and the selected executable/source identity. Explicitly decide which expected behaviours are authoritative requirements and which are questions to characterise. CARD-SRC-09

Completion evidence. Retain the comparison, the selected baseline and the reason each expected result is authoritative or provisional. Agreement on a path description alone does not prove complete baseline equivalence. CARD-SRC-07 CARD-SRC-14

Recording results later

For each eventual execution, retain the task and candidate identifiers, dated environment/build/configuration references, fixtures, observed values, logs, outcome and interpretation. Separate a procedure that ran from one that merely exists. Source reading, documentation research and graph checks in this assessment are not application test results.