FITHUB/i — Fitness Club Membership & Billing

FITHUB/i is a single-location fitness-club membership and billing application: member and agreement maintenance, recurring monthly dues billing with freeze/pause and first-month pro-ration, auto-pay receipt posting, dunning/late-fee assessment, capacity-checked class booking and check-in, personal-training package usage with session-by-session revenue recognition, and a balanced GL close posted under commitment control. The whole estate is column-exact IBM i source — DDS physical and logical files, an SQL DDL table for the GL feed, RPG (fixed-form and **FREE) cycle programs, a COBOL cross-check report, and CL cycle drivers — loaded into library FITHUB. 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 (fitness-app/src/sources.mjs, src/seed.mjs, and the test/fithub_build.mjs / fithub_daily.mjs drivers).

A. Overview & Architecture ↑ top

A.1 What it does

FITHUB/i services the life of a fitness-club membership:

• Membership & agreements — maintain members (FHMEMBR) and their plan agreements (FHAGREE): create/change, inquire, and freeze/unfreeze an agreement. Each agreement links a member to a plan (FHPLAN: BAS/PLS/PRM) and carries a recurring-billing cursor (NEXTBILL).
• Recurring dues billing — bill every open agreement due on/before the run cutoff, pro-rating the very first partial month, skipping frozen agreements entirely (pause/resume with no backlog), and advancing each agreement's NEXTBILL one calendar month. Charges raise the member's running balance (MBAL) and write a dues ledger row.
• Auto-pay / receipts — apply cash receipts (FHRCPT) against the member's running balance and journal each payment to the ledger.
• Dunning & late fees — flag active members over the delinquency threshold as delinquent (MSTAT='D') and assess a flat late fee, once per crossing.
• Classes & bookings — capacity-checked booking, check-in, and cancellation against sessions (FHCLASS), maintaining a live seat count (CAPCNT vs CAPMAX).
• PT-package revenue recognition — draw one personal-training session down from a package (FHPTPKG) at a time, recognizing its slice of the pre-paid package price and sweeping the rounding residual on the final session so recognized revenue sums to the package price exactly.
• GL close — summarize the ledger by type and post balanced debit/credit rows to the GL feed (FHGLF) under commitment control, committing only if debits equal credits; a COBOL report (FHGLRPT) independently cross-checks the A/R posting.

A.2 Design shape: RPG/COBOL over DDS + a running-account ledger

FITHUB/i is a classic record-level-access IBM i application, not an SQL-PL app. A few shape points matter to operations:

• Running-account model. The member ledger is a single running balance (MBAL) on FHMEMBR, not a per-invoice A/R. Dues billing always adds the full or pro-rated charge; auto-pay subtracts a receipt (the balance may legitimately go negative — a credit balance). This is deliberate: club dues are a running account, not a per-invoice receivable.
• A durable, keyed ledger. FHLEDG is a UNIQUE-keyed PF, not a bare arrival file, on purpose: an output-opened non-keyed PF truncates on each program's OPEN, so a shared arrival ledger would only hold the last posting program's rows. The UNIQUE key routes writes through the keyed (append) path so the ledger accumulates across the whole cycle chain into a genuine audit trail. Every posting program assigns LEDGSEQ from a disjoint numeric band (section F.2) so keys never collide.
• Deferred-revenue liability for PT packages. A PT package's price is booked as a liability at purchase; recognizing revenue session-by-session draws that liability down. The GL posting debits the PT-package-liability account (not A/R) for recognized PT revenue.
• Truncating money math. RPG packed-decimal division-then-assignment truncates (does not round). First-month pro-ration and per-session PT amounts are computed on that basis; the PT final session sweeps the residual so a package always recognizes its full price. Operators reconciling by hand should truncate, not round, intermediate divisions.

Everything runs in library FITHUB. Journaling (FHJRN/FHRCV) is active on the two audit files FHAGREE and FHLEDG.

