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

Behaviours

Scope and confidence

The evidence supports a partial, source-level reconstruction of CARDDEMO/CARD-DEMO as a heterogeneous legacy or simulated mainframe-oriented suite. It contains COBOL, CICS, BMS, VSAM, JCL, sequential-file, and optional DB2, IMS, MQ, assembly, REXX, GSAM/BSAM, Control-M, and UNIX components README.md; CARDDEMO.CSD; E0001 E0010 E0017 E0038 E0044. The evidence establishes declarations, mappings, and intended operations, but does not establish successful compilation, linkage, deployment, connectivity, execution, production use, complete topology, data correctness, or one integrated end-to-end system E0001 E0002 E0018 E0032.

Inventories, source ranges, observation totals, relationships, and reported layouts conflict or are incomplete. Missing copybooks and source, restricted or truncated extracts, repeated records, and unavailable runtime evidence limit confidence. Names such as “FLEET DOCUMENT,” “ER Diagram,” and “IMS” are not authoritative evidence of runtime behaviour or dependencies [README.md] E0047.

Online behaviour

The clearest recorded online flow begins at CICS sign-on transaction CC00. COSGN00C reads and validates USRSEC, redisplays errors, exits on PF3, and routes authenticated ADMIN users to COADM01C; other authenticated users are routed to COMEN01C through XCTL and a commarea [COSGN00C.cbl; COSGN00.bms; COSGN00.CPY] E0028 E0030 E0034. The complete screen, key-action, commarea, state, and response models are unavailable.

Recorded journeys include account viewing and updating, card listing and search, transaction processing, bill payment, reporting, administration, and user maintenance. These journeys use BMS maps, terminal I/O, paging, and VSAM browse or update operations. Named programs include COACTVWC, COACTUPC, COCRDLIC, COCRDSEC, COBIL00C, and COACCT01 E0013 E0026 E0038.

Account viewing reportedly reads cross-reference, account-master, and customer-master records. Account updating validates input and commarea values and may lock and rewrite account and customer records. The code reportedly handles missing records, concurrent updates, and customer-update failure, but exact validation cannot be confirmed because CSLKPCDY is absent E0025 E0029.

Bill payment reportedly checks account existence, positive balance, duplicate transaction ID, and confirmation before creating a transaction and updating a balance. Identifier generation and uniqueness, concurrency, commit behaviour, and the result of non-confirmation are unproven E0029.

Transaction programs reportedly validate account and card relationships, limits, expiry, and references; update balances or account data; and may write rejects to DALYREJS. CBTRN02C visibly performs substantive validation and posting. Claims that CBTRN01C posts transactions are contradicted by the visible absence of WRITE, REWRITE, and DELETE operations in that program [COTRN00C.cbl] [COTRN01C.cbl] [COTRN02C.cbl] [CBTRN01C.cbl] [CBTRN02C.cbl]. Atomicity, commit or rollback, reconciliation, and recovery are not established.

Data and batch behaviour

Named information includes customers, accounts, cards, transactions, cross-references, categories, statements, reports, authorization and fraud records, security data, backups, exports, and rejects. Catalog evidence reports 209 entries under AWS.M2.CARDDEMO, including NONVSAM, DATA, INDEX, CLUSTER, and GDG components; LISTCAT completed with condition code 0 [LISTCAT.txt]. Reported record lengths and keys conflict, including account, card, transaction, and customer layouts. Copybook alignment, field semantics, encodings, lineage, retention, and protection of CVV or other sensitive fields remain unresolved [ACCTFILE.jcl] [CARDFILE.jcl] [TRANFILE.jcl] [XREFFILE.jcl] [CVACT01Y.cpy] [CVTRA05Y.cpy] E0002 E0036.

Batch intent covers initialization, loading and replacement, posting, interest and fee calculation, statements, reports, imports, exports, indexing, backups, cleanup, and scheduled workflows. CBEXPORT and CBIMPORT are described, but the export layout is unavailable and a sequential-versus-indexed file mismatch remains unresolved E0007 E0040. REPROCT.ctl confirms a REPRO from FILEIN to FILEOUT, but does not establish filtering or validation E0022. Partial updates, end-of-file ordering, abends, restart, rerun, and compensation behaviour are not established E0045.

External and failure behaviour

Interfaces are declared or referenced for CICS, BMS, commareas, VSAM, DB2 SQL and binding, IMS PSB/DBD access, GSAM/BSAM, MQ GET/PUT1, JCL, IDCAMS, RACF, JES/TSO, SDSF, FTP, sorting, PDF conversion, and Control-M/UNIX tooling E0035 E0046. Queue names, endpoints, contracts, transformations, encodings, external ownership, and dataset identities are unknown. Optional authorization processing combines MQ, IMS, DB2, and VSAM, but cross-system atomicity is unproven [COPAUA0C.cbl] [COPAUS2C.cbl] [DBPAUTP0.dbd] [UNLDPADB.JCL] E0009 E0011.

