REALTY/i — Property Management: Leases, Rent Roll & Tenant Ledger

REALTY/i is a property-management application: a property/unit inventory, tenant and lease master, a monthly rent-roll charge run, daily cash-receipt application against the tenant ledger, a period AR ageing run with late-fee assessment, a lease-expiry sweep, an owner-distribution calculation, and a balanced GL feed with an AR control report. It is built as a classic IBM i application — RPG and ILE COBOL over keyed physical/logical files, DDS display and printer files, an SQL GL distribution table, and CL job cycles — and the money-moving programs enforce a single hard invariant: a lease's AR balance moves only by the charge run (up) and cash application (down). This manual is the reference for the operator who runs the online screens and the periodic cycles, and for the developer maintaining the application. It is grounded entirely in the committed source (property-app/src/sources.mjs, src/seed.mjs, and the test/rl_build.mjs / test/rl_cycle.mjs drivers). Everything runs in library REALTY.

A. Overview & Architecture ↑ top

A.1 What it does

REALTY/i services the full month of a small property book — two properties (Riverside Court, Oakwood Plaza), seven units, five tenants, five active leases, two owners in the seeded book:

• Property, unit, tenant & lease inventory — a property master, a composite-keyed unit master (rent/CAM standing figures, vacancy status), a tenant master, and a lease master whose LSTAT drives the lease lifecycle (new → active → expired / terminated).
• Monthly rent-roll charge run (RLCHRUN) — for every active lease, post a rent charge and a CAM charge to the tenant ledger for the period and raise the lease's AR balance by exactly the two charges' total.
• Daily cash-receipt application (RLCASHAP) — apply each unapplied receipt against the ledger charge it names, reducing the lease balance by exactly the amount applied; an over-payment applies only what is owed and the excess stays unapplied.
• Period AR ageing + late fees (RLLATE) — stamp every open charge's ageing bucket (0/1/2/3) from days overdue, then assess at most one late fee per lease whose grace period (LTERMS days) has been breached — 5% of contracted rent.
• Lease-expiry sweep (RLRENEW) — expire any active lease whose LEND has passed and vacate its unit; flag a unit whose lease is within 30 days of expiry as notice-to-vacate.
• Owner distribution (RLDISTRB) — per owner, sum the cash actually collected this period for that owner's property, deduct the management fee, and write a balanced distribution row (DISTGROSS = DISTFEE + DISTNET).
• GL post & AR control (RLGLPST / RLARRPT) — write balanced DR/CR pairs into the SQL GL distribution (DR receivable, CR rent / CAM / late-fee revenue), then print an AR control report proving the receivables sub-ledger totals reconcile.

A.2 Layered architecture: keyed-file RPG/COBOL with an SQL GL edge

The application is a conventional IBM i keyed-file design with one SQL edge:

• Data layer (DDS PF/LF). Nine physical files (property, unit, tenant, lease, ledger, receipt, owner, distribution, history) plus three logical files that provide alternate access paths, all created by RLSETUP from DDS source in REALTY/QDDSSRC. The tenant ledger (RLLEDG) is the receivables sub-ledger; the lease master (RLLEASE) carries the running AR balance LBAL.
• Business-logic layer (RPG / ILE COBOL). Each posting program is a fixed-form RPG driver that walks a master file, does the money math in packed-decimal work fields, writes ledger / history rows, and updates the lease balance — the AR invariant lives here. The AR control report (RLARRPT) is hand-written ILE COBOL over the ledger's keyed side.
• SQL edge (SQLRPGLE + SQL DDL). The GL distribution is a real SQL table (REALTY.RLGLDIST) created by RUNSQLSTM; the GL post (RLGLPST) is SQLRPGLE that reads the RPG history file with native I/O and writes the balanced GL rows with embedded EXEC SQL.
• Orchestration (CL). Three CL job cycles — RLDAILY, RLMONTH, RLPERIOD — each ADDLIBLE REALTY then CALL the programs of that cycle in order and send a completion banner.

The design deliberately mirrors the sibling order-app (ORDERIS/i): the ledger/receipt/balance model follows OEAROP/OECASH/OECUST, and the durable history file RLHIST mirrors OESHIS — one accumulating audit trail every posting program contributes to, with disjoint numeric key ranges per program derived from a stable business key, which is what makes every cycle idempotent (Section F.2).

