Chapter 28 Exercises: Batch Processing Patterns and Design
Tier 1: Recall (Exercises 1-7)
Exercise 1: Batch Pattern Identification
Identify which batch processing pattern each of the following scenarios represents:
a) A program reads a sorted employee file and produces a report with subtotals by department and grand totals for the entire company. b) A program reads a master customer file and a sorted transaction file, applying inserts, updates, and deletes to produce a new master file. c) A program reads account records from a DB2 database, validates and reformats them, and writes the output as a sequential file for transmission to a regulatory agency. d) A program saves its position and accumulators to a checkpoint file every 50,000 records so it can resume after a failure. e) A program reads two pre-sorted regional sales files and produces a single national sales file in sort order.
Solution:
a) Control break processing -- The program detects changes in the department field and prints subtotals at each break level.
b) Sequential master file update (balanced line algorithm) -- Two sorted files are processed in parallel, applying transactions to the master to produce a new master.
c) Extract-Transform-Load (ETL) -- Data is extracted from a source (DB2), transformed (validated and reformatted), and loaded into a target (sequential file).
d) Checkpoint/restart -- The program periodically saves its state to enable restart from the last checkpoint rather than from the beginning.
e) File matching/merging -- Two sorted files are interleaved to produce a single sorted output.
Exercise 2: Read-Ahead Technique
Explain why the following "read-ahead" structure is preferred over reading at the beginning of the loop. What problem does it prevent?
PERFORM 1000-READ-FIRST-RECORD.
PERFORM 2000-PROCESS-RECORDS
UNTIL WS-EOF = 'Y'.
PERFORM 3000-FINALIZE.
STOP RUN.
2000-PROCESS-RECORDS.
PERFORM 2100-PROCESS-CURRENT-RECORD.
PERFORM 1000-READ-NEXT-RECORD.
Solution:
The read-ahead technique reads the first record before entering the processing loop, and reads the next record at the end of each iteration (after processing the current record). This structure prevents two problems:
-
Processing a record after end-of-file: If the read were at the beginning of the loop, the AT END condition would be detected, but the processing logic would still execute on whatever data happened to be in the record buffer. With read-ahead, when AT END is detected, the loop exits immediately without processing invalid data.
-
Empty file handling: If the input file is empty, the first read sets WS-EOF to 'Y', and the loop never executes. Without read-ahead, the program might attempt to process an uninitialized record buffer before detecting the empty file.
The read-ahead pattern is the universal standard for COBOL batch processing because it provides clean, predictable end-of-file handling.
Exercise 3: Return Code Conventions
A batch COBOL program finishes with the following statistics: - 1,000,000 records read - 998,500 records processed successfully - 1,500 records written to the error file
The error threshold is configured at 1% (10,000 records). What return code should the program set? Explain the standard mainframe return code conventions.
Solution:
The program should set RETURN-CODE = 4 (Warning).
1,500 rejected records out of 1,000,000 is 0.15%, which is below the 1% error threshold. The program completed its work, but some records were rejected, so a warning is appropriate.
Standard mainframe return code conventions:
| RC | Meaning | When to Use |
|---|---|---|
| 0 | Success | All records processed, no errors |
| 4 | Warning | Processing completed, but some issues detected (errors below threshold) |
| 8 | Error | Processing may be incomplete or unreliable (errors exceed threshold) |
| 12 | Severe error | Processing failed; significant data issues |
| 16 | Critical | Processing aborted; unrecoverable error |
EVALUATE TRUE
WHEN WS-ERROR-COUNT = 0
MOVE 0 TO RETURN-CODE
WHEN WS-ERROR-COUNT < WS-ERROR-THRESHOLD
MOVE 4 TO RETURN-CODE
WHEN OTHER
MOVE 8 TO RETURN-CODE
END-EVALUATE.
Exercise 4: Control Break Accumulators
A three-level control break report is sorted by Region, Branch, and Teller. The program uses four accumulators: WS-TELLER-TOTAL, WS-BRANCH-TOTAL, WS-REGION-TOTAL, and WS-GRAND-TOTAL. When a teller break occurs, describe precisely:
a) What is printed b) Which accumulators are updated c) Which accumulators are reset
Solution:
When a teller break occurs (the teller field changes between consecutive records):
a) Printed: A subtotal line showing the teller's name/ID and the WS-TELLER-TOTAL (the sum of all transaction amounts for that teller within the current branch).
b) Updated: WS-BRANCH-TOTAL is updated by adding WS-TELLER-TOTAL to it. This "rolls up" the teller's total into the branch accumulator.
c) Reset: WS-TELLER-TOTAL is reset to zero. The previous teller control value (WS-PREV-TELLER) is updated to the new teller's value.
The code:
3000-TELLER-BREAK.
MOVE WS-TELLER-TOTAL TO RPT-SUBTOTAL.
MOVE WS-PREV-TELLER TO RPT-TELLER-ID.
WRITE REPORT-RECORD FROM WS-TELLER-LINE
AFTER ADVANCING 1 LINE.
ADD WS-TELLER-TOTAL TO WS-BRANCH-TOTAL.
MOVE 0 TO WS-TELLER-TOTAL.
MOVE INPUT-TELLER TO WS-PREV-TELLER.
Important: Higher-level breaks (branch, region) cascade through lower-level breaks. A branch break triggers a teller break first, then the branch subtotal is printed. A region break triggers both a teller break and a branch break before printing the region subtotal.
Exercise 5: Balanced Line Algorithm Tracing
Trace the execution of the balanced line algorithm for the following master and transaction files. Show the contents of the new master file and any error messages produced.
Master file (sorted by account number):
ACCT-1001 BALANCE=5000.00 STATUS=ACTIVE
ACCT-1003 BALANCE=2500.00 STATUS=ACTIVE
ACCT-1005 BALANCE=10000.00 STATUS=ACTIVE
ACCT-1007 BALANCE=750.00 STATUS=CLOSED
Transaction file (sorted by account number):
ACCT-1001 TYPE=C AMOUNT=500.00 (Change: add to balance)
ACCT-1002 TYPE=A BALANCE=1000.00 (Add new account)
ACCT-1003 TYPE=D (Delete account)
ACCT-1005 TYPE=C AMOUNT=-200.00 (Change: subtract from balance)
ACCT-1006 TYPE=C AMOUNT=100.00 (Change: no master exists)
Solution:
Step-by-step trace:
-
Read master: ACCT-1001. Read trans: ACCT-1001. Keys match. - Transaction type C: Update balance 5000.00 + 500.00 = 5500.00. - Write to new master: ACCT-1001 BALANCE=5500.00 STATUS=ACTIVE. - Read next master: ACCT-1003. Read next trans: ACCT-1002.
-
Master ACCT-1003 > Trans ACCT-1002. Unmatched transaction. - Transaction type A: Add new account. - Write to new master: ACCT-1002 BALANCE=1000.00 STATUS=ACTIVE. - Read next trans: ACCT-1003.
-
Master ACCT-1003 = Trans ACCT-1003. Keys match. - Transaction type D: Delete account. - Do NOT write master record (effectively deleted). - Read next master: ACCT-1005. Read next trans: ACCT-1005.
-
Master ACCT-1005 = Trans ACCT-1005. Keys match. - Transaction type C: Update balance 10000.00 + (-200.00) = 9800.00. - Write to new master: ACCT-1005 BALANCE=9800.00 STATUS=ACTIVE. - Read next master: ACCT-1007. Read next trans: ACCT-1006.
-
Master ACCT-1007 > Trans ACCT-1006. Unmatched transaction. - Transaction type C: Change, but no master exists. - Error: "Change transaction ACCT-1006 has no matching master." - Write to error file. - Read next trans: HIGH-VALUES (end of trans file).
-
Master ACCT-1007 < Trans HIGH-VALUES. Unmatched master. - Write to new master unchanged: ACCT-1007 BALANCE=750.00 STATUS=CLOSED. - Read next master: HIGH-VALUES.
-
Both keys = HIGH-VALUES. Processing complete.
New master file:
ACCT-1001 BALANCE=5500.00 STATUS=ACTIVE
ACCT-1002 BALANCE=1000.00 STATUS=ACTIVE
ACCT-1005 BALANCE=9800.00 STATUS=ACTIVE
ACCT-1007 BALANCE=750.00 STATUS=CLOSED
Error file:
ACCT-1006 TYPE=C ERROR: Change transaction has no matching master
Exercise 6: Header/Trailer Record Validation
A batch file has the following header and trailer records:
H20260115ACME-BANK 000050000
D...record 1...
D...record 2...
...
T000049998 0000000125000000
Header fields: Record type ('H'), file date (YYYYMMDD), source system (13 chars), expected record count (9 digits). Trailer fields: Record type ('T'), actual record count (9 digits), hash total of account numbers (16 digits).
The program reads 49,998 detail records ('D' type). What validations should the program perform, and what errors should it report?
Solution:
The program should perform these validations:
-
Header validation: - Verify record type is 'H' - Verify file date is a valid date and is today's date (or within acceptable range) - Verify source system matches expected value ('ACME-BANK') - Store expected record count (50,000) for later comparison
-
Trailer validation: - Verify record type is 'T' - Compare actual record count in trailer (49,998) to program's own count of detail records processed - Compare hash total in trailer to program's calculated hash total of account numbers - Compare trailer record count (49,998) to header expected count (50,000)
-
Errors to report: - Record count mismatch: Header expected 50,000 records but trailer shows 49,998 and program counted 49,998. This 2-record discrepancy should be reported as a warning or error depending on tolerance. It could indicate records were lost between creation and transmission. - The program should report: "Expected: 50,000, Trailer: 49,998, Counted: 49,998 -- MISMATCH with header." - If the program count differs from the trailer count, that indicates records were lost during processing, which is a more severe error.
Exercise 7: Batch vs Online Decision
For each of the following banking operations, determine whether it should be implemented as a batch process or an online (CICS) transaction. Explain your reasoning.
a) Applying daily interest accrual to 5 million savings accounts b) Processing a single ATM withdrawal request c) Generating monthly customer statements for all accounts d) Looking up an account balance for a teller e) Scanning all transactions for suspicious activity patterns (anti-money-laundering) f) Processing a wire transfer initiated by a customer
Solution:
a) Batch -- High volume (5 million accounts), periodic (daily), sequential processing of every account, no user interaction needed. This is a classic batch workload.
b) Online -- Single transaction, real-time response required (customer is waiting at the ATM), random access to one account.
c) Batch -- High volume (all accounts), periodic (monthly), generates large output (print files or electronic delivery), runs during off-peak hours.
d) Online -- Single record lookup, real-time response required (teller is serving a customer), random access by account number.
e) Batch -- Must scan all transactions (high volume), pattern detection requires analyzing multiple records across time, resource-intensive calculations, results reviewed later by analysts.
f) Online -- Single transaction, real-time processing required (customer expects immediate confirmation), involves updates to specific accounts. However, the downstream settlement of the wire transfer may be batch.
Tier 2: Understand (Exercises 8-14)
Exercise 8: Multi-Level Control Break Program
Write a complete COBOL program that reads a sorted transaction file and produces a report with three levels of control breaks: Region, Branch, and Account. The report should show:
- Detail lines: Transaction date, description, amount
- Account subtotal: Total debits and credits for the account
- Branch subtotal: Total debits, credits, and net for the branch
- Region subtotal: Total debits, credits, and net for the region
- Grand total: Total debits, credits, and net for the entire file
Input record layout (FB, LRECL=100):
01 TRANS-RECORD.
05 TR-REGION PIC X(04).
05 TR-BRANCH PIC X(06).
05 TR-ACCOUNT PIC X(10).
05 TR-DATE PIC X(10).
05 TR-DESCRIPTION PIC X(30).
05 TR-AMOUNT PIC S9(09)V99 COMP-3.
05 TR-TYPE PIC X(01).
88 TR-DEBIT VALUE 'D'.
88 TR-CREDIT VALUE 'C'.
05 TR-FILLER PIC X(33).
Solution:
IDENTIFICATION DIVISION.
PROGRAM-ID. CTRLBRK.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT TRANS-FILE ASSIGN TO TRANSIN
FILE STATUS IS WS-TRANS-STATUS.
SELECT REPORT-FILE ASSIGN TO RPTFILE
FILE STATUS IS WS-RPT-STATUS.
DATA DIVISION.
FILE SECTION.
FD TRANS-FILE
RECORDING MODE IS F
RECORD CONTAINS 100 CHARACTERS.
01 TRANS-RECORD.
05 TR-REGION PIC X(04).
05 TR-BRANCH PIC X(06).
05 TR-ACCOUNT PIC X(10).
05 TR-DATE PIC X(10).
05 TR-DESCRIPTION PIC X(30).
05 TR-AMOUNT PIC S9(09)V99 COMP-3.
05 TR-TYPE PIC X(01).
88 TR-DEBIT VALUE 'D'.
88 TR-CREDIT VALUE 'C'.
05 TR-FILLER PIC X(33).
FD REPORT-FILE
RECORDING MODE IS F
RECORD CONTAINS 133 CHARACTERS.
01 REPORT-RECORD PIC X(133).
WORKING-STORAGE SECTION.
01 WS-TRANS-STATUS PIC X(02).
01 WS-RPT-STATUS PIC X(02).
01 WS-EOF PIC X(01) VALUE 'N'.
88 END-OF-FILE VALUE 'Y'.
01 WS-RECORDS-READ PIC 9(09) VALUE 0.
01 WS-PREV-REGION PIC X(04).
01 WS-PREV-BRANCH PIC X(06).
01 WS-PREV-ACCOUNT PIC X(10).
01 WS-FIRST-RECORD PIC X(01) VALUE 'Y'.
01 WS-ACCT-DEBITS PIC S9(13)V99 VALUE 0.
01 WS-ACCT-CREDITS PIC S9(13)V99 VALUE 0.
01 WS-BRANCH-DEBITS PIC S9(13)V99 VALUE 0.
01 WS-BRANCH-CREDITS PIC S9(13)V99 VALUE 0.
01 WS-REGION-DEBITS PIC S9(13)V99 VALUE 0.
01 WS-REGION-CREDITS PIC S9(13)V99 VALUE 0.
01 WS-GRAND-DEBITS PIC S9(13)V99 VALUE 0.
01 WS-GRAND-CREDITS PIC S9(13)V99 VALUE 0.
01 WS-DETAIL-LINE.
05 FILLER PIC X(01) VALUE SPACE.
05 DL-DATE PIC X(10).
05 FILLER PIC X(03) VALUE SPACES.
05 DL-DESC PIC X(30).
05 FILLER PIC X(03) VALUE SPACES.
05 DL-AMOUNT PIC ZZZ,ZZZ,ZZ9.99-.
05 FILLER PIC X(72) VALUE SPACES.
01 WS-ACCT-TOTAL-LINE.
05 FILLER PIC X(01) VALUE SPACE.
05 FILLER PIC X(20)
VALUE ' Account Total: '.
05 AT-DEBITS PIC ZZZ,ZZZ,ZZ9.99-.
05 FILLER PIC X(03) VALUE SPACES.
05 AT-CREDITS PIC ZZZ,ZZZ,ZZ9.99-.
05 FILLER PIC X(75) VALUE SPACES.
PROCEDURE DIVISION.
0000-MAIN.
PERFORM 1000-INITIALIZE.
PERFORM 1100-READ-TRANS.
IF NOT END-OF-FILE
MOVE TR-REGION TO WS-PREV-REGION
MOVE TR-BRANCH TO WS-PREV-BRANCH
MOVE TR-ACCOUNT TO WS-PREV-ACCOUNT
MOVE 'N' TO WS-FIRST-RECORD
END-IF.
PERFORM 2000-PROCESS
UNTIL END-OF-FILE.
IF WS-FIRST-RECORD = 'N'
PERFORM 3100-ACCOUNT-BREAK
PERFORM 3200-BRANCH-BREAK
PERFORM 3300-REGION-BREAK
END-IF.
PERFORM 3400-GRAND-TOTAL.
PERFORM 4000-FINALIZE.
STOP RUN.
1000-INITIALIZE.
OPEN INPUT TRANS-FILE.
OPEN OUTPUT REPORT-FILE.
1100-READ-TRANS.
READ TRANS-FILE
AT END SET END-OF-FILE TO TRUE
END-READ.
IF NOT END-OF-FILE
ADD 1 TO WS-RECORDS-READ
END-IF.
2000-PROCESS.
EVALUATE TRUE
WHEN TR-REGION NOT = WS-PREV-REGION
PERFORM 3100-ACCOUNT-BREAK
PERFORM 3200-BRANCH-BREAK
PERFORM 3300-REGION-BREAK
WHEN TR-BRANCH NOT = WS-PREV-BRANCH
PERFORM 3100-ACCOUNT-BREAK
PERFORM 3200-BRANCH-BREAK
WHEN TR-ACCOUNT NOT = WS-PREV-ACCOUNT
PERFORM 3100-ACCOUNT-BREAK
END-EVALUATE.
PERFORM 2100-PROCESS-DETAIL.
PERFORM 1100-READ-TRANS.
2100-PROCESS-DETAIL.
MOVE TR-DATE TO DL-DATE.
MOVE TR-DESCRIPTION TO DL-DESC.
MOVE TR-AMOUNT TO DL-AMOUNT.
WRITE REPORT-RECORD FROM WS-DETAIL-LINE
AFTER ADVANCING 1 LINE.
IF TR-DEBIT
ADD TR-AMOUNT TO WS-ACCT-DEBITS
ELSE
ADD TR-AMOUNT TO WS-ACCT-CREDITS
END-IF.
3100-ACCOUNT-BREAK.
MOVE WS-ACCT-DEBITS TO AT-DEBITS.
MOVE WS-ACCT-CREDITS TO AT-CREDITS.
WRITE REPORT-RECORD FROM WS-ACCT-TOTAL-LINE
AFTER ADVANCING 1 LINE.
ADD WS-ACCT-DEBITS TO WS-BRANCH-DEBITS.
ADD WS-ACCT-CREDITS TO WS-BRANCH-CREDITS.
MOVE 0 TO WS-ACCT-DEBITS.
MOVE 0 TO WS-ACCT-CREDITS.
MOVE TR-ACCOUNT TO WS-PREV-ACCOUNT.
3200-BRANCH-BREAK.
ADD WS-BRANCH-DEBITS TO WS-REGION-DEBITS.
ADD WS-BRANCH-CREDITS TO WS-REGION-CREDITS.
MOVE 0 TO WS-BRANCH-DEBITS.
MOVE 0 TO WS-BRANCH-CREDITS.
MOVE TR-BRANCH TO WS-PREV-BRANCH.
3300-REGION-BREAK.
ADD WS-REGION-DEBITS TO WS-GRAND-DEBITS.
ADD WS-REGION-CREDITS TO WS-GRAND-CREDITS.
MOVE 0 TO WS-REGION-DEBITS.
MOVE 0 TO WS-REGION-CREDITS.
MOVE TR-REGION TO WS-PREV-REGION.
3400-GRAND-TOTAL.
DISPLAY 'GRAND TOTAL DEBITS: ' WS-GRAND-DEBITS.
DISPLAY 'GRAND TOTAL CREDITS: ' WS-GRAND-CREDITS.
4000-FINALIZE.
DISPLAY 'RECORDS READ: ' WS-RECORDS-READ.
CLOSE TRANS-FILE.
CLOSE REPORT-FILE.
Exercise 9: Sequential Master Update Program
Write the core paragraphs (the balanced line algorithm) for a sequential master file update program for a bank's account master. The program must handle three transaction types:
- A (Add): Create a new account. Error if account already exists.
- C (Change): Update account balance. Error if account does not exist.
- D (Delete): Mark account as closed. Error if account does not exist.
Multiple transactions may exist for the same account key. Process all transactions for a key before moving to the next key.
Master record:
01 MASTER-RECORD.
05 MR-ACCOUNT PIC X(10).
05 MR-CUST-NAME PIC X(30).
05 MR-BALANCE PIC S9(11)V99 COMP-3.
05 MR-STATUS PIC X(01).
05 MR-FILLER PIC X(50).
Transaction record:
01 TRANS-RECORD.
05 TR-ACCOUNT PIC X(10).
05 TR-TYPE PIC X(01).
05 TR-AMOUNT PIC S9(11)V99 COMP-3.
05 TR-CUST-NAME PIC X(30).
05 TR-FILLER PIC X(50).
Solution:
2000-PROCESS-LOOP.
PERFORM UNTIL WS-MASTER-KEY = HIGH-VALUES
AND WS-TRANS-KEY = HIGH-VALUES
EVALUATE TRUE
WHEN WS-MASTER-KEY < WS-TRANS-KEY
PERFORM 2100-WRITE-MASTER-UNCHANGED
PERFORM 1100-READ-MASTER
WHEN WS-MASTER-KEY = WS-TRANS-KEY
PERFORM 2200-APPLY-TRANSACTIONS
WHEN WS-MASTER-KEY > WS-TRANS-KEY
PERFORM 2300-UNMATCHED-TRANS
END-EVALUATE
END-PERFORM.
2100-WRITE-MASTER-UNCHANGED.
WRITE NEW-MASTER-RECORD FROM MASTER-RECORD.
ADD 1 TO WS-MASTER-WRITTEN.
2200-APPLY-TRANSACTIONS.
MOVE MASTER-RECORD TO WS-WORK-MASTER.
MOVE 'N' TO WS-DELETE-FLAG.
PERFORM 2210-PROCESS-TRANS-GROUP
UNTIL WS-TRANS-KEY NOT = WS-MASTER-KEY.
IF WS-DELETE-FLAG = 'N'
WRITE NEW-MASTER-RECORD FROM WS-WORK-MASTER
ADD 1 TO WS-MASTER-WRITTEN
ELSE
ADD 1 TO WS-MASTER-DELETED
END-IF.
PERFORM 1100-READ-MASTER.
2210-PROCESS-TRANS-GROUP.
EVALUATE TR-TYPE
WHEN 'A'
MOVE 'Duplicate add' TO WS-ERR-MSG
PERFORM 9100-WRITE-ERROR
WHEN 'C'
ADD TR-AMOUNT TO WM-BALANCE
ADD 1 TO WS-CHANGES-APPLIED
WHEN 'D'
MOVE 'C' TO WM-STATUS
MOVE 'Y' TO WS-DELETE-FLAG
ADD 1 TO WS-DELETES-APPLIED
WHEN OTHER
MOVE 'Invalid trans type' TO WS-ERR-MSG
PERFORM 9100-WRITE-ERROR
END-EVALUATE.
PERFORM 1200-READ-TRANS.
2300-UNMATCHED-TRANS.
EVALUATE TR-TYPE
WHEN 'A'
INITIALIZE WS-WORK-MASTER
MOVE TR-ACCOUNT TO WM-ACCOUNT
MOVE TR-CUST-NAME TO WM-CUST-NAME
MOVE TR-AMOUNT TO WM-BALANCE
MOVE 'A' TO WM-STATUS
WRITE NEW-MASTER-RECORD FROM WS-WORK-MASTER
ADD 1 TO WS-MASTER-ADDED
WHEN OTHER
MOVE 'No matching master' TO WS-ERR-MSG
PERFORM 9100-WRITE-ERROR
END-EVALUATE.
PERFORM 1200-READ-TRANS.
Exercise 10: Checkpoint/Restart Implementation
Write the checkpoint writing and restart reading paragraphs for a batch program that processes 10 million account records. The checkpoint should be written every 100,000 records and must save:
- Current record count
- Running total of all account balances
- Running total of all debits applied
- Running total of all credits applied
- The last processed account number (for repositioning)
- A timestamp
On restart, the program must: 1. Read the checkpoint file 2. Restore all accumulators 3. Reposition the input file by reading and discarding records until reaching the checkpoint position 4. Resume normal processing
Solution:
01 WS-CHECKPOINT-REC.
05 CK-RECORD-COUNT PIC 9(10).
05 CK-BALANCE-TOTAL PIC S9(15)V99 COMP-3.
05 CK-DEBIT-TOTAL PIC S9(15)V99 COMP-3.
05 CK-CREDIT-TOTAL PIC S9(15)V99 COMP-3.
05 CK-LAST-ACCOUNT PIC X(10).
05 CK-TIMESTAMP PIC X(26).
05 CK-EYE-CATCHER PIC X(08) VALUE 'CKPT-OK '.
01 WS-RESTART-MODE PIC X(01) VALUE 'N'.
01 WS-CHECKPOINT-INTERVAL PIC 9(06) VALUE 100000.
5000-WRITE-CHECKPOINT.
MOVE WS-RECORD-COUNT TO CK-RECORD-COUNT.
MOVE WS-BALANCE-TOTAL TO CK-BALANCE-TOTAL.
MOVE WS-DEBIT-TOTAL TO CK-DEBIT-TOTAL.
MOVE WS-CREDIT-TOTAL TO CK-CREDIT-TOTAL.
MOVE WS-LAST-ACCOUNT TO CK-LAST-ACCOUNT.
MOVE FUNCTION CURRENT-DATE TO CK-TIMESTAMP.
MOVE 'CKPT-OK ' TO CK-EYE-CATCHER.
OPEN OUTPUT CHECKPOINT-FILE.
WRITE CHECKPOINT-RECORD FROM WS-CHECKPOINT-REC.
CLOSE CHECKPOINT-FILE.
DISPLAY 'CHECKPOINT AT RECORD ' WS-RECORD-COUNT
' ACCOUNT ' WS-LAST-ACCOUNT
' TIME ' CK-TIMESTAMP.
5100-CHECK-CHECKPOINT.
IF FUNCTION MOD(WS-RECORD-COUNT,
WS-CHECKPOINT-INTERVAL) = 0
PERFORM 5000-WRITE-CHECKPOINT
END-IF.
6000-RESTART-FROM-CHECKPOINT.
OPEN INPUT CHECKPOINT-FILE.
READ CHECKPOINT-FILE INTO WS-CHECKPOINT-REC
AT END
DISPLAY 'No checkpoint found - starting fresh'
CLOSE CHECKPOINT-FILE
MOVE 'N' TO WS-RESTART-MODE
EXIT PARAGRAPH
END-READ.
CLOSE CHECKPOINT-FILE.
IF CK-EYE-CATCHER NOT = 'CKPT-OK '
DISPLAY 'Invalid checkpoint - starting fresh'
MOVE 'N' TO WS-RESTART-MODE
EXIT PARAGRAPH
END-IF.
DISPLAY 'RESTARTING FROM CHECKPOINT:'.
DISPLAY ' RECORDS: ' CK-RECORD-COUNT.
DISPLAY ' LAST ACCOUNT: ' CK-LAST-ACCOUNT.
DISPLAY ' TIMESTAMP: ' CK-TIMESTAMP.
MOVE CK-RECORD-COUNT TO WS-RECORD-COUNT.
MOVE CK-BALANCE-TOTAL TO WS-BALANCE-TOTAL.
MOVE CK-DEBIT-TOTAL TO WS-DEBIT-TOTAL.
MOVE CK-CREDIT-TOTAL TO WS-CREDIT-TOTAL.
MOVE 'Y' TO WS-RESTART-MODE.
* Reposition input by reading and discarding
DISPLAY 'Repositioning to record '
WS-RECORD-COUNT '...'.
PERFORM CK-RECORD-COUNT TIMES
READ INPUT-FILE INTO WS-DISCARD-REC
AT END
DISPLAY 'ERROR: EOF before checkpoint'
MOVE 16 TO RETURN-CODE
STOP RUN
END-READ
END-PERFORM.
DISPLAY 'Repositioning complete. Resuming.'.
Exercise 11: ETL Validation Program
Write a complete COBOL program that performs ETL processing for a bank's daily transaction extract. The program must:
- Read a fixed-length input file from an external system
- Validate each record: - Account number must be 10 numeric digits - Transaction date must be a valid date in YYYYMMDD format - Amount must be positive and less than $1,000,000 - Transaction code must be 'DEP', 'WDR', 'TFR', or 'FEE'
- Transform valid records: - Convert amount from external format (PIC 9(09)V99 display) to internal format (PIC S9(09)V99 COMP-3) - Derive a fiscal quarter field from the transaction date
- Write valid records to a clean output file
- Write invalid records to a reject file with error codes
- Display statistics: total read, valid, rejected, by error type
Hint: Use a validation flag that accumulates error codes as each field is checked.
Exercise 12: Hash Total and Control Total Verification
Write the paragraphs for a batch program that calculates and verifies three types of totals:
a) Record count: Number of detail records processed b) Control total: Sum of all transaction amounts (monetary total) c) Hash total: Sum of all account numbers (non-meaningful numeric total used to detect lost or duplicated records)
The program reads a trailer record containing expected values for all three totals. Write the comparison logic that reports discrepancies and sets appropriate return codes.
Solution:
01 WS-COUNTS.
05 WS-RECORD-COUNT PIC 9(09) VALUE 0.
05 WS-CONTROL-TOTAL PIC S9(15)V99 VALUE 0.
05 WS-HASH-TOTAL PIC 9(15) VALUE 0.
01 WS-TRAILER-COUNTS.
05 TL-RECORD-COUNT PIC 9(09).
05 TL-CONTROL-TOTAL PIC S9(15)V99.
05 TL-HASH-TOTAL PIC 9(15).
01 WS-MISMATCH-FLAG PIC X(01) VALUE 'N'.
2100-ACCUMULATE-TOTALS.
ADD 1 TO WS-RECORD-COUNT.
ADD TR-AMOUNT TO WS-CONTROL-TOTAL.
ADD FUNCTION NUMVAL(TR-ACCOUNT) TO WS-HASH-TOTAL.
3500-VERIFY-TOTALS.
MOVE 'N' TO WS-MISMATCH-FLAG.
IF WS-RECORD-COUNT NOT = TL-RECORD-COUNT
DISPLAY 'RECORD COUNT MISMATCH:'
DISPLAY ' EXPECTED: ' TL-RECORD-COUNT
DISPLAY ' ACTUAL: ' WS-RECORD-COUNT
COMPUTE WS-DIFF =
TL-RECORD-COUNT - WS-RECORD-COUNT
DISPLAY ' DIFFERENCE: ' WS-DIFF
MOVE 'Y' TO WS-MISMATCH-FLAG
END-IF.
IF WS-CONTROL-TOTAL NOT = TL-CONTROL-TOTAL
DISPLAY 'CONTROL TOTAL MISMATCH:'
DISPLAY ' EXPECTED: ' TL-CONTROL-TOTAL
DISPLAY ' ACTUAL: ' WS-CONTROL-TOTAL
COMPUTE WS-DIFF =
TL-CONTROL-TOTAL - WS-CONTROL-TOTAL
DISPLAY ' DIFFERENCE: ' WS-DIFF
MOVE 'Y' TO WS-MISMATCH-FLAG
END-IF.
IF WS-HASH-TOTAL NOT = TL-HASH-TOTAL
DISPLAY 'HASH TOTAL MISMATCH:'
DISPLAY ' EXPECTED: ' TL-HASH-TOTAL
DISPLAY ' ACTUAL: ' WS-HASH-TOTAL
MOVE 'Y' TO WS-MISMATCH-FLAG
END-IF.
IF WS-MISMATCH-FLAG = 'Y'
DISPLAY '*** TOTAL VERIFICATION FAILED ***'
MOVE 8 TO RETURN-CODE
ELSE
DISPLAY 'ALL TOTALS VERIFIED SUCCESSFULLY'
END-IF.
Exercise 13: Error Handling with Threshold
Write the error handling framework for a batch program that processes loan payment records. The framework must:
- Count errors by category (invalid account, invalid amount, invalid date, duplicate payment)
- Write each error to a reject file with the error category and a descriptive message
- Continue processing after non-fatal errors
- Abort processing if: - The total error count exceeds a configurable threshold (default: 1% of records read) - Any single error category exceeds 500 occurrences - A fatal error occurs (file I/O failure, data corruption)
- Set the return code based on the outcome
Solution:
01 WS-ERROR-COUNTS.
05 WS-ERR-INVALID-ACCT PIC 9(06) VALUE 0.
05 WS-ERR-INVALID-AMT PIC 9(06) VALUE 0.
05 WS-ERR-INVALID-DATE PIC 9(06) VALUE 0.
05 WS-ERR-DUPLICATE PIC 9(06) VALUE 0.
05 WS-ERR-TOTAL PIC 9(08) VALUE 0.
01 WS-THRESHOLDS.
05 WS-PCT-THRESHOLD PIC 9(03) VALUE 1.
05 WS-CAT-THRESHOLD PIC 9(06) VALUE 500.
01 WS-ABORT-FLAG PIC X(01) VALUE 'N'.
9000-RECORD-ERROR.
ADD 1 TO WS-ERR-TOTAL.
EVALUATE WS-ERROR-CATEGORY
WHEN 'ACCT'
ADD 1 TO WS-ERR-INVALID-ACCT
IF WS-ERR-INVALID-ACCT > WS-CAT-THRESHOLD
MOVE 'Y' TO WS-ABORT-FLAG
DISPLAY 'ABORT: Invalid account threshold'
END-IF
WHEN 'AMNT'
ADD 1 TO WS-ERR-INVALID-AMT
IF WS-ERR-INVALID-AMT > WS-CAT-THRESHOLD
MOVE 'Y' TO WS-ABORT-FLAG
DISPLAY 'ABORT: Invalid amount threshold'
END-IF
WHEN 'DATE'
ADD 1 TO WS-ERR-INVALID-DATE
IF WS-ERR-INVALID-DATE > WS-CAT-THRESHOLD
MOVE 'Y' TO WS-ABORT-FLAG
DISPLAY 'ABORT: Invalid date threshold'
END-IF
WHEN 'DUPL'
ADD 1 TO WS-ERR-DUPLICATE
IF WS-ERR-DUPLICATE > WS-CAT-THRESHOLD
MOVE 'Y' TO WS-ABORT-FLAG
DISPLAY 'ABORT: Duplicate threshold'
END-IF
END-EVALUATE.
MOVE WS-ERROR-CATEGORY TO ERR-CATEGORY.
MOVE WS-ERROR-MSG TO ERR-MESSAGE.
MOVE TRANS-RECORD TO ERR-ORIGINAL-REC.
WRITE ERROR-RECORD FROM WS-ERROR-OUTPUT.
* Check percentage threshold
IF WS-RECORDS-READ > 0
COMPUTE WS-ERR-PCT =
(WS-ERR-TOTAL / WS-RECORDS-READ) * 100
IF WS-ERR-PCT > WS-PCT-THRESHOLD
MOVE 'Y' TO WS-ABORT-FLAG
DISPLAY 'ABORT: Error percentage '
WS-ERR-PCT '% exceeds threshold '
WS-PCT-THRESHOLD '%'
END-IF
END-IF.
9500-SET-RETURN-CODE.
EVALUATE TRUE
WHEN WS-ABORT-FLAG = 'Y'
MOVE 12 TO RETURN-CODE
DISPLAY 'JOB ABORTED DUE TO ERRORS'
WHEN WS-ERR-TOTAL > 0
MOVE 4 TO RETURN-CODE
DISPLAY 'COMPLETED WITH WARNINGS'
WHEN OTHER
MOVE 0 TO RETURN-CODE
DISPLAY 'COMPLETED SUCCESSFULLY'
END-EVALUATE.
9600-DISPLAY-STATISTICS.
DISPLAY '=== PROCESSING STATISTICS ==='.
DISPLAY 'Records read: ' WS-RECORDS-READ.
DISPLAY 'Records processed: ' WS-RECORDS-PROC.
DISPLAY 'Records rejected: ' WS-ERR-TOTAL.
DISPLAY ' Invalid account: ' WS-ERR-INVALID-ACCT.
DISPLAY ' Invalid amount: ' WS-ERR-INVALID-AMT.
DISPLAY ' Invalid date: ' WS-ERR-INVALID-DATE.
DISPLAY ' Duplicates: ' WS-ERR-DUPLICATE.
DISPLAY 'Return code: ' RETURN-CODE.
Exercise 14: Batch Job Flow Design
A bank's end-of-day batch cycle consists of the following programs. Draw the dependency graph and identify which programs can run in parallel. Calculate the critical path (minimum elapsed time).
| Program | Duration | Depends On | Description |
|---|---|---|---|
| TXSORT | 20 min | (none) | Sort daily transactions |
| TXPOST | 60 min | TXSORT | Post transactions to accounts |
| INTCALC | 45 min | TXPOST | Calculate daily interest |
| FEECALC | 30 min | TXPOST | Calculate monthly fees |
| STMTGEN | 40 min | INTCALC, FEECALC | Generate statements |
| GLPOST | 25 min | TXPOST | Post to General Ledger |
| REGEXTR | 35 min | TXPOST | Regulatory extract |
| ARCHIVE | 15 min | STMTGEN, GLPOST, REGEXTR | Archive all outputs |
Solution:
Dependency graph:
TXSORT (20)
|
TXPOST (60)
|
+--- INTCALC (45) ---+
| |
+--- FEECALC (30) ---+--- STMTGEN (40) ---+
| |
+--- GLPOST (25) ------------------------+--- ARCHIVE (15)
| |
+--- REGEXTR (35) ------------------------+
Parallel execution groups: - After TXPOST: INTCALC, FEECALC, GLPOST, and REGEXTR can all run in parallel - STMTGEN waits for both INTCALC and FEECALC - ARCHIVE waits for STMTGEN, GLPOST, and REGEXTR
Critical path (longest path through the graph): 1. TXSORT (20) + TXPOST (60) + INTCALC (45) + STMTGEN (40) + ARCHIVE (15) = 180 minutes (3 hours)
Alternative path: TXSORT (20) + TXPOST (60) + FEECALC (30) + STMTGEN (40) + ARCHIVE (15) = 165 minutes (not critical)
With full parallelism, the batch window requirement is 3 hours. Without parallelism (all sequential), it would be 270 minutes (4.5 hours).
Tier 3: Apply (Exercises 15-22)
Exercise 15: Complete Batch Framework Program
Write a complete batch processing program that incorporates all standard batch patterns:
- Parameter file processing (read configuration from a control file)
- Header/trailer validation
- Record-by-record processing with validation
- Error file with descriptive messages
- Checkpoint/restart support
- Record counts, control totals, and hash totals
- Statistics report at end of processing
- Return code management
The program processes a daily wire transfer file for a bank. Input records contain: sender account, receiver account, amount, currency code, and reference number. The program validates each transfer, converts foreign currency amounts to USD, and writes an output file for the settlement system.
Hint: Use the batch framework pattern from section 28.12 of the chapter as a template.
Exercise 16: Multi-File Match and Reconcile
Write a COBOL program that reconciles two sorted files:
File A: Bank's internal transaction log (sorted by transaction reference) File B: External clearing house settlement file (sorted by transaction reference)
The program must produce four outputs: 1. Matched records (reference exists in both files) 2. Unmatched from File A (internal transactions not in clearing house -- potential issues) 3. Unmatched from File B (clearing house transactions not in bank's records -- potential fraud) 4. Amount discrepancies (reference matches but amounts differ)
Include full error handling, record counts for each output, and a summary report.
Exercise 17: Interest Calculation Batch Program
Write a COBOL program that calculates daily interest for a bank's savings accounts. Requirements:
- Read all savings accounts from a sorted sequential file
- Look up the interest rate based on account type and balance tier:
- Standard savings, balance < $10,000: 0.50% annual
- Standard savings, balance $10,000-$49,999: 1.00% annual
- Standard savings, balance >= $50,000: 1.50% annual
- Premium savings, all balances: 2.00% annual
- Calculate daily interest: balance * (annual rate / 365)
- Accumulate the daily interest in an accrual field
- On the posting date (1st of each month), add accrued interest to the balance
- Write an updated account file and an interest posting report
- Include control break totals by account type
Exercise 18: Batch Window Optimization
A batch job currently takes 5 hours. The batch window is only 4 hours. The current job design is:
Step 1: Sort 50 million transactions (90 min)
Step 2: Validate all transactions (60 min)
Step 3: Post valid transactions to accounts (120 min)
Step 4: Generate statements (30 min)
Step 5: Generate reports (30 min)
Step 6: Archive (10 min)
Redesign the job to fit within the 4-hour window. Describe at least four optimization techniques you would apply and estimate the time savings for each. Write the JCL for the optimized job flow.
Exercise 19: Abend Recovery Handler
Write a COBOL subprogram (ABNDHDLR) that serves as a standard abend handler for batch programs. When called (or when an abend occurs), the handler must:
- Capture the abend code (system or user)
- Write an error record to a standard error log file
- Display the failing program name, section, and approximate line number
- Write the current record counts and control totals to the checkpoint file
- Set the return code to 16
- Close all open files
The handler should be reusable across multiple batch programs.
Exercise 20: Report Generation with Page Breaks
Write a complete report generation program that produces a formatted bank account summary report with:
- Report headers on each page (report title, date, page number)
- Column headers (account, name, type, balance, status)
- Detail lines with proper formatting (edited numeric fields, aligned columns)
- Page breaks every 55 lines
- Control break subtotals by account type
- Grand totals on the last page
- Line counting and page numbering
Use ASA carriage control characters for page breaks (RECFM=FBA, LRECL=133).
Exercise 21: Batch Audit Trail
Design and implement a batch audit trail system. Every batch program in the bank must write standardized audit records that include:
- Job name, step name, program name
- Start and end timestamps
- Input file names and record counts
- Output file names and record counts
- Error counts by category
- Control totals (monetary amounts)
- Return code
Write a COBOL copybook for the audit record, a reusable audit writing subprogram, and show how a batch program would call it at initialization and finalization.
Exercise 22: GDG-Based Daily Processing
Write a complete COBOL program and JCL for a daily account update process that uses GDGs for versioning:
- Read the current account master:
PROD.ACCT.MASTER(0) - Read the daily transaction file:
PROD.DAILY.TRANS(0) - Apply transactions and write the new account master:
PROD.ACCT.MASTER(+1) - Archive the processed transactions:
PROD.TRANS.ARCHIVE(+1)
The JCL must handle the GDG references correctly, and the COBOL program must validate that the input files are from the correct processing date.
Tier 4: Analyze (Exercises 23-29)
Exercise 23: End-of-Day Processing System Design
Design a complete end-of-day batch processing system for a mid-size bank with 500,000 customer accounts and 2 million daily transactions. The system must include:
- Transaction capture and validation
- Account posting (debits and credits)
- Interest calculation and accrual
- Fee assessment
- Overdraft detection and notification
- General ledger posting
- Regulatory reporting (CTR, SAR)
- Statement generation
- Archive and purge
For each component, specify: the program name, input/output files, processing logic, dependencies on other components, estimated runtime, and error handling strategy. Draw the complete job dependency diagram and identify the critical path.
Exercise 24: Checkpoint/Restart Design Analysis
A batch program processes 50 million records in 6 hours. Checkpoints are taken every 500,000 records. The program fails after processing 35 million records.
a) How many checkpoints were taken before the failure? b) How many records must be reprocessed after restart? c) What is the estimated restart time (assume linear processing)? d) If the checkpoint overhead is 3 seconds per checkpoint, what is the total checkpoint overhead during a normal run? e) What would happen if checkpoints were taken every 50,000 records instead? Calculate the tradeoff between restart time saved and checkpoint overhead added. f) What is the optimal checkpoint interval? Justify your answer.
Hint: The optimal interval minimizes the sum of expected restart time and checkpoint overhead.
Exercise 25: Batch Performance Analysis
A bank's daily posting job processes 10 million transaction records against a 5 million record account master. Both files are sequential (FB, LRECL=200). The job currently takes 4 hours. Analyze and quantify the impact of:
a) Changing BLKSIZE from 200 (unblocked) to 27800 (139 records per block) b) Increasing BUFNO from 1 to 10 c) Changing WS-COUNTER from PIC 9(8) DISPLAY to PIC 9(8) COMP d) Replacing sequential SEARCH with SEARCH ALL for a 500-entry rate lookup table e) Consolidating two separate passes over the master file into one pass
Estimate the time savings for each optimization.
Exercise 26: Disaster Recovery Batch Design
Design a batch disaster recovery plan for a banking system. The plan must handle:
- Loss of the account master VSAM KSDS
- Loss of one day's transaction file
- Corruption of the general ledger
- Failure of the batch system during end-of-day processing (partial completion)
For each scenario, specify: - How the problem is detected - What backup data is needed for recovery - The step-by-step recovery procedure (including JCL) - How data integrity is verified after recovery - The maximum acceptable recovery time
Exercise 27: Batch Testing Strategy
Design a comprehensive testing strategy for a new sequential master update program. Include:
- Test case categories (at least 10 categories covering normal processing, error conditions, boundary cases, and volume testing)
- For each category, list 3-5 specific test cases with input data and expected output
- The JCL to run the test suite
- A comparison approach to verify outputs
- Performance benchmarking criteria
Focus on the banking domain: account updates, balance calculations, and transaction processing.
Exercise 28: Multi-Step Job Dependency Analysis
A production batch cycle has the following job stream. A runtime error in GLPOST causes the entire cycle to halt. Redesign the job stream to isolate the failure and allow unaffected streams to continue.
Current (sequential) flow:
TXSORT -> TXVALID -> TXPOST -> INTCALC -> FEECALC -> GLPOST -> STMTGEN -> ARCHIVE
Requirements: - STMTGEN depends only on INTCALC and FEECALC, not on GLPOST - ARCHIVE depends on STMTGEN and GLPOST - GLPOST failure should not prevent STMTGEN from running - A notification job must run whenever any job fails
Draw the redesigned dependency graph and write the JCL with IF/THEN/ELSE logic to implement it.
Exercise 29: Batch Capacity Planning
A bank is growing from 1 million to 5 million accounts over the next 3 years. The current batch cycle processes 1 million accounts in 2 hours. Analyze:
a) If processing time scales linearly, what will the batch cycle take with 5 million accounts? b) The current batch window is 4 hours. At what account volume will the batch cycle exceed the window? c) Propose three architectural changes to handle the growth without exceeding the batch window d) For each proposed change, estimate the implementation effort and expected improvement e) Write the JCL for a parallel processing approach that splits accounts across multiple job streams by account number range
Tier 5: Create (Exercises 30-35)
Exercise 30: Complete Banking Batch System
Design and implement a complete end-of-day batch processing system for a small bank. Write the COBOL programs and JCL for:
- TXSORT: Sort daily transactions by account number
- TXPOST: Apply transactions to account master (sequential update with balanced line algorithm)
- INTCALC: Calculate daily interest accrual for all savings accounts
- STMTGEN: Generate monthly statements (control break report)
- EODRECON: End-of-day reconciliation (verify debits = credits)
Include complete error handling, checkpoint/restart, and a master JCL job that orchestrates the entire cycle with proper dependencies and conditional execution.
Exercise 31: Regulatory Reporting Extract
Design and implement a batch system that produces a Currency Transaction Report (CTR) extract for regulatory compliance. The system must:
- Scan all daily transactions for cash transactions exceeding $10,000
- Aggregate multiple transactions from the same customer on the same day
- If the aggregate exceeds $10,000, include the customer in the report
- Format the output according to the regulatory specification (specific field positions, codes, and formats)
- Produce an audit trail of all included and excluded transactions
- Generate control totals for submission verification
Write the complete COBOL program and JCL, including the regulatory output format and the audit trail.
Exercise 32: Parallel Processing Framework
Design and implement a framework for running the same COBOL program against multiple partitions of data simultaneously. The framework must:
- Split an input file into N partitions based on a key range (e.g., accounts 0000000001-2000000000, 2000000001-4000000000, etc.)
- Submit N parallel instances of the processing program
- Merge the N output files into a single output
- Reconcile record counts (sum of partitions must equal total)
- Handle the failure of any single partition without affecting others
Write the file splitting program, the JCL for parallel execution, and the merge/reconciliation program.
Exercise 33: ETL Data Quality Framework
Design a reusable data quality framework for batch ETL programs. The framework must provide:
- A copybook defining a standard validation result structure
- A validation subprogram that checks: - Numeric field validity - Date field validity - Required field presence - Code field values against reference tables - Cross-field business rules
- A scoring mechanism that assigns a quality score to each record
- Configurable thresholds for accept/reject/review
- A standard error reporting format
Write the copybook, the validation subprogram, and a sample ETL program that uses the framework.
Exercise 34: Batch Monitoring Dashboard
Design a batch monitoring system that tracks the health of a bank's nightly batch cycle. The system must:
- Record the start time, end time, record counts, and return code of every job step
- Compare actual durations to historical baselines
- Generate alerts when: - A job runs more than 20% longer than its baseline - A job's error rate exceeds its historical average by 2x - The overall batch cycle is projected to exceed the batch window
- Produce a summary report showing the status of the entire batch cycle
Write the COBOL monitoring data collection program, the analysis program, and the JCL that integrates monitoring into the batch cycle.
Exercise 35: Migration from Sequential to VSAM
A legacy banking application uses sequential master files updated nightly through the balanced line algorithm. The bank wants to migrate to VSAM KSDS to enable online random access during the day while maintaining the nightly batch update.
Design and implement the migration: 1. A COBOL program to convert the sequential master to a VSAM KSDS 2. A modified batch update program that reads the sorted transactions and applies them to the VSAM KSDS using random access (READ/REWRITE/WRITE/DELETE) instead of the balanced line algorithm 3. JCL for the VSAM definition, initial load, and nightly batch update 4. A comparison of performance characteristics between the old sequential approach and the new VSAM approach 5. A rollback plan if the VSAM approach encounters issues
Address the challenges of converting from a two-file-in, one-file-out pattern to an in-place update pattern, including backup strategy and recovery.