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

Data

Data

The evidence supports a partial, source-level inventory of information handled by CARDDEMO/CARD-DEMO. Named information includes customers, accounts, cards, transactions, cross-references, categories, statements, reports, authorization and fraud records, security data, backups, exports, and rejects. These names indicate intended processing areas, not a confirmed integrated data model or complete runtime dataset README.md; E0001 E0038.

Catalog evidence records 209 entries under AWS.M2.CARDDEMO: 160 NONVSAM, 13 DATA, 13 INDEX, 10 CLUSTER, and 7 GDG components. LISTCAT completed with condition code 0, but the catalog does not establish that all components are populated, connected to the application programs, or used in production [LISTCAT.txt]. The source describes VSAM files, sequential files, and optional DB2, IMS, GSAM, and BSAM data handling. Dataset identities, ownership, lifecycle status, and runtime connectivity remain incomplete or unknown E0002 E0036.

Reported record layouts and key definitions conflict. Examples include account records of 300 bytes, card records of 150 bytes, transaction records of 350 bytes, and customer records of 500 bytes. A 350-byte transaction layout conflicts with a separate 500-byte migration format. Account-key and field-width evidence also differs, including a ten-byte account ZIP in one layout and a five-byte screen field elsewhere. These discrepancies prevent a definitive statement of record shape, key structure, field semantics, encoding, or compatibility [ACCTFILE.jcl] [CARDFILE.jcl] [TRANFILE.jcl] [XREFFILE.jcl] [CVACT01Y.cpy] [CVTRA05Y.cpy] E0002 E0036.

The online programs reportedly read and update cross-reference, account-master, customer-master, card, and transaction information through CICS and VSAM operations. Account view reads cross-reference, account-master, and customer-master data. Account update validates input and commarea values and may lock and rewrite account and customer records, with paths for missing records, concurrent updates, and customer-update failure. The exact validation rules remain uncertain because CSLKPCDY is absent E0025 E0029.

Bill payment reportedly verifies account existence, positive balance, duplicate transaction ID, and user confirmation before creating a transaction and updating a balance. Transaction processing validates account/card relationships, limits, expiry, and references, and may update balances or account data and write rejects to DALYREJS. CBTRN02C visibly performs substantive validation and posting. Claims that CBTRN01C posts transactions are not supported by the visible absence of WRITE, REWRITE, or DELETE operations [COTRN00C.cbl] [COTRN01C.cbl] [COTRN02C.cbl] [CBTRN01C.cbl] [CBTRN02C.cbl]. Identifier uniqueness, concurrency control, commit or rollback behavior, atomicity, reconciliation, and recovery are unproven.

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

Optional authorization processing combines MQ, IMS, DB2, and VSAM. PAUTDTL1 declares 200 bytes while an unload specifies LRECL=206; relationships among AUTHFRDS, DBPAUTP0, and their differing error handling remain unresolved [COPAUA0C.cbl] [COPAUS2C.cbl] [DBPAUTP0.dbd] [UNLDPADB.JCL] E0009 E0011. Queue names, endpoints, transformations, external ownership, dataset identities, and encoding rules are unknown. Copybook alignment, lineage, retention, and protection of CVV or government-identifier fields are likewise unresolved. Plaintext password fields, possible exposed sensitive values, destructive replacement, JOURNAL(NO), RECOVERY(NONE), and ERROROPTION(IGNORE) are risk indicators rather than confirmed incidents [FTPJCL.JCL] E0016 E0032 E0033.

Accordingly, the evidence establishes intended data handling and several declared storage artifacts, but not a canonical schema, authoritative ownership, complete lineage, data quality, retention policy, protection controls, or successful end-to-end processing.

Automated evidence review

Data review

Supported or reasonably supported

