Skip to content

COBTUPDT

Source: app-transaction-type-db2/cbl/COBTUPDT.cbl

Type: Batch program (DB2)

Purpose

COBTUPDT is a batch maintenance program that applies a set of add, update, and delete instructions to the CARDDEMO.TRANSACTION_TYPE reference table (transaction type codes and their descriptions). It reads a sequential control file where each record specifies an action code and the transaction type data, then makes the corresponding change directly against the DB2 table. This is essentially a bulk-load/maintenance utility for keeping the transaction type lookup table in sync, likely run outside of the online CICS system (no CICS commands are present).

How it works

  • 0001-OPEN-FILES opens the input file TR-RECORD (DD INPFILE) and displays whether the open succeeded, based on the file status code — but does not stop processing if the open fails.

  • 1001-READ-NEXT-RECORDS is the main driver: it performs an initial read (1002-READ-RECORDS), then loops PERFORM UNTIL LASTREC = 'Y', alternating between processing the current record (1003-TREAT-RECORD) and reading the next one, until end-of-file is reached. It then performs 2001-CLOSE-STOP to close the file, exits the paragraph, and falls through to STOP RUN.

  • 1002-READ-RECORDS reads the next record from the input file into WS-INPUT-REC. On end-of-file it sets LASTREC to 'Y'; otherwise it displays the record being processed.

  • 1003-TREAT-RECORD examines INPUT-REC-TYPE (first character of the record) and branches:

  • 'A' → 10031-INSERT-DB (insert a new transaction type row)

  • 'U' → 10032-UPDATE-DB (update the description for an existing type)

  • 'D' → 10033-DELETE-DB (delete a transaction type row)

  • '*' → treated as a comment line and ignored

  • any other value → builds an error message and calls 9999-ABEND

  • Each of the three DB paragraphs issues its SQL statement, captures SQLCODE, and evaluates the result:

  • SQLCODE = 0 → success message displayed

  • SQLCODE = +100 (update/delete only) → "No records found" message, then 9999-ABEND

  • SQLCODE < 0 → builds an "Error accessing... SQLCODE:" message, then 9999-ABEND

  • 9999-ABEND displays the accumulated error message and sets RETURN-CODE to 4 — but does not stop the program or the read loop (see Things to know).

  • 2001-CLOSE-STOP closes the input file at end-of-job.

Inputs & outputs

Things to know

  • 9999-ABEND does not actually abend or stop the run. It only displays the message and sets RETURN-CODE to 4 — the main read/process loop (1001-READ-NEXT-RECORDS) continues to the next record regardless of a prior error. Anyone relying on this program to halt on bad data will be surprised: it keeps going and simply leaves a non-zero return code at the end.

  • File-open failure is not fatal either. 0001-OPEN-FILES only displays 'OPEN FILE NOT OK' if the status isn't '00'; there's no branch to stop processing, so a failed open would likely lead to read errors or an empty/garbage loop rather than a clean abort.

  • INPUT-REC-TYPE validation is minimal. Any character other than A, U, D, or * triggers the generic "TYPE NOT VALID" error path (via 9999-ABEND), but again does not stop the batch — it just logs and moves on.

  • Hard-coded return code of 4 is used for all error conditions (bad type, SQL negative code, "no records found" on update/delete) — the return code doesn't distinguish between these different failure types.

  • Comment/skip convention: a record type of '*' is treated as a commented-out/ignored line, a convention embedded only in this program's logic — worth documenting for anyone preparing input files.

  • No rollback/commit logic is visible in this excerpt — there's no explicit COMMIT or ROLLBACK shown, so transaction boundary behavior (autocommit vs. explicit) depends on the DB2 subsystem/job setup, not shown in this program.

  • Table name discrepancy: the parser's extracted sql_tables list shows CARDDEMO.TRANSACTION three times, but the actual SQL statements in source reference CARDDEMO.TRANSACTION_TYPE. Documentation/tooling consumers should be aware the extracted table name may be truncated/inaccurate.

  • Duplicate copies of the field name — the FD defines WS-INPUT-VARS (with INPUT-TYPE, INPUT-TR-NUMBER, INPUT-TR-DESC) but the actual read target and SQL host variables use a separately-declared WS-INPUT-REC (INPUT-REC-TYPE, INPUT-REC-NUMBER, INPUT-REC-DESC) in Working-Storage. The FD-level WS-INPUT-VARS fields appear unused; this duplication could be confusing during maintenance.

Files

Logical file DD name
TR-RECORD INPFILE

DB2 tables

CARDDEMO.TRANSACTION, CARDDEMO.TRANSACTION, CARDDEMO.TRANSACTION

Paragraph flow

flowchart TD
    0001_OPEN_FILES["0001-OPEN-FILES"]
    1001_READ_NEXT_RECORDS["1001-READ-NEXT-RECORDS"]
    1002_READ_RECORDS["1002-READ-RECORDS"]
    1003_TREAT_RECORD["1003-TREAT-RECORD"]
    10031_INSERT_DB["10031-INSERT-DB"]
    10032_UPDATE_DB["10032-UPDATE-DB"]
    10033_DELETE_DB["10033-DELETE-DB"]
    9999_ABEND["9999-ABEND"]
    2001_CLOSE_STOP["2001-CLOSE-STOP"]
    1001_READ_NEXT_RECORDS --> 1002_READ_RECORDS
    1001_READ_NEXT_RECORDS --> 1003_TREAT_RECORD
    1001_READ_NEXT_RECORDS --> 2001_CLOSE_STOP
    1003_TREAT_RECORD --> 10031_INSERT_DB
    1003_TREAT_RECORD --> 10032_UPDATE_DB
    1003_TREAT_RECORD --> 10033_DELETE_DB
    1003_TREAT_RECORD --> 9999_ABEND
    10031_INSERT_DB --> 9999_ABEND
    10032_UPDATE_DB --> 9999_ABEND
    10033_DELETE_DB --> 9999_ABEND

Paragraphs

Paragraph Line Performs
0001-OPEN-FILES 82
1001-READ-NEXT-RECORDS 91 1002-READ-RECORDS, 1003-TREAT-RECORD, 1002-READ-RECORDS, 2001-CLOSE-STOP
1002-READ-RECORDS 100
1003-TREAT-RECORD 109 10031-INSERT-DB, 10032-UPDATE-DB, 10033-DELETE-DB, 9999-ABEND
10031-INSERT-DB 132 9999-ABEND
10032-UPDATE-DB 166 9999-ABEND, 9999-ABEND
10033-DELETE-DB 196 9999-ABEND, 9999-ABEND
9999-ABEND 230
2001-CLOSE-STOP 234