CARDCOR/i — Credit Card Core

CARDCOR/i is a bank card-issuing back office: cardholder and account masters, card issuance, real-time authorization against open-to-buy, settlement of authorized purchases into a posted ledger, average-daily-balance finance charges, delinquency and credit-limit management, a statement/minimum-payment cycle with a printed spool, payments, a balanced general-ledger feed, and a full dispute/chargeback lifecycle. It is a mixed-language IBM i application — fixed- and free-form RPG, ILE COBOL, CL, DDS (PF/LF, display, printer) and embedded/DDL SQL — running in library CARDCOR. This manual is the reference for the operator who runs the online screens and the night-batch chain, and for the developer maintaining it. It is grounded entirely in the committed source (creditcard-app/src/sources.mjs, src/seed.mjs, the test/cc_*.mjs drivers and PLAN.md), and it is honest where the application deliberately simplifies or where a documented gap exists.

A. Overview & Architecture ↑ top

A.1 What it does

CARDCOR/i services the life of a revolving credit-card account:

• Account & card setup — maintain the account master (add / change / inquire / close via CCACCMNT) and issue plastics onto an open account (CCISSUE).
• Authorization — approve or decline a purchase against open-to-buy = CRLIMIT − ACCBAL − HELDAUTH, placing a hold on approval, and log every request to AUTHTRN (CCAUTH).
• Posting / settlement — settle each approved-but-unsettled authorization into the posted ledger, raise the balance and release the hold (CCPOST).
• Finance charge — assess an average-daily-balance finance charge on every open, non-zero account (CCFIN).
• Delinquency & credit-limit management — over-limit and late-fee assessment, with an account-freeze path (CCDELQ).
• Statement / minimum payment — cut a cycle, compute the minimum payment, write the statement header and print a real spooled statement (CCSTMT).
• Payments — apply a borrower payment, reducing the balance (CCPAY).
• General-ledger feed — consolidate posted activity into balanced DR/CR pairs under commitment control (CCGL), cross-checked by a COBOL portfolio report (CCACCRPT).
• Dispute & chargeback — open a dispute against a posted purchase with a provisional credit (CCDISP) and resolve it won or lost (CCCHGBK).

A.2 Native-record + SQL architecture

Unlike the SQL-PL-centred sibling apps, CARDCOR/i keeps its business logic in the RPG/COBOL programs and uses DB2 for i primarily as a keyed record store, reached through native record I/O (CHAIN / READ / WRITE / UPDATE / SETLL over DDS PFs and LFs). SQL appears in two deliberate places:

• Embedded SQL for arrival-sequence ids. Every posting/auth/dispute program derives its next unique id with exec sql select coalesce(max(id),0) into :w from cardcor.<file> and bumps a local counter. This is a documented design-around for a platform quirk (a SETGT *HIVAL / READP reposition over an output-opened file does not see rows written earlier in the same job); embedded-SQL MAX always sees committed rows. See F.2.
• Embedded SQL + a DDL table for the GL. CCGL writes balanced DR/CR pairs into the SQL table GLENTRY and finalises the batch with a real EXEC SQL COMMIT under the job's commitment definition; the COBOL CCACCRPT cross-checks with an EXEC SQL SUM over GLENTRY.

The application follows the proven POLARIS/i house style (the column-exact RPG C()/D() helpers in sources.mjs) and is coded around several documented emulator quirks — nested if/else only (free-form elseif mis-scopes its END-IF), packed id parameters to match packed callers, UF A opens where a program both CHAINs and WRITEs the same file, and PRTF field columns whose position digits end at DDS column 44. Everything runs in library CARDCOR.

