SteelFrame SYNBANK — Operations Manual

A developer & operator manual for SYNBANK, the clean-room synthetic core-banking estate that runs on the SteelFrame z/OS emulator. Every transaction, job, screen field and dataset below is drawn from the shipped SYNBANK source; nothing here is invented.

← back to the terminal conformance REST admin API

A. Overview & architecture

SYNBANK is a clean-room, synthetic core-banking estate modelled on the function of a Systematics-class mainframe bank core (system-of-record for customers, accounts, postings, interest, GL and reporting). It is single-tenant synthetic demo data — no proprietary source, screen text, record layouts or transaction codes are reproduced. The functional model is documented in notes/SYSTEMATICS-REFERENCE.md.

Naming convention across the estate:

The estate follows the classic core-banking split (see SYSTEMATICS-REFERENCE.md §5, §8, §9):

• Online, by day (CICS). Pseudo-conversational BMS 3270 transactions do real-time inquiry and memo posting — teller activity updates the available balance and writes journal/pending items, but the authoritative ledger is not yet updated.
• Batch, at night. A JCL-driven nightly cycle hard-posts the memo/captured activity to the master files, accrues loan interest, consolidates and balances the GL (debits = credits), and advances the business (cycle) date.
• Table-driven. Product behaviour, tran codes and GL mapping live in control tables (PRODUCT, TRANCODE, GLMAP, RATE) — a signature core-banking trait.

Sources: notes/SYSTEMATICS-REFERENCE.md, notes/SYNBANK-SIM-LOG.md, test/synbk_cics_install.mjs, test/synbk_batch_install.mjs.

B. Online transactions & screens

SYNBANK installs 10 CICS transactions into the SteelFrame CICS region (group SYSBK). Seven are the headline operator functions; three (SBRD/SBRB/SBFC) are read-only oracle helpers used by the test harness but installed as real transactions.

Sources: test/synbk_cics_install.mjs:150–153 (CICSPGMS + TXPGM), test/import/src/SYSBKCED.jcl:124–133, and each program's header comment (SYSBK*.cbl line 3).

All maps share a common layout

Every SYNBANK map is a 24×80 screen (DFHMDI SIZE=(24,80)) with:

• A bright title on row 1 (e.g. SYSBK CIF CUSTOMER INQUIRY).
• A COMMAND ==> line on row 2 (label at POS=(2,5), a 4-char unprotected input field at POS=(2,19)) — see §B.1.
• Function-specific input/output fields from row 3 down.
• A turquoise message line at POS=(22,5) (60 chars) that returns results/errors (e.g. CUSTOMER FOUND, NSF - INSUFFICIENT AVAILABLE FUNDS).

Common PF-key actions: ENTER submits the map (runs the function); PF3 ends the pseudo-conversational pin and frees the terminal.

SBCI — CIF customer inquiry SYSBKM01 / CIFMP

Purpose. Look up a customer master record by customer number and show identity + the accounts on file (the CIF relationship view). Read-only.

Flow. Type a customer number → ENTER → the map re-paints with the name, SSN, status and account list, and CFMSG shows CUSTOMER FOUND (or a not-found message). Seeded customers include 0000100001 AVERY N BLOOM, 0000100002 CORA D FENWICK, 0000100003 DELTA WORKS LLC, 0000100004 MIRA O SANDOVAL.

Source: SYSBKM01.bms (CIFMP), SYSBKCIN.cbl, seed in synbk_cics_install.mjs:74–79.

SBBL — account balance & history SYSBKM01 / BALMP

Purpose. Show the four balances for an account — ledger, collected, holds and available (avail printed in green) — plus up to four recent history lines. Read-only.

Flow. Type an account → ENTER → balances + history paint. Available = ledger − holds − uncollected float (memo-posting model, §A).

Source: SYSBKM01.bms (BALMP), SYSBKBAL.cbl.

SBTL — teller memo posting SYSBKM01 / TLRMP

Purpose. Post a teller financial transaction (deposit or withdrawal) as a memo post — it updates the available balance, writes a journal item for the nightly hard post, and enforces an available-funds edit.

SBHP — teller hold place / release SYSBKM03 / HLDMP

Purpose. Place or release a hold on a DDA account and see the effect on available funds. A hold reduces available balance without touching the ledger.

Flow. Place: account + P + amount → ENTER → HOLD PLACED, HLSEQ returns the assigned sequence; avail drops by the hold amount. Release: account + R + the sequence → ENTER → the hold is released. Holds live in SYN.BANK.THOLD.VSAM.KSDS.

Source: SYSBKM03.bms (HLDMP), SYSBKHLC.cbl.

SBPM — product / parameter maintenance SYSBKM03 / PRMMP

