Batch vs Online Processing

Merge a sorted old master with sorted transactions to create a new master (the "balance line" algorithm):

Online (CICS / IMS TM) Scheduler, time, or file arrival User, API call, message Volume per run Millions of records One request, a few records

Minutes to hours (must fit the batch window) Sequential files, sort, bulk SQL Random reads by key

Long-running, STOP RUN/GOBACK, DISPLAY to SYSOUT Short tasks, pseudo-conversational, CICS commands only

Checkpoint/restart, rerun from a GDG generation, commit every n records

Automatic backout of the unit of work (SYNCPOINT) Exclusive access to files is common

Thousands of concurrent tasks; record locking Master-file update, interest calculation, statements, extracts, reports Inquiries, updates, payments, APIs

39.1 The classic sequential master-file update

Merge a sorted old master with sorted transactions to create a new master (the "balance line" algorithm):

Writing a new generation (GDG +1) instead of updating in place makes reruns trivial — the old master is untouched.

read first old-master record and first transaction
loop until both are at HIGH-VALUES:
    if  master key < transaction key  → write master unchanged to new master; read master
    if  master key = transaction key  → apply change/delete; read transaction
                                         (multiple transactions per master allowed)
    if  master key > transaction key  → transaction is an ADD (or an error); read transaction
at end of each file, move HIGH-VALUES to its key so the other file drains

39.2 Modern trends

Shrinking batch windows (24×7 online) push work to continuous processing — CICS asynchronous APIs, MQ-triggered programs, batch running concurrently with online through Db2 or VSAM RLS — and Java and COBOL batch steps increasingly coexist in the same job (JZOS, JSR 352 Java batch).