• The draft appropriately limits its conclusion to a partial, source-level inventory rather than claiming a verified integrated data model.
• The named domains—customers, accounts, cards, transactions, cross-references, statements, reports, authorization/fraud, exports, backups, and rejects—are presented as intended processing areas, which is appropriately cautious.
• The stated layout discrepancies and the uncertainty around copybook alignment, field semantics, encoding, lineage, retention, and protection are material and should remain prominent.
• The discussion of CBTRN02C is appropriately stronger than the discussion of CBTRN01C: visible validation/posting logic is distinguishable from an unsupported claim that CBTRN01C writes transactions.
• The draft correctly distinguishes a successful LISTCAT command from proof that datasets are populated, connected, or used operationally.
• The authorization-processing section appropriately treats the 200-byte versus LRECL=206 discrepancy and differing MQ/IMS/DB2/VSAM relationships as unresolved rather than explaining them speculatively.

Issues requiring correction or qualification

1. Catalog arithmetic does not reconcile.
   The reported categories total 203, not 209:
   160 + 13 + 13 + 10 + 7 = 203.
   The draft should explain whether categories overlap, whether six entries are unclassified, or whether one of the counts is incorrect. Until reconciled, state the counts as reported rather than as a single validated breakdown.

2. “Conflicting layouts” may overstate the evidence.
   A 350-byte transaction record and a 500-byte migration record may represent different versions, formats, or staging records rather than a direct contradiction. Similarly, a ten-byte stored ZIP and a five-byte screen field may reflect truncation, display formatting, or a different business field. Describe these as unresolved format differences unless the evidence proves they refer to the same record or field.

3. “Record layouts and key definitions conflict” needs specificity.
   Identify the exact dataset, copybook, offsets, key positions, and source authority for each alternative. Otherwise, the conclusion that no definitive record shape or key structure exists is reasonable, but the underlying comparison is not reproducible.

4. Some operational statements remain inferred.
   Claims that programs “may lock and rewrite,” “update balances,” “write rejects,” or handle concurrent updates should distinguish visible code paths from comments, declarations, or intended behavior. In particular, identify whether locking, rewrite, and failure handling are actually present in executable statements.

5. Security wording risks implying incidents.
   “Plaintext password fields,” “exposed sensitive values,” and “destructive replacement” should be explicitly qualified as declarations, literals, sample data, or possible code paths. The evidence does not establish that sensitive values were populated, transmitted externally, exposed, or used in production.

6. The LISTCAT result is not evidence of data content.
   The draft correctly notes this, but should also avoid implying that component type counts establish a complete storage inventory. Aliases, alternate indexes, GDG generations, migrated datasets, and non-cataloged files may affect completeness.

7. Citation inconsistency.
   <span class="prsd-reference" title="Evidence E0025 retained privately">E0025</span> appears mismatched: the identifier and linked evidence filename differ. Correct this before publication and verify the other similarly paired citations.

Gaps and unresolved questions

• Which datasets are authoritative for customer, account, card, transaction, and cross-reference data?
• Are the catalog entries populated, and what are their record counts, generations, allocation status, and last-use dates?
• Which copybook/layout applies to each dataset, program, migration file, and screen field?
• What are the primary and alternate keys, duplicate-key rules, and data encoding conventions?
• Are account updates and bill payments atomic across related files? Where are commits, syncpoints, rollback, and restart logic defined?
• Does DALYREJS contain rejected transaction data, and what are its retention and access controls?
• What are the actual import/export schemas, delimiters, encodings, and direction of movement?
• Are authorization records persisted in more than one system, and how are identifiers and status changes reconciled?
• What retention, masking, encryption, audit, backup, and restoration controls apply to CVV, government identifiers, passwords, and account data?
• Which evidence demonstrates execution rather than source intent—job logs, CICS traces, VSAM statistics, DB2/IMS logs, MQ records, or test results?

Recommended revision

Retain the cautious overall conclusion, but separate observed declarations, visible executable behavior, and unverified intended behavior. Reconcile the catalog counts, correct citation links, and label format differences as unresolved until dataset-to-copybook mappings and runtime evidence establish whether they are true incompatibilities.