Combined mainframe assessment

Account Data Extraction and Formatting Batch Utility

The CBACT01C program is a batch processing component of the CardDemo credit card management system. Its primary business purpose is to read master account information from a primary database and distribute, format, and restructure this data into multiple downstream files. This utility acts as a data preparation and integration bridge, ensuring that core account metrics are readily available for reporting, archiving, and external subsystems.

For every account record retrieved from the master file, the program extracts key financial and administrative details, including current balances, credit limits, and cycle activities. It standardizes date formats—specifically the card reissue date—by invoking an external date-formatting utility to ensure consistency across the system. Additionally, the program applies business rules to populate default financial values, such as setting a standard debit amount when no cycle debit activity is recorded, before writing the formatted record to the main output file.

In addition to the primary output, the program restructures the account data into an array-based format for a second output file. This file captures multi-period balance and debit snapshots for each account, populating specific data slots to facilitate trend analysis, historical tracking, or multi-value reporting in downstream applications.

To optimize storage and support varied data consumers, the program also writes to a third, variable-length output file. It splits the account information into two distinct record types—a short administrative record containing the account ID and active status, and a longer financial summary record containing balances, credit limits, and the reissue year. Both records are written sequentially to the same variable-format file, allowing downstream systems to process only the specific data segments they require.

The program features robust error-checking mechanisms that monitor all file operations. If any file access or formatting error occurs, the program logs the diagnostic status and safely terminates execution to prevent data corruption, ensuring high operational reliability and data integrity within the batch production environment.

Functional Overview

The CBACT01C program is a batch utility designed to process account records from an indexed VSAM Key-Sequenced Data Set (KSDS) named ACCTFILE-FILE . For every account record read sequentially from the input file, the program performs data transformations, formats dates using an external utility, and writes output records to three distinct sequential target files:

• OUT-FILE : A sequential file containing detailed account information.

• ARRY-FILE : A sequential file containing an array structure populated with a combination of mapped and hardcoded financial balances.

• VBRC-FILE : A variable-length sequential file. For each input account record, the program writes two separate records of different lengths (12 bytes and 39 bytes) to this file.

Detailed Business and Processing Logic

1. Initialization and File Operations

• The program begins execution by displaying a startup message.

• It attempts to open four files:

• ACCTFILE-FILE (Input, VSAM KSDS)

• OUT-FILE (Output, Sequential)

• ARRY-FILE (Output, Sequential)

• VBRC-FILE (Output, Variable-Length Sequential)

• If any file fails to open successfully (status other than '00' ), the program displays an error message and terminates abnormally.

2. Main Processing Loop

The program executes a sequential read loop on ACCTFILE-FILE until the End-of-File (EOF) condition is met (File Status '10' ). For each valid record retrieved:

• The raw input record is displayed in the system log.

• The program processes and writes data to the three output files sequentially.

3. Output File Generation Logic

A. Detailed Account Extract ( OUT-FILE )

• Direct Mapping : Key fields such as Account ID, Active Status, Current Balance, Credit Limit, Cash Credit Limit, Open Date, Expiration Date, Current Cycle Credit, and Group ID are mapped directly from the input record to the output record structure.

• Date Formatting :

• The program maps the input ACCT-REISSUE-DATE to the date-formatting parameter structure CODATECN-REC and to a working storage variable WS-REISSUE-DATE .

• It sets the input date format type to '2' (indicating YYYY-MM-DD ) and the desired output date format type to '2' (indicating YYYYMMDD ).

• It calls the external Assembler program COBDATFT to perform the date conversion.

• The formatted date ( CODATECN-0UT-DATE ) is then moved to OUT-ACCT-REISSUE-DATE .

• Conditional Debit Logic :

• The program checks the input ACCT-CURR-CYC-DEBIT .

• If the input debit amount is equal to zero, it overrides the output field OUT-ACCT-CURR-CYC-DEBIT with a default value of 2525.00 .

• Note : If the input debit amount is non-zero, the program does not copy the input value to the output record, leaving the output field unpopulated (retaining residual or uninitialized data).

• The completed record is written to OUT-FILE .

B. Array Account Extract ( ARRY-FILE )

• The array record structure ARR-ARRAY-REC is initialized to clear previous data.

• The Account ID is mapped to ARR-ACCT-ID .

• A 5-occurrence array ( ARR-ACCT-BAL ) is populated with a mix of mapped and hardcoded values:

• Occurrence 1 : Current Balance is mapped from ACCT-CURR-BAL ; Current Cycle Debit is set to a hardcoded value of 1005.00 .

• Occurrence 2 : Current Balance is mapped from ACCT-CURR-BAL ; Current Cycle Debit is set to a hardcoded value of 1525.00 .

• Occurrence 3 : Current Balance is set to a hardcoded value of -1025.00 ; Current Cycle Debit is set to a hardcoded value of -2500.00 .

• Occurrences 4 and 5 : Remain zero-filled due to the initialization step.

• The record is written to ARRY-FILE .

C. Variable-Length Record Extract ( VBRC-FILE )

For every single input account record, the program writes two separate records of different lengths to the variable-length file:

• Record 1 (Status Record) :

• The program initializes the VBRC-REC1 structure.

• It maps the Account ID and Account Active Status.

• It sets the variable record length indicator WS-RECD-LEN to 12 .

• It writes the 12-byte record to VBRC-FILE .

• Record 2 (Financial & Reissue Record) :

• The program maps the Account ID, Current Balance, and Credit Limit.

• It extracts the 4-digit reissue year ( WS-ACCT-REISSUE-YYYY ) parsed during the date-formatting step and maps it to VB2-ACCT-REISSUE-YYYY .

• It sets the variable record length indicator WS-RECD-LEN to 39 .

• It writes the 39-byte record to VBRC-FILE .

4. Program Termination

• Upon reaching the end of the input file, the program closes the input ACCTFILE-FILE .

• Note : The program does not explicitly close the three output files ( OUT-FILE , ARRY-FILE , and VBRC-FILE ) in its termination routine.

• It displays an execution end message and exits using GOBACK .

Important Constants

• CODATECN-TYPE = "2" : Specifies that the input date format to the formatting utility is YYYY-MM-DD .

• CODATECN-OUTTYPE = "2" : Specifies that the desired output date format from the formatting utility is YYYYMMDD .

• 2525.00 : Default debit amount applied to OUT-ACCT-CURR-CYC-DEBIT when the input debit is zero.

• 1005.00 / 1525.00 / -1025.00 / -2500.00 : Hardcoded financial values used to populate occurrences 1, 2, and 3 of the output array record.

• 12 : Record length specified for the first variable-length output record ( VBRC-REC1 ).

• 39 : Record length specified for the second variable-length output record ( VBRC-REC2 ).

• 999 : Abend code passed to the CEE3ABD system utility during abnormal termination.

Validation Logic

• File Status Validation :

• Open Operations : The program validates that the file status is '00' after opening each of the four files. Any other status is treated as a critical failure.

• Read Operations : The program validates that the read status is either '00' (successful read) or '10' (End of File). Any other status triggers an immediate failure.

• Write Operations : The program validates that write operations return a status of '00' or '10' . Any other status triggers an immediate failure.

• Data Condition Validation :

• Debit Zero Check : The program explicitly checks if ACCT-CURR-CYC-DEBIT EQUAL TO ZERO to determine whether to apply the default value of 2525.00 .

• Numeric Status Check : During error handling, the program checks if the file status is numeric or if the first byte is '9' (indicating a VSAM-specific operating system code) to format the error display appropriately.

Data Elements Processed

Input Elements ( ACCTFILE-FILE )

• ACCT-ID (11-digit numeric): Unique account identifier.

• ACCT-ACTIVE-STATUS (1-character alphanumeric): Account status indicator.

• ACCT-CURR-BAL (Signed numeric, 10 integer, 2 decimal): Current account balance.

• ACCT-CREDIT-LIMIT (Signed numeric, 10 integer, 2 decimal): Total credit limit.

• ACCT-CASH-CREDIT-LIMIT (Signed numeric, 10 integer, 2 decimal): Cash advance limit.

• ACCT-OPEN-DATE (10-character alphanumeric): Date the account was opened.

• ACCT-EXPIRAION-DATE (10-character alphanumeric): Account expiration date.

• ACCT-REISSUE-DATE (10-character alphanumeric): Date the account card was reissued.

• ACCT-CURR-CYC-CREDIT (Signed numeric, 10 integer, 2 decimal): Total credits in the current cycle.

• ACCT-CURR-CYC-DEBIT (Signed numeric, 10 integer, 2 decimal): Total debits in the current cycle.

• ACCT-GROUP-ID (10-character alphanumeric): Group identifier associated with the account.

Transformed and Output Elements

• OUT-ACCT-REISSUE-DATE (10-character alphanumeric): Reissue date reformatted to YYYYMMDD via COBDATFT .

• WS-ACCT-REISSUE-YYYY (4-character alphanumeric): Extracted year portion of the reissue date, written to the variable-length file.

• ARR-ACCT-BAL (Array of 5 occurrences): Contains mapped current balances and hardcoded cycle debits.

• WS-RECD-LEN (4-digit numeric): Controls the record length dynamically written to the variable-length file VBRC-FILE .

Exception and Error Handling

• I/O Error Detection : After every file operation (OPEN, READ, WRITE, CLOSE), the program evaluates the corresponding file status variable.

• File Status Formatting ( 9910-DISPLAY-IO-STATUS ) :

• If a file status is non-numeric or starts with '9' (indicating a VSAM binary status code), the program extracts the binary sub-codes and formats them into a 4-digit display structure ( FILE STATUS IS: NNNN ).

• For standard status codes, it formats them directly into the display structure.

• Abnormal Program Termination ( 9999-ABEND-PROGRAM ) :

• If any file operation returns an unexpected status code, the program displays a descriptive error message (e.g., 'ERROR READING ACCOUNT FILE' ), calls the status formatting routine, and invokes the IBM Language Environment (LE) abend service CEE3ABD .

• It passes an abend code of 999 and a timing parameter of 0 to force an immediate dump and termination.

Security and Authorization Checks

No explicit security checks identified. The program relies entirely on external dataset-level security (such as RACF or ACF2) managed by the operating system and JCL execution environment.

Performance Considerations

• Sequential VSAM Access : The program accesses the indexed VSAM KSDS file sequentially ( ACCESS MODE IS SEQUENTIAL ). This is highly efficient for batch processing where the entire file must be read.

• Double Write Operations : For every input record, the program performs two separate write operations to the variable-length file VBRC-FILE . This doubles the I/O overhead for this specific dataset.

• Lack of Commit/Checkpointing : The program does not implement intermediate commits or checkpointing. In the event of a failure mid-run, the entire step must be restarted, and output files must be cleared to prevent duplicate records.

• Missing File Closes : The program fails to close OUT-FILE , ARRY-FILE , and VBRC-FILE before exiting. While modern operating systems automatically close open files upon step termination, relying on this behavior can lead to buffered data loss or resource locks in certain legacy environments.

<h2

Card Account Data Extraction and Reporting Utility

The CBACT02C program is a batch utility within the CardDemo application designed to sequentially read and report credit or debit card information from a master indexed database. Its primary business purpose is to provide a straightforward mechanism for extracting, auditing, and verifying cardholder data stored within the system, serving as a foundational tool for administrative reporting and data validation.

During execution, the program processes individual card records containing essential business and security details. This includes the unique 16-digit card number, the associated 11-digit customer account identifier, the 3-digit card verification value (CVV), the cardholder's embossed name, the card's expiration date, and its current operational status (such as active or inactive).

The operational flow of the utility is structured and sequential. It begins by establishing a connection to the card data file. Once the file is successfully opened, the program enters a processing loop that retrieves each card record one by one. For every record successfully read, the utility outputs the complete card details to the system log or standard output stream, continuing this process until it reaches the end of the file.

To ensure operational reliability, the program incorporates robust error-handling routines. If an unexpected issue occurs during the file opening, reading, or closing phases, the utility captures the specific file status code. It then formats this code into a readable diagnostic message, logs the error details to assist system administrators in troubleshooting, and initiates a controlled abnormal termination of the program to safeguard data integrity.

Program Overview

The CBACT02C program is a batch COBOL utility designed to sequentially read and print the contents of an indexed card data file ( CARDFILE ). The program opens the file, loops through all records sequentially, displays each record's content to the standard output, and closes the file upon reaching the end of the file (EOF). It features robust error handling, including specialized formatting for VSAM file status codes, and abnormally terminates (ABENDs) using the IBM Language Environment service CEE3ABD if any file operation fails.

Important Constants

• 999 : The abnormal termination (ABEND) code passed to the CEE3ABD system utility.

• 0 : The timing parameter value passed to CEE3ABD .

• 'Y' : The state flag indicating that the End-of-File (EOF) has been reached.

• 'N' : The state flag indicating that active processing is ongoing.

• '00' : The standard COBOL file status code representing a successful I/O operation.

• '10' : The standard COBOL file status code representing End-of-File.

• 16 : The internal application result code ( APPL-EOF ) representing EOF.

• 12 : The internal application result code representing a general I/O error.

• 8 : The initial application result code set before opening or closing the file.

Validation Logic

Before and during processing, the program performs the following validation and integrity checks:

• File Status Verification : After every file I/O operation (OPEN, READ, and CLOSE), the program validates the CARDFILE-STATUS variable.

• A status of '00' is validated as successful, allowing the program to continue.

• During a READ operation, a status of '10' is validated as a normal End-of-File condition, which gracefully stops the processing loop.

• Any other status code is treated as an integrity failure, triggering error reporting and an immediate program abend.

• File Status Type Validation : In the status display routine, the program checks if IO-STATUS is non-numeric or if the first character of the status is '9' . This validates whether the error is a standard COBOL file status or a VSAM-specific operating system status code, determining how the error code is parsed and formatted.

Data Elements Processed

• CARDFILE-FILE : The input indexed VSAM dataset (KSDS) containing card records.

• CARD-RECORD : The Working-Storage structure into which each record is read. It contains the following fields:

• CARD-NUM (PIC X(16)): The primary key of the record, representing the credit card number.

• CARD-ACCT-ID (PIC 9(11)): The account identifier associated with the card.

• CARD-CVV-CD (PIC 9(03)): The card verification value.

• CARD-EMBOSSED-NAME (PIC X(50)): The cardholder's name as embossed on the card.

• CARD-EXPIRAION-DATE (PIC X(10)): The expiration date of the card.

• CARD-ACTIVE-STATUS (PIC X(01)): The status flag indicating if the card is active.

• CARDFILE-STATUS / IO-STATUS : Two-byte file status variables used to capture and evaluate the result of file operations.

• IO-STATUS-04 : A formatted 4-character field used to display the file status in a standardized format.

• TWO-BYTES-BINARY / TWO-BYTES-ALPHA : A redefinition structure used to convert binary VSAM status codes (when the status starts with '9') into a displayable numeric format.

• APPL-RESULT : An internal status variable used to control program flow based on the success or failure of file operations.

Exception and Error Handling

• I/O Error Detection : If any file operation (OPEN, READ, CLOSE) returns a status other than '00' (or '10' for READ), the program initiates its error handling routine.

• Error Reporting : The program displays a specific error message (e.g., 'ERROR OPENING CARDFILE' , 'ERROR READING CARDFILE' , or 'ERROR CLOSING CARDFILE' ). It then calls 9910-DISPLAY-IO-STATUS to format and print the file status.

• VSAM Status Formatting : If the file status is non-numeric or starts with '9' , the program extracts the second byte of the status as a binary value, converts it to a 3-digit integer, and displays it alongside the first character (e.g., 9 followed by the binary code converted to decimal). Otherwise, it displays the standard 2-digit status padded with leading zeros.

• Abnormal Termination (ABEND) : After displaying the error details, the program calls 9999-ABEND-PROGRAM , which invokes the IBM Language Environment abend routine CEE3ABD with an abend code of 999 and a timing parameter of 0 . This terminates execution immediately and generates a dump for debugging.

Security and Authorization Checks

No explicit security checks identified. The program relies on external mainframe security, such as RACF (Resource Access Control Facility), to control access to the CARDFILE dataset at the JCL/operating system level.

Performance Considerations

• Sequential Access of Indexed File : The program accesses an indexed file ( ORGANIZATION IS INDEXED ) using ACCESS MODE IS SEQUENTIAL . This is highly efficient for reading the entire dataset from beginning to end, as it avoids random index lookups for each record.

• No Commit/Checkpointing : Since this is a read-only program that does not update any databases or files, there is no need for commit processing, checkpointing, or transaction logging.

• Console I/O : The program uses DISPLAY statements to print every record. In a high-volume production environment, displaying thousands of records to the system console or job log ( SYSOUT ) can cause significant I/O overhead and inflate spool usage. If the dataset is large, redirecting this output or writing to a sequential report file would be more performant.

<h2

Batch Utility for Reading and Reporting Card Account Cross-Reference Data

The CBACT03C program is a batch utility within the CardDemo application designed to retrieve and display account cross-reference information. In credit card processing systems, maintaining a clear link between physical cards, customer profiles, and financial accounts is essential. This program serves as an administrative and diagnostic tool to extract and output these relationships from the master cross-reference data store.

At its core, the program processes records that map individual credit card numbers to their corresponding customer and account identifiers. Each record contains a 16-digit card number, a 9-digit customer ID, and an 11-digit account ID. By reading this data, the program provides visibility into how credit cards are linked to specific customer accounts, which is vital for auditing, troubleshooting, and system reconciliation.

During execution, the program operates sequentially. It opens the indexed cross-reference file and enters a processing loop, reading each record one by one until it reaches the end of the file. As each valid record is retrieved, its contents are written to the system's standard output log, allowing administrators to view the complete mapping of cards to accounts. Once all records have been processed, the program closes the file and terminates normally.

To ensure operational reliability, the utility incorporates structured error handling for all file interactions. If an error occurs during the opening, reading, or closing of the cross-reference file, the program captures the file status, formats a diagnostic error message for system operators, and triggers a controlled abnormal termination. This prevents the program from failing silently and ensures that data access issues are immediately flagged for technical support.

Business Logic

The primary purpose of the CBACT03C program is to sequentially read and print the contents of an indexed Account Cross-Reference VSAM dataset ( XREFFILE ).

The execution flow of the program is structured as follows:

Initialization :

• The program displays a startup message: 'START OF EXECUTION OF PROGRAM CBACT03C' .

• It attempts to open the cross-reference file ( XREFFILE-FILE ) in INPUT mode.

Sequential Processing Loop :

• The program executes a processing loop that continues until the END-OF-FILE flag is set to 'Y' .

• Within each iteration, it calls the read routine ( 1000-XREFFILE-GET-NEXT ) to retrieve the next record from the file.

• Redundant Display Behavior : If a record is successfully read (File Status '00' ), the program displays the record contents twice:

• First, inside the read routine ( 1000-XREFFILE-GET-NEXT ) immediately after a successful read.

• Second, in the main control loop after verifying that the END-OF-FILE flag remains 'N' .

• When the end of the file is reached (File Status '10' ), the END-OF-FILE flag is set to 'Y' , which terminates the loop.

Termination :

• The program closes the XREFFILE-FILE .

• It displays a completion message: 'END OF EXECUTION OF PROGRAM CBACT03C' .

• The program terminates and returns control to the operating system via GOBACK .

Important Constants

• APPL-AOK (Value 0 ) : Represents a successful application operation (e.g., successful file open, read, or close).

• APPL-EOF (Value 16 ) : Represents the End-of-File condition.

• ABCODE (Value 999 ) : The specific abnormal termination code passed to the IBM Language Environment abend utility.

• File Status '00' : Standard COBOL file status indicating successful completion of an I/O operation.

• File Status '10' : Standard COBOL file status indicating that the end of the file has been reached during a sequential read.

Validation Logic

The program does not perform business-level validation on the data fields contained within the records. Instead, its validation logic is strictly focused on technical I/O integrity and file status verification:

• File Open Validation : After executing the OPEN INPUT statement, the program verifies if XREFFILE-STATUS is equal to '00' . Any other status is treated as a critical failure.

• File Read Validation : During sequential retrieval, the program checks XREFFILE-STATUS .

• A status of '00' is validated as a successful read.

• A status of '10' is validated as a normal End-of-File condition.

• Any other status code is treated as an unexpected I/O error.

• File Close Validation : After executing the CLOSE statement, the program verifies if XREFFILE-STATUS is equal to '00' . Any other status triggers an error routine.

Data Elements Processed

• FD-XREF-CARD-NUM / XREF-CARD-NUM : A 16-character alphanumeric field representing the credit card number. This field serves as the primary record key for the indexed VSAM file.

• XREF-CUST-ID : A 9-digit numeric field representing the unique customer identifier associated with the card.

• XREF-ACCT-ID : An 11-digit numeric field representing the unique account identifier associated with the card.

• XREFFILE-STATUS / IO-STATUS : Two-character alphanumeric fields used to capture and evaluate the status codes returned by the file system after every I/O operation.

• IO-STATUS-04 : A formatted 4-character display field used to present file status codes in a readable format during error reporting.

Exception and Error Handling

If any file operation (Open, Read, or Close) fails with an unexpected status code, the program initiates a standardized abnormal termination sequence:

• Error Logging : The program displays a specific error message indicating where the failure occurred (e.g., 'ERROR READING XREFFILE' , 'ERROR OPENING XREFFILE' , or 'ERROR CLOSING XREFFILE' ).

• Status Formatting ( 9910-DISPLAY-IO-STATUS ) :

• If the file status is non-numeric or begins with '9' (indicating a VSAM-specific operating system status), the program extracts the binary value of the second status byte, converts it to a 3-digit integer, and displays it alongside the first character (e.g., 9 followed by the binary sub-code).

• If the status is standard numeric, it formats it as a 4-digit number with leading zeros (e.g., 0030 ) and displays it.

• Abnormal Termination ( 9999-ABEND-PROGRAM ) :

• The program displays 'ABENDING PROGRAM' .

• It sets the timing parameter to 0 and the abend code to 999 .

• It calls the IBM Language Environment dump and abend utility CEE3ABD using these parameters to force an immediate task termination and generate diagnostic logs.

Security and Authorization Checks

No explicit security checks identified. The program relies entirely on mainframe operating system-level security (such as IBM RACF) to control dataset access permissions for the physical file associated with the XREFFILE DD statement.

Performance Considerations

• Sequential Access Mode : The program accesses the indexed VSAM file sequentially ( ACCESS MODE IS SEQUENTIAL ). This is the most efficient method for reading an entire dataset from beginning to end, as it minimizes index lookups.

• I/O Overhead : The program contains redundant DISPLAY statements that write the entire CARD-XREF-RECORD to the system output ( SYSOUT ) twice for every record processed. In a high-volume production environment containing millions of cross-reference records, this redundant console logging will cause severe I/O bottlenecks and generate excessively large spool files.

<h2

Credit Card Account Monthly Interest Calculation and Posting Batch Process

This batch program is a core financial component of the CardDemo credit card processing system, responsible for calculating and posting monthly interest charges to customer accounts. By processing outstanding balances categorized by specific transaction types (such as purchases or cash advances), the program ensures that finance charges are accurately assessed and applied to each account according to its associated terms.

The program sequentially processes transaction category balances for each account. For every unique account, it retrieves master account details and cross-references the account with its associated card number. To determine the correct interest rate, the program matches the account's group classification, transaction type, and transaction category against a disclosure group registry. If a specific rate structure is not defined for an account group, the system automatically falls back to a standardized default interest rate to ensure continuous processing.

Once the applicable interest rate is determined, the program calculates the monthly interest charge based on the outstanding balance for that specific transaction category. For every calculated interest charge, the program generates a new system-initiated transaction record. This transaction includes details such as the calculated interest amount, a standardized description, the associated card number, and a current timestamp, which is then written to an output transaction file for downstream ledger posting.

As the program aggregates the calculated interest across different transaction categories for an account, it maintains a running total of the monthly interest. When the program finishes processing all categories for a given account, it updates the master account record. The total accumulated interest is added to the account's current balance, and the current cycle's credit and debit accumulators are reset to prepare the account for the next billing cycle.

Business Logic

The program CBACT04C is a batch COBOL program designed to calculate monthly interest for credit card accounts based on their category balances and applicable interest rates. It processes transaction category balances, computes interest, generates system transactions for the calculated interest, and updates the account master balances.

1. Initialization and File Processing

• Parameter Input : The program accepts an external parameter containing a 10-character date ( PARM-DATE ), which is used during transaction record generation.

• File Operations : Upon execution, the program opens five files:

• TCATBAL-FILE (Input): Contains transaction category balances.

• XREF-FILE (Input): Cross-references account IDs to card numbers.

• DISCGRP-FILE (Input): Contains disclosure group interest rates.

• ACCOUNT-FILE (I-O): Contains account master records.

• TRANSACT-FILE (Output): Stores generated interest transactions.

2. Sequential Balance Processing and Account Grouping

• The program reads the TCATBAL-FILE sequentially.

• It groups transaction category balance records by Account ID ( TRANCAT-ACCT-ID ).

• Account Change Detection :

• When a new Account ID is encountered (or on the first record):

• If it is not the first record processed, the program updates the previous account's master record with the accumulated interest.

• It resets the accumulated interest accumulator ( WS-TOTAL-INT ) to zero.

• It retrieves the new account's master record from ACCOUNT-FILE using the Account ID.

• It retrieves the card cross-reference record from XREF-FILE using the Account ID to obtain the associated card number ( XREF-CARD-NUM ).

3. Interest Rate Retrieval and Fallback Logic

• For each transaction category balance record, the program attempts to retrieve the interest rate from DISCGRP-FILE using a composite key consisting of:

• Account Group ID ( ACCT-GROUP-ID from the account master record)

• Transaction Category Code ( TRANCAT-CD )

• Transaction Type Code ( TRANCAT-TYPE-CD )

• Fallback Mechanism : If no specific disclosure group record is found (File Status '23' ), the program displays a warning and attempts to read a default interest rate by setting the Account Group ID to 'DEFAULT' while keeping the same transaction category and type codes.

4. Interest Calculation and Transaction Generation

• If the retrieved interest rate ( DIS-INT-RATE ) is non-zero, the program performs the following:

• Monthly Interest Calculation :

$$\text{Monthly Interest} = \frac{\text{Transaction Category Balance} \times \text{Interest Rate}}{1200}$$

• Accumulation : The calculated monthly interest is added to the account's total accumulated interest ( WS-TOTAL-INT ).

• Transaction Generation : A system-generated transaction record is created and written to TRANSACT-FILE with the following details:

• Transaction ID : A concatenation of PARM-DATE and a sequential suffix ( WS-TRANID-SUFFIX ).

• Transaction Type : '01' (representing interest/finance charges).

• Transaction Category : '05' .

• Source : 'System' .

• Description : 'Int. for a/c [Account ID]' .

• Amount : The calculated monthly interest.

• Card Number : Retrieved from the cross-reference file.

• Timestamps : Current system timestamp in DB2 format ( YYYY-MM-DD-HH.MIN.SS.MIL0000 ).

5. Fee Calculation (Stub)

• The program contains a placeholder paragraph 1400-COMPUTE-FEES intended for fee calculations, which is currently not implemented.

6. Account Master Update and Logic Flaw

• Account Update : When updating an account, the program:

• Adds the accumulated interest ( WS-TOTAL-INT ) to the current account balance ( ACCT-CURR-BAL ).

• Resets the current cycle credit ( ACCT-CURR-CYC-CREDIT ) and cycle debit ( ACCT-CURR-CYC-DEBIT ) fields to zero.

• Rewrites the updated record back to ACCOUNT-FILE .

• Critical Logic Flaw : Due to the structure of the main processing loop ( PERFORM UNTIL END-OF-FILE = 'Y' ), when the end of the TCATBAL-FILE is reached, the loop terminates immediately. As a result, the final account processed in the batch is never updated in ACCOUNT-FILE because the final 1050-UPDATE-ACCOUNT call is located in an unreachable ELSE branch of the loop.

Important Constants

• Transaction Type Code (Interest) : '01'

• Transaction Category Code (Interest) : '05'

• Transaction Source : 'System'

• Default Disclosure Group ID : 'DEFAULT'

• Abend Code : 999

• File Status Success : '00'

• File Status End-of-File (EOF) : '10'

• File Status Key Not Found : '23'

Validation Logic

• File Open Status Verification : After opening each of the five files, the program verifies that the file status is '00' . Any other status code triggers an immediate program abend.

• Sequential Read Validation : During sequential reads of TCATBAL-FILE , the program checks for status '00' (success) and '10' (EOF). Any other status code is treated as a critical error and triggers an abend.

• Random Read Validation :

• Account File : If a read on ACCOUNT-FILE fails with an INVALID KEY condition, the program displays an "ACCOUNT NOT FOUND" message. It then checks the file status; if it is not '00' , the program abends.

• Cross-Reference File : If a read on XREF-FILE fails with an INVALID KEY condition, the program displays an "ACCOUNT NOT FOUND" message. If the file status is not '00' , the program abends.

• Disclosure Group File : If a read on DISCGRP-FILE returns status '23' (Key Not Found), the program handles this as a valid business condition and triggers the fallback logic to search for the 'DEFAULT' group. Any status other than '00' or '23' triggers an abend.

• Write/Rewrite Validation :

• Rewriting to ACCOUNT-FILE and writing to TRANSACT-FILE require a file status of '00' . Any other status code results in an abend.

• Interest Rate Check : The program verifies that DIS-INT-RATE is not equal to zero before executing interest calculations and transaction generation.

Data Elements Processed

Input Parameters

• PARM-DATE : A 10-character date passed from the external execution environment, used as a prefix for generated transaction IDs.

Key Identifiers

• TRANCAT-ACCT-ID / FD-ACCT-ID / FD-XREF-ACCT-ID / ACCT-ID : The 11-digit account number used to identify the customer account across the balance, master, and cross-reference files.

• XREF-CARD-NUM : The 16-digit card number retrieved from the cross-reference file and written to the output transaction record.

• ACCT-GROUP-ID / FD-DIS-ACCT-GROUP-ID : The 10-character group identifier used to determine the interest rate structure.

• TRANCAT-CD / FD-DIS-TRAN-CAT-CD / TRAN-CAT-CD : The 4-digit transaction category code.

• TRANCAT-TYPE-CD / FD-DIS-TRAN-TYPE-CD / TRAN-TYPE-CD : The 2-character transaction type code.

• TRAN-ID : A 16-character unique transaction identifier generated by concatenating PARM-DATE and WS-TRANID-SUFFIX .

Financial Amounts and Balances

• TRAN-CAT-BAL : The current balance for a specific transaction category, used as the principal for interest calculation.

• DIS-INT-RATE : The interest rate retrieved from the disclosure group file.

• WS-MONTHLY-INT : The calculated interest amount for the current category balance.

• WS-TOTAL-INT : The accumulated interest across all categories for the current account.

• ACCT-CURR-BAL : The current outstanding balance of the account, updated with the accumulated interest.

• ACCT-CURR-CYC-CREDIT / ACCT-CURR-CYC-DEBIT : Cycle credit and debit accumulators, reset to zero during the account update.

• TRAN-AMT : The transaction amount written to the output file (set to WS-MONTHLY-INT ).

Exception and Error Handling

• File Status Formatting ( 9910-DISPLAY-IO-STATUS ) : When an I-O error occurs, the program formats the file status. If the status is non-numeric or represents a VSAM status code (first character '9' ), it extracts the binary sub-codes to display a detailed 4-digit error status.

• Abnormal Program Termination ( 9999-ABEND-PROGRAM ) : In the event of an unrecoverable file status error, the program displays "ABENDING PROGRAM" and calls the IBM Language Environment abend service CEE3ABD with an abend code of 999 and a timing parameter of 0 to terminate execution and generate a dump.

• Missing Master Records : If an account master or cross-reference record is missing for a processed balance, the program displays a console message but relies on the subsequent file status check to trigger the standard abend routine.

Security and Authorization Checks

No explicit security checks identified.

Performance Considerations

• Sequential vs. Random Access :

• TCATBAL-FILE is processed sequentially, which is optimal for batch processing of all category balances.

• ACCOUNT-FILE , XREF-FILE , and DISCGRP-FILE are accessed randomly. Because these are indexed files, performing random reads for every account change and category balance record can introduce significant I/O overhead if the dataset is large.

• I/O Overhead :

• A random read on DISCGRP-FILE is performed for every transaction category balance record. If accounts have multiple category balances, this results in repetitive disk I/O.

• An output transaction is written to TRANSACT-FILE for every non-zero interest calculation, increasing write I/O.

• Lack of Commit/Checkpointing : The program does not implement database commits, checkpointing, or restartability logic. If the program abends mid-run, the ACCOUNT-FILE (opened in I-O mode) will be left in a partially updated state, requiring a file restore before restarting the job.

<h2

CardDemo Customer Data Retrieval and Reporting Utility

This batch utility program is a core component of the CardDemo application, designed to sequentially retrieve and display comprehensive customer profile information from the primary customer database. Its primary business purpose is to serve as an administrative reporting and data verification tool, allowing system operators and business analysts to inspect the active customer registry.

The program processes detailed customer records containing sensitive and critical business data. This includes personal identification details such as full names, Social Security Numbers, government-issued IDs, and dates of birth. It also handles contact information, including multi-line physical addresses and telephone numbers, alongside financial attributes like electronic funds transfer (EFT) account identifiers, primary cardholder indicators, and FICO credit scores.

Operationally, the utility executes in a sequential batch flow. It begins by establishing a secure connection to the indexed customer data store. Once the file is successfully opened, the program enters a processing loop that reads each customer record one by one. For every record retrieved, the system outputs the complete customer profile to the system log for reporting purposes, continuing this cycle until it reaches the end of the database.

To ensure operational reliability and ease of maintenance, the utility features robust error-handling capabilities. It continuously monitors the status of all file operations. If an unexpected error occurs during the opening, reading, or closing of the customer database, the program captures the diagnostic status codes, logs a detailed error message to assist system administrators, and triggers a controlled abnormal termination to prevent data corruption or incomplete processing.

Functional Overview

The CBCUS01C program is a batch COBOL utility designed to sequentially read and print the contents of an indexed customer master file ( CUSTFILE ). The program opens the file, loops through all records from the beginning to the end of the file, outputs the record contents to the system display (SYSOUT), and closes the file before terminating.

A notable characteristic of this program's processing logic is that every successfully read customer record is displayed twice:

• Once inside the read routine ( 1000-CUSTFILE-GET-NEXT ) immediately after a successful read.

• A second time in the main processing loop of the PROCEDURE DIVISION after control returns from the read routine.

Important Constants

• APPL-AOK (Value 0 ): Condition name indicating a successful file operation or application state.

• APPL-EOF (Value 16 ): Condition name indicating that the End-Of-File (EOF) has been reached on the input file.

• ABCODE (Value 999 ): The abnormal termination code passed to the IBM Language Environment (LE) abend service.

• TIMING (Value 0 ): Timing parameter passed to the abend service, specifying immediate termination without delay.

• END-OF-FILE Flags:

• 'N' : Indicates there are more records to process.

• 'Y' : Indicates the end of the file has been reached.

Validation Logic

• File Status Code Verification: The program performs strict validation on the 2-character COBOL File Status key ( CUSTFILE-STATUS ) after every file system interaction:

• Open Validation: Verifies that the status is exactly '00' (Success). Any other status is treated as a critical failure.

• Read Validation: Validates if the status is '00' (Success) or '10' (End of File). Any other status (such as a hardware error or locked record) is treated as a critical failure.

• Close Validation: Verifies that the status is exactly '00' (Success). Any other status is treated as a critical failure.

• No Field-Level Validation: The program does not perform any data integrity or format validation (such as numeric checks on SSN, FICO score, or date formats) on the individual fields of the customer record before displaying them. It relies entirely on the structural integrity of the VSAM file.

Data Elements Processed

• CUSTFILE-FILE : The input indexed VSAM dataset (KSDS).

• FD-CUST-ID (PIC 9(09)): The primary key of the indexed file, representing the unique Customer Identifier.

• CUSTOMER-RECORD : The 500-byte target structure into which the file records are read. Key fields within this structure include:

• CUST-ID (PIC 9(09)): Customer Identifier.

• CUST-FIRST-NAME (PIC X(25)), CUST-MIDDLE-NAME (PIC X(25)), CUST-LAST-NAME (PIC X(25)): Customer name components.

• CUST-ADDR-LINE-1 / 2 / 3 (PIC X(50) each): Street address lines.

• CUST-ADDR-STATE-CD (PIC X(02)), CUST-ADDR-COUNTRY-CD (PIC X(03)), CUST-ADDR-ZIP (PIC X(10)): Geographic address details.

• CUST-PHONE-NUM-1 / 2 (PIC X(15) each): Contact phone numbers.

• CUST-SSN (PIC 9(09)): Social Security Number.

• CUST-GOVT-ISSUED-ID (PIC X(20)): Government-issued identification number.

• CUST-DOB-YYYY-MM-DD (PIC X(10)): Customer Date of Birth.

• CUST-EFT-ACCOUNT-ID (PIC X(10)): Electronic Funds Transfer Account ID.

• CUST-PRI-CARD-HOLDER-IND (PIC X(01)): Primary cardholder indicator flag.

• CUST-FICO-CREDIT-SCORE (PIC 9(03)): Customer's FICO credit score.

• CUSTFILE-STATUS / IO-STATUS : 2-character status variables used to capture and evaluate VSAM I/O return codes.

• IO-STATUS-04 : A formatted 4-character alphanumeric field used to construct a readable file status code for error reporting.

Exception and Error Handling

• I/O Failure Detection: If any file operation (Open, Read, or Close) returns an unexpected file status code, the program bypasses normal processing and branches to error handling.

• File Status Formatting ( Z-DISPLAY-IO-STATUS ):

• If the file status is non-numeric or begins with '9' (indicating a VSAM-specific operating system/file system error), the program extracts the second byte of the status, redefines it as a binary value, and formats it into a 4-digit display string as 9NNN (where NNN is the binary value of the second byte).

• For standard COBOL file status codes, it formats the status as 00XX (where XX is the 2-character status).

• The formatted status is displayed to the console: FILE STATUS IS: NNNN [status] .

• Abnormal Program Termination ( Z-ABEND-PROGRAM ):

• Upon encountering a critical I/O error, the program displays the message 'ABENDING PROGRAM' .

• It calls the IBM Language Environment service CEE3ABD using ABCODE ( 999 ) and TIMING ( 0 ) to force an immediate abnormal termination (ABEND) of the batch job step, preventing subsequent steps in the JCL from executing.

Security and Authorization Checks

• No explicit security checks identified. The program relies entirely on mainframe dataset-level security (such as RACF or ACF2) to control read access to the physical CUSTFILE dataset at the JCL execution level.

Performance Considerations

• Sequential Access Mode: The program accesses the indexed VSAM file using ACCESS MODE IS SEQUENTIAL . This is the most efficient access method for reading an entire dataset from start to finish, as it allows the operating system to utilize read-ahead buffering.

• I/O Overhead (SYSOUT): The program executes two DISPLAY statements for every single customer record processed. In a production environment with a large volume of customer records, writing excessive data to SYSOUT will cause severe I/O bottlenecks, significantly increase execution time, and consume excessive system spool space.

<h2

CardDemo Branch Migration Data Export Utility

The CardDemo Branch Migration Data Export Utility is a batch processing program designed to facilitate the migration of credit card and customer data during branch restructuring or system integration. Its primary business purpose is to consolidate disparate customer-related information from multiple source databases into a single, standardized sequential export file. This consolidated file serves as the primary data payload for downstream migration and ingestion systems.

To build a complete profile for migration, the utility extracts data across five core business areas. It reads comprehensive customer profiles (including contact details and credit scores), account financial statuses (such as balances and credit limits), card cross-reference mappings, historical transaction records, and active card details. By gathering these interrelated data points, the program ensures that no critical customer or financial history is left behind during the migration process.

The output of this utility is a unified, multi-record export file where each record is formatted with a standardized metadata header. This header includes a record type indicator (distinguishing customers, accounts, transactions, cross-references, and cards), a precise generation timestamp, a sequential tracking number, and regional branch identifiers. The specific business data for each entity is appended to this header, creating a highly structured and optimized file layout that simplifies parsing for target systems.

Operating in a sequential batch execution flow, the program processes each data category systematically. It incorporates strict validation and error-handling protocols; if any file access or write operation encounters an issue, the program immediately terminates processing to prevent the generation of incomplete or corrupted export files. Upon successful completion, the utility outputs a detailed summary report to the system logs, detailing the exact number of records processed for each category and the grand total, providing immediate verification for data audit and reconciliation teams.

Business Logic

The CBEXPORT program is a batch COBOL utility designed to consolidate and export normalized customer, account, cross-reference, transaction, and card data from five separate indexed VSAM files into a single, multi-record sequential export file. This consolidated file is structured for branch migration and data integration purposes.

The program executes its business logic through the following sequential phases:

1. Initialization Phase

• Execution Start : The program logs its startup to the console.

• Timestamp Generation :

• Retrieves the current system date in YYYYMMDD format and system time in HHMMSS99 format.

• Formats the date into YYYY-MM-DD and the time into HH:MM:SS .

• Combines these into a standardized 26-character timestamp: YYYY-MM-DD HH:MM:SS.00 . This timestamp is applied to every exported record to ensure temporal consistency across the export batch.

• File Opening : Opens the five input files ( CUSTOMER-INPUT , ACCOUNT-INPUT , XREF-INPUT , TRANSACTION-INPUT , CARD-INPUT ) in INPUT mode and the single output file ( EXPORT-OUTPUT ) in OUTPUT mode. Each open operation is verified against its file status.

2. Sequential Export Processing

The program processes each input file entirely in a sequential, back-to-back manner. For every record read, it increments a global sequence counter ( WS-SEQUENCE-COUNTER ), formats a 500-byte export record, writes it to the output file, and updates entity-specific counters.

Customer Export ( 2000-EXPORT-CUSTOMERS ) :

• Reads CUSTOMER-INPUT sequentially until End-Of-File (EOF).

• Sets the record type identifier to 'C' .

• Populates the common header fields (Timestamp, Sequence Number, Branch ID '0001' , and Region Code 'NORTH' ).

• Maps customer-specific fields (such as Customer ID, Name, Address lines, State, Country, Zip, Phone numbers, SSN, Government ID, Date of Birth, EFT Account ID, Primary Cardholder Indicator, and FICO Credit Score) into the redefined customer data area.

• Writes the record to EXPORT-OUTPUT .

Account Export ( 3000-EXPORT-ACCOUNTS ) :

• Reads ACCOUNT-INPUT sequentially until EOF.

• Sets the record type identifier to 'A' .

• Populates the common header fields.

• Maps account-specific fields (including Account ID, Active Status, Current Balance, Credit Limit, Cash Credit Limit, Open/Expiration/Reissue Dates, Current Cycle Credit/Debit, Zip Code, and Group ID) into the redefined account data area.

• Writes the record to EXPORT-OUTPUT .

Cross-Reference Export ( 4000-EXPORT-XREFS ) :

• Reads XREF-INPUT sequentially until EOF.

• Sets the record type identifier to 'X' .

• Populates the common header fields.

• Maps cross-reference fields (Card Number, Customer ID, and Account ID) into the redefined cross-reference data area.

• Writes the record to EXPORT-OUTPUT .

Transaction Export ( 5000-EXPORT-TRANSACTIONS ) :

• Reads TRANSACTION-INPUT sequentially until EOF.

• Sets the record type identifier to 'T' .

• Populates the common header fields.

• Maps transaction-specific fields (Transaction ID, Type Code, Category Code, Source, Description, Amount, Merchant ID, Merchant Name, Merchant City, Merchant Zip, Card Number, Original Timestamp, and Processed Timestamp) into the redefined transaction data area.

• Writes the record to EXPORT-OUTPUT .

Card Export ( 5500-EXPORT-CARDS ) :

• Reads CARD-INPUT sequentially until EOF.

• Sets the record type identifier to 'D' .

• Populates the common header fields.

• Maps card-specific fields (Card Number, Account ID, CVV Code, Embossed Name, Expiration Date, and Active Status) into the redefined card data area.

• Writes the record to EXPORT-OUTPUT .

3. Finalization Phase

• File Closure : Closes all five input files and the output export file.

• Reporting : Outputs a summary report to the job log displaying the total number of records exported for each entity type, as well as the grand total of all records written.

Important Constants

• Record Type Identifiers :

• 'C' : Customer Record

• 'A' : Account Record

• 'X' : Card Cross-Reference Record

• 'T' : Transaction Record

• 'D' : Card Record

• Default Branch ID : '0001'

• Default Region Code : 'NORTH'

• File Status Codes :

• '00' : Success / OK

• '10' : End of File (EOF)

Validation Logic

• File Status Verification :

• The program performs strict validation on the file status of every I/O operation.

• After opening each file, the program verifies that the status is '00' (Success). Any other status code is treated as a critical failure.

• During sequential read loops, the program verifies that the status is either '00' (Success) or '10' (End of File). Any other status code triggers an immediate abnormal termination.

• After every write operation to the export file, the program verifies that the status is '00' .

• Data Integrity :

• The program does not perform field-level validation (such as range checks, numeric validation, or date format verification) on the input data. It assumes the source indexed files contain clean, pre-validated data and directly maps the fields to the output structure.

Data Elements Processed

Identifiers and Keys

• CUST-ID / EXP-CUST-ID : 9-digit Customer Identifier.

• ACCT-ID / EXP-ACCT-ID : 11-digit Account Identifier.

• XREF-CARD-NUM / EXP-XREF-CARD-NUM : 16-character Card Number used for cross-referencing.

• TRAN-ID / EXP-TRAN-ID : 16-character Transaction Identifier.

• CARD-NUM / EXP-CARD-NUM : 16-character Card Number.

• EXPORT-SEQUENCE-NUM : 9-digit binary ( COMP ) auto-incrementing sequence number for the export file.

• EXPORT-BRANCH-ID : 4-character Branch Identifier (hardcoded to '0001' ).

• EXPORT-REGION-CODE : 5-character Region Code (hardcoded to 'NORTH' ).

Financial Amounts

• ACCT-CURR-BAL / EXP-ACCT-CURR-BAL : Current Account Balance (Signed, Packed Decimal COMP-3 ).

• ACCT-CREDIT-LIMIT / EXP-ACCT-CREDIT-LIMIT : Account Credit Limit (Signed Numeric).

• ACCT-CASH-CREDIT-LIMIT / EXP-ACCT-CASH-CREDIT-LIMIT : Cash Credit Limit (Signed, Packed Decimal COMP-3 ).

• ACCT-CURR-CYC-CREDIT / EXP-ACCT-CURR-CYC-CREDIT : Current Cycle Credit Amount (Signed Numeric).

• ACCT-CURR-CYC-DEBIT / EXP-ACCT-CURR-CYC-DEBIT : Current Cycle Debit Amount (Signed, Binary COMP ).

• TRAN-AMT / EXP-TRAN-AMT : Transaction Amount (Signed, Packed Decimal COMP-3 ).

Dates and Timestamps

• CUST-DOB-YYYY-MM-DD / EXP-CUST-DOB-YYYY-MM-DD : Customer Date of Birth.

• ACCT-OPEN-DATE / EXP-ACCT-OPEN-DATE : Account Opening Date.

• ACCT-EXPIRAION-DATE / EXP-ACCT-EXPIRAION-DATE : Account Expiration Date.

• ACCT-REISSUE-DATE / EXP-ACCT-REISSUE-DATE : Account Reissue Date.

• TRAN-ORIG-TS / EXP-TRAN-ORIG-TS : Original Transaction Timestamp.

• TRAN-PROC-TS / EXP-TRAN-PROC-TS : Processed Transaction Timestamp.

• CARD-EXPIRAION-DATE / EXP-CARD-EXPIRAION-DATE : Card Expiration Date.

• EXPORT-TIMESTAMP : 26-character Export Generation Timestamp.

Control and Statistical Counters

• WS-SEQUENCE-COUNTER : Internal counter tracking the global sequence of written records.

• WS-CUSTOMER-RECORDS-EXPORTED : Total count of customer records processed.

• WS-ACCOUNT-RECORDS-EXPORTED : Total count of account records processed.

• WS-XREF-RECORDS-EXPORTED : Total count of cross-reference records processed.

• WS-TRAN-RECORDS-EXPORTED : Total count of transaction records processed.

• WS-CARD-RECORDS-EXPORTED : Total count of card records processed.

• WS-TOTAL-RECORDS-EXPORTED : Grand total of all records written to the export file.

Exception and Error Handling

• I/O Error Detection : The program continuously monitors the file status variables ( WS-CUSTOMER-STATUS , WS-ACCOUNT-STATUS , WS-XREF-STATUS , WS-TRANSACTION-STATUS , WS-CARD-STATUS , WS-EXPORT-STATUS ) after every file interaction.

• Console Error Logging : If an unexpected file status is encountered (any status other than '00' , or '10' during a read), the program writes a descriptive error message to the console (e.g., 'ERROR: Reading CUSTOMER-INPUT, Status: [status-code]' ).

• Abnormal Program Termination (ABEND) : Upon detecting a critical I/O error, the program transfers control to the 9999-ABEND-PROGRAM paragraph. This paragraph displays 'CBEXPORT: ABENDING PROGRAM' and calls the IBM Language Environment dump and abend service CEE3ABD to terminate execution immediately, preventing partial or corrupted exports.

Security and Authorization Checks

No explicit security checks identified.

Performance Considerations

• Sequential Access Mode : Although the input files are defined as ORGANIZATION IS INDEXED , they are accessed using ACCESS MODE IS SEQUENTIAL . This is highly efficient for bulk data extraction because it reads the VSAM datasets in physical sequence, avoiding the overhead associated with random index lookups.

• Storage and I/O Optimization :

• The export record structure utilizes computational data formats ( COMP for binary integers and COMP-3 for packed decimals) for numeric and financial fields. This significantly reduces the physical record size on disk.

• The output record length is fixed at exactly 500 bytes ( RECORD CONTAINS 500 CHARACTERS with RECORDING MODE IS F ), which allows for predictable block sizes and optimized I/O buffer allocation on the mainframe.

• Memory Efficiency : The program uses a single EXPORT-RECORD structure in Working-Storage with multiple REDEFINES clauses. This allows the program to reuse the same 460-byte data buffer ( EXPORT-RECORD-DATA ) for all five record types, minimizing the program's memory footprint.

• Commit Frequency : The program does not implement intermediate commits, checkpoints, or restartability logic. It processes the entire export as a single, continuous unit of work. If a failure occurs mid-process, the entire job must be restarted from the beginning.

<h2

Batch Data Import and Normalization Utility for Credit Card Branch Migration

The CBIMPORT program is a batch processing utility designed for the CardDemo credit card application to facilitate seamless branch migrations. Its primary business purpose is to ingest a consolidated, multi-record export file containing migrated branch data and split it into separate, normalized target files. By acting as an ETL (Extract, Transform, Load) pipeline, the program ensures that legacy or consolidated branch data is cleanly distributed into the core system's structured data model.

The program sequentially processes a single input file containing mixed record types. As it reads each record, it identifies the specific business entity based on a record type indicator. The system supports five core business entities essential to credit card operations: Customer Profiles, Financial Accounts, Card-to-Account Cross-References, Financial Transactions, and Physical Card details.

During the processing phase, the program maps the fields from the consolidated import record into their respective normalized structures. Each validated record is then written to its dedicated sequential output file. This decomposition process ensures that downstream database tables and core application systems receive clean, isolated, and properly formatted datasets.

To maintain high operational integrity, the program features robust error handling and validation mechanisms. If a critical file system error occurs during the opening, reading, or writing of any file, the program immediately terminates execution to prevent data corruption. Any unrecognized or malformed records encountered during the run are redirected to a dedicated error log, complete with a timestamp, sequence number, and diagnostic message for administrative troubleshooting.

Upon reaching the end of the input file, the program performs finalization tasks by closing all resources and generating a comprehensive execution summary. It outputs detailed processing statistics to the system log, including the total number of records read, the count of successfully imported records for each business entity, and the total number of errors logged. This provides administrators with complete visibility and auditability over the migration process.

Business Logic Overview

The CBIMPORT program is a batch COBOL utility designed for the Branch Migration Import process within the CardDemo application. Its primary business purpose is to ingest a consolidated, multi-record export file containing migrated branch data and split (normalize) it into five distinct, entity-specific sequential target files: Customers, Accounts, Card Cross-References, Transactions, and Cards.

The program reads the input file sequentially, identifies the record type of each entry, maps the compressed/binary data fields into standard display formats, writes the formatted records to their respective output destinations, and logs any unrecognized record types to an error file. At the end of execution, it generates a detailed console report summarizing the import statistics.

Detailed Process Flow

Initialization ( 1000-INITIALIZE & 1100-OPEN-FILES ) :

• Displays a startup message to the console.

• Captures the current system date and time using FUNCTION CURRENT-DATE and formats them into YYYY-MM-DD and HH:MM:SS formats for reporting.

• Opens the input export file ( EXPORT-INPUT ) and all six output files ( CUSTOMER-OUTPUT , ACCOUNT-OUTPUT , XREF-OUTPUT , TRANSACTION-OUTPUT , CARD-OUTPUT , and ERROR-OUTPUT ).

• Verifies the file status of each open operation. If any file fails to open successfully, the program displays an error message and terminates abnormally.

File Processing Loop ( 2000-PROCESS-EXPORT-FILE ) :

• Performs an initial read of the export file.

• Enters a loop that continues until the End-of-File (EOF) status ( 10 ) is reached on the input file.

• For each record read:

• Increments the total record read counter ( WS-TOTAL-RECORDS-READ ).

• Evaluates the record type and routes the record to the appropriate processing paragraph.

• Reads the next record from the input file.

Record-Specific Processing ( 2200-PROCESS-RECORD-BY-TYPE through 2750-WRITE-ERROR ) :

• Customer Records (Type 'C') :

• Initializes the customer output record structure.

• Maps fields from the input redefined area ( EXPORT-CUSTOMER-DATA ) to the output structure ( CUSTOMER-RECORD ). This includes converting the binary customer ID ( COMP ) and packed decimal FICO score ( COMP-3 ) into standard display formats, and mapping occurring arrays for addresses (3 occurrences) and phone numbers (2 occurrences).

• Writes the record to CUSTOMER-OUTPUT , verifies the write status, and increments the customer import counter.

• Account Records (Type 'A') :

• Initializes the account output record structure.

• Maps fields from EXPORT-ACCOUNT-DATA to ACCOUNT-RECORD . This includes converting packed decimal fields ( EXP-ACCT-CURR-BAL , EXP-ACCT-CASH-CREDIT-LIMIT ) and binary fields ( EXP-ACCT-CURR-CYC-DEBIT ) to display formats.

• Writes the record to ACCOUNT-OUTPUT , verifies the write status, and increments the account import counter.

• Card Cross-Reference Records (Type 'X') :

• Initializes the cross-reference output record structure.

• Maps fields from EXPORT-CARD-XREF-DATA to CARD-XREF-RECORD , converting the binary account ID ( COMP ) to display format.

• Writes the record to XREF-OUTPUT , verifies the write status, and increments the cross-reference import counter.

• Transaction Records (Type 'T') :

• Initializes the transaction output record structure.

• Maps fields from EXPORT-TRANSACTION-DATA to TRAN-RECORD , converting the packed decimal transaction amount ( COMP-3 ) and binary merchant ID ( COMP ) to display formats.

• Writes the record to TRANSACTION-OUTPUT , verifies the write status, and increments the transaction import counter.

• Card Records (Type 'D') :

• Initializes the card output record structure.

• Maps fields from EXPORT-CARD-DATA to CARD-RECORD , converting the binary account ID ( COMP ) and binary CVV code ( COMP ) to display formats.

• Writes the record to CARD-OUTPUT , verifies the write status, and increments the card import counter.

• Unknown Records (Any other type) :

• Increments the unknown record counter.

• Formats an error record with the current timestamp, the invalid record type character, the record's sequence number, and the message "Unknown record type encountered" .

• Writes this formatted error record to ERROR-OUTPUT and increments the error write counter.

Validation ( 3000-VALIDATE-IMPORT ) :

• Executes a placeholder validation paragraph that logs completion messages to the console.

Finalization ( 4000-FINALIZE ) :

• Closes all open input and output files.

• Prints a comprehensive execution summary to the console, detailing:

• Total records read.

• Total records successfully imported for each of the five target entities.

• Total error records written.

• Total unknown record types encountered.

Important Constants

• Record Type Identifiers :

• 'C' - Customer Record

• 'A' - Account Record

• 'X' - Card Cross-Reference Record

• 'T' - Transaction Record

• 'D' - Card Record

• File Status Codes :

• '00' - Success / OK

• '10' - End of File (EOF)

• System Abend Utility :

• 'CEE3ABD' - IBM Language Environment service used to trigger an abnormal program termination.

Validation Logic

• File Status Verification : The program strictly validates the file status code after every file operation (Open, Read, and Write). If any status code other than '00' (or '10' for EOF on reads) is returned, the program immediately halts processing and triggers an ABEND.

• Record Type Validation : The program performs a structural validation on the input record's header field EXPORT-REC-TYPE . If the value is not one of the five valid constants ( 'C' , 'A' , 'X' , 'T' , or 'D' ), the record is rejected from normal processing, classified as an error, and written to the error log.

• Data Integrity : Although the business use case mentions checksum validation, the actual implementation in 3000-VALIDATE-IMPORT is a placeholder that automatically logs successful validation without performing active data-level checksum calculations.

Data Elements Processed

Input Elements (from EXPORT-INPUT )

• Metadata : EXPORT-REC-TYPE (1-byte type indicator), EXPORT-SEQUENCE-NUM (4-byte binary sequence key), EXPORT-TIMESTAMP (26-byte timestamp).

• Customer Data : EXP-CUST-ID (4-byte binary), names (first, middle, last), address lines (3-element array), state, country, zip, phone numbers (2-element array), SSN, government ID, date of birth, EFT account ID, primary cardholder indicator, and EXP-CUST-FICO-CREDIT-SCORE (2-byte packed decimal).

• Account Data : EXP-ACCT-ID (11-digit numeric), active status, EXP-ACCT-CURR-BAL (7-byte packed decimal), credit limit, EXP-ACCT-CASH-CREDIT-LIMIT (7-byte packed decimal), open/expiration/reissue dates, current cycle credit, EXP-ACCT-CURR-CYC-DEBIT (4-byte binary), zip, and group ID.

• Cross-Reference Data : EXP-XREF-CARD-NUM (16-byte card number), EXP-XREF-CUST-ID (9-digit customer ID), and EXP-XREF-ACCT-ID (8-byte binary account ID).

• Transaction Data : EXP-TRAN-ID (16-byte transaction ID), type code, category code, source, description, EXP-TRAN-AMT (6-byte packed decimal), EXP-TRAN-MERCHANT-ID (4-byte binary), merchant name/city/zip, card number, and transaction timestamps.

• Card Data : EXP-CARD-NUM (16-byte card number), EXP-CARD-ACCT-ID (8-byte binary account ID), EXP-CARD-CVV-CD (2-byte binary CVV), embossed name, expiration date, and active status.

Output Elements (Transformed and Written)

• Normalized Records : Mapped and unpacked equivalents of all input elements written to CUSTOMER-OUTPUT (500 bytes), ACCOUNT-OUTPUT (300 bytes), XREF-OUTPUT (50 bytes), TRANSACTION-OUTPUT (350 bytes), and CARD-OUTPUT (150 bytes). All binary ( COMP ) and packed decimal ( COMP-3 ) fields are expanded into standard zoned-decimal display formats.

• Error Records : Written to ERROR-OUTPUT (132 bytes) containing the error timestamp, the invalid record type, the sequence number, and the literal message "Unknown record type encountered" .

Exception and Error Handling

• Critical File Failures : If any file operation (such as opening a file or writing a record) fails with a non-zero status, the program writes a descriptive error message to the console (e.g., 'ERROR: Cannot open EXPORT-INPUT, Status: [status-code]' ) and calls paragraph 9999-ABEND-PROGRAM .

• Program ABEND : The 9999-ABEND-PROGRAM paragraph calls the IBM Language Environment service 'CEE3ABD' to abnormally terminate the program. This ensures that the job step fails in the JCL, preventing downstream jobs from running with incomplete data.

• Non-Critical Record Errors : If an unrecognized record type is encountered, the program does not abend. Instead, it handles the exception gracefully by logging the record's metadata to the ERROR-OUTPUT file, incrementing the error counters, and continuing to process the remaining records in the export file.

Security and Authorization Checks

No explicit security checks identified.

Performance Considerations

• Sequential I/O Efficiency : The program processes the input file sequentially, which is highly efficient for batch processing of large datasets.

• Data Conversion Overhead : The program performs extensive data conversion from packed decimal ( COMP-3 ) and binary ( COMP ) formats in the input file to zoned decimal/display formats in the output files. This is a CPU-bound operation that occurs for every record.

• No Commit/Checkpointing : The program does not implement database commits or checkpoint-restart logic (e.g., IMS or DB2 checkpoints), as it operates entirely on flat/sequential files. If a failure occurs, the entire batch job must be restarted from the beginning, and output files must be cleared/recreated (since they are opened in OUTPUT mode, which overwrites existing content).

• I/O Overhead : Writing to six different output files simultaneously can introduce I/O channel contention depending on the mainframe storage configuration.

<h2

Pending Credit Card Authorization Expiry and Database Cleanup Batch Process

The primary business purpose of this program is to manage and clean up pending credit card transaction authorizations within the CardDemo application. In credit card processing, authorizations temporarily hold funds on a customer's account. If these authorizations are not finalized within a specific timeframe, they must be removed to release the held credit and keep the database performing efficiently. This batch program automates the identification and deletion of these stale, expired pending authorizations.

Upon execution, the program initializes its configuration by reading runtime parameters, which define the expiration threshold (defaulting to five days if not specified), database checkpoint frequencies, and diagnostic logging preferences. It captures the current system date to establish a baseline for calculating the age of each pending transaction.

The program systematically processes the hierarchical database by scanning through account-level authorization summary records and examining their associated detailed transaction records. For every pending transaction detail, the program calculates the number of days that have elapsed since the authorization was originally requested. If the transaction's age meets or exceeds the configured expiration threshold, it is classified as expired and targeted for removal.

Before deleting an expired transaction, the program dynamically updates the parent account's summary record. It subtracts the transaction's value and count from the accumulated pending totals—distinguishing between approved and declined amounts—to ensure the customer's credit availability and account balances are accurately restored. If a parent summary record no longer contains any active pending transactions after this cleanup, the program deletes the summary record itself to reclaim database storage.

To ensure operational reliability and prevent data loss in the event of a system interruption, the program periodically commits its database updates using a checkpoint mechanism based on the configured frequency. Once the entire database has been processed, the program outputs a final execution report detailing the total number of summary and detail records analyzed and deleted, providing clear visibility into the cleanup operations.

Program Overview

The CBPAUP0C program is a batch COBOL IMS program designed to clean up expired pending authorization records from an IMS database. It processes a hierarchical database consisting of a root segment, Pending Authorization Summary ( PAUTSUM0 ), and a child segment, Pending Authorization Details ( PAUTDTL1 ).

The program identifies expired authorization details based on a configurable retention period, deletes those details, adjusts the corresponding summary counters and amounts, and deletes the parent summary segment if no active authorizations remain.

Important Constants

• WS-PGMNAME : 'CBPAUP0C' — The program identifier used in messages and logs.

• PSB-NAME : 'PSBPAUTB' — The Program Specification Block name used to access the IMS database.

• PAUT-PCB-NUM : +2 — The PCB index offset representing the database PCB.

• WK-CHKPT-ID Prefix : 'RMAD' — The prefix used to generate unique checkpoint IDs.

• Default Expiry Days : 5 — The default retention threshold if the input parameter is invalid or non-numeric.

• Default Checkpoint Frequency : 5 — The default number of processed summary records before committing database changes.

• Default Checkpoint Display Frequency : 10 — The default interval for displaying checkpoint success messages.

• Approved Response Code : '00' — The code indicating a successfully approved authorization.

Validation Logic

1. Input Parameter Validation

Upon startup, the program reads execution parameters from SYSIN into the PRM-INFO structure and validates them:

• P-EXPIRY-DAYS : Checked to ensure it is numeric. If valid, it is moved to WS-EXPIRY-DAYS ; otherwise, it defaults to 5 .

• P-CHKP-FREQ : Checked for spaces, zero, or low-values. If invalid, it defaults to 5 .

• P-CHKP-DIS-FREQ : Checked for spaces, zero, or low-values. If invalid, it defaults to 10 .

• P-DEBUG-FLAG : Checked to see if it equals 'Y' . If not, it is forced to 'N' .

2. IMS Database Status Code Validation

The program evaluates the Database Interface Block Status Code ( DIBSTAT ) after every database operation to ensure data integrity:

• Get Next (GN) on Summary ( PAUTSUM0 ) :

• ' ' (Spaces): Success; processing continues.

• 'GB' (End of Database): Normal termination flag is set.

• Any other code : Triggers an immediate program ABEND.

• Get Next in Parent (GNP) on Details ( PAUTDTL1 ) :

• ' ' (Spaces): Success; child record found.

• 'GE' / 'GB' (Not Found / End of Database): Indicates no more child segments exist for the current parent; loop terminates normally.

• Any other code : Triggers an immediate program ABEND.

• Delete (DLET) on Details or Summary :

• ' ' (Spaces): Success.

• Any other code : Triggers an immediate program ABEND.

• Checkpoint (CHKP) :

• ' ' (Spaces): Success.

• Any other code : Triggers an immediate program ABEND.

Data Elements Processed

Input Parameters (SYSIN)

• P-EXPIRY-DAYS : Number of days an authorization is allowed to remain pending before expiration.

• P-CHKP-FREQ : Number of root segments to process before issuing an IMS checkpoint.

• P-CHKP-DIS-FREQ : Frequency of displaying checkpoint status messages in the job log.

• P-DEBUG-FLAG : Activates verbose logging when set to 'Y' .

System Variables

• CURRENT-DATE : Current system date in YYMMDD format.

• CURRENT-YYDDD : Current system date in Julian format ( YYDDD ).

IMS Pending Authorization Summary Segment ( PAUTSUM0 )

• PA-ACCT-ID : Account Identifier (Key field).

• PA-APPROVED-AUTH-CNT : Count of approved pending authorizations.

• PA-DECLINED-AUTH-CNT : Count of declined pending authorizations.

• PA-APPROVED-AUTH-AMT : Total monetary amount of approved pending authorizations.

• PA-DECLINED-AUTH-AMT : Total monetary amount of declined pending authorizations.

IMS Pending Authorization Details Segment ( PAUTDTL1 )

• PA-AUTH-DATE-9C : Complemented authorization date (stored as 99999 - Julian Date for descending sort order).

• PA-AUTH-RESP-CODE : Response code of the authorization (e.g., '00' for approved).

• PA-APPROVED-AMT : Approved transaction amount.

• PA-TRANSACTION-AMT : Requested transaction amount.

Internal Accumulators

• WS-NO-SUMRY-READ : Total number of summary records read.

• WS-NO-SUMRY-DELETED : Total number of summary records deleted.

• WS-NO-DTL-READ : Total number of detail records read.

• WS-NO-DTL-DELETED : Total number of detail records deleted.

Business Logic and Program Flow

1. Initialization Phase

• Retrieves the current system date and Julian date.

• Accepts and validates runtime parameters from SYSIN .

• Displays startup messages and the active configuration parameters.

2. Main Processing Loop

The program performs a sequential sweep of the database:

• Step 2.1: Read Parent Summary

• Issues an IMS GN (Get Next) call to retrieve the next PAUTSUM0 segment.

• If the end of the database is reached ( DIBSTAT = 'GB' ), the loop terminates.

• Step 2.2: Process Child Details

• Issues an IMS GNP (Get Next in Parent) call to retrieve the first child PAUTDTL1 segment under the current parent.

• For each child segment retrieved, the program determines if it has expired:

• Decode Date : Reconstructs the original Julian date of the authorization:

$$\text{WS-AUTH-DATE} = 99999 - \text{PA-AUTH-DATE-9C}$$

• Calculate Age : Computes the difference in days:

$$\text{WS-DAY-DIFF} = \text{CURRENT-YYDDD} - \text{WS-AUTH-DATE}$$

• Evaluate Expiration : If WS-DAY-DIFF is greater than or equal to WS-EXPIRY-DAYS , the record is marked for deletion.

• Adjust Parent Totals : If the detail record is expired, the parent summary counters and amounts are adjusted before deletion:

• If Approved ( PA-AUTH-RESP-CODE = '00' ) :

• Subtract 1 from PA-APPROVED-AUTH-CNT .

• Subtract PA-APPROVED-AMT from PA-APPROVED-AUTH-AMT .

• If Declined (Any other response code) :

• Subtract 1 from PA-DECLINED-AUTH-CNT .

• Subtract PA-TRANSACTION-AMT from PA-DECLINED-AUTH-AMT .

• Delete Detail : Issues an IMS DLET call to physically delete the expired PAUTDTL1 segment.

• Repeats the GNP call until all child segments for the current parent have been processed.

• Step 2.3: Evaluate Parent Summary Deletion

• After processing all child details, the program checks if the parent summary segment itself should be deleted.

• Note on Code Logic : The program contains a logical redundancy/quirk in this check:

IF PA-APPROVED-AUTH-CNT <= 0 AND PA-APPROVED-AUTH-CNT <= 0

This statement evaluates the approved count twice instead of checking both approved and declined counts. If this condition is met, the program issues an IMS DLET call to delete the parent PAUTSUM0 segment.

• Step 2.4: Checkpoint Management

• Increments the processed summary counter ( WS-AUTH-SMRY-PROC-CNT ).

• If the counter exceeds P-CHKP-FREQ , the program issues an IMS basic checkpoint ( CHKP ) to commit database changes and resets the counter.

3. Termination Phase

• Issues a final IMS checkpoint to commit any remaining uncommitted changes.

• Displays execution statistics including total records read and deleted for both summary and detail segments.

• Terminates execution using GOBACK .

Exception and Error Handling

• Centralized ABEND ( 9999-ABEND ) : Any unexpected database status code or system error routes processing to this paragraph.

• Error Reporting : Before terminating, the program writes diagnostic information to the standard output, including:

• The failed IMS operation status code ( DIBSTAT ).

• The Account ID ( PA-ACCT-ID ) currently being processed.

• The total number of records processed up to the point of failure.

• Return Code : Sets the job step return code ( RETURN-CODE ) to 16 to signal a critical failure to the Job Control Language (JCL) controller, preventing subsequent job steps from executing.

Security and Authorization Checks

No explicit security checks (such as RACF calls or transaction authorization checks) are identified within this program. Security is assumed to be managed at the environment level via JCL execution authority and IMS database access control lists.

Performance Considerations

• Get Next in Parent ( GNP ) : The program utilizes GNP rather than unqualified GN calls to retrieve child segments. This restricts database searching strictly to the twin chain of the current parent segment, minimizing database I/O.

• Complemented Keys : The authorization date is stored in a complemented format ( 99999 - Date ). This is a standard mainframe design pattern that allows IMS to index and retrieve the most recent authorization records first (descending order) without requiring a database sort.

• Dynamic Checkpoint Frequency : Database commits are managed dynamically via the P-CHKP-FREQ parameter. This allows database administrators to tune the commit frequency to balance lock retention times against checkpoint overhead based on the volume of data in the environment.

<h2

Account Statement Generator with Dual-Format Output

This batch program is a core utility within the card processing system designed to generate comprehensive account statements for credit card customers. Its primary business purpose is to aggregate financial data and produce statements in two distinct formats simultaneously: a traditional plain-text report suitable for legacy printing or archiving, and a structured HTML document designed for digital distribution, email delivery, or web-based customer portals.

To compile these statements, the program orchestrates the retrieval of data from multiple foundational business entities. It interfaces with a centralized data access subroutine to sequentially process cardholder cross-reference records, which link credit cards to specific customer profiles and account identifiers. For each valid link, the program retrieves detailed customer demographics (such as names and addresses), credit risk metrics (like FICO scores), and account financial summaries (including current balances).

A key efficiency of this program is its handling of transaction history. Before generating individual statements, the program pre-loads and groups transaction records in memory by card number. As it processes each customer account, it performs an in-memory lookup to match and append the corresponding transaction ledger to the statement. It dynamically calculates the total expenditure for the billing cycle, formatting and writing this financial summary to both the text and HTML outputs.

In addition to its reporting duties, the program performs low-level system diagnostics. Upon startup, it queries mainframe system control blocks to identify and log the active job name and step execution details, ensuring operational traceability. This combination of system-level integration, structured in-memory data aggregation, and dual-format document generation makes the program a critical component for customer communications and a prime candidate for cloud-based document generation modernization.

Business Logic Overview

The CBSTM03A program is a batch COBOL application designed to generate account statements in two distinct formats: plain text ( STMT-FILE ) and HTML ( HTML-FILE ). The program integrates customer demographic data, account balances, credit scores, and transaction histories to produce comprehensive, customer-facing statements.

The program executes its business and system logic through the following phases:

System Diagnostics & Control Block Traversal

Before processing any business files, the program accesses low-level MVS system control blocks to perform environment diagnostics. Starting from the Prefixed Save Area (PSA) pointer, it navigates to the Task Control Block (TCB) and then to the Task Input/Output Table (TIOT). It extracts and displays the JCL Job Name and Step Name, then loops through the TIOT entries to identify active DD names and validate their associated Unit Control Blocks (UCBs).

State-Driven File Initialization

The program utilizes a state-machine pattern controlled by the variable WS-FL-DD and dynamic ALTER ... TO PROCEED TO statements to open its required files. It sequentially invokes the I/O subroutine CBSTM03B to open:

• The Transaction File ( TRNXFILE )

• The Cross-Reference File ( XREFFILE )

• The Customer File ( CUSTFILE )

• The Account File ( ACCTFILE )

In-Memory Transaction Caching

Immediately after opening the transaction file, the program reads all transaction records sequentially and loads them into a two-dimensional in-memory table ( WS-TRNX-TABLE ). This table groups transactions by card number, allowing up to 51 unique cards and up to 10 transactions per card. This caching mechanism eliminates the need for repetitive disk I/O during statement generation.

Sequential Statement Generation Loop

Once initialization and caching are complete, the program enters its main processing loop, reading the Card-to-Customer Cross-Reference File ( XREFFILE ) sequentially from beginning to end. For each cross-reference record retrieved:

• Customer Lookup : The program performs a random, key-based read on the Customer File ( CUSTFILE ) using the Customer ID ( XREF-CUST-ID ) to retrieve the customer's name and address.

• Account Lookup : It performs a random, key-based read on the Account File ( ACCTFILE ) using the Account ID ( XREF-ACCT-ID ) to retrieve the current balance.

• Header Generation : It formats and writes the statement headers, customer address blocks, and basic account details (including the FICO score) to both the plain text and HTML output files.

• Transaction Matching & Detail Writing : It searches the in-memory transaction cache for card numbers matching the current cross-reference card number ( XREF-CARD-NUM ). For every match found, it writes the individual transaction details (ID, description, and amount) to both output files and accumulates the transaction amounts into a running total.

• Footer Generation : It writes the accumulated transaction total (Total Expenses) and the statement closing footers to both output files, completing the statement for that account.

Cleanup and Termination

After reaching the end of the cross-reference file, the program calls CBSTM03B to close all four input files, closes the two output statement files, and terminates execution.

Important Constants

• WS-FL-DD State Constants :

• 'TRNXFILE' : Initiates the opening of the transaction file.

• 'XREFFILE' : Initiates the opening of the cross-reference file.

• 'CUSTFILE' : Initiates the opening of the customer file.

• 'ACCTFILE' : Initiates the opening of the account file.

• 'READTRNX' : Triggers the sequential reading and caching of transaction records.

• WS-M03B-OPER Subroutine Operations :

• 'O' ( M03B-OPEN ): Open file.

• 'C' ( M03B-CLOSE ): Close file.

• 'R' ( M03B-READ ): Sequential read.

• 'K' ( M03B-READ-K ): Random read by key.

• HTML Template Markers ( HTML-FIXED-LN 88-levels) :

• HTML-L01 through HTML-L80 : Predefined HTML tags, document structures, and inline CSS styles used to construct the HTML statement layout.

• Array Dimensions :

• Card Table Limit: 51 (Maximum number of unique cards cached in memory).

• Transaction Table Limit: 10 (Maximum number of transactions cached per card).

Validation Logic

Prior to and during data processing, the program enforces several validation checks and status verifications:

• Unit Control Block (UCB) Validation : During the startup diagnostic phase, the program inspects the UCB-ADDR field of each TIOT entry. If the address is equal to LOW-VALUES ( NULL-UCB ), it identifies and logs the entry as a null UCB; otherwise, it validates it as a active, valid UCB.

• I/O Subroutine Return Code Verification : After every call to the centralized I/O module CBSTM03B , the program validates the returned status code ( WS-M03B-RC ):

• File Open : Must return '00' (Success) or '04' (Success with warning/already open). Any other code triggers an immediate program abend.

• Sequential Read : Must return '00' (Success) or '10' (End of File). Any other code triggers an abend.

• Random Key Read : Must return '00' (Success). Any other code (such as '23' Record Not Found) triggers an abend.

• Transaction Matching : During statement generation, the program validates that the card number associated with cached transactions ( WS-CARD-NUM ) exactly matches the card number from the active cross-reference record ( XREF-CARD-NUM ) before writing transaction lines.

Data Elements Processed

Input Elements (via Subroutine Buffers)

• Cross-Reference Fields :

• XREF-CARD-NUM : The 16-character card number used as the primary key to match transactions.

• XREF-CUST-ID : The 9-digit customer identifier.

• XREF-ACCT-ID : The 11-digit account identifier.

• Customer Profile Fields :

• CUST-FIRST-NAME , CUST-MIDDLE-NAME , CUST-LAST-NAME : Customer name components.

• CUST-ADDR-LINE-1 , CUST-ADDR-LINE-2 , CUST-ADDR-LINE-3 : Customer street address lines.

• CUST-ADDR-STATE-CD , CUST-ADDR-COUNTRY-CD , CUST-ADDR-ZIP : Customer regional address details.

• CUST-FICO-CREDIT-SCORE : The 3-digit credit score.

• Account Profile Fields :

• ACCT-ID : The 11-digit account number.

• ACCT-CURR-BAL : The current account balance (signed numeric S9(10)V99 ).

• Transaction History Fields :

• TRNX-CARD-NUM : The card number associated with the transaction.

• TRNX-ID : The 16-character unique transaction identifier.

• TRNX-DESC : The 100-character transaction description.

• TRNX-AMT : The transaction amount (signed numeric S9(9)V99 ).

Transformed & Formatted Output Elements

• ST-NAME : Formatted customer name, constructed by stringing together the first, middle, and last names delimited by spaces.

• ST-ADD3 : Formatted city/state/zip line, constructed by stringing together address line 3, state code, country code, and zip code.

• ST-CURR-BAL : Formatted account balance mapped to an edited mask ( 9(9).99- ).

• ST-TRANAMT : Formatted individual transaction amount mapped to an edited mask ( Z(9).99- ).

• ST-TOTAL-TRAMT : Formatted sum of all transaction amounts for the account, mapped to an edited mask ( Z(9).99- ).

• HTML Output Records : Dynamic HTML strings constructed using STRING ... DELIMITED BY to embed customer names, addresses, account IDs, balances, and transaction details directly into HTML paragraph ( <p> ) and table row ( <tr> / <td> ) elements.

Exception and Error Handling

• Subroutine Error Detection : The program does not handle file system errors directly. Instead, it relies on the return codes passed back from CBSTM03B in WS-M03B-RC .

• Abnormal Program Termination (ABEND) : If any file operation (Open, Read, Key-Read, Close) returns an unexpected or unsuccessful status code, the program branches to the 9999-ABEND-PROGRAM paragraph. This paragraph:

• Writes an error message to the standard display output indicating which file failed and the return code received.

• Displays "ABENDING PROGRAM".

• Calls the IBM Language Environment abend service CEE3ABD to terminate execution immediately and generate a system dump.

• End-of-File Management : Sequential reads on the cross-reference file handle the '10' (EOF) status code gracefully by setting the END-OF-FILE switch to 'Y' , which terminates the mainline processing loop and initiates normal shutdown.

Security and Authorization Checks

No explicit security checks identified. The program does not perform any RACF, user authorization, or data masking checks. It assumes that the calling environment and dataset-level security rules govern access permissions.

Performance Considerations

• In-Memory Caching of Transactions : Reading the entire transaction file sequentially at startup and caching it in the 2D array WS-TRNX-TABLE is a significant performance optimization. It avoids the high overhead of performing random VSAM reads or repeated sequential scans of the transaction file for every customer processed.

• Array Boundary Vulnerability : The in-memory cache is statically dimensioned to support a maximum of 51 cards and 10 transactions per card. The program lacks boundary checks during the loading phase ( 8500-READTRNX-READ ). If the input transaction file contains more than 51 unique cards or more than 10 transactions for a single card, the program will experience index out-of-bounds conditions, leading to memory corruption or an execution failure.

• Random Access for Master Data : The program utilizes random key-based access ( M03B-READ-K ) to retrieve customer and account records. This is highly efficient because it directly targets the required records using their unique identifiers, minimizing I/O operations compared to sequential scanning.

<h2

Centralized File I/O Handler for CardDemo Transaction Reporting

The CBSTM03B program is a specialized batch utility within the CardDemo application designed to centralize and standardize file access operations. Its primary business purpose is to act as a data access layer for transaction reporting processes, shielding calling programs from the complexities of direct file handling. By consolidating file operations into a single module, the application ensures consistent data retrieval and uniform error handling across reporting workflows.

The program manages access to four critical data sources essential for generating transaction reports: transaction history, card-to-customer cross-references, customer profiles, and account details. Depending on the reporting requirements, the program accesses these files either sequentially—to process large volumes of transactions and cross-reference records—or randomly using specific lookup keys to retrieve individual customer and account details on demand.

To perform its tasks, the program receives instructions from a calling application specifying the target file, the requested operation, and any necessary search keys. It supports standard file operations, including opening files, closing files, reading records sequentially, and performing targeted lookups using unique identifiers like customer or account numbers. Once an operation is executed, the program returns the retrieved record data along with a standardized status code to indicate success or specific file conditions.

This modular architecture simplifies the development of business reports by allowing developers to focus on reporting logic rather than file management. It also provides a single point of maintenance, meaning any future changes to file structures, access methods, or storage technologies can be implemented within this single program without impacting the broader suite of reporting applications.

Business Logic Overview

The CBSTM03B program is a specialized, centralized batch COBOL I/O subroutine designed to manage file operations for four primary indexed files used in the CardDemo application's transaction reporting process. Instead of having the main reporting program perform direct file operations, it calls CBSTM03B and passes a control block ( LK-M03B-AREA ) containing the target file identifier, the requested operation, key information, and a data buffer.

The program acts as an I/O router. Upon invocation, it evaluates the requested DD name, routes the execution to the paragraph dedicated to that file, performs the requested operation (Open, Read, Read by Key, or Close), captures the resulting COBOL File Status, and returns control to the calling program.

The four files managed by this program are:

• Transaction File ( TRNX-FILE ) : Accessed sequentially to read transaction records.

• Cross-Reference File ( XREF-FILE ) : Accessed sequentially to read card-to-customer cross-reference records.

• Customer File ( CUST-FILE ) : Accessed randomly to retrieve customer details using a specific Customer ID.

• Account File ( ACCT-FILE ) : Accessed randomly to retrieve account details using a specific Account ID.

Important Constants

The program utilizes specific 88-level condition names defined in the Linkage Section to identify the requested file operations:

• M03B-OPEN ( 'O' ) : Opens the designated file in INPUT mode.

• M03B-CLOSE ( 'C' ) : Closes the designated file.

• M03B-READ ( 'R' ) : Performs a sequential read on the designated file.

• M03B-READ-K ( 'K' ) : Performs a random read on the designated file using a key.

• M03B-WRITE ( 'W' ) : Defined for write operations (not implemented in the current Procedure Division).

• M03B-REWRITE ( 'Z' ) : Defined for rewrite operations (not implemented in the current Procedure Division).

The program also evaluates specific DD name constants to route processing:

• 'TRNXFILE' : Routes processing to the Transaction File paragraph.

• 'XREFFILE' : Routes processing to the Cross-Reference File paragraph.

• 'CUSTFILE' : Routes processing to the Customer File paragraph.

• 'ACCTFILE' : Routes processing to the Account File paragraph.

Validation Logic

Before executing any file operations, the program performs the following validation and routing checks:

• DD Name Validation : The program evaluates the input field LK-M03B-DD . If the value does not match one of the four supported constants ( 'TRNXFILE' , 'XREFFILE' , 'CUSTFILE' , or 'ACCTFILE' ), the program bypasses all processing and branches directly to 9999-GOBACK to exit.

• Operation Code Validation : Within each file-specific paragraph, the program checks the operation code ( LK-M03B-OPER ) using the 88-level condition names. If an operation is requested that is not supported for that specific file (for example, requesting a sequential read 'R' on a randomly accessed file like CUSTFILE , or a key-based read 'K' on a sequentially accessed file like TRNXFILE ), the program bypasses the file operation entirely, moves the current file status to the return code, and exits.

• Key Length Reference Modification : For key-based reads ( M03B-READ-K ), the program validates and extracts the key from the linkage buffer using reference modification: LK-M03B-KEY (1:LK-M03B-KEY-LN) . This ensures that only the active portion of the key buffer, as specified by the length parameter LK-M03B-KEY-LN , is moved to the file record key, preventing trailing spaces or garbage data from corrupting the search key.

Data Elements Processed

The program processes the following data elements passed via the LK-M03B-AREA linkage structure:

• LK-M03B-DD (Input, PIC X(08)) : The DD name of the target file to be operated upon.

• LK-M03B-OPER (Input, PIC X(01)) : The operation code indicating the action to perform (Open, Close, Read, Read-Key).

• LK-M03B-RC (Output, PIC X(02)) : The 2-character return code returned to the caller, populated with the standard COBOL File Status.

• LK-M03B-KEY (Input, PIC X(25)) : The key buffer containing the search key for random reads.

• LK-M03B-KEY-LN (Input, S9(4) COMP) : The length of the active key within the key buffer.

• LK-M03B-FLDT (Output, PIC X(1000)) : The data buffer where the retrieved file record is placed during a read operation.

• FD-TRNXS-ID (Key, PIC X(32)) : The composite primary key for the Transaction File, consisting of:

• FD-TRNX-CARD (PIC X(16))

• FD-TRNX-ID (PIC X(16))

• FD-XREF-CARD-NUM (Key, PIC X(16)) : The primary key for the Cross-Reference File.

• FD-CUST-ID (Key, PIC X(09)) : The primary key for the Customer File.

• FD-ACCT-ID (Key, PIC 9(11)) : The primary key for the Account File.

Exception and Error Handling

• File Status Capture : The program does not use DECLARATIVES or explicit INVALID KEY / AT END clauses. Instead, it relies on standard COBOL File Status tracking. After every file operation, the 2-character file status variable ( TRNXFILE-STATUS , XREFFILE-STATUS , CUSTFILE-STATUS , or ACCTFILE-STATUS ) is captured and moved to the linkage return code field LK-M03B-RC .

• Caller Responsibility : It is the responsibility of the calling program to inspect the returned LK-M03B-RC value to detect conditions such as:

• '00' : Successful operation.

• '10' : End of file (EOF) reached during sequential reads.

• '23' : Record not found during key-based random reads.

• Invalid DD Routing : If an invalid DD name is passed, the program exits immediately without modifying LK-M03B-RC , which may leave the return code in an undefined state or containing its previous value.

Security and Authorization Checks

No explicit security checks identified. The program does not perform any RACF, user authorization, or data masking checks. It assumes that the calling environment and dataset-level security rules (e.g., access control lists on the physical VSAM datasets) govern access permissions.

Performance Considerations

• Access Mode Optimization :

• TRNX-FILE and XREF-FILE are defined with ACCESS IS SEQUENTIAL . This is highly efficient for batch reporting runs that process the entire dataset from beginning to end.

• CUST-FILE and ACCT-FILE are defined with ACCESS IS RANDOM . This is optimal for direct, single-record lookups using keys, avoiding the overhead of scanning the entire file.

• Input-Only Mode : All files are opened exclusively as INPUT . This prevents lock contention on the VSAM datasets, allowing multiple concurrent batch jobs or online transactions to read the files simultaneously without performance degradation.

• Reference Modification Overhead : The use of reference modification LK-M03B-KEY (1:LK-M03B-KEY-LN) is a CPU-efficient way to handle variable-length keys without requiring complex string parsing or padding loops.

<h2

Daily Transaction Validation and Account Verification Batch Process

The Daily Transaction Validation and Account Verification program is a vital batch processing component within the CardDemo credit card application. Its primary business purpose is to read, verify, and validate daily financial transactions against the system's master records. By ensuring that every transaction is linked to a legitimate card and account, the program acts as an essential quality control gatekeeper before any financial updates are finalized.

During its execution, the program sequentially processes a file containing the day's transaction records. For each transaction, it extracts the card number used in the purchase and performs a lookup against a cross-reference database. This step is crucial for security and integrity, as it verifies that the card number exists and retrieves the associated customer and account identifiers.

After successfully linking the card to an account identifier, the program performs a secondary validation by querying the master account database. This step ensures that the account associated with the transaction is valid and active in the system. If the account lookup fails, the program logs an error indicating that the account could not be found, preventing unauthorized or orphaned transactions from proceeding.

The program features robust error handling and logging capabilities. If a card number cannot be verified in the cross-reference database, the transaction is skipped, and a warning is logged. Furthermore, the program closely monitors all file operations; any critical issues encountered while opening, reading, or closing files will trigger an immediate, controlled system shutdown to protect data integrity.

Functional Overview

CBTRN01C is a batch COBOL program within the CardDemo application. Its primary function is to read and validate daily transaction records from a sequential input file against indexed master files.

For each transaction record processed, the program performs the following operations:

• Reads a transaction record sequentially from the daily transaction file.

• Extracts the card number from the transaction and performs a random read (key lookup) on the Card Cross-Reference indexed file to retrieve the associated Account ID and Customer ID.

• If the card number is successfully verified, the program uses the retrieved Account ID to perform a random read on the Account Master indexed file to verify the account's existence.

• If any lookup fails, the program logs the failure to the system display and skips further processing for that transaction.

• Although the program opens and closes the Customer Master, Card Master, and Transaction History files, it does not perform any read or write operations on them in this version.

Important Constants

• APPL-AOK (Value 0 ) : Condition code indicating successful execution of a file operation.

• APPL-EOF (Value 16 ) : Condition code indicating that the End-of-File has been reached on the sequential daily transaction file.

• 12 : General error return code assigned to APPL-RESULT when a file I/O operation fails.

• 4 : Status code assigned to WS-XREF-READ-STATUS or WS-ACCT-READ-STATUS indicating that a record was not found (Invalid Key) during an indexed file read.

• 999 : The abnormal termination (ABEND) code passed to the IBM Language Environment service CEE3ABD .

Validation Logic

Before processing transaction data, the program performs several layers of validation:

• File Status Validation : After every OPEN , CLOSE , and sequential READ operation, the program validates the file status. Only a status of '00' (or '10' for End-of-File on reads) is considered valid. Any other status code triggers an immediate program abend.

• Card Number Verification : The program validates the transaction's card number ( DALYTRAN-CARD-NUM ) by attempting to retrieve its corresponding record from the XREF-FILE . If the key does not exist (triggering the INVALID KEY condition), the transaction is flagged as unverified and skipped.

• Account ID Verification : The Account ID ( XREF-ACCT-ID ) retrieved from the cross-reference file is validated by attempting to read the ACCOUNT-FILE . If the account record does not exist, the program displays an "ACCOUNT NOT FOUND" warning.

Data Elements Processed

• DALYTRAN-RECORD : The input sequential record containing daily transaction details. Key fields processed include:

• DALYTRAN-ID : Unique transaction identifier.

• DALYTRAN-CARD-NUM : The 16-character card number used to link the transaction to an account.

• CARD-XREF-RECORD : The cross-reference record retrieved from XREF-FILE using DALYTRAN-CARD-NUM as the key. Key fields processed include:

• XREF-CARD-NUM : The indexed lookup key.

• XREF-ACCT-ID : The 11-digit account identifier used to retrieve account details.

• XREF-CUST-ID : The 9-digit customer identifier.

• ACCOUNT-RECORD : The account master record retrieved from ACCOUNT-FILE using XREF-ACCT-ID as the key.

• ACCT-ID : The indexed lookup key.

• IO-STATUS / IO-STATUS-04 : Working-storage fields used to capture, format, and display file status codes (including binary VSAM status codes) during error handling.

Exception and Error Handling

• Indexed Record Not Found (Invalid Key) :

• If a card number is not found in the XREF-FILE , the program displays: INVALID CARD NUMBER FOR XREF followed by CARD NUMBER [num] COULD NOT BE VERIFIED. SKIPPING TRANSACTION ID-[id] . It sets WS-XREF-READ-STATUS to 4 to gracefully bypass account validation for that record.

• If an account is not found in the ACCOUNT-FILE , the program displays: INVALID ACCOUNT NUMBER FOUND followed by ACCOUNT [id] NOT FOUND . It sets WS-ACCT-READ-STATUS to 4 and continues processing the next transaction.

• Critical I/O Failures : Any unexpected file status during OPEN , CLOSE , or sequential READ operations is treated as a critical failure. The program:

• Displays a specific error message indicating which file operation failed.

• Calls Z-DISPLAY-IO-STATUS to format and print the file status.

• Calls Z-ABEND-PROGRAM , which invokes the IBM system utility CEE3ABD with abend code 999 to terminate execution and generate a dump.

• Logic Bug in Close Error Handling : In paragraph 9000-DALYTRAN-CLOSE , if the close of DALYTRAN-FILE fails, the program incorrectly checks CUSTFILE-STATUS and displays "ERROR CLOSING CUSTOMER FILE" instead of checking DALYTRAN-STATUS and displaying a daily transaction file error.

Security and Authorization Checks

No explicit security checks identified. The program relies entirely on mainframe operating system-level security (such as RACF) to control dataset access permissions for the execution JCL.

Performance Considerations

• Unused File Resources : The program opens and closes CUSTOMER-FILE , CARD-FILE , and TRANSACT-FILE in INPUT mode but never reads from them. This incurs unnecessary system overhead during job step initialization and termination, and unnecessarily holds shared locks on these VSAM datasets.

• Random I/O Overhead : For every sequential transaction record read, the program performs up to two random reads (one on XREF-FILE and one on ACCOUNT-FILE ). In a high-volume production environment, this hybrid sequential-random processing pattern can cause significant I/O bottlenecks. Performance could be improved by ensuring appropriate VSAM buffer allocations (BUFND/BUFNI) are defined in the execution JCL.

• Read-Only Processing : Since all files are opened as INPUT and no updates or writes are performed, there is no database modification or write activity. Consequently, checkpointing and commit frequencies are not required for data integrity.

<h2

Daily Credit Card Transaction Posting and Validation Batch Process

This batch program is a core processing component of the CardDemo credit card application. Its primary business purpose is to process and post daily credit card transactions from an incoming sequential file into the system's master databases. By automating this daily reconciliation, the program ensures that customer account balances, transaction histories, and category-specific balances are kept accurate and up to date.

Before any transaction is posted, the program performs a series of critical business validations to protect the financial integrity of the system. It first cross-references the transaction's card number to identify the associated customer account. Once the account is identified, the program verifies that the account is active, checks that the transaction amount will not push the account over its assigned credit limit, and ensures the transaction date does not exceed the card's expiration date.

For transactions that pass all validation checks, the program performs real-time financial updates. It adjusts the customer's current account balance and updates the cycle's credit or debit totals depending on whether the transaction is a charge or a payment. Additionally, it updates or creates category-specific transaction balances (such as retail, travel, or cash advances) to track spending habits, and writes a permanent record of the approved transaction to the master transaction history file.

Transactions that fail validation are rejected and written to a daily rejects file, accompanied by a specific error code and description explaining the failure (such as an invalid card number, an expired card, or an over-limit transaction). Upon completing the file processing, the program displays summary statistics detailing the total number of transactions processed and rejected, and issues a warning return code if any rejected transactions require operational review.

Business Logic Overview

The CBTRN02C program is a batch COBOL program designed to process and post daily transaction records from a sequential input file ( DALYTRAN ) into the core system. The program performs validation checks against a card cross-reference file and an account master file.

For each valid transaction, the program:

• Updates the transaction category balance file ( TCATBAL ).

• Updates the account master file ( ACCOUNT ) with the transaction amount and cycle accumulators.

• Writes the posted transaction to the master transaction file ( TRANSACT ).

If a transaction fails any validation check, it is rejected. The program writes the rejected transaction along with a validation trailer containing the error code and description to a sequential rejects file ( DALYREJS ).

Detailed Process Flow

Initialization :

• Opens all required files:

• DALYTRAN-FILE (Sequential Input)

• TRANSACT-FILE (Indexed Output)

• XREF-FILE (Indexed Input)

• DALYREJS-FILE (Sequential Output)

• ACCOUNT-FILE (Indexed I-O)

• TCATBAL-FILE (Indexed I-O)

• If any file fails to open successfully (status other than 00 ), the program displays an error message, formats the status, and terminates abnormally (ABEND).

Main Processing Loop :

• Reads the DALYTRAN-FILE sequentially until the end of the file is reached.

• For each record read:

• Increments the total transaction counter ( WS-TRANSACTION-COUNT ).

• Initializes the validation failure reason and description.

• Executes the validation logic.

• If Validation Succeeds :

• Formats the transaction record and generates a DB2-style processing timestamp.

• Updates the transaction category balance (either updates an existing record or creates a new one if it does not exist).

• Updates the account master record's current balance and cycle credit/debit accumulators.

• Writes the transaction record to the master transaction file.

• If Validation Fails :

• Increments the reject counter ( WS-REJECT-COUNT ).

• Writes the original transaction data along with the validation failure reason and description to the rejects file.

Termination :

• Closes all open files.

• Displays the total number of transactions processed and rejected.

• If any transactions were rejected during the run, the program sets the job step return code ( RETURN-CODE ) to 4 .

• Terminates execution normally.

Important Constants

• Validation Error Codes :

• 100 : Invalid Card Number Found (Cross-reference lookup failed).

• 101 : Account Record Not Found (Account lookup failed).

• 102 : Overlimit Transaction (New balance exceeds the credit limit).

• 103 : Transaction Received After Account Expiration (Transaction date is past the account expiration date).

• 109 : Account Record Not Found during rewrite (Account update failed).

• File Status Codes :

• '00' : Successful I/O operation.

• '10' : End of file reached.

• '23' : Record not found (Key mismatch on indexed files).

• Abend Code :

• 999 : Passed to the IBM Language Environment abend service CEE3ABD during critical I/O failures.

Validation Logic

Before any transaction is posted, it must pass the following sequential validation checks:

Card Cross-Reference Lookup :

• The program searches the XREF-FILE using the transaction's card number ( DALYTRAN-CARD-NUM ) as the key.

• If the card number is not found (triggering an INVALID KEY condition), validation fails with error code 100 ("INVALID CARD NUMBER FOUND").

Account Master Lookup :

• If the card is valid, the program retrieves the associated account ID ( XREF-ACCT-ID ) from the cross-reference record and searches the ACCOUNT-FILE .

• If the account record is not found (triggering an INVALID KEY condition), validation fails with error code 101 ("ACCOUNT RECORD NOT FOUND").

Credit Limit Verification :

• If the account is found, the program calculates a temporary balance:

$$\text{Temporary Balance} = \text{Current Cycle Credit} - \text{Current Cycle Debit} + \text{Transaction Amount}$$

• If the calculated temporary balance exceeds the account's credit limit ( ACCT-CREDIT-LIMIT ), validation fails with error code 102 ("OVERLIMIT TRANSACTION").

Account Expiration Verification :

• The program compares the account's expiration date ( ACCT-EXPIRAION-DATE ) with the transaction's origin date (extracted from the first 10 characters of DALYTRAN-ORIG-TS ).

• If the transaction origin date is strictly greater than the account expiration date, validation fails with error code 103 ("TRANSACTION RECEIVED AFTER ACCT EXPIRATION").

Data Elements Processed

Input Transaction Fields ( DALYTRAN-RECORD ) :

• DALYTRAN-ID : Unique transaction identifier.

• DALYTRAN-CARD-NUM : Card number used for cross-reference lookup.

• DALYTRAN-AMT : Signed numeric transaction amount.

• DALYTRAN-TYPE-CD & DALYTRAN-CAT-CD : Transaction type and category codes used for balance tracking.

• DALYTRAN-ORIG-TS : Timestamp of when the transaction originated.

• Merchant details: DALYTRAN-MERCHANT-ID , DALYTRAN-MERCHANT-NAME , DALYTRAN-MERCHANT-CITY , and DALYTRAN-MERCHANT-ZIP .

Account Master Fields ( ACCOUNT-RECORD ) :

• ACCT-ID : Unique account identifier.

• ACCT-CREDIT-LIMIT : Maximum credit limit allowed.

• ACCT-EXPIRAION-DATE : Expiration date of the account.

• ACCT-CURR-BAL : Current outstanding balance.

• ACCT-CURR-CYC-CREDIT : Accumulated credit amount for the current billing cycle.

• ACCT-CURR-CYC-DEBIT : Accumulated debit amount for the current billing cycle.

Transaction Category Balance Fields ( TRAN-CAT-BAL-RECORD ) :

• TRAN-CAT-KEY : Composite key consisting of Account ID, Transaction Type Code, and Transaction Category Code.

• TRAN-CAT-BAL : Accumulated balance for this specific transaction category.

Output/Generated Fields :

• TRAN-PROC-TS : Processing timestamp generated in DB2 format ( YYYY-MM-DD-HH.MM.SS.MIL0000 ).

• WS-VALIDATION-FAIL-REASON & WS-VALIDATION-FAIL-REASON-DESC : Error details written to the rejects file trailer.

Exception and Error Handling

Critical File I/O Failures :

• Every file operation (Open, Read, Write, Rewrite, Close) is monitored via its file status variable.

• If an unexpected file status is returned (any status other than '00' , '10' for EOF, or '23' where handled), the program:

• Displays a descriptive error message.

• Formats the file status using 9910-DISPLAY-IO-STATUS (handling both standard and VSAM-specific status codes).

• Calls 9999-ABEND-PROGRAM , which invokes the IBM system service CEE3ABD with abend code 999 to terminate the job step immediately.

Non-Critical Validation Failures :

• Mismatches during random reads on XREF-FILE and ACCOUNT-FILE are handled gracefully via INVALID KEY clauses. Instead of crashing, the program flags the record as rejected, writes it to the rejects file, and continues processing the next transaction.

Account Update Failures :

• If a rewrite operation on the ACCOUNT-FILE fails with an INVALID KEY condition, the program assigns error code 109 to the validation trailer but does not abend, allowing subsequent records to process.

Security and Authorization Checks

No explicit security checks identified.

Performance Considerations

Random I/O Bottlenecks :

• The program processes the input file sequentially but performs multiple random reads and writes ( READ , WRITE , REWRITE ) against indexed VSAM files ( XREF-FILE , ACCOUNT-FILE , TCATBAL-FILE ) for every transaction. In high-volume environments, this pattern can cause significant I/O overhead.

Lack of Commit/Checkpointing :

• The program does not implement database commits or checkpoint-restart logic. If an abend occurs mid-run, the indexed files will be left in a partially updated state. This requires restoring the files from backups or performing manual reconciliation before restarting the batch job.

<h2

Daily Transaction Detail Reporting and Reconciliation Program

The CBTRN03C program is a batch processing component of the CardDemo credit card management system. Its primary business purpose is to generate a structured, formatted Daily Transaction Report that details financial activities within a specified timeframe. This report serves as a critical tool for financial auditing, account reconciliation, and operational oversight.

To initiate the reporting process, the program reads a date parameter file to establish the start and end dates for the reporting window. It then sequentially processes the main transaction ledger, filtering out any transactions that fall outside this specified date range. This ensures that the resulting report is strictly focused on the requested accounting period.

For each transaction within the date range, the program performs automated lookups against multiple master reference files to enrich the raw transaction data. It translates the card number into the associated customer account identifier and retrieves descriptive, human-readable names for both the transaction type and the transaction category. This enrichment process converts raw system codes into clear, actionable business information for report readers.

The program formats the compiled data into a professional multi-page report. It groups transactions by cardholder account, automatically calculating and printing sub-totals when transitioning between different accounts. Additionally, the program manages page layouts by inserting standardized headers and calculating page-level totals at regular intervals, concluding the entire run with a grand total of all processed transaction amounts to ensure complete financial balancing.

Business Logic

The program CBTRN03C is a batch COBOL program designed to process a sequential transaction file and generate a formatted "Daily Transaction Report" ( TRANREPT ). The report includes transaction details, page-level totals, account-level totals (triggered by a control break on the card number), and a final grand total.

1. Initialization and Setup

• File Operations : The program opens six files:

• TRANSACT-FILE (Input, Sequential): Contains the transaction records to be processed.

• REPORT-FILE (Output, Sequential): The destination for the formatted report.

• XREF-FILE (Input, Indexed VSAM): Cross-reference file linking card numbers to account IDs.

• TRANTYPE-FILE (Input, Indexed VSAM): Contains transaction type descriptions.

• TRANCATG-FILE (Input, Indexed VSAM): Contains transaction category descriptions.

• DATE-PARMS-FILE (Input, Sequential): Contains the start and end dates for filtering transactions.

• Parameter Retrieval : The program reads a single record from the DATE-PARMS-FILE to populate WS-START-DATE and WS-END-DATE . If successful, it displays the reporting date range.

2. Main Processing Loop

The program reads the TRANSACT-FILE sequentially and processes each record within a loop until the end of the file ( END-OF-FILE = 'Y' ) is reached.

Date Filtering and Logical Flow :

• For each transaction, the program extracts the first 10 characters of the processing timestamp ( TRAN-PROC-TS ).

• It compares this date against the parameter range ( WS-START-DATE and WS-END-DATE ).

• Logical Anomaly : If the transaction date is within the range, the program executes CONTINUE and proceeds. If the date is outside the range, it executes NEXT SENTENCE . In this program's structure, because there are no periods inside the PERFORM UNTIL loop, NEXT SENTENCE transfers control to the statement immediately following the next period (which is after END-PERFORM ). This causes the program to prematurely exit the processing loop and terminate as soon as any transaction falls outside the date range.

Control Break on Card Number :

• The program tracks the card number of the current transaction using WS-CURR-CARD-NUM .

• When the card number changes (and it is not the first record processed), an account control break is triggered:

• The accumulated account total ( WS-ACCOUNT-TOTAL ) is formatted and written to the report.

• The account total accumulator is reset to zero.

• A separator line is written to the report.

• The program then updates WS-CURR-CARD-NUM with the new transaction's card number and performs a random read on the XREF-FILE to retrieve the associated Account ID ( XREF-ACCT-ID ).

Master Data Lookups :

• Transaction Type : The program uses TRAN-TYPE-CD to perform a random read on TRANTYPE-FILE to retrieve the transaction type description ( TRAN-TYPE-DESC ).

• Transaction Category : The program constructs a composite key using TRAN-TYPE-CD and TRAN-CAT-CD to perform a random read on TRANCATG-FILE to retrieve the category description ( TRAN-CAT-TYPE-DESC ).

Report Formatting and Pagination :

• First-Time Execution : On the very first detail record, the program writes the main report header (including the date range parameters) and sets WS-FIRST-TIME to 'N'.

• Pagination : The program monitors the line count ( WS-LINE-COUNTER ) against the page size ( WS-PAGE-SIZE = 20) using a modulo operation ( FUNCTION MOD ). When the line limit is reached:

• The current page total ( WS-PAGE-TOTAL ) is written to the report.

• The page total is added to the grand total ( WS-GRAND-TOTAL ), and the page accumulator is reset to zero.

• A new page header is written.

• Accumulation : The transaction amount ( TRAN-AMT ) is added to both WS-PAGE-TOTAL and WS-ACCOUNT-TOTAL .

• Detail Writing : The transaction details (ID, Account ID, Type, Category, Source, and Amount) are formatted into TRANSACTION-DETAIL-REPORT and written to the report file.

3. End-of-File Processing

When the sequential transaction file reaches EOF:

• Logical Anomaly : The program enters the ELSE block of the EOF check. It displays the last transaction amount and page total, and adds TRAN-AMT (which is now invalid or contains stale data from the last record) to the page and account accumulators.

• The final page totals are written to the report (which also adds the final page total to the grand total).

• The final grand total ( WS-GRAND-TOTAL ) is formatted and written to the report.

• All open files are closed, and the program terminates.

Important Constants

• REPT-SHORT-NAME : 'DALYREPT' (The short identifier printed in the report header).

• REPT-LONG-NAME : 'Daily Transaction Report' (The main title printed in the report header).

• WS-PAGE-SIZE : 20 (The maximum number of detail lines printed per page before triggering a page break).

• ABCODE : 999 (The abnormal termination code passed to the system dump routine).

Validation Logic

• File Status Code Verification : After every file I/O operation (OPEN, READ, WRITE, CLOSE), the program evaluates the corresponding file status variable (e.g., TRANFILE-STATUS , CARDXREF-STATUS ).

• A status of '00' indicates success.

• For read operations, a status of '10' indicates End of File (EOF).

• Any other status code is treated as a critical error, triggering an error message display, a formatted status dump, and an immediate program ABEND.

• Date Range Validation : The program validates that the transaction processing date ( TRAN-PROC-TS positions 1-10) is chronologically greater than or equal to WS-START-DATE and less than or equal to WS-END-DATE .

• Referential Integrity / Key Lookups :

• Card Cross-Reference : The transaction card number ( TRAN-CARD-NUM ) is used as a key to read XREF-FILE . If the card number does not exist, the INVALID KEY routine is triggered, displaying an error message and abending the program.

• Transaction Type : The transaction type code ( TRAN-TYPE-CD ) must exist in TRANTYPE-FILE . An invalid key triggers an immediate program ABEND.

• Transaction Category : The composite key of type and category must exist in TRANCATG-FILE . An invalid key triggers an immediate program ABEND.

Data Elements Processed

Input Parameters

• WS-START-DATE (PIC X(10)): The starting date of the reporting window.

• WS-END-DATE (PIC X(10)): The ending date of the reporting window.

Transaction Record Fields

• TRAN-ID (PIC X(16)): Unique identifier for the transaction.

• TRAN-CARD-NUM (PIC X(16)): The card number used to perform the account lookup.

• TRAN-TYPE-CD (PIC X(02)): Code representing the type of transaction.

• TRAN-CAT-CD (PIC 9(04)): Code representing the category of transaction.

• TRAN-SOURCE (PIC X(10)): The origin channel of the transaction.

• TRAN-AMT (PIC S9(09)V99): The signed monetary value of the transaction.

• TRAN-PROC-TS (PIC X(26)): The timestamp when the transaction was processed.

Lookup and Reference Fields

• XREF-ACCT-ID (PIC 9(11)): The account number retrieved from the cross-reference file.

• TRAN-TYPE-DESC (PIC X(50)): Text description of the transaction type.

• TRAN-CAT-TYPE-DESC (PIC X(50)): Text description of the transaction category.

Accumulators and Counters

• WS-LINE-COUNTER (PIC 9(09) COMP-3): Tracks the number of lines written to the current page.

• WS-PAGE-TOTAL (PIC S9(09)V99): Accumulates transaction amounts for the current page.

• WS-ACCOUNT-TOTAL (PIC S9(09)V99): Accumulates transaction amounts for the current card/account.

• WS-GRAND-TOTAL (PIC S9(09)V99): Accumulates transaction amounts across the entire run.

Output Fields

• FD-REPTFILE-REC (PIC X(133)): The 133-character output buffer written to the sequential report file.

Exception and Error Handling

• I/O Error Detection : The program maps file status codes to a standardized application result ( APPL-RESULT ). If an operation fails (status other than '00' or '10' ), the program branches to error-handling routines.

• ABEND Management : When a critical error is encountered (such as a file open failure, write failure, or an invalid key on a VSAM lookup), the program executes 9999-ABEND-PROGRAM :

• It displays a specific error message indicating which file or operation failed.

• It calls 9910-DISPLAY-IO-STATUS to format and display the exact file status. For VSAM files (status starting with '9'), it extracts and displays the binary sub-codes.

• It calls the IBM Language Environment dump and abend service CEE3ABD using an abend code of 999 and a timing parameter of 0 to terminate execution immediately.

• Invalid Key Handling : Random reads on indexed VSAM files utilize the INVALID KEY imperative statement. If a lookup key is missing from the index, the program displays the invalid key value, sets the status to '23' (Record not found), and triggers the standard ABEND routine.

Security and Authorization Checks

No explicit security checks identified.

Performance Considerations

• Indexed VSAM Lookups : The program performs random reads ( ACCESS MODE IS RANDOM ) on three indexed files ( XREF-FILE , TRANTYPE-FILE , and TRANCATG-FILE ) for each transaction. While random access is efficient for individual lookups, processing large volumes of transactions sequentially will result in high I/O overhead.

• Control Break Optimization : The program optimizes cross-reference lookups by only querying the XREF-FILE when the card number changes ( WS-CURR-CARD-NUM NOT= TRAN-CARD-NUM ). If the input transaction file is pre-sorted by card number, this significantly reduces the number of VSAM read operations.

• Packed Decimal Usage : Accumulators ( WS-LINE-COUNTER , WS-PAGE-SIZE ) are defined as COMP-3 (packed decimal), which optimizes arithmetic operations and decimal alignment on IBM Mainframe processors.

<h2

Mainframe Account Inquiry Message Queue Processor

This program serves as an asynchronous business service that processes account inquiry requests within a CICS mainframe environment. By interfacing with IBM MQ messaging middleware, the program acts as a bridge between external requesting applications and the core mainframe account database, enabling high-throughput, message-driven account data retrieval.

Upon invocation, the program retrieves its startup configuration from CICS to identify the triggering input queue. It establishes connections to three critical message queues: the input queue containing incoming requests, a reply queue for sending back account details, and a dedicated error queue for logging system and processing failures. Once the queues are successfully opened, the program enters a processing loop to handle all available messages.

For each request retrieved from the input queue, the program extracts the requested transaction function and the unique account identifier. It validates the request and queries the primary account data store to retrieve comprehensive account details. The retrieved information includes the account's active status, current balance, credit and cash limits, key lifecycle dates (such as open, expiration, and reissue dates), and current cycle financial balances.

After successfully retrieving the account record, the program formats a structured response message and posts it to the designated reply queue, ensuring the original message identifiers are preserved for request-response correlation. If the requested account is not found or if the input parameters are invalid, the program generates a descriptive error response and sends it back to the requester. Any unexpected system or queue manager errors are routed to the centralized error queue for administrative monitoring.

To maintain data consistency and operational reliability, the program utilizes transactional syncpoints to commit message consumption and database reads. The processing loop continues until a predefined wait interval expires with no new messages, at which point the program safely closes all open queues, releases system resources, and terminates cleanly.

Business Case and User Interaction Report: COACCT01

Business Case Overview

COACCT01 is a backend, message-driven CICS-MQ service program designed to handle Account Inquiry ( INQA ) requests. It acts as an integration middleware service within a mainframe modernization architecture (such as CardDemo).

Instead of interacting directly with an end-user via CICS BMS maps (screens), this program processes asynchronous or synchronous MQ messages sent by upstream client applications (such as web portals, mobile apps, or API gateways).

The program performs the following business functions:

• Triggered Execution : Started automatically by CICS when a message arrives on the monitored input queue.

• Message Retrieval : Reads request messages containing account inquiry parameters.

• Data Retrieval : Queries a VSAM Key-Sequenced Data Set (KSDS) named ACCTDAT using the provided Account ID.

• Response Formatting : Formats the retrieved account details into a structured, readable text layout.

• Reply Delivery : Sends the formatted response back to the designated reply queue.

• Error Logging : Routes any processing or system errors to a centralized error queue for monitoring and troubleshooting.

User Interaction and Interface Representation

Because COACCT01 is a non-interactive service program, there are no physical screens. Instead, the "user interaction" is defined by the input request message payload and the output reply message payload.

Request Message Format (Input)

The upstream system must send a text message of 1000 bytes containing:

• Function Code (4 characters): Must be INQA .

• Account ID (11 characters): The numeric key of the account to query.

Reply Message Format (Output)

When an account is successfully found, the program returns a formatted string containing labeled account details:

ACCOUNT ID : [11-digit ID] ACCOUNT STATUS : [Status] BALANCE : [Amount] CREDIT LIMIT : [Amount] CASH LIMIT : [Amount] OPEN DATE : [Date] EXPR DATE : [Date] REIS DATE : [Date] CREDIT BAL : [Amount] DEBIT BAL : [Amount] GROUP ID : [Group ID]

System Interaction and Data Flow Diagram

The following ASCII diagram illustrates how the client application, MQ queues, CICS, the COACCT01 program, and the VSAM database interact.

+---------------------------------------------------------------------------------+

| UPSTREAM SYSTEM |

+---------------------------------------------------------------------------------+

| ^

| 1. Send Request Message | 8. Receive Reply

v |

+-----------------------+ +------------------+

| MQ Input Queue | | MQ Reply Queue |

| (e.g. CARD.DEMO.INP) | | (Dynamic/Static) |

+-----------------------+ +------------------+

| ^

| 2. Trigger | 7. MQPUT

v | Reply

+-----------------------+ 3. Start +------------------+ |

| CICS Trigger Monitor | ---------------> | COBOL Program | -----------+

| (CKTI) | | COACCT01 |

+-----------------------+ +------------------+

| ^

4. MQGET | | 6. Read Success/

Request v | Not Found

+------------------+

| VSAM KSDS |

| File: ACCTDAT |

+------------------+

|

| (On System Error)

v

+------------------+

| MQ Error Queue |

| CARD.DEMO.ERROR |

+------------------+

Data Flow Description

• Initiation : An upstream client puts a request message onto the MQ Input Queue.

• Triggering : The CICS Trigger Monitor ( CKTI ) detects the message and triggers the execution of transaction COACCT01 .

• Queue Retrieval : COACCT01 starts and executes EXEC CICS RETRIEVE to obtain the name of the queue that triggered it.

• Queue Opening : The program opens the Input Queue, the Default Reply Queue ( CARD.DEMO.REPLY.ACCT ), and the Error Queue ( CARD.DEMO.ERROR ).

• Message Processing Loop :

• The program performs an MQGET to retrieve the request message.

• It extracts the Function Code ( WS-FUNC ) and Account ID ( WS-KEY ).

• It performs a random read ( EXEC CICS READ ) on the ACCTDAT VSAM file using the Account ID as the key.

• If found, it maps the VSAM record fields to the formatted output structure ( WS-ACCT-RESPONSE ) and puts it on the reply queue via MQPUT .

• If not found or if the input is invalid, it formats an error text response and puts it on the reply queue.

• Commitment : An EXEC CICS SYNCPOINT is issued after processing each message to commit the MQ and VSAM operations.

• Termination : The loop continues until no more messages are available on the input queue (after a 5-second wait timeout), at which point the program closes all queues and terminates.

User Navigation

Since this is an automated service, there is no manual user navigation. The "navigation" is transaction-driven:

• Request Submission : The client application connects to MQ and submits an inquiry payload.

• Processing : The client application waits synchronously or asynchronously on its designated reply queue (using the CorrelId or MsgId for correlation).

• Response Consumption : The client application receives the formatted text response, parses it, and displays the data on the end-user's screen (web/mobile/terminal).

Important Constants

The following constants are defined and utilized within the program:

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| LIT-ACCTFILENAME | 'ACCTDAT ' | The DD name of the VSAM KSDS file containing account records. |

| REPLY-QUEUE-NAME | 'CARD.DEMO.REPLY.ACCT' | The default MQ queue name used for sending successful or validation-failed replies. |

| ERROR-QUEUE-NAME | 'CARD.DEMO.ERROR' | The MQ queue name used for routing system and application error descriptors. |

| WS-FUNC (Expected) | 'INQA' | The required transaction function code for Account Inquiry. |

| MQGMO-WAITINTERVAL | 5000 | The MQGET wait time-out interval in milliseconds (5 seconds). |

| MQ-BUFFER-LENGTH | 1000 | The standard buffer size allocated for MQ messages. |

Validation Logic

The program performs several layers of validation before processing the business logic:

• CICS Retrieve Validation :

• Checks if the CICS start/retrieve process succeeded ( WS-CICS-RESP1-CD = DFHRESP(NORMAL) ). If it fails, the program logs the error and terminates immediately.

• Function Code Validation :

• The input field WS-FUNC is checked. It must be exactly 'INQA' . If it is not, the request is rejected as invalid.

• Key Validation :

• The input field WS-KEY (Account ID) is checked. It must be greater than zero ( WS-KEY > ZEROES ). If it is zero or spaces, the request is rejected.

• VSAM Record Existence Check :

• When reading the ACCTDAT file, the program checks the CICS response code ( WS-RESP-CD ).

• If DFHRESP(NORMAL) , validation succeeds and processing continues.

• If DFHRESP(NOTFND) , the validation fails because the account does not exist.

Data Elements Processed

Input Request Fields

• WS-FUNC : Function code requested (4 characters).

• WS-KEY : Account ID key requested (11 digits).

Backend Database Fields (VSAM ACCOUNT-RECORD )

• ACCT-ID : Unique account identifier (11 digits).

• ACCT-ACTIVE-STATUS : Status of the account (1 character, e.g., Active/Inactive).

• ACCT-CURR-BAL : Current balance of the account (Signed numeric, 10v92).

• ACCT-CREDIT-LIMIT : Maximum credit limit (Signed numeric, 10v92).

• ACCT-CASH-CREDIT-LIMIT : Cash advance limit (Signed numeric, 10v92).

• ACCT-OPEN-DATE : Date the account was opened (10 characters).

• ACCT-EXPIRAION-DATE : Expiration date of the account card (10 characters).

• ACCT-REISSUE-DATE : Last reissue date of the card (10 characters).

• ACCT-CURR-CYC-CREDIT : Total credits in the current cycle (Signed numeric, 10v92).

• ACCT-CURR-CYC-DEBIT : Total debits in the current cycle (Signed numeric, 10v92).

• ACCT-GROUP-ID : Group identifier associated with the account (10 characters).

Exception and Error Handling

The program features robust error handling designed to prevent message loss and report system failures:

1. Application-Level Errors (Returned to Reply Queue)

When a request fails validation or the account is not found, the program formats a descriptive error message and sends it back to the client via the Reply Queue :

• Account Not Found :

INVALID REQUEST PARAMETERS ACCT ID : [WS-KEY]

• Invalid Function/Parameters :

INVALID REQUEST PARAMETERS ACCT ID : [WS-KEY] FUNCTION : [WS-FUNC]

2. System-Level Errors (Routed to Error Queue)

If a severe system error occurs (such as an MQ call failure or a VSAM read error other than NOTFND ), the program:

• Formats an error block ( MQ-ERR-DISPLAY ) containing:

• The paragraph where the error occurred ( MQ-ERROR-PARA ).

• A descriptive return message ( MQ-APPL-RETURN-MESSAGE ).

• The MQ/CICS Condition Code ( MQ-APPL-CONDITION-CODE ).

• The MQ/CICS Reason Code ( MQ-APPL-REASON-CODE ).

• The target Queue Name ( MQ-APPL-QUEUE-NAME ).

• Executes MQPUT to write this error block to the Error Queue ( CARD.DEMO.ERROR ).

• Calls the termination routine ( 8000-TERMINATION ) to close open queues and exit.

3. CICS Response Codes Checked

• DFHRESP(NORMAL) : Proceed with normal processing.

• DFHRESP(NOTFND) : Handle gracefully by returning an "Invalid Request Parameters" message to the reply queue.

• Other CICS Responses : Treated as severe system errors; routed to the error queue, followed by program termination.

Security and Authorization Checks

• No explicit security checks identified within the source code.

• There are no RACF calls ( EXEC SECURE or AUTH ), transaction security checks, or sign-on validations ( CESN / CESF ) implemented inside COACCT01 . Security is assumed to be managed externally at the CICS transaction definition level or via MQ queue access control lists (ACLs).

Performance Considerations

• Syncpoint Control :

The program utilizes CICS Syncpoint ( EXEC CICS SYNCPOINT ) at the start of each message processing cycle ( 4000-MAIN-PROCESS ). This ensures that the MQ message consumption and any associated resource updates are committed safely under a single Unit of Work (UOW).

• MQ Wait Interval :

The MQGET call uses a wait interval of 5000ms (5 seconds) with the MQGMO-WAIT option. This prevents the program from consuming CPU cycles in a tight loop when the queue is empty, allowing it to terminate gracefully when work is complete.

• Shared Input Queue :

The input queue is opened with MQOO-INPUT-SHARED , allowing multiple instances of this program to run concurrently in CICS to handle high-volume message spikes.

• Fail-If-Quiescing :

All MQ operations use the FAIL-IF-QUIESCING option, ensuring that the program shuts down cleanly if the MQ Queue Manager is shutting down.

<h2

Online Account and Customer Profile Update Management System

The COACTUPC program is an interactive business-logic application designed to facilitate the secure retrieval, validation, and modification of credit card accounts and associated customer profiles. Operating within the CardDemo credit card processing suite, this program serves as a critical administrative tool that allows customer service representatives and credit managers to maintain up-to-date financial and personal data. By consolidating account-level financial parameters and customer-level demographic details into a single operational flow, the program ensures data consistency across the enterprise's core databases.

When a user initiates an update, the program prompts for a unique eleven-digit account number. Upon entry, it performs a multi-file lookup, first querying a card cross-reference index to identify the associated customer ID and card number, and then retrieving the complete records from the Account Master and Customer Master databases. The system displays a comprehensive view of the current state, including credit limits, cash advance limits, outstanding balances, cycle credits/debits, and the customer's personal details such as name, address, phone numbers, Social Security Number, date of birth, and FICO credit score.

Before any modification is committed to the database, the program executes a rigorous suite of business and validation rules to protect data integrity. It verifies that financial limits are valid numeric amounts, ensures that dates (such as account opening, expiration, reissue, and birth dates) are calendar-compliant and logical, and validates that the customer's FICO score falls within the standard credit bureau range of 300 to 850. Furthermore, it performs regional checks, such as verifying that the state code is valid and matches the first digits of the provided ZIP code, and ensures that phone numbers and Social Security Numbers conform to standard North American formats.

To prevent data conflicts in a high-volume, multi-user environment, the program implements a secure double-lock update process with optimistic concurrency control. Once the user reviews and confirms the validated changes, the program temporarily locks both the account and customer records for update. It then compares the database's current state with the original values fetched at the start of the session; if another user has modified the records in the interim, the transaction is safely aborted to prevent overwriting. If the records are unchanged, the program rewrites both files in a coordinated transaction, rolling back changes if either update fails.

The program is designed to support seamless navigation and session preservation within the larger CardDemo ecosystem. It integrates directly with the application's main menu and other card management modules, passing critical session metadata—such as user identity, security roles, and transaction history—via a shared communication area. This pseudo-conversational design ensures that mainframe system resources are released while waiting for user input, optimizing system performance and supporting high concurrent user activity.

Business Case and User Interaction

Business Case Overview

The COACTUPC program is a core business logic and presentation controller within the CardDemo application. It provides online terminal users with the ability to search, retrieve, validate, and update comprehensive Account and Customer Master records.

By integrating data from three distinct files—the Card Cross-Reference file ( CXACAIX ), the Account Master file ( ACCTDAT ), and the Customer Master file ( CUSTDAT )—the program presents a unified view of a customer's financial account limits, status, and personal demographic details.

The primary business objectives of this program are:

• Data Integrity : Enforcing strict validation rules on all editable fields (such as credit limits, dates, Social Security Numbers, FICO scores, and address details) before committing changes.

• Concurrency Control : Implementing optimistic locking checks to ensure that no two operators overwrite each other's changes simultaneously.

• User-Friendly Workflow : Guiding the operator through a multi-stage process of searching, editing, reviewing, and confirming updates.

User Interaction and Screen Flow

1. Search Stage (Initial Entry)

• Action : The user enters the program (either directly or via the Main Menu COMEN01C ).

• Screen State : All detail fields are protected and blank. Only the Account ID search field is unprotected and ready for input.

• User Input : The user types an 11-digit Account ID and presses ENTER .

• System Response :

• The program reads the Card Cross-Reference file using the Account ID to find the associated Customer ID and Card Number.

• It then retrieves the corresponding records from the Account Master and Customer Master files.

• If found, the screen is populated with the retrieved data, detail fields are unprotected for editing, and the program prompts: "Update account details presented above."

• If not found, an appropriate error message is displayed in red at the bottom of the screen.

2. Edit and Validation Stage

• Action : The user modifies any of the unprotected fields (e.g., changing the Credit Limit, updating an address, or correcting a phone number).

• User Input : The user presses ENTER to submit the changes.

• System Response :

• The program compares the new screen inputs against the originally fetched values.

• If no changes are detected, it displays: "No change detected with respect to values fetched."

• If changes are detected, it performs extensive validation on every modified field.

• Validation Failure : If any field fails validation, the program marks the field in error, changes its attribute to red, positions the cursor at the first invalid field, and displays a specific error message.

• Validation Success : If all fields pass validation, the program transitions to a "pending confirmation" state, protects the input fields, and prompts: "Changes validated. Press F5 to save" .

3. Confirmation and Commit Stage

• Action : The user reviews the validated changes.

• User Input :

• Press PF5 to confirm and save.

• Press PF12 to cancel and revert to the original values.

• System Response (PF5 - Save) :

• The program re-reads both the Account and Customer records with an update lock ( READ UPDATE ).

• It performs a concurrency check to verify that the records have not been modified by another transaction since they were initially fetched.

• If the records are unchanged, the program rewrites both files, commits the transaction, clears the screen, and displays: "Changes committed to database" .

• If a concurrency conflict is detected, the update is aborted, and the user is prompted to review the updated record.

• System Response (PF12 - Cancel) :

• The program discards the pending changes, re-reads the original records from the database, and redisplays them.

4. Exit Stage

• User Input : The user presses PF3 at any time.

• System Response : The program performs a CICS syncpoint and transfers control ( EXEC CICS XCTL ) back to the calling program or the Main Menu ( COMEN01C ).

Screen Layout and Flow Diagrams

Screen Layout (CACTUPA)

+-----------------------------------------------------------------------------+

| Tran: CAUP AWS Mainframe Modernization Date: MM/DD/YY |

| Prog: COACTUPC CardDemo Time: HH:MM:SS |

| |

| UPDATE ACCOUNT & CUSTOMER DETAILS |

| |

| Account ID: [12345678901] Account Status: [Y] |

| Open Date : [2020]-[01]-[15] Credit Limit : [$ 10,000.00] |

| Exp Date : [2025]-[01]-[15] Cash Limit : [$ 2,000.00] |

| Reissue Dt: [2020]-[01]-[15] Group ID : [GROUP01 ] |

| Curr Bal : [$ 50.00] Cycle Credit : [$ 0.00] |

| Cycle Deb : [$ 50.00] |

| --------------------------------------------------------------------------- |

| Cust ID : 000000123 SSN : [123]-[45]-[6789] |

| First Name: [JOHN ] Middle Name : [ALAN ]

| Last Name : [DOE ] DOB : [1980]-[05]-[20] |

| FICO Score: [750] Govt ID : [AB123456C ]|

| Address L1: [123 MAIN STREET ]|

| Address L2: [APARTMENT 4B ]|

| City : [NEW YORK ]|

| State : [NY] Zip Code : [10001] |

| Country : USA EFT Acct ID : [1234567890] |

| Phone 1 : ([212])-[555]-[1234] Phone 2 : ([ ])-[ ]-[ ] |

| Pri Holder: [Y] |

| |

| Info: <WS-INFO-MSG: Prompt messages appear here > |

| Error: <WS-RETURN-MSG: Validation/System errors appear here in red > |

| |

| ENTER=Validate F5=Save F12=Cancel F3=Exit |

+-----------------------------------------------------------------------------+

Screen Navigation and State Transitions

+------------------------+

| Start / Main Menu |

| (COMEN01C) |

+-----------+------------+

|

| (Select Option 2 / Tran: CAUP)

v

+------------------------+

| State: NOT FETCHED | <----------------------------+

| - Prompt for Acct ID | |

+-----------+------------+ |

| |

| (Enter Acct ID & Press ENTER) |

v |

+------------------------+ |

| State: SHOW DETAILS | |

| - Display fetched data | |

+-----------+------------+ |

| |

| (Modify Fields & Press ENTER) |

v |

/----------------------\ |

/ Are Changes Valid? \ |

\ / |

\----------+-----------/ |

| |

No | Yes |

+-------------------------+-------------------------+ |

| | |

v v |

+------------------------+ +------------------------+ |

| State: CHANGES NOT OK | | State: OK NOT CONFIRMED| |

| - Highlight errors | | - Prompt PF5 to Save | |

| - Redisplay screen | +------------+-----------+ |

+-----------+------------+ | |

| | |

| (Re-edit & Press ENTER) | |

+---------------------------------------------------|-(PF12) |

| |

| (PF5) |

v |

+------------------------+ |

| State: OKAYED & DONE | |

| - Commit to Database | |

| - Clear Screen | |

+------------+-----------+ |

| |

+-------------+

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| LIT-THISPGM | 'COACTUPC' | Program ID of this module |

| LIT-THISTRANID | 'CAUP' | CICS Transaction ID for Account Update |

| LIT-THISMAPSET | 'COACTUP ' | BMS Mapset name |

| LIT-THISMAP | 'CACTUPA' | BMS Map name |

| LIT-MENUPGM | 'COMEN01C' | Program ID of the Main Menu |

| LIT-MENUTRANID | 'CM00' | CICS Transaction ID of the Main Menu |

| LIT-ACCTFILENAME | 'ACCTDAT ' | Account Master VSAM KSDS dataset name |

| LIT-CUSTFILENAME | 'CUSTDAT ' | Customer Master VSAM KSDS dataset name |

| LIT-CARDXREFNAME-ACCT-PATH | 'CXACAIX ' | Card Cross-Reference Alternate Index Path |

| DFHBMFSE | CICS Constant | Attribute byte: Unprotected, Normal Intensity, MDT On |

| DFHBMPRF | CICS Constant | Attribute byte: Protected, Normal Intensity |

| DFHRED | CICS Constant | Color attribute: Red |

| DFHGREEN | CICS Constant | Color attribute: Green |

| DFHBMASB | CICS Constant | Attribute byte: Bright Intensity |

| DFHBMDAR | CICS Constant | Attribute byte: Dark/Invisible |

Validation Logic

Input Field Validations

Account ID ( ACCTSIDI )

• Mandatory : Must be supplied. Cannot be spaces, low-values, or asterisks ( * ).

• Format : Must be strictly numeric and exactly 11 digits.

• Value : Must be a non-zero positive number.

Account Status ( ACSTTUSI )

• Mandatory : Must be supplied.

• Value : Must be exactly 'Y' (Active) or 'N' (Inactive).

Financial Amounts (Credit Limit, Cash Limit, Current Balance, Cycle Credit, Cycle Debit)

• Mandatory : Must be supplied.

• Format : Must be a valid signed numeric format. Checked using FUNCTION TEST-NUMVAL-C .

• Conversion : Converted to numeric using FUNCTION NUMVAL-C before database storage.

Dates (Open Date, Expiry Date, Reissue Date, Date of Birth)

• Mandatory : Year, Month, and Day components must be supplied.

• Year Validation :

• Must be a 4-digit numeric value.

• Century must be 19 or 20 .

• Month Validation : Must be numeric and between 1 and 12 .

• Day Validation :

• Must be numeric and between 1 and 31 .

• Cannot be 31 for 30-day months (April, June, September, November).

• Cannot be 30 or 31 for February.

• Leap Year Check: For February 29th, the year must be divisible by 4 (or 400 for century years).

• Logical Checks :

• Date of Birth : Must be in the past. Verified by comparing the Lilian date of birth against the current system date.

• System Validation : All dates are passed to the utility program CSUTLDTC for final calendar validation.

Social Security Number ( ACTSSN1I , ACTSSN2I , ACTSSN3I )

• Mandatory : All three parts must be supplied.

• Format : Must be numeric (Part 1: 3 digits, Part 2: 2 digits, Part 3: 4 digits).

• Part 1 Restrictions : Cannot be 000 , 666 , or in the range 900 through 999 .

FICO Score ( ACSTFCOI )

• Mandatory : Must be supplied.

• Format : Must be a 3-digit numeric value.

• Range : Must be between 300 and 850 inclusive.

Customer Names (First Name, Last Name, Middle Name)

• Mandatory : First Name and Last Name are mandatory. Middle Name is optional.

• Format : Must contain only alphabetic characters ( A-Z , a-z ) and spaces.

Address Fields (Address Line 1, City, State, Zip Code, Country)

• Address Line 1 : Mandatory. Cannot be blank.

• City : Mandatory. Must contain only alphabetic characters and spaces.

• State : Mandatory. Must be a valid 2-character US State code (validated against a list of 56 valid codes, e.g., AL , NY , WY ).

• Zip Code : Mandatory. Must be a 5-digit numeric value.

• Country : Mandatory. Must be a 3-character alphabetic value (typically USA ).

Phone Numbers (Phone 1 and Phone 2)

• Optional : Phone numbers are not mandatory.

• Format : If any part of a phone number is entered, all parts (Area Code, Prefix, Line Number) must be supplied.

• Area Code : Must be a 3-digit numeric value. Must be a valid North American Numbering Plan (NANPA) general-purpose area code.

• Prefix : Must be a 3-digit numeric value greater than zero.

• Line Number : Must be a 4-digit numeric value greater than zero.

EFT Account ID ( ACSEFTCI )

• Mandatory : Must be supplied.

• Format : Must be a 10-digit numeric value. Cannot be zero.

Primary Card Holder Indicator ( ACSPFLGI )

• Mandatory : Must be supplied.

• Value : Must be exactly 'Y' or 'N' .

Screen-Level and Cross-Field Validations

State and Zip Code Combination

• The program performs a cross-field validation check by concatenating the 2-character State code with the first 2 digits of the Zip Code.

• This 4-character combination is validated against a predefined list of valid US State/Zip prefix combinations (e.g., NY10 , CA90 , FL32 ). If the combination is invalid, both fields are flagged in error.

Attention Identifier (AID) Key Validation

• Valid Keys : ENTER , PF3 (Exit), PF5 (Save - only when changes are validated), and PF12 (Cancel - only when details are fetched).

• Invalid Keys : Any other key press is intercepted, treated as an invalid key, and defaults to redisplaying the screen with an error message.

Data Elements Processed

Screen Map Fields ( CACTUPAI / CACTUPAO )

| Map Field Name | Type | Length | Description |

| :--- | :--- | :--- | :--- |

| ACCTSIDI / ACCTSIDO | Alphanumeric | 11 | Account ID (Search Key) |

| ACSTTUSI / ACSTTUSO | Alphanumeric | 1 | Account Active Status ( Y / N ) |

| OPNYEARI / OPNMONI / OPNDAYI | Alphanumeric | 4 / 2 / 2 | Account Open Date (CCYY-MM-DD) |

| ACRDLIMI / ACRDLIMO | Alphanumeric | 15 | Credit Limit (Formatted Currency) |

| EXPYEARI / EXPMONI / EXPDAYI | Alphanumeric | 4 / 2 / 2 | Account Expiration Date (CCYY-MM-DD) |

| ACSHLIMI / ACSHLIMO | Alphanumeric | 15 | Cash Credit Limit (Formatted Currency) |

| RISYEARI / RISMONI / RISDAYI | Alphanumeric | 4 / 2 / 2 | Account Reissue Date (CCYY-MM-DD) |

| ACURBALI / ACURBALO | Alphanumeric | 15 | Current Balance (Formatted Currency) |

| ACRCYCRI / ACRCYCRO | Alphanumeric | 15 | Current Cycle Credit Limit (Formatted Currency) |

| ACRCYDBI / ACRCYDBO | Alphanumeric | 15 | Current Cycle Debit Limit (Formatted Currency) |

| AADDGRPI / AADDGRPO | Alphanumeric | 10 | Account Group ID |

| ACSTNUMI / ACSTNUMO | Alphanumeric | 9 | Customer ID (Protected) |

| ACTSSN1I / ACTSSN2I / ACTSSN3I | Alphanumeric | 3 / 2 / 4 | Customer Social Security Number |

| DOBYEARI / DOBMONI / DOBDAYI | Alphanumeric | 4 / 2 / 2 | Customer Date of Birth (CCYY-MM-DD) |

| ACSTFCOI / ACSTFCOO | Alphanumeric | 3 | Customer FICO Credit Score |

| ACSFNAMI / ACSFNAMO | Alphanumeric | 25 | Customer First Name |

| ACSMNAMI / ACSMNAMO | Alphanumeric | 25 | Customer Middle Name |

| ACSLNAMI / ACSLNAMO | Alphanumeric | 25 | Customer Last Name |

| ACSADL1I / ACSADL1O | Alphanumeric | 50 | Customer Address Line 1 |

| ACSADL2I / ACSADL2O | Alphanumeric | 50 | Customer Address Line 2 |

| ACSCITYI / ACSCITYO | Alphanumeric | 50 | Customer City (Address Line 3) |

| ACSSTTEI / ACSSTTEO | Alphanumeric | 2 | Customer State Code |

| ACSZIPCI / ACSZIPCO | Alphanumeric | 5 | Customer Zip Code |

| ACSCTRYI / ACSCTRYO | Alphanumeric | 3 | Customer Country Code |

| ACSPH1AI / ACSPH1BI / ACSPH1CI | Alphanumeric | 3 / 3 / 4 | Customer Phone Number 1 |

| ACSPH2AI / ACSPH2BI / ACSPH2CI | Alphanumeric | 3 / 3 / 4 | Customer Phone Number 2 |

| ACSGOVTI / ACSGOVTO | Alphanumeric | 20 | Customer Government Issued ID |

| ACSEFTCI / ACSEFTCO | Alphanumeric | 10 | Customer EFT Account ID |

| ACSPFLGI / ACSPFLGO | Alphanumeric | 1 | Primary Card Holder Indicator ( Y / N ) |

| INFOMSGO | Alphanumeric | 45 | Informational Prompt Message |

| ERRMSGO | Alphanumeric | 78 | Error Message (Displayed in Red) |

Backend and Control Fields

| Field Name | Type | Length/Format | Description |

| :--- | :--- | :--- | :--- |

| CDEMO-ACCT-ID | Numeric | 9(11) | Account ID passed in CARDDEMO-COMMAREA |

| CDEMO-CUST-ID | Numeric | 9(09) | Customer ID passed in CARDDEMO-COMMAREA |

| ACCT-UPDATE-RECORD | Group | 300 bytes | Layout used to rewrite the Account Master file |

| CUST-UPDATE-RECORD | Group | 500 bytes | Layout used to rewrite the Customer Master file |

| ACUP-OLD-DETAILS | Group | Variable | Storage area for original values used in concurrency checks |

| ACUP-NEW-DETAILS | Group | Variable | Storage area for modified screen values during validation |

Exception and Error Handling

CICS Command Exception Handling

The program utilizes inline response checking ( RESP and RESP2 options) for all file control commands to handle exceptions gracefully without abending the CICS region.

EXEC CICS READ (Card Xref, Account Master, Customer Master)

• DFHRESP(NORMAL) : Execution continues normally.

• DFHRESP(NOTFND) :

• If the Account ID is not found in the Card Xref file, the program flags the field in error and displays: "Account: [ID] not found in Cross ref file."

• If the Account ID is not found in the Account Master, it displays: "Account: [ID] not found in Acct Master file."

• If the Customer ID is not found in the Customer Master, it displays: "CustId: [ID] not found in customer master."

• Other Responses : Any other database error (e.g., IOERR , DISABLED ) is formatted into a standard file error message containing the operation name, file name, RESP , and RESP2 codes, and displayed to the user.

EXEC CICS READ UPDATE (Locking for Rewrite)

• If the program cannot lock the Account record, it sets the error flag and displays: "Could not lock account record for update" .

• If it cannot lock the Customer record, it displays: "Could not lock customer record for update" .

• In both cases, the update transaction is aborted, and no data is written.

EXEC CICS REWRITE (Commit Phase)

• If the Account rewrite fails, the program aborts and displays: "Update of record failed" .

• If the Customer rewrite fails after a successful Account rewrite, the program executes an explicit rollback command:

EXEC CICS SYNCPOINT ROLLBACK END-EXEC

This ensures database consistency by reverting the Account update, preventing orphaned or mismatched records.

Concurrency Conflict (Optimistic Locking)

Before performing any database writes, the program compares the current state of the records on disk with the original values fetched at the start of the user's session ( 9700-CHECK-CHANGE-IN-REC ).

• Trigger : If any field in the Account Master or Customer Master record on disk does not match the original values stored in ACUP-OLD-DETAILS .

• Handling : The program aborts the update, rolls back any locks, and displays: "Record changed by some one else. Please review" . This prevents the current operator from accidentally overwriting changes made by another user in the interim.

Global Abend Handling

The program registers a global abend handler at entry:

EXEC CICS HANDLE ABEND LABEL(ABEND-ROUTINE) END-EXEC

• Trigger : Any unhandled CICS exception or program abend.

• Handling :

• The program intercepts the abend and transfers control to ABEND-ROUTINE .

• It populates ABEND-DATA with the program name ( COACTUPC ) and a default message: "UNEXPECTED ABEND OCCURRED."

• It sends this error screen to the terminal, cancels the active abend handler to prevent loops, and terminates the transaction with abend code '9999' .

Security and Authorization Checks

• No Explicit External Security : The program does not directly interface with external security managers such as IBM RACF, nor does it execute standard CICS Sign-on ( CESN / CESF ) commands.

• Application-Managed Session Context : Security is managed entirely at the application level via the shared communication area ( CARDDEMO-COMMAREA ). The program verifies that a valid user session exists by checking that CDEMO-USER-ID is populated and that the transaction context is preserved across pseudo-conversational boundaries.

Performance Considerations

Pseudo-Conversational Design

The program is strictly designed as a pseudo-conversational transaction. It does not remain active in memory or hold database locks while waiting for user terminal input.

• After sending a map to the screen, it releases all resources and terminates using:

EXEC CICS RETURN TRANSID('CAUP') COMMAREA(WS-COMMAREA) END-EXEC

• The entire state of the transaction (including original and modified record details) is saved in the COMMAREA and passed back to CICS, ensuring high concurrency and minimal memory footprint on the mainframe.

Optimistic Locking vs. Pessimistic Locking

• To maximize throughput and minimize lock contention on the VSAM datasets, the program does not hold locks on records while the user is editing them on the screen.

• Instead, it reads the records without locks, allows the user to make changes, and only acquires exclusive update locks ( READ UPDATE ) for a fraction of a second during the final commit phase. This pattern significantly reduces database deadlocks in high-volume environments.

Dynamic Program Calls

• The program dynamically calls the date validation utility CSUTLDTC using:

CALL 'CSUTLDTC' USING ...

• While dynamic calls introduce a minor CPU overhead compared to static linking, they allow the date validation logic to be centrally maintained and updated without requiring the recompilation of COACTUPC .

<h2

CardDemo Account View Inquiry Program

The CardDemo Account View Inquiry Program is a core business service designed to provide customer service representatives and authorized personnel with a comprehensive, read-only view of credit card accounts. By entering a specific account number, users can instantly access critical financial metrics and customer demographics. This program plays a vital role in daily operations, enabling staff to quickly resolve customer inquiries, verify account statuses, and review credit limits.

When interacting with the system, the user is presented with a clean, structured interface where they can input an 11-digit account number. The program immediately validates this input to ensure it is formatted correctly. Once verified, the screen dynamically populates with detailed account information, including active status, current balance, credit and cash limits, open and expiration dates, and recent cycle activity.

Behind the scenes, the program coordinates a multi-step data retrieval process across several core databases. It first accesses a cross-reference registry to link the account number to its associated customer ID and card number. Using these identifiers, it simultaneously queries the account master database for financial details and the customer master database to retrieve personal information, such as the cardholder's full name, address, masked Social Security Number, and FICO credit score.

This program is fully integrated into the CardDemo application's navigation flow. It is typically invoked from the main menu and allows users to seamlessly return to their previous context or the main menu by pressing a designated exit key. Throughout this process, the program securely preserves the user's session context, ensuring that security roles and transaction histories are maintained as they navigate between different modules.

To ensure high performance and a smooth user experience, the program features robust error handling and an optimized design. If an account is not found or if database errors occur, the system displays clear, color-coded feedback directly on the screen rather than interrupting the user session. Additionally, its efficient design releases system resources while waiting for user input, allowing the mainframe to support a high volume of concurrent customer service inquiries.

Business Case and User Interaction

Business Case Overview

The COACTVWC program is a core business logic and presentation component of the CardDemo application. Its primary business purpose is to provide customer service representatives, credit officers, and back-office administrators with a comprehensive, read-only view of a specific credit card account and its associated customer details.

By entering a single 11-digit Account ID, the program orchestrates the retrieval of data across three distinct physical data stores:

• Cross-Reference Store ( CXACAIX ) : Maps the Account ID to its associated Customer ID and Card Number.

• Account Master Store ( ACCTDAT ) : Retrieves financial metrics, credit limits, balances, and account lifecycle dates.

• Customer Master Store ( CUSTDAT ) : Retrieves personal demographic details, contact information, government identifiers, and credit scores.

This consolidated view enables rapid inquiry handling, credit assessment, and customer verification from a single interface.

User Interaction and Screen Flow

• Inquiry Initiation : The user navigates to the Account View screen (typically via Option 1 on the Main Menu, COMEN01C ).

• Initial Screen Presentation : The program displays the CACTVWA map. On initial entry, all data fields are blank, and the system prompts the user with the message: "Enter or update id of account to display" .

• Account Selection : The user types an 11-digit Account ID into the protected/unprotected input field and presses ENTER .

• Data Retrieval & Display :

• If the Account ID passes validation and exists in the database, the program populates the screen with the account's financial status and the customer's personal details. An informational message "Displaying details of given Account" is displayed.

• If validation fails or the account is not found, the input field is highlighted in red, the cursor is positioned at the input field, and a descriptive error message is displayed at the bottom of the screen.

• Subsequent Inquiries : The user can overwrite the Account ID field with a new account number and press ENTER to perform another search.

• Exit : The user presses PF3 to exit the screen and return to the calling program (usually the Main Menu).

Screen Layout (CACTVWA)

+-----------------------------------------------------------------------------+

| Tran: CAVW AWS Mainframe Modernization Date: MM/DD/YY |

| Prog: COACTVWC CardDemo Time: HH:MM:SS |

| |

| CUSTOMER ACCOUNT VIEW |

| |

| Account ID: [11-Digit Acct ID] Status: [ ] |

| |

| Open Date : [10-Chars] Exp Date : [10-Chars] Reissue Date: [10-Chars] |

| Credit Lim: [ Formatted ] Cash Limit: [ Formatted ] Group ID : [10-Ch] |

| Curr Bal : [ Formatted ] Cycle Cred: [ Formatted ] Cycle Deb : [ For] |

| --------------------------------------------------------------------------- |

| Customer ID: [9-Digits] SSN: [XXX-XX-XXXX] FICO: [3-D] DOB: [10-Chars] |

| First Name : [25-Chars ] Middle Name: [25-Chars ] |

| Last Name : [25-Chars ] Primary Ind: [ ] |

| Addr Line 1: [50-Chars ] |

| Addr Line 2: [50-Chars ] |

| City : [50-Chars ] |

| State : [ ] Zip: [5-Ch] Country : [3-D] |

| Phone 1 : [13-Chars ] Phone 2 : [13-Chars ] |

| Govt ID : [20-Chars ] EFT Acct : [10-Chars ] |

| |

| <INFOMSG: Informational messages appear here > |

| <ERRMSG: Error messages appear here in red > |

| |

| ENTER=Fetch Details F3=Exit |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+--------------------------------------------------+

| Main Menu Screen |

| (COMEN01C) |

+-----------------------+--------------------------+

|

| (Select Option 1 / XCTL)

v

+--------------------------------------------------+

| Account View Screen | <-----------------+

| (COACTVWC) | |

+-----------------------+--------------------------+ |

| |

+------------------+------------------+ |

| [PF3] (Exit) | [ENTER] (Fetch Details) | (Re-enter /

v v | New Search)

+-----------------------+ +------------------+ |

| Main Menu Screen | | Validate Input & | |

| (COMEN01C) | | Read VSAM Files | -----------------+

+-----------------------+ +------------------+

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| LIT-THISPGM | 'COACTVWC' | Program identifier |

| LIT-THISTRANID | 'CAVW' | CICS Transaction ID associated with this program |

| LIT-THISMAPSET | 'COACTVW ' | BMS Mapset name |

| LIT-THISMAP | 'CACTVWA' | BMS Map name |

| LIT-MENUPGM | 'COMEN01C' | Target program name for Main Menu |

| LIT-MENUTRANID | 'CM00' | Target transaction ID for Main Menu |

| LIT-ACCTFILENAME | 'ACCTDAT ' | Account Master VSAM dataset name |

| LIT-CUSTFILENAME | 'CUSTDAT ' | Customer Master VSAM dataset name |

| LIT-CARDXREFNAME-ACCT-PATH | 'CXACAIX ' | Card Cross-Reference Alternate Index Path |

Validation Logic

Input Field Validations

• Account ID ( ACCTSIDI ) :

• If the input is * or spaces, it is treated as low-values (blank).

• Presence Check : If the field is blank, the program flags an input error and sets the message "Account number not provided" .

• Numeric Check : The input must be strictly numeric. If it contains non-numeric characters or is equal to zero, the program flags an input error and sets the message "Account Filter must be a non-zero 11 digit number" .

Screen-Level Validations

• Attention Identifier (AID) Validation :

• ENTER : Triggers map receipt, input validation, and database read operations.

• PF3 : Triggers exit processing, transferring control back to the calling program (or Main Menu).

• Other Keys : Any other key (e.g., PF1, PF2, PF4, Clear) is mapped to ENTER behavior by default, but the program flags the key as invalid and re-processes the screen.

Condition Checks

• Program Context Check :

• Evaluates CDEMO-PGM-CONTEXT to determine if the transaction is a fresh entry ( CDEMO-PGM-ENTER ) or a conversational re-entry ( CDEMO-PGM-REENTER ).

• On fresh entry, it bypasses input processing and directly displays the initial empty screen.

• On re-entry, it processes the submitted map inputs.

Data Elements Processed

Screen Input/Output Fields

• ACCTSIDI / ACCTSIDO : 11-digit Account ID used as the primary search key.

• ACSTTUSO : 1-character Account Active Status.

• ADTOPENO : 10-character Account Open Date.

• AEXPDTO : 10-character Account Expiration Date.

• AREISDTO : 10-character Account Reissue Date.

• AADDGRPO : 10-character Account Group ID.

• ACSTNUMO : 9-digit Customer ID.

• ACSTSSNO : 12-character formatted Social Security Number ( XXX-XX-XXXX ).

• ACSTFCOO : 3-digit FICO Credit Score.

• ACSTDOBO : 10-character Customer Date of Birth.

• ACSFNAMO / ACSMNAMO / ACSLNAMO : Customer First, Middle, and Last Names.

• ACSADL1O / ACSADL2O / ACSCITYO : Customer Address Lines and City.

• ACSSTTEO / ACSZIPCO / ACSCTRYO : Customer State, Zip Code, and Country.

• ACSPHN1O / ACSPHN2O : Customer Primary and Secondary Phone Numbers.

• ACSGOVTO : 20-character Government Issued ID.

• ACSEFTCO : 10-character EFT Account ID.

• ACSPFLGO : 1-character Primary Card Holder Indicator.

Financial Amounts (Formatted Output)

• ACURBALO : Current Balance (formatted as +ZZZ,ZZZ,ZZZ.99 ).

• ACRDLIMO : Credit Limit (formatted as +ZZZ,ZZZ,ZZZ.99 ).

• ACSHLIMO : Cash Credit Limit (formatted as +ZZZ,ZZZ,ZZZ.99 ).

• ACRCYCRO : Current Cycle Credit (formatted as +ZZZ,ZZZ,ZZZ.99 ).

• ACRCYDBO : Current Cycle Debit (formatted as +ZZZ,ZZZ,ZZZ.99 ).

Exception and Error Handling

Error Messages Displayed

| Message Text | Color | Trigger Condition |

| :--- | :--- | :--- |

| Account number not provided | Red | User pressed ENTER with a blank Account ID field. |

| Account Filter must be a non-zero 11 digit number | Red | User entered non-numeric characters or zeroes in the Account ID field. |

| Account: [AcctID] not found in Cross ref file. Resp: [R] Reas: [R2] | Red | The Account ID does not exist in the CXACAIX cross-reference file. |

| Account: [AcctID] not found in Acct Master file. Resp: [R] Reas: [R2] | Red | The Account ID exists in cross-reference but is missing from ACCTDAT . |

| CustId: [CustID] not found in customer master. Resp: [R] REAS: [R2] | Red | The associated Customer ID is missing from CUSTDAT . |

| File Error: [OP] on [FILE] returned RESP [R], RESP2 [R2] | Red | Any unexpected VSAM/CICS error during file read operations. |

CICS HANDLE CONDITION and ABEND Logic

• EXEC CICS HANDLE ABEND :

• Establishes an exit label ABEND-ROUTINE . If an unhandled program abend occurs, control is transferred to this routine.

• The program populates ABEND-DATA with the program name ( COACTVWC ) and a default message "UNEXPECTED ABEND OCCURRED." , sends this plain text to the terminal, and terminates via EXEC CICS ABEND ABCODE('9999') .

• Inline Response Code Handling :

• The program avoids global HANDLE CONDITION statements for file operations. Instead, it utilizes the RESP and RESP2 options on all EXEC CICS READ commands.

• It explicitly evaluates WS-RESP-CD for DFHRESP(NORMAL) and DFHRESP(NOTFND) to handle missing records gracefully without crashing the transaction.

Security and Authorization Checks

• Preservation of Session Context :

• The program does not perform explicit external security manager (e.g., IBM RACF) checks or standard CICS Signon ( CESN / CESF ) integrations.

• Security and user tracking are managed at the application level via the CARDDEMO-COMMAREA . The program preserves the logged-in user's identity ( CDEMO-USER-ID ) and role ( CDEMO-USER-TYPE ) across program transfers.

• Transaction Security :

• When exiting to the Main Menu, the program explicitly sets the user type to standard user ( SET CDEMO-USRTYP-USER TO TRUE ) to prevent privilege escalation.

Performance Considerations

• Pseudo-Conversational Design :

• The program is designed to be pseudo-conversational. After sending the map ( EXEC CICS SEND MAP ), it issues an EXEC CICS RETURN specifying the transaction ID CAVW and passing the communication area. This releases CICS thread resources and memory while waiting for user input, maximizing concurrent user capacity.

• VSAM Alternate Index (AIX) Access :

• The program reads the Card Cross-Reference file ( CXACAIX ) using an alternate index path ( LIT-CARDXREFNAME-ACCT-PATH ) keyed by Account ID. This allows direct, single-record retrieval of the Customer ID and Card Number without performing resource-intensive sequential file browses ( STARTBR / READNEXT ).

• Direct Key Reads :

• All database retrievals ( ACCTDAT and CUSTDAT ) are performed via direct key reads ( READ with RIDFLD ), which is the most efficient access pattern for VSAM datasets.

<h2

CardDemo Administration Menu Program

The COADM01C program serves as the centralized administrative hub for the CardDemo credit card management application. Designed exclusively for users with administrator-level privileges, this program acts as a secure gateway to critical system configuration and security management functions. By providing a structured, menu-driven interface, it ensures that authorized personnel can efficiently oversee user access and maintain core application lookup tables.

Upon entering the administration portal, users are presented with a clean, professional menu screen displaying a list of available administrative tasks. These tasks are categorized into two primary functional areas: security administration and database maintenance. Security options allow administrators to list, add, update, and delete application users, while database maintenance options facilitate the listing and updating of transaction types. The screen also displays real-time system metadata, including the current date, time, and active transaction identifier, to maintain situational awareness.

User interaction is designed to be simple and intuitive. To execute a task, the administrator enters the corresponding option number and presses the enter key. The program immediately validates the input to ensure it is a valid, active option. If the validation succeeds, the program transfers control to the appropriate sub-program to perform the requested action, passing along the user's session context. If the input is invalid or represents an uninstalled feature, the program displays a clear, contextual error message at the bottom of the screen and prompts the user for a correct entry.

To optimize mainframe resource utilization, the program is built using a pseudo-conversational design. It does not remain active in system memory while waiting for user input, thereby maximizing concurrent user capacity and minimizing processing overhead. Session state, user authorization levels, and transaction history are securely maintained across program transitions using a shared communication area. Additionally, administrators can safely exit the menu and return to the main sign-on screen at any time by pressing a designated function key, ensuring a secure and controlled session termination.

Business Case and User Interaction

Business Case Overview

The COADM01C program serves as the centralized Administration Menu for the CardDemo application. It acts as a secure, role-based control panel that allows administrative users to navigate to various system management and security functions. The program dynamically builds and displays a menu of administrative options, validates user selections, and transfers control to the appropriate sub-programs.

The administrative functions accessible through this menu include:

• User List (Security) : Displays a list of application users.

• User Add (Security) : Allows creation of new application users.

• User Update (Security) : Allows modification of existing user profiles.

• User Delete (Security) : Allows removal of users from the system.

• Transaction Type List/Update (Db2) : Manages transaction type configurations stored in Db2.

• Transaction Type Maintenance (Db2) : Performs detailed maintenance on transaction types.

User Interaction and Screen Flow

• Entry : The user is routed to this screen automatically after successful authentication as an Administrator (User Type 'A') in the Sign-on program ( COSGN00C ), or by returning from one of the sub-programs.

• Screen Display : The program displays the COADM1A map, showing the system header (Transaction ID, Program Name, Current Date, and Time) and the list of 6 active administrative options.

• Option Selection : The user types a 1- or 2-digit option number into the selection field and presses ENTER .

• Execution :

• If the selection is valid, the program transfers control (via XCTL ) to the corresponding program.

• If the selection is invalid, an error message is displayed at the bottom of the screen, and the menu is redisplayed.

• Exit : The user can press PF3 at any time to exit the Admin Menu and return to the Sign-on screen.

Screen Layout and Navigation

Screen Layout (COADM1A)

+-----------------------------------------------------------------------------+

| Tran: CA00 AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: COADM01C CardDemo Time: hh:mm:ss |

| |

| Admin Menu |

| |

| 1. User List (Security) |

| 2. User Add (Security) |

| 3. User Update (Security) |

| 4. User Delete (Security) |

| 5. Transaction Type List/Update (Db2) |

| 6. Transaction Type Maintenance (Db2) |

| |

| |

| |

| Please select an option : [ ] |

| |

| <ERRMSG: Error messages appear here in red/green > |

| |

| ENTER=Continue F3=Exit |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+--------------------------------------------------+

| CICS Terminal |

+------------------------+-------------------------+

|

| (Transaction CA00 / EIBCALEN > 0)

v

+--------------------------+

| COADM01C | <------------------+

| (Admin Menu Pgm) | |

+------------+-------------+ |

| |

| (Presents COADM1A Map) |

v |

+--------------------------+ |

| COADM1A Map | |

+------------+-------------+ |

| |

+---[PF3]-------------+---[ENTER] |

| | |

v v |

+------------------+ [Validate Option] |

| COSGN00C | | |

| (Sign-on Screen) | +---(If Invalid Option)--+

+------------------+ |

| (If Valid Option)

v

[XCTL to Target Program]

- Option 1: COUSR00C

- Option 2: COUSR01C

- Option 3: COUSR02C

- Option 4: COUSR03C

- Option 5: COTRTLIC

- Option 6: COTRTUPC

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| WS-PGMNAME | 'COADM01C' | Program identifier |

| WS-TRANID | 'CA00' | CICS Transaction ID associated with this program |

| CDEMO-ADMIN-OPT-COUNT | 6 | Total number of active menu options |

| CCDA-TITLE01 | ' AWS Mainframe Modernization ' | Screen Header Title Line 1 |

| CCDA-TITLE02 | ' CardDemo ' | Screen Header Title Line 2 |

| CCDA-MSG-INVALID-KEY | 'Invalid key pressed. Please see below... ' | Error message for unsupported AID keys |

Validation Logic

Input Field Validations

• Option Selection Validation :

• The program trims trailing spaces from the input field OPTIONI .

• Any remaining spaces are replaced with '0' to normalize the input (e.g., ' 1' or '1 ' becomes '01' ).

• The normalized value is moved to a numeric field ( WS-OPTION ).

• Numeric Check : The entered option must be numeric.

• Range Check : The option must be greater than 0 and less than or equal to CDEMO-ADMIN-OPT-COUNT (6).

• If any of these checks fail, WS-ERR-FLG is set to 'Y' , the error message "Please enter a valid option number..." is displayed in red, and the screen is redisplayed.

Screen-Level Validations

• Attention Identifier (AID) Validation :

• ENTER : Initiates option validation and program transfer.

• PF3 : Triggers exit processing, redirecting the user back to the Sign-on screen ( COSGN00C ).

• Other Keys : Any other key (e.g., PF1, PF2, PF4, Clear) is rejected. The program sets WS-ERR-FLG to 'Y' , displays "Invalid key pressed. Please see below..." , and redisplays the menu.

Condition Checks

• Commarea Length Check : If EIBCALEN is 0 (indicating the program was invoked directly without a communication area), the program bypasses the menu, sets the target program to 'COSGN00C' , and redirects to the Sign-on screen.

• Re-entry Check : The program uses CDEMO-PGM-REENTER to determine if this is the initial display of the menu (sends a fresh map with low-values) or a postback from a user interaction (receives and processes the input).

• Dummy Program Check : Before executing an XCTL , the program verifies that the target program name associated with the selected option does not start with 'DUMMY' .

Data Elements Processed

Screen and Input Fields

• OPTIONI / OPTIONO : User-entered menu option (2 characters).

• ERRMSGO / ERRMSGC : Error message text and attribute color control field.

• OPTN001O to OPTN012O : Output fields on the map used to display the formatted menu options.

Backend and Control Fields

• CARDDEMO-COMMAREA : Shared communication area passed between programs.

• CDEMO-FROM-TRANID : Set to 'CA00' before transferring control to track the originating transaction.

• CDEMO-FROM-PROGRAM : Set to 'COADM01C' before transferring control to track the originating program.

• CDEMO-TO-PROGRAM : Set to 'COSGN00C' during exit processing to specify the target redirection program.

• CDEMO-PGM-CONTEXT : Reset to 0 (Enter context) before transferring control to signal a fresh entry into the target program.

• CDEMO-ADMIN-OPT-PGMNAME(WS-OPTION) : Resolves the target program name based on the validated user selection.

Exception and Error Handling

CICS HANDLE CONDITION

• PGMIDERR : The program registers a global handle condition for PGMIDERR pointing to PGMIDERR-ERR-PARA . If an XCTL command fails because the target program is not defined or installed in the CICS region, the program catches the exception, sets the message "This option is not installed ..." in green, redisplays the menu, and returns control to CICS.

Error Messages

• "Please enter a valid option number..." : Displayed in red when the user enters a non-numeric value, a value of 0 , or a value greater than 6 .

• "Invalid key pressed. Please see below..." : Displayed in red when the user presses an unsupported AID key.

• "This option is not installed ..." : Displayed in green if a PGMIDERR occurs during transfer, or if the selected option's program name starts with 'DUMMY' .

Security and Authorization Checks

• Role-Based Access : The program relies on the upstream authentication process ( COSGN00C ) to verify that the user is an Administrator ( CDEMO-USRTYP-ADMIN is 'A' ).

• Direct Access Prevention : If a user attempts to bypass the sign-on screen and execute the transaction CA00 directly, EIBCALEN will be 0 . The program detects this, blocks access, and immediately redirects the user to the Sign-on screen ( COSGN00C ).

• No Explicit Platform Security : No explicit external security manager (such as RACF) checks or standard CICS Signon ( CESN / CESF ) integrations are implemented within this program.

Performance Considerations

• Pseudo-Conversational Design : The program is designed to be pseudo-conversational. It does not remain active in memory while waiting for user input. Instead, it sends the map and issues an EXEC CICS RETURN specifying the transaction ID CA00 and passing the CARDDEMO-COMMAREA . This minimizes CICS resource consumption.

• No Database or File I/O : This program does not perform any VSAM or Db2 database operations, making it highly efficient and fast to execute. Target program names are resolved entirely from static tables defined in Working-Storage.

<h2

Online Bill Payment Processing System for CardDemo

The COBIL00C program serves as the online bill payment module within the CardDemo application, designed to facilitate the full payment of outstanding credit card account balances. Its primary business purpose is to provide a secure, interactive interface where users can retrieve an account's current balance, verify the details, and process a payment to bring the outstanding balance down to zero. This program ensures financial consistency by coordinating real-time updates across account records and transaction logs.

When a user accesses the bill payment screen, they are prompted to enter a valid account ID. The program retrieves the account's current balance from the database and displays it on the screen. To prevent accidental or unauthorized payments, the system enforces a two-step confirmation workflow. The user must explicitly confirm the payment by entering a confirmation response. If the user confirms the payment, the system proceeds with the financial processing; if they decline or cancel, the transaction is aborted, and the screen is safely cleared.

Upon receiving user confirmation, the program performs a series of coordinated database updates to finalize the payment. It first performs a cross-reference lookup to identify the credit card number associated with the account. It then queries the transaction registry to determine the next sequential transaction identifier. Using this identifier, the system generates and writes a new transaction record detailing the online bill payment, including the payment amount, timestamp, and standard merchant information. Simultaneously, the program updates the account record by subtracting the payment amount—effectively resetting the outstanding balance to zero—and saves the updated account details.

The program is designed with robust validation and error-handling mechanisms to ensure data integrity. It verifies that the entered account exists, checks that there is an active balance to be paid, and validates all user inputs. If any step fails—such as a missing account or an invalid confirmation code—the program displays clear, contextual error messages to guide the user. Upon a successful payment, a green confirmation message is displayed on the screen, presenting the user with the newly generated transaction receipt number. Users can also easily clear their inputs or navigate back to the main menu using standard function keys.

Business Case and User Interaction

Business Case Overview

The COBIL00C program implements the Online Bill Payment functionality for the CardDemo Credit Card Processing Application. Its primary business purpose is to allow cardholders or operators to pay off an account's outstanding balance in full.

When executed, the program performs the following core business functions:

• Balance Retrieval : Looks up the specified Account ID in the account database ( ACCTDAT ) and displays the current outstanding balance.

• Payment Confirmation : Prompts the user to confirm the payment transaction.

• Transaction Generation : Upon confirmation, it automatically generates a unique transaction ID, creates a new financial transaction record in the transaction log ( TRANSACT ), and sets the transaction amount to the full outstanding balance.

• Account Update : Deducts the payment amount from the account's current balance (bringing the balance to zero) and updates the account record in the database.

User Interaction and Screen Flow

• Entry : The user navigates to the Bill Payment screen, typically from the Main Menu ( COMEN01C ) or another sub-application. If an Account ID was already selected in a previous screen, it is automatically populated in the "Enter Acct ID" field, and the balance is retrieved immediately.

• Account Input : If the Account ID field is empty, the user types an 11-digit Account ID and presses ENTER .

• Balance Display & Confirmation Prompt : The program retrieves and displays the current balance. It then prompts the user with the message "Confirm to make a bill payment..." and positions the cursor on the confirmation field.

• Confirmation Input : The user types 'Y' (Yes) or 'N' (No) in the confirmation field and presses ENTER .

• If the user enters 'Y' , the payment is processed, the account balance is updated to zero, a success message is displayed in green with the new Transaction ID, and the input fields are cleared.

• If the user enters 'N' , the transaction is aborted, the screen is cleared, and the fields are reset.

• Exit/Clear :

• The user can press PF3 to return to the previous screen.

• The user can press PF4 to clear all input fields and reset the screen.

Screen Layout and Navigation

Screen Layout (COBIL0A)

+-----------------------------------------------------------------------------+

| Tran: CB00 AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: COBIL00C CardDemo Time: hh:mm:ss |

| |

| Bill Payment |

| |

| Enter Acct ID: [ ] |

| |

| ---------------------------------------------- ---------------|

| |

| Your current balance is: [ ] |

| |

| Do you want to pay your balance now. Please confirm: [ ] (Y/N) |

| |

| <ERRMSG: Error or success messages appear here > |

| |

| ENTER=Continue F3=Back F4=Clear |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+--------------------------------------------------+

| Main Menu / Calling Program |

| (e.g., COMEN01C or COTRN00C) |

+-----------------------+--------------------------+

|

| (Transfers Control via XCTL)

v

+--------------------------------------------------+

| Bill Payment Program | <-----------------+

| (COBIL00C) | |

+-----------------------+--------------------------+ |

| |

+------------------+------------------+ | (Re-entry /

| [PF3] | [ENTER] | Validation

v v | Failure)

+-----------------------+ +------------------+ |

| Previous Screen | | Validate Inputs | -----------------+

| (COMEN01C / CDEMO-F*) | | & Process VSAM |

+-----------------------+ +------------------+

Data Flow Description

• Incoming Data : The program receives the CARDDEMO-COMMAREA from the calling program. If CDEMO-CB00-TRN-SELECTED contains an Account ID, it is automatically moved to the screen input field ( ACTIDINI ) to initiate an immediate balance lookup.

• Outgoing Data : When returning to the previous screen via PF3 , the program updates the CARDDEMO-COMMAREA with its own transaction ID ( CB00 ) and program name ( COBIL00C ) in the tracking fields before executing XCTL .

User Navigation

• ENTER : Validates the Account ID, retrieves the balance, prompts for confirmation, and processes the payment.

• PF3 : Returns control to the program specified in CDEMO-FROM-PROGRAM (or defaults to COMEN01C if empty).

• PF4 : Clears all screen fields and resets the cursor to the Account ID field.

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| WS-PGMNAME | 'COBIL00C' | Program identifier |

| WS-TRANID | 'CB00' | CICS Transaction ID associated with this program |

| WS-TRANSACT-FILE | 'TRANSACT' | VSAM KSDS file containing transaction records |

| WS-ACCTDAT-FILE | 'ACCTDAT ' | VSAM KSDS file containing account master records |

| WS-CXACAIX-FILE | 'CXACAIX ' | VSAM Alternate Index path linking accounts to card numbers |

| CCDA-TITLE01 | ' AWS Mainframe Modernization ' | Screen Header Title Line 1 |

| CCDA-TITLE02 | ' CardDemo ' | Screen Header Title Line 2 |

| CCDA-MSG-INVALID-KEY | 'Invalid key pressed. Please see below... ' | Error message for unsupported AID keys |

Validation Logic

Input Field Validations

• Account ID ( ACTIDINI ) :

• Must not be spaces or low-values.

• If empty, the program sets WS-ERR-FLG to 'Y' , displays "Acct ID can NOT be empty..." , and positions the cursor on the Account ID field ( ACTIDINL = -1 ).

• Confirmation Flag ( CONFIRMI ) :

• Must be one of the following values: 'Y' , 'y' , 'N' , 'n' , spaces, or low-values.

• If any other character is entered, the program sets WS-ERR-FLG to 'Y' , displays "Invalid value. Valid values are (Y/N)..." , and positions the cursor on the confirmation field ( CONFIRML = -1 ).

Screen-Level Validations

• Attention Identifier (AID) Validation :

• ENTER : Triggers input validation, balance retrieval, and payment processing.

• PF3 : Triggers exit processing, transferring control back to the calling program.

• PF4 : Clears all input and output fields on the screen and positions the cursor on the Account ID field.

• Other Keys : Any other key is rejected. The program sets WS-ERR-FLG to 'Y' , displays "Invalid key pressed. Please see below..." , and redisplays the screen.

Condition Checks

• Zero or Negative Balance Check :

• If the retrieved account balance ( ACCT-CURR-BAL ) is less than or equal to zero, the program blocks the payment process, sets WS-ERR-FLG to 'Y' , displays "You have nothing to pay..." , and positions the cursor on the Account ID field.

• Confirmation Check :

• If CONFIRMI is 'N' or 'n' , the program aborts the payment, clears the screen, and sets the error flag.

• If CONFIRMI is spaces or low-values, the program retrieves the balance and prompts the user with "Confirm to make a bill payment..." without executing the transaction.

• If CONFIRMI is 'Y' or 'y' , the program proceeds to execute the payment transaction.

Data Elements Processed

Screen Fields

• ACTIDINI / ACTIDINO : Input/Output field for the 11-digit Account ID.

• CURBALI / CURBALO : Output field displaying the retrieved account balance formatted as currency.

• CONFIRMI / CONFIRMO : Input/Output field for the 1-character payment confirmation flag ( Y/N ).

• ERRMSGO : Output field for error, warning, and success messages.

• ERRMSGC : Attribute byte used to dynamically change the color of the error message (e.g., DFHGREEN for successful payments, default red for errors).

Backend and Control Fields

• ACCT-ID : Key field used to read and update the ACCTDAT file.

• ACCT-CURR-BAL : Stored account balance retrieved from the ACCOUNT-RECORD .

• XREF-ACCT-ID : Key field used to read the CXACAIX file to retrieve the associated card number.

• XREF-CARD-NUM : Card number retrieved from the cross-reference record, mapped to TRAN-CARD-NUM .

• TRAN-ID : Key field used to read and write records in the TRANSACT file.

• TRAN-AMT : Transaction amount, set to the full outstanding account balance ( ACCT-CURR-BAL ).

• WS-TIMESTAMP : Generated timestamp used to populate TRAN-ORIG-TS and TRAN-PROC-TS .

Exception and Error Handling

CICS File Exception Handling

The program utilizes explicit response checking ( RESP and RESP2 parameters) on all file operations to handle exceptions inline:

READ / REWRITE on ACCTDAT :

• DFHRESP(NORMAL) : Continues processing.

• DFHRESP(NOTFND) : Sets WS-ERR-FLG to 'Y' , displays "Account ID NOT found..." , and positions the cursor on the Account ID field.

• Other Errors : Displays the response and reason codes, sets WS-ERR-FLG to 'Y' , and displays "Unable to lookup Account..." or "Unable to Update Account..." .

READ on CXACAIX :

• DFHRESP(NORMAL) : Continues processing.

• DFHRESP(NOTFND) : Sets WS-ERR-FLG to 'Y' , displays "Account ID NOT found..." , and positions the cursor on the Account ID field.

• Other Errors : Displays the response and reason codes, sets WS-ERR-FLG to 'Y' , and displays "Unable to lookup XREF AIX file..." .

STARTBR / READPREV on TRANSACT :

• DFHRESP(NORMAL) : Continues processing.

• DFHRESP(NOTFND) : Sets WS-ERR-FLG to 'Y' , displays "Transaction ID NOT found..." , and positions the cursor on the Account ID field.

• DFHRESP(ENDFILE) : Gracefully handles an empty transaction file by initializing TRAN-ID to zeros.

• Other Errors : Displays the response and reason codes, sets WS-ERR-FLG to 'Y' , and displays "Unable to lookup Transaction..." .

WRITE on TRANSACT :

• DFHRESP(NORMAL) : Clears input fields, sets the message color to green, and displays "Payment successful. Your Transaction ID is [TRAN-ID]."

• DFHRESP(DUPKEY) / DFHRESP(DUPREC) : Sets WS-ERR-FLG to 'Y' , displays "Tran ID already exist..." , and positions the cursor on the Account ID field.

• Other Errors : Displays the response and reason codes, sets WS-ERR-FLG to 'Y' , and displays "Unable to Add Bill pay Transaction..." .

Security and Authorization Checks

• Session Validation : The program checks if EIBCALEN is equal to 0 . If true, it indicates that the program was accessed directly without a valid CICS communication area. The program immediately redirects the user to the Sign-on screen ( COSGN00C ).

• No Explicit Security Checks : No explicit external security manager (such as IBM RACF) checks, EXEC CICS ASSIGN USERID calls, or standard CICS Signon ( CESN / CESF ) integrations are implemented within this program. Security and session state are entirely application-managed via the CARDDEMO-COMMAREA .

Performance Considerations

• Pseudo-Conversational Design : The program is designed to be pseudo-conversational. It does not remain active in memory while waiting for user input. After sending the map, it issues an EXEC CICS RETURN specifying the transaction ID CB00 and passing the CARDDEMO-COMMAREA . This releases CICS resources and maximizes concurrent user capacity.

• Efficient Last Key Retrieval : To generate a unique, sequential Transaction ID, the program performs a STARTBR with HIGH-VALUES on the TRANSACT file, followed by a single READPREV to retrieve the highest existing key, and immediately issues an ENDBR . This is a highly efficient mainframe pattern that avoids scanning the entire VSAM KSDS file.

• Exclusive Lock on Read : The READ command on the ACCTDAT file is executed with the UPDATE option. This places an exclusive lock on the account record, preventing concurrent update anomalies (lost updates) until the subsequent REWRITE is executed.

<h2

COBSWAIT: A Batch Utility Program for Introducing Controlled Execution Delays

The COBSWAIT program is a utility component within the CardDemo batch processing framework. Its primary business purpose is to introduce a controlled, temporary pause in the execution flow of batch jobs. This is particularly useful in enterprise environments where sequential job steps or interdependent processes need to be synchronized, or when throttling is required to prevent resource contention and manage system workload effectively.

To determine the duration of the delay, the program reads an input parameter from the standard system input stream. This parameter specifies the desired wait time, allowing scheduling administrators or calling processes to dynamically define how long the execution should be suspended for each specific run without needing to modify the program's underlying logic.

The input value is processed and converted into a specific time format measured in centiseconds (hundredths of a second). This high-resolution timing capability allows for precise control over the delay, ranging from fractions of a second to longer durations. Once the time value is prepared, the program delegates the actual waiting operation to a specialized system-level service.

By calling the external system routine responsible for managing environment-level waits, COBSWAIT safely suspends the execution thread. During this pause, no active processing occurs, preserving valuable CPU cycles. Once the specified duration has elapsed, the system service returns control to the utility, which then cleanly terminates, allowing the subsequent steps in the batch job stream to resume.

Program Business Logic Description

COBSWAIT is a batch utility program designed to pause or suspend the execution of a batch job step for a specified duration. The program acts as a wrapper that interfaces with an external system-level wait routine.

The business and operational logic of the program is executed as follows:

• Read Input Parameter : The program reads an 8-character alphanumeric value from the standard input stream ( SYSIN ) into the variable PARM-VALUE . This value represents the desired wait time.

• Format Conversion : The alphanumeric input is moved to a computational binary numeric field ( MVSWAIT-TIME ). This implicit conversion prepares the duration value in the format required by the operating system's wait utility.

• Invoke Wait Routine : The program calls the external system utility MVSWAIT , passing the binary wait time as a parameter. The unit of time expected by MVSWAIT is centiseconds (1/100ths of a second).

• Terminate Execution : Once the external MVSWAIT routine completes the pause and returns control, the program terminates execution using STOP RUN .

Important Constants

• Centisecond Unit (Implicit) : While not explicitly defined as a named constant in the WORKING-STORAGE SECTION , the program logic implicitly operates on the constant time unit of centiseconds (1/100th of a second) for the input parameter.

Validation Logic

The program does not contain any explicit validation logic or data integrity checks:

• No Input Validation : The program does not verify if the data read from SYSIN is present, non-empty, or numeric before attempting to move it to the numeric field.

• No Range Validation : There are no checks to ensure the wait time is within reasonable or safe operational limits (e.g., preventing excessively long sleep times that could hang a batch queue).

Data Elements Processed

• PARM-VALUE (PIC X(8)) : An alphanumeric field that receives the raw wait duration parameter from the SYSIN input stream.

• MVSWAIT-TIME (PIC 9(8) COMP) : A computational (binary) numeric field that stores the converted wait duration in centiseconds. This field is passed as the parameter to the MVSWAIT system call.

Exception and Error Handling

The program lacks explicit exception handling or recovery routines. Consequently, it is susceptible to the following abnormal terminations (ABENDs):

• Data Exception (S0C7 ABEND) : If the input read from SYSIN contains non-numeric characters, the implicit conversion during the MOVE PARM-VALUE TO MVSWAIT-TIME statement will result in a decimal data exception.

• Program Call Failure (S806 ABEND) : If the external utility MVSWAIT is not accessible in the system's link list or the job's load library concatenation ( STEPLIB / JOBLIB ), the program will fail when attempting the CALL statement.

Security and Authorization Checks

No explicit security checks identified.

Performance Considerations

• Initiator and Resource Holding : While the program is in a wait state, it does not consume significant CPU cycles (as the MVSWAIT routine yields CPU control to the operating system). However, the batch job step remains active, holding its assigned batch initiator and any allocated system resources (such as datasets or database locks) for the duration of the wait. This can impact overall batch window throughput if long wait times are specified.

<h2

Transaction Type Database Maintenance Utility

The Transaction Type Database Maintenance utility is a batch processing program designed to manage and synchronize transaction type definitions within a core financial database. By processing a sequential input file containing requested changes, the program ensures that the system's transaction classification records remain accurate and up to date. This automated maintenance is critical for downstream transaction processing, reporting, and auditing functions.

The program operates by reading an input file sequentially, where each record represents a specific maintenance request. Each input record contains an action indicator, a unique transaction type identifier, and an associated transaction description. The utility processes these records one by one, translating the input data into corresponding database operations against the central transaction type registry.

Depending on the action indicator provided in the input file, the utility performs one of three primary database operations. It can insert new transaction types into the database, update the descriptions of existing transaction types, or delete obsolete transaction types. Additionally, the program supports comment lines within the input file, allowing administrators to document the input file without affecting the database.

To ensure data integrity, the utility incorporates robust validation and error-handling procedures. If an input record contains an invalid action code, or if a database operation fails—such as attempting to update or delete a non-existent transaction type—the program logs a descriptive error message and terminates processing with a warning status. This immediate feedback mechanism alerts system administrators to data discrepancies or database connectivity issues that require manual intervention.

Business Logic Description

The COBTUPDT program is a batch utility designed to process transaction type updates from a sequential input file and apply those changes to a DB2 database table named CARDDEMO.TRANSACTION_TYPE .

The program executes the following sequential business flow:

• Initialization and File Opening :

The program opens the sequential input file TR-RECORD (associated with the JCL DD name INPFILE ). It verifies the file status immediately after opening.

• Sequential Processing Loop :

The program performs a priming read to fetch the first record. It then enters a loop that continues until the End-of-File (EOF) marker is reached ( LASTREC = 'Y' ). For each valid record read, the program:

• Displays the record content being processed.

• Evaluates the action indicator (record type) to determine the database operation.

• Executes the corresponding SQL statement (Insert, Update, or Delete) or ignores the record if marked as a comment.

• Performs a subsequent read to fetch the next record.

• Database Operations :

• Insert ('A') : Inserts a new transaction type code and its description into the CARDDEMO.TRANSACTION_TYPE table.

• Update ('U') : Updates the description of an existing transaction type code in the database.

• Delete ('D') : Deletes the row matching the transaction type code from the database.

• Comment ('*') : Bypasses database processing for the current record.

• Termination :

Once all records are processed, the program closes the input file and terminates execution.

Important Constants

• Action Codes ( INPUT-REC-TYPE ) :

• 'A' : Add/Insert record.

• 'U' : Update record.

• 'D' : Delete record.

• '*' : Comment line (ignored).

• File Status Codes :

• '00' : Successful file open.

• SQL Codes ( SQLCODE ) :

• 0 (ZERO): Successful SQL execution.

• +100 : Row not found (applicable to Update and Delete operations).

• Return Codes :

• 4 : Assigned to the RETURN-CODE special register to indicate a processing error or warning.

Validation Logic

• File Open Verification : After opening TR-RECORD , the program checks if WS-INF-STATUS is equal to '00' . If it is not, it displays 'OPEN FILE NOT OK' , but does not halt execution.

• Action Code Validation : The program evaluates the INPUT-REC-TYPE field of each record. If the value is not 'A' , 'U' , 'D' , or '*' , it is treated as invalid. The program constructs an error message ( 'ERROR: TYPE NOT VALID' ) and triggers the error handling routine.

• Database Existence Verification :

• For Update ( 'U' ) and Delete ( 'D' ) operations, the program validates that the target record exists in the database by checking if SQLCODE is +100 (Not Found). If the record does not exist, it treats this as a validation failure, formats a 'No records found.' message, and triggers the error handling routine.

Data Elements Processed

• INPUT-REC-TYPE (PIC X(1)): The action indicator read from the input file that dictates whether to insert, update, delete, or ignore the record.

• INPUT-REC-NUMBER (PIC X(2)): The transaction type identifier read from the input file. This maps directly to the host variable used in the SQL WHERE clause ( TR_TYPE ) for updates and deletes, and the insert value list.

• INPUT-REC-DESC (PIC X(50)): The transaction description read from the input file. This maps to the host variable used to populate or update the TR_DESCRIPTION column in the database.

• SQLCODE / WS-VAR-SQLCODE (PIC ----9): The DB2 return code used to evaluate the success, warning, or failure status of each SQL execution.

• WS-RETURN-MSG (PIC X(80)): A working storage variable used to format error messages before they are written to the system output.

• RETURN-CODE : A COBOL special register updated to 4 when database or validation errors occur.

Exception and Error Handling

• Invalid Action Code Handling : If an invalid action code is encountered, the program moves 'ERROR: TYPE NOT VALID' to WS-RETURN-MSG and performs 9999-ABEND .

• SQL Error Handling (Negative SQLCODE) : If any database operation results in a negative SQLCODE (indicating a database error), the program formats an error message containing the specific SQL code (e.g., 'Error accessing: TRANSACTION_TYPE table. SQLCODE: -xxx' ), moves it to WS-RETURN-MSG , and performs 9999-ABEND .

• Record Not Found Handling (+100) : For Update and Delete operations, if the target row does not exist ( SQLCODE = +100 ), the program formats 'No records found.' into WS-RETURN-MSG and performs 9999-ABEND .

• ABEND Routine ( 9999-ABEND ) : This paragraph displays the formatted error message stored in WS-RETURN-MSG and sets the COBOL RETURN-CODE special register to 4 .

• Non-Fatal Error Flow : It is important to note that the 9999-ABEND routine does not issue a STOP RUN or abnormal termination command. After setting RETURN-CODE to 4 , control returns to the main processing loop, allowing the program to continue reading and processing subsequent records in the input file. The final job step return code will reflect 4 if any error occurred during the run.

Security and Authorization Checks

No explicit security checks identified. The program relies on the mainframe environment's dataset security (e.g., RACF) for file access and the DB2 subsystem's authorization mechanism for table access privileges (INSERT, UPDATE, DELETE on CARDDEMO.TRANSACTION_TYPE ).

Performance Considerations

• Row-by-Row Processing : The program processes database updates sequentially, one record at a time. It does not utilize bulk insert/update techniques or cursor-based batching.

• Commit Frequency : There are no explicit COMMIT or ROLLBACK statements within the program. Transaction management (commit scope) is deferred to the external execution environment (e.g., TSO batch runner IKJEFT01 or the calling JCL step configuration).

• Database Indexing : The UPDATE and DELETE statements filter on TR_TYPE = :INPUT-REC-NUMBER . For optimal performance, the TR_TYPE column should be defined as the primary key or have a unique index on the CARDDEMO.TRANSACTION_TYPE table to avoid full table scans.

<h2

Credit Card Search and List Utility for CardDemo

The COCRDLIC program serves as the primary search and directory interface for credit cards within the CardDemo application. Its main business purpose is to provide customer service representatives, operators, and administrators with a flexible, paginated list of credit cards registered in the system. Depending on the user's security role and the initial navigation context, the program can display all credit cards in the database or restrict the list to cards associated with a specific account.

Users interact with the program through an interactive search screen where they can filter results by entering an Account ID, a Card Number, or both. The retrieved records are presented in a structured, seven-row grid displaying essential card attributes, including the associated account number, the card number, and its current active status. This high-level overview allows operators to quickly scan and locate specific card records from a large database.

Beyond simple browsing, the list screen acts as a functional launchpad for deeper card management tasks. By entering action codes next to any listed card, users can initiate downstream workflows: selecting 'S' routes them to the Credit Card Detail Inquiry program to view comprehensive cardholder details, while selecting 'U' transfers control to the Credit Card Update program to modify card attributes. The program automatically carries over the selected card and account context, ensuring a seamless transition without requiring the user to re-type search keys.

To handle large volumes of credit card records efficiently, the program features robust pagination controls, allowing users to scroll forward and backward through search results using standard function keys. It also enforces strict input validation on search filters, ensuring that any entered criteria are strictly numeric and of the correct length. If validation fails, the program dynamically highlights the erroneous fields in red and displays descriptive error messages to guide the user.

Under the hood, the program is built using a high-performance, pseudo-conversational design that optimizes mainframe resource utilization by releasing active system threads while waiting for user input. It maintains session state, user authorization levels, and navigation history across screen transitions using a shared communication area. This architecture ensures a secure, responsive, and consistent user experience even under heavy concurrent workloads.

Business Case and User Interaction

Business Case Overview

The COCRDLIC program is the "Credit Card List" component of the CardDemo mainframe application. Its primary business purpose is to display a paginated list of credit cards stored in the system, allowing operators to browse records, apply search filters (by Account ID and/or Card Number), and select specific cards for detailed inquiry or modification.

This program acts as an intermediary navigation directory, supporting the following operational workflows:

• Card Browsing : Displays up to 7 credit card records per screen, showing the Account Number, Card Number, and Active Status.

• Filtered Search : Allows users to narrow down the list by entering a specific 11-digit Account ID or a 16-digit Card Number.

• Action Dispatching :

• View Detail ('S') : Transfers control to the Credit Card Detail Inquiry program ( COCRDSLC ) to view comprehensive cardholder information.

• Update ('U') : Transfers control to the Credit Card Detail Update program ( COCRDUPC ) to modify card attributes.

Screen Layout and Navigation

Screen Layout (CCRDLIA)

The screen displays system metadata in the header, search filter inputs, a 7-row tabular grid for card records, and navigation/action instructions at the bottom.

+-----------------------------------------------------------------------------+

| Tran: CCLI AWS Mainframe Modernization Date: MM/DD/YY |

| Prog: COCRDLIC CardDemo Time: HH:MM:SS |

| |

| Credit Card List Screen Page: 01 |

| |

| Account Id: [ ] |

| Card Number: [ ] |

| |

| Sel Account ID Card Number Status |

| --- ------------ ------------------ ------ |

| [ ] [12345678901] [4321098765432109] [Y] |

| [ ] [12345678901] [4321098765432110] [N] |

| [ ] [12345678902] [4321098765432111] [Y] |

| [ ] [ ] [ ] [ ] |

| [ ] [ ] [ ] [ ] |

| [ ] [ ] [ ] [ ] |

| [ ] [ ] [ ] [ ] |

| |

| <INFOMSGI: TYPE S FOR DETAIL, U TO UPDATE ANY RECORD > |

| <ERRMSGI: Error messages appear here in red > |

| |

| ENTER=Fetch/Select F3=Exit F7=PageUp F8=PageDown |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+--------------------------------------------------+

| Main Menu (COMEN01C) |

+------------------------+-------------------------+

|

| (Select Option 3)

v

+-----------------------------------------------------------------------------+

| Credit Card List (COCRDLIC) |

| |

| 1. Displays paginated list of cards (7 rows max) |

| 2. Accepts filters: Account ID and Card Number |

| 3. Accepts row actions: 'S' (View Detail), 'U' (Update) |

+-----------------------------------------------------------------------------+

| | |

| [PF3] | Action='S' | Action='U'

v v v

+------------------+ +------------------+ +------------------+

| Main Menu | | Card Detail | | Card Update |

| (COMEN01C) | | (COCRDSLC) | | (COCRDUPC) |

+------------------+ +------------------+ +------------------+

Screen Flow and User Navigation

• Entry : The user enters transaction CCLI or selects Option 3 from the Main Menu ( COMEN01C ).

• Filtering : The user can enter search criteria in the Account Id or Card Number fields and press ENTER to filter the list.

• Pagination :

• PF8 (Page Down) : Displays the next 7 records starting from the last card key of the current page.

• PF7 (Page Up) : Displays the previous 7 records using a backward file browse.

• Row Selection :

• To view details, the user types S in the Sel column of a row and presses ENTER . The program transfers control to COCRDSLC via EXEC CICS XCTL .

• To update details, the user types U in the Sel column of a row and presses ENTER . The program transfers control to COCRDUPC via EXEC CICS XCTL .

• Exit : The user presses PF3 to return to the Main Menu ( COMEN01C ).

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| LIT-THISPGM | 'COCRDLIC' | Program identifier |

| LIT-THISTRANID | 'CCLI' | CICS Transaction ID for this program |

| LIT-THISMAPSET | 'COCRDLI' | BMS Mapset name |

| LIT-THISMAP | 'CCRDLIA' | BMS Map name |

| LIT-MENUPGM | 'COMEN01C' | Program ID of the Main Menu program |

| LIT-CARDDTLPGM | 'COCRDSLC' | Program ID of the Card Detail program |

| LIT-CARDUPDPGM | 'COCRDUPC' | Program ID of the Card Update program |

| LIT-CARD-FILE | 'CARDDAT ' | Primary VSAM KSDS Card Data File |

| LIT-CARD-FILE-ACCT-PATH | 'CARDAIX ' | Alternate Index Path for Card Data File (by Account ID) |

| WS-MAX-SCREEN-LINES | 7 | Maximum number of records displayed per page |

Validation Logic

The program performs input validation during pseudo-conversational re-entry.

Input Field Validations

• Account ID Filter ( 2210-EDIT-ACCOUNT ) :

• If supplied, the value must be strictly numeric.

• If non-numeric, the program flags INPUT-ERROR , sets FLG-ACCTFILTER-NOT-OK , protects the selection rows, and displays: "ACCOUNT FILTER,IF SUPPLIED MUST BE A 11 DIGIT NUMBER" .

• Card Number Filter ( 2220-EDIT-CARD ) :

• If supplied, the value must be strictly numeric.

• If non-numeric, the program flags INPUT-ERROR , sets FLG-CARDFILTER-NOT-OK , protects the selection rows, and displays: "CARD ID FILTER,IF SUPPLIED MUST BE A 16 DIGIT NUMBER" .

Row Selection Validations ( 2250-EDIT-ARRAY )

• Action Code Validation :

• The selection character in the Sel column must be 'S' (View), 'U' (Update), or blank/low-values.

• Any other character flags an error, highlights the selection field in red, and displays: "INVALID ACTION CODE" .

• Single Selection Enforcement :

• The user is only allowed to select one record at a time for viewing or updating.

• If multiple rows have selection characters ( 'S' or 'U' ), the program flags an error, highlights the offending selection fields in red, and displays: "PLEASE SELECT ONLY ONE RECORD TO VIEW OR UPDATE" .

Screen-Level Validations

• Attention Identifier (AID) Validation :

• Valid keys are ENTER , PF3 (Exit), PF7 (Page Up), and PF8 (Page Down).

• If any other key is pressed, the program defaults the action to ENTER but flags the key as invalid.

• Pagination Bounds :

• Pressing PF7 on the first page displays the error: "NO PREVIOUS PAGES TO DISPLAY" .

• Pressing PF8 on the last page displays the error: "NO MORE PAGES TO DISPLAY" .

Data Elements Processed

Screen Fields

• ACCTSIDI / ACCTSIDO : Input/Output field for the 11-digit Account ID filter.

• CARDSIDI / CARDSIDO : Input/Output field for the 16-digit Card Number filter.

• CRDSEL1I to CRDSEL7I / CRDSEL1O to CRDSEL7O : Input/Output selection action fields for rows 1 to 7.

• ACCTNO1O to ACCTNO7O : Output fields for displayed Account Numbers.

• CRDNUM1O to CRDNUM7O : Output fields for displayed Card Numbers.

• CRDSTS1O to CRDSTS7O : Output fields for displayed Card Statuses.

• PAGENOO : Output field for the current page number.

• INFOMSGO : Output field for informational messages (green/neutral text).

• ERRMSGO : Output field for error messages (red text).

Backend and Control Fields

• CARDDEMO-COMMAREA : Shared communication area containing session metadata.

• CDEMO-USER-ID : Logged-in user identifier.

• CDEMO-USER-TYPE : User role ( 'A' for Admin, 'U' for User).

• CDEMO-ACCT-ID : Passed Account ID.

• CDEMO-CARD-NUM : Passed Card Number.

• WS-THIS-PROGCOMMAREA : Program-specific state appended to the COMMAREA.

• WS-CA-FIRST-CARD-NUM / WS-CA-FIRST-CARD-ACCT-ID : Keys of the first record on the current page (used for backward paging).

• WS-CA-LAST-CARD-NUM / WS-CA-LAST-CARD-ACCT-ID : Keys of the last record on the current page (used for forward paging).

• WS-CA-SCREEN-NUM : Current page number.

• WS-CA-LAST-PAGE-DISPLAYED : Flag indicating if the last page has been reached.

• WS-CA-NEXT-PAGE-IND : Flag indicating if a next page exists.

• CARD-RECORD : VSAM record structure mapped from CARDDAT .

• CARD-NUM : Primary key (16-digit card number).

• CARD-ACCT-ID : Associated 11-digit account ID.

• CARD-ACTIVE-STATUS : Status flag ( 'Y' / 'N' ).

Exception and Error Handling

CICS Command Exception Handling

• EXEC CICS STARTBR / READNEXT / READPREV (File: CARDDAT ) :

• NORMAL / DUPREC : Record successfully processed.

• ENDFILE : Handled gracefully. Sets CA-NEXT-PAGE-NOT-EXISTS to true and displays "NO MORE RECORDS TO SHOW" . If no records are found on the very first page, it sets WS-NO-RECORDS-FOUND ("NO RECORDS FOUND FOR THIS SEARCH CONDITION.").

• Other Responses : Captures the response codes in WS-RESP-CD and WS-REAS-CD , formats a system error message using WS-FILE-ERROR-MESSAGE (e.g., "File Error: READ on CARDDAT returned RESP... ,RESP2..." ), and displays it on the screen.

Error Messages and Triggers

| Error Message | Trigger Condition |

| :--- | :--- |

| ACCOUNT FILTER,IF SUPPLIED MUST BE A 11 DIGIT NUMBER | Account ID filter contains non-numeric characters. |

| CARD ID FILTER,IF SUPPLIED MUST BE A 16 DIGIT NUMBER | Card Number filter contains non-numeric characters. |

| PLEASE SELECT ONLY ONE RECORD TO VIEW OR UPDATE | User entered selection characters on more than one row. |

| INVALID ACTION CODE | User entered a character other than 'S', 'U', or space in the selection column. |

| NO PREVIOUS PAGES TO DISPLAY | User pressed PF7 while on page 1. |

| NO MORE PAGES TO DISPLAY | User pressed PF8 when no more records are available. |

| NO RECORDS FOUND FOR THIS SEARCH CONDITION. | No records match the search filters on initial load. |

Security and Authorization Checks

• No explicit security checks identified : The program does not perform RACF checks or use CICS Sign-on APIs directly.

• Session-Based Context :

• The program relies on the application-managed CARDDEMO-COMMAREA passed from previous programs to maintain user context ( CDEMO-USER-ID , CDEMO-USER-TYPE ).

• When exiting via PF3 or starting a fresh session, the program explicitly sets the user type to standard user ( SET CDEMO-USRTYP-USER TO TRUE ) to ensure standard user privileges are maintained.

Performance Considerations

Manual Scan Filtering (Critical Performance Issue)

The program performs a file browse ( STARTBR and READNEXT / READPREV loops) on the primary KSDS file CARDDAT using the Card Number as the key.

If a user filters by Account ID ( CC-ACCT-ID ), the program still browses the primary file sequentially and filters records in memory ( 9500-FILTER-RECORDS ). This is highly inefficient because it reads every single record in the database from the starting point to find matches for the specified Account ID.

Although the alternate index path constant LIT-CARD-FILE-ACCT-PATH ( 'CARDAIX ' ) is defined in Working-Storage, it is not used in the STARTBR or READ commands. A more performant design would open the browse on the alternate index path ( CARDAIX ) when filtering by Account ID, allowing direct retrieval of only the records associated with that account.

<h2

Credit Card Detail Inquiry and Retrieval Program

The COCRDSLC program is a core business logic component of the CardDemo application designed to facilitate the secure retrieval and display of detailed credit card information. Its primary business purpose is to provide customer service representatives and standard users with a dedicated inquiry interface to view specific card attributes. By entering an account number and a card number, users can instantly access critical cardholder details, including the embossed name, card expiration date, and current activation status.

User interaction with the program is designed to be highly flexible and intuitive. Users can either access the detail screen directly from the main menu or be routed to it automatically after selecting a specific card from the Credit Card List screen. When navigating from the list screen, the program automatically carries over the selected account and card numbers, bypassing manual entry and immediately displaying the card details. For manual searches, the program provides an interactive form, allowing users to input search criteria and execute the query, with the option to exit back to the main menu or the calling program at any time using a designated function key.

To maintain high data quality and prevent unnecessary database overhead, the program performs robust validation on all user inputs. It ensures that the entered account number is a non-zero, 11-digit numeric value and that the card number is a valid 16-digit numeric identifier. Once the inputs pass validation, the program queries the primary card database. If a matching card record is found, the screen is populated with the retrieved details. If the search fails to find a match, or if the inputs are malformed, the program dynamically highlights the invalid fields in red and displays clear, descriptive error messages to guide the user.

Behind the scenes, the program is built using a pseudo-conversational design to maximize mainframe performance and support high volumes of concurrent users. It efficiently releases system resources while waiting for user input on the screen. Throughout the user's session, the program maintains state, security roles, and navigation history by passing a shared communication area between screens. This ensures that the user's context is preserved as they navigate between the main menu, the card list, and the detailed card view.

Business Case and User Interaction

Business Case Overview

The COCRDSLC program is the "Credit Card Detail View" component of the CardDemo mainframe application. Its primary business purpose is to retrieve and display detailed information for a specific credit card, including the cardholder's embossed name, card status (active/inactive), and expiration date.

This program supports two primary operational workflows:

• Direct Inquiry : A business user enters a specific Account ID and Credit Card Number directly on the screen to retrieve card details.

• List-to-Detail Navigation : A user selects a specific card from the Credit Card List screen ( COCRDLIC ), which automatically transfers control to COCRDSLC with the selection criteria pre-populated, bypassing manual input.

User Interaction and Screen Flow

• Screen Entry :

• If accessed from the Main Menu ( COMEN01C ), the screen is displayed with empty input fields, prompting the user to enter search criteria.

• If accessed from the Credit Card List ( COCRDLIC ), the program automatically retrieves and displays the card details for the selected account and card number.

• Data Query : The user enters an 11-digit Account ID and a 16-digit Card Number, then presses ENTER .

• Result Presentation :

• If the card is found in the database, the system populates the read-only fields (Embossed Name, Status, Expiration Month, and Expiration Year) and displays a success message: "Displaying requested details" .

• If validation fails or the card is not found, the input fields are highlighted in red, the cursor is positioned at the invalid field, and an error message is displayed at the bottom of the screen.

• Exit/Navigation : The user can press PF3 to exit the screen and return to the calling program (either the Credit Card List or the Main Menu).

Screen Layout and Navigation

Screen Layout (CCRDSLA)

+-----------------------------------------------------------------------------+

| Tran: CCDL AWS Mainframe Modernization Date: MM/DD/YY |

| Prog: COCRDSLC CardDemo Time: HH:MM:SS |

| |

| Credit Card Detail Screen |

| |

| Account Id: [ 12345678901 ] |

| Card Number: [ 1234567890123456 ] |

| |

| Name on Card: [ John Doe ] |

| Card Status: [ A ] |

| Expiration Month: [ 12 ] Expiration Year: [ 2026 ] |

| |

| |

| |

| |

| |

| <INFOMSGI: Displaying requested details > |

| <ERRMSGI: Error messages appear here in red > |

| |

| ENTER=Fetch F3=Back |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+--------------------------------------------------+

| Main Menu (COMEN01C) |

+------------------------+-------------------------+

|

| (Select Option 4)

v

+--------------------------------------------------+

| Credit Card List (COCRDLIC) |

+------------------------+-------------------------+

|

| (Select Card & Press Enter)

v

+-----------------------------------------------------------------------------+

| Card Detail View (COCRDSLC) |

| |

| 1. Receives Account ID & Card Number via COMMAREA |

| 2. Reads CARDDAT file directly |

| 3. Displays Cardholder Name, Status, and Expiration Date |

+-----------------------------------------------------------------------------+

| |

| [PF3] (If called from List) | [PF3] (If called from Menu)

v v

+---------------------------------+ +--------------------------+

| Credit Card List (COCRDLIC) | | Main Menu (COMEN01C) |

+---------------------------------+ +--------------------------+

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| LIT-THISPGM | 'COCRDSLC' | Program identifier |

| LIT-THISTRANID | 'CCDL' | CICS Transaction ID for this program |

| LIT-THISMAPSET | 'COCRDSL ' | BMS Mapset name |

| LIT-THISMAP | 'CCRDSLA' | BMS Map name |

| LIT-CCLISTPGM | 'COCRDLIC' | Program ID of the Credit Card List program |

| LIT-MENUPGM | 'COMEN01C' | Program ID of the Main Menu program |

| LIT-CARDFILENAME | 'CARDDAT ' | VSAM KSDS Card Data File |

| LIT-CARDFILENAME-ACCT-PATH | 'CARDAIX ' | Alternate Index Path for Card Data File (by Account ID) |

Validation Logic

The program performs input validation during pseudo-conversational re-entry ( CDEMO-PGM-REENTER ).

Input Field Validations

• Account ID Validation ( 2210-EDIT-ACCOUNT ) :

• Checks if the field is empty, spaces, or contains asterisks ( * ). If so, it sets FLG-ACCTFILTER-BLANK and triggers the error "Account number not provided" .

• Verifies if the input is strictly numeric. If non-numeric, it flags FLG-ACCTFILTER-NOT-OK and displays "ACCOUNT FILTER,IF SUPPLIED MUST BE A 11 DIGIT NUMBER" .

• Verifies that the value is non-zero.

• Card Number Validation ( 2220-EDIT-CARD ) :

• Checks if the field is empty, spaces, or contains asterisks ( * ). If so, it sets FLG-CARDFILTER-BLANK and triggers the error "Card number not provided" .

• Verifies if the input is strictly numeric. If non-numeric, it flags FLG-CARDFILTER-NOT-OK and displays "CARD ID FILTER,IF SUPPLIED MUST BE A 16 DIGIT NUMBER" .

• Verifies that the value is non-zero.

Screen-Level Validations

• Cross-Field Validation :

• If both Account ID and Card Number are blank or contain asterisks, the program flags an error and displays "No input received" .

• Attention Identifier (AID) Validation :

• ENTER : Initiates input processing and database retrieval.

• PF3 : Triggers exit processing, returning the user to the calling program.

• Other Keys : Any other key is treated as invalid. The program defaults the action to ENTER but flags the key as invalid.

Data Elements Processed

Screen Fields

• ACCTSIDI / ACCTSIDO : Input/Output field for the 11-digit Account ID.

• CARDSIDI / CARDSIDO : Input/Output field for the 16-digit Card Number.

• CRDNAMEO : Output field for the cardholder's embossed name (50 characters).

• CRDSTCDO : Output field for the card status (1 character).

• EXPMONO : Output field for the card expiration month (2 characters).

• EXPYEARO : Output field for the card expiration year (4 characters).

• INFOMSGO : Output field for informational messages (green/neutral text).

• ERRMSGO : Output field for error messages (red text).

Backend and Control Fields

• CARDDEMO-COMMAREA : Shared communication area containing session metadata.

• CDEMO-FROM-PROGRAM : Tracks the calling program to determine where to return on PF3 .

• CDEMO-ACCT-ID : Passed Account ID from the calling program.

• CDEMO-CARD-NUM : Passed Card Number from the calling program.

• CARD-RECORD : VSAM record structure mapped from CARDDAT .

• CARD-NUM : Primary key (16-digit card number).

• CARD-ACCT-ID : Associated 11-digit account ID.

• CARD-CVV-CD : Card verification value.

• CARD-EMBOSSED-NAME : Name printed on the card.

• CARD-EXPIRAION-DATE : Expiration date stored as YYYY-MM-DD .

• CARD-ACTIVE-STATUS : Status flag ( 'Y' / 'N' ).

Exception and Error Handling

CICS Command Exception Handling

• EXEC CICS READ (File: CARDDAT ) :

• NORMAL : Card record successfully retrieved. Sets FOUND-CARDS-FOR-ACCOUNT to true.

• NOTFND : Card number not found in the database. Sets INPUT-ERROR and displays "Did not find cards for this search condition" .

• Other Responses : Captures the response codes in WS-RESP-CD and WS-REAS-CD , formats a system error message using WS-FILE-ERROR-MESSAGE (e.g., "File Error: READ on CARDDAT returned RESP... ,RESP2..." ), and displays it on the screen.

• EXEC CICS READ (File: CARDAIX - Alternate Index) :

• Implemented in paragraph 9150-GETCARD-BYACCT (not actively called in the main execution path but available for alternate index reads).

• NOTFND : Displays "Did not find this account in cards database" .

Abnormal Condition Responses (ABEND)

• EXEC CICS HANDLE ABEND :

• If an unhandled system abend occurs, control is transferred to ABEND-ROUTINE .

• The program populates ABEND-DATA with the program name ( COCRDSLC ) and an error message ( "UNEXPECTED ABEND OCCURRED." ).

• It sends this plain text message to the terminal and terminates the transaction with abend code '9999' .

Security and Authorization Checks

• Application-Level Authorization :

• The program checks the user type ( CDEMO-USER-TYPE ) passed in the CARDDEMO-COMMAREA .

• When exiting via PF3 , it explicitly sets CDEMO-USRTYP-USER to TRUE to ensure standard user privileges are maintained upon return to the calling program.

• Platform Security :

• No explicit external security manager (such as IBM RACF) checks, transaction security profiles, or standard CICS Sign-on ( CESN / CESF ) integrations are implemented within this program. Security is entirely application-managed via the COMMAREA.

Performance Considerations

• Pseudo-Conversational Design :

• The program utilizes a pseudo-conversational model. After sending the map ( EXEC CICS SEND MAP ), it terminates execution and releases system resources by issuing EXEC CICS RETURN with transaction ID CCDL and the communication area. This prevents active tasks from holding CICS threads while waiting for user input.

• Direct Key Access :

• Database retrieval is performed via a direct READ on the primary key (Card Number) of the CARDDAT VSAM KSDS file. This is highly efficient and avoids resource-intensive file browsing operations.

<h2

Credit Card Detail Update Program for the CardDemo Application

The COCRDUPC program is a core business-logic and presentation component of the CardDemo application, designed to facilitate the secure retrieval and modification of credit card account details. From a business perspective, it allows customer service representatives and authorized personnel to search for specific credit cards, view their current status, and update critical information such as the cardholder's embossed name, active status, and expiration date. This ensures that the credit card registry remains accurate, up-to-date, and compliant with business rules.

Users can access this update utility either directly from the main application menu or by selecting a specific card from a search list. When initiating a fresh search, the user must provide a valid account number and credit card number. Once the program successfully retrieves the matching record from the database, it populates the screen with the card's current details, transitioning the interface into an edit mode where authorized fields become modifiable.

To safeguard data integrity, the program enforces strict business validation rules on all user inputs before any database modifications are permitted. The account and card numbers must be strictly numeric and conform to standard lengths. The cardholder's embossed name is validated to ensure it contains only alphabetic characters and spaces, the active status must be a simple 'Y' or 'N' indicator, and the expiration month and year are verified to represent a valid future calendar date. Any validation failures are highlighted in red on the screen with clear, contextual error messages.

A critical feature of this program is its robust concurrency control mechanism, which prevents data corruption in a multi-user environment. When a user submits validated changes, the program temporarily locks the record and performs a comparison between the original data fetched at the start of the session and the current state of the database. If another user has modified the record in the interim, the update is aborted, the user is alerted to the conflict, and the screen is refreshed with the latest database values to prevent accidental overwrites.

Operating under an efficient pseudo-conversational design, the program optimizes mainframe system resources by releasing active threads while waiting for user input. It maintains session state and user context across screen transitions using a shared communication area. Users can seamlessly commit validated updates, cancel pending changes, or navigate back to the main menu or the preceding credit card list screen using standard keyboard function keys.

Business Case and User Interaction

Business Case Overview

The COCRDUPC program is a core business logic and presentation component of the CardDemo application. Its primary business purpose is to allow authorized operators to update credit card details, specifically the cardholder's embossed name, active status, and expiration date.

To ensure data integrity and prevent concurrent update conflicts (lost updates), the program implements an optimistic concurrency control pattern. It reads the record without a lock, allows the user to make modifications, and then performs a secondary verification read with an update lock ( READ UPDATE ) immediately before rewriting the record. If another transaction modified the record in the interim, the update is rejected, and the operator is prompted to review the updated data.

Screen Layouts

Screen 1: Search / Initial Entry Screen (CCRDUPA)

This screen is presented when the program is first executed or after an update has been successfully completed. The operator must provide both the Account ID and the Card Number to retrieve the card details.

+-----------------------------------------------------------------------------+

| Tran: CCUP AWS Mainframe Modernization Date: MM/DD/YY |

| Prog: COCRDUPC CardDemo Time: HH:MM:SS |

| |

| Update Credit Card Details |

| |

| Account Id : [ ] |

| Card Number : [ ] |

| |

| Card Name : [ ] |

| Active Status: [ ] |

| Expiry Month: [ ] Expiry Year: [ ] Expiry Day: [ ] |

| |

| |

| |

| |

| |

| Message: Please enter Account and Card Number |

| Error : |

| |

| ENTER=Fetch F3=Exit F12=Cancel |

+-----------------------------------------------------------------------------+

Screen 2: Details Display / Edit Screen

Once a valid Account ID and Card Number are entered and fetched, the card details are displayed. The search key fields become protected (read-only), and the editable fields (Card Name, Active Status, Expiry Month, Expiry Year) become unprotected.

+-----------------------------------------------------------------------------+

| Tran: CCUP AWS Mainframe Modernization Date: MM/DD/YY |

| Prog: COCRDUPC CardDemo Time: HH:MM:SS |

| |

| Update Credit Card Details |

| |

| Account Id : 12345678901 |

| Card Number : 4321098765432109 |

| |

| Card Name : [JOHN DOE ] |

| Active Status: [Y] |

| Expiry Month: [12] Expiry Year: [2026] Expiry Day: 01 |

| |

| |

| |

| |

| |

| Message: Details of selected card shown above |

| Error : |

| |

| ENTER=Validate F3=Exit F12=Cancel |

+-----------------------------------------------------------------------------+

Screen 3: Validation / Save Confirmation Screen

After the operator modifies the fields and presses ENTER , the program validates the inputs. If validation succeeds, all input fields are protected, and the operator is prompted to confirm the save operation by pressing PF5 .

+-----------------------------------------------------------------------------+

| Tran: CCUP AWS Mainframe Modernization Date: MM/DD/YY |

| Prog: COCRDUPC CardDemo Time: HH:MM:SS |

| |

| Update Credit Card Details |

| |

| Account Id : 12345678901 |

| Card Number : 4321098765432109 |

| |

| Card Name : JOHN A DOE |

| Active Status: Y |

| Expiry Month: 12 Expiry Year: 2028 Expiry Day: 01 |

| |

| |

| |

| |

| |

| Message: Changes validated.Press F5 to save |

| Error : |

| |

| F5=Save F3=Exit F12=Cancel |

+-----------------------------------------------------------------------------+

Screen Flow and User Navigation

+--------------------------------------------------+

| Main Menu / List |

| (COMEN01C / COCRDLIC) |

+-----------------------+--------------------------+

|

| (Select Update Option / Pass Keys)

v

+--------------------------------------------------+

+----> | Search / Initial Entry | <-----------------+

| | (State: NOT-FETCHED) | |

| +-----------------------+--------------------------+ |

| | |

| | (Enter Keys & Press ENTER) |

| v |

| +--------------------------------------------------+ |

| | Details Display / Edit | |

| | (State: SHOW-DETAILS) | |

| +-----------------------+--------------------------+ |

| | | (PF12 Cancel /

| | (Modify Fields & Press ENTER) | Update Success)

| v |

| +--------------------------------------------------+ |

| | Validation / Confirmation | |

| | (State: OK-NOT-CONFIRMED) | ------------------+

| +-----------------------+--------------------------+

| |

| | (Press PF5 to Save)

| v

| +--------------------------------------------------+

| | Write Processing & Commit |

| | (State: OKAYED-AND-DONE) |

| +-----------------------+--------------------------+

| |

+------------------------------+ (Auto-Reset to Search)

Navigation and Data Flow Description

• Entry : The program can be invoked directly from the Main Menu ( COMEN01C ) or with pre-populated keys from the Credit Card List program ( COCRDLIC ).

• Search State : If no keys are passed, the program starts in the CCUP-DETAILS-NOT-FETCHED state. The operator enters the Account ID and Card Number and presses ENTER . The program reads the CARDDAT file. If found, the state transitions to CCUP-SHOW-DETAILS .

• Edit State : The screen is redisplayed with the card details. The operator can modify the Card Name, Active Status, Expiry Month, and Expiry Year. Pressing ENTER triggers validation.

• Confirmation State : If validation is successful, the state transitions to CCUP-CHANGES-OK-NOT-CONFIRMED . The screen fields are protected, and the operator is prompted to press PF5 to save or PF12 to cancel.

• Commit State : Pressing PF5 triggers the write processing. The program locks the record, verifies that no other user has changed it, rewrites the record, and transitions to CCUP-CHANGES-OKAYED-AND-DONE . The screen is then reset to the initial search state with a success message.

• Exit : Pressing PF3 at any time exits the program and returns control to the calling program or the Main Menu.

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| LIT-THISPGM | 'COCRDUPC' | Current Program Name |

| LIT-THISTRANID | 'CCUP' | Current Transaction ID |

| LIT-THISMAPSET | 'COCRDUP ' | Mapset Name |

| LIT-THISMAP | 'CCRDUPA' | Map Name |

| LIT-CCLISTPGM | 'COCRDLIC' | Credit Card List Program Name |

| LIT-MENUPGM | 'COMEN01C' | Main Menu Program Name |

| LIT-CARDFILENAME | 'CARDDAT ' | VSAM Card Data File Name |

| LIT-ALL-ALPHA-FROM | 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' | Source string for alphabetic validation |

| LIT-ALL-SPACES-TO | SPACES (52 spaces) | Target string for alphabetic validation |

Validation Logic

Input Field Validations

Account ID ( ACCTSIDI )

• Must be supplied (cannot be spaces, low-values, or asterisks).

• Must be strictly numeric.

• Must be an 11-digit non-zero number.

• If invalid, the field is highlighted in red, the cursor is positioned on it, and the error message "Account number must be a non zero 11 digit number" is displayed.

Card Number ( CARDSIDI )

• Must be supplied (cannot be spaces, low-values, or asterisks).

• Must be strictly numeric.

• Must be a 16-digit non-zero number.

• If invalid, the field is highlighted in red, the cursor is positioned on it, and the error message "Card number if supplied must be a 16 digit number" is displayed.

Cardholder Name ( CRDNAMEI )

• Must be supplied (cannot be spaces, low-values, or asterisks).

• Must contain only alphabetic characters (A-Z, a-z) and spaces. This is validated by converting all alphabetic characters to spaces using INSPECT CONVERTING and verifying that the remaining trimmed string length is zero.

• If invalid, the field is highlighted in red, the cursor is positioned on it, and the error message "Card name can only contain alphabets and spaces" is displayed.

Card Active Status ( CRDSTCDI )

• Must be supplied (cannot be spaces, low-values, or asterisks).

• Must be exactly 'Y' or 'N' .

• If invalid, the field is highlighted in red, the cursor is positioned on it, and the error message "Card Active Status must be Y or N" is displayed.

Expiry Month ( EXPMONI )

• Must be supplied (cannot be spaces, low-values, or asterisks).

• Must be numeric and fall within the range of 01 through 12 .

• If invalid, the field is highlighted in red, the cursor is positioned on it, and the error message "Card expiry month must be between 1 and 12" is displayed.

Expiry Year ( EXPYEARI )

• Must be supplied (cannot be spaces, low-values, or asterisks).

• Must be numeric and fall within the range of 1950 through 2099 .

• If invalid, the field is highlighted in red, the cursor is positioned on it, and the error message "Invalid card expiry year" is displayed.

Screen-Level Validations and Condition Checks

Attention Identifier (AID) Key Validation

• PF3 : Allowed at any time to exit the program.

• PF12 : Allowed to cancel the current operation and reset the screen.

• PF5 : Only allowed when the program is in the CCUP-CHANGES-OK-NOT-CONFIRMED state (changes validated but not yet saved).

• ENTER : Used to submit search keys or submit modifications for validation.

• Any other key is treated as invalid, and the program defaults the action to ENTER .

No Changes Detected Check

• If the program is in the CCUP-SHOW-DETAILS state and the operator presses ENTER without modifying any of the editable fields (Card Name, Status, Expiry Month, Expiry Year), the program rejects the submission with the message "No change detected with respect to values fetched." .

Optimistic Concurrency Check

• Before rewriting the record to the VSAM file, the program performs a READ UPDATE to lock the record and compares the current file values against the original values stored in CCUP-OLD-DETAILS .

• If any field (CVV, Embossed Name, Expiry Year, Expiry Month, Expiry Day, or Active Status) has changed since the initial read, the update is aborted, the state is reset to CCUP-SHOW-DETAILS , and the error message "Record changed by some one else. Please review" is displayed.

Data Elements Processed

Screen Fields (Map CCRDUPA )

• ACCTSIDI / ACCTSIDO : Input/Output Account ID (11 characters).

• CARDSIDI / CARDSIDO : Input/Output Card Number (16 characters).

• CRDNAMEI / CRDNAMEO : Input/Output Cardholder Embossed Name (50 characters).

• CRDSTCDI / CRDSTCDO : Input/Output Card Active Status (1 character).

• EXPMONI / EXPMONO : Input/Output Expiry Month (2 characters).

• EXPYEARI / EXPYEARO : Input/Output Expiry Year (4 characters).

• EXPDAYI / EXPDAYO : Input/Output Expiry Day (2 characters, protected).

• INFOMSGO : Output Information Message (40 characters).

• ERRMSGO : Output Error Message (80 characters).

Commarea Fields ( CARDDEMO-COMMAREA & WS-THIS-PROGCOMMAREA )

• CDEMO-USER-ID : Logged-in user identifier.

• CDEMO-USER-TYPE : User role ( 'A' for Admin, 'U' for User).

• CCUP-CHANGE-ACTION : Current state flag of the update process:

• LOW-VALUES / SPACES : Details not yet fetched.

• 'S' : Details fetched and displayed.

• 'E' : Validation errors found.

• 'N' : Changes validated, awaiting confirmation.

• 'C' : Changes successfully committed.

• 'L' : Lock error during update.

• 'F' : Update failed.

• CCUP-OLD-DETAILS : Group item storing the original values of the card record for concurrency verification.

• CCUP-NEW-DETAILS : Group item storing the newly entered values from the screen.

Database Fields ( CARD-RECORD from CARDDAT )

• CARD-NUM : Primary key, Card Number (16 characters).

• CARD-ACCT-ID : Account ID (9-digit numeric, redefined as 11 characters).

• CARD-CVV-CD : Card Verification Value (3-digit numeric).

• CARD-EMBOSSED-NAME : Cardholder Name (50 characters).

• CARD-EXPIRAION-DATE : Expiration Date stored in YYYY-MM-DD format (10 characters).

• CARD-ACTIVE-STATUS : Active Status flag (1 character).

Exception and Error Handling

CICS Command Exception Handling

• EXEC CICS HANDLE ABEND : Directs any unhandled program abends to the ABEND-ROUTINE label, which sends an abend screen with the code '9999' and terminates the task.

• EXEC CICS READ (Initial Read) :

• NOTFND : Handled gracefully. Sets the error message "Did not find cards for this search condition" and highlights the search fields in red.

• Other errors: Formats a file error message containing the operation ( READ ), file name ( CARDDAT ), RESP , and RESP2 codes, and displays it in ERRMSGO .

• EXEC CICS READ UPDATE (Locking Read) :

• If the record cannot be locked or read, the program sets the error message "Could not lock record for update" and aborts the write sequence.

• EXEC CICS REWRITE :

• If the rewrite operation fails, the program sets the error message "Update of record failed" and aborts.

Error Messages and Triggers

| Error Message | Trigger Condition |

| :--- | :--- |

| Account number not provided | Account ID field is blank or contains asterisks on search submission. |

| Card number not provided | Card Number field is blank or contains asterisks on search submission. |

| Card name not provided | Card Name field is blanked out during modification. |

| Card name can only contain alphabets and spaces | Card Name contains numeric or special characters. |

| No input received | Both Account ID and Card Number are blank on search submission. |

| No change detected with respect to values fetched. | Operator pressed ENTER without modifying any fields in edit mode. |

| Account number must be a non zero 11 digit number | Account ID is non-numeric or not 11 digits. |

| Card number if supplied must be a 16 digit number | Card Number is non-numeric or not 16 digits. |

| Card Active Status must be Y or N | Active Status field contains a value other than 'Y' or 'N'. |

| Card expiry month must be between 1 and 12 | Expiry Month is non-numeric or outside the 01-12 range. |

| Invalid card expiry year | Expiry Year is non-numeric or outside the 1950-2099 range. |

| Did not find cards for this search condition | VSAM read returned NOTFND for the specified Card Number. |

| Could not lock record for update | VSAM READ UPDATE failed to acquire an exclusive lock. |

| Record changed by some one else. Please review | Concurrency check failed; the record was modified by another transaction. |

| Update of record failed | VSAM REWRITE returned a non-normal response. |

Security and Authorization Checks

• No explicit external security checks (such as IBM RACF or standard CICS Signon CESN / CESF integrations) are implemented within this program.

• Session-Based Authorization : The program relies entirely on the application-managed CARDDEMO-COMMAREA passed from previous programs to maintain user context ( CDEMO-USER-ID , CDEMO-USER-TYPE ).

• Role Assignment : Upon returning to the calling menu, the program explicitly sets the user type to standard user ( SET CDEMO-USRTYP-USER TO TRUE ).

Performance Considerations

Pseudo-Conversational Design

The program is designed to be pseudo-conversational. It does not remain active in memory while waiting for operator input. After sending a map, it issues an EXEC CICS RETURN specifying the transaction ID CCUP and passing the transaction state in the COMMAREA . This releases CICS thread storage and resources, maximizing concurrent user capacity.

Optimistic Locking Pattern

To prevent long-held locks on the VSAM file ( CARDDAT ), the program reads the record without a lock during the initial fetch ( 9100-GETCARD-BYACCTCARD ).

An exclusive lock is only acquired during the write processing phase ( 9200-WRITE-PROCESSING ) using EXEC CICS READ UPDATE . This lock is held for a minimal duration—only long enough to perform the concurrency comparison and execute the EXEC CICS REWRITE —before being released by the implicit syncpoint at task end. This pattern significantly reduces transaction queuing and deadlocks in high-concurrency environments.

<h2

Automated System Date and Time Query Service via IBM MQ

This program serves as an automated utility service within a CICS mainframe environment, designed to provide the current system date and time to requesting client applications. Operating as an asynchronous message consumer, the program processes incoming inquiries via IBM MQ, allowing external or internal systems to synchronize or verify their clocks against the mainframe's authoritative system time.

Upon invocation, which is typically triggered automatically when a new message arrives, the program retrieves the identity of the initiating queue. It then establishes connections to three distinct message queues: an input queue for receiving requests, an output queue for sending responses, and a dedicated error queue for logging operational anomalies. This setup ensures that the program can dynamically adapt to the queue that triggered its execution while maintaining a structured path for communication and error reporting.

The core processing logic runs in a continuous loop, fetching request messages from the input queue. For each message retrieved, the program queries the mainframe operating system to obtain the current absolute time. It formats this timestamp into a standardized date (MM-DD-YYYY) and time string, constructs a response message, and dispatches it to the designated reply queue. To maintain message context and ensure the requesting application can match the response to its original request, the program preserves and attaches the original message and correlation identifiers to the reply.

The program continues to process incoming requests until no more messages are available on the input queue, utilizing a short wait interval to detect idle periods. If an error occurs during queue operations or message processing, the program formats a detailed diagnostic message, routes it to the centralized error queue for administrator review, and initiates a shutdown. Once all messages are processed or an unrecoverable error is encountered, the program gracefully closes all active queues and terminates its execution, releasing system resources back to the CICS environment.

Program Analysis: CODATE01

Business Case

The CODATE01 program is an asynchronous, message-driven CICS-MQ service that acts as a centralized system date and time provider. It is designed to run in the background on an IBM Mainframe, triggered automatically when request messages arrive on a designated MQ input queue.

The primary business purpose of this program is to provide a standardized, synchronized mainframe system timestamp to requesting client applications (which may be external systems or other mainframe applications). By offloading this to a dedicated service, the enterprise ensures consistent date and time formatting across integrated systems.

User Interaction and Screen Navigation

CODATE01 is a headless, system-to-system middleware program . It does not feature any user interface, 3270 terminal screens, or direct human interaction.

Interaction Workflow

• Triggering : An external application puts a request message onto an MQ input queue.

• CICS Initiation : The arrival of the message triggers the CICS transaction associated with CODATE01 (typically via the CICS-MQ trigger monitor, CKTI ).

• Processing : CODATE01 reads the request, fetches the system date and time, and formats it.

• Replying : The program writes the formatted date/time string back to a reply queue.

• Termination : The program continues to process messages until the input queue is empty, then terminates.

System Interaction Diagram

+-----------------------------------------------------------------+

| Requesting Client Application |

+-------------------------------+---------------------------------+

|

| 1. Sends Request Message

v

+-------------------------------+---------------------------------+

| MQ Input Queue |

+-------------------------------+---------------------------------+

|

| 2. Triggers CICS Transaction

v

+-------------------------------+---------------------------------+

| COBOL Program: CODATE01 |

| |

| - Retrieves Input Queue Name via EXEC CICS RETRIEVE |

| - Opens Input, Reply, and Error Queues |

| - Loops MQGET with 5-second wait |

| - Formats System Date & Time via CICS ASKTIME/FORMATTIME |

+---------------+---------------------------------+---------------+

| |

| 3a. Success: MQPUT | 3b. Failure: MQPUT

v v

+---------------+-----------------+ +-------------+-----------------+

| MQ Reply Queue | | MQ Error Queue |

| (CARD.DEMO.REPLY.DATE) | | (CARD.DEMO.ERROR) |

+---------------------------------+ +---------------------------------+

Data Flow

• Trigger Data Retrieval : Upon startup, the program issues an EXEC CICS RETRIEVE command to obtain the MQ Trigger Message ( MQTM ). This structure contains the name of the queue that triggered the transaction ( MQTM-QNAME ).

• Queue Initialization : The program uses the retrieved queue name to open the input queue for reading, and opens the hardcoded reply and error queues for writing.

• Message Consumption : The program enters a loop, executing MQGET to retrieve messages from the input queue.

• Date/Time Retrieval : For each message successfully retrieved:

• It executes EXEC CICS ASKTIME to get the raw absolute system time.

• It executes EXEC CICS FORMATTIME to convert the absolute time into a readable date ( MM-DD-YYYY ) and time ( HH:MM:SS ).

• Response Construction : The program concatenates the literal headers with the formatted values into a single string:

"SYSTEM DATE : MM-DD-YYYYSYSTEM TIME : HH:MM:SS"

• Message Correlation : The program copies the MsgId and CorrelId from the incoming request message descriptor ( MQMD ) into the outgoing message descriptor. This ensures the requesting client can correlate the reply with its original request.

• Reply Transmission : The program executes MQPUT to write the response string to the reply queue ( CARD.DEMO.REPLY.DATE ).

• Transaction Commit : An EXEC CICS SYNCPOINT is issued after each message is processed to commit the MQ operations.

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| REPLY-QUEUE-NAME | 'CARD.DEMO.REPLY.DATE' | The hardcoded MQ queue where successful date/time replies are sent. |

| ERROR-QUEUE-NAME | 'CARD.DEMO.ERROR' | The hardcoded MQ queue where application and MQ error details are logged. |

| MQGMO-WAITINTERVAL | 5000 | The MQ Get Message Option wait interval set to 5,000 milliseconds (5 seconds). |

| MQ-BUFFER-LENGTH | 1000 | The maximum buffer size (1,000 bytes) allocated for MQ messages. |

| LIT-ACCTFILENAME | 'ACCTDAT ' | Hardcoded file name literal (defined but unused in the logic). |

Validation Logic

The program performs several system-level and conditional validations to ensure robust execution:

• CICS Start Validation : Validates the success of the EXEC CICS RETRIEVE command by checking if WS-CICS-RESP1-CD is equal to DFHRESP(NORMAL) . If the retrieve fails, the program logs the error and terminates.

• MQ Open Validation : After calling MQOPEN for the input, reply, and error queues, the program validates that MQ-CONDITION-CODE is equal to MQCC-OK . Any other value triggers the error routine.

• MQ Get Validation : After calling MQGET , the program checks MQ-CONDITION-CODE :

• If MQCC-OK , it proceeds to process the message.

• If not MQCC-OK , it checks if MQ-REASON-CODE is MQRC-NO-MSG-AVAILABLE . If true, it gracefully sets the end-of-messages flag ( NO-MORE-MSGS to TRUE ) to exit the processing loop.

• Any other reason code is treated as a fatal error, triggering the error routine.

• MQ Put/Close Validation : Every MQPUT and MQCLOSE call is validated against MQ-CONDITION-CODE = MQCC-OK . Failure results in immediate error logging and program termination.

Data Elements Processed

The key data fields and parameters processed by the program include:

• MQTM-QNAME : The input queue name passed by CICS during transaction initiation.

• INPUT-QUEUE-NAME : The variable holding the active input queue name.

• WS-ABS-TIME : A packed decimal field ( PIC S9(15) COMP-3 ) holding the raw absolute system time from CICS.

• WS-MMDDYYYY : A 10-character field ( PIC X(10) ) holding the formatted system date (e.g., 12-31-2023 ).

• WS-TIME : An 8-character field ( PIC X(8) ) holding the formatted system time (e.g., 14:30:00 ).

• MQ-BUFFER : A 1,000-byte alphanumeric field used as the transit buffer for sending and receiving MQ payloads.

• MQMD-MSGID / SAVE-MSGID : The unique 24-byte Message Identifier used to correlate the reply message.

• MQMD-CORRELID / SAVE-CORELID : The 24-byte Correlation Identifier used to match the reply to the client's request.

• MQ-ERR-DISPLAY : A structured group item used to format error details, containing:

• MQ-ERROR-PARA : The paragraph where the error occurred.

• MQ-APPL-RETURN-MESSAGE : A descriptive error message.

• MQ-APPL-CONDITION-CODE : The MQ condition code.

• MQ-APPL-REASON-CODE : The MQ reason code.

• MQ-APPL-QUEUE-NAME : The name of the queue associated with the failure.

Exception and Error Handling

CODATE01 implements structured error handling to prevent silent failures and ensure message integrity:

• CICS Response Codes : Uses the RESP and RESP2 options on CICS commands. If EXEC CICS RETRIEVE fails, the response codes are converted to decimal format, formatted into a string, and sent to the error queue before the program exits.

• MQ Error Logging : When an MQ call fails (e.g., MQOPEN or MQGET returns a non-zero condition code other than "no message available"), the program:

• Populates the MQ-ERR-DISPLAY structure with the failing paragraph, MQ condition code, MQ reason code, and queue name.

• Moves this structure to the MQ buffer.

• Executes MQPUT to write the error details to the CARD.DEMO.ERROR queue.

• Calls the termination routine to close any open queues and exit.

• Double-Fault Protection : If an error occurs while trying to open or write to the error queue itself, the program falls back to a standard DISPLAY MQ-ERR-DISPLAY statement to write the error details directly to the CICS system log (sysout), then terminates immediately.

• Transactional Rollback : The program utilizes MQ syncpoint options ( MQGMO-SYNCPOINT and MQPMO-SYNCPOINT ) in conjunction with EXEC CICS SYNCPOINT . If the program encounters a fatal error and terminates, CICS will automatically roll back any uncommitted MQ operations, ensuring that the request message is not lost and can be retried or sent to a dead-letter queue by the queue manager.

Security and Authorization Checks

• No explicit security checks identified : The program does not contain any explicit RACF calls ( EXEC SECU ), transaction security checks, or sign-on validations ( CESN / CESF ).

• Infrastructure Security : It relies entirely on the underlying CICS transaction security profiles and IBM MQ queue-level authorization checks configured by system administrators.

Performance Considerations

• IS INITIAL Program Attribute : The program is defined with IS INITIAL in the PROGRAM-ID paragraph. This ensures that the program's Working-Storage Section is reset to its initial state on every execution, preventing memory leaks but introducing a minor overhead for re-initialization.

• Non-Blocking Wait Interval : The MQGET call uses a 5-second wait interval ( MQGMO-WAITINTERVAL = 5000 ) with the MQGMO-WAIT option. This prevents CPU spinning (busy-waiting) when the queue is temporarily empty, allowing the program to wait efficiently for incoming messages.

• Shared Input Queue : The input queue is opened with MQOO-INPUT-SHARED . This allows multiple instances of CODATE01 to run concurrently, enabling parallel processing of date/time requests under heavy workloads.

• Syncpoint Management : By issuing EXEC CICS SYNCPOINT inside the main loop after each message is processed, the program releases locks and commits MQ messages incrementally, preventing long-running units of work (UOWs) from consuming excessive system resources.

<h2

CardDemo Main Application Menu for Regular Users

The COMEN01C program serves as the central navigation hub for standard, non-administrative users within the CardDemo credit card processing application. Acting as the primary landing page immediately following a successful login, this program presents users with a structured, interactive menu of daily business operations. Its main business purpose is to facilitate seamless navigation across the application's core functional areas while maintaining a secure and consistent user session.

Through this main menu, standard users can access a comprehensive suite of credit card management and financial transaction features. The menu options include viewing and updating customer account details, searching and updating credit card records, and managing financial transactions—such as listing, viewing, and adding new transactions. Additionally, users can navigate to modules for generating transaction reports, processing bill payments, and viewing pending transaction authorizations.

User interaction is designed to be intuitive and robust. The user selects a desired function by entering its corresponding menu number. The program immediately validates the input to ensure it is a valid, active option. It also performs role-based authorization checks to ensure standard users do not accidentally access restricted administrative functions. If the user enters an invalid option, presses an unsupported key, or attempts to access an unauthorized area, the program displays clear, contextual error messages at the bottom of the screen.

Behind the scenes, the program coordinates navigation by dynamically transferring control to the selected sub-application. It utilizes a shared communication area to pass critical session metadata—such as the user's identity, role, and transaction history—ensuring that the user's context is preserved as they move between different screens. The program also features built-in safeguards, such as verifying whether a target module is installed before attempting to load it, and displaying "coming soon" notifications for features currently under development.

To ensure a user-friendly experience, the program allows users to safely exit the menu and return to the main sign-on screen at any time by pressing a designated function key. Operating under a pseudo-conversational design, the program efficiently releases system resources while waiting for user input, optimizing mainframe performance and supporting high concurrent user activity.

CardDemo Main Menu Program ( COMEN01C ) - Business & Technical Description

Business Case and User Interaction

Business Case Overview

The COMEN01C program serves as the primary navigation hub (Main Menu) for regular, non-administrative users of the CardDemo Credit Card Processing Application. Its primary business purpose is to present a structured list of available application functions—such as viewing accounts, updating credit cards, listing transactions, and viewing pending authorizations—and safely route the user to their selected destination.

By acting as a centralized dispatcher, the program ensures that users can seamlessly navigate the application while maintaining their security context, user profile, and session state across different functional modules.

User Interaction and Screen Flow

• Menu Entry : The user is automatically routed to this menu program ( COMEN01C ) after successful authentication via the Sign-on program ( COSGN00C ), provided their user type is "Regular User" ('U').

• Screen Presentation : The program displays the COMEN1A map, which dynamically lists up to 11 functional options. The header displays real-time system metadata, including the transaction ID ( CM00 ), program name ( COMEN01C ), current date, and current time.

• Option Selection : The user types a 1- or 2-digit option number (1 through 11) into the selection field and presses the ENTER key.

• Routing :

• If the option is valid and installed, the program transfers control ( EXEC CICS XCTL ) to the corresponding target program, passing the user's session data in the CICS Communication Area ( COMMAREA ).

• If the option is marked as "coming soon" (dummy program) or is not installed on the CICS region, an appropriate status or error message is displayed at the bottom of the screen, and the menu is redisplayed.

• Exit : The user can press the PF3 key at any time to exit the menu. This action routes them back to the Sign-on screen ( COSGN00C ).

Screen Layout and Navigation

Screen Layout (COMEN1A)

+-----------------------------------------------------------------------------+

| Tran: CM00 AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: COMEN01C CardDemo Time: hh:mm:ss |

| |

| Main Menu |

| |

| 1. Account View |

| 2. Account Update |

| 3. Credit Card List |

| 4. Credit Card View |

| 5. Credit Card Update |

| 6. Transaction List |

| 7. Transaction View |

| 8. Transaction Add |

| 9. Transaction Reports |

| 10. Bill Payment |

| 11. Pending Authorization View |

| |

| |

| Please select an option : [ ] |

| |

| <ERRMSG: Error or status messages appear here in red/green > |

| |

| ENTER=Continue F3=Exit |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+--------------------------------------------------+

| Sign-on Screen |

| (COSGN00C) |

+-----------------------+--------------------------+

|

| (Successful Login - Regular User)

v

+--------------------------------------------------+

| Main Menu Program | <-----------------+

| (COMEN01C) | |

+-----------------------+--------------------------+ |

| |

+------------------+------------------+ |

| [PF3] | [ENTER] (Valid Option) | (XCTL Return /

v v | Invalid Option)

+-----------------------+ +------------------+ |

| Sign-on Screen | | Target Program | |

| (COSGN00C) | | (e.g., COACTVWC) | -----------------+

+-----------------------+ +------------------+

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| WS-PGMNAME | 'COMEN01C' | Program identifier |

| WS-TRANID | 'CM00' | CICS Transaction ID associated with this program |

| CDEMO-MENU-OPT-COUNT | 11 | Total number of active menu options |

| CCDA-TITLE01 | ' AWS Mainframe Modernization ' | Screen Header Title Line 1 |

| CCDA-TITLE02 | ' CardDemo ' | Screen Header Title Line 2 |

| CCDA-MSG-INVALID-KEY | 'Invalid key pressed. Please see below... ' | Error message for unsupported AID keys |

| CCDA-MSG-THANK-YOU | 'Thank you for using CardDemo application... ' | Exit message |

Validation Logic

Input Field Validations

• Option Selection Validation :

• The program extracts the user input from OPTIONI and trims trailing spaces.

• Any remaining spaces are replaced with '0' characters to ensure a clean numeric conversion.

• The input is verified to be strictly numeric. If non-numeric characters are present, the error "Please enter a valid option number..." is displayed.

• The numeric value must fall within the range of 1 to 11 (defined by CDEMO-MENU-OPT-COUNT ). If the value is 0 or greater than 11 , the error "Please enter a valid option number..." is displayed.

Screen-Level Validations

• Attention Identifier (AID) Validation :

• ENTER : Triggers option validation and program routing.

• PF3 : Triggers exit processing, transferring control back to COSGN00C .

• Other Keys : Any other key (e.g., PF1, PF2, PF4, Clear) is rejected. The program sets WS-ERR-FLG to 'Y' , displays "Invalid key pressed. Please see below..." , and redisplays the menu.

Condition Checks

• Role-Based Authorization Check :

• The program checks if the current user's role ( CDEMO-USER-TYPE ) is authorized for the selected option.

• If the user is a standard user ( CDEMO-USRTYP-USER / 'U' ) and the selected option's metadata requires admin privileges ( CDEMO-MENU-OPT-USRTYPE = 'A' ), access is blocked, and the message "No access - Admin Only option... " is displayed.

• Program Installation Check :

• For Option 11 ( COPAUS0C ), the program performs a dynamic CICS inquiry ( EXEC CICS INQUIRE PROGRAM ) to verify if the program is installed in the CICS region.

• If the program is not installed, it prevents the transfer of control and displays "This option Pending Authorization View is not installed..." in red.

• Dummy Program Check :

• If the target program name associated with the selected option starts with 'DUMMY' , the program displays "This option [Option Name] is coming soon ..." in green.

Data Elements Processed

Screen Fields

• TRNNAMEO : Output field for the transaction ID ( CM00 ).

• PGMNAMEO : Output field for the program name ( COMEN01C ).

• TITLE01O / TITLE02O : Output fields for screen headers.

• CURDATEO / CURTIMEO : Output fields for the formatted system date ( MM/DD/YY ) and time ( HH:MM:SS ).

• OPTN001O through OPTN012O : Output fields displaying the formatted menu option text (e.g., "1. Account View" ).

• OPTIONI / OPTIONO : Input/Output field for the user's menu selection.

• ERRMSGO : Output field for error and status messages.

• ERRMSGC : Attribute byte used to dynamically change the color of the error message (e.g., DFHRED for errors, DFHGREEN for status updates).

Backend and Control Fields

• CARDDEMO-COMMAREA : The primary CICS Communication Area used to pass session state between programs.

• CDEMO-FROM-TRANID : Set to 'CM00' before transferring control.

• CDEMO-FROM-PROGRAM : Set to 'COMEN01C' before transferring control.

• CDEMO-USER-ID : Retains the logged-in user's ID.

• CDEMO-USER-TYPE : Retains the user's role ( 'U' for Regular User, 'A' for Admin).

• CDEMO-PGM-CONTEXT : Set to 0 (Enter context) to signal a fresh entry into the target program.

Exception and Error Handling

CICS Command Exception Handling

• EXEC CICS INQUIRE PROGRAM :

• The program utilizes the NOHANDLE option to prevent CICS from abending if the target program is not defined in the CICS System Definition (CSD) file.

• The response code is captured in EIBRESP . If EIBRESP does not equal DFHRESP(NORMAL) , the program gracefully handles the error by displaying a red error message indicating the option is not installed.

• EXEC CICS RECEIVE MAP :

• Response codes are captured using the RESP and RESP2 options into WS-RESP-CD and WS-REAS-CD to ensure structured, inline error handling.

Error Messages Displayed

| Message Text | Color | Trigger Condition |

| :--- | :--- | :--- |

| Invalid key pressed. Please see below... | Red | User pressed an unsupported AID key (not ENTER or PF3). |

| Please enter a valid option number... | Red | User entered a non-numeric value, a value of 0, or a value greater than 11. |

| No access - Admin Only option... | Red | A regular user attempted to select an option reserved for administrators. |

| This option [Option Name] is not installed... | Red | The target program for the selected option is not defined in the CICS region. |

| This option [Option Name] is coming soon ... | Green | The selected option is mapped to a dummy program. |

Security and Authorization Checks

• Role-Based Authorization :

• The program performs an application-level authorization check by comparing the user's role ( CDEMO-USER-TYPE from the COMMAREA) against the required user type of the selected menu option ( CDEMO-MENU-OPT-USRTYPE ).

• Standard users ( 'U' ) are blocked from executing options flagged as Admin-only ( 'A' ).

• Platform Security :

• No explicit external security manager (such as IBM RACF) checks, EXEC CICS ASSIGN USERID calls, or standard CICS Signon ( CESN / CESF ) integrations are implemented within this program. Security is entirely application-managed via the COMMAREA.

Performance Considerations

• Pseudo-Conversational Design :

• The program is designed to be pseudo-conversational. It does not remain active in memory while waiting for user input.

• After sending the map, it issues an EXEC CICS RETURN specifying the transaction ID CM00 and passing the CARDDEMO-COMMAREA . This releases CICS resources (such as thread storage) and maximizes concurrent user capacity.

• Dynamic Program Inquiry :

• By using EXEC CICS INQUIRE PROGRAM with NOHANDLE before executing XCTL for optional programs, the program avoids costly transaction abends (such as PGMIDERR ), which are resource-intensive for the CICS region to process.

<h2

Card Authorization Decision and Transaction Processing Engine

The COPAUA0C program is a core transactional component of the CardDemo authorization module, designed to evaluate and decide on credit card transaction requests in real time. Operating as an asynchronous, message-driven service within a CICS environment, the program is triggered by incoming messages on a request queue. It processes batches of transaction requests to determine whether a cardholder's purchase should be approved or declined based on credit availability and account status.

Upon receiving a transaction request, the program performs a series of data retrieval steps to establish the context of the transaction. It maps the incoming card number to its associated customer and account identifiers using cross-reference files. Once the identifiers are resolved, the program retrieves the master account details, customer profile information, and any existing pending authorization summaries from an IMS database to obtain an accurate, up-to-date financial profile of the cardholder.

The core business logic centers on credit evaluation and risk assessment. The program calculates the cardholder's available credit by subtracting their current balance and pending transactions from their total credit limit. If the requested transaction amount is within the available limit, the transaction is approved; otherwise, it is declined due to insufficient funds. The program also handles fallback scenarios where master account data is used if pending summaries are unavailable, and it assigns specific response codes to communicate the exact reason for any declined transactions, such as inactive accounts or suspected fraud.

After making a decision, the program immediately formats and sends a response message back to the originating system via a reply queue, ensuring minimal latency for the merchant. Concurrently, it updates the system's database of record. It modifies the pending authorization summary with updated balances and transaction counts, and inserts a detailed authorization record containing timestamps, merchant details, and the final decision status for subsequent clearing and settlement matching.

To ensure operational efficiency and system stability, the program processes messages in a controlled loop up to a predefined limit per execution. It incorporates robust error-handling routines that capture database, file, or messaging middleware failures, logging detailed diagnostic information to a centralized system queue. This design guarantees that critical processing errors are recorded for administrative action while maintaining the integrity of the financial transaction stream.

Business Case and Overview

The COPAUA0C program is the core Card Authorization Decision Program within the CardDemo application's Authorization Module. It is designed as an automated, high-performance, message-driven background process running under CICS.

Instead of interacting with human users via 3270 terminal screens, this program processes credit card transaction authorization requests submitted asynchronously by external point-of-sale (POS) or merchant systems.

Core Business Functions:

• Request Retrieval : Receives transaction authorization requests from an IBM MQ Request Queue.

• Data Validation & Cross-Referencing : Validates the incoming card number against a cross-reference file ( CCXREF ), retrieves the associated account master record ( ACCTDAT ), and verifies the customer master record ( CUSTDAT ).

• Credit Limit Evaluation : Retrieves the current pending authorization summary from an IMS database ( PSBPAUTB ). It calculates the available credit limit and evaluates whether the requested transaction amount can be approved.

• Decisioning : Approves or declines the transaction, assigning standardized response and reason codes.

• Response Delivery : Sends an immediate CSV-formatted response message back to the caller via an MQ Reply Queue.

• Audit Trail & Ledger Update : Updates the IMS database with the new authorization summary and inserts a detailed transaction record for audit and matching purposes.

System Interaction and Data Flow

Because COPAUA0C is a background, message-driven program triggered by MQ events, there are no user-facing screens or direct user navigation. The system-to-system interaction and data flow are illustrated below.

System Interaction Diagram

+-----------------------------------------------------------------------+

| External POS / Merchant |

+-----------------------------------+-----------------------------------+

|

1. Send Auth Request (CSV) | 7. Receive Auth Response (CSV)

v

+-----------------------------------------------------------------------+

| IBM MQ Series |

| |

| +--------------------------+ +--------------------------+ |

| | MQ Request Queue | | MQ Reply Queue | |

| +------------+-------------+ +------------^-------------+ |

+----------------|------------------------------------|-----------------+

| |

| 2. Trigger (CKTI) | 6. MQPUT1 (Response)

v |

+-----------------------------------------------------|-----------------+

| CICS Region | |

| | |

| +-------------------------------------------------+-------------+ |

| | Transaction: CP00 Program: COPAUA0C | |

| +------------+--------------------------------------------------+ |

| | |

| |-- 3. Read Request (MQGET) |

| | |

| |-- 4. Read VSAM Files (EXEC CICS READ) |

| | | |

| | +--> CCXREF (Card Cross-Reference) |

| | +--> ACCTDAT (Account Master) |

| | +--> CUSTDAT (Customer Master) |

| | |

| |-- 5. Read/Write IMS DB (EXEC DLI) |

| | | |

| | +--> PAUTSUM0 (Summary Segment - GU/REPL/ISRT) |

| | +--> PAUTDTL1 (Detail Segment - ISRT) |

| | |

| +-- 8. Log Errors (EXEC CICS WRITEQ TD -> CSSL) |

+-----------------------------------------------------------------------+

Data Flow Description

• Triggering : An external system places a CSV-formatted authorization request on the MQ Request Queue. The CICS MQ Trigger Monitor (CKTI) detects the message and starts transaction CP00 , invoking program COPAUA0C .

• Initialization : The program retrieves trigger information using EXEC CICS RETRIEVE to identify the request queue name. It then opens the request queue.

• Message Consumption : The program reads the request message from the queue using MQGET .

• Parsing : The CSV payload is unstrung into the PENDING-AUTH-REQUEST structure.

• Validation & Database Lookup :

• Reads the CCXREF VSAM file to map the card number to an Account ID and Customer ID.

• Reads the ACCTDAT VSAM file to obtain the account status and credit limits.

• Reads the CUSTDAT VSAM file to verify customer details.

• Issues an IMS GU (Get Unique) call to retrieve the PAUTSUM0 segment for the account.

• Decision Processing : Compares the transaction amount against the available credit.

• Response Dispatch : Formats the decision into a CSV string and sends it to the MQ Reply Queue using MQPUT1 .

• Database Update : Updates the IMS PAUTSUM0 summary segment (using REPL or ISRT ) and inserts a new PAUTDTL1 detail segment (using ISRT ).

• Commit : Issues EXEC CICS SYNCPOINT to commit all VSAM, IMS, and MQ updates for the processed message.

User Navigation

There is no user navigation. The program runs entirely in the background, processing up to 500 messages per execution loop before terminating normally.

Validation Logic

The program performs several layers of validation and condition checks to determine if a transaction should be approved or declined:

Card Cross-Reference Validation :

• The incoming card number ( PA-RQ-CARD-NUM ) is used to search the CCXREF file.

• Condition Check : If the card is not found ( DFHRESP(NOTFND) ), the transaction is immediately declined with Response Code 05 and Reason Code 3100 (Card/Account/Customer Not Found).

Account Master Validation :

• The Account ID retrieved from the cross-reference is used to search the ACCTDAT file.

• Condition Check : If the account is not found, the transaction is declined with Response Code 05 and Reason Code 3100 .

Customer Master Validation :

• The Customer ID retrieved from the cross-reference is used to search the CUSTDAT file.

• Condition Check : If the customer is not found, the transaction is declined with Response Code 05 and Reason Code 3100 .

Credit Limit and Balance Validation :

• Scenario A: IMS Summary Segment Exists ( FOUND-PAUT-SMRY-SEG ) :

• Calculates available credit: Available Amount = PA-CREDIT-LIMIT - PA-CREDIT-BALANCE .

• Condition Check : If PA-RQ-TRANSACTION-AMT > Available Amount , the transaction is declined with Response Code 05 and Reason Code 4100 (Insufficient Funds).

• Scenario B: IMS Summary Segment Does Not Exist ( NFOUND-PAUT-SMRY-SEG ) :

• Falls back to the Account Master file.

• Calculates available credit: Available Amount = ACCT-CREDIT-LIMIT - ACCT-CURR-BAL .

• Condition Check : If PA-RQ-TRANSACTION-AMT > Available Amount , the transaction is declined with Response Code 05 and Reason Code 4100 .

• If the account master record is also missing, the transaction is declined.

Data Elements Processed

The following table lists the key data fields, amounts, and parameters used during message processing and database updates:

| Data Element | COBOL Picture | Source / Destination | Description |

| :--- | :--- | :--- | :--- |

| PA-RQ-CARD-NUM | PIC X(16) | MQ Request / CCXREF Key | Credit card number being authorized. |

| PA-RQ-TRANSACTION-AMT | PIC +9(10).99 | MQ Request (CSV) | Requested transaction amount. |

| XREF-ACCT-ID | PIC 9(11) | CCXREF Record | Account ID associated with the card. |

| XREF-CUST-ID | PIC 9(09) | CCXREF Record | Customer ID associated with the card. |

| ACCT-CREDIT-LIMIT | PIC S9(10)V99 | ACCTDAT Record | Total credit limit assigned to the account. |

| ACCT-CURR-BAL | PIC S9(10)V99 | ACCTDAT Record | Current outstanding balance on the account. |

| PA-CREDIT-LIMIT | PIC S9(09)V99 | IMS PAUTSUM0 Segment | Credit limit stored in the authorization summary. |

| PA-CREDIT-BALANCE | PIC S9(09)V99 | IMS PAUTSUM0 Segment | Current balance including pending authorizations. |

| PA-RL-AUTH-RESP-CODE | PIC X(02) | MQ Reply (CSV) | Approval status: 00 (Approved), 05 (Declined). |

| PA-RL-AUTH-RESP-REASON | PIC X(04) | MQ Reply (CSV) | Specific reason code for declines (e.g., 4100 ). |

| PA-RL-APPROVED-AMT | PIC +9(10).99 | MQ Reply (CSV) | The final approved amount (0 if declined). |

Exception and Error Handling

The program implements a robust error-handling mechanism that logs failures to the CICS Transient Data Queue CSSL and terminates processing gracefully on critical errors.

Error Logging Structure ( ERROR-LOG-RECORD )

When an error occurs, the program populates ERROR-LOG-RECORD with:

• Current Date and Time.

• Application ID ( CP00 ) and Program ID ( COPAUA0C ).

• Error Location (e.g., M001 for MQ Open, I001 for IMS Schedule, C001 for VSAM Read).

• Severity Level ( L = Log, I = Info, W = Warning, C = Critical).

• Subsystem ( A = App, C = CICS, I = IMS, M = MQ, F = File).

• Error Codes (CICS Response Codes, MQ Reason Codes, or IMS Status Codes).

• Error Message and Event Key (e.g., Card Number or Account ID).

Specific Exception Handling Logic

MQ Errors :

• MQGET No Message : If MQGET returns MQRC-NO-MSG-AVAILABLE (Reason Code 2033 ), it is treated as a normal end-of-queue condition. The program sets NO-MORE-MSG-AVAILABLE to true and exits the processing loop.

• Other MQ Failures : Any other failure during MQOPEN , MQGET , MQPUT1 , or MQCLOSE logs a critical error and triggers the emergency shutdown routine ( 9990-END-ROUTINE ).

VSAM Errors :

• Record Not Found ( DFHRESP(NOTFND) ) : Handled as a business exception. The program logs a warning (e.g., A001 for XREF not found), declines the transaction, and continues processing subsequent messages.

• Other VSAM Failures : Any unexpected CICS response code (e.g., LOCKED , IOERR ) is treated as a critical error, logging the response codes and triggering 9990-END-ROUTINE .

IMS Database Errors :

• PSB Schedule Failure : If the PSB cannot be scheduled, a critical error ( I001 ) is logged, and the program terminates.

• Segment Not Found ( GE ) : During a GU call on PAUTSUM0 , a GE status is handled gracefully by setting NFOUND-PAUT-SMRY-SEG to true, allowing the program to fall back to VSAM account data.

• Other IMS Failures : Any other status code during GU , REPL , or ISRT logs a critical error and terminates the program.

Emergency Shutdown ( 9990-END-ROUTINE ) :

• Terminates the IMS PSB schedule ( EXEC DLI TERM ).

• Closes the MQ Request Queue if it is currently open.

• Issues EXEC CICS RETURN to stop execution immediately, preventing further message processing.

Security and Authorization Checks

• No explicit security checks identified within the source code.

• System-Level Security : The program relies on external security managers (such as RACF) to secure CICS transaction CP00 and restrict access to the MQ queues ( WS-REQUEST-QNAME and WS-REPLY-QNAME ) and VSAM datasets.

Performance Considerations

• Batch Processing Limit : To prevent transaction timeouts, excessive CPU consumption, and long-held database locks, the program limits processing to a maximum of 500 messages ( WS-REQSTS-PROCESS-LIMIT ) per execution.

• MQ Wait Interval : The MQGET call uses a wait interval of 5000 milliseconds ( WS-WAIT-INTERVAL ). This allows the program to wait briefly for new messages before terminating when the queue becomes empty.

• Optimized Reply Mechanism : The program uses MQPUT1 to send response messages. MQPUT1 is highly efficient for single-message delivery because it combines open, put, and close operations into a single call.

• Message Expiry and Persistence : Reply messages are marked as non-persistent ( MQPER-NOT-PERSISTENT ) with a short expiry time of 50 seconds ( MQMD-EXPIRY = 50 ), reducing MQ overhead and preventing queue buildup.

• Unit of Work Commit ( SYNCPOINT ) : The program issues EXEC CICS SYNCPOINT after processing each individual message. This commits VSAM updates, IMS database inserts/replacements, and MQ messages, releasing database locks quickly and ensuring data consistency.

Important Constants

The following constants are defined in the program's Working-Storage Section:

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| WS-PGM-AUTH | 'COPAUA0C' | Program Identifier. |

| WS-CICS-TRANID | 'CP00' | CICS Transaction ID. |

| WS-CCXREF-FILE | 'CCXREF ' | Card Cross-Reference VSAM File Name. |

| WS-ACCTFILENAME | 'ACCTDAT ' | Account Master VSAM File Name. |

| WS-CUSTFILENAME | 'CUSTDAT ' | Customer Master VSAM File Name. |

| PSB-NAME | 'PSBPAUTB' | IMS PSB Name for Authorization Database. |

| WS-REQSTS-PROCESS-LIMIT | 500 | Maximum messages processed per execution run. |

| WS-WAIT-INTERVAL | 5000 | MQGET wait time in milliseconds (5 seconds). |

| PA-RL-AUTH-RESP-CODE | '00' / '05' | '00' = Approved, '05' = Declined. |

| PA-RL-AUTH-RESP-REASON | '0000' | Approved transaction reason code. |

| PA-RL-AUTH-RESP-REASON | '3100' | Decline: Card, Account, or Customer not found. |

| PA-RL-AUTH-RESP-REASON | '4100' | Decline: Insufficient Funds. |

<h2

Credit Card Pending Transaction Authorization Summary Viewer

The COPAUS0C program serves as an interactive summary dashboard within the CardDemo application, allowing customer service representatives and credit analysts to view pending transaction authorizations for a specific customer account. From a business perspective, this program is critical for real-time credit monitoring, risk management, and customer support. It provides a consolidated view of an account's credit status, including credit limits, cash limits, current balances, and the total count and amount of approved versus declined authorizations, helping the institution assess credit exposure and address cardholder inquiries promptly.

When a user enters a valid Account ID, the program retrieves and displays the account's financial profile alongside a list of recent pending authorization requests. The screen displays up to five authorization records at a time, showing essential transaction details such as the transaction ID, date, time, transaction type, approval status, and the requested amount. This immediate visibility allows analysts to quickly identify unusual activity, verify recent transaction attempts, and assist customers who may be experiencing issues with card declines at the point of sale.

To facilitate efficient navigation through large volumes of transactions, the program supports robust pagination. Users can scroll forward and backward through multiple pages of pending authorizations using standard function keys (PF7 for Page Up and PF8 for Page Down). The program dynamically tracks the database keys in a shared communication area to maintain the user's context across page boundaries. Furthermore, users can select any individual transaction from the summary list to drill down into its granular details, which automatically transfers control to the Authorization Detail module, or press PF3 to return to the main application menu.

Behind the scenes, the program coordinates complex data retrieval by integrating multiple data sources. It combines core customer demographics, card cross-references, and account balances stored in indexed files with real-time pending authorization records maintained in a hierarchical database. By consolidating this information into a single, cohesive screen, the program eliminates the need for users to navigate multiple systems, significantly improving operational efficiency and reducing response times during customer interactions.

Business Case and User Interaction

Business Case Overview

The COPAUS0C program is an interactive, screen-based CICS application within the CardDemo Authorization Module. Its primary business purpose is to provide a comprehensive summary view of pending transaction authorizations for a specific credit card account.

By aggregating account-level financial metrics (such as credit limits, cash limits, current balances, and approved/declined transaction counts and amounts) and listing individual pending authorization requests, this program enables customer service representatives and credit analysts to monitor account activity, verify pending charges, and identify potential credit or fraud issues in real time.

User Interaction and Screen Flow

Initial Entry :

• The user can access this screen directly or be routed from the CardDemo Main Menu ( COMEN01C ) with an Account ID already populated in the communication area.

• If entered with no prior context, the screen displays empty fields, prompting the user to input an Account ID.

Account Search :

• The user enters an 11-digit Account ID in the Search Acct Id field and presses ENTER .

• The program validates the input, retrieves the associated customer and account records from VSAM files, and queries the IMS database for pending authorization summaries and details.

• The screen is populated with customer demographics, account status, credit limits, balances, and a list of up to 5 pending authorizations.

Pagination :

• PF8 (Forward) : If more than 5 pending authorizations exist, the user presses PF8 to view the next page of transactions.

• PF7 (Backward) : The user presses PF7 to return to the previous page of transactions.

Detail Drill-Down :

• To view the granular details of a specific pending authorization, the user types 'S' (or 's' ) in the Sel column next to the desired transaction and presses ENTER .

• The program transfers control ( XCTL ) to the Authorization Detail program ( COPAUS1C ), passing the selected transaction's unique authorization key.

Exit :

• The user presses PF3 to exit the summary view and return to the Main Menu ( COMEN01C ).

Screen Layout and Navigation

Screen Layout (COPAU0A)

+-----------------------------------------------------------------------------+

| Tran: CPVS AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: COPAUS0C CardDemo Time: hh:mm:ss |

| |

| View Authorizations |

| |

| Search Acct Id: [ ] |

| |

| Name: [ ] Customer Id: [ ] |

| Acct Status: [ ] Addr Line 1: [ ]|

| Addr Line 2: [ ] |

| PH: [ ] Approval # : [ ] Decline #: [ ] |

| |

| Credit Lim: [ ] Cash Lim: [ ] Appr Amt: [ ]|

| Credit Bal: [ ] Cash Bal: [ ] Decl Amt: [ ]|

| |

| Sel Transaction ID Date Time Type A/D STS Amount |

| --- ---------------- -------- -------- ---- --- --- ------------ |

| [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] |

| [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] |

| [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] |

| [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] |

| [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] |

| |

| Type 'S' to View Authorization details from the list |

| <ERRMSG: Error or status messages appear here in red > |

| ENTER=Continue F3=Back F7=Backward F8=Forward |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+--------------------------------------------------+

| Main Menu (COMEN01C) |

+------------------------+-------------------------+

|

| (Select Option 11)

v

+--------------------------------------------------+

| Authorization Summary (COPAUS0C) | <---------+

+------------------------+-------------------------+ |

| |

+---------------------+---------------------+ |

| [PF3] | [ENTER] (Sel = 'S') | [PF7/PF8] | (PF3 / Back)

v v v |

+-----------------------+ +------------------+ +--------------+ |

| Main Menu (COMEN01C) | | Auth Details | | IMS Database | |

| | | (COPAUS1C) | | (Page Scroll)| ------+

+-----------------------+ +--------+---------+ +--------------+

|

+-----------------------------------+

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| WS-PGM-AUTH-SMRY | 'COPAUS0C' | Program ID of the Authorization Summary program |

| WS-PGM-AUTH-DTL | 'COPAUS1C' | Program ID of the Authorization Detail program |

| WS-PGM-MENU | 'COMEN01C' | Program ID of the Main Menu program |

| WS-CICS-TRANID | 'CPVS' | CICS Transaction ID associated with this program |

| PSB-NAME | 'PSBPAUTB' | IMS Program Specification Block (PSB) Name |

| PAUT-PCB-NUM | +1 | IMS PCB Offset number |

| WS-CARDXREFNAME-ACCT-PATH | 'CXACAIX ' | VSAM Alternate Index path for Card Cross-Reference |

| WS-ACCTFILENAME | 'ACCTDAT ' | VSAM Account Master File |

| WS-CUSTFILENAME | 'CUSTDAT ' | VSAM Customer Master File |

Validation Logic

Input Field Validations

• Account ID ( ACCTIDI ) :

• Must not be spaces or low-values. If empty, sets error: "Please enter Acct Id..." .

• Must be strictly numeric. If non-numeric, sets error: "Acct Id must be Numeric ..." .

• Row Selection ( SEL0001I to SEL0005I ) :

• Checked when the user presses ENTER .

• If a selection field is populated, it must be 'S' or 's' . Any other character triggers the error: "Invalid selection. Valid value is S" .

• Only one selection is processed at a time (evaluated sequentially from row 1 to 5).

Screen-Level Validations

• Attention Identifier (AID) Validation :

• ENTER : Triggers input validation, account data retrieval, and detail selection processing.

• PF3 : Triggers exit processing, returning the user to the Main Menu ( COMEN01C ).

• PF7 : Triggers backward pagination. Validates that the current page number is greater than 1. If already at page 1, displays: "You are already at the top of the page..." .

• PF8 : Triggers forward pagination. Verifies if more records exist. If no more records are available, displays: "You are already at the bottom of the page..." .

• Other Keys : Any other key triggers the error: "Invalid key pressed. Please see below..." .

Condition Checks

• IMS Status Code Checks :

• Evaluates DIBSTAT after every database call.

• ' ' or 'FW' indicates successful execution ( STATUS-OK ).

• 'GE' or 'GB' indicates segment not found or end of database ( AUTHS-EOF ).

• VSAM Response Checks :

• Evaluates WS-RESP-CD after VSAM reads.

• DFHRESP(NORMAL) indicates successful read.

• DFHRESP(NOTFND) triggers a specific "not found" error message on the screen.

Data Elements Processed

Screen and Commarea Fields

• CDEMO-ACCT-ID / WS-ACCT-ID : 11-digit Account ID used as the primary search key.

• CDEMO-CPVS-PAU-SEL-FLG : Selection flag passed to the detail program ( 'S' ).

• CDEMO-CPVS-PAU-SELECTED : The unique 8-character authorization key of the selected transaction.

• CDEMO-CPVS-PAGE-NUM : Current page number for pagination tracking.

• CDEMO-CPVS-PAUKEY-PREV-PG : Occurs 20 times; stores the starting authorization keys of previous pages for backward scrolling.

• CDEMO-CPVS-PAUKEY-LAST : Stores the last authorization key processed on the current page.

VSAM Record Fields

• CARD-XREF-RECORD (Read via Alternate Index CXACAIX using Account ID):

• XREF-CUST-ID : Customer ID associated with the account.

• XREF-CARD-NUM : Card number associated with the account.

• ACCOUNT-RECORD (Read from ACCTDAT using Account ID):

• ACCT-CREDIT-LIMIT : Total credit limit.

• ACCT-CASH-CREDIT-LIMIT : Cash advance limit.

• CUSTOMER-RECORD (Read from CUSTDAT using Customer ID):

• CUST-FIRST-NAME , CUST-MIDDLE-NAME , CUST-LAST-NAME : Formatted into the screen name field.

• CUST-ADDR-LINE-1 , CUST-ADDR-LINE-2 , CUST-ADDR-LINE-3 , CUST-ADDR-STATE-CD , CUST-ADDR-ZIP : Formatted into screen address fields.

• CUST-PHONE-NUM-1 : Customer phone number.

IMS Database Segment Fields

• PENDING-AUTH-SUMMARY (Root Segment PAUTSUM0 ):

• PA-ACCT-ID : Account ID key.

• PA-APPROVED-AUTH-CNT / PA-DECLINED-AUTH-CNT : Counts of approved/declined authorizations.

• PA-APPROVED-AUTH-AMT / PA-DECLINED-AUTH-AMT : Total amounts of approved/declined authorizations.

• PA-CREDIT-BALANCE / PA-CASH-BALANCE : Current credit and cash balances.

• PENDING-AUTH-DETAILS (Child Segment PAUTDTL1 ):

• PA-AUTHORIZATION-KEY : Composite key containing packed date and time.

• PA-TRANSACTION-ID : Unique transaction identifier.

• PA-AUTH-ORIG-DATE / PA-AUTH-ORIG-TIME : Transaction timestamp.

• PA-AUTH-TYPE : Transaction type (e.g., Purchase, Cash).

• PA-AUTH-RESP-CODE : Response code ( '00' = Approved, others = Declined).

• PA-MATCH-STATUS : Match status code.

• PA-APPROVED-AMT : Transaction amount.

Exception and Error Handling

VSAM File Read Exceptions

The program explicitly captures response codes ( RESP and RESP2 ) for all VSAM operations:

• DFHRESP(NOTFND) :

• If the account is not found in the Cross-Reference file: "Account: [ID] not found in XREF file. Resp: [code] Reas: [code]"

• If the account is not found in the Account Master file: "Account: [ID] not found in ACCT file. Resp: [code] Reas: [code]"

• If the customer is not found in the Customer Master file: "Customer: [ID] not found in CUST file. Resp: [code] Reas: [code]"

• Other VSAM Errors :

• Displays a system error message: "Account/Customer: [ID] System error while reading [FILE] file. Resp: [code] Reas: [code]"

IMS Database Exceptions

The program evaluates the DIBSTAT field after every DLI call:

• PSB Scheduling Failure : If scheduling the PSB ( PSBPAUTB ) fails, the program displays: " System error while scheduling PSB: Code: [DIBSTAT]"

• Summary Segment Read Failure : If reading the PAUTSUM0 segment fails with an unexpected status code, displays: " System error while reading AUTH Summary: Code: [DIBSTAT]"

• Detail Segment Read/Reposition Failure : If reading or repositioning on the PAUTDTL1 segment fails, displays: " System error while reading/repos. AUTH Details: Code: [DIBSTAT]"

CICS Command Failures

• The program uses explicit response checking ( RESP and RESP2 ) on all CICS commands (such as RECEIVE MAP ) to prevent transaction abends and ensure graceful recovery.

Security and Authorization Checks

• No explicit security checks identified within the program code.

• The program does not perform direct RACF checks, transaction security validations, or sign-on checks.

• It relies entirely on the security context of the calling transaction ( CPVS ) and the CICS region configuration to restrict unauthorized access to the authorization summary functionality.

Performance Considerations

Pseudo-Conversational Design :

• The program is designed to be pseudo-conversational. It does not remain active in memory while waiting for user input.

• After sending the map, it issues an EXEC CICS RETURN specifying the transaction ID CPVS and passing the CARDDEMO-COMMAREA . This releases CICS resources and maximizes concurrent user capacity.

Dynamic PSB Scheduling :

• The program dynamically schedules the PSB ( PSBPAUTB ) using EXEC DLI SCHD only when database access is required.

• It releases database locks promptly by performing a syncpoint ( EXEC CICS SYNCPOINT ) before sending the screen to the user terminal, ensuring high concurrency.

Alternate Index (AIX) Path Usage :

• The program utilizes the alternate index path CXACAIX to read the Card Cross-Reference file by Account ID. This allows direct, high-performance key access and avoids costly sequential file scans.

Efficient Pagination :

• To support backward scrolling (PF7) without re-scanning the database from the beginning, the program stores the starting authorization keys of previously visited pages in an array ( CDEMO-CPVS-PAUKEY-PREV-PG ) within the COMMAREA .

• When paging forward (PF8) or backward (PF7), the program uses these saved keys to perform qualified direct reads ( WHERE (PAUT9CTS = PA-AUTHORIZATION-KEY) ) to reposition the database cursor instantly.

<h2

Credit Card Transaction Authorization Detail and Fraud Management System

This program serves as an interactive customer service and fraud analysis tool within the CardDemo application, providing a comprehensive, detailed view of individual credit card transaction authorizations. Operating within a CICS environment, it allows financial analysts and customer service representatives to inspect the exact status and technical details of pending or processed transaction requests. By presenting a clear breakdown of transaction parameters, the program helps the institution resolve cardholder inquiries, audit transaction histories, and maintain operational security.

The program retrieves transaction data from an IMS database, combining account-level summaries with specific transaction details. It formats and displays critical information on the user's terminal, including the card number, transaction timestamp, requested and approved amounts, and merchant details such as name, ID, and location. To facilitate quick decision-making, the program automatically translates technical response codes into human-readable descriptions, clearly indicating whether a transaction was approved or declined, and specifying the exact reason for any decline, such as insufficient funds, an inactive card, or suspected fraud.

A core business capability of this program is its direct integration with fraud mitigation workflows. From the detail screen, an authorized user can instantly flag a transaction as fraudulent or reverse a previous fraud designation. When this action is triggered, the program coordinates with a specialized backend fraud management service to update the central database, modifies the local transaction record, and utilizes strict transactional control protocols (commit and rollback) to ensure that database updates are processed reliably and securely.

To optimize the analyst's workflow, the program supports intuitive screen navigation and paging controls. Users can easily return to the primary authorization summary list or page forward to inspect the next sequential authorization record associated with the active account. This seamless navigation allows fraud analysts to rapidly review multiple disputed charges in sequence, significantly reducing investigation times and improving overall operational efficiency.

Business Case and User Interaction

Business Case

The COPAUS1C program is an interactive, screen-based CICS application within the CardDemo Authorization Module. Its primary business purpose is to provide a detailed, read-only view of a specific pending transaction authorization. It also allows authorized users (such as fraud analysts or customer service representatives) to perform two key operational tasks:

• Fraud Tagging : Toggle the fraud status of a transaction (marking it as fraudulent or removing a previous fraud flag).

• Sequential Browsing : Page through subsequent authorization records for the same account sequentially.

By providing granular transaction details (including merchant information, point-of-sale entry modes, and response codes) and integrating with the fraud management system, this program helps financial institutions investigate disputed charges, mitigate fraud losses, and maintain cardholder security.

User Interaction and Screen Flow

+---------------------------------------+

| COPAUS0C |

| (Authorization Summary) |

+-------------------+-------------------+

|

| Selects an Auth

v

+---------------------------------------------------------------------------+

| COPAU1A |

| (View Authorization Details) |

+-------------------------------------+-------------------------------------+

|

+------------------------+------------------------+

| (PF3) | (PF5) | (PF8)

v v v

+------------+------------+ +--------+--------+ +------------+------------+

| COPAUS0C | | COPAUS2C | | IMS Database |

| (Authorization Summary) | | (Fraud Service) | | (Read Next Auth Record) |

+-------------------------+ +-----------------+ +-------------------------+

Screen Navigation and Flow

• Entry : The user arrives at the COPAU1A screen from the Authorization Summary screen ( COPAUS0C ) after selecting a specific authorization record.

• Viewing Details : The program retrieves the authorization summary and detail records from the IMS database and populates the screen fields.

• PF3 (Back) : Returns the user to the Authorization Summary screen ( COPAUS0C ).

• PF5 (Mark/Remove Fraud) : Toggles the fraud status of the current transaction. It calls the backend program COPAUS2C via a CICS LINK to update the central fraud database, updates the local IMS segment, and refreshes the screen with a confirmation message.

• PF8 (Next Auth) : Retrieves and displays the next sequential authorization detail record for the current account. If the user is already at the last record, an informational message is displayed.

Important Constants

| Constant Value | Field / Variable | Description |

| :--- | :--- | :--- |

| 'COPAUS1C' | WS-PGM-AUTH-DTL | Current Program Identifier |

| 'COPAUS0C' | WS-PGM-AUTH-SMRY | Target Summary Program Identifier |

| 'COPAUS2C' | WS-PGM-AUTH-FRAUD | Backend Fraud Management Program |

| 'CPVD' | WS-CICS-TRANID | CICS Transaction ID |

| 'PSBPAUTB' | PSB-NAME | IMS Program Specification Block (PSB) Name |

| +1 | PAUT-PCB-NUM | IMS PCB Offset |

| '00' | PA-AUTH-APPROVED | Response code indicating an approved transaction |

| 'F' | WS-REPORT-FRAUD | Action code to report/flag a transaction as fraud |

| 'R' | WS-REMOVE-FRAUD | Action code to remove/clear a fraud flag |

| 'S' | WS-FRD-UPDT-SUCCESS | Status indicating successful fraud database update |

| 'F' | WS-FRD-UPDT-FAILED | Status indicating failed fraud database update |

Validation Logic

The program performs several critical validations and condition checks during execution:

Input Parameter Validation :

• Verifies that the Account ID ( CDEMO-ACCT-ID ) passed in the communication area is numeric.

• Verifies that the selected Authorization Key ( CDEMO-CPVD-PAU-SELECTED ) is not spaces or low-values.

• If either check fails, the error flag is set ( WS-ERR-FLG = 'Y' ) and details are not populated.

Response Code Formatting :

• Evaluates the authorization response code ( PA-AUTH-RESP-CODE ).

• If the code is '00' (Approved), the screen field AUTHRSPO is set to 'A' and colored green ( DFHGREEN ).

• For any other code (Declined), AUTHRSPO is set to 'D' and colored red ( DFHRED ).

Decline Reason Lookup :

• Performs a binary/sequential search ( SEARCH ALL ) on the internal decline reason table ( WS-DECLINE-REASON-TAB ) using the response reason code ( PA-AUTH-RESP-REASON ).

• If found, it populates the screen with the code and its description (e.g., 4100-INSUFFICNT FUND ).

• If not found, it defaults the screen display to 9999-ERROR .

Fraud Status Toggle Logic :

• Evaluates the current fraud status of the record ( PA-FRAUD-CONFIRMED ).

• If the transaction is already flagged as fraud, it sets the action to remove the flag ( 'R' ).

• If the transaction is not flagged, it sets the action to report the fraud ( 'F' ).

End-of-Database Check :

• During sequential browsing (PF8), the program checks the IMS status code ( DIBSTAT ). If it receives 'GE' (Segment Not Found) or 'GB' (End of Database), it sets the end-of-file flag ( AUTHS-EOF ) and displays an informational message to the user.

Data Elements Processed

The program processes the following key data elements during screen interactions and database operations:

Screen and Commarea Fields

• CDEMO-ACCT-ID / WS-ACCT-ID : Account ID (11-digit numeric).

• CDEMO-CPVD-PAU-SELECTED / WS-AUTH-KEY : Selected Authorization Key (8-character alphanumeric).

• CARDNUMO : Credit Card Number displayed on screen (16 characters).

• AUTHDTO / AUTHTMO : Formatted Authorization Date (MM/DD/YY) and Time (HH:MM:SS).

• AUTHAMTO : Formatted Authorization Amount (edited numeric -zzzzzzz9.99 ).

• AUTHRSPO / AUTHRSNO : Authorization Response Status (A/D) and Reason Description.

• AUTHFRDO : Fraud Status and Report Date displayed on screen (e.g., F-YYYYMMDD ).

IMS Database Segment Fields (Pending Authorizations)

• PA-ACCT-ID : Account ID key.

• PA-AUTHORIZATION-KEY : Composite key containing packed date and time.

• PA-CARD-NUM : Card number associated with the authorization.

• PA-TRANSACTION-AMT / PA-APPROVED-AMT : Transaction and approved amounts.

• PA-MATCH-STATUS : Match status flag ( P = Pending, D = Declined, E = Expired, M = Matched).

• PA-AUTH-FRAUD : Fraud status flag ( F = Confirmed, R = Removed).

• PA-FRAUD-RPT-DATE : Date the fraud status was updated.

• Merchant Details : Name, ID, City, State, and Zip code of the merchant.

Exception and Error Handling

IMS Database Exception Handling

The program evaluates the IMS status code ( DIBSTAT ) after every database call:

• STATUS-OK ( ' ' , 'FW' ) : Execution continues normally.

• SEGMENT-NOT-FOUND ( 'GE' ) / END-OF-DB ( 'GB' ) : Handled as a standard business condition (sets EOF flag).

• Other Database Errors : Sets the error flag, formats a descriptive error message containing the specific IMS status code, and displays it in the screen's error message field ( ERRMSGO ):

• Example : " System error while reading Auth Summary: Code: [DIBSTAT]"

• Example : " System error while reading Auth Details: Code: [DIBSTAT]"

CICS Link and Transaction Recovery

• CICS LINK Failures : When linking to COPAUS2C via EXEC CICS LINK , the program uses the NOHANDLE option. If the link fails (i.e., EIBRESP is not NORMAL ), the program executes a rollback ( EXEC CICS SYNCPOINT ROLLBACK ) to ensure database integrity.

• Fraud Update Failures : If the backend program COPAUS2C returns a failed update status ( WS-FRD-UPDT-FAILED ), the program displays the returned error message ( WS-FRD-ACT-MSG ) and performs a rollback.

• IMS Update Failures : If the REPL call to update the IMS segment fails, the program performs a rollback and displays:

• " System error while FRAUD Tagging, ROLLBACK||[DIBSTAT]"

User Input Errors

• Invalid Keys : If the user presses an unsupported key, the program retains the current screen data, sets the cursor, and displays:

• "Invalid key pressed. Please see below... "

Security and Authorization Checks

• No explicit security checks identified within the program code.

• The program does not perform direct RACF checks, transaction security validations, or sign-on checks.

• It relies entirely on the security context of the calling transaction ( CPVD ) and the CICS region configuration to restrict unauthorized access to the authorization detail and fraud tagging functionalities.

Performance Considerations

Dynamic PSB Scheduling :

• The program dynamically schedules the PSB ( PSBPAUTB ) using EXEC DLI SCHD only when database access is required.

• If the PSB is already scheduled, it terminates and reschedules it to prevent conflicts.

• It releases database locks promptly by performing a syncpoint ( EXEC CICS SYNCPOINT ) after completing read or update operations.

Efficient Sequential Browsing :

• For the "Next Auth" function (PF8), the program utilizes an unqualified EXEC DLI GNP (Get Next in Parent) call.

• Because the parent segment ( PAUTSUM0 ) is already established during the initial read, the database engine can rapidly retrieve the next child segment ( PAUTDTL1 ) sequentially without the overhead of re-evaluating fully qualified search arguments.

Transaction Integrity :

• Explicit use of EXEC CICS SYNCPOINT and EXEC CICS SYNCPOINT ROLLBACK ensures that database locks are held for the shortest time possible, minimizing database contention in high-concurrency environments.

<h2

CardDemo Credit Card Authorization Fraud Management Program

The primary business purpose of this program is to manage and record fraudulent activity associated with credit card transaction authorizations within the CardDemo application. It serves as a backend service that processes requests to either flag a transaction as fraudulent or reverse a previous fraud designation. By maintaining an accurate registry of disputed transactions, the program helps the financial institution mitigate risk, protect cardholders, and maintain security standards.

Upon receiving a request, the program extracts comprehensive transaction details, including the account and customer identifiers, card number, transaction amounts, and merchant information. It performs necessary date and time conversions to reconstruct the exact timestamp of the original authorization. This ensures that the transaction can be uniquely identified and accurately recorded in the database, with the current system date marked as the fraud reporting date.

The program first attempts to register the transaction as a new entry in the central fraud tracking database. If the transaction has not been flagged before, a new record is created containing all the relevant transaction details, the merchant's location and identity, and the specified fraud status. This automated entry streamlines the auditing process for disputed charges.

In cases where the transaction has already been registered in the database, the program automatically detects the duplicate entry and switches to an update mode. Instead of failing, it modifies the existing record to reflect the updated fraud status—such as confirming or removing the fraud flag—and refreshes the reporting date to the current date. Once the database operation is complete, the program returns a success or error message to the calling system, ensuring seamless integration with the user interface.

Business Case and User Interaction

Business Case

The COPAUS2C program is a backend service within the CardDemo Authorization Module. Its primary business function is to manage the fraud status of credit card transactions. It allows the system to either flag a pending transaction as fraudulent ('F') or clear/remove a fraud flag ('R').

This program acts as an "Upsert" (Update or Insert) service for the CARDDEMO.AUTHFRDS DB2 table. When a fraud analyst or customer service representative interacts with a front-end screen to report or resolve fraud, the front-end application calls COPAUS2C via a CICS LINK or XCTL passing the transaction details. COPAUS2C then:

• Attempts to insert a new fraud record into the database.

• If the record already exists (indicated by a duplicate key SQL error), it updates the existing record with the new fraud status and reporting date.

User Interaction and Screen Flow

COPAUS2C is a non-interactive, program-to-program (backend) CICS program . It does not directly send or receive BMS maps (screens) to an end-user terminal. Instead, it is invoked by a parent UI program (such as an Authorization Inquiry or Fraud Management screen) which handles the user interface.

Screen and User Interaction Diagram

+-----------------------------------------------------------------------+

| Calling Program (UI) |

| (e.g., Fraud Management / Auth Inquiry Screen) |

+-----------------------------------+-----------------------------------+

|

CICS LINK with DFHCOMMAREA Data

v

+-----------------------------------------------------------------------+

| COPAUS2C |

| (Fraud Status Update Service) |

+-----------------------------------+-----------------------------------+

|

1. Attempt SQL INSERT

|

+--------------+--------------+

| |

[SQLCODE = 0] [SQLCODE = -803]

| (Duplicate Key)

| |

| v

| 2. Attempt SQL UPDATE

| |

| +------+------+

| | |

| [SQLCODE=0] [SQLCODE!=0]

v v v

(Add Success) (Updt Success) (Updt Error)

| | |

+--------------+-------+-------------+

|

Return Status & Message in COMMAREA

v

+-----------------------------------------------------------------------+

| Calling Program (UI) |

| (Displays Success/Error Message to the User) |

+-----------------------------------------------------------------------+

Data Flow Between Screens

• Input Flow : The calling program populates the DFHCOMMAREA with the account ID, customer ID, transaction details (from the IMS pending authorization segment), and the requested action ( WS-FRD-ACTION set to 'F' or 'R').

• Processing : COPAUS2C processes the request, interacts with the DB2 database, and updates the status fields in the DFHCOMMAREA ( WS-FRD-UPDATE-STATUS and WS-FRD-ACT-MSG ).

• Output Flow : COPAUS2C returns control to the calling program. The calling program reads the returned status and message from the DFHCOMMAREA and displays a success or error message to the user on the terminal screen.

User Navigation

• The user does not navigate directly to or from COPAUS2C .

• Navigation is controlled entirely by the calling program. Once COPAUS2C completes its execution, it issues an EXEC CICS RETURN to hand control back to the calling program, which remains on the active user screen.

Important Constants

| Constant Value | Field / Variable | Description |

| :--- | :--- | :--- |

| 'COPAUS2C' | WS-PGMNAME | Program Identifier |

| 'F' | WS-REPORT-FRAUD / WS-FRD-ACTION | Action code to report/flag a transaction as fraud |

| 'R' | WS-REMOVE-FRAUD / WS-FRD-ACTION | Action code to remove/clear a fraud flag |

| 'S' | WS-FRD-UPDT-SUCCESS | Status indicating the database operation succeeded |

| 'F' | WS-FRD-UPDT-FAILED | Status indicating the database operation failed |

| 'ADD SUCCESS' | WS-FRD-ACT-MSG | Message returned when a new fraud record is successfully inserted |

| 'UPDT SUCCESS' | WS-FRD-ACT-MSG | Message returned when an existing fraud record is successfully updated |

| 0 | SQLCODE | SQL execution successful |

| -803 | SQLCODE | SQL duplicate key error (Unique Constraint Violation) |

Validation Logic

Because COPAUS2C is a backend service, it assumes that basic data format validations have been performed by the calling program. However, it performs several critical data transformations and conditional checks:

Action Code Validation :

• Evaluates WS-FRD-ACTION to determine whether to flag the transaction as fraud ( 'F' ) or remove the flag ( 'R' ).

Timestamp Reconstruction :

• The program reconstructs the original transaction timestamp ( WS-AUTH-TS ) from the IMS segment fields:

• Extracts Year ( WS-AUTH-YY ), Month ( WS-AUTH-MM ), and Day ( WS-AUTH-DD ) from PA-AUTH-ORIG-DATE .

• Decodes the inverted time key: WS-AUTH-TIME = 999999999 - PA-AUTH-TIME-9C .

• Extracts Hours ( WS-AUTH-HH ), Minutes ( WS-AUTH-MI ), Seconds ( WS-AUTH-SS ), and Milliseconds ( WS-AUTH-SSS ) from the decoded time.

• This reconstructed timestamp is validated and formatted into a DB2-compatible timestamp using the DB2 TIMESTAMP_FORMAT function: 'YY-MM-DD HH24.MI.SSNNNNNN' .

Database Write Validation (Upsert Logic) :

• Insert Check : The program first attempts to insert the record. If SQLCODE = 0 , the write is valid and complete.

• Duplicate Key Check : If SQLCODE = -803 , the program detects that the record already exists and branches to the FRAUD-UPDATE paragraph to perform an update instead.

• Update Check : In the update paragraph, it verifies that SQLCODE = 0 to confirm the update succeeded.

Data Elements Processed

The following key data elements are passed via the DFHCOMMAREA and processed by the program:

Input Elements (from Calling Program)

• WS-ACCT-ID : Account ID (11-digit numeric).

• WS-CUST-ID : Customer ID (9-digit numeric).

• PA-CARD-NUM : Credit card number (16-character alphanumeric).

• PA-AUTH-ORIG-DATE : Original authorization date (6-character YYMMDD).

• PA-AUTH-TIME-9C : Inverted authorization time (9-digit packed decimal).

• PA-AUTH-TYPE : Type of authorization (4-character alphanumeric).

• PA-CARD-EXPIRY-DATE : Card expiration date (4-character alphanumeric).

• PA-TRANSACTION-AMT : Transaction amount (packed decimal with 2 decimal places).

• PA-APPROVED-AMT : Approved transaction amount (packed decimal with 2 decimal places).

• PA-MERCHANT-ID : Merchant identifier (15-character alphanumeric).

• PA-MERCHANT-NAME : Merchant name (22-character alphanumeric).

• WS-FRD-ACTION : Requested action ('F' = Report Fraud, 'R' = Remove Fraud).

Output Elements (Returned to Calling Program)

• PA-FRAUD-RPT-DATE : Date the fraud was reported (8-character formatted date).

• WS-FRD-UPDATE-STATUS : Status of the update operation ('S' = Success, 'F' = Failed).

• WS-FRD-ACT-MSG : Descriptive result message (up to 50 characters) containing success confirmation or detailed DB2 error codes.

Exception and Error Handling

COPAUS2C implements robust error handling to prevent transaction abends and return meaningful diagnostics to the calling program:

CICS Command Exception Handling :

• The EXEC CICS ASKTIME and EXEC CICS FORMATTIME commands utilize the NOHANDLE option. This ensures that if a CICS-level exception occurs during time retrieval or formatting, the program will not abend and will continue execution.

DB2 SQL Exception Handling :

• Duplicate Key ( SQLCODE = -803 ) : This is handled as a normal business exception. The program automatically recovers by executing the FRAUD-UPDATE paragraph.

• Other SQL Errors : If any other database error occurs during INSERT or UPDATE (e.g., connection loss, table locked, resource unavailable):

• The update status is set to failed: SET WS-FRD-UPDT-FAILED TO TRUE (sets WS-FRD-UPDATE-STATUS to 'F' ).

• The program captures the specific SQLCODE and SQLSTATE .

• A formatted error message is constructed and returned in WS-FRD-ACT-MSG :

• For Insert Errors: ' SYSTEM ERROR DB2: CODE:[SQLCODE], STATE: [SQLSTATE]'

• For Update Errors: ' UPDT ERROR DB2: CODE:[SQLCODE], STATE: [SQLSTATE]'

Security and Authorization Checks

• No explicit security checks identified within this program.

• COPAUS2C does not perform any direct RACF checks, transaction security validations, or sign-on checks (CESN/CESF).

• It relies entirely on the security context of the calling transaction/program and the CICS region configuration to restrict unauthorized access to the fraud management functionality.

Performance Considerations

Upsert Pattern Efficiency :

• The program uses an "Insert-else-Update" pattern. This is highly efficient if the majority of transactions processed are being flagged for fraud for the first time (resulting in a successful insert on the first try). If most transactions are updates, an "Update-else-Insert" pattern would be more performant to avoid the overhead of handling -803 SQL exceptions.

Timestamp Inversion :

• The calculation 999999999 - PA-AUTH-TIME-9C is a classic mainframe performance design pattern. Inverting the timestamp allows database indexes (especially in legacy IMS or DB2 structures) to store the most recent transactions at the beginning of the index, optimizing retrieval times for recent activity.

Use of NOHANDLE :

• Using NOHANDLE on CICS system calls avoids the overhead of CICS establishing and tearing down condition-handling blocks.

<h2

Online Transaction Report Submission Gateway

The CORPT00C program serves as an online gateway within the CardDemo application, enabling business users to initiate the generation and printing of comprehensive transaction reports. Instead of running resource-intensive report generation directly within the interactive online session, this program bridges the gap between the user interface and the system's background processing capabilities. It allows users to request reports on demand, which are then queued and processed efficiently in the background without degrading online system performance.

Through an intuitive interactive screen, users can choose from three distinct reporting periods: Monthly, Yearly, or a Custom date range. Selecting a Monthly or Yearly report automatically calculates the appropriate start and end dates based on the current system date. For more targeted analysis, the Custom option allows users to manually input specific start and end dates, providing the flexibility needed to audit transactions for precise, user-defined timeframes.

To ensure data integrity and prevent downstream processing errors, the program performs rigorous validation on all user inputs. When a custom date range is specified, the system verifies that the entered months, days, and years are numeric and represent valid calendar dates. Once the inputs are validated, the program requires an explicit confirmation from the user before proceeding, safeguarding against accidental or duplicate report submissions.

Upon receiving user confirmation, the program dynamically prepares a background job script. It injects the selected date parameters into a predefined job template and writes this payload to a specialized system queue that acts as an internal reader. This action triggers a background batch job to compile and print the transaction report, allowing the online user to immediately return to other tasks while the system handles the heavy lifting.

Seamlessly integrated into the CardDemo ecosystem, the program maintains user session context and security roles throughout the interaction. Users can easily navigate back to the main application menu once a report is submitted, or exit directly to the sign-on screen. This design ensures a smooth, responsive user experience that optimizes system resources and supports high volumes of concurrent business activity.

Business Case and User Interaction

Business Case Overview

The CORPT00C program is an online CICS COBOL application within the CardDemo system that allows authorized users to request and print transaction reports. To prevent long-running, resource-intensive reporting queries from blocking the online CICS region, the program offloads the report generation to an asynchronous batch job.

When a user requests a report, the program dynamically constructs a Job Control Language (JCL) stream in memory, injects user-specified date parameters, and submits the JCL to the JES spool via an extra-partition Transient Data Queue (TDQ) named JOBS (which is mapped to the JES internal reader). This design ensures a highly responsive online user experience while leveraging the mainframe's batch processing capabilities for heavy data retrieval.

The program supports three reporting options:

• Monthly Report : Automatically calculates and submits a report for the current calendar month (from the 1st day to the last day of the current month).

• Yearly Report : Automatically calculates and submits a report for the current calendar year (from January 1st to December 31st).

• Custom Report : Allows the user to input a specific start and end date range, which is validated online before job submission.

User Interaction and Screen Flow

• Menu Entry : The user navigates to the Transaction Reports screen from the CardDemo Main Menu ( COMEN01C ) by selecting Option 9.

• Screen Presentation : The program displays the CORPT0A map. The header displays system metadata (Transaction ID CR00 , Program ID CORPT00C , current date, and current time). The selection fields for Monthly, Yearly, and Custom reports are displayed as empty input fields.

• Report Selection :

• Monthly/Yearly : The user types any non-space character in the selection field next to "Monthly" or "Yearly" and presses ENTER .

• Custom : The user types any non-space character in the selection field next to "Custom", enters the Start Date ( MM/DD/YYYY ) and End Date ( MM/DD/YYYY ) in the designated input fields, and presses ENTER .

• Confirmation : Before submitting the job, the program prompts the user for confirmation by displaying a message: Please confirm to print the [Report Type] report... . The cursor is positioned on the confirmation field.

• The user must enter Y or y to confirm, or N or n to cancel.

• Submission & Feedback :

• If confirmed, the JCL is written to the JOBS TDQ, and a green success message is displayed: [Report Type] report submitted for printing ... .

• If cancelled, the input fields are cleared, and the screen is reset.

• Exit : The user can press PF3 at any time to exit the screen and return to the Main Menu ( COMEN01C ).

Screen Layout and Navigation

Screen Layout (CORPT0A)

+-----------------------------------------------------------------------------+

| Tran: CR00 AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: CORPT00C CardDemo Time: hh:mm:ss |

| |

| Transaction Reports |

| |

| [ ] Monthly (Current Month) |

| |

| [ ] Yearly (Current Year) |

| |

| [ ] Custom (Date Range) |

| |

| Start Date : [ ] / [ ] / [ ] (MM/DD/YYYY) |

| End Date : [ ] / [ ] / [ ] (MM/DD/YYYY) |

| |

| |

| The Report will be submitted for printing. Please confirm: [ ] (Y/N) |

| |

| <ERRMSG: Error or status messages appear here in red/green > |

| |

| ENTER=Continue F3=Back |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+--------------------------------------------------+

| Main Menu Screen |

| (COMEN01C) |

+-----------------------+--------------------------+

|

| (Select Option 9)

v

+--------------------------------------------------+

| Transaction Reports Screen | <----------------+

| (CORPT00C) | |

+-----------------------+--------------------------+ |

| |

+------------------+------------------+ |

| [PF3] | [ENTER] (Valid Input) | (Re-display /

v v | Error / Cancel)

+-----------------------+ +------------------+ |

| Main Menu Screen | | Prompt Confirm | ----------------+

| (COMEN01C) | | (Y/N Field) |

+-----------------------+ +--------+---------+

|

| (Confirm = 'Y')

v

[Write JCL to TDQ]

|

v

[Submit Batch Job]

Data Flow Between Screens

• COMEN01C to CORPT00C : Preserves the user session context by passing the CARDDEMO-COMMAREA via the CICS COMMAREA .

• CORPT00C to CSUTLDTC : Passes the formatted date string ( YYYY-MM-DD ) and the format mask ( YYYY-MM-DD ) to the date utility program to validate calendar integrity.

• CORPT00C to COMEN01C : Returns control to the main menu when the user presses PF3 , passing back the updated CARDDEMO-COMMAREA .

• CORPT00C to COSGN00C : If the program is initiated directly without an active session ( EIBCALEN = 0 ), it automatically redirects the user to the Sign-on screen.

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| WS-PGMNAME | 'CORPT00C' | Program identifier |

| WS-TRANID | 'CR00' | CICS Transaction ID associated with this program |

| WS-TRANSACT-FILE | 'TRANSACT' | Transaction file identifier |

| WS-DATE-FORMAT | 'YYYY-MM-DD' | Standard date format mask used for validation |

| JOBS | 'JOBS' | Extra-partition Transient Data Queue (TDQ) name for job submission |

| CCDA-TITLE01 | ' AWS Mainframe Modernization ' | Screen Header Title Line 1 |

| CCDA-TITLE02 | ' CardDemo ' | Screen Header Title Line 2 |

| CCDA-MSG-INVALID-KEY | 'Invalid key pressed. Please see below... ' | Error message for unsupported AID keys |

Validation Logic

Input Field Validations

• Report Type Selection :

• The user must select exactly one report type (Monthly, Yearly, or Custom) by entering a non-space character in the corresponding selection field ( MONTHLYI , YEARLYI , or CUSTOMI ).

• If no report type is selected, the program displays: Select a report type to print report... .

• Custom Date Fields :

• If the Custom report is selected, the program ensures that none of the start date ( SDTMMI , SDTDDI , SDTYYYYI ) or end date ( EDTMMI , EDTDDI , EDTYYYYI ) fields are empty or contain low-values.

• If any field is empty, a targeted error message is displayed (e.g., Start Date - Month can NOT be empty... ), and the cursor is positioned on the missing field.

• Numeric and Range Checks :

• Date inputs are converted to numeric values using FUNCTION NUMVAL-C .

• Month fields must be numeric and less than or equal to 12 .

• Day fields must be numeric and less than or equal to 31 .

• Year fields must be strictly numeric.

• If any check fails, a descriptive error is displayed (e.g., Start Date - Not a valid Month... ).

• Calendar Integrity Validation :

• The program formats the input dates into YYYY-MM-DD and calls the utility program CSUTLDTC to perform calendar validation (e.g., checking for leap years and correct days per month).

• If CSUTLDTC returns a severity code other than '0000' (excluding warning code '2513' ), the program rejects the input and displays: Start Date - Not a valid date... or End Date - Not a valid date... .

• Confirmation Validation :

• The confirmation field ( CONFIRMI ) must contain Y , y , N , or n .

• If empty, the program prompts: Please confirm to print the [Report Type] report... .

• If N or n is entered, the transaction is cancelled, fields are initialized, and the screen is reset.

• If any other character is entered, the program displays: "[Value]" is not a valid value to confirm... .

Screen-Level Validations

• Attention Identifier (AID) Validation :

• ENTER : Triggers input validation, date calculations, and job submission.

• PF3 : Safely exits the program and transfers control back to COMEN01C .

• Other Keys : Any other key is rejected with the error message Invalid key pressed. Please see below... .

Condition Checks

• Session Validation : Checks EIBCALEN . If it is 0 , the user is redirected to COSGN00C to prevent unauthorized access bypassing the login screen.

Data Elements Processed

Screen and Input Fields

• MONTHLYI / MONTHLYO : Input selection for Monthly report.

• YEARLYI / YEARLYO : Input selection for Yearly report.

• CUSTOMI / CUSTOMO : Input selection for Custom report.

• SDTMMI / SDTDDI / SDTYYYYI : Input fields for Custom Start Date (Month, Day, Year).

• EDTMMI / EDTDDI / EDTYYYYI : Input fields for Custom End Date (Month, Day, Year).

• CONFIRMI / CONFIRMO : Input confirmation flag ( Y/N ).

• ERRMSGO : Output field for error and status messages.

• ERRMSGC : Attribute byte used to dynamically change the color of the error message (e.g., DFHRED for errors, DFHGREEN for success).

Backend and Control Fields

• PARM-START-DATE-1 / PARM-START-DATE-2 : Dynamic JCL parameters populated with the calculated or input start date.

• PARM-END-DATE-1 / PARM-END-DATE-2 : Dynamic JCL parameters populated with the calculated or input end date.

• JCL-RECORD : 80-character buffer used to write JCL lines sequentially to the TDQ.

• JOB-LINES : Redefined array containing the template JCL statements.

• CARDDEMO-COMMAREA : The primary CICS Communication Area used to maintain session state.

Exception and Error Handling

CICS Command Exception Handling

• EXEC CICS WRITEQ TD :

• The program writes JCL records to the JOBS queue.

• It captures the response code in WS-RESP-CD and the reason code in WS-REAS-CD using the RESP and RESP2 options.

• If the response is not DFHRESP(NORMAL) , the program displays a red error message: Unable to Write TDQ (JOBS)... and outputs the response and reason codes to the CICS log for diagnostics.

• EXEC CICS RECEIVE MAP :

• Captures response codes inline using RESP and RESP2 to handle map failures gracefully without abending the transaction.

Error Messages Displayed

| Message Text | Color | Trigger Condition |

| :--- | :--- | :--- |

| Invalid key pressed. Please see below... | Red | User pressed an unsupported AID key. |

| Select a report type to print report... | Red | User pressed ENTER without selecting Monthly, Yearly, or Custom. |

| Start Date - Month can NOT be empty... | Red | Custom report selected but Start Month is blank. |

| Start Date - Not a valid Month... | Red | Start Month is non-numeric or greater than 12. |

| Start Date - Not a valid date... | Red | Start Date failed calendar validation in CSUTLDTC . |

| "[Value]" is not a valid value to confirm... | Red | User entered an invalid character in the confirmation field. |

| Unable to Write TDQ (JOBS)... | Red | CICS failed to write the JCL record to the Transient Data Queue. |

| [Report Type] report submitted for printing ... | Green | JCL successfully written to the TDQ. |

Security and Authorization Checks

• Session Verification :

• The program verifies that EIBCALEN is greater than 0 . If a user attempts to execute the transaction directly (e.g., typing CR00 on a blank screen without logging in), the program intercepts the request and redirects them to the Sign-on screen ( COSGN00C ).

• Platform Security :

• No explicit external security manager (such as IBM RACF) checks, EXEC CICS ASSIGN USERID calls, or standard CICS Signon ( CESN / CESF ) integrations are implemented within this program. Security is entirely application-managed via the COMMAREA.

Performance Considerations

• Pseudo-Conversational Design :

• The program is designed to be pseudo-conversational. It does not remain active in memory while waiting for user input.

• After sending the map, it issues an EXEC CICS RETURN specifying the transaction ID CR00 and passing the CARDDEMO-COMMAREA . This releases CICS resources (such as thread storage) and maximizes concurrent user capacity.

• Asynchronous Batch Offloading :

• By offloading the transaction report generation to a batch job via the JOBS TDQ, the program avoids executing heavy, resource-intensive file reads and formatting loops within the online CICS region. This prevents transaction timeouts and preserves online performance.

• Efficient TDQ Writing :

• The program loops through the JCL template array in memory and writes 80-byte records sequentially to the extra-partition TDQ. This is a low-overhead operation compared to direct database or file updates.

<h2

CardDemo Application Sign-on and User Authentication Gateway

The COSGN00C program serves as the secure entry point and primary sign-on gateway for the CardDemo credit card management application. Its main business purpose is to authenticate users attempting to access the system and route them to the appropriate functional areas based on their assigned security privileges. By acting as the initial gatekeeper, the program ensures that only authorized personnel can interact with the application's sensitive financial and administrative features.

Upon initial execution, the program initializes a standardized sign-on screen. This interface displays a professional header containing real-time system metadata—such as the current date, time, transaction identifier, and system name—alongside input fields for the User ID and Password. To facilitate a smooth user experience, the program automatically positions the cursor on the User ID field, ready for the user to input their credentials.

When a user submits their credentials, the program performs immediate input validation to ensure both the User ID and Password fields are populated. If any required information is missing, it alerts the user with a targeted message and highlights the incomplete field. Once basic validation passes, the program queries a secure user registry file. It handles various authentication outcomes by displaying clear, contextual error messages on the screen if the user is not found, if the password is incorrect, or if a general system verification error occurs.

Following successful authentication, the program determines the user's access level, distinguishing between administrative personnel and standard business users. It populates a shared communication area with the authenticated user's profile details and session context. The program then seamlessly transfers control to the appropriate landing page: administrators are routed to the Administration Menu, while standard users are directed to the Main Application Menu.

In addition to credential verification, the program manages basic screen navigation and exit procedures. Users can gracefully exit the sign-on screen at any time by pressing the designated exit key, which triggers a friendly departure message and terminates the session. Any unrecognized keyboard inputs are intercepted with an invalid key warning, ensuring the application remains robust and user-friendly from the very first interaction.

Business Case and User Interaction

Business Case Overview

The COSGN00C program serves as the centralized Signon (Login) screen for the CardDemo Credit Card Processing Application. It acts as the secure gateway to the application, authenticating users against a VSAM security file ( USRSEC ) and routing them to the appropriate functional menu based on their assigned user role (Administrator or Regular User).

User Interaction and Screen Flow

• Initial Entry : The user initiates the transaction (typically via transaction code CC00 ). The program displays the signon screen ( COSGN0A ) with empty fields for User ID and Password, placing the cursor on the User ID field.

• Credential Input : The user enters their 8-character User ID and 8-character Password. The password field is masked on the screen for security.

• Submission : The user presses the ENTER key to submit their credentials.

• Authentication & Routing :

• If authentication is successful and the user is an Administrator (User Type 'A'), the program transfers control to the Admin Menu ( COADM01C ).

• If authentication is successful and the user is a Regular User (User Type 'U'), the program transfers control to the Main Menu ( COMEN01C ).

• If authentication fails, an error message is displayed at the bottom of the screen, and the cursor is positioned on the invalid field.

• Exit : The user can press PF3 at any time to exit the application. The screen is cleared, a thank-you message is displayed, and the transaction terminates.

Screen Layout and Navigation

Screen Layout (COSGN0A)

+-----------------------------------------------------------------------------+

| Tran: CC00 AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: COSGN00C CardDemo Time: hh:mm:ss |

| AppID: APPLID SysID: SYSID |

| |

| This is a Credit Card Demo Application for Mainframe Modernization |

| |

| +========================================+ |

| |%%%%%%% NATIONAL RESERVE NOTE %%%%%%%%| |

| |%(1) THE UNITED STATES OF KICSLAND (1)%| |

| |%$$ ___ $$%| |

| |%$ {x} (o o) $%| |

| |%$ ( V ) O N E $%| |

| |%(1) ---m-m--- (1)%| |

| |%%~~~~~~~~~~~ ONE DOLLAR ~~~~~~~~~~~~~%%| |

| +========================================+ |

| |

| Type your User ID and Password, then press ENTER: |

| |

| User ID : [ ] (8 Char) |

| Password : [] (8 Char) |

| |

| <ERRMSG: Error messages appear here in red > |

| |

| ENTER=Sign-on F3=Exit |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+------------------+

| CICS Terminal |

+--------+---------+

|

| (Transaction CC00 / EIBCALEN = 0)

v

+------------------+

| COSGN00C | <----------------------------------+

| (Signon Program) | |

+--------+---------+ |

| |

| (Presents COSGN0A Map) |

v |

+------------------+ |

| COSGN0A Map | |

+--------+---------+ |

| |

+---[PF3]---> (Exit / Plain Text Message) |

| |

+---[ENTER]--> [Validate Inputs] |

| |

| (If Invalid) |

+------------------------+

|

| (If Valid Inputs)

v

[Read USRSEC VSAM File]

|

+---(User Not Found / Wrong Pwd)---+

| |

| (Success & Admin) v

+---> [XCTL to COADM01C]

|

| (Success & Regular User)

+---> [XCTL to COMEN01C]

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| WS-PGMNAME | 'COSGN00C' | Program identifier |

| WS-TRANID | 'CC00' | CICS Transaction ID associated with this program |

| WS-USRSEC-FILE | 'USRSEC ' | VSAM KSDS file containing user security records |

| CCDA-TITLE01 | ' AWS Mainframe Modernization ' | Screen Header Title Line 1 |

| CCDA-TITLE02 | ' CardDemo ' | Screen Header Title Line 2 |

| CCDA-MSG-THANK-YOU | 'Thank you for using CardDemo application... ' | Exit message displayed on PF3 |

| CCDA-MSG-INVALID-KEY | 'Invalid key pressed. Please see below... ' | Error message for unsupported keys |

Validation Logic

Input Field Validations

• User ID Validation :

• Must not be spaces or low-values.

• If empty, the program sets WS-ERR-FLG to 'Y' , displays the message "Please enter User ID ..." , and positions the cursor on the User ID field ( USERIDL = -1 ).

• Password Validation :

• Must not be spaces or low-values.

• If empty, the program sets WS-ERR-FLG to 'Y' , displays the message "Please enter Password ..." , and positions the cursor on the Password field ( PASSWDL = -1 ).

Screen-Level Validations

• Attention Identifier (AID) Validation :

• ENTER : Initiates credential validation and sign-on processing.

• PF3 : Initiates exit processing, displaying a thank-you message and terminating the transaction.

• Other Keys : Any other key (e.g., PF1, PF2, PF4, Clear) is rejected. The program sets WS-ERR-FLG to 'Y' , displays "Invalid key pressed. Please see below..." , and redisplays the signon screen.

Condition Checks

• Case Normalization : Both the entered User ID and Password are automatically converted to uppercase using the FUNCTION UPPER-CASE intrinsic function before performing file lookups or comparisons.

• Password Matching : The entered password (converted to uppercase) is compared directly against the password retrieved from the VSAM file ( SEC-USR-PWD ). If they do not match, the error "Wrong Password. Try again ..." is displayed, and the cursor is positioned on the Password field.

Data Elements Processed

Screen and Input Fields

• USERIDI / USERIDO : User ID entered on the screen (up to 8 characters).

• PASSWDI / PASSWDO : Password entered on the screen (up to 8 characters, masked).

• ERRMSGO : Error message field at the bottom of the screen.

Backend and Control Fields

• SEC-USR-ID : Key field used to read the USRSEC VSAM file.

• SEC-USR-PWD : Stored password retrieved from the USRSEC file.

• SEC-USR-TYPE : Stored user role/type retrieved from the USRSEC file:

• 'A' : Administrator

• 'U' : Regular User

• CDEMO-FROM-TRANID : Set to 'CC00' to pass the originating transaction ID to the next program.

• CDEMO-FROM-PROGRAM : Set to 'COSGN00C' to pass the originating program name to the next program.

• CDEMO-USER-ID : Set to the authenticated User ID to maintain session state.

• CDEMO-USER-TYPE : Set to the authenticated user's role to maintain authorization state.

• CDEMO-PGM-CONTEXT : Set to 0 (Enter context) to signal a fresh entry into the next program.

Exception and Error Handling

CICS File Read Exception Handling

The program explicitly checks the CICS response code ( WS-RESP-CD ) after attempting to read the USRSEC VSAM file:

• WS-RESP-CD = 0 (Normal) : The record was successfully found. The program proceeds to password verification.

• WS-RESP-CD = 13 (Not Found / DFHRESP(NOTFND) ) : The User ID does not exist in the security file. The program sets WS-ERR-FLG to 'Y' , displays "User not found. Try again ..." , and positions the cursor on the User ID field.

• WS-RESP-CD = Other : Any other error (e.g., file closed, record locked, or hardware error). The program sets WS-ERR-FLG to 'Y' , displays "Unable to verify the User ..." , and positions the cursor on the User ID field.

CICS Command Failures

The program utilizes explicit response checking ( RESP and RESP2 options) on all file operations rather than relying on global EXEC CICS HANDLE CONDITION statements. This ensures structured, inline error handling and prevents unexpected program abends.

Security and Authorization Checks

• Authentication : Performed by matching the uppercase representation of the user-entered password against the stored password ( SEC-USR-PWD ) in the USRSEC VSAM file.

• Role-Based Authorization :

• Users with SEC-USR-TYPE equal to 'A' (Admin) are authorized to access the Administration Menu ( COADM01C ).

• Users with SEC-USR-TYPE equal to 'U' (Regular User) are authorized to access the standard Main Menu ( COMEN01C ).

• Platform Security : No explicit external security manager (such as RACF) checks, EXEC CICS ASSIGN USERID calls, or standard CICS Signon ( CESN / CESF ) integrations are implemented within this program. Security is entirely application-managed.

Performance Considerations

• Pseudo-Conversational Design : The program is designed to be pseudo-conversational. It does not remain active in memory while waiting for user input. Instead, it sends the map and issues an EXEC CICS RETURN specifying the next transaction ID ( CC00 ) and passing the CARDDEMO-COMMAREA . This minimizes CICS resource consumption and maximizes concurrent user capacity.

• Efficient VSAM Access : The read operation on the USRSEC file is a direct key read ( RIDFLD ), which is highly efficient and avoids resource-intensive browse operations.

<h2

CardDemo Transaction List: Interactive Credit Card Transaction Portal

The COTRN00C program serves as the interactive transaction listing and browsing portal within the CardDemo credit card processing application. Its primary business purpose is to provide customer service representatives, auditors, and financial analysts with a structured, paginated view of all credit card transactions recorded in the system. By presenting transaction histories in an accessible format, the program enables staff to monitor financial activities, verify postings, and quickly locate specific records.

Upon entering the screen, users are presented with a clean, tabular list displaying up to ten transactions at a time, complete with transaction IDs, dates, descriptions, and amounts. The program supports intuitive navigation, allowing users to scroll forward and backward through the transaction ledger using standard function keys. To streamline searches within large volumes of data, users can input a specific Transaction ID to jump directly to that point in the ledger, bypassing manual scrolling.

A key feature of this program is its seamless integration with the detailed transaction inquiry module. From the list, a user can select any individual transaction by entering a selection code next to it. The program then automatically transfers control to the Transaction Viewer program, passing the selected transaction's details so the user can immediately inspect comprehensive merchant, cardholder, and processing information without re-entering data.

To maintain high data quality and a smooth user experience, the program features robust input validation and user feedback mechanisms. It ensures that search queries are valid and numeric, preventing system errors before they occur. If a user attempts an invalid action, presses an unsupported key, or reaches the boundaries of the transaction file, the program displays clear, contextual messages at the bottom of the screen to guide their next steps.

Operating as a core component of the CardDemo suite, the program maintains strict session security and context. It coordinates closely with the Main Menu and Sign-on screens, ensuring that user roles and security permissions are preserved as operators navigate through the system. Its efficient, resource-conscious design ensures rapid response times and high availability, even when processing large volumes of concurrent transaction queries.

COTRN00C - CardDemo Transaction List Program

Business Case and User Interaction

Business Case Overview

The COTRN00C program is an essential component of the CardDemo credit card processing application. Its primary business purpose is to provide a paginated, scrollable list of financial transactions retrieved from the transaction master file ( TRANSACT ).

This program allows customer service representatives, billing administrators, and financial auditors to:

• Browse Transactions : View a high-level summary of transactions (up to 10 per page), including Transaction ID, Date, Description, and Amount.

• Search by Transaction ID : Initiate a targeted search by entering a specific Transaction ID to start browsing the list from that point forward.

• Select for Detailed View : Select a specific transaction from the list to view its complete details by transferring control to the Transaction Viewer program ( COTRN01C ).

• Navigate Pages : Scroll forward (PF8) and backward (PF7) through the transaction database.

User Interaction and Screen Flow

• Screen Entry : The user enters the transaction list screen either from the Main Menu ( COMEN01C ) by selecting Option 6, or directly via transaction code CT00 .

• Initial Display : The program performs a browse operation on the TRANSACT VSAM file starting from the beginning (or from a passed key) and displays the first 10 records.

• Searching : The user can type a numeric Transaction ID in the "Search Tran ID" field and press ENTER . The list will refresh, starting with the specified ID (or the next closest match).

• Selecting a Transaction : The user can type S or s in the selection field ( Sel ) next to any of the 10 displayed transactions and press ENTER . The program will transfer control ( EXEC CICS XCTL ) to COTRN01C to display the detailed transaction view.

• Pagination :

• PF8 (Forward) : Displays the next 10 transactions.

• PF7 (Backward) : Displays the previous 10 transactions.

• Exit : The user can press PF3 to return to the Main Menu ( COMEN01C ).

Screen Layout and Navigation

Screen Layout (COTRN0A)

+-----------------------------------------------------------------------------+

| Tran: CT00 AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: COTRN00C CardDemo Time: hh:mm:ss |

| |

| List Transactions Page: 00000001 |

| |

| Search Tran ID: [ ] |

| |

| Sel Transaction ID Date Description Amount |

| --- ---------------- -------- ------------------------- ------------ |

| [ ] 0000000000000001 12/31/22 Gas Station Purchase $ 45.50 |

| [ ] 0000000000000002 12/31/22 Grocery Store $ 120.10 |

| [ ] 0000000000000003 01/01/23 Online Retailer $ 15.99 |

| [ ] 0000000000000004 01/01/23 Restaurant $ 85.00 |

| [ ] 0000000000000005 01/02/23 Coffee Shop $ 4.75 |

| [ ] 0000000000000006 01/02/23 Utility Bill $ 150.00 |

| [ ] 0000000000000007 01/03/23 Streaming Service $ 14.99 |

| [ ] 0000000000000008 01/03/23 Department Store $ 210.45 |

| [ ] 0000000000000009 01/04/23 Pharmacy $ 32.20 |

| [ ] 0000000000000010 01/04/23 Gym Membership $ 50.00 |

| |

| Type 'S' to View Transaction details from the list |

| |

| <ERRMSG: Error or status messages appear here in red > |

| |

| ENTER=Continue F3=Back F7=Backward F8=Forward |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+--------------------------------------------------+

| Sign-on Screen |

| (COSGN00C) |

+-----------------------+--------------------------+

|

| (If EIBCALEN = 0)

v

+--------------------------------------------------+

| Main Menu Program |

| (COMEN01C) |

+-----------------------+--------------------------+

|

| (Select Option 6)

v

+--------------------------------------------------+

+----> | Transaction List Screen | <----+ (PF7/PF8 Scroll)

| | (COTRN00C) | -----+

| +-----------------------+--------------------------+

| |

| | (Select Row with 'S' + ENTER)

| v

| +--------------------------------------------------+

| | Transaction View Screen |

| | (COTRN01C) |

| +-----------------------+--------------------------+

| |

+------------------------------+ (PF3 Back)

Data Flow Between Screens

• CARDDEMO-COMMAREA : This shared memory block is passed between programs during XCTL transfers to maintain session state.

• CDEMO-FROM-PROGRAM : Tracks the calling program name ( COTRN00C ) so that pressing PF3 in COTRN01C returns the user to the list.

• CDEMO-FROM-TRANID : Tracks the calling transaction ID ( CT00 ).

• CDEMO-CT00-TRNID-FIRST : Stores the first Transaction ID displayed on the current page. Used as the starting key for backward scrolling (PF7).

• CDEMO-CT00-TRNID-LAST : Stores the last Transaction ID displayed on the current page. Used as the starting key for forward scrolling (PF8).

• CDEMO-CT00-PAGE-NUM : Tracks the current page number.

• CDEMO-CT00-NEXT-PAGE-FLG : A flag ('Y'/'N') indicating if there are more records beyond the current page.

• CDEMO-CT00-TRN-SELECTED : Holds the Transaction ID selected by the user. This is passed to COTRN01C for detailed lookup.

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| WS-PGMNAME | 'COTRN00C' | Program identifier |

| WS-TRANID | 'CT00' | CICS Transaction ID associated with this program |

| WS-TRANSACT-FILE | 'TRANSACT' | Name of the VSAM KSDS file containing transaction records |

| CCDA-TITLE01 | ' AWS Mainframe Modernization ' | Screen Header Title Line 1 |

| CCDA-TITLE02 | ' CardDemo ' | Screen Header Title Line 2 |

| CCDA-MSG-INVALID-KEY | 'Invalid key pressed. Please see below... ' | Error message for unsupported AID keys |

Validation Logic

Input Field Validations

• Search Transaction ID ( TRNIDINI ) :

• If the field is populated, it must be strictly numeric.

• If non-numeric characters are entered, the program sets WS-ERR-FLG to 'Y' , displays the error message "Tran ID must be Numeric ..." , and positions the cursor on the search field ( TRNIDINL = -1 ).

• If the field is empty or contains low-values, the program defaults the search key to low-values to start browsing from the beginning of the file.

• Row Selection Fields ( SEL0001I to SEL0010I ) :

• Only one row should be selected at a time.

• The selection character must be 'S' or 's' .

• If an invalid character is entered, the program displays the error message "Invalid selection. Valid value is S" .

Screen-Level Validations

• Attention Identifier (AID) Validation :

• ENTER : Processes search inputs or row selections.

• PF3 : Transfers control back to the Main Menu ( COMEN01C ).

• PF7 : Triggers backward pagination.

• PF8 : Triggers forward pagination.

• Other Keys : Any other key is rejected. The program sets WS-ERR-FLG to 'Y' , displays "Invalid key pressed. Please see below..." , and redisplays the screen.

Condition Checks

• First-Time Entry Check : The program checks CDEMO-PGM-CONTEXT . If it is not set to 1 (re-entry), it initializes the screen, sets the page number to 0, and performs an initial forward browse.

• Boundary Checks :

• Top of File : If the user is on Page 1 and presses PF7 , the program blocks the action and displays "You are already at the top of the page..." .

• Bottom of File : If the user is on the last page (where CDEMO-CT00-NEXT-PAGE-FLG is 'N' ) and presses PF8 , the program blocks the action and displays "You are already at the bottom of the page..." .

Data Elements Processed

Screen Fields

• TRNIDINI / TRNIDINO : Input/Output field for the Search Transaction ID.

• PAGENUMI / PAGENUMO : Output field for the current page number.

• SEL0001I to SEL0010I : Input fields for selecting a transaction row.

• TRNID01O to TRNID10O : Output fields displaying the 16-character Transaction IDs.

• TDATE01O to TDATE10O : Output fields displaying the formatted transaction dates ( MM/DD/YY ).

• TDESC01O to TDESC10O : Output fields displaying the transaction descriptions.

• TAMT001O to TAMT010O : Output fields displaying the formatted transaction amounts.

• ERRMSGO : Output field for error and status messages.

Backend and Control Fields

• TRAN-RECORD : The record structure mapping the TRANSACT VSAM file.

• TRAN-ID : Key field used for VSAM browse operations ( STARTBR , READNEXT , READPREV ).

• TRAN-AMT : Packed-decimal transaction amount ( S9(09)V99 ) read from the file.

• WS-TRAN-AMT : Numeric-edited working storage field ( +99999999.99 ) used to format the amount before screen display.

• TRAN-ORIG-TS : Timestamp field used to extract and format the transaction date.

Exception and Error Handling

CICS Command Exception Handling

The program uses explicit response code checking ( RESP and RESP2 ) on all CICS file control commands instead of global HANDLE CONDITION statements.

EXEC CICS STARTBR (Start Browse) :

• DFHRESP(NORMAL) : Browse successfully initiated.

• DFHRESP(NOTFND) : The starting key was not found. The program sets the EOF flag, displays "You are at the top of the page..." , and redisplays the screen.

• Other Responses : The program displays the response and reason codes, sets WS-ERR-FLG to 'Y' , and displays "Unable to lookup transaction..." .

EXEC CICS READNEXT (Read Next Record) :

• DFHRESP(NORMAL) : Record successfully retrieved.

• DFHRESP(ENDFILE) : End of file reached. The program sets the EOF flag, displays "You have reached the bottom of the page..." , and redisplays the screen.

• Other Responses : The program displays the response and reason codes, sets WS-ERR-FLG to 'Y' , and displays "Unable to lookup transaction..." .

EXEC CICS READPREV (Read Previous Record) :

• DFHRESP(NORMAL) : Record successfully retrieved.

• DFHRESP(ENDFILE) : Beginning of file reached. The program sets the EOF flag, displays "You have reached the top of the page..." , and redisplays the screen.

• Other Responses : The program displays the response and reason codes, sets WS-ERR-FLG to 'Y' , and displays "Unable to lookup transaction..." .

Error Messages Displayed

| Message Text | Trigger Condition |

| :--- | :--- |

| Tran ID must be Numeric ... | User entered non-numeric characters in the Search Tran ID field. |

| Invalid selection. Valid value is S | User entered a character other than 'S' or 's' in a row selection field. |

| You are already at the top of the page... | User pressed PF7 while on Page 1. |

| You are already at the bottom of the page... | User pressed PF8 when no more records were available. |

| Unable to lookup transaction... | A technical error occurred during a VSAM file operation. |

| Invalid key pressed. Please see below... | User pressed an unsupported AID key. |

Security and Authorization Checks

• No explicit security checks identified : The program does not perform RACF checks, call EXEC CICS ASSIGN USERID , or utilize standard CICS Sign-on ( CESN / CESF ) integrations. Security and session state are managed entirely at the application level via the passed CARDDEMO-COMMAREA .

Performance Considerations

• Efficient VSAM Browsing :

• The program utilizes CICS browse operations ( STARTBR , READNEXT , READPREV , ENDBR ) which are highly efficient for sequential retrieval of records from a VSAM KSDS.

• It properly terminates the browse operation using EXEC CICS ENDBR as soon as the page is populated, releasing VSAM browse locks and resources.

• Look-Ahead Pagination :

• To determine if a "Next Page" exists, the program reads an 11th record ( READNEXT ) after populating the 10 screen rows. If successful, it sets NEXT-PAGE-YES to 'Y' . This prevents unnecessary "empty" page scrolls and provides a better user experience without loading the entire dataset into memory.

• Pseudo-Conversational Design :

• The program is designed to be pseudo-conversational. It releases CICS resources while waiting for user input by issuing EXEC CICS RETURN specifying the transaction ID CT00 and passing the CARDDEMO-COMMAREA .

<h2

CardDemo Transaction Viewer: Detailed Credit Card Transaction Inquiry

The COTRN01C program is a core component of the CardDemo application, serving as a dedicated inquiry tool for viewing detailed information about individual credit card transactions. Its primary business purpose is to provide customer service representatives, financial analysts, and administrators with a comprehensive, read-only view of any transaction stored in the system's database. By entering a unique transaction identifier, users can instantly access the complete history and context of a specific financial event.

When a user accesses the transaction viewer, they are presented with a structured screen where they can input a Transaction ID. Alternatively, the program can be invoked directly from a transaction list screen with a pre-selected ID, automatically loading the details upon entry. The retrieved information is highly detailed, encompassing the associated credit card number, transaction type, category, source, transaction amount, description, and precise timestamps for both when the transaction originated and when it was processed. Additionally, it displays merchant-specific details such as the merchant ID, name, city, and zip code.

Navigation within the program is designed to be intuitive and user-friendly, utilizing standard terminal function keys. Users can press Enter to execute a search, clear the current screen to start a new inquiry, or return to the previous screen—typically the main menu or the transaction list. This seamless flow allows operators to quickly toggle between high-level transaction lists and deep-dive individual views without losing their operational context.

To ensure data integrity and a smooth user experience, the program features robust input validation and error handling. It verifies that the Transaction ID field is not empty before attempting a database lookup. If the requested transaction does not exist in the system, or if a database access issue occurs, the program gracefully intercepts the error and displays a clear, descriptive message on the screen. It also handles invalid keyboard inputs by alerting the user rather than interrupting the application flow.

Operating under a pseudo-conversational design, the program efficiently manages system resources by releasing them while waiting for user input. It relies on a shared communication area to pass session metadata, such as user identity and navigation history, between screens. This architecture ensures that security contexts are maintained and that the application remains highly responsive, even under heavy concurrent user traffic.

Business Case and User Interaction

Business Case Overview

The COTRN01C program is a core component of the CardDemo credit card processing application. Its primary business purpose is to provide a detailed, read-only view of a specific financial transaction retrieved from the transaction master file ( TRANSACT ).

This program is typically invoked when a business user or customer service representative needs to audit or verify the specifics of a transaction—such as the transaction amount, processing timestamps, cardholder number, and merchant details (name, city, and zip code). It supports both direct lookup via manual entry of a Transaction ID and contextual navigation where a Transaction ID is passed from a transaction listing or browse program.

User Interaction and Screen Flow

• Screen Entry :

• Direct Entry : The user navigates to the Transaction View screen. The input field "Enter Tran ID" is empty, and the cursor is positioned there.

• Contextual Entry : If the user arrives from another program (such as the Transaction Browse program COTRN00C ) with a pre-selected transaction, the program automatically populates the "Enter Tran ID" field, executes the lookup logic, and displays the transaction details immediately.

• Manual Lookup : The user types a 16-character Transaction ID into the "Enter Tran ID" field and presses ENTER .

• Details Display : If the transaction is found, the program populates and displays all transaction details on the screen. If not found, an error message is displayed at the bottom of the screen.

• Screen Clearing : The user can press PF4 to clear all input and output fields, resetting the screen for a new search.

• Navigation :

• Pressing PF3 returns the user to the calling program (stored in the communication area) or defaults to the Main Menu ( COMEN01C ).

• Pressing PF5 transfers control directly to the Transaction Browse program ( COTRN00C ).

Screen Layout and Navigation

Screen Layout (COTRN1A)

+-----------------------------------------------------------------------------+

| Tran: CT01 AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: COTRN01C CardDemo Time: hh:mm:ss |

| |

| View Transaction |

| |

| Enter Tran ID: [ ] |

| ---------------------------------------------- ---------------|

| |

| Transaction ID: [ ] Card Number: [ ] |

| |

| Type CD: [ ] Category CD: [ ] Source: [ ] |

| |

| Description: [ ] |

| |

| Amount: [ ] Orig Date: [ ] Proc Date: [ ] |

| |

| Merchant ID: [ ] Merchant Name: [ ] |

| Merchant City: [ ] Merchant Zip: [ ] |

| |

| <ERRMSG: Error or status messages appear here > |

| |

| ENTER=Fetch F3=Back F4=Clear F5=Browse Tran |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+-----------------------+

| Sign-on (COSGN00C) |

+-----------+-----------+

| (If EIBCALEN = 0)

v

+-----------------------+

| Main Menu (COMEN01C)|

+-----------+-----------+

|

| (Select Option 7)

v

+-----------------------+

| Transaction Browse |

| (COTRN00C) |

+-----------+-----------+

|

| (Select Transaction / PF5)

v

+-----------------------+

| Transaction View | <---+ (PF4 Clear / ENTER Fetch)

| (COTRN01C) | ----+

+-----------+-----------+

|

+--------+--------+

| [PF3] | [PF5]

v v

+--------------------+ +--------------------+

| Previous Screen | | Transaction Browse |

| (e.g., COMEN01C) | | (COTRN00C) |

+--------------------+ +--------------------+

Data Flow Between Screens

• CARDDEMO-COMMAREA : This shared memory block is passed between programs during XCTL transfers.

• CDEMO-FROM-PROGRAM : Tracks the calling program name so that pressing PF3 returns the user to the correct screen.

• CDEMO-CT01-TRN-SELECTED : Holds the Transaction ID selected from the browse screen ( COTRN00C ). If populated, COTRN01C automatically performs a lookup on this ID upon entry.

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| WS-PGMNAME | 'COTRN01C' | Program identifier |

| WS-TRANID | 'CT01' | CICS Transaction ID associated with this program |

| WS-TRANSACT-FILE | 'TRANSACT' | Name of the VSAM KSDS file containing transaction records |

| CCDA-TITLE01 | ' AWS Mainframe Modernization ' | Screen Header Title Line 1 |

| CCDA-TITLE02 | ' CardDemo ' | Screen Header Title Line 2 |

| CCDA-MSG-INVALID-KEY | 'Invalid key pressed. Please see below... ' | Error message for unsupported AID keys |

Validation Logic

Input Field Validations

• Transaction ID Input ( TRNIDINI ) :

• Must not be spaces or low-values.

• If the field is empty when the user presses ENTER , the program sets WS-ERR-FLG to 'Y' , displays the error message "Tran ID can NOT be empty..." , and positions the cursor on the input field ( TRNIDINL = -1 ).

Screen-Level Validations

• Attention Identifier (AID) Validation :

• ENTER : Triggers input validation and executes the VSAM file read.

• PF3 : Triggers exit processing, returning control to the program stored in CDEMO-FROM-PROGRAM (or COMEN01C if empty).

• PF4 : Clears all screen fields and resets the cursor to the input field.

• PF5 : Transfers control directly to the Transaction Browse program ( COTRN00C ).

• Other Keys : Any other key is rejected. The program sets WS-ERR-FLG to 'Y' , displays "Invalid key pressed. Please see below..." , and redisplays the screen.

Condition Checks

• First-Time Entry Check : The program checks CDEMO-PGM-CONTEXT . If it is not set to 1 (re-entry), it initializes the screen and checks if a Transaction ID was passed from the calling program via CDEMO-CT01-TRN-SELECTED . If passed, it automatically executes the lookup.

Data Elements Processed

Screen Fields

• TRNIDINI / TRNIDINO : Input field for the Transaction ID search.

• TRNIDO : Output field displaying the retrieved Transaction ID.

• CARDNUMO : Output field displaying the 16-digit credit card number.

• TTYPCDO : Output field displaying the 2-character transaction type code.

• TCATCDO : Output field displaying the 4-digit transaction category code.

• TRNSRCO : Output field displaying the transaction source (e.g., POS, ATM).

• TDESCO : Output field displaying the transaction description.

• TRNAMTO : Output field displaying the formatted transaction amount.

• TORIGDTO : Output field displaying the original transaction timestamp.

• TPROCDTO : Output field displaying the processing timestamp.

• MIDO : Output field displaying the 9-digit Merchant ID.

• MNAMEO : Output field displaying the merchant's name.

• MCITYO : Output field displaying the merchant's city.

• MZIPO : Output field displaying the merchant's zip code.

• ERRMSGO : Output field for error and status messages.

Backend and Control Fields

• TRAN-RECORD : The record structure mapping the TRANSACT VSAM file.

• TRAN-AMT : The packed-decimal transaction amount ( S9(09)V99 ) read from the file.

• WS-TRAN-AMT : A numeric-edited working storage field ( +99999999.99 ) used to format the transaction amount before displaying it on the screen.

Exception and Error Handling

CICS Command Exception Handling

The program uses explicit response code checking ( RESP and RESP2 ) on all CICS commands instead of global HANDLE CONDITION statements.

• EXEC CICS READ (on TRANSACT file) :

• DFHRESP(NORMAL) : The record was successfully retrieved. The program proceeds to format and display the data.

• DFHRESP(NOTFND) : The Transaction ID does not exist in the file. The program sets WS-ERR-FLG to 'Y' , displays "Transaction ID NOT found..." , and positions the cursor on the input field.

• Other Responses : Any other error (e.g., file disabled or closed) is caught. The program displays the response and reason codes to the system log, sets WS-ERR-FLG to 'Y' , displays "Unable to lookup Transaction..." , and positions the cursor on the input field.

Error Messages Displayed

| Message Text | Trigger Condition |

| :--- | :--- |

| Tran ID can NOT be empty... | User pressed ENTER with spaces or low-values in the input field. |

| Transaction ID NOT found... | The entered Transaction ID does not exist in the TRANSACT file. |

| Unable to lookup Transaction... | A technical error occurred during the VSAM read operation. |

| Invalid key pressed. Please see below... | The user pressed an unsupported AID key. |

Security and Authorization Checks

• No explicit security checks identified : The program does not perform RACF checks, call EXEC CICS ASSIGN USERID , or utilize standard CICS Sign-on ( CESN / CESF ) integrations. Security and session state are managed entirely at the application level via the passed CARDDEMO-COMMAREA .

Performance Considerations

• Unnecessary Update Lock (Critical Anti-Pattern) :

• In the READ-TRANSACT-FILE paragraph, the program issues an EXEC CICS READ with the UPDATE option:

EXEC CICS READ

DATASET (WS-TRANSACT-FILE)

INTO (TRAN-RECORD)

...

UPDATE

RESP (WS-RESP-CD)

END-EXEC.

• Because COTRN01C is a read-only "View" program and does not perform a subsequent REWRITE or DELETE , requesting an update lock is highly inefficient. It holds an exclusive lock on the VSAM record until the transaction ends ( EXEC CICS RETURN ), which can cause severe lock contention, transaction queuing, and potential deadlocks in a high-concurrency production environment.

• Pseudo-Conversational Design :

• The program is designed to be pseudo-conversational. It releases CICS resources while waiting for user input by issuing EXEC CICS RETURN specifying the transaction ID CT01 and passing the CARDDEMO-COMMAREA .

<h2

CardDemo Transaction Creation and Validation Gateway

The COTRN02C program serves as the manual transaction entry gateway for the CardDemo credit card application. Its primary business purpose is to allow authorized operators to securely record new financial transactions—such as purchases, returns, or adjustments—directly into the system's master ledger. By providing a controlled interface for manual entry, the program ensures that all new transaction records are complete, accurate, and properly formatted before they impact customer accounts.

The user interaction begins with the operator entering either an Account ID or a Credit Card Number. The program automatically cross-references these identifiers against system files; entering one will automatically retrieve and display the other, verifying that the account exists and is valid. To streamline repetitive data entry, the program features a "copy last" function that allows operators to pre-populate the screen with details from the most recently recorded transaction, which they can then modify as needed.

Before any transaction is committed to the database, the program performs comprehensive validation on all input fields. It verifies that mandatory details—such as the transaction type, category, source, description, amount, and merchant information—are present and numeric where required. Additionally, the program integrates with a centralized date utility to ensure that both the transaction's original date and processing date are valid calendar dates, preventing downstream processing errors caused by corrupt date formats.

To safeguard financial data integrity, the program enforces a two-step confirmation process. After validating the inputs, the system prompts the operator to confirm the addition of the transaction. Once confirmed, the program dynamically determines the next sequential transaction identifier by scanning the transaction database, assigns this unique ID to the new record, and writes the transaction to the master file. A successful operation concludes with a green confirmation message displaying the newly generated transaction ID.

Operating under a pseudo-conversational design, the program efficiently manages mainframe system resources while waiting for operator input. It maintains the user's session context and security profile as they navigate through the application. Operators can easily clear the screen to start a new entry, cancel the operation, or return to the main application menu, ensuring a fluid and secure user experience.

Business Case and User Interaction

Business Case Overview

The COTRN02C program is the "Transaction Add" module of the CardDemo Credit Card Processing Application. Its primary business purpose is to allow authorized users to manually record and insert a new financial transaction into the system. This is particularly useful for manual adjustments, offline transaction logging, or administrative overrides.

The program ensures data integrity by validating all transaction details (such as transaction types, categories, amounts, dates, and merchant information) and cross-referencing the account or card number against the system's cross-reference files ( CCXREF and CXACAIX ). Once validated, the program automatically generates a unique, sequential Transaction ID and commits the new record to the primary transaction database ( TRANSACT ).

User Interaction and Screen Flow

• Screen Entry : The user navigates to this screen from the Main Menu ( COMEN01C ) by selecting the "Transaction Add" option, or is redirected here from another module with a pre-selected card or account number.

• Key Field Input : The user must enter either an Account Number or a Card Number . Entering one and pressing ENTER automatically triggers a cross-reference lookup to populate the other field.

• Data Entry : The user fills in the transaction details:

• Type CD and Category CD (numeric codes representing the transaction type and category).

• Source (origin of the transaction, e.g., Terminal, Online).

• Description (textual description of the transaction).

• Amount (signed numeric value, e.g., +150.00 or -50.00 ).

• Orig Date and Proc Date (dates in YYYY-MM-DD format).

• Merchant Details (ID, Name, City, and Zip Code).

• Template Copy (Optional) : The user can press PF5 to copy the details of the most recently recorded transaction in the system into the data fields, serving as a template to speed up repetitive data entry.

• Confirmation : To prevent accidental entries, the user must explicitly enter Y in the confirmation field and press ENTER to commit the transaction.

• Commit and Feedback : Upon successful insertion, the screen fields are cleared, and a green success message is displayed at the bottom of the screen, showing the newly generated Transaction ID. If validation fails, red error messages highlight the invalid fields.

Screen Layout

Screen Layout (COTRN2A)

+-----------------------------------------------------------------------------+

| Tran: CT02 AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: COTRN02C CardDemo Time: hh:mm:ss |

| |

| Add Transaction |

| |

| Enter Acct #: [ ] (or) Card #: [ ] |

| |

| ---------------------------------------------- ---------------|

| |

| Type CD: [ ] Category CD: [ ] Source: [ ] |

| |

| Description: [ ] |

| |

| Amount: [ ] Orig Date: [ ] Proc Date: [ ] |

| (-99999999.99) (YYYY-MM-DD) (YYYY-MM-DD) |

| |

| Merchant ID: [ ] Merchant Name: [ ] |

| |

| Merchant City: [ ] Merchant Zip: [ ] |

| |

| You are about to add this transaction. Please confirm : [ ] (Y/N) |

| |

| <ERRMSG: Error or success messages appear here > |

| |

| ENTER=Continue F3=Back F4=Clear F5=Copy Last Tran. |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+-----------------------------------------------------------------+

| Main Menu (COMEN01C) |

+-------------------------------+---------------------------------+

|

| (Select Option 8 / XCTL)

v

+-----------------------------------------------------------------+

| Add Transaction (COTRN02C) | <---+

+-------------------------------+---------------------------------+ |

| |

+-------------------+-------------------+ |

| [PF3] | [ENTER] |

v v |

+-------------------------------+ +-------------------+ |

| Previous Screen | | Validate Inputs | |

| (COMEN01C / CDEMO-FROM-PROG) | +---------+---------+ |

+-------------------------------+ | |

| (If Valid & |

| Confirmed) |

v |

+-------------------+ |

| Write to VSAM |---------+

| (TRANSACT File) | (Success/Error

+-------------------+ Message)

Screen Navigation

• PF3 (Back) : Returns the user to the calling program (stored in CDEMO-FROM-PROGRAM ) or defaults to the Main Menu ( COMEN01C ).

• PF4 (Clear) : Clears all input fields on the current screen.

• PF5 (Copy Last Tran) : Performs a backward browse on the TRANSACT file to retrieve the most recent transaction record and populates the screen data fields with its values.

• ENTER : Submits the entered data for validation and processing.

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| WS-PGMNAME | 'COTRN02C' | Program identifier |

| WS-TRANID | 'CT02' | CICS Transaction ID associated with this program |

| WS-TRANSACT-FILE | 'TRANSACT' | VSAM KSDS file containing transaction records |

| WS-CCXREF-FILE | 'CCXREF ' | VSAM KSDS cross-reference file (keyed by Card Number) |

| WS-CXACAIX-FILE | 'CXACAIX ' | VSAM Alternate Index path for cross-reference (keyed by Account ID) |

| WS-DATE-FORMAT | 'YYYY-MM-DD' | Expected date format mask for validation |

| CCDA-TITLE01 | ' AWS Mainframe Modernization ' | Screen Header Title Line 1 |

| CCDA-TITLE02 | ' CardDemo ' | Screen Header Title Line 2 |

Validation Logic

Input Field Validations

• Account Number ( ACTIDINI ) / Card Number ( CARDNINI ) :

• At least one of these key fields must be entered. If both are empty, the error "Account or Card Number must be entered..." is displayed.

• If Account Number is entered, it must be numeric. If valid, the program reads the CXACAIX file to retrieve and populate the corresponding Card Number.

• If Card Number is entered, it must be numeric. If valid, the program reads the CCXREF file to retrieve and populate the corresponding Account Number.

• Type CD ( TTYPCDI ) :

• Cannot be empty or low-values.

• Must be strictly numeric.

• Category CD ( TCATCDI ) :

• Cannot be empty or low-values.

• Must be strictly numeric.

• Source ( TRNSRCI ) :

• Cannot be empty or low-values.

• Description ( TDESCI ) :

• Cannot be empty or low-values.

• Amount ( TRNAMTI ) :

• Cannot be empty or low-values.

• Must match the format +99999999.99 or -99999999.99 (first character must be + or - , positions 2-9 must be numeric, position 10 must be . , and positions 11-12 must be numeric).

• Orig Date ( TORIGDTI ) / Proc Date ( TPROCDTI ) :

• Cannot be empty or low-values.

• Must match the format YYYY-MM-DD (positions 1-4 numeric, position 5 is - , positions 6-7 numeric, position 8 is - , positions 9-10 numeric).

• The date is logically validated by calling the utility program CSUTLDTC . If the utility returns a severity code other than '0000' (excluding warning '2513' ), the error "Orig Date - Not a valid date..." or "Proc Date - Not a valid date..." is displayed.

• Merchant ID ( MIDI ) :

• Cannot be empty or low-values.

• Must be strictly numeric.

• Merchant Name ( MNAMEI ) / City ( MCITYI ) / Zip ( MZIPI ) :

• Cannot be empty or low-values.

Screen-Level Validations

• Attention Identifier (AID) Validation :

• Only ENTER , PF3 , PF4 , and PF5 are valid keys. Any other key triggers the error "Invalid key pressed. Please see below..." .

• Confirmation Field ( CONFIRMI ) :

• To commit the transaction, the user must enter Y or y .

• If the field contains N , n , spaces, or low-values, the program prompts "Confirm to add this transaction..." and positions the cursor on the confirmation field.

• Any other value triggers the error "Invalid value. Valid values are (Y/N)..." .

Condition Checks

• Error Cascading : If any key field validation fails, the program automatically clears all transaction data fields on the screen to prevent processing mismatched data.

Data Elements Processed

Screen Fields

• ACTIDINI / ACTIDINO : Input/Output field for the 11-digit Account ID.

• CARDNINI / CARDNINO : Input/Output field for the 16-digit Card Number.

• TTYPCDI / TTYPCDO : Input/Output field for the 2-digit Transaction Type Code.

• TCATCDI / TCATCDO : Input/Output field for the 4-digit Transaction Category Code.

• TRNSRCI / TRNSRCO : Input/Output field for the 10-character Transaction Source.

• TDESCI / TDESCO : Input/Output field for the 60-character Transaction Description.

• TRNAMTI / TRNAMTO : Input/Output field for the 12-character formatted Transaction Amount.

• TORIGDTI / TORIGDTO : Input/Output field for the 10-character Original Date ( YYYY-MM-DD ).

• TPROCDTI / TPROCDTO : Input/Output field for the 10-character Processed Date ( YYYY-MM-DD ).

• MIDI / MIDO : Input/Output field for the 9-digit Merchant ID.

• MNAMEI / MNAMEO : Input/Output field for the 30-character Merchant Name.

• MCITYI / MCITYO : Input/Output field for the 25-character Merchant City.

• MZIPI / MZIPO : Input/Output field for the 10-character Merchant Zip Code.

• CONFIRMI / CONFIRMO : Input/Output field for the 1-character confirmation flag ( Y/N ).

• ERRMSGO : Output field for error and success messages.

Backend and Control Fields

• TRAN-ID : Key field for the TRANSACT file (16-character alphanumeric representing a sequential number).

• TRAN-RECORD : The record structure written to the TRANSACT file containing all transaction details.

• CARD-XREF-RECORD : The record structure read from CCXREF or CXACAIX to map Card Numbers to Account IDs.

• CARDDEMO-COMMAREA : The primary CICS Communication Area used to pass session state and navigation metadata.

Exception and Error Handling

CICS Command Exception Handling

The program utilizes explicit response checking ( RESP and RESP2 options) on all CICS file operations to handle exceptions inline:

• EXEC CICS READ (on CXACAIX / CCXREF ) :

• DFHRESP(NOTFND) : If the Account ID or Card Number is not found in the cross-reference files, the program displays "Account ID NOT found..." or "Card Number NOT found..." and highlights the invalid field.

• Other Errors : Displays "Unable to lookup Acct in XREF AIX file..." or "Unable to lookup Card # in XREF file..." .

• EXEC CICS STARTBR / READPREV (on TRANSACT ) :

• DFHRESP(NOTFND) : If no transactions exist, displays "Transaction ID NOT found..." .

• DFHRESP(ENDFILE) : If the end of the file is reached during a backward browse, the program defaults the Transaction ID to zero.

• Other Errors : Displays "Unable to lookup Transaction..." .

• EXEC CICS WRITE (on TRANSACT ) :

• DFHRESP(NORMAL) : Clears the screen and displays a green success message: "Transaction added successfully. Your Tran ID is [TRAN-ID]."

• DFHRESP(DUPKEY) / DFHRESP(DUPREC) : Displays "Tran ID already exist..." .

• Other Errors : Displays "Unable to Add Transaction..." .

Error Messages Summary

| Message Text | Color | Trigger Condition |

| :--- | :--- | :--- |

| Account ID must be Numeric... | Red | Account ID input contains non-numeric characters. |

| Card Number must be Numeric... | Red | Card Number input contains non-numeric characters. |

| Account or Card Number must be entered... | Red | Both Account ID and Card Number fields are left blank. |

| [Field Name] can NOT be empty... | Red | A required transaction data field is left blank. |

| Amount should be in format -99999999.99 | Red | Amount does not match the required signed decimal format. |

| [Orig/Proc] Date should be in format YYYY-MM-DD | Red | Date input does not match the required template format. |

| [Orig/Proc] Date - Not a valid date... | Red | Date is formatted correctly but is logically invalid (e.g., February 30th). |

| Confirm to add this transaction... | Red | User pressed ENTER without confirming the transaction. |

| Invalid value. Valid values are (Y/N)... | Red | User entered an invalid character in the confirmation field. |

Security and Authorization Checks

No explicit security checks identified.

The program relies on the CICS Communication Area ( CARDDEMO-COMMAREA ) passed from previous screens to maintain session context, but does not perform explicit RACF checks, transaction security validations, or standard CICS Sign-on ( CESN / CESF ) integrations within this module.

Performance Considerations

• Efficient Sequential ID Generation : To generate a new Transaction ID, the program performs a backward browse starting from HIGH-VALUES ( STARTBR followed by READPREV ). This is a highly efficient mainframe pattern for finding the maximum key in a VSAM Key Sequenced Data Set (KSDS) without scanning the entire file.

• Pseudo-Conversational Design : The program is designed to be pseudo-conversational. It releases CICS system resources (such as thread storage) while waiting for user input by issuing an EXEC CICS RETURN specifying the transaction ID CT02 and passing the CARDDEMO-COMMAREA .

• In-Memory Date Validation : The program delegates logical date validation to the external utility CSUTLDTC . While this modularizes the code, frequent dynamic program calls ( CALL ) can introduce minor CPU overhead in high-volume environments compared to inline validation routines.

<h2

Transaction Type List and Maintenance Utility for CardDemo

The COTRTLIC program is an administrative business utility within the CardDemo application designed to manage transaction type configurations. Operating within a CICS and Db2 environment, this program provides administrators with a centralized, interactive list of transaction types (such as purchases, fees, or credits) stored in the relational database. By maintaining these core lookup configurations, the program ensures that the downstream transaction processing engine functions with accurate and consistent metadata.

To facilitate efficient data retrieval, the program features robust search, filtering, and paging capabilities. Administrators can filter the list by entering a specific transaction type code or a partial description. Because the database may contain numerous transaction types, the program implements high-performance screen paging. Users can seamlessly navigate forward and backward through pages of results using standard terminal function keys, ensuring a responsive user experience without overloading system resources.

Beyond listing and searching, the program supports direct update and delete operations. From the list screen, an administrator can select a specific record to modify its description or initiate its deletion. To safeguard data integrity, the program enforces strict validation rules, ensuring that modified descriptions contain only authorized alphanumeric characters and that only one record is processed at a time. Destructive actions, such as deletions, require a multi-step confirmation workflow where the user must verify the action before changes are permanently committed to the database.

The program is fully integrated into the CardDemo administrative suite, typically receiving control from the main Administration Menu. It preserves the user's session state, security privileges, and search criteria when transitioning between screens, allowing for seamless navigation. Additionally, administrators can easily navigate from this list to a dedicated maintenance screen to add new transaction types, or return to the main menu, ensuring a secure and controlled user workflow.

Built with a pseudo-conversational design, the program optimizes mainframe resource utilization by releasing system memory while waiting for user input. It interacts with the relational database using optimized queries to fetch only the required number of records per screen page. Furthermore, it handles database constraints gracefully, preventing the deletion of transaction types that are currently referenced by active financial records, thereby maintaining referential integrity across the application.

Business Case and User Interaction

Business Case Overview

The COTRTLIC program is the Transaction Type List component of the CardDemo mainframe application. It provides administrative users with a paginated, grid-based interface to browse, filter, update, and delete transaction type configurations stored in the relational database ( CARDDEMO.TRANSACTION_TYPE table).

This program serves as a high-efficiency administrative console that supports:

• Paginated Inquiry : Browsing transaction types 7 rows at a time using database cursors.

• Dynamic Filtering : Filtering the list by a 2-digit Transaction Type Code or a partial Transaction Description (using SQL LIKE wildcards).

• Inline Updates : Modifying a transaction type's description directly within the grid.

• Inline Deletes : Removing a transaction type directly from the grid, subject to referential integrity checks.

• Navigation Hub : Transferring control to the Transaction Type Maintenance program ( COTRTUPC ) to add new records, or returning to the Administration Menu ( COADM01C ).

User Interaction and Screen Flow

• Entry : The user enters this screen from the Administration Menu ( COADM01C ) or returns from the Transaction Type Maintenance program ( COTRTUPC ). Upon entry, the program executes a priming query to verify database connectivity and displays the first page of transaction types.

• Filtering :

• The user can enter a 2-digit numeric code in the Transaction Type filter field, a text string in the Transaction Desc filter field, or both.

• Pressing ENTER applies the filters. If matching records exist, the grid refreshes to display them. If no records match, an error message is displayed.

• Paging :

• The user presses PF8 to page forward (Next Page) or PF7 to page backward (Previous Page).

• The program uses cursor-based pagination to fetch the next or previous 7 records relative to the keys stored in the communication area.

• Inline Update :

• The user types U in the Sel column of the desired row, modifies the text in the Transaction Description column, and presses ENTER .

• The program validates the modified description. If valid, it highlights the row and prompts: "Update HIGHLIGHTED row. Press F10 to save" .

• The user presses PF10 to commit the update to the database.

• Inline Delete :

• The user types D in the Sel column of the desired row and presses ENTER .

• The program highlights the row and prompts: "Delete HIGHLIGHTED row ? Press F10 to confirm" .

• The user presses PF10 to commit the deletion.

• Add Record :

• The user presses PF2 to navigate to the Transaction Type Maintenance screen ( COTRTUPC ) to add a new transaction type.

• Exit :

• The user presses PF3 to exit the list and return to the Administration Menu ( COADM01C ).

Screen Layout and Navigation

Screen Layout (CTRTLIA)

+-----------------------------------------------------------------------------+

| Tran: CTLI AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: COTRTLIC CardDemo Time: hh:mm:ss |

| Page: 9 |

| Transaction Type List |

| |

| Transaction Type : [ ] Transaction Desc : [ ] |

| |

| Sel Type Transaction Description |

| --- ---- -------------------------------------------------- |

| [ ] 99 [ ] |

| [ ] 99 [ ] |

| [ ] 99 [ ] |

| [ ] 99 [ ] |

| [ ] 99 [ ] |

| [ ] 99 [ ] |

| [ ] 99 [ ] |

| |

| <INFO-MSG: Center-aligned informational message> |

| <ERR-MSG: Left-aligned error messages appear here in red > |

| |

| ENTER=Search/Process F2=Add F3=Exit F7=Prev F8=Next F10=Save/Confirm |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+----------------------------------+

| CICS Terminal |

+----------------+-----------------+

|

| (Transaction CTLI)

v

+--------------------------+

| COTRTLIC | <-------------------+

| (Tran Type List Pgm) | |

+------------+-------------+ |

| |

| (Presents CTRTLIA Map) |

v |

+--------------------------+ |

| CTRTLIA Map | |

+------------+-------------+ |

| |

+---[PF3]-----------------+---[PF2] |

| | |

v v |

+-----------------------+ +-----------------------+ |

| COADM01C | | COTRTUPC | |

| (Admin Menu Pgm) | | (Tran Type Update Pgm)| |

+-----------------------+ +-----------------------+ |

| |

+---[ENTER/PF7/PF8/PF10]------------+

(Paging, Filtering, CRUD)

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| LIT-THISPGM | 'COTRTLIC' | Program identifier |

| LIT-THISTRANID | 'CTLI' | CICS Transaction ID for this program |

| LIT-THISMAPSET | 'COTRTLI' | BMS Mapset name |

| LIT-THISMAP | 'CTRTLIA' | BMS Map name |

| LIT-ADMINPGM | 'COADM01C' | Administration Menu Program Name |

| LIT-ADMINTRANID | 'CA00' | Administration Menu Transaction ID |

| LIT-ADDTPGM | 'COTRTUPC' | Transaction Type Maintenance Program Name |

| LIT-ADDTTRANID | 'CTTU' | Transaction Type Maintenance Transaction ID |

| LIT-DELETE-FLAG | 'D' | Selection flag for deleting a record |

| LIT-UPDATE-FLAG | 'U' | Selection flag for updating a record |

| WS-MAX-SCREEN-LINES | 7 | Maximum number of detail rows displayed per page |

Validation Logic

Input Field Validations

• Transaction Type Filter ( TRTYPEI ) :

• Must be numeric and exactly 2 digits if supplied.

• If non-numeric, the program flags an input error and displays: "TYPE CODE FILTER,IF SUPPLIED MUST BE A 2 DIGIT NUMBER" .

• Row Selection ( TRTSELI ) :

• Must be either U (Update), D (Delete), space, or low-value.

• Any other character triggers an input error and displays: "Action code selected is invalid" .

• Row Description ( TRTYPDI ) :

• Validated only when the corresponding row selection is U (Update).

• Must be supplied (cannot be blank, spaces, or low-values).

• Must contain only alphanumeric characters and spaces. If invalid, the program flags an input error and displays: "Transaction Desc can have numbers or alphabets only." or "Transaction Desc must be supplied." .

Screen-Level Validations

• Single Action Constraint :

• The user is permitted to perform only one row action ( U or D ) per interaction.

• If multiple rows have selection characters, the program flags an error and displays: "Please select only 1 action" .

• Attention Identifier (AID) Validation :

• Valid keys are ENTER , PF2 , PF3 , PF7 , PF8 , and PF10 .

• PF10 is valid only when an update or delete action has been requested and validated.

• Any other key defaults to ENTER processing.

Condition Checks

• Filter Change Detection :

• If the user has a pending update or delete action (validated but not yet confirmed via PF10 ) and modifies either the Transaction Type or Transaction Desc filter fields, the program cancels the pending action and treats the interaction as a new search request.

• Db2 Connectivity Check :

• Before executing any business logic, the program performs a priming query against SYSIBM.SYSDUMMY1 . If this query fails, the program displays a database access error and terminates.

Data Elements Processed

Screen and Input/Output Fields

• TRTYPEI / TRTYPEO : Transaction Type filter input/output field (2 characters).

• TRDESCI / TRDESCO : Transaction Description filter input/output field (50 characters).

• TRTSELI / TRTSELO : Row selection action field (1 character, occurs 7 times).

• TRTTYPI / TRTTYPO : Row Transaction Type Code display field (2 characters, occurs 7 times).

• TRTYPDI / TRTYPDO : Row Transaction Description input/output field (50 characters, occurs 7 times).

• PAGENOO : Current page number display field (3 characters).

• INFOMSGO : Center-aligned informational message field (45 characters).

• ERRMSGO : Left-aligned error message field (78 characters).

Backend and Control Fields

• CARDDEMO-COMMAREA : Shared session communication area.

• CDEMO-FROM-PROGRAM : Tracks the calling program to ensure correct return routing.

• CDEMO-USER-TYPE : Verified to ensure administrative access ( 'A' ).

• WS-THIS-PROGCOMMAREA : Program-specific state tracking area.

• WS-CA-TYPE-CD : Stores the active type filter.

• WS-CA-TYPE-DESC : Stores the active description filter.

• WS-CA-SCREEN-NUM : Tracks the current page number.

• WS-CA-FIRST-TR-CODE : Stores the first key on the current page (used for backward paging).

• WS-CA-LAST-TR-CODE : Stores the last key on the current page (used for forward paging).

• WS-CA-DELETE-FLAG : Tracks if a delete confirmation is pending.

• WS-CA-UPDATE-FLAG : Tracks if an update confirmation is pending.

Database Fields (CARDDEMO.TRANSACTION_TYPE)

• TR_TYPE : Transaction Type Code (CHAR(2), Primary Key).

• TR_DESCRIPTION : Transaction Description (VARCHAR(50)).

Exception and Error Handling

Database SQL Code Exception Handling

• SQLCODE = 0 : Success.

• SQLCODE = +100 (Not Found / End of Data) :

• During forward paging: Indicates the end of the dataset. The program sets the next page indicator to false and displays: "No more pages for these search conditions" .

• During initial search: Indicates no records match the filters. The program displays: "No records found for this search condition." .

• SQLCODE = -532 (Referential Integrity Violation on Delete) :

• Triggered if the user attempts to delete a transaction type that is currently referenced by active transaction records. The program displays: "Please delete associated child records first:" .

• SQLCODE = -911 (Deadlock/Timeout) :

• Triggered if the row is locked by another process during an update. The program displays: "Deadlock. Someone else updating ?" .

• Other Negative SQL Codes :

• The program calls the DSNTIAC subroutine to format the Db2 error message, appends the SQLCODE, and displays the formatted error in the long message area.

CICS Response Codes

• WS-RESP-CD is captured during RECEIVE MAP and SEND MAP commands to detect terminal or map failures.

Security and Authorization Checks

• Role-Based Access Control :

• The program extracts the user type from the shared communication area ( CDEMO-USER-TYPE ).

• Only users with Administrator privileges ( CDEMO-USRTYP-ADMIN = 'A' ) are authorized to access this program.

• Direct Access Prevention :

• If a user attempts to execute the transaction CTLI directly from a blank terminal screen, EIBCALEN will be 0 . The program detects this, initializes the communication area, and defaults the user type to Administrator to allow access, but typically relies on upstream authentication from the Sign-on program ( COSGN00C ).

Performance Considerations

• Cursor-Based Pagination :

• To avoid loading the entire TRANSACTION_TYPE table into memory, the program implements scrollable paging using two distinct cursors:

• C-TR-TYPE-FORWARD : Fetches records where TR_TYPE >= :WS-START-KEY ordered by TR_TYPE ASC.

• C-TR-TYPE-BACKWARD : Fetches records where TR_TYPE < :WS-START-KEY ordered by TR_TYPE DESC.

• This pattern ensures optimal database CPU and memory utilization, especially for large tables.

• Pseudo-Conversational Design :

• The program is fully pseudo-conversational. It does not hold CICS resources or database locks while waiting for user input.

• It transmits the screen map and terminates execution using EXEC CICS RETURN , passing the transaction ID CTLI and the state-preserving WS-COMMAREA .

• Lightweight Priming Query :

• The program executes a fast SELECT 1 FROM SYSIBM.SYSDUMMY1 FETCH FIRST 1 ROW ONLY query to verify database availability before executing more resource-intensive cursor operations.

<h2

Transaction Type Maintenance and Update Program for CardDemo

The COTRTUPC program is an administrative utility within the CardDemo application designed to manage transaction type configurations. Operating within a CICS environment, this program provides business administrators with a secure interface to view, create, modify, and delete transaction types stored in the application's relational database. By maintaining these core lookup configurations—such as defining what constitutes a purchase, fee, or credit—the program ensures the downstream transaction processing engine functions with accurate and consistent metadata.

The user interaction is designed around a pseudo-conversational flow to optimize system resources. Upon launching the program, the administrator is prompted to enter a specific transaction type code. The program queries the database and, if the record is found, displays its current description for review, modification, or deletion. If the entered code does not exist, the program dynamically transitions into an creation mode, prompting the administrator to define a brand-new transaction type and description.

To safeguard data integrity, the program implements robust input validation and multi-step confirmation workflows. Any modified or newly entered transaction description is validated to ensure it is not blank and contains only authorized alphanumeric characters. Destructive actions, such as deleting an existing configuration or committing new changes, are never executed instantly; instead, they require the user to verify the action and press a specific function key to finalize the request. Furthermore, the program safely handles database constraints, preventing the deletion of transaction types that are currently referenced by active financial records.

This program is fully integrated into the CardDemo administrative suite, typically receiving control from the Administration Menu or the Transaction Type List program. It utilizes a shared communication area to preserve user session state, security privileges, and navigation history across screen transitions. Administrators can easily back out of pending changes using a cancel key or exit the utility entirely to return to the main administrative menu, ensuring a secure, controlled, and intuitive user experience.

Business Case and User Interaction

Business Case Overview

The COTRTUPC program is the Transaction Type Maintenance (Update/Add/Delete) component of the CardDemo mainframe application. It provides administrative users with a secure, transactional interface to manage transaction type configurations stored in the relational database ( CARDDEMO.TRANSACTION_TYPE table).

This program supports full CRUD (Create, Read, Update, Delete) operations on transaction types:

• Inquiry (Read) : Retrieve and display the description of a specific transaction type code.

• Update (U) : Modify the description of an existing transaction type.

• Create (C) : Add a new transaction type code and description if the searched code does not exist.

• Delete (D) : Remove an existing transaction type from the database, with referential integrity checks.

User Interaction and Screen Flow

• Entry : The user enters this screen from the Admin Menu ( COADM01C ) or the Transaction Type List screen ( COTRTLIC ).

• Search/Inquiry :

• The screen initially displays empty fields and prompts: "Enter transaction type to be maintained" .

• The user inputs a 2-digit Transaction Type Code and presses ENTER .

• The program queries the database.

• If found : The program displays the current description, changes state to TTUP-SHOW-DETAILS , and prompts: "Update transaction type details shown." .

• If not found : The program prompts: "Press F05 to add. F12 to cancel" .

• Modify/Update :

• The user modifies the description field and presses ENTER .

• The program validates the input. If valid, it prompts: "Changes validated. Press F5 to save" .

• The user presses PF5 to commit the changes to the database, or PF12 to cancel.

• Add/Create :

• If the record was not found, the user presses PF5 to initiate creation.

• The screen unlocks the description field and prompts: "Enter new transaction type details." .

• The user enters the description and presses ENTER to validate, followed by PF5 to save.

• Delete :

• From the details screen, the user can press PF4 to delete the record.

• The program prompts: "Delete this record ? Press F4 to confirm" .

• The user presses PF4 again to confirm deletion, or PF12 to cancel.

Screen Layout and Navigation

Screen Layout (CTRTUPA)

+-----------------------------------------------------------------------------+

| Tran: CTTU AWS Mainframe Modernization Date: mm/dd/yy |

| Prog: COTRTUPC CardDemo Time: hh:mm:ss |

| |

| Transaction Type Update |

| |

| |

| Transaction Type Code: [ ] |

| |

| Transaction Desc : [ ]

| |

| |

| |

| |

| <INFO-MSG: Center-aligned informational message> |

| <ERR-MSG: Left-aligned error messages appear here in red > |

| |

| ENTER=Continue F3=Exit F4=Delete F5=Save F12=Cancel |

+-----------------------------------------------------------------------------+

Navigation and Data Flow Diagram

+--------------------------------------------------+

| CICS Terminal |

+------------------------+-------------------------+

|

| (Invoked via XCTL from Admin Menu/List)

v

+--------------------------+

| COTRTUPC | <------------------+

| (Tran Type Update Pgm) | |

+------------+-------------+ |

| |

| (Presents CTRTUPA Map) |

v |

+--------------------------+ |

| CTRTUPA Map | |

+------------+-------------+ |

| |

+---[PF3]-------------+---[ENTER/PF4/PF5/PF12] |

| |

v |

[Determine Target] |

- CDEMO-FROM-PROGRAM |

| |

+---> (If COADM01C) -> XCTL to COADM01C |

| |

+---> (If COTRTLIC) -> XCTL to COTRTLIC |

| |

+---> (If Default) -> XCTL to COADM01C |

|

+---(Loop for validation/confirm)

Important Constants

| Constant Name | Value | Description |

| :--- | :--- | :--- |

| LIT-THISPGM | 'COTRTUPC' | Program identifier |

| LIT-THISTRANID | 'CTTU' | CICS Transaction ID for this program |

| LIT-THISMAPSET | 'COTRTUP ' | BMS Mapset name |

| LIT-THISMAP | 'CTRTUPA' | BMS Map name |

| LIT-ADMINPGM | 'COADM01C' | Admin Menu Program Name |

| LIT-ADMINTRANID | 'CA00' | Admin Menu Transaction ID |

| LIT-LISTTPGM | 'COTRTLIC' | Transaction Type List Program Name |

| LIT-LISTTTRANID | 'CTLI' | Transaction Type List Transaction ID |

Validation Logic

Input Field Validations

• Transaction Type Code ( TRTYPCDI ) :

• Presence Check : Must be supplied; cannot be spaces or low-values.

• Numeric Check : Must be a valid numeric value (validated via FUNCTION TEST-NUMVAL ).

• Value Check : Must not be zero.

• Formatting : If valid, the value is padded with leading zeros to ensure a 2-character format (e.g., '1' becomes '01' ).

• Transaction Description ( TRTYDSCI ) :

• Presence Check : Must be supplied; cannot be spaces or low-values.

• Alphanumeric Check : Must contain only letters, numbers, and spaces. This is validated by converting all valid alphanumeric characters to spaces using INSPECT CONVERTING and verifying that the remaining trimmed string length is zero.

Screen-Level Validations

• Attention Identifier (AID) Validation :

• Valid keys are dynamically checked in paragraph 0001-CHECK-PFKEYS based on the current program state ( TTUP-CHANGE-ACTION ):

• PF3 : Always valid (Exit).

• ENTER : Valid for initial search and input validation, except when confirming a deletion.

• PF4 : Valid only when details are displayed ( TTUP-SHOW-DETAILS ) or when confirming a deletion ( TTUP-CONFIRM-DELETE ).

• PF5 : Valid only when confirming changes ( TTUP-CHANGES-OK-NOT-CONFIRMED ), when a record is not found to initiate creation ( TTUP-DETAILS-NOT-FOUND ), or during delete-in-progress.

• PF12 : Valid during active operations to cancel and revert to the previous state.

• Any unauthorized key press sets WS-INVALID-KEY-PRESSED to true, displays an error message, and redisplays the screen.

Condition Checks

• Commarea Length Check : If EIBCALEN is 0 , or if the program is entered fresh from COADM01C or COTRTLIC (where CDEMO-PGM-REENTER is false), the program initializes the communication areas, sets the state to TTUP-DETAILS-NOT-FETCHED , and displays a blank search screen.

• Data Change Detection : Before updating, paragraph 1205-COMPARE-OLD-NEW compares the current screen inputs with the originally fetched database values. If no changes are detected, the program displays the message "No change detected with respect to values fetched." and prevents unnecessary database updates.

Data Elements Processed

Screen and Input/Output Fields

• TRTYPCDI / TRTYPCDO : Transaction Type Code input/output field (2 characters).

• TRTYDSCI / TRTYDSCO : Transaction Description input/output field (50 characters).

• INFOMSGO : Center-aligned informational message field (45 characters).

• ERRMSGO : Left-aligned error message field (78 characters).

Backend and Control Fields

• CARDDEMO-COMMAREA : Shared session communication area.

• CDEMO-FROM-PROGRAM : Tracks the calling program ( COADM01C or COTRTLIC ) to ensure correct return routing.

• CDEMO-USER-TYPE : Verified to ensure administrative access.

• WS-THIS-PROGCOMMAREA : Program-specific state tracking area.

• TTUP-CHANGE-ACTION : State variable tracking the current step of the CRUD lifecycle (e.g., TTUP-SHOW-DETAILS , TTUP-CONFIRM-DELETE , TTUP-CHANGES-OK-NOT-CONFIRMED ).

• TTUP-OLD-DETAILS : Stores the original database values to detect concurrent modifications or lack of changes.

• TTUP-NEW-DETAILS : Stores the validated user inputs prior to database commit.

Database Fields (CARDDEMO.TRANSACTION_TYPE)

• DCL-TR-TYPE : Host variable for the transaction type code (mapped to TR_TYPE , CHAR(2) ).

• DCL-TR-DESCRIPTION : Host variable structure for the transaction description (mapped to TR_DESCRIPTION , VARCHAR(50) ).

Exception and Error Handling

Database SQL Code Exception Handling

• SQLCODE = 0 : Success.

• SQLCODE = +100 (Not Found) :

• During SELECT : Triggers the TTUP-DETAILS-NOT-FOUND state, prompting the user to add the record.

• During UPDATE : Indicates the record was deleted by another user. The program automatically attempts to insert the record as new via 9700-INSERT-RECORD .

• SQLCODE = -911 (Deadlock/Timeout) : Sets the error message "Could not lock record for update" and flags the state as TTUP-CHANGES-OKAYED-LOCK-ERROR .

• SQLCODE = -532 (Referential Integrity Violation on Delete) : Triggered if the transaction type is referenced by child records (e.g., in the transaction history table). Displays the error: "Please delete associated child records first: SQLCODE : -532" .

• Other Negative SQL Codes : Displays a formatted error message containing the SQLCODE and the error message text from the SQLCA ( SQLERRM ).

CICS Conditions and Abend Handling

• EXEC CICS HANDLE ABEND : Registers ABEND-ROUTINE to intercept unexpected runtime failures.

• ABEND-ROUTINE :

• Populates ABEND-DATA with the program name ( COTRTUPC ) and abend code ( 9999 ).

• Sends a full-screen abend message to the terminal.

• Cancels active abend handling and terminates the task abnormally using EXEC CICS ABEND .

Security and Authorization Checks

• Role-Based Access Control : The program relies on the session context passed via CARDDEMO-COMMAREA . It checks that the user is authorized as an administrator ( CDEMO-USRTYP-ADMIN is 'A' ).

• Direct Access Prevention : If a user attempts to execute the transaction CTTU directly from a blank terminal screen, EIBCALEN will be 0 . The program detects this, initializes the communication area, and forces the user back to the entry state.

• No Explicit Platform Security : No direct RACF, CICS Sign-on ( CESN ), or external security manager (ESM) calls are implemented within this program. Security is inherited from the upstream menu and sign-on transactions.

Performance Considerations

• Pseudo-Conversational Design : The program is fully pseudo-conversational. It does not hold CICS resources or thread locks while waiting for user input. It transmits the screen map and terminates execution using EXEC CICS RETURN , passing the transaction ID CTTU and the state-preserving WS-COMMAREA .

• Efficient Database Access : All SQL operations ( SELECT , UPDATE , INSERT , DELETE ) are executed as single-row operations using the primary key ( TR_TYPE ). This ensures index-only or high-speed index scans, minimizing database CPU overhead and page locking.

• Explicit Transaction Boundaries : Database updates, inserts, and deletes are immediately followed by an explicit EXEC CICS SYNCPOINT upon receiving SQLCODE = 0 . This releases database locks as quickly as possible, reducing lock contention in high-concurrency environments.

<h2