Purpose. Maintain a row in the product-parameter table (the table-driven config that governs a product's maintenance fee and min-balance waiver).

Flow. Type a product code → ENTER shows the current row; enter a new fee / waiver → ENTER updates SYN.BANK.PRODUCT.VSAM.KSDS. Seeded products: DDA1 REGULAR CHECKING, DDA2 BUSINESS CHECKING, SAV1 STATEMENT SAVINGS, LON1 INSTALLMENT LOAN.

Source: SYSBKM03.bms (PRMMP), SYSBKPRM.cbl, product seed synbk_cics_install.mjs:105–110.

SBMK / SBCK — account-master maintenance (maker–checker) SYSBKM02

These two transactions implement dual-control account-master maintenance. See §B.2 for the full four-eyes workflow.

SBMK — MAKER (map MNTMP)

SBCK — CHECKER (map APRMP)

Source: SYSBKM02.bms (MNTMP/APRMP), SYSBKMNT.cbl, SYSBKAPR.cbl.

B.1 The COMMAND ==> line — operator navigation

Every SYNBANK map carries a COMMAND ==> field on row 2 (4 chars, unprotected, at POS=(2,19); reachable at client column 20). It is a real-shop "command line" that lets an operator jump between SYNBANK transactions without freeing the terminal first.

How it works. Each SYNBANK program pseudo-conversationally re-pins its own transid via EXEC CICS RETURN TRANSID('SBxx'). Immediately after its RECEIVE MAP, a CHECK-SWITCH paragraph reads the COMMAND field, upshifts it, and — if it names a known, different SYNBANK transid — issues EXEC CICS XCTL PROGRAM(target). The target cold-paints (ERASE) and re-pins itself. A blank / same-transid command falls straight through to normal processing, preserving all field entry.

Source: notes/RETEST-SYNBANK-O1-REDESIGN-2026-07-31.md; COMMAND field present in all three mapsets (SYSBKM01/02/03.bms, field IDs CFCMD/BLCMD/TLCMD/MKCMD/APCMD/HLCMD/PMCMD).

B.2 Maker–checker (four-eyes) workflow

Sensitive account-master changes (name / status) use dual control: the operator who submits a change (the maker) cannot be the one who approves it (the checker).

1. Maker (SBMK). On MNTMP, enter the account, the field to change (Name or Status), and the new value → ENTER. The change is recorded as pending (it is not applied to the master yet).
2. Checker (SBCK). A different user runs APRMP, which displays the pending change (account, description, maker) → enter A to approve or R to reject → ENTER. Only on approve is the change applied to the account master.

C. Batch jobs & the nightly cycle

The SYNBANK nightly cycle is a 5-member JCL chain in SYN.BANK.PROCLIB, run in step order. It opens the cycle, hard-posts DDA activity, accrues loan interest, consolidates and balances the GL, and rolls the business date.

Sources: test/synbk_batch_install.mjs:69 (PROCS) and the JCL members SYNB*.jcl; program headers SYSBK*.cbl:3.

Two guard rails you must know

How an operator runs the cycle

Two equivalent ways:

1. Demand the schedule (recommended)

POST /api/sched/demand   { "job": "SYNBCTLS", "schid": "001" }

This kicks off the SYNBANK cycle through the ZWS scheduler; the folder SYNBANK then runs the 5 members in dependency order. Verify with GET /api/sched/jobs?folder=SYNBANK. Source: test/synbk_batch_install.mjs:155,158.

2. Submit the JCL directly

Submit each member from SYN.BANK.PROCLIB in order (SYNBCTLS → SYNBPOST → SYNBLNAC → SYNBGLP → SYNBCTLR) via POST /api/submit or the terminal SUBMIT path.

C.1 Full batch program set

Beyond the 5-member nightly spine, SYNBANK ships a broader batch program set (staged + compiled by test/synbk_batch_install.mjs:60–67). "Wired" means the program runs inside the current nightly cycle members; the rest are standalone (period-end, reporting, payments) — installed and runnable, but not in the current 5-member chain.

Source: BATCH array test/synbk_batch_install.mjs:60–67; purposes from each SYSBK*.cbl:3 header.

D. Data files (SYN.BANK.*)

The estate is defined by IDCAMS in SYSBKCED.jcl:65–94 and synbk_cics_install.mjs:206–220, and mapped to CICS FILE resources in synbk_cics_install.mjs:154–159. All KSDS clusters are on volume WORK01, SHAREOPTIONS(2 3).

Sources: SYSBKCED.jcl:65–94, synbk_cics_install.mjs:146–159,206–220, synbk_batch_install.mjs:127–147 (HIST ESDS + POSTING.INPUT PS). The 8 CICS-defined FILE resources are exactly the FILES object in synbk_cics_install.mjs:154–159; the rest are batch-accessed by DD.

E. Operations runbook

Reaching a transaction (:3270 terminal)

1. Open the SteelFrame terminal at http://localhost:3270/.
2. Type a SYNBANK transid (SBCI, SBBL, SBTL, SBMK, SBCK, SBHP, SBPM) and press ENTER — the map paints.
3. To switch to another SYNBANK transaction, type its transid into the COMMAND ==> field (row 2) and press ENTER (§B.1).
4. Press PF3 to end and free the terminal.

Read a balance

Start SBBL → type an account (e.g. DK00100000001) → ENTER. Read AVAIL (green) for spendable funds; HOLDS shows the reduction from placed holds.

Post a teller transaction

Start SBTL → account, D or W, amount → ENTER. A withdrawal over available funds is rejected (NSF - INSUFFICIENT AVAILABLE FUNDS) and nothing changes. The post is a memo post — it will be hard-posted by the nightly cycle.

Place / release a hold

Start SBHP. Place: account + P + amount → ENTER; note the returned REL SEQ. Release: account + R + that sequence → ENTER.

Do a maker–checker change

Maker runs SBMK (account, N/S, new value → ENTER). A different user runs SBCK, reviews the pending change, and enters A (approve) or R (reject) → ENTER. Only approval applies the change (§B.2).

Run the nightly cycle

1. Demand it: POST /api/sched/demand {job:'SYNBCTLS', schid:'001'} (or submit the 5 SYNB* members in order).
2. Watch GET /api/sched/jobs?folder=SYNBANK for all 5 to complete.
3. Check the SYSBKGLP trial balance — it must show debits = credits (no OUT-OF-BALANCE).
4. Confirm SYNBCTLR rolled the business date in the cycle-control record.

What the guard rails protect against

• COND=(0,LT,S4CAT) — if the GL extract concat fails, the GL post is skipped so you never post a half-consolidated GL.
• GL dr=cr balance check — an out-of-balance GL is flagged rather than silently rolled; treat OUT-OF-BALANCE as "halt and investigate".
• NSF edit — over-available withdrawals are rejected online, so the nightly hard post is not fed impossible debits.
• Four-eyes — master-data changes require a second user to approve.

F. Developer reference

Install path

Both drivers are idempotent (allocate / define / stage / compile / CEDA-define all tolerate "already present") and log on as IBMUSER/SYS1. Run without --live for a dry-run plan print.

The RDO / source-of-truth deck

test/import/src/SYSBKCED.jcl is the authoritative, human-readable statement of what is installed online: STEP 1 allocates SRC+COPYLIB, STEP 2 assembles the 3 BMS mapsets (DFHBMSCP PARM='SYSPARM(DSECT)'), STEP 3 IDCAMS-defines the clusters, STEP 4 compiles via IGYWCL, and STEP 5 reproduces the full CEDA DEFINE PROGRAM/MAPSET/TRANSACTION/FILE + INSTALL GROUP(SYSBK) list.

Copybook set

Online copybooks (staged by the CICS install, synbk_cics_install.mjs:146–148):

SYSBKCIF SYSBKXRF SYSBKACT SYSBKDDA SYSBKSAV SYSBKLON SYSBKGLM
SYSBKHST SYSBKTCT SYSBKPRD SYSBKGLX SYSBKRAT SYSBKCYC SYSBKPIN
SYSBKGLE SYSBKJRN SYSBKCAP SYSBKPND SYSBKTHD

The batch install stages additional copybooks discovered by COPY-scanning each batch program (synbk_batch_install.mjs:73–80,99–101) — e.g. fee / OD-link / routing / suspense copybooks that the online subset does not need. The BMS symbolic map DSECTs (SYSBKM01/02/03) are punched into COPYLIB by DFHBMSCP at assemble time, so adding a map field regenerates the DSECT — no copybook is hand-edited.

Compile / install on an ephemeral engine

To verify changes without touching the live region, spin up your own engine on a random port with a mkdtemp copy of web/, then point the driver at it:

STEELFRAME_PORT=0    # random port; read the chosen port from startup log
node test/synbk_cics_install.mjs  --live
node test/synbk_batch_install.mjs --live

The compile pipeline is the real IGYWCL cataloged procedure (COBOL.SYSLIB → SYN.BANK.COPYLIB, COBOL.SYSIN → SYN.BANK.SRC(pgm)); a maxcc > 4 aborts the install with the first IGY diagnostics.

Where the tests (battles) are

Battle names as cited in notes/RETEST-SYNBANK-O1-REDESIGN-2026-07-31.md §"FULL SYNBANK REGRESSION". The SYNBANK suites are synbk_* / synbank_*; tw_syn_* is a different estate and does not apply here.

G. Glossary

Fuller vocabulary: notes/SYSTEMATICS-REFERENCE.md §13.