Skip to content

COPAUS2C

Source: app-authorization-ims-db2-mq/cbl/COPAUS2C.cbl

Type: CICS transaction program (DB2)

COPAUS2C — Mark Authorization Message Fraud

Purpose

This CICS program records or updates fraud markings on card authorization messages. It is called (via CICS COMMAREA, not shown as a standalone transaction entry point in these facts) to persist a fraud-related record into the CARDDEMO.AUTHFRDS DB2 table — either inserting a new row for an authorization message, or, if that row already exists, updating its fraud flag and report date. This supports the CardDemo authorization module's fraud-tracking/reporting capability.

How it works

Processing is driven entirely from MAIN-PARA (the only paragraph CICS transfers control to; it in turn performs FRAUD-UPDATE under one condition):

  1. Timestamp setup — MAIN-PARA issues EXEC CICS ASKTIME and EXEC CICS FORMATTIME to get the current date (WS-CUR-DATE), which is moved into PA-FRAUD-RPT-DATE.
  2. Derive authorization timestamp — The program reconstructs a human-readable timestamp (WS-AUTH-TS) from the incoming PA-AUTH-ORIG-DATE (year/month/day) and PA-AUTH-TIME-9C (computed as 999999999 - PA-AUTH-TIME-9C, then split into HH/MI/SS/SSS). This suggests the incoming time field is stored in an inverted/complemented numeric form.
  3. Field mapping — A long sequence of MOVE statements copies commarea fields (card number, auth type, expiry date, message type/source, response codes, transaction amount, merchant details, transaction ID, match status, fraud action flag, account/customer IDs) into DB2 host variables matching the AUTHFRDS table columns.
  4. Insert attempt — An EXEC SQL INSERT INTO CARDDEMO.AUTHFRDS is executed, converting the auth timestamp with TIMESTAMP_FORMAT and setting FRAUD_RPT_DATE to CURRENT DATE.
  5. If SQLCODE = 0: success — status set to success (WS-FRD-UPDT-SUCCESS), message 'ADD SUCCESS'.
  6. If SQLCODE = -803 (duplicate key): the program falls back to FRAUD-UPDATE to update the existing row instead.
  7. Any other non-zero SQLCODE: status set to failed, and a formatted error message with SQLCODE/SQLSTATE is built into WS-FRD-ACT-MSG.
  8. FRAUD-UPDATE paragraph — Executes an EXEC SQL UPDATE against CARDDEMO.AUTHFRDS, setting AUTH_FRAUD and FRAUD_RPT_DATE for the row matching CARD_NUM and AUTH_TS. Success or failure is again reflected in WS-FRD-UPDT-STATUS and WS-FRD-ACT-MSG.
  9. Control returns to CICS via EXEC CICS RETURN (no transaction ID passed, so no explicit continuation is specified in this program).

Inputs & outputs

  • DFHCOMMAREA (Linkage Section input/output) — sole interface into the program:
  • WS-ACCT-ID, WS-CUST-ID — account/customer identifiers.
  • WS-FRAUD-AUTH-RECORD (via copybook CIPAUDTY) — the full authorization message data (card number, auth type/time/date, response codes, transaction/merchant details, match status) that gets persisted.
  • WS-FRAUD-STATUS-RECORD — output area: WS-FRD-ACTION (input flag indicating report ('F') or remove ('R') fraud — used to set AUTH_FRAUD), WS-FRD-UPDATE-STATUS (output: success/failed), WS-FRD-ACT-MSG (output: human-readable result/error message).
  • Copybook CIPAUDTY — defines the layout of the incoming authorization record fields (PA-* fields referenced throughout MAIN-PARA).
  • DB2 table CARDDEMO.AUTHFRDS — read/write target:
  • INSERT in MAIN-PARA to create a new fraud record.
  • UPDATE in FRAUD-UPDATE to modify an existing record's AUTH_FRAUD and FRAUD_RPT_DATE when a duplicate key is detected.
  • No physical files (VSAM/QSAM) are used — this is a pure CICS/DB2 program with no files listed by the parser.
  • CICS services used: ASKTIME, FORMATTIME (both NOHANDLE, meaning CICS exceptions are suppressed rather than trapped explicitly), and RETURN.

Things to know

  • No file I/O — all data enters/exits via the COMMAREA; there is no direct terminal (BMS map) interaction in this program despite it being a CICS transaction.
  • NOHANDLE on ASKTIME/FORMATTIME — any failure in these CICS calls is silently ignored (no explicit error branch), so a bad date/time conversion would not be flagged to the caller.
  • Time field inversion logic is non-obvious: WS-AUTH-TIME = 999999999 - PA-AUTH-TIME-9C is a hard-coded "complement" calculation to decode the original time; the reason for this encoding is not documented in the source and should be verified with the producer of PA-AUTH-TIME-9C.
  • Error handling relies on SQLCODE branching:
  • SQLCODE = 0 → success.
  • SQLCODE = -803 (duplicate key violation) → triggers fallback to FRAUD-UPDATE, meaning insert-then-update is the intended pattern for idempotent fraud marking. This is a specific hard-coded DB2 return code dependency.
  • Any other non-zero code → treated as a generic "SYSTEM ERROR DB2" and surfaced in WS-FRD-ACT-MSG, but the program does not roll back or take any DB2-specific corrective action — it simply reports failure back to the caller via the commarea.
  • No explicit COMMIT/ROLLBACK appears in this program; transaction boundary/commit control is presumably managed by the CICS/DB2 sync point mechanism outside this code, which should be confirmed.
  • Hard-coded values: literal date/time format mask 'YY-MM-DD HH24.MI.SSNNNNNN' used in TIMESTAMP_FORMAT (both insert and update), and the constant 999999999 used in time decoding — both are magic values with no in-code explanation.
  • Two SQL statements only (INSERT and UPDATE) against the same table; parser correctly lists CARDDEMO.AUTHFRDS twice, once per statement.
  • WS-FRD-ACTION ('F'=report fraud, 'R'=remove fraud) is simply written to AUTH_FRAUD without validation in this program — any other value passed by the caller would be stored as-is, since no range/value check is shown here.

DB2 tables

CARDDEMO.AUTHFRDS, CARDDEMO.AUTHFRDS

CICS commands

ASKTIME NOHANDLE, FORMATTIME, RETURN

Copybooks

CIPAUDTY

Paragraph flow

flowchart TD
    MAIN_PARA["MAIN-PARA"]
    FRAUD_UPDATE["FRAUD-UPDATE"]
    MAIN_PARA --> FRAUD_UPDATE

Paragraphs

Paragraph Line Performs
MAIN-PARA 89 FRAUD-UPDATE
FRAUD-UPDATE 221