Security-related behaviour references USRSEC, RACF, and user-maintenance programs. Effective authorization, auditing, segregation of duties, lockout, encryption, masking, queue permissions, network protection, credential status, and identity propagation are unverified. Plaintext fixed-length passwords, example or literal FTP credentials, possible exposure of CVV or government identifiers, destructive replacement, JOURNAL(NO), RECOVERY(NONE), and ERROROPTION(IGNORE) are risk indicators rather than confirmed incidents [FTPJCL.JCL] E0016 E0032 E0033.

Overall, the recorded behaviours should be treated as intended or source-indicated paths pending execution-based characterization. Build, bind, deployment, connectivity, online journeys, batch chains, scheduling, failure, rerun, backup, restoration, commits, logs, and external effects remain to be verified.

Automated evidence review

Behaviours review

Overall assessment

The draft is appropriately cautious about the lack of execution evidence, but it still sometimes presents source-indicated intent as recorded behaviour. The second version is clearer and more consolidated; it should be preferred, subject to the issues below. This review is advisory and does not constitute approval.

Unsupported or overstated claims

• “Heterogeneous legacy or simulated mainframe-oriented suite” is a reasonable characterization, but “simulated” and “optional” components should be explicitly attributed to repository documentation or marked as interpretations.
• “Recorded journeys include” account updates, transaction processing, bill payment, and reporting. Unless execution traces exist, these are source-described capabilities or intended paths, not demonstrated journeys. Use “documented journeys” or “source-indicated flows.”
• Claims that account update handles concurrent updates, locks records, and manages customer-update failure need to distinguish visible code branches from verified runtime outcomes. The absent CSLKPCDY materially limits confirmation.
• Bill payment “before creating a transaction and updating a balance” describes intended ordering, not proven behavior. Identifier generation, duplicate handling, commit scope, and non-confirmation paths remain unknown.
• “Transaction programs validate … and update balances or account data” is too broad if CBTRN01C lacks visible write operations. Attribute each behavior to the specific program. The draft should also resolve the apparent filename inconsistency between COTRN01C/COTRN02C and CBTRN01C/CBTRN02C.
• LISTCAT condition code 0 establishes completion of that command, not that the reported catalog inventory is complete, correct, or usable.
• “Interfaces include” may imply implemented integrations. “Artifacts reference” or “sources declare” is safer for DB2, IMS, MQ, FTP, RACF, Control-M, and UNIX components.
• Security statements should distinguish observed source patterns from confirmed exposure. For example, a fixed-length password field or literal FTP credential may be a test artifact, example, or active credential; its operational status is unknown.

Contradictions and data-quality issues

• Input 2 reports 209 catalog entries but gives component totals of 160 NONVSAM, 13 DATA, 13 INDEX, 10 CLUSTER, and 7 GDG. These sum to 203, not 209. Explain whether categories overlap, six entries are unclassified, or one total is wrong.
• The draft reports conflicting source ranges, observation totals, layouts, keys, job orders, map/program names, PF7 behavior, FTP direction, dataset names, and copybook coverage, but does not identify which source is preferred or why.
• PAUTDTL1 being 200 bytes while an unload uses LRECL=206 is a discrepancy, not necessarily a contradiction: headers, trailers, padding, or another record format could explain it. The draft should state that the format relationship is unresolved.
• The COND=(4,LT) observation is important but should state the exact JCL consequence. Under ordinary semantics, a prior return code below 4 causes the conditioned step to be bypassed, which conflicts with the claim that NEWCOPY follows a successful compile.
• The first version describes CBEXPORT/CBIMPORT and the second describes a “possible” sequential/indexed mismatch. Retain the uncertainty unless the evidence proves the mismatch.
• Citation references are inconsistent or potentially mistyped: examples include E0026 versus E0027, E0007 versus E0008, E0040 versus E0041, and E0033 versus E0034. These should be reconciled.

Gaps

The section does not establish:

• whether any source set compiles, links, binds, deploys, or runs together;
• transaction and program entry points beyond the sign-on path;
• BMS map-to-program and commarea contracts, screen state, PF-key semantics, and error responses;
• VSAM browse/update semantics, record locking, alternate indexes, or file-open modes;
• transaction boundaries, SYNCPOINT, rollback, restartability, or recovery;
• batch dependency order, scheduling triggers, return-code handling, rerun safety, or partial-update behavior;
• actual DB2, IMS, MQ, FTP, RACF, or Control-M connectivity and ownership;
• data lineage between online files, batch files, backups, exports, and migration formats;
• handling of malformed records, duplicate keys, missing files, unavailable queues, authorization failures, or abends;
• logging, audit records, monitoring, alerting, retention, and restoration validation;
• whether sensitive fields are masked, encrypted, protected by access controls, or merely present in source layouts.

Unresolved questions and recommended priorities

1. Which exact source, copybook, and configuration versions form one buildable system?
2. Which discrepancies are genuine defects versus alternate environments, record formats, or documentation errors?
3. Do the named online programs share a common commarea and transaction model?
4. What are the actual commit, lock, rollback, and recovery boundaries?
5. Do export/import formats match their target datasets, including the 200/206-byte and 350/500-byte discrepancies?
6. Can the system be executed safely in an isolated environment to capture return codes, datasets, bindings, messages, external effects, and rerun outcomes?

Use the second draft as the base, but preserve explicit source-versus-runtime qualifiers and resolve the numerical and citation inconsistencies before publication.