A.3 Component & flow

  ONLINE (5250)          FRONT-OFFICE            NIGHT BATCH (CCNIGHT -> CCNITEQ *JOBQ)
  -------------          ------------            -------------------------------------
  CCMENUP  --CALL-->     CCISSUE  (issue card)   CCPOST  --settle AUTHTRN 'A' -> POSTTRN 'P'
    opt 1 -> CCACCINQ    CCAUTH   (authorize)             (+ACCBAL, release HELDAUTH, A->S)
    opt 2 -> CCTRNINQ      OTB check -> AUTHTRN   CCFIN   --ADB finance charge -> POSTTRN 'I'
             (SFL over      'A'/'D'               CCDELQ  --late/over-limit fee -> POSTTRN 'F'
              POSTLF)     CCPAY    (payment)      CCGL    --POSTTRN -> balanced GLENTRY DR/CR
                            -> POSTTRN 'Y'                 (EXEC SQL, COMMIT)
                          CCDISP   (open disp.)   CCSTMT  --cut cycle -> STMTHDR + PRTF spool
                            -> DISPTRN 'O'
                            + POSTTRN 'C'          CCACCRPT (COBOL) -- portfolio report,
                          CCCHGBK  (resolve)                GLENTRY cross-check "IN BALANCE"
                            'W' stand / 'L' rebill
                            -> POSTTRN 'B'
              \                                   /
               \                                 /
                v                               v
     ACCTMST (account master: ACCBAL, HELDAUTH, DELQBKT, ASTAT, MINPAY, LASTBAL)
        |   \        \                    journaled ledgers: AUTHTRN, POSTTRN, DISPTRN
        |    +--> AUTHTRN (auth log)              (CCJRN, IMAGES(*BOTH))
        |    +--> POSTTRN (posted ledger) --POSTLF--> CCTRNINQ subfile
        |    +--> DISPTRN (dispute ledger) --DISPLF--> per-account dispute history
        +------> STMTHDR (statement header)  +  STMTP spool  +  GLENTRY (GL feed)

A single event — say a purchase — flows: CCAUTH approves it and writes an AUTHTRN 'A' row plus a HELDAUTH hold → the night CCPOST settles it into a POSTTRN 'P' row, adds the amount to ACCBAL, releases the hold and flips the auth marker 'A'→'S' so a re-run skips it → CCGL later mirrors that posted row into a balanced GLENTRY DR/CR pair.

A.4 Object inventory

The full catalogue is 8 PFs + 3 LFs + 1 SQL table, 3 DSPF + 1 PRTF, 15 RPG programs, 1 COBOL program and 2 CL programs, with three ledger tables journaled to CCJRN. Sections D and F expand each.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

CARDCOR/i has no CICS transaction identifiers and no transid switch. On IBM i, each program is reached by name from a 5250 command-entry line (or through the operator menu, or a JOBQ/scheduler for the batch chain). The operator equivalent of “type a transid and Enter” is “type a CALL command and Enter”. Before invoking anything, the job's library list must include CARDCOR — the tested jobs run with LIBL = QSYS QGPL CARDCOR QTEMP and CURLIB = CARDCOR.

The front-office programs (CCISSUE, CCAUTH, CCPAY, CCACCMNT, CCDISP, CCCHGBK) are callable with an *ENTRY PLIST — they take parameters and return a response code, so in practice they are invoked program-to-program (an acquiring feed, a teller front-end, or a test driver) rather than typed by hand. The three interactive programs (CCMENUP, CCACCINQ, CCTRNINQ) are 5250 screens. The batch programs are described in section C.

B.2 The menu & inquiry screens

CARDCOR/i has three real 5250 programs. CCMENUP (over DDS CCMENUD) is the operator menu; it routes option 1 to CCACCINQ and option 2 to CCTRNINQ with a classic indicator-conditioned dynamic CALL, rejects any other option with “Invalid option”, and exits on F3.

Account inquiry — CCACCINQ / ACCTDSPF

A plain (non-subfile) EXFMT loop over record format ACCINQF. The operator keys an account number into IACCTNO and presses Enter; the program CHAINs ACCTMST, then CHAINs CARDHLDR for the holder name, and renders status, credit limit, balance, open-to-buy (CRLIMIT − ACCBAL − HELDAUTH), APR, minimum payment and delinquency bucket. A not-found account clears the output fields and shows “Account not found: <acct>”. F3 exits.

Transaction inquiry — CCTRNINQ / TRNDSPF (subfile)

A header record plus a real SFL/SFLCTL subfile (TRNSFL under TRNCTL, SFLPAG(0010) per page, SFLSIZ(0020)). The operator keys an account number; the program clears the subfile (SFLCLR), then loads it from POSTLF (the posted-ledger logical keyed by account) with SETLL/READ, writing one TRNSFL row per posted transaction until the account changes, and displays it. The SFL indicators mirror the DDS numbering: 31=SFLDSP, 32=SFLDSPCTL, 33=SFLCLR, 34=SFLEND(*MORE); SFLDSPCTL must be on before the first EXFMT or nothing renders.

B.3 Controls & audit workflow (no four-eyes maker–checker)

Honest statement: CARDCOR/i does not model a four-eyes maker–checker / separate-authorization workflow. There is no “one user requests, a second user approves” step: a CCAUTH approves-or-declines in one call, CCPAY and CCDISP act immediately, and account maintenance through CCACCMNT applies at once. The manual documents the control model the application does have:

