Source-derived document; review findings and open questions with the application owner.

Acceptance criteria

Acceptance is limited to evidence-based characterization of the supplied CARDDEMO/CARD-DEMO materials. It must not be interpreted as confirmation of a complete, integrated, deployable, or production-ready system. The evidence currently establishes artifacts, declarations, mappings, and intended operations, but does not establish successful compilation, linkage, deployment, connectivity, execution, production use, ownership, data correctness, or complete topology README.md; E0001 E0010 E0017 E0038.

Source and build characterization

Acceptance requires recording which supplied sources and copybooks:

• compile successfully;
• bind or link successfully;
• deploy to the applicable runtime;
• require unavailable or optional components; and
• fail because of missing source, copybooks, configuration, conflicting declarations, or unresolved dependencies.

The result must preserve compiler, binder, and job return codes and must not infer successful execution from source intent. JCL conditions and job ordering require explicit verification, including the inconsistency in which COND=(4,LT) appears inconsistent with the claim that NEWCOPY follows a successful compile under ordinary JCL semantics [CICCMP.jcl] [BLDCIDB2.prc] [IMSMQCMP.jcl].

Conflicting inventories, hashes, source ranges, observation totals, draw.io names, and “FLEET DOCUMENT” descriptions must be reported as discrepancies rather than reconciled by assumption. They are not authoritative evidence of architecture, dependencies, or runtime behavior [README.md] E0047.

Online behavior

Acceptance requires execution-based characterization of the sign-on path beginning at CC00, including validation of USRSEC, error redisplay, PF3 exit behavior, authenticated routing to COADM01C or COMEN01C, XCTL behavior, and commarea contents [COSGN00C.cbl; COSGN00.bms; COSGN00.CPY] E0028 E0030 E0034.

The recorded account, card, transaction, bill-payment, reporting, administration, and user-maintenance journeys must be tested only where their required sources, maps, data, and runtime dependencies are available. Characterization must record terminal responses, paging and key actions, commareas, state changes, return codes, logs, data updates, and external effects. Missing screen, key-action, commarea, state, and response models remain acceptance limitations E0013 E0026 E0038.

Account view and update must establish, rather than assume, cross-reference, account-master, and customer-master reads; validation; locking; rewrite behavior; missing-record handling; concurrent-update handling; and customer-update failure behavior. The effect of absent CSLKPCDY must be recorded E0025 E0029.

Bill payment must establish account and balance checks, duplicate transaction handling, confirmation behavior, transaction creation, balance update, identifier generation, uniqueness, concurrency, and commit behavior. Unconfirmed or failed payments must be tested for observable effects.

Transaction processing must distinguish validation from posting. In particular, claims about CBTRN01C posting transactions must not be accepted without observed or visible write evidence, because the supplied source lacks visible WRITE, REWRITE, or DELETE operations, while CBTRN02C visibly performs substantive validation and posting [COTRN00C.cbl] [COTRN01C.cbl] [COTRN02C.cbl] [CBTRN01C.cbl] [CBTRN02C.cbl]. Atomicity, commit or rollback, reconciliation, and recovery remain unaccepted unless demonstrated.

Data and interface boundaries

Acceptance requires recording the actual layouts, keys, lengths, encodings, field semantics, lineage, and update behavior encountered at runtime or established directly from authoritative source. Conflicts must remain explicit, including the reported account, card, transaction, and customer lengths; the ten-byte account ZIP versus five-byte screen field; and the 350-byte transaction layout versus 500-byte migration format [ACCTFILE.jcl] [CARDFILE.jcl] [TRANFILE.jcl] [XREFFILE.jcl] [CVACT01Y.cpy] [CVTRA05Y.cpy] E0002 E0036.

Catalog evidence may be reported as observed, including the LISTCAT completion condition code of 0 and its reported component counts, but must not be treated as proof that all datasets are present, correctly populated, or connected to the programs [LISTCAT.txt].

