Now I have all the information I need. I can see the complete card name validation logic from lines 806-843. The logic uses the INSPECT statement to convert all alphabetic characters (both uppercase and lowercase) to spaces, then checks if anything remains after trimming. If anything remains, it means there were non-alphabetic characters (other than spaces), which triggers the error.

Business Rules Reference

Purpose

This document summarizes critical business rules that are implemented in the CardDemo codebase. As a developer, you must understand and enforce these rules when modifying existing code or adding new features.

Account Management Rules

Rule: Credit Limit Enforcement

Business Rule: Account balance cannot exceed the credit limit.

Implementation: CBTRN02C.cbl lines 407-413

IF WS-ACCT-CURR-BAL > WS-ACCT-CREDIT-LIMIT
    SET REJECT-REASON TO 102
    MOVE 'OVERLIMIT TRANSACTION' TO REJECT-REASON-DESC
    PERFORM WRITE-REJECT-TRAN

Why it matters: Prevents accounts from going overlimit. If you modify transaction posting, ensure this check remains in place.

Rule: Account Expiration Validation

Business Rule: Transactions received after account expiration date must be rejected.

Implementation: CBTRN02C.cbl lines 414-420

Why it matters: Prevents charging expired accounts. Check expiration date before posting transactions.

Rule: Default Debit Value

Business Rule: When account current cycle debit equals zero, set it to 2525.00.

Implementation: CBACT01C.cbl lines 236-238

Why it matters: Ensures accounts have minimum activity for testing/demonstration purposes. This is a demo rule you might remove in production.

Card Management Rules

Rule: Card Number Format Validation

Business Rule: Card numbers must be exactly 16 numeric digits.

Implementation: COCRDLIC.cbl lines 1017-1025, COCRDUPC.cbl lines 784-794

Why it matters: Ensures card number format consistency. Always validate card number format before writes.

Rule: Card Name Character Validation

Business Rule: Card embossed name can only contain alphabetic characters (A-Z, a-z) and spaces. No numbers, special characters, or punctuation marks are allowed.

Implementation: COCRDUPC.cbl lines 806-843

The validation logic works by converting all valid alphabetic characters to spaces, then checking if anything remains:

       1230-EDIT-NAME.
      *    Not BLANK
           SET FLG-CARDNAME-NOT-OK      TO TRUE
                                                            
      *    Not supplied                                                         
           IF CCUP-NEW-CRDNAME   EQUAL LOW-VALUES                               
           OR CCUP-NEW-CRDNAME   EQUAL SPACES                                   
           OR CCUP-NEW-CRDNAME   EQUAL ZEROS                                    
              SET INPUT-ERROR           TO TRUE                                 
              SET FLG-CARDNAME-BLANK  TO TRUE                                   
              IF WS-RETURN-MSG-OFF                                              
                 SET WS-PROMPT-FOR-NAME TO TRUE                                 
              END-IF                                                            
              GO TO  1230-EDIT-NAME-EXIT                                        
           END-IF                                                               
                                                                                
      *    Only Alphabets and space allowed                                     
           MOVE CCUP-NEW-CRDNAME        TO CARD-NAME-CHECK                      
           INSPECT CARD-NAME-CHECK                                              
             CONVERTING LIT-ALL-ALPHA-FROM                                      
                     TO LIT-ALL-SPACES-TO                                       
                                                                                
           IF FUNCTION LENGTH(FUNCTION TRIM(CARD-NAME-CHECK)) = 0               
              CONTINUE                                                          
           ELSE                                                                 
              SET INPUT-ERROR           TO TRUE                                 
              SET FLG-CARDNAME-NOT-OK   TO TRUE                                 
              IF WS-RETURN-MSG-OFF                                              
                 SET WS-NAME-MUST-BE-ALPHA  TO TRUE                             
              END-IF                                                            
              GO TO  1230-EDIT-NAME-EXIT                                        
           END-IF                                                               
                                                                                
           SET FLG-CARDNAME-ISVALID     TO TRUE                                 
           .                                                                    
       1230-EDIT-NAME-EXIT.                                                     
           EXIT                                                                 
           .

