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

Gaps

Gaps

Evidence and scope

The available material supports only a partial, source-level reconstruction of CARDDEMO/CARD-DEMO. It does not establish successful compilation, linkage, deployment, connectivity, execution, production use, ownership, data correctness, or one integrated end-to-end system README.md; CARDDEMO.CSD; E0001 E0010 E0017 E0038 E0044. Missing source and copybooks, restricted or truncated extracts, repeated records, incomplete configuration, and absent runtime evidence further limit confidence E0001 E0002 E0018 E0032.

Inventories, hashes, source ranges, observation totals, and relationship reports conflict. Endpoints are omitted or marked unknown, and no confirmed baseline is available. “FLEET DOCUMENT” and draw.io page names are not authoritative evidence of architecture, dependencies, or runtime behavior [README.md] E0047.

Build, deployment, and runtime

It remains unknown which sources compile, link, bind, deploy, connect, and run together. The evidence does not provide a complete topology, executable configuration, library concatenation, copybook set, DB2 or IMS bindings, CICS resource definitions, queue configuration, dataset allocation, or environment mapping. The significance of contradictory names and settings—including DB201PLN versus AWS01PLN, TRANFILE versus TRANBKP, AWSTSSC.AUTHFRDS versus hard-coded CARDDEMO.AUTHFRDS, and disputed map, program, and copybook references—is unresolved E0002 E0032 E0045. The COND=(4,LT) condition in relation to the claimed NEWCOPY compile sequence is also not reconciled with ordinary JCL semantics [CICCMP.jcl] [BLDCIDB2.prc].

No execution evidence confirms sign-on, routing, screen behavior, PF-key behavior, commarea contents, state transitions, response handling, or complete online journeys. The documented flow from CC00 through COSGN00C to administrative or general menus is therefore an intended or reconstructed flow rather than a demonstrated one [COSGN00C.cbl; COSGN00.bms; COSGN00.CPY] E0028 E0030 E0034.

Functional and transaction behavior

Account view and update, card operations, bill payment, reporting, administration, and user maintenance are described, but their complete validation rules and failure behavior remain unavailable. In particular, CSLKPCDY is absent, and identifier generation, uniqueness, concurrency, commit behavior, and non-confirmation behavior are unproven E0025 E0029.

Transaction behavior is contradictory. CBTRN02C visibly performs substantive validation and posting, while the visible CBTRN01C source lacks WRITE, REWRITE, and DELETE operations despite claims that it posts transactions [COTRN00C.cbl] [COTRN01C.cbl] [COTRN02C.cbl] [CBTRN01C.cbl] [CBTRN02C.cbl]. Atomicity, commit and rollback boundaries, reconciliation, recovery, and the treatment of rejects in DALYREJS are not established.

Data and interface contracts

Catalog evidence confirms reported VSAM and NONVSAM components, but not their semantic correctness or use by a single running system. Record lengths, keys, layouts, copybook alignment, field meanings, encodings, lineage, retention, and protection remain unresolved. Examples include conflicting account, card, transaction, and customer lengths; a ten-byte account ZIP versus a five-byte screen field; and a 350-byte transaction layout versus a 500-byte migration format [LISTCAT.txt] [ACCTFILE.jcl] [CARDFILE.jcl] [TRANFILE.jcl] [XREFFILE.jcl] [CVACT01Y.cpy] [CVTRA05Y.cpy] E0002 E0036.

CICS, BMS, commarea, VSAM, DB2, IMS, MQ, GSAM/BSAM, JCL, FTP, sorting, PDF, Control-M, and UNIX references do not establish complete contracts. Queue names, endpoints, transformations, encodings, external ownership, dataset identities, and error semantics are unknown E0022 E0035. REPROCT.ctl confirms a REPRO from FILEIN to FILEOUT, but not filtering, validation, or downstream interpretation E0046.

Batch, recovery, and security

Batch intent is described for loading, replacement, posting, interest and fee calculation, statements, reporting, imports, exports, indexing, backups, cleanup, and scheduling. Actual job order, dependencies, EOF handling, partial-update behavior, abends, restart, rerun, compensation, and restoration are not established. CBEXPORT and CBIMPORT remain incompletely characterized, including a possible sequential-versus-indexed file mismatch E0007 E0040 E0045.

Authorization processing across MQ, IMS, DB2, and VSAM has no demonstrated cross-system atomicity. PAUTDTL1 declares 200 bytes while an unload specifies LRECL=206; relationships among AUTHFRDS, DBPAUTP0, and their error handling remain unresolved [COPAUA0C.cbl] [COPAUS2C.cbl] [DBPAUTP0.dbd] [UNLDPADB.JCL] E0009 E0011.