• Immutable, journaled ledgers. Every authorization (AUTHTRN), every posted money movement (POSTTRN) and every dispute (DISPTRN) is written as an arrival-sequence row and journaled to CCJRN with IMAGES(*BOTH). This is the after-the-fact reconstructable trail — the account balance can always be re-derived from the posted ledger.
• Status / state gating. Business rules gate what can happen by account and record state: CCISSUE rejects a card onto a non-open account (ASTAT≠'O'); CCAUTH declines any account not open; CCPOST settles only auths still marked 'A' (approved-unsettled) and flips them to 'S' so a re-run is a no-op; CCDISP rejects a dispute unless the posted txn exists and is a purchase ('P'); CCCHGBK rejects a dispute that is not still 'O' (open).
• Duplicate-add guarding. CCACCMNT add ('A') does a guarding CHAIN(E) first and rejects if the account already exists — it never relies on the WRITE itself to reject a duplicate (a design-around for the documented PG-049 unmonitored-dup-WRITE-absorption behaviour). Every maintenance UPDATE re-CHAINs the record immediately before it (never a double-UPDATE of one read record).
• Held-authorization discipline. An approved auth places a HELDAUTH hold that reduces open-to-buy until settlement releases it (floored at 0), so a card cannot be over-authorized between auth and posting.

In sum, the control posture is immutable journaled ledgers + status/state gating + duplicate-add guarding, enforced in the application programs, rather than a segregation-of-duties approval workflow.

C. Batch Jobs & the Periodic Cycle ↑ top

CARDCOR/i's servicing runs as a night-batch chain packaged by the CL program CCNIGHT, which creates the CCNITEQ job queue and submits each step as its own SBMJOB in sequence: CCPOST → CCFIN → CCDELQ → CCGL → CCSTMT. Each step is a separate job on purpose — a documented platform quirk means rows written to an output-opened file may not be visible to a program CALLed inline in the same job until the writer closes, so the steps are not chained as one CL calling all five inline. (The test harness drives the individual steps directly where it must assert between them; CCNIGHT is the packaged operator entry point that proves the chain exists as one command.)

-- run the whole night chain (creates CCNITEQ, submits the five steps)
CALL PGM(CARDCOR/CCNIGHT)

-- or submit an individual step
SBMJOB CMD(CALL PGM(CARDCOR/CCPOST)) JOB(CCPOSTJ) JOBQ(CARDCOR/CCNITEQ)
SBMJOB CMD(CALL PGM(CARDCOR/CCSTMT) PARM('001')) JOB(CCSTMTJ) JOBQ(CARDCOR/CCNITEQ)

Most batch programs take no CALL parameters and read the whole account or ledger file forward; only CCSTMT takes a parameter (the 3-digit cycle number). None of these programs reads a control-date row — the posting date on the ledger rows they write is a fixed literal (20260201) in the current source (see F.5), so the “processing date” is compiled-in rather than operator-supplied.

C.1 Full batch program set

Front-office CCISSUE, CCAUTH, CCPAY, CCACCMNT, CCDISP and CCCHGBK are on-demand callables, not part of the night chain; they are driven as transactions arrive.

C.2 Auth / posting / statement / finance detail

Authorization — CCAUTH (front-office)

Computes open-to-buy = CRLIMIT − ACCBAL − HELDAUTH with packed-decimal math. A blocked/non-open account (ASTAT≠'O') is declined. Otherwise if AUTHAMT ≤ OTB the auth is approved ('A'): HELDAUTH rises by the amount (the hold) and an AUTHTRN 'A' row is written; else declined ('D'), no hold, but an AUTHTRN 'D' row is still logged. The response code is returned in the last PARM.

Seeded example (from cc_daycycle):
  AC00000001 bal 200.00, limit 5000.00, held 0  -> OTB 4800.00
  CCAUTH 300.00 -> A  (300 <= 4800)      HELDAUTH now 300.00
  AC00000002 bal 4800.00, limit 5000.00          -> OTB 200.00
  CCAUTH 200.00 -> A  (fits exactly)
  CCAUTH 500.00 -> D  (OTB now 0, declined)

Posting / settlement — CCPOST

One forward pass over AUTHTRN in arrival sequence. For each auth still marked 'A' (approved-unsettled) it writes a POSTTRN 'P' (PURCHASE SETTLEMENT) row, adds AUTHAMT to ACCTMST.ACCBAL, releases the hold (HELDAUTH −= AUTHAMT, floored at 0), and flips the auth marker 'A'→'S' in place so a re-run is idempotent (already-settled 'S'/declined 'D' auths are skipped). It seeds the next POSTID once from COALESCE(MAX(POSTID),0) via embedded SQL, then bumps a local counter per WRITE.