Each exercised CICS, BMS, VSAM, DB2, IMS, MQ, GSAM/BSAM, JCL, RACF, JES/TSO, SDSF, FTP, sorting, PDF, Control-M, or UNIX boundary must have its actual endpoint, contract, encoding, transformation, ownership, dataset or queue identity, and failure result recorded where available. Unknown values remain unknown. REPROCT.ctl establishes a REPRO from FILEIN to FILEOUT, but not filtering or validation E0022 E0035 E0046.

Batch, failure, and recovery behavior

Acceptance requires characterization of available initialization, loading, replacement, posting, interest and fee, statement, reporting, import, export, indexing, backup, cleanup, and scheduled flows. Testing must record ordering, EOF handling, partial updates, abends, return codes, restart and rerun behavior, compensation, backup, and restoration. The possible sequential-versus-indexed mismatch and unavailable export layout must remain open until demonstrated E0007 E0040 E0045.

Optional authorization processing must not be accepted as cross-system atomic without evidence covering MQ, IMS, DB2, and VSAM effects. The PAUTDTL1 200-byte declaration versus LRECL=206, the relationships among AUTHFRDS, DBPAUTP0, and their differing error handling, and dataset-name discrepancies require explicit test or source resolution [COPAUA0C.cbl] [COPAUS2C.cbl] [DBPAUTP0.dbd] [UNLDPADB.JCL] E0009 E0011.

Security and residual uncertainty

Acceptance must record observed behavior for authentication, authorization, auditing, segregation of duties, lockout, masking, encryption, queue permissions, network protection, credential handling, and identity propagation. Presence of USRSEC, RACF references, plaintext-password fields, example FTP credentials, possible CVV or government-identifier exposure, destructive replacement, JOURNAL(NO), RECOVERY(NONE), or ERROROPTION(IGNORE) is evidence of risk or an unresolved question, not proof of an incident or effective control [FTPJCL.JCL] E0016 E0032 E0033.

Final acceptance is therefore a bounded record of what builds, runs, connects, changes data, fails, reruns, and recovers, together with explicit contradictions and unknowns. No unsupported end-to-end, production, security, ownership, or data-correctness claim may be made.

Automated evidence review

Advisory review — Acceptance criteria

Overall assessment

The section is appropriately cautious and generally consistent with the bounded evidence. It correctly distinguishes source-level declarations and intended operations from proven compilation, execution, deployment, integration, data correctness, security effectiveness, and recovery. However, it currently reads more like a characterization plan and uncertainty register than objective acceptance criteria. It does not define a test scope, environment, evidence format, pass/fail rule, or treatment of failed, blocked, and out-of-scope items. It therefore cannot itself support an acceptance decision.

Unsupported or overstated points

• “Authenticated routing” and “XCTL behavior” are supported by source-level evidence, but not by execution evidence. The criterion should say that source behavior must be verified at runtime, and that the current evidence only shows intended routing.
• Account update behavior is described as requiring validation of locking, rewriting, missing-record handling, concurrency, and customer-update failure. The evidence reportedly indicates these may exist, not that all are implemented or reachable. Label them as behaviors to verify, not expected capabilities.
• Bill-payment processing similarly should distinguish reported/source-indicated behavior from demonstrated transaction creation, balance modification, identifier generation, and commit semantics.
• The statement that CBTRN01C lacks WRITE, REWRITE, or DELETE is supported only for the visible supplied extract. It should not imply that the entire program or called programs cannot perform writes.
• “Actual endpoint, contract, encoding, transformation, ownership…” is a valid investigation requirement, but the evidence does not identify an authoritative source for ownership or external endpoint identity. Define what counts as authoritative evidence.
• Security findings such as plaintext passwords, FTP credentials, CVV or government-identifier exposure, and destructive replacement are appropriately called risk indicators. The acceptance text should also require safe handling: redact secrets, use non-production credentials, and prohibit live destructive or unauthorized tests.