USRSEC, RACF, and user-maintenance programs indicate security-related mechanisms, but effective authorization, auditing, segregation of duties, lockout, encryption, masking, queue permissions, network protection, credential status, and identity propagation are unverified. Plaintext or example credentials, possible exposed 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.

Execution-based characterization is therefore still required to determine what actually builds and runs, how data and interfaces behave, and whether failures, reruns, backups, and restoration produce the behavior implied by the source evidence.

Automated evidence review

Gaps

• The draft is appropriately cautious about the absence of runtime proof, but it still presents several source-level descriptions as “recorded capabilities” or “journeys.” The sign-on flow, account update, bill payment, transaction posting, and batch functions should be explicitly labelled as inferred or intended unless execution traces, return codes, screen captures, or transaction results exist.

• The evidence basis for several detailed behavioral claims is not clear. Examples include locking and rewriting records, handling concurrent updates, duplicate transaction detection, confirmation requirements, balance updates, reject processing, PF-key behavior, and routing by user type. The draft should identify the exact source statement or observation supporting each claim, or mark it as unresolved.

• Some statements may overstate what static evidence establishes. LISTCAT completion with condition code 0 proves that the catalog inquiry completed, not that the listed datasets were populated correctly, accessible to the application, or used by a functioning system. Similarly, declarations of MQ, DB2, IMS, CICS, FTP, Control-M, or UNIX interfaces do not establish configured or reachable endpoints.

• The draft does not clearly separate observed facts, source declarations, analyst reconstruction, and risk indicators. A compact evidence-status convention would reduce ambiguity, particularly for “reportedly,” “may,” “clearest flow,” “optional,” and “recorded journeys.”

• Citation integrity requires correction before reliance. Several evidence identifiers and filenames appear mismatched, including E0025 linked to evidence-E0029.md, E0007 linked to evidence-E0008.md, E0040 linked to evidence-E0041.md, E0045 linked to evidence-E0046.md, and E0033 linked to evidence-E0034.md. The transaction citations also alternate among COTRN01C.cbl, CBTRN01C.cbl, and related names without explaining whether these are different files or naming errors.

• The two supplied versions are not fully consistent. One says the material supports a “partial, source-level reconstruction,” while the other introduces detailed catalog totals, source ranges, observation counts, and the claim that LISTCAT completed with condition code 0. Those additions need direct evidence references and reconciliation with the first version.

• The draft identifies conflicting lengths and names but does not state what would resolve them. It should specify whether the conflicts arise from active layouts, migration formats, unload records, screen fields, copybooks, or obsolete artifacts. The same applies to DB201PLN/AWS01PLN, TRANFILE/TRANBKP, map and program names, FTP direction, and copybook coverage.

• The build discussion does not establish the exact semantics of COND=(4,LT) in the relevant job and procedure, including step names, return-code propagation, and whether NEWCOPY is conditional on the intended prior step. The apparent contradiction should remain an open verification item rather than a settled conclusion.

• Functional gaps remain for validation rules, field normalization, duplicate handling, identifier generation, uniqueness scope, locking, commits, rollback, restartability, and rejected-record treatment. The absence of CSLKPCDY is noted, but the draft should also identify which other missing copybooks, macros, maps, procedures, and configuration members prevent reconstruction.

• Interface gaps are broad but could be made more actionable. The draft should enumerate the missing contract elements for each interface: endpoint or resource name, record/message layout, encoding, ownership, timeout, retry, acknowledgment, error mapping, security, and version.

• Security observations need careful qualification. “Plaintext passwords,” “literal FTP credentials,” and “possible exposed CVV or government identifiers” should be tied to exact artifacts and distinguished between actual populated secrets, sample values, field definitions, and merely named fields. No confirmed exposure should be implied without access-control and content evidence.

• Recovery and operational gaps are correctly identified but lack acceptance criteria. The review should require evidence for job dependencies, restart points, idempotency, commit intervals, backup completeness, restore testing, reconciliation, audit trails, and behavior after partial failure.

• Ownership, environment, and baseline provenance remain unresolved. The draft should identify the missing authoritative inventory, source version, deployment target, dataset owner, interface owner, and configuration baseline needed to determine whether conflicting artifacts belong to one system or multiple variants.

• The final characterization plan is directionally sound but should state prerequisites and safeguards: isolated test data, nonproduction endpoints, credential handling, dataset backups, transaction rollback controls, and a documented mapping from each unresolved question to a reproducible test.