LINKS/i — Golf Course / Country Club

LINKS/i runs the operations and member billing of a golf course / country club: membership classes and recurring dues, tee-time booking and played rounds (green fees with a per-class discount), pro-shop inventory and sales, F&B chits with per-class minimum-spend tracking, cart rentals, member payments, and a chargeable-to-account member ledger (the receivables book) that ages into late fees and closes into a balanced GL feed. Every business rule lives in RPG (with one ILE COBOL control report and one SQLRPGLE GL close); the three CL job cycles — GCDAILY, GCMONTH, GCPERIOD — chain the programs. This manual is the reference for the operator who runs the online screens and the periodic batch cycles, and for the developer maintaining the application. It is grounded entirely in the committed source (golf-app/src/sources.mjs, src/seed.mjs, and the test/gc_*.mjs drivers).

A. Overview & Architecture ↑ top

A.1 What it does

LINKS/i runs a club's member-facing operations and the receivables billing behind them:

• Membership & dues — every member belongs to a class (Full / Senior / Junior / Social) whose tariff drives monthly dues, the F&B minimum spend, and the green-fee discount. The monthly cycle bills recurring dues to the member ledger.
• Tee-times & rounds — a booking becomes a played round; the daily cycle prices the green fee against the member's class discount, adds any cart charge and every sponsored guest's (full-rate) fee, writes a durable round record, and posts the total to the member ledger.
• Pro-shop — inventory items are sold to members (or walk-ins); the daily cycle relieves on-hand stock by exactly what shipped and posts the sale to the member ledger.
• F&B chits & minimum spend — food-and-beverage chits post to the ledger and accumulate a period F&B-spend tracker; the monthly cycle charges any member who spent below their class minimum the shortfall.
• Cart rentals & payments — standalone cart rentals post to the ledger; member receipts post as negative ledger amounts, lowering the balance.
• Ageing, late fees & GL close — the period cycle ages each member's account from their last payment, charges a flat late fee past a grace window, prints the AR ageing report, and posts a balanced GL feed of the ledger's movement.

A.2 The member-ledger spine

The application is organised around one central book: GCMEMB.MBAL, the live chargeable-to-account member balance, mirrored by the GCLEDG member ledger (one immutable row per posting). The invariant every test asserts is that MBAL moves only by postings (up) and payments (down), and always reconstructs exactly as SUM(GCLEDG.LEDAMT) over the member's own rows. Charges raise the balance and write a positive ledger row; a receipt lowers it and writes a negative one.

• Every business event lands on the ledger. Green fee/cart/guest (G), pro-shop sale (P), F&B chit (F), cart rental (C), dues (D), minimum-spend shortfall (M), late fee (L) and receipt (R) all become GCLEDG rows, keyed (MEMNO, LEDSEQ) so a member's entries sit together for a keyed partial read.
• The ledger is never updated once written. It is a running account history, so the balance is always independently reconstructible — the basis for the GCARRPT control report and the GCGLPST GL close.
• Two conservation invariants back it. Pro-shop on-hand only ever falls by exactly what a sale ships (never for an out-of-scope walk-in), and a receipt lowers MBAL by exactly the amount received.

Everything runs in library LINKS. There is no SQL-PL layer here (unlike LOANSVC/i): the logic is hand-written RPG over keyed physical files, with a single SQLRPGLE program (GCGLPST) for the GL feed and one ILE COBOL program (GCARRPT) for the control report.

A.3 Component & flow

  ONLINE                 BATCH (three job cycles)
  ------                 ------------------------
  GCMENU (5250)          GCDAILY  --> GCRNDPST   (green fee/cart/guest -> ledger 'G')
    opt 1 -> GCMEMBIQ                 GCSALEPST  (pro-shop sale, relieve stock -> 'P')
    opt 2 -> GCLEDIQ                  GCCHITPST  (F&B chit -> 'F', accumulate MFBSPND)
             (subfile over GCLEDG)    GCCARTPST  (standalone cart rental -> 'C')
                                      GCRCPTPST  (receipt -> 'R', negative amount)
                       GCMONTH  --> GCDUES     (recurring dues -> 'D')
                                      GCMINCHK   (F&B min-spend shortfall -> 'M', reset MFBSPND)
                                      GCAGE      (AR ageing report, PRTF)
                       GCPERIOD --> GCLATE     (ageing -> late fee -> 'L')
                                      GCGLPST    (balanced GL close -> GCGLDIST)
                                      GCARRPT    (COBOL member-ledger control report)
       \                    /
        v                  v
     GCMEMB  (MBAL: the live member balance)   <-- moved ONLY by postings / payments
        |
        +--> GCLEDG   (one immutable row per posting; balance = sum(LEDAMT))
        +--> GCROUND / GCITEM / GCGUEST ...    (per-stream durable records)