A.3 Component & flow

  MAINTENANCE / ONLINE        BATCH (periodic, via *JOBQ)
  --------------------        ---------------------------
  FHMNT  (member/agr,         MONTHLY  FHMONTH --> FHDUES(cutoff)  recurring dues
         freeze/unfreeze)                       --> FHDUESPR       dues statements
  FHBOOK1 (book/checkin/      DAILY    FHDAILY --> FHAUTOPAY       receipt posting
           cancel)            PERIOD   FHPERIOD--> FHDUNNING(dt)   delinquency + late fee
  FHMENU (5250 menu)                            --> FHPTUSE        PT usage recognition
    1 -> FHMBRIQ (plain)                        --> FHGLPST        balanced GL close
    2 -> FHLEDIQ (subfile)              cross-check: FHGLRPT (COBOL)

  every posting program --writes--> FHLEDG (durable keyed ledger, disjoint LEDGSEQ bands)
                                     FHMEMBR.MBAL (running balance)
  FHGLPST --summarizes FHLEDG by LTYPE--> FHGLF (balanced DR/CR, commit if in balance)

A single billing event flows: operator (or the FHMONTH CL) submits FHDUES with a cutoff date → it scans open agreements in NEXTBILL order via the FHAGEL access path → for each due, unfrozen agreement it computes the (possibly pro-rated) dues, raises FHMEMBR.MBAL, writes an FHLEDG 'D' row, and advances NEXTBILL one calendar month on FHAGREE (journaled).

A.4 Object inventory

The full catalogue is 9 PFs + 5 LFs + 1 SQL table, 3 DSPFs + 1 PRTF, 12 RPG programs + 1 COBOL program, and 4 CL programs, plus journal (FHJRN) and receiver (FHRCV). Sections D and F expand each.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

FITHUB/i has no CICS transaction identifiers and no menu-driven transid switch. On IBM i, each program is reached by name from a 5250 command-entry line (or a JOBQ/scheduler for the batch jobs). 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 FITHUB — the tested jobs run with LIBL = QSYS QGPL FITHUB QTEMP and CURLIB = FITHUB.

FHMNT, FHBOOK1 and FHPTUSE are callable programs with an *ENTRY parameter interface (dcl-pi): they are the program-to-program CALL idiom used by the test harness and by any wrapper. FHMENU, FHMBRIQ and FHLEDIQ are the three interactive 5250 programs. The batch cycle programs are covered in section C.

B.2 The operator menu & inquiries (FHMENU / FHMBRIQ / FHLEDIQ)

FHMENU displays a two-option menu (FHMENUD) and routes by a dynamic CALL: option 1 calls FHMBRIQ (member inquiry, plain WORKSTN), option 2 calls FHLEDIQ (ledger inquiry, subfile). F3 exits.

FHMBRIQ — member inquiry (plain)

Keys a member number; CHAINs FHMEMBR for name/status/balance and FHAGRML (agreements by member) for the plan, freeze flag and next-bill date, then redisplays. Enter re-inquires; F3 exits back to the menu.

FHLEDIQ — ledger inquiry (subfile)

The app's one subfile screen (FHLEDGD: record LSFL under control LCTL, SFLPAG(0012), SFLSIZ(0030)). Keys a member; on a match it clears the subfile (SFLCLR), loads the member's ledger rows from FHLEDML (ledger by member), and displays them. Control indicators are 41=SFLDSP, 42=SFLDSPCTL, 43=SFLCLR, 44=SFLEND(*MORE).

B.3 Maintenance & controls (FHMNT / FHBOOK1)

FHMNT is the member/agreement maintenance program, dispatched by a two-character action:

Create/change is validate-before-write and idempotent: a change re-CHAINs on the full key and UPDATEs the found record; a create WRITEs a fresh record. The program re-CHAINs immediately before each UPDATE so it never double-UPDATEs a stale read.

FHBOOK1 is the class booking program, also dispatched by action:

C. Batch Jobs & the Periodic Cycle ↑ top