Expected DSPLY:
  CCPOST SETTLED=2 SKIP=1   2 approved auths settled, 1 declined skipped

Finance charge — CCFIN

Forward pass over ACCTMST. For every account with ASTAT='O' and ACCBAL > 0: ADB = (LASTBAL + ACCBAL) / 2 (a two-point average-daily-balance proxy — a real system tracks per-day balances; documented in PLAN.md), monthly periodic rate = APR / 1200 (APR is an annual percent, so /100 for a fraction and /12 for the month), finance charge = %DECH(ADB × rate). A positive charge is written as a POSTTRN 'I' (FINANCE CHARGE) row and added to ACCBAL; zero-balance accounts are skipped.

Worked example (SIM-2026-M3, AC1 at month-accumulated 730.00):
  ADB 730.00 x (18.00/1200) = 730.00 x 0.015 = 10.95   -> POSTTRN 'I' 10.95

Delinquency / credit-limit — CCDELQ

Forward pass over DELQLF (keyed DELQBKT then ACCTNO, so it reads worst-first within a bucket). Per account: if ACCBAL > CRLIMIT it assesses an over-limit fee (FEESCHED 'OVL', default 35.00); else if DELQBKT ≥ 1 (past due) it assesses a late fee (FEESCHED 'LTE', default 29.00). Either fee is written as a POSTTRN 'F' (DELINQUENCY FEE) row and added to ACCBAL; if DELQBKT ≥ 3 the account is frozen (ASTAT→'F').

Statement / minimum payment — CCSTMT