A single event — say a played round — flows: GCRNDPST reads the played (TSTAT='P') tee-time, prices the green fee against the member's class discount, sums cart and guest fees, writes a GCROUND row, flips the tee-time to 'G', raises GCMEMB.MBAL and writes one GCLEDG 'G' row. Every posting program derives its ledger sequence number from stable source digits so a re-run lands on the identical key and the CHAIN(EN) guard refuses it — each cycle is idempotent by construction.

A.4 Object inventory

The full catalogue is 11 PFs + 1 LF + 1 SQL table (with index), 3 DSPFs and 1 PRTF, driven by 14 RPG programs, 1 ILE COBOL program and 4 CL programs. Sections D and F expand each.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

LINKS/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 a JOBQ/scheduler for the batch cycles). 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 LINKS — the tested jobs run with LIBL = QSYS QGPL LINKS QTEMP and CURLIB = LINKS.

The batch programs take no CALL parameters. There is no LOANSVC-style single control row; instead each program reads its processing/billing date and period from hard-coded working-storage defaults in the source (e.g. GCDUES.WDT INZ(20260901), GCDUES.WPERIOD INZ(9), GCLATE.WRUNDT INZ(20260930)). A scheduled submission is therefore a bare CALL; to process a different date/period the source constant is changed and the program recompiled. This is honest to the source — the app models the business rules, not a production date-parameter surface.

B.2 The menu & member inquiry (GCMENU / GCMEMBIQ / GCMEMBD)

GCMENU is the operator entry point: a plain menu (GCMENUD record GCMENU) offering 1. Member Inquiry and 2. Ledger Inquiry. It program-to-program CALLs the chosen inquiry, redisplays on return, reports Invalid option for anything else, and exits on F3.

GCMEMBIQ is a plain (non-subfile) inquiry over GCMEMBD record MEMINQ. The operator keys a member number; the program CHAINs GCMEMB then GCCLASS and renders the master record plus the class tariff and the live F&B-spend figure. An unknown member shows Member not found. with the detail cleared.

Member-inquiry fields (MEMINQ)

B.3 The ledger subfile screen (GCLEDIQ / GCLEDD)

GCLEDIQ is the app's subfile screen. It presents a member header plus a subfile (DDS record LSFL under control record LCTL, SFLPAG(5) per page, SFLSIZ(0050), ROLLUP/ROLLDOWN) of that member's ledger entries. The operator keys a member number; the program clears the subfile, CHAINs GCMEMB for the header, then does a keyed partial read of GCLEDG (SETLL + READE on MEMNO) loading one subfile row per ledger entry, and redisplays.

Subfile columns (LSFL)

Actions & keys

• Key a Member number and Enter — reload the header + ledger subfile for that member.
• Roll Up / Roll Down — page through a member with more than five ledger rows.
• F3 (Exit) — leave the program (both inquiry screens and the menu use CA03).

Both inquiry screens are strictly read-only: they display the member master, class tariff and ledger. No balance or ledger row is edited from the screen — every money movement happens through the batch posting programs, so the ledger stays an immutable audit trail.

B.4 Controls & audit posture (no four-eyes maker–checker)

Honest statement: LINKS/i does not model a true four-eyes maker–checker / separate-authorization workflow. There is no "one user posts, a second user approves" step: a booking that is marked played, a chit, a sale, a receipt are all posted by the next batch cycle with no interactive approval gate. The manual documents the control model the application does have:

• Immutable ledger audit trail (GCLEDG). Every money movement is one durable, never-updated ledger row, so a member's balance is always fully reconstructable as SUM(LEDAMT). The tests assert this reconstruction for every member after every cycle.
• Status gating by record lifecycle. Programs act only on records in the right state: GCRNDPST processes only TSTAT='P' (played) tee-times; the posting programs process only 'O' (open/unposted) sales/chits/carts and 'U' (unapplied) receipts, flipping each to its posted status so it cannot be picked up twice.
• Scope gating. A pro-shop sale or chit with a blank member number (a walk-in cash-and-carry) never posts to any member ledger — it is explicitly out of scope for member billing, the same way a guest fee is scoped to its sponsoring member.
• Manual hold is a privilege flag, not a billing gate. MHOLD='Y' parks a member for new privileges but does not stop dues, min-spend or postings — a held member still owes. The tests verify M00004 (held) is still billed and never has its status changed by a cycle.
• Conservation invariants. Pro-shop ONHAND falls by exactly what a sale ships (floored at zero), and a receipt lowers MBAL by exactly the amount received — the two invariants the daily suite checks.
• Idempotency guard. Every posting derives its ledger key from stable source digits and a CHAIN(EN) guard refuses a duplicate, so re-running a cycle never double-posts (see F.3).

In sum, the control posture is immutable-ledger audit + record-lifecycle/scope gating + conservation invariants + derived-key idempotency, rather than a segregation-of-duties approval workflow.

C. Batch Jobs & the Job Cycles ↑ top

LINKS/i's processing runs as three CL-driven cycles rather than one monolithic nightly job: a daily posting cycle (GCDAILY), a monthly billing cycle (GCMONTH), and a period ageing/close cycle (GCPERIOD). Each CL ADDLIBLE LIB(LINKS), chains its member programs by bare CALL, and ends with a completion banner. All programs take no CALL parameters; dates/periods are working-storage constants in the source (B.1).

-- the three cycles are parameterless SBMJOBs:
SBMJOB CMD(CALL PGM(LINKS/GCDAILY))  JOB(GCDAILY)
SBMJOB CMD(CALL PGM(LINKS/GCMONTH))  JOB(GCMONTH)
SBMJOB CMD(CALL PGM(LINKS/GCPERIOD)) JOB(GCPERIOD)

C.1 Full batch program set

C.2 Daily / monthly / period detail

Daily — GCDAILY

The CL chains, in order: GCRNDPST → GCSALEPST → GCCHITPST → GCCARTPST → GCRCPTPST. Green fees price the standard 45.00 fee against the member's class discount, add the standard 20.00 cart charge (if CARTYN='Y') and every sponsored guest's flat 45.00 fee (never discounted), write a GCROUND row and one GCLEDG 'G' row. Pro-shop sales relieve ONHAND by exactly the quantity sold (floored at zero). Chits post and add to MFBSPND. Receipts post as a negative amount and lower MBAL.

Expected DSPLY (gc_daily oracle: 3 played tee-times, 1 sale, 2 chits, 1 cart, 1 receipt):
  GCRNDPST POSTED=3 SKIP=1     the 4th tee-time is BOOKED, not played -> skipped
  GCSALEPST POSTED=1 SKIP=0
  GCCHITPST POSTED=2 SKIP=0
  GCCARTPST POSTED=1 SKIP=0
  GCRCPTPST APPLIED=1 SKIP=0
Resulting member balances: M00001=201.00 (65 round + 36 shop + 200 chit - 100 receipt),
M00002=121.00 (81 round + 40 chit), M00003=62.50 (42.50 round + 20 cart), M00004=0.00.
Pro-shop glove on-hand 40 -> 38. Every member's balance = sum of their own ledger rows.

Monthly — GCMONTH

The CL chains GCDUES → GCMINCHK → GCAGE. GCDUES bills every MSTAT='A' member their class dues (a manual hold does not skip billing). GCMINCHK compares each member's accumulated MFBSPND against the class minimum: a member below the minimum is charged the shortfall (ledger 'M', a positive amount); one who met it gets a zero-amount 'M' marker row (so the idempotency guard has something to find on a re-run); either way MFBSPND resets to zero for the next period. GCAGE prints the AR ageing report.

Expected DSPLY (gc_monthly oracle: FL/SR/JR/FL-held members; M00002 pre-set MFBSPND=80):
  GCDUES BILLED=4 SKIP=0
  GCMINCHK CHARGED=3 MET=1 SKIP=0   M00002 met 75.00 minimum (spent 80) -> no charge
  GCAGE MEMBERS=4 TOTAL=...