How it works: The INSPECT CONVERTING statement replaces all characters in LIT-ALL-ALPHA-FROM (which contains 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz') with spaces from LIT-ALL-SPACES-TO. After conversion, if the trimmed result has zero length, the name contained only valid characters. If any characters remain after trimming, they were invalid (numbers, punctuation, special characters) and the validation fails with error message "Card name can only contain alphabets and spaces".

Why it matters: Prevents invalid characters from being embossed on physical cards. Card embossing machines can only handle alphabetic characters and spaces. Invalid characters would cause production errors or illegible cards. Always validate the card name before any card creation or update operations.

Error message: When validation fails, the user sees: "Card name can only contain alphabets and spaces" (defined at line 183-184).

Rule: Card Expiration Date Range

Business Rule: Card expiry month must be 1-12, year must be 1950-2099.

Implementation: COCRDUPC.cbl lines 883-943

Why it matters: Prevents invalid expiration dates that would cause transaction authorization failures.

Rule: Card-Account Linkage

Business Rule: Each card must be linked to exactly one account.

Implementation: Cross-reference file (CCXREF) maintains this relationship

Why it matters: Foundation of transaction processing. Never create orphan cards or break card-account links.

Transaction Processing Rules

Rule: Transaction Validation Order

Business Rule: Transactions must be validated in this order: (1) card lookup, (2) account lookup, (3) business rules.

Implementation: CBTRN02C.cbl lines 370-378

PERFORM CHECK-XREF-RETURN
IF XREF-CARD-FOUND
    PERFORM READ-ACCTDAT-RECORD
    IF ACCTDAT-FOUND
        PERFORM VALIDATE-BUSINESS-RULES

Why it matters: Ensures proper error messages. Don't check business rules if card/account doesn't exist.

Rule: Invalid Card Rejection

Business Rule: If card number is not found in cross-reference file, reject with reason code 100.

Implementation: CBTRN02C.cbl lines 382-391

Why it matters: Prevents posting to non-existent cards. All transaction processing must validate card first.

Rule: Balance Update Logic

Business Rule: If transaction amount ≥ 0, add to current cycle credit. Otherwise, add to current cycle debit.

Implementation: CBTRN02C.cbl lines 547-552

ADD WS-TRAN-AMT TO ACCOUNT-CURR-BAL
IF WS-TRAN-AMT >= ZERO
    ADD WS-TRAN-AMT TO ACCOUNT-CURR-CYC-CREDIT
ELSE
    ADD WS-TRAN-AMT TO ACCOUNT-CURR-CYC-DEBIT

Why it matters: Determines how transactions affect cycle totals. Credits and debits are tracked separately for statement generation.

Rule: Transaction Category Balance Creation

Business Rule: When a transaction category balance record doesn't exist, create it. When it exists, update it.

Implementation: CBTRN02C.cbl lines 495-527

Why it matters: Enables spending analysis by category. Must handle both create and update cases.

Payment Processing Rules

Rule: Zero Balance Prevention

Business Rule: Payment cannot be processed if account balance ≤ 0.

Implementation: COBIL00C.cbl lines 198-206

IF ACCOUNT-CURR-BAL <= 0
    MOVE 'You have nothing to pay...' TO MESSAGEO

Why it matters: Prevents negative balance from payment. Check balance before allowing payment.

Rule: Full Balance Payment

Business Rule: Bill payment amount equals the full current balance.

Implementation: COBIL00C.cbl line 224

COMPUTE WS-TRAN-AMT = ACCOUNT-CURR-BAL * -1

Why it matters: CardDemo only supports full balance payments. If you need partial payments, modify this logic.

Rule: Payment Transaction Type

Business Rule: Bill payments must use transaction type '02' and category 2.

Implementation: COBIL00C.cbl lines 220-222

Why it matters: Ensures payments are correctly categorized in reports and statements.

Authorization Rules

Rule: Authorization Status Determination

Business Rule: If authorization response code = '00', status is 'A' (Approved). Otherwise, status is 'D' (Declined).

Implementation: COPAUS0C.cbl lines 536-540

IF AUTH-RESP-CD = '00'
    MOVE 'A' TO WS-APPROVAL-STATUS
ELSE
    MOVE 'D' TO WS-APPROVAL-STATUS

Why it matters: Standard authorization response codes. Response code '00' is the only success code.

Data Validation Rules

Rule: Account Number Format

Business Rule: Account numbers must be exactly 11 numeric digits, cannot be blank, spaces, or zeros.

Implementation: COACTUPC.cbl lines 725-756

Why it matters: Primary key for account lookups. Always validate format before file operations.

Rule: SSN Part 1 Invalid Values

Business Rule: First 3 digits of SSN cannot be 0, 666, or 900-999.

Implementation: COACTUPC.cbl lines 121-123

Why it matters: Follows real-world SSN validation rules. Important for customer data integrity.

Rule: Date of Birth Range Validation

Business Rule: Birth date year, month, and day must all be valid numeric values within acceptable ranges.

Implementation: COACTUPC.cbl lines 216-230

Why it matters: Prevents invalid dates that cause downstream processing errors.

Security Rules

Rule: Role-Based Menu Access

Business Rule: Admin users see admin menu, regular users see main menu. No crossover allowed.

Implementation: COSGN00C.cbl sign-on logic, menu programs filter based on user type

Why it matters: Fundamental security control. Never show admin functions to regular users, even if disabled.

Rule: User Type Values

Business Rule: User type must be 'A' (admin) or 'U' (regular user).

Implementation: Throughout user management programs

Why it matters: Binary classification drives all authorization decisions. Don't add new user types without updating all authorization checks.

Statement Generation Rules

Rule: Statement Page Size

Business Rule: Display maximum 5 transactions per statement page for readability.

Implementation: CBSTM03A.cbl statement formatting logic

Why it matters: Affects statement pagination and formatting. Change carefully to avoid layout issues.

Critical Rules Summary Table

Developer Guidelines

When Modifying Existing Code:

1. Identify affected business rules - Check this document before changing transaction or account logic
2. Preserve validation logic - Don't remove validation checks to "simplify" code
3. Test boundary conditions - Zero balances, credit limits, expired cards, invalid formats
4. Update rule documentation - If you change a rule, update this file

When Adding New Features:

1. Understand related rules - New card features must respect card format and linkage rules
2. Follow existing patterns - Use same validation approach as similar features
3. Document new rules - Add new business rules to this document
4. Consider downstream impact - How does your change affect statements, reports, batch processing?

Red Flags to Watch For:

• Bypassing validation "just this once"
• Hardcoded business values (credit limits, transaction types) instead of reference data
• Direct file updates without validation
• Removing "unnecessary" checks that enforce business rules
• Different validation logic in online vs. batch programs

Finding Rule Implementations

Search Patterns:

• Credit limit checks: CREDIT-LIMIT, OVERLIMIT, CURR-BAL
• Card validation: CARD-NUM, XREF, INVALID CARD
• Card name validation: CARD-NAME-CHECK, LIT-ALL-ALPHA-FROM, INSPECT CONVERTING
• Transaction posting: POST, UPDATE-ACCOUNT, TRANSACTION-AMT
• Authorization: AUTH-RESP, APPROVAL, DECLINE
• Balance updates: CURR-BAL, CYCLE-CREDIT, CYCLE-DEBIT

Key Programs:

• Transaction posting rules: CBTRN02C.cbl
• Card validation rules: COCRDUPC.cbl
• Account validation rules: COACTUPC.cbl
• Payment rules: COBIL00C.cbl
• Authorization rules: COPAUS0C.cbl