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

Diagrams

Architecture and relationships

The available evidence supports only a partial, source-level reconstruction of CARDDEMO/CARD-DEMO. It describes a heterogeneous legacy or simulated mainframe-oriented suite containing COBOL programs, CICS transactions, BMS maps, VSAM files, JCL and sequential-file processing, with optional or incompletely evidenced DB2, IMS, MQ, assembly, REXX, GSAM/BSAM, Control-M, and UNIX components. The evidence does not establish that these artifacts compile, bind, deploy, connect, or operate together as one integrated runtime system. Complete topology, ownership, deployment boundaries, and production use remain unknown README.md; CARDDEMO.CSD; E0001 E0010 E0017 E0038 E0044.

The clearest recorded online relationship is a CICS and BMS interaction. A user enters through sign-on transaction CC00, where COSGN00C uses the USRSEC data to validate credentials, redisplays errors, exits on PF3, and routes an authenticated administrator to COADM01C or another user to COMEN01C. The routing uses XCTL and a commarea. Subsequent functions reportedly use BMS maps, terminal I/O, paging, and VSAM browse or update operations. Recorded programs include account viewing and updating, card listing and search, bill payment, transaction processing, reporting, administration, and user maintenance. The complete screen sequence, action model, commarea contents, session state, and response behavior are not available [COSGN00C.cbl; COSGN00.bms; COSGN00.CPY] E0028 E0030 E0034 E0013 E0026.

The online programs appear to relate business functions to several VSAM-backed information areas. 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, including handling for missing records, concurrent updates, and customer-update failure. Bill payment reportedly checks account existence, positive balance, duplicate transaction identifiers, and confirmation before creating a transaction and updating a balance. These relationships are inferred from source descriptions and visible operations; validation details, identifier generation, uniqueness, concurrency, commit behavior, and non-confirmation handling remain unresolved, including because CSLKPCDY is absent E0025 E0029.

Transaction processing relates accounts, cards, limits, expiry information, references, balances, and possible reject output in DALYREJS. CBTRN02C visibly performs substantive validation and posting. By contrast, claims that CBTRN01C posts transactions are contradicted by the visible absence of WRITE, REWRITE, or DELETE operations in that program. The evidence therefore does not establish a single transaction-processing chain, nor atomicity, commit or rollback, reconciliation, or recovery across related updates [COTRN00C.cbl] [COTRN01C.cbl] [COTRN02C.cbl] [CBTRN01C.cbl] [CBTRN02C.cbl].

Batch relationships are represented through JCL, IDCAMS, sequential files, VSAM utilities, and reported scheduled workflows. Intended activities include initialization, loading and replacement, posting, interest and fee calculation, statements, reports, imports, exports, indexing, backup, and cleanup. REPROCT.ctl confirms a REPRO from FILEIN to FILEOUT, but does not establish filtering, validation, or downstream consumers. CBEXPORT and CBIMPORT are described, although the export layout is unavailable and a sequential-versus-indexed file relationship remains unresolved. Job order, EOF handling, partial updates, abends, restart, rerun, and compensation behavior are not established E0007 E0040 E0045 E0022.

The catalog evidence identifies reported data components under AWS.M2.CARDDEMO, including NONVSAM, DATA, INDEX, CLUSTER, and GDG entries, but does not provide a consistent authoritative inventory or topology. Reported layouts and keys conflict or are incomplete: accounts, cards, transactions, and customer records are variously described with different lengths; a ten-byte account ZIP conflicts with a five-byte screen field; and a 350-byte transaction layout conflicts with a 500-byte migration format. Copybook alignment, field semantics, encoding, lineage, retention, and protection of sensitive fields remain unresolved [LISTCAT.txt] [ACCTFILE.jcl] [CARDFILE.jcl] [TRANFILE.jcl] [XREFFILE.jcl] [CVACT01Y.cpy] [CVTRA05Y.cpy] E0002 E0036.

Optional relationships to DB2, IMS, and MQ are indicated rather than demonstrated as an integrated path. Authorization processing reportedly combines MQ, IMS, DB2, and VSAM, but queue names, endpoints, contracts, transformations, ownership, and cross-system atomicity are unknown. PAUTDTL1 declares 200 bytes while an unload specifies LRECL=206; relationships among AUTHFRDS, DBPAUTP0, and their differing error handling are unresolved. Other conflicting names and references include AWSTSSC.AUTHFRDS versus hard-coded CARDDEMO.AUTHFRDS, DB201PLN versus AWS01PLN, and TRANFILE versus TRANBKP [COPAUA0C.cbl] [COPAUS2C.cbl] [DBPAUTP0.dbd] [UNLDPADB.JCL] E0009 E0011.

Inventory ranges, observation totals, file extracts, diagram names, and reported relationships vary substantially. Consequently, the documented relationships should be treated as recorded declarations or intended operations, not as a confirmed runtime architecture. Build, bind, deployment, connectivity, execution, data correctness, security enforcement, and recovery relationships require execution-based characterization before they can be considered established.

Automated evidence review

Architecture and relationships — advisory review

Overall assessment

