HARBOR/i — Marina: Slips, Boat Registry, Rentals, Fuel Dock & Billing

HARBOR/i runs the day-to-day operation of a marina: a slip inventory by size-class and rate, a boat/owner registry, slip rental agreements (monthly, seasonal and transient), fuel-dock sales with inventory relief, service work orders, a customer ledger / accounts-receivable with open-item discipline, cash-receipt application, AR aging with late fees, and a balanced GL close. It is a classic IBM i application: DDS physical/logical files, fixed-form and free-form RPG batch programs, two interactive 5250 screens (one plain, one subfile), an ILE COBOL control report, an embedded-SQL GL post, and CL job cycles that string the batch programs together. This manual is the reference for the operator who runs the online screens and the three periodic cycles, and for the developer maintaining the application. It is grounded entirely in the committed source (marina-app/src/sources.mjs, src/seed.mjs, and the test/hb_*.mjs drivers). Everything runs in library HARBOR.

A. Overview & Architecture ↑ top

A.1 What it does

HARBOR/i covers the operational life of a boat's stay at the marina:

• Slip inventory & availability — slips are held per marina/basin, each tagged with a size class (S/M/L) and a status (V vacant, O occupied, M maintenance). The availability screen answers "have we got a 35ft slip free?" with live counts.
• Boat/owner registry & rental agreements — each boat-to-slip rental is an agreement carrying a billing cadence (M monthly, S seasonal, T transient) and a rate locked at signing (SLRATE), so a later change to the standard rate table never silently reprices an existing renter.
• Recurring billing — the monthly rent-roll charges every active monthly/seasonal agreement its locked rate; transient stays are billed per night at checkout.
• Fuel dock & service — fuel deliveries raise inventory and fuel sales relieve it gallon-for-gallon; a charged sale (and a completed service work order) posts a debit to the boat's ledger and raises its agreement balance.
• Customer ledger / AR — every charge and every payment is a ledger row (an audit trail, not just a running total). Each debit is its own open item; cash receipts apply oldest-due-first.
• Aging, late fees & GL close — the monthly close ages the receivables, assesses a flat late fee past a grace period, and posts balanced double-entry rows into the GL distribution.

A.2 The ledger invariant & conservation rules

Two invariants run through the whole application and are the operator's and the developer's north star:

• Agreement-balance invariant. HBSLIPAG.RBAL (the live ledger balance of an agreement) rises only via a charge (slip rent, fuel, service, or late fee) and falls only via cash application. Every charge/payment test asserts the balance moved by exactly the transaction amount — no rounding drift, no double-posting.
• Fuel-inventory conservation. HBFUEL.FQOH (gallons on hand) falls only via a fuel sale (HBFUELPOST relief) and rises only via a delivery (HBFUELRCV receipt), each by exactly the ticket quantity. A cash sale still relieves inventory but posts no ledger charge (paid on the spot at the dock terminal, out of this system's scope).

Each posting batch is also idempotent: a re-run never double-charges, double-relieves or double-pays. Idempotency is enforced either by a per-row posted-flag (FPOST/RPOST/WPOST), by a derived charge key (a charge number computed from the agreement plus the run period, so a same-period re-run regenerates the same key and is refused), or, for the GL, by a watermark-since-last-post subtraction.

A.3 Component & flow

  SETUP / SEED           ONLINE                 BATCH (three cycles)
  ------------           ------                 --------------------
  HBSETUP (CL)           HBMENU (5250)          DAILY  (HBDAILY CL):
    CRTPF/CRTLF/...        opt 1 -> HBAVAILQ      HBFUELRCV  (delivery in)
    CRTBNDRPG/...         opt 2 -> HBLEDGQ        HBFUELPOST (sales + relief + 'U' charge)
  HBREFLD (RPG)                                   HBWOPOST   (service 'S' charge)
    seeds MAR/SZCL/                               HBCASHAP   (cash apply, oldest-due-first)
    SLIP/BOAT/AGR/FUEL   HBAVAILQ (plain DSPF)  MONTHLY (HBMONTH CL):
                          slips by size class     HBRENTRL   (rent-roll 'R' charge)
                         HBLEDGQ  (subfile)       HBAGE      (AR aging -> HBDELQ)
                          boat's ledger history   HBLATEFEE  ('L' late fee)
                                                  HBGLPST    (balanced GL post)
                                                  HBAGERPT   (COBOL control report)
                                                 PERIOD (HBPERIOD CL):
                                                  HBTRNBILL  (transient checkout billing)

  Every charge/payment writes an HBCHG ledger row and moves HBSLIPAG.RBAL.
  Fuel sales/deliveries move HBFUEL.FQOH. The GL close reads HBCHG and writes
  balanced DR/CR rows into HBGLDIST (SQL table).

A single event — say a charged fuel sale — flows: the dock captures an HBFSALE ticket (FPOST='N') → the daily HBFUELPOST relieves HBFUEL.FQOH by the gallons sold, writes a 'U' ledger debit to HBCHG, raises the boat's HBSLIPAG.RBAL, and stamps the ticket FPOST='Y' so it is never posted twice.

A.4 Object inventory

The catalogue is 15 database files (12 PF + 3 LF), 1 SQL table + index, 4 DSPF/PRTF, 13 RPG/SQLRPGLE programs, 1 COBOL program and 4 CL programs. Sections D and F expand each.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

HARBOR/i has no CICS transaction identifiers. On IBM i each program is reached by name from a 5250 command-entry line (or a JOBQ/scheduler for the batch cycles). Before invoking anything, the job's library list must include HARBOR — the tested jobs run with LIBL = QSYS QGPL HARBOR QTEMP and CURLIB = HARBOR. The everyday entry point is the menu; from there the operator picks the two inquiry screens.

The batch drivers take no CALL parameters: run dates and periods are compiled into the RPG as named constants (e.g. WRUNDT INZ(20260901), WPERIOD INZ('09')), so a scheduled submission is a bare CALL. Only the three HB*Q/HBMENU programs are interactive; the batch programs run to completion and DSPLY a one-line result summary each.

B.2 The main menu (HBMENU / HBMENUD)

HBMENU is the front door. It shows a two-option menu and program-to-program CALLs the chosen inquiry, returning to the menu when the operator presses F3 in the inquiry. An option other than 1/2/blank sets the "Invalid option." message.

B.3 Slip availability inquiry (HBAVAILQ / HBAVAILD)

A plain (non-subfile) screen answering the everyday "have we got a slip of this class free?" question. The operator keys a marina code and a size class; the program CHAINs HBSZCL to render that class's description and its three rate tiers, then walks every slip at the marina (READE on HBSLIP by MARCD) and tallies live counts of vacant / occupied / maintenance slips of that class. Re-key and press Enter to inquire again; F3 exits.

B.4 Customer ledger subfile inquiry (HBLEDGQ / HBLEDGD)

HBLEDGQ is the app's subfile screen (DDS record LSFL under control record LCTL, SFLPAG(5) per page, SFLSIZ(30), ROLLUP/ROLLDOWN paging). The operator keys a boat number; the program CHAINs HBBOAT for the boat name, scans HBSLIPAG for that boat's agreement (header agreement number and live balance), then loads the boat's ledger rows from HBCHGLF (keyed by BOATNO) into the subfile in posting order. The subfile is cleared and reloaded each pass, so a fresh inquiry always reflects current data.

Subfile columns (LSFL)

C. Batch Jobs & the Periodic Cycles ↑ top

HARBOR/i's processing runs as three CL-driven cycles rather than one nightly monolith: a daily cycle (fuel receiving + fuel sale posting + service posting + cash application), a monthly cycle (slip rent-roll → AR aging → late fees → GL post → aging report), and a period cycle (transient-slip checkout billing). Each CL simply ADDLIBLE HARBOR then CALLs its member programs in order. None takes parameters.

-- run the three cycles (bare, parameterless CALLs / SBMJOBs)
CALL PGM(HARBOR/HBDAILY)
CALL PGM(HARBOR/HBMONTH)
CALL PGM(HARBOR/HBPERIOD)
-- or scheduled:
SBMJOB CMD(CALL PGM(HARBOR/HBDAILY)) JOB(HBDAILY)

C.1 Full batch program set

C.2 Daily / monthly / period detail

Daily — HBDAILY (HBFUELRCV, HBFUELPOST, HBWOPOST, HBCASHAP)

The daily cycle moves money and inventory captured during the day: (1) HBFUELRCV raises HBFUEL.FQOH by each unposted delivery's RQTY and replaces the standing cost; (2) HBFUELPOST relieves FQOH by each unposted sale's FQTY and, for a FPAY='A' (charged) sale, writes a 'U' ledger debit and raises the agreement balance — a FPAY='C' (cash) sale relieves inventory only; (3) HBWOPOST posts each complete-and-unposted work order as an 'S' debit; (4) HBCASHAP walks each unapplied receipt against its agreement's open charges oldest-due-first.

Expected DSPLY (the hb_cycle oracle: 1 delivery, 2 sales, 1 WO, 2 receipts):
  HBFUELRCV RECEIVED=    1 SKIP=    0   MAR1 gas 800.0 -> 1000.0 (+200.0)
  HBFUELPOST POSTED=    2 SKIP=    0    1000.0 -> 920.0 (-50 cash -30 charged)
  HBWOPOST POSTED=    1 SKIP=    0      AG000002 +75.00 service
  HBCASHAP APPLIED=    2 SKIP=    0     RC000001 full, RC000002 part

Monthly — HBMONTH (HBRENTRL, HBAGE, HBLATEFEE, HBGLPST, HBAGERPT)

(1) HBRENTRL writes one 'R' slip-rent charge per active M/S agreement for its locked SLRATE and raises the balance by exactly that amount — transient (T) agreements are skipped. (2) HBAGE finds each active agreement's oldest open charge and stamps HBDELQ.DDAYS = days past due on the 30/360 serial convention. (3) HBLATEFEE charges a flat 25.00 fee to any agreement whose DDAYS > 10 (the grace period), once per period. (4) HBGLPST sums the ledger by type and posts balanced GL rows. (5) HBAGERPT (COBOL) prints/DSPLYs the receivables control totals.

Expected DSPLY (the hb_cycle oracle):
  HBRENTRL BILLED=    4 SKIP=    1   4 monthly/seasonal billed, 1 transient skipped
  HBAGE CURRENT=    1 LATE=    4     only the un-charged transient is current
  HBLATEFEE CHARGED=    4 SKIP=    1
  HBGLPST BATCH=202609 ROWS=n       DR total = CR total

The GL post writes a balanced set for the movement since the last close: DR 1200-AR against CR 4100-RENT / 4300-FUEL / 4400-SVC / 4200-FEES for the billed charges, and DR 1000-CASH / CR 1200-AR for cash applied. In the seeded run the credit totals reconcile to slip-rent 4585.00, fuel 112.50, service 75.00, late fees 100.00 (4×25.00), and cash 500.00 — and total debits equal total credits.

Period — HBPERIOD (HBTRNBILL)

For every active transient (T) agreement whose RCKOUTDT is set (checkout recorded) and not yet billed, HBTRNBILL computes the number of nights between RSTRTDT and RCKOUTDT on the 30/360 serial convention (minimum one night), charges nights × SLRATE as an 'R' ledger row, raises the balance, and terminates the agreement (RSTAT='T'). An agreement not yet checked out (RCKOUTDT=0) is simply skipped until it is.

Expected DSPLY (AG000005 checks in 09-10, out 09-13 = 3 nights @ 45.00):
  HBTRNBILL BILLED=    1 SKIP=    4   3 x 45.00 = 135.00, RSTAT -> T

C.3 Ordering & dependencies

• Within the daily cycle the CL order is fixed: receive fuel before posting sales (so a same-day delivery is on hand), post fuel and service charges before cash application (so the day's new debits are settleable), and apply cash last.
• Within the monthly cycle the order is rent-roll → aging → late fees → GL post → report. Aging must see the current period's charges; late fees key off the just-stamped HBDELQ.DDAYS; the GL post must see the late-fee rows so its balanced set is complete.
• Daily before monthly. Because aging and the late fee work off open charges, run the day's fuel/service/cash posting first — e.g. a cash receipt settling a charge before the aging run keeps that agreement out of the delinquent set.
• Period is independent — transient checkout billing can run whenever a transient boat leaves; it touches only transient agreements and their own ledger rows.

D. Data Files (data dictionary) ↑ top

All files are in library HARBOR, grounded in the DDS in src/sources.mjs. Dates are stored as signed 8S0 in YYYYMMDD form; money is packed DECIMAL; fuel quantities are packed one-decimal gallons; fuel cost/price are packed three-decimal per-gallon.

HBMAR — Marina/basin master (K MARCD)

HBSZCL — Slip size-class rate table (K SZCLCD)

Seeded classes: S 250/1100/45, M 400/1800/65, L 650/2900/95. These are the standard rates a new rental picks up at signing; the agreement then carries its own locked SLRATE, so a later table change never reprices an existing renter.

HBSLIP — Slip master (K MARCD, SLIPNO)

Alternate access path HBSLPLF keys the same records by (MARCD, SSTAT, SZCLCD) for the availability inquiry without a scan.

HBBOAT — Boat/owner registry (K BOATNO)

HBSLIPAG — Slip rental agreement (K AGRNO)

HBCHG — Customer ledger / charge journal (K CHGNO)

Two alternate access paths: HBCHGLF (BOATNO, CHGNO) for the ledger subfile, and HBCHGDLF (AGRNO, CDUEDT, CHGNO) for the oldest-due-first walk aging/cash want.

HBRCPT — Cash receipts (K RCPTNO)

HBDELQ — AR aging / late-fee detail (K AGRNO)

HBFUEL — Fuel-dock inventory (K MARCD, FGRADE)

HBFSALE — Fuel sale ticket (K SALENO)

HBFUELRC — Fuel delivery/receipt (K RCPTNO)

HBWO — Service work order (K WONO)

HBGLDIST — GL distribution (SQL table, PK GLSEQ)

Relationships

• HBSLIP.MARCD → HBMAR.MARCD; HBSLIP.SZCLCD → HBSZCL.SZCLCD.
• HBSLIPAG.BOATNO → HBBOAT.BOATNO; HBSLIPAG.(MARCD,SLIPNO) → HBSLIP.
• HBCHG.AGRNO → HBSLIPAG.AGRNO (the ledger journals one row per money movement).
• HBRCPT / HBFSALE / HBWO reference an AGRNO/BOATNO; posting writes an HBCHG row and moves HBSLIPAG.RBAL.
• HBDELQ is a per-agreement aging row, upserted each aging run (keyed by AGRNO).
• HBGLDIST is the aggregate GL feed keyed by GLSEQ; HBGLPST reads HBCHG to build it.

E. Operations Runbook ↑ top

E.1 Setup & seed (first time)

1. Ensure the job's library list includes HARBOR (ADDLIBLE HARBOR).
2. CALL HARBOR/HBSETUP — deletes any prior files, then CRTPF/CRTLF the database, CRTDSPF/CRTPRTF the screens/report, RUNSQLSTM the GL table + index, and CRTBNDRPG/CRTBNDCBL every program. It ends with the "HARBOR setup complete." message.
3. CALL HARBOR/HBREFLD — seeds 2 marinas, 3 size classes, 8 slips, 5 boats, 5 rental agreements and 4 fuel-inventory rows. Confirm the DSPLY: HBREFLD MAR=2 SZCL=3 SLIP=8 BOAT=5 AGR=5 FUEL=4.

E.2 Day-in-the-life

1. Capture the day's fuel deliveries (HBFUELRC, RPOST='N'), fuel sale tickets (HBFSALE, FPOST='N'), completed work orders (HBWO, WSTAT='C', WPOST='N') and cash receipts (HBRCPT, RCSTAT='U') — captured at the dock/desk during the day.
2. Submit the daily cycle: SBMJOB CMD(CALL PGM(HARBOR/HBDAILY)).
3. Post-check each DSPLY summary line (below).
4. Handle inquiries interactively through CALL HARBOR/HBMENU (availability, ledger) as needed.
5. When a transient boat checks out, set its HBSLIPAG.RCKOUTDT and run CALL HARBOR/HBPERIOD to bill the stay.

Post-checks after the daily cycle:

• HBFUELRCV RECEIVED= equals the deliveries staged; QOH rose by exactly the delivered gallons (conservation).
• HBFUELPOST POSTED= equals the tickets staged; QOH fell by exactly the total gallons sold; each charged (A) sale wrote one 'U' ledger debit and raised its agreement balance; cash (C) sales wrote no ledger row.
• HBWOPOST POSTED= equals the completed work orders; each raised its balance by exactly WAMT.
• HBCASHAP APPLIED= equals the unapplied receipts; balances fell by exactly the amount applied; over-payment left a remainder unapplied (RCSTAT='P').

E.3 Month-end close

1. Confirm the month's daily cycles have all run (fuel, service and cash are posted).
2. Submit the monthly cycle: SBMJOB CMD(CALL PGM(HARBOR/HBMONTH)).
3. Confirm the DSPLY chain: HBRENTRL BILLED=, HBAGE CURRENT=/LATE=, HBLATEFEE CHARGED=, HBGLPST BATCH=/ROWS=, and the HBAGERPT control totals.
4. Reconcile the GL — total debits must equal total credits:

SELECT DRCR, SUM(AMT) FROM HARBOR.HBGLDIST GROUP BY DRCR;
-- and by account:
SELECT ACCT, DRCR, SUM(AMT) FROM HARBOR.HBGLDIST GROUP BY ACCT, DRCR ORDER BY ACCT;

Reconciling figures (the same ones the hb_cycle simulation checks against a hand-derived JS oracle):

• Slip-rent revenue (4100-RENT credit) = the regular monthly/seasonal charges + any backdated + the transient billing, e.g. 400+250+400+2900 + 500 + 135 = 4585.00.
• Fuel revenue (4300-FUEL) = the charged fuel sales only (cash sales bypass the ledger), e.g. 112.50.
• Service revenue (4400-SVC) = the posted work orders, e.g. 75.00.
• Late-fee revenue (4200-FEES) = 25.00 × delinquent agreements, e.g. 100.00.
• Cash (1000-CASH debit) = the payments applied, e.g. 500.00.
• AR (1200-AR) nets the billed charges (debit) against cash applied (credit); the DR and CR totals across all accounts are equal.

Aging control: HBAGERPT (COBOL) DSPLYs BILLED (sum of debit charge amounts), OPEN (sum still unpaid), CHARGES (debit row count) and STILLOPEN (count of open debits) so the receivables sub-ledger can be reconciled against the ledger.

E.4 Failure & re-run rules

Every posting batch is safely re-runnable; each DSPLYs a POSTED/BILLED/APPLIED= plus a SKIP= count, and on a clean re-run the posted count drops to 0 while everything is skipped.

F. Developer Reference ↑ top

The programs are held as JS string constants in marina-app/src/sources.mjs and loaded into library HARBOR's source physical files by src/seed.mjs (seedHarbor()), mirroring the emulator's ibmi/samples.js DEMOLIB convention. The RPG is mostly fixed-form C-specs with /free blocks; two programs (HBGLPST embedded SQL, and the interactive drivers) lean more on free-form.

F.1 Batch programs

HBREFLD (RPG) — reference seed

Output-only over 6 files; writes the marinas, size classes, slips, boats, agreements and fuel inventory, then DSPLYs the seed counts.

HBRENTRL (RPG) — monthly/seasonal rent-roll

Reads HBSLIPAG; for each active M/S agreement builds WCHGNO = 'R' + %subst(agr:4:5) + period, guards with CHAIN(EN) + IF *IN95=*OFF, then writes a 'R' charge and raises RBAL. Transient agreements are skipped.

HBTRNBILL (RPG) — transient checkout billing

For active T agreements with RCKOUTDT≠0: computes nights on the 30/360 serial (min 1), charges nights×SLRATE, sets RSTAT='T'. Guarded by a derived 'T' charge key.

HBFUELPOST (SQLRPGLE-free/RPG) — fuel sale posting

For each FPOST='N' sale: CHAIN(E) HBFUEL and relieve FQOH -= FQTY; for FPAY='A', write a 'U' ledger debit and raise RBAL; stamp FPOST='Y'. Its idempotency guard uses free-form CHAIN + %FOUND() (not a fixed-form indicator) — see F.4.

HBFUELRCV (RPG) — fuel delivery receiving

For each RPOST='N' delivery: FQOH += RQTY, replace FCOST (simple replace-cost, not weighted-average), stamp RPOST='Y'.

HBWOPOST (RPG) — work-order posting

For each complete-and-unposted work order: write an 'S' debit and raise RBAL. Work variables are prefixed WK* deliberately — see F.3.

HBCASHAP (RPG) — cash application

For each RCSTAT='U' receipt, walks the agreement's open charges oldest-due-first by scanning HBCHG, settling COPEN one charge at a time until the receipt is exhausted; reduces RBAL by the amount applied; writes a 'P' payment row keyed by a derived receipt key; stamps RCSTAT='A'/'P'.

HBAGE (RPG) — AR aging

For each active agreement, finds the oldest open charge (scan) and stamps HBDELQ.DDAYS = run-date minus due-date on the 30/360 serial. Upserts the HBDELQ row.

HBLATEFEE (RPG) — late-fee assessment

For each HBDELQ row with DDAYS>10 (grace), charges one flat 25.00 'L' fee (derived-key guarded) and raises RBAL.

HBGLPST (SQLRPGLE) — GL post

Accumulates HBCHG by CTYPE, reads the already-posted totals per account (the watermark), subtracts them, and INSERTs balanced DR/CR rows into HBGLDIST continuing GLSEQ from MAX(GLSEQ). Only a row whose insert returned SQLCOD=0 is counted.

HBAGERPT (ILE COBOL) — AR aging control report

Sequentially reads HBCHG, sums debit charge amounts and open amounts, counts charges and still-open debits; DSPLYs BILLED / OPEN / CHARGES / STILLOPEN.

F.2 Interactive programs

HBMENU (RPG) — menu driver

EXFMT HBMENU loop; option 1 CALL 'HBAVAILQ', option 2 CALL 'HBLEDGQ', anything else sets "Invalid option."; *IN03 (F3) exits.

HBAVAILQ (RPG) — slip availability inquiry

CHAIN(E) HBSZCL for the rate tiers, then READE HBSLIP by marina tallying vacant/occupied/maintenance for the keyed class; renders via %EDITC.

HBLEDGQ (RPG) — customer ledger subfile

Subfile LSFL/LCTL over HBLEDGD (SFILE(LSFL:RRN)). Clears the subfile (*IN31 → WRITE LCTL) each pass, CHAINs HBBOAT, scans HBSLIPAG for the header, then loads HBCHGLF rows by boat.

F.3 Key patterns & conventions

• Derived-key idempotency. Posting programs build the ledger charge number from stable inputs (agreement + period, or the source ticket/receipt number) so a re-run regenerates the same key and a guard CHAIN detects it already exists — e.g. 'R'+%subst(agr:4:5)+period (rent), 'L'+...+period (late fee), 'U'+%subst(sale:2:7) (fuel), 'S'+%subst(wono:2:7) (service), 'P'+%subst(rcpt:4:5)+'00' (payment).
• 30/360 serial date math. Aging and transient nights convert YYYYMMDD to a serial ((yy*12)+mm)*30+dd and subtract — a simple, deterministic day count matching the sibling storage-app.
• Posted-flag guards. FPOST/RPOST/WPOST gate the one-time inventory/ledger effect of a captured ticket, splitting capture (at the dock/desk) from posting (a separate idempotent batch step).
• Scan-vs-key honesty. Where HBCHG's own key (CHGNO) does not match the access order a routine needs, HARBOR/i scans rather than pretend a keyed read — documented in the source and mirrored from storage-app.
• WK*-prefixed work fields in HBWOPOST. HBWO's externally-described fields already include WAMT/WSTAT/WPOST; a standalone D-spec sharing one of those names would share its storage slot on this platform (a known quirk), so HBWOPOST names its work variables WKAMT/WKPOST/... to avoid aliasing the real ledger fields.

F.4 Platform finding PG-HB-001 (honest)

Finding. During the build of HARBOR/i, the fixed-form RPG CHAIN(xN) FILE key nn not-found resulting indicator was found to unreliably report FOUND for a key proven absent from the file, while the free-form %FOUND() built-in on the identical operation is reliable. The behavior is 100% reproducible in a minimal single-file repro (a freshly created UNIQUE-keyed PF with zero records: WKEY CHAIN(EN) TESTPFR nn then IF *INnn=*ON prints "FOUND" when the file is empty), yet the exact trigger could not be reduced below "a hand-written program of this shape" — the sibling storage-app's real SVCASHAP, using the identical idiom, correctly reports NOT FOUND on an empty file. Logged as Confirmed (behavior) / Suspected (exact trigger) in marina-app/FINDINGS.md; locus ibmi/rpg.js emitChain()'s indicator-assignment codegen path (the %FOUND() path is unaffected).

Where it bit HARBOR/i and the fix. In HBFUELPOST, the charged-fuel-sale idempotency guard WCHGNO CHAIN(EN) HBCHGR ... 95 reported FOUND on the first run against an empty HBCHG, so the 'U' fuel debit was silently never written and the boat's balance was never raised for the charge — while inventory relief and the "POSTED=n" counter were still correct, making the bug easy to miss. The fix, in HARBOR/i's own source (not a platform workaround that hides the finding), switched that guard to the free-form CHAIN + %FOUND() form, which is reliable in every repro. See S.HBFUELPOST, the block commented PG-HB-001.

G. Glossary ↑ top

Agreement (slip rental agreement, HBSLIPAG)

One boat-to-slip rental, carrying a billing cadence (monthly / seasonal / transient), a rate locked at signing (SLRATE) and a live ledger balance (RBAL).

Aging (AR aging)

Measuring how overdue an agreement's oldest unpaid charge is. HARBOR/i stamps days-past-due into HBDELQ.DDAYS on the 30/360 serial convention.

Charge / ledger row (HBCHG)

One debit (rent, fuel, service, late fee) or credit (payment) row. A debit is its own open item with a remaining unpaid amount (COPEN) and a status (O/P).

Conservation invariant (fuel)

Fuel on hand (FQOH) falls only via a sale and rises only via a delivery, each by exactly the ticket quantity.

Derived charge key

A ledger charge number computed from stable inputs (agreement + period, or a source ticket/receipt number) so a same-period re-run collides on the key and is refused — the idempotency guard.

Grace period

Days past due before a late fee applies. HARBOR/i uses 10 days; anything more overdue earns one flat 25.00 fee per period.

Idempotent

Safe to run again with the same result. HARBOR/i's posting batches are idempotent via posted-flags, derived keys, or (for the GL) a watermark subtraction.

Ledger invariant (balance)

An agreement balance rises only via a charge and falls only via cash application, by exactly the transaction amount.

Locked rate (SLRATE)

The rate an agreement carries from signing, independent of later changes to the standard HBSZCL rate table, so an existing renter is never silently repriced.

Oldest-due-first (open-item application)

Cash is applied to an agreement's open charges in due-date order, settling each fully before the next. A surplus stays unapplied on the receipt (RCSTAT='P').

Open item

A debit charge that still has an unpaid remainder (COPEN>0, CSTAT='O'); cash application and aging both walk open items.

SBMJOB

Submit Job — the IBM i command that queues a program to run as a batch job (e.g. SBMJOB CMD(CALL PGM(HARBOR/HBDAILY))).

Subfile

A 5250 display construct listing many rows on one screen (DDS SFL/SFLCTL). HBLEDGQ's ledger list is a subfile with roll-up/roll-down paging.

Transient

A short-stay boat billed per night at the locked day-rate, charged at checkout by HBTRNBILL, which then terminates the agreement (RSTAT='T').

Watermark (GL post)

Posting only the ledger movement since the last close by subtracting the already-posted per-account totals, so a second run never re-posts the first period's figures.

30/360 serial

A day-count convention treating every month as 30 days: a date becomes ((yy*12)+mm)*30+dd, and day counts are differences of these serials.