Given a cycle number, a forward pass over ACCTMST cuts a statement for every open, non-zero account: NEWBAL = ACCBAL; minimum payment = the greater of a floor (FEESCHED 'MIN' FEEAMT, default 25.00) or a percentage of the balance (FEESCHED 'MIN' FEEFCTR, default 0.020 = 2%), never more than the whole balance. It writes a STMTHDR row (keyed SACCTNO+CYCLENO), records MINPAY on the account, snapshots LASTBAL = NEWBAL (setting up the next cycle's ADB start point), and prints a real STMTP statement line to the spool.

Example (cc_daycycle, AC2 at 5125.00): 2% x 5125.00 = 102.50 > 25.00 floor
  MINPAY = 102.50    STMTHDR written    LASTBAL <- 5125.00
  CCSTMT CUT=n CYCLE=001

General-ledger feed — CCGL

One pass over POSTTRN in arrival sequence, mapping each posted row to a balanced DR/CR pair (chart-of-accounts-lite, documented, not a real GL): P DR 1400-RECV / CR 2200-STLMT; Y DR 1000-CASH / CR 1400-RECV; F DR 1400-RECV / CR 4200-FEEIN; I DR 1400-RECV / CR 4100-FININ. TRNAMT is signed; each posting uses %ABS so DR and CR magnitudes match, keeping SUM(DR) = SUM(CR) by construction. Both inserts run as embedded EXEC SQL under the job's commitment definition, finalised with a real EXEC SQL COMMIT.

C.3 Ordering & dependencies

• CCPOST first. Settlement must run before the finance charge and the statement so the balance reflects the cycle's purchases before it is charged and billed.
• CCFIN and CCDELQ before CCSTMT. The statement's new balance and minimum payment must be computed on the fully-charged, fully-fee'd balance, so the finance charge and delinquency/over-limit fees post before the cycle is cut.
• CCGL after the posting/fee/interest rows exist. The GL feed mirrors POSTTRN, so it runs after CCPOST/CCFIN/CCDELQ have written their rows. This is the exact order CCNIGHT submits: CCPOST → CCFIN → CCDELQ → CCGL → CCSTMT.
• CCACCRPT last (reconcile) — it cross-checks the open-account balance total against the GLENTRY receivable DR total, so it runs after CCGL.

D. Data Files (data dictionary) ↑ top

All files are in library CARDCOR, grounded in src/sources.mjs. Money is packed decimal 11P2 (nine integer digits) or 9P2; dates are stored as zoned integers in YYYYMMDD (or YYYYMM forms as noted); APR is packed 5P2 as an annual percent (18.00 = 18%); the fee factor is packed 5P3 (0.020 = 2%).

CARDHLDR — Cardholder master (UNIQUE, key CHNO)

ACCTMST — Account master (UNIQUE, key ACCTNO)

CARDMST — Issued cards (UNIQUE, key CARDNO); CARDLF — LF by ACCTNO+CARDNO

CARDLF is a logical over CARDMST keyed ACCTNO then CARDNO — an account's cards in order.

AUTHTRN — Authorization log (UNIQUE arrival, key AUTHID) — journaled

POSTTRN — Posted-transaction ledger (UNIQUE arrival, key POSTID) — journaled

POSTLF is a logical over POSTTRN keyed ACCTNO then POSTID — the source the CCTRNINQ subfile loads from.

FEESCHED — Fee/rate schedule (UNIQUE, key FEECD)

Seeded rows (from the day-cycle driver): MIN 25.00 / 0.020 (min-payment floor/pct), LTE 29.00 (late fee), OVL 35.00 (over-limit fee). Programs fall back to hard-coded defaults (25.00/0.020, 29.00, 35.00) if a code is missing.

STMTHDR — Statement/cycle header (UNIQUE, key SACCTNO+CYCLENO)

DELQLF — Delinquency-management LF over ACCTMST (key DELQBKT+ACCTNO)

A logical over ACCTMST exposing ACCTNO, CHNO, CRLIMIT, ACCBAL, APR, ASTAT, DELQBKT, MINPAY, keyed DELQBKT then ACCTNO so a delinquency pass reads worst-first-in-bucket order. CCDELQ scans this LF but CHAINs the base ACCTMST for its UPDATE.

DISPTRN — Dispute/chargeback ledger (UNIQUE arrival, key DISPID) — journaled

DISPLF is a logical over DISPTRN keyed ACCTNO then DISPID — an account's dispute history in order.

GLENTRY — GL posting feed (SQL DDL table)

Relationships

• CARDHLDR 1—N ACCTMST (ACCTMST.CHNO → CARDHLDR.CHNO).
• ACCTMST 1—N CARDMST (cards); 1—N AUTHTRN; 1—N POSTTRN; 1—N STMTHDR; 1—N DISPTRN.
• DISPTRN.DPOSTID → POSTTRN.POSTID (a dispute references a posted purchase).
• POSTLF / CARDLF / DISPLF / DELQLF are logicals over their base PFs (no separate data).
• GLENTRY is an aggregate feed keyed only by batch (no per-row FK; ACCT is a GL account string).

E. Operations Runbook ↑ top

E.1 Day-in-the-life

1. Build / verify the library (first time or after a reset): create CARDCOR, load the source with the seeder, compile CCSETUP and run it — CALL PGM(CARDCOR/CCSETUP) creates every object, journals the three ledger tables to CCJRN, and is the single build entry point.
2. Set up masters as needed: CALL CARDCOR/CCACCMNT (add / change / close accounts) and CALL CARDCOR/CCISSUE (issue a card onto an open account).
3. Take authorizations through the day: each CALL CARDCOR/CCAUTH approves or declines against open-to-buy and logs an AUTHTRN row; approvals place a HELDAUTH hold.
4. Take payments as they arrive: CALL CARDCOR/CCPAY (account + amount) reduces the balance and writes a POSTTRN 'Y' row.
5. Handle disputes on demand: CALL CARDCOR/CCDISP opens a dispute (provisional credit), CALL CARDCOR/CCCHGBK resolves it won/lost.
6. Run the night batch: CALL CARDCOR/CCNIGHT queues CCPOST → CCFIN → CCDELQ → CCGL → CCSTMT onto CCNITEQ.
7. Operators can inquire any time via CALL CARDCOR/CCMENUP (account / transaction inquiry).

Pre-checks: confirm the job's library list includes CARDCOR; confirm the three ledger tables are journaled to CCJRN (they are, after CCSETUP).

Post-checks after posting (CCPOST):

• CCPOST SETTLED=n SKIP=n — SETTLED equals the count of auths that were 'A'; those auths are now 'S', each has a POSTTRN 'P' row, and each account's ACCBAL rose by its amount while HELDAUTH fell (floored 0).
• Re-running CCPOST should report SETTLED=0 (all now 'S') — the idempotency check.

E.2 Statement / month-end close

1. Confirm the day's/cycle's authorizations are posted (CCPOST) so balances are current.
2. Run the finance charge and delinquency passes: CCFIN then CCDELQ (order matters — both feed the balance the statement bills).
3. Post the GL feed: CCGL (once per cycle — no re-run guard; see C.2 note).
4. Cut the statement: CALL CARDCOR/CCSTMT PARM('001') (the cycle number). Confirm CCSTMT CUT=n CYCLE=001 and inspect the spooled statement.
5. Reconcile with the COBOL report: CALL CARDCOR/CCACCRPT.

Reconciling figures (the same the day-cycle and SIM drivers assert):

• Open-account balance — CCACCRPT OPEN-ACCTS n BAL amt = count and SUM(ACCBAL) over ASTAT='O' accounts; non-open accounts are counted separately.
• GL is balanced — SUM(AMT) WHERE DRCR='D' equals SUM(AMT) WHERE DRCR='C' in GLENTRY (e.g. the monthly SIM closed at DR=CR=5017.49). CCGL writes exactly two rows per POSTTRN row, so after one run COUNT(GLENTRY) = 2 × COUNT(POSTTRN).
• Receivable cross-check — CCACCRPT GLENTRY-RECV-DR n AMT amt is the SUM of 1400-RECV debit rows written by CCGL — the “IN BALANCE” idiom comparing the ledger's receivable side to the account portfolio.
• Finance charge — CCFIN CHARGED=n TOTFC=amt; per account %DECH((LASTBAL+ACCBAL)/2 × APR/1200) (e.g. ADB 730.00 @ 18% = 10.95).
• Minimum payment — on ACCTMST.MINPAY and STMTHDR.MINDUE, the greater of 25.00 or 2% of the new balance (e.g. 5125.00 → 102.50).

E.3 Failure & re-run rules

Each program DSPLYs a one-line summary. The safe-to-rerun posture differs per program:

F. Developer Reference ↑ top

The complete program surface, from src/sources.mjs. All objects are in library CARDCOR; source is held as JS string constants and loaded into the library's source physical files (QDDSSRC / QRPGLESRC / QCBLLESRC / QCLSRC / QSQLSRC) by src/seed.mjs.

F.1 Programs

CCISSUE (IN PACCTNO, PCARDNO, PEXPDT) — RPG

Issues a card onto an open account. Guards the account exists and is open (ASTAT='O'); idempotent (CHAIN(E) CARDR first, skip if the card already exists); writes a CARDMST row with CSTAT='A' for the caller-supplied card number.

CCAUTH (IN PACCTNO, PCARDNO, PAUTHDT, PAUTHAMT, PMCC; OUT POUTRSP) — RPG

Open-to-buy authorization. WOTB = CRLIMIT − ACCBAL − HELDAUTH (packed). Non-open account or amount > OTB → 'D'; else 'A' with HELDAUTH += AUTHAMT. Always writes an AUTHTRN row (A or D). Next AUTHID via committed MAX.

CCPOST — RPG

Pass over AUTHTRN; for each AUTHRSP='A': write POSTTRN 'P', ACCBAL += AUTHAMT, HELDAUTH −= AUTHAMT (floored 0), flip 'A'→'S'. DSPLYs SETTLED/SKIP. Seeds POSTID once from committed MAX.

CCPAY (IN PACCTNO, PPAYAMT) — RPG

Reduces ACCBAL by the payment, floored at 0 (an overpayment zeroes the balance; the excess is not carried as a credit — documented simplification), writes a POSTTRN 'Y' row with a negative TRNAMT. Guards the account exists.

CCFIN — RPG

Pass over ACCTMST; for open, non-zero accounts: WADB=(LASTBAL+ACCBAL)/2, WRATE=APR/1200, WFC=%DECH(WADB×WRATE); if >0, write POSTTRN 'I' and add to balance. Nested if/else only.

CCDELQ — RPG

Pass over DELQLF: ACCBAL>CRLIMIT → over-limit fee (OVL); else DELQBKT≥1 → late fee (LTE). Writes POSTTRN 'F', adds to balance, freezes (ASTAT='F') if DELQBKT≥3. Note: never increments DELQBKT (F.5).

CCSTMT (IN WCYCLE) — RPG

Cuts statements for open non-zero accounts: min pay = greater of floor (MIN FEEAMT) or pct (MIN FEEFCTR), capped at the balance; writes STMTHDR, sets MINPAY and LASTBAL=NEWBAL, prints STMTP spool.

CCGL — RPG (embedded SQL, commitment control)

Pass over POSTTRN; maps each row to a balanced DR/CR pair by TRNTYPE (P/Y/F/I), inserts two GLENTRY rows using %ABS(TRNAMT), ends with EXEC SQL COMMIT. No period watermark (F.5).

CCDISP (IN PACCTNO, PPOSTID, PDISPAMT, PREASON; OUT POUTRSP) — RPG

Opens a dispute against a posted purchase: validates the account and that POSTID exists and is 'P'; writes DISPTRN 'O', a POSTTRN 'C' provisional credit (negative amount), and reduces ACCBAL by the dispute amount (Reg-Z provisional credit). PPOSTID is packed to match the packed caller. POSTTRN opened UF A (both CHAIN and WRITE).

CCCHGBK (IN PDISPID, POUTCOME; OUT POUTRSP) — RPG

Resolves an open dispute: 'W' won → DISPTRN 'O'→'W', balance unchanged; 'L' lost → write POSTTRN 'B' rebill (+amount), restore ACCBAL, DISPTRN 'O'→'L'. Guards the dispute exists and is still open. Nested if/else only.

CCACCMNT (IN PACTION + fields; OUT POUTBAL, POUTSTAT, POUTRSP) — RPG

Account-master maintenance: 'A' add (guarding CHAIN, reject if exists), 'C' change (limit/APR/status), 'I' inquire (balance/status out), 'X' close (ASTAT='C'). Every UPDATE re-CHAINs first.

CCACCINQ / CCTRNINQ / CCMENUP — RPG (5250)

Account inquiry, transaction-subfile inquiry, and the routing menu (B.2).

CCACCRPT — COBOL (ILE)

COMP-3 FD over ACCTMST byte-for-byte; totals ACCBAL for 'O' accounts; EXEC SQL SUM over GLENTRY receivable DR rows; “IN BALANCE” cross-check. Zoned nS0 map to PIC S9(n) DISPLAY, packed nP2 to COMP-3.

CCSETUP / CCNIGHT — CL

CCSETUP: single build entry point — DLTF/CRTPF/CRTLF/CRTDSPF/CRTPRTF/RUNSQLSTM, CRTBNDRPG/CRTBNDCBL/CRTCLPGM for every program, then CRTJRNRCV/CRTJRN/STRJRNPF (AUTHTRN, POSTTRN, DISPTRN to CCJRN). CCNIGHT: creates CCNITEQ and SBMJOBs the five night steps.

F.2 The next-id idiom & embedded SQL

Every arrival-sequence id (AUTHID, POSTID, DISPID) is generated with embedded SQL, not a native reposition:

-- once at entry for a multi-write batch, then bump a local counter per WRITE
exec sql select coalesce(max(postid),0) into :wnewid from cardcor.posttrn;
wnewid += 1;

This is a documented design-around (PLAN.md §5): a SETGT *HIVAL / READP next-id generator over an output-opened file does not see rows written earlier in the same job, so it returned 1 on every call after the first and the resulting duplicate-key WRITEs were silently dropped. Embedded-SQL MAX always sees committed rows. Multi-write batch programs (CCPOST/CCFIN/CCDELQ) query MAX once then bump locally within the run. Other embedded-SQL idioms: CCGL's two INSERTs + COMMIT, and CCACCRPT's SELECT COUNT/SUM ... INTO.

F.3 Journaling & commitment control

• Journaling. CCSETUP creates journal receiver CCRCV and journal CCJRN, then STRJRNPF ... IMAGES(*BOTH) on the three audit-critical ledgers: AUTHTRN, POSTTRN, DISPTRN. Both before- and after-images are captured, so every row insert on those tables is journaled and reconstructable (the cc_journal suite verifies this including a receiver roll).
• Commitment control. The GL path routes its money through embedded SQL under the job's commitment definition (the caller does STRCMTCTL) and finalises with a real EXEC SQL COMMIT — a documented quirk is that commitment control / ROLLBACK are honored on the SQL path but not the native-record path, so the GL posting deliberately uses the SQL path for real commit semantics.
• Authority. A documented platform behaviour is that RVKOBJAUT *ALL + GRTOBJAUT *USE on a batch-written file can throw SFF9802 even under QSECOFR; the app's authority proof grants *CHANGE (not *USE) to a writer on a batch-written file.

F.4 TRNTYPE / status codes

F.5 Known simplifications & gaps (honest)

Grounded in PLAN.md §6 and the source; all confirmed correct-as-designed or documented, none a platform bug hidden from the operator:

• CCDELQ never increments DELQBKT (SIM-2026-Y4). Its header says it “bumps” the bucket, but no statement in the code advances it. A bucket-1 account is late-fee'd every cycle but is never auto-frozen by CCDELQ alone (freeze needs DELQBKT≥3); freeze is reachable only via an over-limit balance or a pre-seeded bucket. Comment/implementation mismatch.
• CCGL re-posts the whole ledger (SIM-2026-M3/Y4). No posting watermark; run once per cycle by discipline. Always balanced (SUM(DR)=SUM(CR)), but the row count inflates on re-runs.
• Fixed post date. POSTDT is a compiled-in literal (20260201) in CCPAY/CCFIN/CCDELQ/CCDISP/CCCHGBK; there is no operator-set processing-date control row.
• Overpayment not credited. CCPAY floors the balance at 0; an overpayment leaves a zero balance and the excess is not carried as a credit balance.
• ADB is a two-point proxy. CCFIN uses (LASTBAL+ACCBAL)/2, not true per-day balances.
• GL is chart-of-accounts-lite. Four DR/CR account pairs, a balanced feed — not a full double-entry general ledger.
• No maker–checker. No segregation-of-duties approval workflow (B.3).
• Deliberately out of scope: rewards/loyalty, multi-currency, real FICO scoring.

Platform quirks the app is coded around (not fixed in the engine): nested if/else only (free-form elseif mis-scopes its END-IF); free-form CHAIN can't reference a fixed-form KLIST; output-opened-file read invisibility (hence embedded-SQL MAX); a native WRITE against an input-only (IF) F-spec is silently lost (hence UF A opens); PRTF field-position digits end at DDS col 44; packed/zoned parameter-type match for CHAIN keys.

G. Glossary ↑ top

ADB — Average Daily Balance

The balance a finance charge is computed on. CARDCOR/i uses a two-point proxy (LASTBAL+ACCBAL)/2 (not true per-day tracking), × the monthly periodic rate.

APR — Annual Percentage Rate

The annual interest rate, stored as a percent (18.00 = 18%). The monthly periodic rate is APR/1200.

Authorization / open-to-buy

A real-time approve/decline of a purchase against open-to-buy = CRLIMIT − ACCBAL − HELDAUTH. An approval places a HELDAUTH hold until settlement releases it.

Chargeback

Resolution of a dispute in the cardholder's favour ('W' won) — the provisional credit becomes permanent. The opposite ('L' lost) rebills the amount.

Commitment control

Transactional grouping of SQL changes under a commitment definition, finalised by COMMIT (or undone by ROLLBACK). CARDCOR/i uses it on the GL path (CCGL), where the emulator honors it.

Delinquency bucket (DELQBKT)

How many cycles past due an account is; drives late-fee assessment and (at ≥3) the freeze path. Note: CCDELQ does not itself advance this value (F.5).

Dispute / provisional credit

A cardholder challenge to a posted purchase. CCDISP opens it (DISPTRN 'O'), posts a provisional credit (POSTTRN 'C') and drops the balance while it is open (Reg-Z).

Finance charge

Interest assessed on the ADB (CCFIN), written as a POSTTRN 'I' row and added to the balance.

HELDAUTH (held authorization)

The sum of open authorization holds on an account; it reduces open-to-buy until each auth settles (CCPOST releases the matching amount).

Idempotent

Safe to run again with the same result. CCPOST (auth marker 'A'→'S') and CCISSUE (dup CHAIN) are idempotent; CCGL/CCFIN/CCDELQ are not (run once per cycle).

Journaling (CCJRN)

Recording before/after images of row changes to a journal. The three ledgers (AUTHTRN, POSTTRN, DISPTRN) are journaled with IMAGES(*BOTH).

MCC — Merchant Category Code

A 4-character code classifying the merchant, stored on each authorization.

Minimum payment

The least the cardholder must pay this cycle: the greater of a floor (25.00) or a percentage (2%) of the new balance, capped at the balance (CCSTMT).

Open-to-buy (OTB)

CRLIMIT − ACCBAL − HELDAUTH — the amount still available to authorize.

Posting / settlement

Turning an approved authorization into a real ledger entry: CCPOST writes POSTTRN 'P', raises ACCBAL and releases the hold.

PRTF / spool

A printer file (STMTP) and the spooled output it produces — here the printed statement cut by CCSTMT.

SBMJOB / *JOBQ

Submit Job / job queue — the IBM i mechanism to queue a program as a batch job. CCNIGHT submits the night chain onto CCNITEQ.

Subfile (SFL/SFLCTL)

A 5250 display construct listing many rows on one screen. CCTRNINQ loads a subfile of an account's posted transactions from POSTLF.

TRNTYPE

The one-character posted-transaction type on POSTTRN: P/Y/F/I/C/B (F.4).