The draft is appropriately cautious and generally distinguishes source-level declarations from verified runtime behavior. It does not establish a single integrated architecture, and that conclusion is supported by the stated gaps, conflicting inventories, and absent execution evidence. However, several relationships are still phrased more strongly than the evidence appears to justify, and some conclusions depend on source descriptions rather than demonstrated call, data, or deployment relationships.

Unsupported or potentially overstated claims

• “Heterogeneous legacy or simulated mainframe-oriented suite” is a reasonable characterization, but “suite” and “mainframe-oriented” should remain descriptive rather than imply a deployable product boundary. The evidence establishes artifacts, not necessarily a coherent system.
• “The clearest recorded online relationship is a CICS and BMS interaction.” This is supported for CC00/COSGN00C, but the draft should distinguish confirmed source references from inferred runtime interaction. BMS map use does not prove successful CICS deployment or terminal execution.
• “Subsequent functions reportedly use BMS maps, terminal I/O, paging, and VSAM browse or update operations.” This should identify the specific programs and source evidence for each relationship. Otherwise it risks generalizing behavior from selected programs across the suite.
• “Account viewing reportedly reads cross-reference, account-master, and customer-master records” and the corresponding account-update and bill-payment descriptions may be source-level behaviors, not established end-to-end relationships. Confirm whether each file is directly referenced, reached through calls, or merely described in comments or documentation.
• The assertion that CBTRN01C does not post transactions because it has no visible WRITE, REWRITE, or DELETE is useful but incomplete. Absence of those verbs does not exclude posting through called programs, dynamic SQL, shared services, MQ, or indirect mechanisms. The conclusion should be limited to “no direct posting operation is visible in the supplied source.”
• “Optional authorization processing combines MQ, IMS, DB2, and VSAM” may overstate the evidence. If the artifacts are separate variants or partial implementations, describe this as “artifacts indicate possible relationships among…” rather than “combines.”
• “Reported scheduled workflows” and the listed batch activities establish intended or documented processing, not actual schedule order or execution. This distinction is mostly made, but should be applied consistently.

Internal contradictions or evidence-handling issues

• The draft says catalog evidence reports 209 entries, while also stating that inventories vary substantially and no authoritative inventory exists. This is not necessarily contradictory, but label 209 explicitly as one reported LISTCAT result, not the system inventory.
• Program naming is inconsistent: COTRN00C/COTRN01C/COTRN02C appear alongside CBTRN01C/CBTRN02C. Resolve whether these are distinct artifacts, naming variants, or transcription errors before presenting a transaction-processing relationship.
• Several citations appear mismatched:
• E0025 links to evidence-E0029.md.
• E0026 links to evidence-E0027.md.
• E0007 links to evidence-E0008.md.
• E0040 links to evidence-E0041.md.
• E0045 links to evidence-E0046.md.

These should be corrected because citation mismatch weakens otherwise cautious conclusions. - The first version says the CBTRN01C posting claim is contradicted by visible source, while the second says “transaction programs … update balances or account data” generally. Narrow the latter so it does not reintroduce the disputed claim. - “VSAM-backed information areas” may be too broad where the evidence only shows dataset declarations or utilities. Separate physical file type, logical business entity, and actual program access.

Architecture gaps

The section does not yet establish:

• program call graphs, including CALL, XCTL, LINK, dynamic calls, and invoked utilities;
• exact dataset-to-program read/write relationships;
• CICS region, transaction, program, mapset, and file-control configuration;
• commarea layouts, channel/container usage, session state, and transaction boundaries;
• whether VSAM files are shared by online and batch processing and how locking is coordinated;
• DB2 package/plan, IMS PSB/DBD, MQ queue, and external endpoint ownership;
• dataset naming resolution, aliases, DD statements, catalog locations, and environment-specific substitutions;
• job dependencies, scheduler definitions, restart points, and batch/online coexistence;
• deployment units, libraries, load modules, bind steps, and version alignment;
• security and identity propagation across CICS, batch, DB2, IMS, MQ, and FTP;
• authoritative record lineage, key definitions, encoding, and migration/conversion boundaries.

Unresolved questions requiring explicit disposition

1. Does COSGN00C actually invoke COADM01C and COMEN01C in the deployed CICS environment?
2. Which programs directly read or modify each VSAM cluster, and are the layouts compatible?
3. Is CBTRN01C a validation/orchestration step that calls a posting module, or is it non-posting?
4. Are CBTRN02C, CBTRN01C, and the COTRN* programs one flow or separate variants?
5. What do the 200-byte/206-byte authorization records represent, and which definition is authoritative?
6. Are TRANFILE and TRANBKP operationally related or merely similarly named datasets?
7. Do batch jobs consume the outputs of online processing, and what prevents partial or conflicting updates?
8. Which artifacts are executable and connected in one environment?

Recommended revision

Retain the cautious conclusion, but label every relationship as confirmed source reference, declared/intended relationship, inferred relationship, or unverified runtime relationship. Correct citation and program-name inconsistencies, and avoid treating absence of visible operations as proof that no indirect relationship exists.