Loading...
This glossary defines key business terms and domain concepts that developers need to understand when working with the CardDemo codebase. Understanding these terms helps you navigate the code, understand variable names, and implement business logic correctly.
A credit facility assigned to a customer with a credit limit and current balance. Each account can have multiple credit cards linked to it.
Example: Account 00000000001 has a $5,000 credit limit with current balance of $1,250.
In code: Stored in ACCTDAT file, represented by CVACT01Y copybook, 11-digit account ID used as primary key.
A physical or virtual card with a 16-digit card number, linked to exactly one account. Used to make transactions.
Example: Card 4000123400004321 is linked to account 00000000001, expires 12/2025.
In code: Stored in CARDDAT file, represented by CVACT02Y copybook, card number is primary key, account ID is foreign key.
An individual person who holds one or more accounts. Contains personal information (name, address, SSN) and credit score.
Example: John Smith, SSN 123-45-6789, FICO score 720, address on file for account statements.
In code: Stored in CUSTDAT file, represented by CVCUS01Y copybook, customer ID links to accounts.
A single credit or debit to an account, such as a purchase, payment, or fee. Each transaction has unique ID, timestamp, amount, and merchant information.
Example: Transaction ID 0000000123, purchase at "Gas Station ABC" for $45.50 on 2025-10-15.
In code: Stored in TRANSACT file, represented by CVTRA05Y copybook, links to card number and account.
The maximum amount a customer can borrow on an account. System rejects transactions that would exceed this limit.
Example: Account has $5,000 credit limit, current balance is $3,200, so $1,800 credit is available.
Why developers care: Overlimit checks are enforced in transaction posting (CBTRN02C) and authorization (pending auth programs). Must calculate available credit correctly.
The total amount currently owed on an account, including all posted transactions minus payments.
Example: Previous balance $1,000 + purchases $500 - payment $200 = current balance $1,300.
Why developers care: Balance calculation must be accurate and consistent across all programs. Balance updates must be atomic to prevent race conditions.
A code classifying the nature of a transaction (purchase, payment, refund, fee, etc.). Determines how transaction affects account balance.
Example: Type '01' = Purchase (increases balance), Type '02' = Payment (decreases balance).
Why developers care: Transaction type drives balance calculation logic. Stored in TRANTYPE file, configured by admins.
A detailed classification within a transaction type (groceries, fuel, utilities, etc.). Used for spending analysis and reporting.
Example: Purchase transaction, Category 5411 = Grocery Stores.
Why developers care: Categories enable spending reports and statement breakdowns. Stored in TRANCATG file with descriptions.
A real-time request to approve a transaction before it's posted. Checks credit limit and fraud rules, returns approval or decline.
Example: Customer swipes card at store, authorization request checks available credit, returns response code '00' (approved).
Why developers care: Authorization subsystem (IMS DB + MQ) is separate from transaction posting. Pending authorizations must eventually match posted transactions.
A credit score (300-850) indicating customer creditworthiness. Higher scores indicate lower credit risk.
Example: Customer with FICO score 720 is considered "good credit," may qualify for higher credit limits.
Why developers care: FICO score is displayed on screens and statements but not used for business logic in current implementation. Field is maintained for potential future use (risk-based pricing, automatic credit limit adjustments).
The linkage between card number, account ID, and customer ID. Enables looking up account information from a card number.
Example: Card 4000123400004321 → Account 00000000001 → Customer 00001.
Why developers care: XREF file (CCXREF) is critical for transaction processing. All transaction postings start by looking up card in XREF to find account. Alternate index (CARDAIX) provides fast access by account ID.
A periodic (usually monthly) summary of account activity showing all transactions, payments, fees, and balance information.
Example: October 2025 statement for account 00000000001 lists 23 transactions totaling $845.67.
Why developers care: Statement generation (CBSTM03A) is a complex batch process that reads multiple files and formats output in text and HTML. Performance matters as it processes all accounts.
A payment made by customer to reduce account balance. In CardDemo, bill payment pays the full current balance.
Example: Customer pays $1,250 balance, system creates payment transaction and updates account balance to zero.
Why developers care: Bill payment (COBIL00C) creates a special transaction type '02' with predefined merchant info. Must validate account has balance > 0 before allowing payment.
A unique identifier for each system user. Used for authentication and determining user role.
Example: User ID "CSR001" for customer service representative, "ADMIN01" for administrator.
Why developers care: User ID is validated against USRSEC file during sign-on (COSGN00C). Must be passed in COMMAREA to subsequent programs for authorization checks.
A classification indicating user role: 'A' for admin, 'U' for regular user. Determines which functions are accessible.
Example: User type 'A' can access user administration, type 'U' can only access customer service functions.
Why developers care: User type drives menu display and function authorization. Check user type before allowing access to admin functions.
A data structure passed between CICS programs containing context information like user ID, screen data, and processing flags.
Example: COMMAREA contains user ID "CSR001", last screen visited, and any error messages to display.
Why developers care: COMMAREA (COCOM01Y copybook) maintains state in pseudo-conversational programs. Must be correctly passed on RETURN and XCTL commands to preserve context between screen interactions.
IBM's file storage system used for primary application data. Provides indexed access for fast retrieval by key.
Example: Account file (ACCTDAT) is a VSAM KSDS with account ID as primary key.
Why developers care: VSAM file access patterns (READ, WRITE, REWRITE, DELETE, STARTBR/READNEXT/ENDBR) are used throughout online programs. Must handle file status codes for error conditions.
A cumulative total of transaction amounts by category for each account. Used for spending analysis.
Example: Account 00000000001 has spent $450 in groceries (category 5411) this billing cycle.
Why developers care: Category balances (TCATBALF file) are updated during transaction posting. Must be created if doesn't exist, updated if exists. Uses account ID + category as composite key.
Reference data containing interest rates and terms organized by account group. Determines how interest is calculated.
Example: Account group 'A' has 18.99% APR, group 'B' has 14.99% APR for customers with higher credit scores.
Why developers care: Disclosure group (DISCGRP file) is currently read but not actively used for interest calculation in CardDemo. Field exists for demonstration of reference data management.
A CICS programming pattern where programs terminate after each user interaction and restart with user input. Efficient for terminal-based applications.
Example: User views account screen, presses Enter, program terminates and passes COMMAREA with account ID, new program instance restarts to process Enter key.
Why developers care: All online CardDemo programs use pseudo-conversational design. Must save context in COMMAREA on RETURN, retrieve it on program entry, and handle EIBCALEN = 0 on first execution.
The process of recording a transaction to the transaction file and updating the affected account's balance.
Example: $50 purchase transaction is posted: written to TRANSACT file, account balance increased by $50, category balance updated.
Why developers care: Transaction posting (CBTRN02C) must be atomic - all file updates must complete or all must be backed out. Validation rules (credit limit, expiration date) must be enforced before posting.
For Code Navigation: When you see field names like FD-ACCT-ID, WS-XREF-CARD-NUM, or TRAN-TYPE-CD, you'll understand what business entities they represent.
For Bug Fixes: When fixing a balance calculation issue, understanding the relationship between accounts, cards, transactions, and category balances helps you identify where the problem is.
For New Features: When adding functionality, knowing the domain model prevents you from creating duplicate entities or breaking business rules.
For Communication: Speaking the same language as business stakeholders makes requirements gathering and code reviews more effective.