FITHUB/i's processing runs as three periodic cycles rather than one monolithic nightly job: a monthly cycle (recurring dues + statements), a daily cycle (auto-pay), and a period cycle (dunning + PT revenue + GL close). Each cycle is a small CL driver that ADDLIBLE FITHUB then calls its programs in order. The drivers are meant to be submitted through a *JOBQ (the tested queue is FITHUB/NITEQ) so each program fully closes its output files before the next opens them — the same single-threaded-batch idiom the setup notes call out.

-- create the batch queue once
CRTJOBQ JOBQ(FITHUB/NITEQ) TEXT('FITHUB batch queue')

-- submit a cycle driver (parameterless)
SBMJOB CMD(CALL FITHUB/FHMONTH) JOB(FHMONTH) JOBQ(FITHUB/NITEQ) HOLD(*NO)

-- or drive dues billing to a SPECIFIC cutoff date directly
SBMJOB CMD(CALL FITHUB/FHDUES PARM('20260801')) JOB(FHDUES1) JOBQ(FITHUB/NITEQ) HOLD(*NO)

The dues and dunning programs take a cutoff/run date parameter (PRUNDT, YYYYMMDD, via the *ENTRY PLIST). The FHMONTH / FHPERIOD wrappers pass the sentinel '99999999' to bill/dun the whole due backlog in one pass; a caller that needs to stop at a specific business date instead calls FHDUES/FHDUNNING directly with that date, exactly as the daycycle test does.

C.1 Full batch program set

C.2 Monthly / daily / period detail

Monthly — FHMONTH (FHDUES → FHDUESPR)

FHDUES does a forward SETLL *LOVAL / READ pass over FHAGEL (agreements keyed by NEXTBILL), stopping at the first agreement whose NEXTBILL > PRUNDT. For each open agreement due for billing:

• Frozen (FRZSTAT='Y'): billing is skipped and NEXTBILL is NOT advanced — freeze pauses the billing cursor entirely, so a later unfreeze resumes from the same date with no backlog and no gap. Counted in FROZEN-SKIPPED.
• First-bill pro-ration: if NEXTBILL = STARTDT (the agreement's very first bill) and the start day-of-month is not the 1st, dues are pro-rated for the partial month: MONDUES × remaining-days / days-in-month, where remaining-days = days-in-month − day + 1 (bills the start day itself; leap-Feb handled by the 4/100/400 rule). Counted in PRORATED. The result truncates to cents.
• Otherwise: a full month's MONDUES.

It then raises FHMEMBR.MBAL, writes an FHLEDG 'D' row, and advances NEXTBILL one calendar month (month +1, wrapping the year at 12→1, day forced to 01). FHDUESPR then prints one statement per 'D' ledger row.

Expected DSPLY (cycle 1: 3 agreements, one prorated first bill, none frozen):
  FHDUES BILLED=3 FROZEN-SKIPPED=0 PRORATED=1
M1 BAS full 39.99, M2 PLS prorated 59.99*16/31 -> 30.96 (truncated), M3 PRM full 99.99
Expected DSPLY (cycle 2, M3 frozen):
  FHDUES BILLED=2 FROZEN-SKIPPED=1 PRORATED=0

Daily — FHDAILY (FHAUTOPAY)

FHAUTOPAY makes one pass over FHRCPT (arrival). Each receipt reduces the member's MBAL directly (MBAL = MBAL − RCPTAMT; may go negative — a valid credit balance) and writes an FHLEDG 'P' row. There are no per-invoice rows to apply against — this is a running account.

Expected DSPLY (one receipt applied):
  FHAUTOPAY POSTED=1 NOMEMBER=0

Period — FHPERIOD (FHDUNNING → FHPTUSE → FHGLPST)

FHDUNNING does a forward pass over FHMEMBR: any active ('A') member with MBAL over the threshold (WTHRESH, seeded 0.00) is flagged MSTAT='D' and assessed a flat 15.00 late fee (added to MBAL, 'F' ledger row). A member already 'D' is not re-flagged/re-feed on a second pass — only a fresh crossing from 'A' triggers a new fee.

FHPTUSE (called once per session) draws one session from a package: the per-session recognized amount is PKGPRC / SESSBUY, and the final session recognizes whatever balance of PKGPRC remains (sweeping the rounding residue) and sets PKGSTAT='X', so a package's recognized revenue sums to PKGPRC exactly. It writes an FHPTUSG usage-event row and an FHLEDG 'R' row; it does not touch MBAL (the member paid up front).

FHGLPST sums FHLEDG by LTYPE and inserts balanced DR/CR rows into FHGLF under commitment control, then re-reads the batch and COMMITs only if DR=CR (else ROLLBACK).

Expected DSPLY:
  FHDUNNING FLAGGED=2               e.g. M2 + M3 both over threshold
  FHPTUSE PKG00001 SESSION RECOGNIZED  33.33, 33.33, 33.34 -> sums 100.00
  FHGLPST IN BALANCE DR=... CR=... COMMITTED
  FHGLRPT ... CROSS-CHECK: IN BALANCE

C.3 Ordering & dependencies

• Within monthly: FHDUES before FHDUESPR — statements print from the 'D' ledger rows dues billing just wrote.
• DUES / AUTOPAY before DUNNING. Dunning keys off MBAL: dues must have raised it and auto-pay must have reduced it, so a member paid to (or below) the threshold is correctly spared. In the tested cycle M1 auto-paid to exactly 0.00 escapes dunning; M2 (never paid) and M3 (frozen but still carrying its balance) are flagged.
• PT usage before GL close. FHGLPST summarizes the whole ledger including the 'R' rows, and cross-checks depend on them.
• GL close last, then cross-check. FHGLPST posts, then FHGLRPT independently verifies A/R.
• Single-thread the queue. Sequence the cycle programs through *JOBQ so each closes its output files before the next opens them.

D. Data Files (data dictionary) ↑ top

All files are in library FITHUB, grounded in the DDS/SQL in fitness-app/src/sources.mjs. Dates are stored as signed numeric YYYYMMDD (8S 0); money is packed decimal (xP 2); A is character.

FHMEMBR — Member master (key MBRNO)

FHPLAN — Plan / dues-rate catalog (key PLANCD)

Seeded catalog (FHPLNLD): BAS “Basic Monthly” 39.99 / 0 PT; PLS “Plus Monthly” 59.99 / 1 PT; PRM “Premium Monthly” 99.99 / 4 PT.

FHAGREE — Membership agreements (key AGRNO)

FHCLASS — Classes / sessions (key CLSNO)

FHBOOK — Bookings / check-ins (key BOOKNO)

FHPTPKG — PT packages (key PKGNO)

FHPTUSG — PT usage events (key USGSEQ)

FHLEDG — Member ledger / A/R audit trail (key LEDGSEQ, UNIQUE)

FHRCPT — Receipts / auto-pay input (key RCPTNO)

FHGLF — GL posting feed (DB2 SQL table)

Logical files & access paths

• FHAGRML — agreements by member (key MBRNO, AGRNO); the member-inquiry drill-down.
• FHAGEL — agreements keyed by NEXTBILL; the dues-billing cursor's access path (forward SETLL *LOVAL/READ scan of every open agreement in due order).
• FHBOKCL — bookings by class (key CLSNO, BOOKNO); capacity accounting.
• FHBOKML — bookings by member (key MBRNO, BOOKNO); member booking history.
• FHLEDML — ledger by member (key MBRNO, LEDGSEQ); the FHLEDIQ subfile's access path.

Relationships

• FHAGREE.MBRNO → FHMEMBR.MBRNO; FHAGREE.PLANCD → FHPLAN.PLANCD.
• FHBOOK.MBRNO → FHMEMBR; FHBOOK.CLSNO → FHCLASS (CAPCNT maintained on booking/cancel).
• FHPTPKG.MBRNO → FHMEMBR; FHPTUSG.PKGNO → FHPTPKG (one usage row per session).
• FHLEDG.MBRNO → FHMEMBR (running-account journal, no per-invoice FK by design).
• FHRCPT.MBRNO → FHMEMBR (receipts applied to the running balance).
• FHGLF is the aggregate GL feed (keyed by batch/account, no per-row FK).

E. Operations Runbook ↑ top

E.1 Day-in-the-life

1. Ensure the library list includes FITHUB and the batch queue exists (CRTJOBQ JOBQ(FITHUB/NITEQ), once).
2. Handle interactive work as it arrives: CALL FITHUB/FHMENU for inquiries; CALL FITHUB/FHMNT PARM(...) to create/change members and agreements or freeze/unfreeze; CALL FITHUB/FHBOOK1 PARM(...) to book/check-in/cancel; CALL FITHUB/FHPTUSE PARM(...) to recognize a PT session.
3. Load the day's receipts into FHRCPT, then submit the daily cycle: SBMJOB CMD(CALL FITHUB/FHDAILY) JOBQ(FITHUB/NITEQ).
4. Post-check the auto-pay run (below).

Pre-checks: confirm the plan catalog is loaded (FHPLNLD ran; BAS/PLS/PRM present); confirm the job's library list includes FITHUB.

Post-checks after the daily cycle:

• FHAUTOPAY POSTED=n NOMEMBER=0 — NOMEMBER should be 0; a non-zero count means a receipt referenced a member not in FHMEMBR.
• Each posted receipt reduced its member's MBAL and wrote a 'P' ledger row of the same amount.
• A member paid to exactly the threshold or below will be spared by the next dunning pass.

E.2 Month-end & period close

1. Monthly dues. Submit FHMONTH (bills the whole backlog via the '99999999' sentinel), or drive a specific cutoff: SBMJOB CMD(CALL FITHUB/FHDUES PARM('<YYYYMMDD>')). Confirm FHDUES BILLED=/FROZEN-SKIPPED=/PRORATED= matches expectation and statements printed (FHDUESPR PRINTED=).
2. Period close. Submit FHPERIOD (FHDUNNING → FHPTUSE → FHGLPST); recognize outstanding PT sessions with FHPTUSE before the GL post. Confirm FHGLPST IN BALANCE ... COMMITTED.
3. Cross-check. CALL FITHUB/FHGLRPT and confirm CROSS-CHECK: IN BALANCE.
4. Review and reconcile the GL feed:

SELECT ACCT, DRCR, SUM(AMT) FROM FITHUB.FHGLF GROUP BY ACCT, DRCR ORDER BY ACCT, DRCR;

Reconciling figures (the same ones the daycycle simulation checks against a hand-derived oracle; note RPG division truncates):

• GL in balance — SUM(AMT) where DRCR='D' equals SUM(AMT) where DRCR='C', and both are non-zero. FHGLPST only commits when this holds.
• A/R debit — account 120000 DR = total dues billed + late fees assessed (the two ledger types that post to A/R). Example from the tested cycle: dues (39.99×2 + 30.96 + 59.99 + 99.99) + two 15.00 late fees.
• PT liability drawdown — account 230000 DR = recognized PT revenue = SUM of the package's 'R' rows = PKGPRC exactly (e.g. 33.33 + 33.33 + 33.34 = 100.00).
• COBOL cross-check — FHGLRPT reads the packed member balances (COMP-3) and confirms the GL A/R debit equals dues+fees (IN BALANCE).

E.3 Failure & re-run rules

Each program DSPLYs a one-line result (section F.5). The critical safety points are the ledger key bands (no cross-program collisions), the freeze/NEXTBILL cursor discipline, and the dunning guard.

F. Developer Reference ↑ top

The complete program surface, from fitness-app/src/sources.mjs. All objects are in library FITHUB.

F.1 Programs (12 RPG + 1 COBOL + 4 CL)

FHPLNLD (RPGLE) — plan-catalog loader

WRITEs the three reference plans (BAS 39.99/0PT, PLS 59.99/1PT, PRM 99.99/4PT) into FHPLAN. Called from FHSETUP.

FHMNT (RPGLE) — member/agreement maintenance

dcl-pi *ENTRY callable. Actions MC/AC/MI/FZ/UF (section B.3). Validate-before-write; re-CHAIN immediately before each UPDATE. Returns pOutFound and pOutMsg.

FHDUES (RPGLE) — recurring dues billing

Forward SETLL *LOVAL/READ over FHAGEL (NEXTBILL order); skips frozen (no NEXTBILL advance), pro-rates the first partial month, bills full months otherwise; raises MBAL, writes 'D' ledger row, advances NEXTBILL +1 month on FHAGREE. PARM PRUNDT cutoff.

FHBOOK1 (RPGLE) — booking / check-in / cancel

dcl-pi *ENTRY callable. Actions BK/CI/CX; capacity-checked booking (CAPCNT vs CAPMAX), cancel decrements CAPCNT. BOOKNO from a whole-file high-water scan.

FHAUTOPAY (RPGLE) — receipt posting

One pass over FHRCPT; MBAL = MBAL − RCPTAMT, writes 'P' ledger row. LEDGSEQ band 20000000.

FHDUNNING (RPGLE) — dunning + late fee

Forward pass over FHMEMBR; active member with MBAL > WTHRESH (0.00) → MSTAT='D', +WLATEFEE (15.00), 'F' ledger row. Guard: already-'D' not re-feed. PARM PRUNDT.

FHPTUSE (RPGLE) — PT usage + revenue recognition

dcl-pi *ENTRY callable. Per-session amount PKGPRC/SESSBUY; final session sweeps the residual and sets PKGSTAT='X'. Writes an FHPTUSG event and an FHLEDG 'R' row; does not touch MBAL. Rejects not-found / already-exhausted.

FHGLPST (SQLRPGLE) — GL posting, commitment control

ctl-opt commit(*yes). Sums FHLEDG by LTYPE, inserts balanced DR/CR rows (section F.3), then re-reads the batch: COMMIT if DR=CR, else ROLLBACK.

FHDUESPR (RPGLE) — dues-statement print

Forward pass over FHLEDG; for each 'D' row, CHAIN FHMEMBR and write the FHDUESP statement lines to spool.

FHMBRIQ (RPGLE) — member inquiry (plain WORKSTN)

CHAIN FHMEMBR by IMBRNO, then FHAGRML for the member's agreement (plan/freeze/next-bill); redisplay.

FHLEDIQ (RPGLE) — ledger inquiry (subfile)

CHAIN FHMEMBR; SFLCLR then load the member's FHLEDML rows into LSFL. Indicators 41/42/43/44 = SFLDSP/SFLDSPCTL/SFLCLR/SFLEND.

FHMENU (RPGLE) — operator menu

Reads MOPT; indicator-conditioned dynamic CALL 'FHMBRIQ' (opt 1) / 'FHLEDIQ' (opt 2).

FHGLRPT (CBLLE) — COBOL GL cross-check

Reads FHMEMBR (COMP-3 FD) totalling balances; embedded SQL sums dues+fees from FHLEDG and the A/R debit from FHGLF; DISPLAYs IN BALANCE / OUT OF BALANCE.

FHSETUP / FHMONTH / FHDAILY / FHPERIOD (CLP)

Setup (build/journal/authority/seed) and the three cycle drivers (section C).

F.2 Ledger key bands (the collision-free durable ledger)

FHLEDG is UNIQUE-keyed so writes append instead of truncating on OPEN. Each posting program seeds its LEDGSEQ from a disjoint band and, at start, does a high-water scan of that band to resume above the last key it wrote — so a second same-period run never collides with the first run's rows.

F.3 GL account map (FHGLPST postings)

PT usage debits the package-liability account (not A/R) because the member already paid cash for the package at purchase (booked as a liability then); recognizing revenue as sessions are used draws that liability down.

F.4 Notable idioms & conventions

• Callable *ENTRY programs — FHMNT, FHBOOK1, FHPTUSE take a dcl-pi parameter list (action + keys + OUT status), the program-to-program CALL-with-parameters idiom.
• Cutoff/run-date PARM — FHDUES and FHDUNNING take a YYYYMMDD via *ENTRY PLIST; the wrappers pass '99999999' for “whole backlog”.
• Forward *LOVAL scan — the billing cursor (FHAGEL keyed NEXTBILL) and the dunning/statement passes all use SETLL *LOVAL / READ to walk a file in key order.
• High-water key scan — sequence-assigning programs scan their key band (or the whole file, for BOOKNO/USGSEQ) to find the next free key before writing.
• Truncating packed math — RPG division-then-assignment truncates; pro-ration and per-session amounts are computed on that basis, with the PT final-session residual sweep guaranteeing the package sums to PKGPRC. (Note the + 0.005 half-cent nudge in FHPTUSE's per-session slice.)
• Embedded SQL under commitment control — FHGLPST uses ctl-opt commit(*yes) with SET OPTION COMMIT=*CS, a balance re-read, and COMMIT/ROLLBACK; FHGLRPT uses embedded SQL SELECT ... INTO against the same feed.
• Nested if (not elseif) in FHMENU — option dispatch uses separate if blocks rather than elseif, per a documented free-form elseif/end-if scoping quirk.

F.5 Program result messages (DSPLY)

G. Glossary ↑ top

Agreement (membership agreement)

The member→plan link (FHAGREE) carrying the recurring-billing cursor (NEXTBILL), freeze state, and term. One member may hold agreements over time.

Auto-pay

Applying a cash receipt (FHRCPT) against the member's running balance (FHAUTOPAY), writing a 'P' ledger row. RTYPE 'A' auto-pay vs 'M' manual.

Commitment control

DB2 transaction scope (commit(*yes)). FHGLPST posts GL rows, checks balance, and COMMITs only if debits equal credits, else ROLLBACKs.

Deferred revenue / PT-package liability

A PT package's price is a liability at purchase (cash received, service owed); recognizing revenue session-by-session draws the liability (account 230000) down.

Delinquency threshold (WTHRESH)

The balance above which dunning flags an active member delinquent and assesses a late fee. Seeded 0.00.

Dunning

The collections pass (FHDUNNING) that flags over-threshold members MSTAT='D' and assesses a flat late fee (WLATEFEE, 15.00), once per crossing.

Freeze / pause-resume

Suspending an agreement's billing (FRZSTAT='Y'). FHDUES skips it and does NOT advance NEXTBILL, so an unfreeze resumes from the same date with no backlog and no gap.

Ledger (running-account ledger)

The durable UNIQUE-keyed FHLEDG audit trail of every dues/payment/fee/PT-revenue movement, keyed by disjoint LEDGSEQ bands so writes append across the cycle chain.

NEXTBILL (billing cursor)

The agreement's next dues billing date (day always 01), advanced one calendar month per bill; the field FHAGEL is keyed on to drive billing in due order.

Pro-ration (first-month)

Charging only the partial first month when an agreement starts mid-month: MONDUES × remaining-days / days-in-month, truncated to cents. Only the very first bill, only if the start day isn't the 1st.

Revenue recognition (PT)

Recognizing PT-package revenue one session at a time (PKGPRC/SESSBUY), with the final session sweeping the rounding residue so recognized revenue sums to PKGPRC exactly.

Running account

A single balance per member (MBAL) that dues raise and payments reduce (may go negative — a credit balance), rather than a per-invoice A/R.

SBMJOB / *JOBQ

Submit Job to a job queue — the IBM i idiom for queuing the cycle drivers so each program closes its output files before the next opens them (queue FITHUB/NITEQ).

Subfile

A 5250 display construct listing many rows on one screen (DDS SFL/SFLCTL). FHLEDIQ's ledger list is the app's one subfile.