Gaps in the criteria

The criteria should additionally specify:

1. Scope and applicability: exact source set, programs, jobs, datasets, maps, copybooks, and optional components included or excluded.
2. Test environment: emulator or mainframe/CICS/DB2/IMS/MQ environment, permitted test data, account identities, and whether production access is prohibited.
3. Evidence requirements: compiler, binder, job, and transaction logs; return codes; dataset snapshots or checksums; commareas; screen captures; database/MQ/VSAM before-and-after state; and timestamped test identifiers.
4. Disposition rules: separate statuses for passed, failed, blocked by missing evidence, not executable, and not applicable. Missing dependencies must not be treated as failures or successes.
5. Traceability: each criterion should map to a test case, source artifact, evidence item, and result.
6. Objective pass conditions: for example, expected return codes, exact state changes, rollback expectations, duplicate behavior, restart outcomes, and acceptable reconciliation variance.
7. Dependency and topology criteria: identify required compile order, link-edit dependencies, CICS definitions, DB2 packages/plans, IMS PSBs/DBDs, MQ queues, RACF identities, and dataset allocation. “Connects” is otherwise too vague.
8. Security test boundaries: authorization matrices, audit-log expectations, masking requirements, credential rotation, and prohibited handling of real sensitive data.
9. Recovery scope: define which failures are injected, what constitutes successful rollback or restart, and what backup/restore evidence is required.
10. Final decision rule: specify whether acceptance is possible with unresolved contradictions, and who records or approves exceptions. Since this is advisory, the document should state that it does not constitute approval.

Contradictions and citation problems

The draft correctly preserves several known contradictions, including:

• COND=(4,LT) versus the claim that NEWCOPY follows only a successful compile;
• conflicting inventories, hashes, source ranges, and observation totals;
• account, card, transaction, customer, ZIP, and migration-layout discrepancies;
• PAUTDTL1 200 bytes versus LRECL=206;
• AWSTSSC.AUTHFRS versus hard-coded CARDDEMO.AUTHFRS;
• DB201PLN versus AWS01PLN;
• TRANFILE versus TRANBKP;
• disputed map/program names, PF7 behavior, FTP direction, and copybook coverage.

However, citation identifiers and filenames appear inconsistent and should be corrected before use. Examples include:

• <span class="prsd-reference" title="Evidence E0025 retained privately">E0025</span> alongside <span class="prsd-reference" title="Evidence E0029 retained privately">E0029</span>;
• <span class="prsd-reference" title="Evidence E0026 retained privately">E0026</span>;
• <span class="prsd-reference" title="Evidence E0033 retained privately">E0033</span>;
• <span class="prsd-reference" title="Evidence E0007 retained privately">E0007</span>;
• <span class="prsd-reference" title="Evidence E0040 retained privately">E0040</span> and <span class="prsd-reference" title="Evidence E0045 retained privately">E0045</span>.

These mismatches weaken traceability and could cause the wrong evidence to be relied upon.

Unresolved questions

• Which evidence version, inventory, and hash set is the baseline?
• Are referenced source extracts complete, or can omitted called programs perform writes or security functions?
• What is the authoritative layout and key definition for each file?
• Which programs, jobs, and datasets form one executable path?
• Are commit, rollback, and restart semantics controlled by CICS, DB2, IMS, application code, or job procedures?
• What is the intended behavior for duplicate, unconfirmed, partially completed, or retried payments?
• Which security controls are requirements versus merely observed implementation artifacts?
• What constitutes closure of a discrepancy when runtime evidence is unavailable?

Recommended conclusion

Retain the bounded language, but rename or supplement this section as an acceptance and characterization plan. Add measurable status fields, evidence standards, test boundaries, traceability, and a formal exception process. Until those are supplied, the criteria appropriately define what must be investigated but do not establish acceptance of the system.