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

Current System: Conceptual Information Model

Scope and status

Observed evidence describes a partially reconstructed CardDemo information model spanning accounts, customers, cards, users, transactions, authorization, fraud, classifications, cross-references, reports, statements, and import or export records. It establishes artifacts and intended behavior, not semantic completeness, successful execution, or one consistently deployed system. E0001 E0004 E0006 E0009 E0010 E0020 E0021

Core information concepts

Accounts and customers are represented in online and batch processing, while cards are connected through card-reference data. Transactions include accepted input and rejected validations; authorization and fraud information are separately identified. User-security records support user administration. Reports and statements represent derived or presented information, but their complete schemas, keys, timestamps, encodings, and transformation rules are unknown. E0002 E0003 E0008 E0016 E0017 E0021 E0022 E0024 E0037

The model also includes transaction-type categories and transaction types. A stated foreign-key relationship connects `TRANSACTION_TYPE_CATEGORY` to `TRANSACTION_TYPE`, with `ON DELETE RESTRICT`; the broader schema and referential-integrity rules are not established. E0010 E0011

Persistence and processing

Observed persistence mechanisms include VSAM KSDS files and indexes, DB2, IMS segments, MQ-related flows, and flat or batch files. The Transaction Type Management module is described as an optional extension maintaining data in both DB2 and VSAM. Other evidence connects customer and card programs to named VSAM datasets, account extraction and payment processing to `ACCTDAT`, and statement processing to `TRNXFILE`. These observations do not establish synchronization, precedence, or a single authoritative store. E0010 E0020 E0021 E0022 E0024

Programs and transactions form processing relationships around the information: account update and view handle account functions; user programs add, rewrite, and delete `USRSEC`; transaction processing writes validated records and rejects; reporting submits batch work; and sign-on routes validated users to administrative or general menus. The evidence does not establish complete call sequencing, commarea contracts, or runtime compatibility. E0002 E0008 E0017 E0025 E0034 E0038

States and rules

Observed information-processing states include validation, confirmation, acceptance, rejection, approval, decline, duplicate handling, end-of-file, concurrent update, backup, error, abend, and deployment. Rules address credentials, dates, balances, expiry, limits, duplicates, paging, retention, return codes, interest, fees, and deletion. Fraud criteria, calculations, checksums, filtering, and complete return-code semantics remain unknown. E0011 E0013 E0015 E0017 E0018 E0041 E0042 E0045

Inference: Validation appears intended to separate accepted processing from rejection handling, but decision ownership, rationale, lifecycle transitions, and recovery semantics are not established. E0003 E0008 E0022 E0025

Boundaries and unknowns

Interfaces include CICS, BMS, `XCTL`, VSAM, DB2, IMS, MQ, JCL, TDQs, REXX, FTP, sorting, and reporting tools. Authentication-related artifacts include `USRSEC`, RACF, and `DUSRSECJ`; enforcement, masking, encryption, audit, permissions, and network boundaries are unknown. E0001 E0032 E0033 E0035 E0036 E0039 E0040

Unknown: Complete conceptual schemas, entity cardinalities, identifiers, mappings, ownership, authoritative sources, transformations, retention, deployment alignment, and end-to-end consistency are not established by the supplied evidence. E0009 E0014 E0020 E0021 E0037 E0047