A.3 Component & flow

  ONLINE                     BATCH CYCLES (CL-driven)
  ------                     ------------------------
  RLMENU (5250 menu)         RLDAILY  -> RLCASHAP          (cash application)
    opt 1 -> RLUNTIQ         RLMONTH  -> RLCHRUN           (rent + CAM charge run)
    opt 2 -> RLLEDIQ         RLPERIOD -> RLLATE            (ageing + late fees)
                                      -> RLRENEW           (lease-expiry sweep)
       (inquiry only)                 -> RLDISTRB          (owner distribution)
                                      -> RLGLPST           (balanced GL post)
                                      -> RLARRPT           (AR control report)
              \                    /
               \                  /
                v                v
     RLLEASE (LBAL: AR balance)  <-- raised ONLY by RLCHRUN/RLLATE, lowered ONLY by RLCASHAP
        |  \
        |   +--> RLLEDG  (one row per charge: rent 'R' / CAM 'C' / late fee 'L')
        |   +--> RLHIST  (durable audit trail; every posting program appends)
        +------> RLDIST (owner distribution)   RLGLDIST (SQL GL distribution)

A single business event — say the monthly charge run — flows: RLMONTH calls RLCHRUN → RLCHRUN reads each active lease, writes a rent and a CAM row to RLLEDG, appends charge rows to RLHIST, and adds the total to RLLEASE.LBAL. The seeded charge period is 2026-09-01 and the period-run date is 2026-09-25 (constants inside the programs; see Section C).

A.4 Object inventory

The full catalogue is 9 PFs + 3 LFs + 1 SQL table + 3 DSPF + 1 PRTF, driven by 10 RPG programs, 1 ILE COBOL program and 4 CL programs, all seeded into library REALTY by seedRealty(). Sections D and F expand each.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

REALTY/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 REALTY — the tested jobs run with LIBL = QSYS QGPL REALTY QTEMP and CURLIB = REALTY. The online surface is inquiry-only (a main menu that dispatches to two inquiry programs); every money-moving action is a batch program driven by a CL cycle.

The batch drivers take no CALL parameters. Rather than a control-row date, each posting program carries its processing date as a program constant in its source (the charge run posts for WPERDT = 20260901; the period programs run for WRUNDT = 20260925). A production reschedule for a new period is therefore a source-constant change and recompile, not a data update — an honest reflection of how this teaching application is written.

B.2 The inquiry screens (RLMENU / RLUNTIQ / RLLEDIQ)

RLMENU (DDS RLMENUD) is a plain menu: option 1 calls RLUNTIQ, option 2 calls RLLEDIQ, any other non-blank option shows Invalid option.; F3 exits.

RLUNTIQ — Unit / Lease Inquiry (plain DSPF)

A non-subfile screen. The operator keys a property and unit; the program CHAINs the unit master, then walks the unit's leases via the RLLSULF (PROPID+UNITNO) access path to find the current active lease, chains the tenant for the name, and displays the derived total monthly charge (rent + CAM) and the lease's AR balance.

RLLEDIQ — Tenant Ledger Inquiry (subfile)

The app's subfile screen (DDS RLLEDD: record LSFL under control record LCTL, SFLPAG(5) / SFLSIZ(20), ROLLUP/ROLLDOWN paging). The operator keys a lease number; the program chains the lease and tenant, then walks the lease's ledger via RLLEDG's own primary key (which starts with LEASENO), loading one subfile row per charge. The subfile is cleared and reloaded on every pass, and SFLDSP is driven from *IN31 so the list displays only once at least one row has loaded — the same subfile-refresh discipline as the sibling order-app's OEORDIQ.

B.3 Controls & audit workflow (no online maker–checker)

Honest statement: REALTY/i does not model a four-eyes maker–checker / separate-authorization workflow, and the online screens post nothing at all. There is no "one user posts, a second approves" step in the code. The control model the application does have is enforced in the batch/data layer:

• Durable audit trail (RLHIST). Every posting program appends to one accumulating history file: a rent charge (HTYPE='R'), a CAM charge ('C'), a cash application ('P', a negative amount), a late fee ('L'), and an owner distribution ('D'). Every key is unique. This is the after-the-fact accountability trail, and the cycle test asserts it carries all five types with distinct keys.
• The AR invariant. A lease's LBAL is moved only by the charge run and late-fee run (up) and cash application (down), each by exactly the charge/fee/payment amount. The tests assert this to the penny (Section F.2).
• Idempotency guards. Each posting program derives a stable history key from a business key (lease, receipt, or owner number) in a disjoint numeric range and does a CHAIN(EN) existence check before posting — so a re-run of the same period regenerates the same key and is refused. The GL post instead posts only the incremental movement since the last close.
• State gating by status. Only an LSTAT='A' (active) lease is charged or fee'd; only an RCSTAT='U' (unapplied) receipt is applied; only an OSTAT='A' owner is distributed to; an owner who collected nothing is skipped entirely (no zero row).
• Balanced by construction. Every owner distribution satisfies DISTGROSS = DISTFEE + DISTNET, and every GL post writes DR = CR exactly.

In sum, the control posture is durable audit + a strict AR balance invariant + per-run idempotency + status gating + balanced double-entry, all in the batch and data layers, rather than an online segregation-of-duties approval workflow.

C. Batch Jobs & the Periodic Cycle ↑ top

REALTY/i's servicing runs as three CL-driven cycles rather than one monolithic nightly job: a daily cycle (cash application), a monthly cycle (the rent-roll charge run), and a period cycle (ageing + late fees → lease-expiry sweep → owner distribution → GL post → AR control report). Each CL ADDLIBLE REALTY, CALLs its programs in a fixed order, and sends a completion banner. All batch programs take no CALL parameters and carry their processing date as a program constant.

-- the three cycles are bare parameterless submissions
SBMJOB CMD(CALL PGM(REALTY/RLMONTH))  JOB(RLMONTH)   rent-roll charge run
SBMJOB CMD(CALL PGM(REALTY/RLDAILY))  JOB(RLDAILY)   cash-receipt application
SBMJOB CMD(CALL PGM(REALTY/RLPERIOD)) JOB(RLPERIOD)  ageing/renewal/distribution/GL/AR

C.1 Full batch program set

C.2 Daily / monthly / period detail

Monthly — RLMONTH → RLCHRUN

For every LSTAT='A' lease, RLCHRUN posts a rent charge (CHGTYPE='R', MONTHLY RENT) and a CAM charge ('C', CAM CHARGE) to RLLEDG for period 20260901 (due 20260901), each with its own ledger sequence and its own RLHIST row, then adds LRENT + LCAM to the lease's LBAL. It finds the next ledger sequence with a SETLL/READE partial-key walk of the lease's existing charges. Idempotent: the history key is 10000000 + leaseDigits×10 + type (rent 0, CAM 1), so a same-period re-run is refused by the CHAIN(EN) guard.

Expected DSPLY (5 active leases, first run):
  RLCHRUN CHARGED= 5 SKIP= 0

AR invariant after the run (LBAL raised by rent+CAM):
  L0000001 -> 895.00   L0000002 -> 1160.00   L0000003 -> 1160.00
  L0000004 -> 2350.00  L0000005 -> 1710.00        (10 ledger rows total)

Daily — RLDAILY → RLCASHAP

RLCASHAP reads every RCSTAT='U' receipt, CHAINs the ledger charge it names by the composite key (LEASENO,RCCHGSQ), and applies only what is owed: wtake = min(RCAMT, CHGOPEN). It reduces CHGOPEN (marking the charge CHGSTAT='P' when fully applied), lowers the lease's LBAL by exactly wtake, writes a negative RLHIST 'P' row, and stamps the receipt 'A' (fully) or 'P' (part). Idempotent: history key 20000000 + receiptDigits.

Seeded receipts (RCDT 20260910): RC000001 pays L1 rent 850.00 full,
RC000002 pays L1 CAM 45.00 full, RC000003 pays 500.00 of L2 rent (1100 open).
  RLCASHAP APPLIED= 3 SKIP= 0
  L0000001 -> 0.00   (895.00 fully settled)     L0000002 -> 660.00 (1160.00 - 500.00)
  L0000002 rent charge open falls 1100.00 -> 600.00; L1 rent+CAM open 0, status P

Period — RLPERIOD → RLLATE, RLRENEW, RLDISTRB, RLGLPST, RLARRPT

