MODULE 9 · INDEXED FILES AND SORT · 8/8

Challenge: overnight customer maintenance

40 min60 XPExercise

This is the job this whole module has been building towards, and a close cousin of programs running in every bank and card issuer tonight.

During the day, branch staff key changes to credit-card accounts: new customers, limit changes, charges, payments, closures. Those changes are not applied to the master immediately. They pile up in a sequential file, in the order they were keyed, which is to say no useful order at all. Overnight, a batch job:

Sorts the transactions by customer and by the sequence number each one was given, so that a customer's changes are applied in the order they were made (a new account must exist before it can be charged).
Applies each transaction to the indexed master: WRITE for new customers, READ + REWRITE for changes, DELETE for closures.
Validates business rules before touching the master: no charge that breaks the credit limit, no closing an account that still owes money.
Audits: every transaction gets a line saying what happened, and the run ends with control totals so operations can reconcile the counts against what the branches sent.

Design notes

The SORT's USING clause reads the raw transactions; an output procedure receives them in order and applies each one. There is no need for an intermediate sorted file.
The SD record is the transaction layout, so after RETURN SORT-WORK every field is ready to use.
Keep one result field per transaction. Start it as ACCEPTED, overwrite it when a rule fails, and drive the counts and the audit line from it. One place to decide, one place to report.
A charge can push the balance past 9(5)V99. Add into a wider work field and compare that with the limit, or the size error goes unnoticed.
DELETE then N for the same customer in one run is legal: the key is free again once the record is deleted.

Read the task carefully: the audit format is fixed because a downstream job (and the grader) parses it.

On the job

Control totals ("records read, accepted, rejected") at the end of a batch step are not decoration. Operations and auditors compare them across steps. If the sort says 15 records in and the update says 14 processed, someone gets paged.

Your task

Overnight customer maintenance. Branches key account changes all day; tonight's job applies them to the credit-account master and prints an audit trail for the operations team.

DD CUSTMAST — indexed (KSDS), record key CUST-ID, 40 bytes: CUST-ID X(6), CUST-NAME X(20), CUST-LIMIT 9(5)V99, CUST-BAL 9(5)V99.

DD MAINTIN — line sequential, 37 bytes, not sorted: TR-ID X(6), TR-SEQ 9(3), TR-CODE X, TR-NAME X(20), TR-AMOUNT 9(5)V99.

DD AUDITOUT — line sequential audit report.

Sort the transactions by TR-ID, then TR-SEQ (both ascending) and apply them in that order:

Code	Action	Rejected when
`N`	New customer: name, limit = `TR-AMOUNT`, balance 0	`ALREADY ON FILE`
`L`	Set limit to `TR-AMOUNT`	`LIMIT BELOW BALANCE` (new limit < balance)
`C`	Charge: add `TR-AMOUNT` to balance	`OVER LIMIT` (new balance > limit)
`P`	Payment: subtract `TR-AMOUNT`	`OVERPAYMENT` (amount > balance)
`X`	Close: delete the customer	`BALANCE NOT ZERO`

Any other code is rejected as INVALID CODE (check this first, before touching the master). L/C/P/X for a missing customer are rejected as NOT ON FILE.

Write to the audit file, one line per transaction in sorted order:

C00100 001 C ACCEPTED
C00100 002 L REJECTED - LIMIT BELOW BALANCE

then ACCEPTED: nnn REJECTED: nnn, then MASTER AFTER MAINTENANCE, then every customer in key order: ID, space, name, space, limit, space, balance, both amounts edited ZZ,ZZ9.99:

C00100 ALICE MORGAN          5,000.00  5,000.00

The starter has all the files, layouts and print lines.

← SORT with input and output procedures Anatomy of a batch report →

Run your program to see its output here. The first visible test's input and datasets are used.

Submit to grade your program against every test.