Balances: M00001=400.00 (250 dues + 150 shortfall), M00002=150.00 (dues only, met),
M00003=85.00 (60 + 25), M00004=400.00 (250 + 150; held still billed). MFBSPND all reset to 0.

Period — GCPERIOD

The CL chains GCLATE → GCGLPST → GCARRPT. GCLATE ages each member from their last payment (the most recent 'R' ledger row; a member with no payment history is judged from their join date), on a 30/360 convention with a 30-day grace window, and charges a flat 25.00 late fee (ledger 'L') only while MBAL > 0. GCGLPST posts a balanced two-leg GL close (F.4). GCARRPT prints the COBOL control report.

Expected DSPLY (gc_period oracle, run date 20260930):
  GCLATE CHARGED=2 OK=1        M00002 (ancient join) + M00004 (89d) late; M00001 (29d) within grace; M00003 zero-bal skipped
  GCGLPST BATCH=202609 ROWS=...
  GCARRPT OWED    190.00 / MEMBERS 4.00 / OUTSTND 3.00 / ONHOLD 1.00
GL: DR total = CR total = 270.00 (230.00 charges leg + 40.00 receipts leg).

C.3 Ordering & dependencies

• DAILY before MONTHLY. The daily chits build up MFBSPND, which the monthly GCMINCHK reads to compute the shortfall — run the month's dailies first or the minimum-spend charge is over-assessed against an empty tracker.
• Within DAILY the order is fixed by the CL: rounds, then sales, then chits, then carts, then receipts. Receipts run last so a same-day payment nets against the day's charges.
• Within MONTHLY: dues before min-spend before ageing; the ageing report reflects the freshly billed balances.
• MONTHLY (and the month's DAILY) before the PERIOD close. GCLATE ages off the posted ledger and GCGLPST nets the ledger movement into the GL, so the ledger must be fully posted first. Within PERIOD: late fees, then GL close (so the fees are in the movement), then the control report.

D. Data Files (data dictionary) ↑ top

All files are in library LINKS, grounded in the DDS/SQL of golf-app/src/sources.mjs. Dates are stored as signed 8S,0 in YYYYMMDD form; money is packed decimal (9P,2 or 11P,2); the green-fee discount is a packed percentage (5P,2, e.g. 20.00 = 20%).

GCCLASS — Membership-class tariff (PK MCCLASS)

Seeded classes: FL 250.00/150.00/0%, SR 150.00/75.00/20%, JR 60.00/25.00/50%, SO 40.00/50.00/0%.

GCMEMB — Member master (PK MEMNO)

Seeded members: M00001 HARRIET NORTHGATE (FL), M00002 DEREK PENNYFEATHER (SR), M00003 CASSIE OAKMOOR (JR), M00004 REGINALD ASHCOMBE (FL, MHOLD=Y). All start MBAL=0, MFBSPND=0.

GCGUEST — Guest register (composite PK MEMNO, GSTNO)

GCTEE — Tee-time bookings (PK TEENO)

GCROUND — Played-round history (PK RNDNO)

GCITEM — Pro-shop inventory (PK ITEMNO)

Seeded items: PS100001 glove 18.00/40, PS100002 balls 32.50/60, PS100003 head-cover set 45.00/3 (critically low), PS100004 polo 55.00/25.

GCSALE — Pro-shop sales (PK SALENO)

GCCHIT — F&B chits (PK CHITNO)

GCCART — Standalone cart rentals (PK CARTNO)

This is the genuinely separate rental stream (e.g. a non-golf outing); tee-time-attached cart charges live on GCTEE/GCROUND instead.

GCLEDG — Member ledger (composite PK MEMNO, LEDSEQ)

Never updated once written; a member's balance is always SUM(LEDAMT) over their own rows.

GCLEDLF — Ledger logical file (keyed LEDTYPE, MEMNO, LEDSEQ)

PFILE(GCLEDG) alternate access path leading on LEDTYPE — the "everything of this kind this period" access the GL close wants without a scan. Same record format, a different leading key from the base PF (which leads on MEMNO).

GCRCPT — Member payments/receipts (PK RCPTNO)

GCGLDIST — GL distribution feed (SQL, PK GLSEQ)

Index GCGLDACC on (ACCT, DRCR) supports the "already posted per account" net-off query the close runs to stay reconcilable across repeated period closes.

Relationships

• GCMEMB.MCLASS → GCCLASS.MCCLASS (dues / minimum / discount tariff).
• GCTEE / GCSALE / GCCHIT / GCCART / GCRCPT / GCGUEST all carry MEMNO → GCMEMB.
• GCROUND.TEENO → GCTEE.TEENO (round derived from a played tee-time).
• GCSALE.ITEMNO → GCITEM.ITEMNO (inventory relieved on sale).
• GCLEDG.MEMNO → GCMEMB.MEMNO (the member's own posting history); GCLEDLF is its per-type path.
• GCGLDIST is the period-keyed GL aggregate (no per-row FK; sourced by summing GCLEDG).

E. Operations Runbook ↑ top

E.1 Day-in-the-life

1. Confirm the job's library list includes LINKS (LIBL = QSYS QGPL LINKS QTEMP, CURLIB = LINKS).
2. Ensure the day's raw records are in place: played tee-times marked TSTAT='P', guests with GSTSTAT='O', open sales/chits/carts ('O'), unapplied receipts ('U').
3. Submit the daily cycle: SBMJOB CMD(CALL PGM(LINKS/GCDAILY)).
4. Post-check the five DSPLY lines (below).
5. Answer member enquiries through CALL LINKS/GCMENU (option 1 member, option 2 ledger).

Post-checks after the daily cycle:

• GCRNDPST POSTED= equals the played tee-times; SKIP= counts booked/cancelled/already-posted ones. Each posted tee-time is now TSTAT='G' with a GCROUND row.
• GCSALEPST: ONHAND fell by exactly the quantity sold; no walk-in (blank-member) sale posted.
• GCCHITPST: each member's MFBSPND rose by their chit total (the figure GCMINCHK will read).
• GCRCPTPST: each receipt is now RSTAT='A' and posted a negative 'R' ledger row; MBAL fell by exactly the amount received.
• Spot-reconcile a member: their MBAL equals the sum of their own GCLEDG rows.

E.2 Month-end & period close

1. Confirm every business day's GCDAILY has run for the month (so MFBSPND is complete).
2. Submit the monthly cycle: SBMJOB CMD(CALL PGM(LINKS/GCMONTH)). Confirm GCDUES BILLED=, GCMINCHK CHARGED=/MET=, and the GCAGE report. Verify every member's MFBSPND reset to 0.00.
3. After the month's dailies and monthly are posted, submit the period cycle: SBMJOB CMD(CALL PGM(LINKS/GCPERIOD)). Confirm GCLATE CHARGED=/OK=, GCGLPST BATCH=/ROWS=, and the GCARRPT control lines.
4. Reconcile the GL feed:

SELECT DRCR, SUM(AMT) FROM LINKS.GCGLDIST GROUP BY DRCR;
-- total debits must equal total credits (the balanced-legs invariant)
SELECT ACCT, DRCR, SUM(AMT) FROM LINKS.GCGLDIST GROUP BY ACCT, DRCR ORDER BY ACCT;

Reconciling figures (the same ones the period volume test checks against a hand-derived oracle):

• Balanced GL — SUM(AMT WHERE DRCR='D') = SUM(AMT WHERE DRCR='C'), always, because the charges leg and receipts leg each balance independently.
• Charges leg — DR 1300-MBAR = the gross of every new charge type; matched krona-for-krona by the per-type revenue CR lines (Dues/Green-fee/Pro-shop/F&B/Cart/Min-spend/Late-fee).
• Receipts leg — DR 1000-CASH = cash received this period; matched by CR 1300-MBAR.
• Movement only — each close nets off what is already posted per account, so a re-run adds nothing and the GL stays balanced.
• Control report — GCARRPT OWED = Σ MBAL over members with a positive balance; OUTSTND = that member count; ONHOLD = held-member count.

E.3 Failure & re-run rules

Each program DSPLYs a POSTED/BILLED/CHARGED/APPLIED count and a SKIP count. A healthy re-run shows the work count at 0 (everything already posted) and the skip count carrying the already-done rows — the derived-key idempotency guard (F.3) makes every cycle safe to re-submit.

F. Developer Reference ↑ top

The program surface, from golf-app/src/sources.mjs. All objects are in library LINKS. The RPG programs are column-exact fixed-form (C/D-spec helpers) with /free blocks; the pattern throughout is a *LOVAL SETLL + READ loop over the driving file, an EXSR per row, and a DSPLY summary line.

F.1 Posting programs (daily)

GCRNDPST — green fee / cart / guest

For each played tee-time (TSTAT='P'): derive RNDNO from the tee-time number ('RN0' + %subst(TEENO:4:5)); guard with CHAIN(EN) on GCROUND; price the green fee WBASE(45) − discount% from the member's class; add the cart (20) if CARTYN='Y'; walk every sponsored guest (READE on MEMNO, matching date and GSTSTAT='O') at the flat WGSTFEE(45); write GCROUND, flip the tee-time to 'G', raise MBAL, write one GCLEDG 'G' row keyed 20000000 + digits. Note the explicit wgst = 0 reset per round — RPG working storage is global, so without it a prior round's guest total would survive into a later guest-less round.

GCSALEPST — pro-shop sale

For each open sale (SSTAT='O') with a non-blank member: ledger key 30000000 + digits, CHAIN(EN) guard; relieve ONHAND by SQTY (floored at zero); flip the sale to 'P'; raise MBAL; write GCLEDG 'P'. Blank-member walk-ins are skipped.

GCCHITPST — F&B chit

For each open chit: key 40000000 + digits; flip to 'P'; raise both MBAL and MFBSPND; write GCLEDG 'F'.

GCCARTPST — standalone cart rental

For each open rental: key 50000000 + digits; flip to 'P'; raise MBAL; write GCLEDG 'C'.

GCRCPTPST — member payment

For each unapplied receipt (RSTAT='U'): key 80000000 + digits; flip to 'A'; lower MBAL by exactly RCPTAMT; write GCLEDG 'R' with a negative amount. The full amount always applies — a club account is a running balance, so it may run credit.

F.2 Billing / close programs (monthly & period)

GCDUES — recurring dues (monthly)

For each active member: ledger key 10000000 + (member-digits × 100) + WPERIOD, CHAIN(EN) guard; look up class dues; raise MBAL; write GCLEDG 'D'. A held member is still billed.

GCMINCHK — F&B minimum-spend shortfall (monthly)

For each active member: key 60000000 + (digits × 100) + WPERIOD; shortfall = max(0, MCMINSP − MFBSPND); raise MBAL by the shortfall; reset MFBSPND to 0 regardless; always write a GCLEDG 'M' row (positive shortfall → CHARGED, zero → MET marker). The zero-amount MET row is the re-run guard.

GCAGE — AR ageing report (monthly)

For each member with MBAL > 0: find the most recent 'R' ledger row (or the join date), compute days on a 30/360 serial, bucket 0/1/2/3 (≤30 / ≤60 / ≤90 / >90 days), and print AGEDTL on GCAGEP with an AGETOT footer. Overflow re-prints AGEHDR via OFLIND(*IN90).

GCLATE — ageing → late fee (period)

For each active member with MBAL > 0: serialise the run date and last-payment date on a 30/360 convention; if the gap is within the 30-day grace → OK; else key 70000000 + (digits × 100) + WPERIOD, guard, raise MBAL by the flat WFEE(25), write GCLEDG 'L'. A member with no payment history is judged from their join date.

GCGLPST — balanced GL close (period, SQLRPGLE)

Sums the ledger by type; nets off what each account already holds (EXEC SQL SELECT SUM(AMT) per account) so only new movement posts; then writes two independently balanced legs (F.4) via a glrow subroutine that INSERTs into GCGLDIST and only counts the row when SQLCOD=0.

GCARRPT — member-ledger control report (period, ILE COBOL)

Reads GCMEMB sequentially; totals owed over positive balances, counts members, outstanding accounts and held members; DISPLAYs OWED / MEMBERS / OUTSTND / ONHOLD.

F.3 The idempotency key convention

LINKS/i has no database sequence and no control-row cursor; instead every posting program derives its GCLEDG.LEDSEQ from stable source digits, so a re-run regenerates the identical key and the CHAIN(EN) guard on that key refuses the duplicate. The high digit namespaces the source stream; period-scoped charges fold in the period so a new period lands on a fresh key.

Several programs re-CHAIN the driving record after the guard/lookup reads (which move the file cursor) before updating it — e.g. GCRNDPST re-CHAINs the tee-time after walking the class and guest files. This is a deliberate cursor-restore, noted inline in the source.

F.4 Ledger types & GL accounts

The GL close maps each ledger type to a revenue/asset account. The charges leg debits AR (1300-MBAR) for the gross and credits each type's own revenue account; the receipts leg debits cash and credits AR — two legs, each balanced by construction.

Worked GL (gc_period oracle): DR 1300-MBAR 230.00 = CR 4100-DUES 180.00 + CR 4700-LATE 50.00; plus DR 1000-CASH 40.00 = CR 1300-MBAR 40.00. Grand total DR = CR = 270.00.

F.5 Engine-compatibility notes (FINDINGS)

Grounded in golf-app/FINDINGS.md. LINKS/i re-confirmed — but did not newly introduce — two already-documented ORDERIS/i engine behaviours in the DDS/subfile renderer (the NA-05/NA-07 estate area):

• Two-digit conditioning indicator (NA-05). In column form N31/31 on SFLDSP/SFLDSPCTL/SFLCLR, the DDS parser reads only the first digit, so N31 and 31 collapse onto indicator 3 instead of two independent ones — the intended "clear then don't display" vs "display" split is not honoured as designed.
• Stale subfile on a zero-row reload (NA-07). When GCLEDIQ reloads for a real member with no ledger rows, the prior pass's rows can still render even though the program issued SFLCLR; the header (name/balance) correctly updates to the new member's 0.00 figures.

Both are cosmetic/interactive-only with no data-integrity impact. No workaround was applied silently: test/gc_interactive.mjs asserts only the correct parts (the header update) and documents the stale-subfile behaviour inline rather than asserting a false pass or masking it with different DDS. The batch posting logic and every balance/ledger/GL invariant are unaffected.

G. Glossary ↑ top

Member ledger (GCLEDG)

The chargeable-to-account receivables book: one immutable row per posting. A member's balance (GCMEMB.MBAL) always reconstructs as the sum of their own ledger rows.

Membership class (GCCLASS)

The tariff table (FL/SR/JR/SO) driving each member's monthly dues, F&B minimum spend, and green-fee discount percentage.

Green-fee discount

A per-class percentage taken off the standard 45.00 green fee (e.g. Junior 50%). Guest fees are never discounted — always the flat 45.00.

Round (GCROUND)

A durable record of a green fee posted from a played tee-time, keyed independently of the tee-time so the history / GL feed has a stable audit trail.

F&B minimum spend / shortfall

Each class sets a period food-and-beverage minimum. A member who spends below it (tracked in MFBSPND) is charged the shortfall (ledger type M); the tracker then resets.

Manual hold (MHOLD)

A flag parking a member for new privileges. It does not stop billing — a held member still owes dues, min-spend and late fees.

Inventory conservation

The invariant that pro-shop ONHAND falls by exactly the quantity a sale ships (floored at zero), never for an out-of-scope walk-in.

Walk-in (blank-member) sale

A cash-and-carry pro-shop sale or chit with no member number — out of scope for member billing; posted to no ledger.

Ageing (30/360)

Measuring days since a member's last payment on a 30-days-per-month serial. Past the 30-day grace window, an outstanding balance draws a flat 25.00 late fee (GCLATE).

Balanced GL legs

The GL close posts a charges leg (DR AR, CR each revenue account) and a receipts leg (DR cash, CR AR), each balanced on its own, so DR = CR regardless of the period's mix.

Movement-only posting

The GL close nets off what each account already holds and posts only the new movement, so repeated period closes stay reconcilable.

Derived-key idempotency

Deriving a posting's ledger key from stable source digits so a re-run regenerates the same key and the CHAIN(EN) guard refuses the duplicate (F.3).

SBMJOB

Submit Job — the IBM i command that queues a program as a batch job (e.g. SBMJOB CMD(CALL PGM(LINKS/GCDAILY))). The LINKS/i cycles take no parameters.

Subfile

A 5250 display construct listing many rows on one screen (DDS SFL/SFLCTL). GCLEDIQ's ledger list is a subfile with paging (SFLPAG 5 / SFLSIZ 50) and roll keys.

SQLRPGLE / EXEC SQL

RPG with embedded SQL. Here only GCGLPST uses it, to sum the ledger and insert the GL distribution rows.