Run date 20260925 throughout. Days overdue use a 30/360 date serial: ((yyyy×12 + mm)×30 + dd), so charges due 20260901 are 24 days overdue.

• RLLATE — Pass 1 ages every open charge into a bucket (0 current, 1 = 1–30, 2 = 31–60, 3 = 61+ days) and stamps CHGAGE. Pass 2 walks each active lease's own open rent/CAM charges (a late fee never triggers another) and, if any is past that lease's LTERMS-day grace, assesses one late fee of LRENT × 5% — a new 'L' ledger row plus an RLHIST 'L' row, raising LBAL. Fully settled charges (open 0) are skipped by both passes. Idempotent: history key 30000000 + leaseDigits.
• RLRENEW — For each active lease: if LEND has passed the run date, vacate the unit (USTAT='V') and expire the lease (LSTAT='X'); if within 30 days of expiry, flag an occupied unit as notice-to-vacate (USTAT='N') without touching the lease. The lease's LSTAT='X' is set only after the unit re-CHAIN, so the in-memory status is not overwritten by a disk reload.
• RLDISTRB — For each active owner, sum the cash actually collected this period (the RLHIST 'P' rows, negated, for leases on that owner's property), deduct the property's OMGMTPCT management fee, and write a balanced RLDIST row. An owner who collected nothing is skipped entirely. Idempotent: history key 40000000 + ownerDigits.
• RLGLPST (SQLRPGLE) — Accumulate the history by type, then write DR 1400-TAR (receivable) = rent + CAM + late fees, and CR 4100-RENT / 4200-CAM / 4300-LATE revenue lines, so DR = CR. Posts only the movement since the last close (it subtracts what is already debited to 1400-TAR), so a second run adds no rows.
• RLARRPT (ILE COBOL) — Read the whole ledger sequentially and print RAISED (sum CHGAMT), OPEN (sum CHGOPEN), ITEMS (row count), and OVERDUE (rows with CHGAGE > 0).

Expected period DSPLY (after the monthly + daily runs above):
  RLLATE B0= 0 B1= 8 B2= 0 B3= 0 FEES= 4     8 open charges aged, 4 late fees (L2..L5)
  RLRENEW EXPIRED= 1 NOTICE= 0 SAME= ...      L0000002 (LEND 20260831) expires; unit 0102 -> V
  RLDISTRB DIST= 1 SKIP= 1                     Riverside distributes; Oakwood collected nothing
  RLGLPST BATCH=202609 ROWS= 4                 DR receivable + 3 CR revenue lines
  RLARRPT ITEMS 00014                          10 charges + 4 late fees

C.3 Ordering & dependencies

• MONTHLY (charge run) before DAILY (cash) before PERIOD. Cash can only be applied to charges that exist, and late fees / ageing / distribution / GL all read the resulting ledger and history, so the natural sequence for a period is: run the month's charge run, apply the month's cash, then close the period.
• Within RLPERIOD the CL fixes the order: RLLATE (age + fee) → RLRENEW (expiry) → RLDISTRB (distribution) → RLGLPST (GL) → RLARRPT (report). Late fees must exist before the GL post totals the late-fee revenue and before the AR report counts them; distribution reads the collected-cash history that daily cash application produced.
• Every cycle is re-runnable. Each program's idempotency guard (or, for the GL, its incremental post) means a whole-cycle re-submission changes nothing — the cycle test re-runs each program and asserts no double-charge, double-apply, double-fee, double-expire, double-distribute or double-post.

D. Data Files (data dictionary) ↑ top

All files are in library REALTY, grounded in the DDS members in sources.mjs. Dates are stored as signed integers in YYYYMMDD form (8S 0); money is packed decimal 11P 2; percentages (fees) are packed 5P 2. Key fields are noted per file.

RLPROP — Property master (key PROPID)

RLUNIT — Unit master (composite key PROPID, UNITNO)

RLTEN — Tenant master (key TENNO)

RLLEASE — Lease master (key LEASENO)

RLLEDG — Tenant AR open-item ledger (composite key LEASENO, CHGSEQ)

RLRCPT — Cash receipts (key RCPTNO)

RLOWN — Owner master (key OWNID)

RLDIST — Owner-distribution history (composite key OWNID, DISTSEQ)

RLHIST — Durable audit trail (key HSEQ)

RLGLDIST — SQL GL distribution (PK GLSEQ)

Logical files (alternate access paths)

Relationships

• RLUNIT.PROPID → RLPROP.PROPID; RLLEASE ties a PROPID+UNITNO (RLUNIT) to a TENNO (RLTEN).
• RLLEDG.LEASENO → RLLEASE.LEASENO (the lease's open-item ledger; charges keyed by CHGSEQ).
• RLRCPT names a specific (LEASENO, RCCHGSQ) ledger charge to apply against.
• RLOWN.PROPID → RLPROP.PROPID; RLDIST is the owner's distribution history keyed by DISTSEQ.
• RLHIST is the aggregate audit trail (every posting program appends); RLGLDIST is the SQL GL feed.

E. Operations Runbook ↑ top

E.1 Day-in-the-life

One-time (or on a rebuild): compile and stand up the application, then seed the reference book.

1. Confirm the job's library list includes REALTY (LIBL = QSYS QGPL REALTY QTEMP, CURLIB = REALTY).
2. Build every object & program: CALL REALTY/RLSETUP — expect the REALTY setup complete. banner.
3. Seed reference data: CALL REALTY/RLREFLD — expect RLREFLD PROP=2 UNIT=7 TEN=5 LEASE=5 OWN=2.

Then, for a normal period:

1. Charge run (start of month): SBMJOB CMD(CALL PGM(REALTY/RLMONTH)). Check the RLCHRUN CHARGED=n SKIP=n line and confirm each active lease's LBAL rose by exactly its rent + CAM.
2. Cash application (daily): post receipts to RLRCPT as RCSTAT='U', then SBMJOB CMD(CALL PGM(REALTY/RLDAILY)). Check RLCASHAP APPLIED=n SKIP=n and confirm each paid lease's LBAL fell by exactly the applied amount.
3. Inquiry as needed: CALL REALTY/RLMENU → option 1 (unit/lease) or 2 (ledger) to look up a unit's lease or a lease's open items.

Post-checks after cash application:

• APPLIED= equals the number of U receipts; SKIP= counts already-applied receipts and any whose named charge was not found.
• A fully-paid charge shows CHGOPEN=0, CHGSTAT='P'; its receipt is RCSTAT='A'.
• An over-payment applied only what was owed; the excess left the receipt RCSTAT='P'.
• Every applied receipt produced one negative-amount RLHIST 'P' row.

E.2 Period-end close

1. Confirm the month's charge run and all cash application have completed.
2. Submit the period cycle: SBMJOB CMD(CALL PGM(REALTY/RLPERIOD)). It runs, in order, RLLATE → RLRENEW → RLDISTRB → RLGLPST → RLARRPT, then sends the period-end banner.
3. Review the GL distribution and the AR control report.

SELECT ACCT, DRCR, SUM(AMT) FROM REALTY.RLGLDIST GROUP BY ACCT, DRCR;
-- proves DR total = CR total
SELECT SUM(CASE WHEN DRCR='D' THEN AMT END) AS DR,
       SUM(CASE WHEN DRCR='C' THEN AMT END) AS CR FROM REALTY.RLGLDIST;

Reconciling figures (the same ones the cycle battle verifies against a hand-derived JS oracle, for the seeded book after the September charge run + the three seeded receipts):

• Late fees — one per lease past grace at 24 days overdue: L2 55.00, L3 55.00, L4 110.00, L5 80.00 (each LRENT×5%). L1, settled before close, earns none. Ageing puts all 8 remaining open charges in bucket 1.
• Lease balances after RLLATE — L2 715.00, L3 1215.00, L4 2460.00, L5 1790.00; L1 0.00.
• Lease-expiry sweep — L0000002 (LEND 20260831, past) expires (LSTAT='X') and its unit P00001/0102 flips to vacant.
• Owner distribution — Riverside (O00001, 10% fee) collected 895.00 + 500.00 = 1395.00; fee 139.50; net 1255.50 (DISTGROSS = DISTFEE + DISTNET). Oakwood (O00002) collected nothing and is skipped (no row).
• GL post — DR 1400-TAR = rent 6850.00 + CAM 425.00 + late fees 300.00 = 7575.00; CR 4100-RENT 6850.00, 4200-CAM 425.00, 4300-LATE 300.00 — DR = CR exactly.
• AR control — RLARRPT ITEMS 00014 (10 rent/CAM charges + 4 late fees), with RAISED and OPEN totals over the whole ledger.

E.3 Failure & re-run rules

Each program DSPLYs a one-line result. A cycle can be re-submitted whole; the idempotency guards make every posting a no-op the second time.

F. Developer Reference ↑ top

The complete program surface, from property-app/src/sources.mjs. All objects are in library REALTY. The fixed-form RPG is generated with two column-exact helpers in sources.mjs (C() for C-specs, D() for D-specs), mirroring the ibmi/samples.js convention.

F.1 Programs

RLREFLD (RPGLE) — reference-data seed

Writes 2 properties, 7 units, 5 tenants, 5 active leases (all LBAL=0), 2 owners, then DSPLYs the seed counts. The one-time source of the seeded book every test and figure in this manual is grounded in.

RLCHRUN (RPGLE) — monthly rent-roll charge run

Reads RLLEASE (SETLL *LOVAL / READ); per active lease, finds the next CHGSEQ by a partial-key SETLL/READE walk, writes a rent and a CAM RLLEDG row and their RLHIST rows, then re-CHAINs the lease and adds WRENT+WCAM to LBAL. Idempotency guard on history key 10000000 + wdig×10 + type.

RLCASHAP (RPGLE) — daily cash-receipt application

Reads RLRCPT; for each U receipt CHAINs the named (LEASENO,CHGSEQ) ledger charge via a KLIST, applies min(RCAMT, CHGOPEN), updates the charge and receipt status, lowers LBAL, writes a negative RLHIST 'P' row. Guard on 20000000 + receiptDigits.

RLLATE (RPGLE) — period ageing + late fee

Pass 1: sequentially age every open charge (30/360 days overdue → bucket 0/1/2/3), update CHGAGE. Pass 2: per active lease, walk its open rent/CAM charges; if any exceeds the lease's LTERMS grace, write one L charge of LRENT×5%, an RLHIST 'L' row, and raise LBAL. Guard on 30000000 + leaseDigits.

RLRENEW (RPGLE) — period lease-expiry sweep

Per active lease: if LEND < run date, vacate the unit (via a PROPID+UNITNO KLIST CHAIN) and, after re-CHAINing the lease, set LSTAT='X'; if within 30 days of expiry, flag an occupied unit USTAT='N'. Counts EXPIRED / NOTICE / SAME.

RLDISTRB (RPGLE) — period owner distribution

Per active owner: sum the negated RLHIST 'P' rows whose lease belongs to the owner's property (cash actually collected), deduct OMGMTPCT, write a balanced RLDIST row (DISTGROSS = DISTFEE + DISTNET) and an RLHIST 'D' row. An owner with zero collected is skipped. Guard on 40000000 + ownerDigits.

RLGLPST (SQLRPGLE) — period GL post

Accumulates RLHIST by type (R/C/L), reads the current 1400-TAR debit total via EXEC SQL, and posts only the incremental movement: DR 1400-TAR, CR 4100-RENT/4200-CAM/4300-LATE, each via EXEC SQL INSERT into REALTY.RLGLDIST. A refused insert is not counted as a posted row.

RLRENEW / RLUNTIQ / RLLEDIQ / RLMENU (RPGLE)

The two inquiry drivers and the menu (Section B). RLLEDIQ is the subfile program; RLUNTIQ uses the RLLSULF access path to find a unit's active lease.

RLARRPT (ILE COBOL) — AR control report

Sequential READ of RLLEDG accumulating RAISED (LG-AMT), OPEN (LG-OPEN), item count, and overdue count (LG-AGE > 0); proves the receivables sub-ledger totals reconcile.

RLSETUP / RLDAILY / RLMONTH / RLPERIOD (CL)

RLSETUP DLTFs then CRTPF/CRTLF/CRTDSPF/CRTPRTF/RUNSQLSTM/CRTBNDRPG/CRTBNDCBL every member. The three cycle CLs ADDLIBLE REALTY and CALL the cycle's programs in order.

F.2 The AR invariant & idempotency

Two properties define the application's correctness and are asserted to the penny by test/rl_cycle.mjs:

• AR balance invariant. RLLEASE.LBAL starts at 0 and moves only by: + (rent + CAM) in RLCHRUN, + late fee in RLLATE, and − amount applied in RLCASHAP. Nothing else touches it. The test drives a full charge/cash/late-fee cycle and checks each lease's balance equals the hand-derived figure (e.g. L0000002: 0 → 1160.00 → 660.00 → 715.00).
• Idempotency by stable-key existence check. Every posting program derives a RLHIST key from a stable business key in a program-disjoint numeric range and does a CHAIN(EN) (existence-only) read before posting. A re-run regenerates the same key, the CHAIN finds it, and the post is refused. The GL post is idempotent differently — it posts only the movement since the last close, so a second run adds nothing.

F.3 Access paths & file discipline

The three logical files are genuine alternate orderings, not decoration — the build test asserts each LF's leading key differs from its PF's:

• RLUNTLF (PROPID) lets the rent-roll read a whole property's units with a partial key.
• RLLSULF (PROPID, UNITNO) lets RLUNTIQ find a unit's current lease directly.
• RLLEDLF (CHGDUE, LEASENO) lets an ageing report walk oldest-due-first without sorting.

F.4 Date-serial & embedded-SQL patterns

• 30/360 date serial. Days between two YYYYMMDD integers are computed by collapsing each to ((yyyy×12 + mm)×30 + dd) and subtracting — the same convention as the order-app's OEAGE. RLLATE and RLRENEW both use it (run date 20260925 → charges due 20260901 are 24 days overdue).
• Native I/O + embedded SQL in RLGLPST. The GL post reads the RPG RLHIST file with native READ, then uses EXEC SQL SELECT ... INTO to read the current GL debit total and EXEC SQL INSERT to write GL rows — the one program that spans both the keyed-file and SQL worlds. It checks SQLCOD and does not count a refused insert.
• KLIST composite keys. Composite-key CHAINs (ledger LEASENO+CHGSEQ, unit PROPID+UNITNO) are built with KLIST/KFLD in the C-specs.

G. Glossary ↑ top

AR (accounts receivable) balance — LBAL

The running amount a lease owes, on RLLEASE.LBAL. Raised only by the charge run and late fees, lowered only by cash application — the invariant the tests assert.

Ageing bucket — CHGAGE

A classification of how overdue an open charge is at the run date: 0 current, 1 = 1–30, 2 = 31–60, 3 = 61+ days, stamped by RLLATE on the 30/360 convention.

CAM — Common Area Maintenance

A recurring charge (alongside rent) for shared-space upkeep. Posted as a separate ledger row (CHGTYPE='C') with its own revenue account 4200-CAM.

Charge run / rent roll

The monthly posting of every active lease's rent and CAM to the tenant ledger (RLCHRUN), raising each lease's AR balance.

Grace period — LTERMS

The number of days past a charge's due date before a late fee applies. Per lease (10, 15 or 5 days in the seeded book).

Idempotent

Safe to run again with the same result. Each posting program's stable history key + CHAIN(EN) guard (and the GL post's incremental logic) makes every cycle re-runnable.

Late fee

A charge assessed once per lease whose grace period is breached, at 5% of contracted rent (CHGTYPE='L', revenue 4300-LATE).

Lease-expiry sweep

The period pass (RLRENEW) that expires any active lease past its LEND and vacates its unit, and flags near-expiry units notice-to-vacate.

Management fee — OMGMTPCT

The percentage a property charges its owner, deducted from collected cash before the owner's distribution (DISTFEE).

Open item

A ledger charge with a non-zero outstanding balance (CHGOPEN > 0). Cash application reduces it; a fully-applied item is skipped by ageing and late fees.

Owner distribution

The period calculation (RLDISTRB) of what to pay each owner: cash collected less management fee, as a balanced RLDIST row (DISTGROSS = DISTFEE + DISTNET).

SBMJOB

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

Subfile

A 5250 display construct listing many rows on one screen (DDS SFL/SFLCTL). RLLEDIQ's ledger list is a subfile with 5-per-page paging.

Tenant ledger — RLLEDG

The receivables sub-ledger: one open-item row per charge (rent, CAM, late fee), reduced as cash is applied.