ESTATE/i — Fixed Assets & Depreciation

ESTATE/i is a fixed-asset accounting application: acquisition and capitalisation, three depreciation methods (straight-line, declining-balance, units-of-production) posted monthly with a GL distribution, asset transfer between cost centres, disposal with gain/loss, weekly maintenance and warranty sweeps, and a year-end register with a fully-depreciated retirement roll. The business logic is classic RPG IV over keyed DDS physical/logical files, with one ILE COBOL summary program and one SQLRPGLE program that posts the GL distribution to a DB2 for i table; the four periodic cycles are driven by CL. This manual is the reference for the operator who runs the periodic cycles and the online inquiry screens, and for the developer maintaining the application. It is grounded entirely in the committed source (assets-app/src/sources.mjs, src/seed.mjs, and the test/fa_*.mjs drivers), which loads library ESTATE.

A. Overview & Architecture ↑ top

A.1 What it does

ESTATE/i accounts for the full life of a fixed asset:

• Acquisition & capitalisation — take an asset sitting at ASTAT='P' (pending), stamp its in-service date from the acquisition date, set NBV = cost, move it to 'A' (in service), and post a capitalisation row to the asset ledger.
• Monthly depreciation — compute and post one period's charge for every in-service asset by its method (straight-line S, declining-balance D, units-of-production U), write a depreciation-history row, roll the master's accumulated depreciation and net book value, then distribute the charge to the general ledger.
• Transfer — move an asset from one cost centre to another (a reclassification, not a value event: cost/accumulated/NBV are untouched), posting a transfer ledger row.
• Disposal — snap the asset's cost and accumulated depreciation, compute NBV = cost−accumulated and gain/loss = proceeds−NBV, flip the asset to 'D' (disposed), and post a signed gain/loss ledger row.
• Maintenance & warranty — a weekly sweep flags maintenance schedules that are due and reports assets whose warranty has expired.
• Year-end — retire fully-depreciated assets to 'F', re-roll every asset's NBV under the invariant, generate the year's asset register and print it.

A.2 Architecture & the ledger discipline

The application is classic IBM i: RPG IV programs orchestrate keyed DDS files, one ILE COBOL program produces an independent depreciation summary, one SQLRPGLE program posts the GL distribution with embedded SQL, and CL ties the objects together into a setup job and four periodic cycles. Everything lives in library ESTATE.

• The asset master (FAASSET) is the spine. Every program reads or updates it; the depreciation policy defaults come from the class master (FACLASS), and the same assets are reachable by cost centre through the alternate access path FAASTLF.
• One accumulating audit ledger (FALEDG). Capitalisation, transfer, disposal, depreciation and retirement each contribute rows to a single durable ledger. Every posting program carves a disjoint LSEQ range and derives each key from a stable business key, so a re-run regenerates the same key and is refused rather than double-posting (see F.2).
• Depreciation history (FADEPH) is period-keyed. The composite (ASTNO, DPER) key both accumulates history across months and is the guard that makes a same-period re-run a no-op — the single most important control in the app (see F.2).
• Depreciation math never exceeds the depreciable base. For every method and every period, the charge is clamped so accumulated depreciation can never pass COST - SALVAGE and NBV can never go negative (see F.1).

There is no CICS, no transaction-id switch and no single monolithic nightly job: work is organised as a daily, a weekly, a monthly and an annual CL cycle, each calling a small set of RPG/COBOL programs in a fixed order.

A.3 Component & flow

  ONLINE (5250)          DAILY  FADAILY        MONTHLY  FAMONTH
  ------------           --------------        ---------------
  FAMENU                 FAACQ    (capitalise) FADEPRUN (depreciate, 3 methods)
   opt 1 -> FAASTIQ      FAXFRUN  (transfer)   FAGLPST  (GL distribution, SQL)
   opt 2 -> FADEPIQ      FADISPOS (dispose)    FADEPSUM (COBOL proof summary)

  WEEKLY  FAWEEK         ANNUAL  FAYEAR
  -------------          --------------
  FAMTSWP (maint due)    FARETIRE (retire fully-depreciated)
  FAWARN  (warranty)     FANBVRL  (NBV roll, invariant)
  FACCRPT (cctr summary) FAREGEN  (register snapshot) -> FAREGPR (print)

                    +-- reads policy --  FACLASS
                    |
   FAASSET  <--------- every program --  (master; keyed also by cctr via FAASTLF)
     |  \
     |   +--> FADEPH  (per-asset-per-period history; -> FAGLDIST via FAGLPST)
     |   +--> FALEDG  (C capitalise / X transfer / S sale / P depn / F retire)
     +------> FAREG   (year-end register snapshot)   FADEPPER (data area: period)

A depreciation event flows: operator sets the period in data area FADEPPER → submits FAMONTH → FADEPRUN reads the period, walks every in-service asset, computes the charge by method, writes a FADEPH row and rolls the master → FAGLPST reads the period through the period-keyed logical and writes balanced DR/CR rows to FAGLDIST → FADEPSUM (COBOL) independently totals the period by method as a proof.

A.4 Object inventory

The catalogue is 11 DDS files (9 PF + 2 LF) + 1 SQL table + 1 data area, 3 display files and 1 printer file, driven by 16 RPG programs, 1 COBOL program and 5 CL programs. Sections D and F expand each.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

ESTATE/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 ESTATE — the tested jobs run with LIBL = QSYS QGPL ESTATE QTEMP and CURLIB = ESTATE.

The batch programs take no CALL parameters. The daily, weekly and annual programs read the run date they need from constants compiled into the source (see the note in C.2); the monthly depreciation and GL programs read the processing period from the FADEPPER data area (default ' 202608'), so a scheduled submission sets that data area, then simply calls the cycle. Only FAMENU, FAASTIQ and FADEPIQ are interactive.

B.2 The menu & the two inquiry screens

Honest statement: the online surface is read-only inquiry plus a menu. There is no maintenance screen: an operator cannot capitalise, transfer, dispose, depreciate or edit an asset from 5250. Those are all batch actions (section C). The three interactive programs are:

FAMENU / FAMENUD — the operator menu

FAMENU presents a two-option menu and routes to the inquiries by a program-to-program CALL: option 1 calls FAASTIQ, option 2 calls FADEPIQ, any other non-blank option shows Invalid option. on the menu itself. F3 ends the program.

FAASTIQ / FAASTD — asset inquiry (plain screen)

A non-subfile screen: key an asset number in IAST and press Enter; the program CHAINs FAASSET and renders the master record with the net book value derived on screen as COST - ACCDEP (work field WN, edited with %editc(...:'K')). An unknown key shows Asset not found. and blanks every value rather than leaving the previous asset's figures stale.

FADEPIQ / FADEPD — depreciation-history inquiry (subfile)

A subfile screen (DDS record DSFL under control record DCTL, SFLPAG(0005) per page, SFLSIZ(0020)): key an asset, and the program loads that asset's period charges from FADEPH (via a keyed READE group) into the subfile, showing period, method, charge, running accumulated and running NBV. It uses a classic load-then-display discipline: it writes SFLCLR (indicator 31) to wipe the previous enquiry, resets the relative record number, then re-loads the rows for the asset actually asked for before the next EXFMT. Roll Up/Roll Down page a longer history (an asset with 6 periods shows 5 on page one, the 6th on Roll Up).

B.3 Controls & audit workflow (no four-eyes maker–checker)

Honest statement: ESTATE/i does not model a four-eyes maker–checker / separate-authorization workflow, and it has no online data-entry at all. A capitalisation, transfer, disposal or depreciation posting is actioned by its batch program the next time the cycle runs; there is no "one user requests, a second user approves" gate in the code. The control model the application does have is:

• Request status gating. Transfers and disposals are driven off request rows: only FAXFER.XSTAT='R' (requested) rows transfer and only FADISP.DSTAT='R' rows dispose; an actioned request flips to 'C' (complete) so it is never re-actioned. A transfer to a non-existent or closed cost centre is refused and the request stays open.
• State gating. Only ASTAT='P' assets capitalise; only 'A' assets depreciate, are swept for maintenance, or retire; a disposed 'D' asset is skipped by the register and re-disposal.
• The accumulating ledger (FALEDG). Every capitalisation (C), transfer (X), disposal (S), depreciation (P) and retirement (F) posts a ledger row with the amount, a reference and a memo, giving a complete, reconstructable, uniquely-keyed audit trail across all four cycles.
• Idempotency guards. Every posting key is derived from a stable business key on a disjoint LSEQ range (see F.2), so a re-run posts nothing rather than double-posting — the property the fa_* suites assert repeatedly.
• The depreciable-base invariant. Accumulated depreciation can never exceed COST - SALVAGE and NBV can never go negative, enforced in the calculation and re-asserted by the annual NBV roll (see F.1).

In sum the control posture is request/state gating + a durable ledger + idempotency + the depreciable-base invariant, all in the batch/data layer, rather than an online segregation-of-duties workflow.

C. Batch Jobs & the Periodic Cycle ↑ top

ESTATE/i runs as four CL cycles rather than one monolithic nightly job: a daily cycle (acquisition, transfer, disposal), a weekly cycle (maintenance sweep, warranty report, cost-centre summary), a monthly cycle (depreciation, GL distribution, COBOL summary) and an annual cycle (retirement, NBV roll, register generate + print). Each cycle is a CL program that ADDLIBLEs ESTATE, CALLs its programs in a fixed order and sends a completion banner.

-- the monthly cycle takes its period from a data area; set it, then submit
CHGDTAARA DTAARA(ESTATE/FADEPPER) VALUE('    202608')
SBMJOB CMD(CALL PGM(ESTATE/FAMONTH)) JOB(FAMONTH)

-- the other cycles are parameterless
SBMJOB CMD(CALL PGM(ESTATE/FADAILY)) JOB(FADAILY)

C.1 Full batch program set

C.2 Daily / weekly / monthly / annual detail

Daily — FADAILY (FAACQ → FAXFRUN → FADISPOS)

FAACQ reads the master sequentially; each asset at ASTAT='P' is capitalised: derive the stable ledger key 10000000 + %dec(%subst(astno:3:6):8:0), refuse (skip) if that ledger row already exists, otherwise CHAIN the class for policy, write the FALEDG 'C' row, re-CHAIN the asset, stamp INSVDT=ACQDT, set NBV=COST-ACCDEP, move to 'A'. FAXFRUN walks FAXFER; for a 'R' request whose destination cost centre exists and is open (CCSTAT='A'), it moves the asset's CCTR, writes a FALEDG 'X' row keyed 20000000 + XSEQ, and flips the request to 'C' (a transfer carries NBV as information only — cost/accum/NBV do not change). FADISPOS walks FADISP; for a 'R' request it snaps cost and accumulated, computes NBV = cost−accum and gain/loss = proceeds−NBV, zeroes the asset's NBV, moves it to 'D', writes a signed FALEDG 'S' row (memo GAIN or LOSS) keyed 30000000 + asset digits, and closes the request.

Expected DSPLY (7 seeded pending assets, 1 valid + 1 bad transfer, 2 disposals):
  FAACQ CAPITALISED=  7 SKIP=  0        capitalised value totals 247200.00
  FAXFRUN TRANSFERRED=  1 SKIP=  1      CC99 destination refused
  FADISPOS DISPOSED=  2 SKIP=  0        gain +2000.00, loss -3500.00

Weekly — FAWEEK (FAMTSWP → FAWARN → FACCRPT)

FAMTSWP flags every MSTAT='S' schedule whose NEXTDT falls on or before the sweep date (compiled constant WRUNDT = 20260815) whose asset is still in service, setting it 'D' and accumulating its MCOST. FAWARN counts and names schedules whose WARRDT has passed the run date. FACCRPT reads each cost centre's assets through the CCTR-keyed logical FAASTLF (a genuine alternate access path — a keyed READE group, not a full-master scan per centre) and summarises count / cost / NBV.

Expected DSPLY (sweep 20260815, all 7 assets in service):
  FAMTSWP DUE=  2 SKIP=  2 COST=  1070.00   750.00 + 320.00
  FAWARN EXPIRED=  1 INWARR=  3             AS100002 out of warranty
  FACCRPT CC10 N=  4 COST= 123200.00 ...    CC20 N=1, CC30 N=2
  FACCRPT CENTRES DONE ASSETS=  7

Monthly — FAMONTH (FADEPRUN → FAGLPST → FADEPSUM)

FADEPRUN reads the period from data area FADEPPER (falling back to 202608 if the data area is blank/invalid), then for every ASTAT='A' asset with depreciable base remaining computes the charge by method (F.1), clamps it to the remaining base, and — guarded by the composite (ASTNO, DPER) key so a same-period re-run posts nothing — writes a FADEPH row and rolls the master's ACCDEP, NBV and LSTPER. FAGLPST reads the whole period through the period-keyed logical FADEPLF, and for each charge writes a balanced pair to FAGLDIST: DR 7100-DEPN (expense) and CR 1590-ADEP (accumulated depreciation), tagged with the asset's cost centre; it is idempotent — if the period already has distribution rows it reports ALREADY POSTED and adds nothing. FADEPSUM (COBOL) independently totals the period's history by method as a cross-check.

Expected DSPLY (period 202608, 7 in-service assets):
  FADEPRUN PER=202608 POSTED=  7 SKIP=  0   period total 8450.00
  FAGLPST PER=202608 ROWS= 14 TOTAL= 8450.00  2 rows/asset, DR=CR=8450.00
  FADEPSUM STRAIGHT      2250.00   900 + 750 + 600
  FADEPSUM DECLINE       1600.00   1000 + 600
  FADEPSUM UNITS         4600.00   3600 + 1000
  FADEPSUM TOTAL         8450.00

Annual — FAYEAR (FARETIRE → FANBVRL → FAREGEN → FAREGPR)

FARETIRE retires any in-service asset whose ACCDEP has reached its depreciable base (COST-SALVAG) to 'F' and posts a FALEDG 'F' row keyed 60000000 + asset digits. FANBVRL re-computes NBV = COST - ACCDEP for every asset, clamping accumulated to the base and NBV to non-negative (disposed assets carry NBV 0), reporting how many it had to clamp. FAREGEN writes one FAREG snapshot row per non-disposed asset for the register year (compiled constant WYR = 2026), composite-keyed (RYEAR, ASTNO) so a re-run is refused. FAREGPR prints the register through FAREGP with page overflow.

Expected DSPLY (after the three depreciation periods in the cycles suite):
  FARETIRE RETIRED=  1 SKIP=  6        the fully-depreciated jig AS400001
  FANBVRL ASSETS=  7 NBV=... CLAMPED=  0
  FAREGEN YEAR=2026 LINES=  7 NBV=... SKIP=  0
  FAREGPR LINES=  7 NBV=...

C.3 Ordering & dependencies

• Setup first. FASETUP creates every object and compiles every program; FAREFLD loads reference data and the seven pending assets. FAACQ (daily) capitalises them before anything can depreciate.
• Within the monthly cycle the order is fixed: FADEPRUN posts the history and rolls the master, then FAGLPST distributes that history to the GL, then FADEPSUM proves the totals. GL distribution must follow depreciation or it finds nothing for the period.
• Set FADEPPER before FAMONTH. The period is read from the data area; advance it each month (and set USEUNIT on any units-of-production asset before the run — the depreciation program consumes the units used in the period).
• Within the annual cycle retirement and the NBV roll precede register generation so the snapshot reflects retirements and clamped NBVs; the print follows generation.
• Within the daily cycle, capitalise, transfer, dispose — a valid order for the request-driven events; each is independent and re-runnable.

D. Data Files (data dictionary) ↑ top

All files are in library ESTATE, grounded in src/sources.mjs. Dates are stored as signed numeric in YYYYMMDD form (periods as YYYYMM); money is packed 11P2; rates are packed 7P4 (0.2000 = 20% a year, or a per-unit amount for units-of-production). NBV is always COST - ACCDEP — derived, but also carried on the master so the register prints without recomputation.

FAASSET — Asset master (key ASTNO)

Seeded (all pending 'P'): AS100001 PLANT 60000/6000/60m/S; AS100002 VEHICLE 40000/4000/48m/S; AS200001 IT 60000/rate .2000/D; AS200002 SERVER 24000/rate .3000/D; AS300001 PRESS 50000/5000/rate .4500/unit/U; AS300002 MOULD 12000/rate .2000/unit/U; AS400001 FIXTURE 1200/0/2m/S (retires fast).

FAASTLF — Asset master by cost centre (LF over FAASSET; key CCTR, ASTNO)

Non-unique alternate access path so the cost-centre register (FACCRPT) and transfer audit are keyed READE reads rather than a full-master scan. A cost centre holds many assets.

FACLASS — Asset-class master (key CLSCD)

Seeded: PLNT (S/60/7100-DEPN), VEHC (S/48/7110-DEPN), ITEQ (D/36/.2000/7120-DEPN), TOOL (U/0/.4500/7130-DEPN).

FACCTR — Cost-centre master (key CCNO)

Seeded: CC10 MAIN FACTORY, CC20 DISTRIBUTION DEPOT, CC30 HEAD OFFICE (all open).

FADEPH — Depreciation history (composite key ASTNO, DPER)

FADEPLF — Depreciation history by period (LF over FADEPH; key DPER, ASTNO)

Alternate access path so the monthly GL distribution (FAGLPST) reads a whole period with one keyed READE group rather than scanning every asset's whole history.

FAXFER — Transfer request log (key XSEQ)

FADISP — Disposal request log (key ASTNO)

FAMAINT — Maintenance schedule (composite key ASTNO, MSEQ)

FALEDG — Durable asset ledger (key LSEQ)

LSEQ ranges: capitalise 10000000+digits, transfer 20000000+XSEQ, disposal 30000000+digits, depreciation 40000000+digits (per-period guard is the FADEPH composite key), retirement 60000000+digits.

FAREG — Year-end register snapshot (composite key RYEAR, ASTNO)

FAGLDIST — GL distribution (SQL table, key GLSEQ)

FADEPPER — Depreciation-period data area (*DTAARA CHAR(10))

Holds the processing period the monthly programs read, created by FASETUP with value ' 202608'. Advance it before each monthly run with CHGDTAARA DTAARA(ESTATE/FADEPPER) VALUE(' YYYYMM'); a blank/invalid value falls back to 202608 in the programs.

Relationships

• FAASSET.ACLASS → FACLASS.CLSCD (policy + GL accounts); FAASSET.CCTR → FACCTR.CCNO.
• FAASTLF is FAASSET keyed by cost centre; FADEPLF is FADEPH keyed by period.
• FADEPH.ASTNO → FAASSET; FADEPH feeds FAGLDIST via FAGLPST.
• FAXFER / FADISP / FAMAINT are per-asset request/schedule logs; FALEDG and FAREG are accumulating logs.
• FADEPPER is the standalone period control the monthly cycle reads.

E. Operations Runbook ↑ top

E.1 Day-in-the-life

1. One-time / on rebuild: CALL ESTATE/FASETUP (creates objects, compiles programs), then CALL ESTATE/FAREFLD (loads classes, cost centres, pending assets, maintenance).
2. Submit the daily cycle: SBMJOB CMD(CALL PGM(ESTATE/FADAILY)) — capitalises any new pending asset, actions transfer and disposal requests.
3. Post-check the daily run (below).
4. Handle enquiries interactively through CALL ESTATE/FAMENU (option 1 asset inquiry, option 2 depreciation history).
5. On the weekly day, submit FAWEEK and review the maintenance-due, warranty and cost-centre lines.

Pre-checks: confirm the job's library list includes ESTATE; for transfers/disposals, confirm the request rows are seeded at status 'R'.

Post-checks after the daily cycle:

• FAACQ CAPITALISED= equals the pending assets; each is now 'A' with INSVDT=ACQDT and NBV=COST; one FALEDG 'C' row each.
• FAXFRUN TRANSFERRED= equals the valid 'R' requests; refused ones stay 'R' (bad/closed destination) and the asset is unmoved.
• FADISPOS DISPOSED= equals the 'R' disposals; each asset is now 'D' with NBV 0 and a signed FALEDG 'S' row (GAIN/LOSS memo).
• Every FALEDG key is unique across the three daily programs (the disjoint-range guarantee).

E.2 Depreciation run & month-end

1. Set the units used this period on any units-of-production asset (e.g. update USEUNIT on AS300001/AS300002); a unit asset that ran 0 units charges nothing that month.
2. Set the period: CHGDTAARA DTAARA(ESTATE/FADEPPER) VALUE(' YYYYMM').
3. Submit FAMONTH. Confirm FADEPRUN PER=YYYYMM POSTED=n, FAGLPST PER=YYYYMM ROWS=2n TOTAL=, and the four FADEPSUM lines.
4. Reconcile the period (below), then advance to the next month.

Reconciling figures (the same ones the cycles suite checks against a hand-derived oracle, period 202608):

• Straight-line = (COST−SALVAGE)/LIFEMT: AS100001 (60000−6000)/60 = 900.00; AS100002 (40000−4000)/48 = 750.00; AS400001 1200/2 = 600.00.
• Declining-balance = (COST−ACCDEP)×DRATE/12: AS200001 60000×0.20/12 = 1000.00; AS200002 24000×0.30/12 = 600.00. Month 2 reduces: AS200001 (60000−1000)×0.20/12 = 983.33.
• Units-of-production = USEUNIT×DRATE: AS300001 8000×0.45 = 3600.00; AS300002 5000×0.20 = 1000.00.
• Period total = 900 + 750 + 1000 + 600 + 3600 + 1000 + 600 = 8450.00.
• GL balance — the period posts DR 7100-DEPN 8450.00 = CR 1590-ADEP 8450.00 (14 rows, 2 per asset); by cost centre CC10 = 900 + 3600 + 1000 + 600 = 6100.00.

Ad-hoc GL review:

SELECT ACCT, DRCR, SUM(AMT) FROM ESTATE.FAGLDIST
  WHERE GLPER = 202608 GROUP BY ACCT, DRCR ORDER BY ACCT;

E.3 Year-end & reconciling the register

1. Confirm every month's FAMONTH has run for the year (FADEPH holds each asset's periods).
2. Submit FAYEAR. Confirm FARETIRE RETIRED=, FANBVRL ... CLAMPED=0, FAREGEN YEAR=y LINES=, FAREGPR LINES=.
3. Reconcile the register snapshot:

-- one row per live asset for the year; RACCUM/RNBV are the year-end position
SELECT ASTNO, RCCTR, RCOST, RACCUM, RNBV FROM ESTATE.FAREG WHERE RYEAR = 2026;

• Retirement — a fully-depreciated in-service asset (ACCDEP = COST−SALVAGE) becomes 'F' with NBV 0 and a FALEDG 'F' row (e.g. AS400001 at LSEQ 60400001).
• NBV roll — CLAMPED=0 means no asset was out of line; a non-zero count means the roll had to hold accumulated at the base or NBV at 0 (investigate the source posting).
• Register position — e.g. the lathe after 3 straight-line months: RACCUM 2700.00 (3×900), RNBV 57300.00 (60000−2700), RCCTR CC10.

E.4 Failure & re-run rules

Each program DSPLYs a counted result line. Every posting program is guarded so a re-run posts nothing rather than double-posting.

F. Developer Reference ↑ top

The mechanics that matter when maintaining ESTATE/i, from src/sources.mjs. All objects are in library ESTATE.

F.1 Depreciation formulae & the invariant

All three methods are computed per PERIOD (one month) in FADEPRUN, subroutine DEP1, and every method half-adjusts to the cent (eval(h)) rather than truncating — a ledger that truncated every month would drift cents from the base and the final clamp would carry the whole error.

S — straight-line

monthly = (COST - SALVAGE) / LIFEMT (only when LIFEMT > 0). Flat across periods.

D — declining-balance

monthly = (COST - ACCDEP) × DRATE / 12. The rate is applied to net book value, so the charge shrinks each month (classic reducing balance).

U — units-of-production

monthly = USEUNIT × DRATE (units run in the period × per-unit rate). The harness/operator stamps USEUNIT before the run; the program consumes it.

The invariant, enforced for every method: the depreciable base is WBASE = COST - SALVAG and the remaining base is WREM = WBASE - ACCDEP. If the computed charge exceeds WREM it is clamped to WREM; a charge ≤ 0 skips the asset (no history row). So accumulated depreciation can never exceed COST - SALVAGE and NBV can never fall below salvage while the asset is live, nor go negative. The annual FANBVRL re-asserts this by clamping accumulated to the base and NBV to non-negative and counting how many it had to fix.

F.2 Idempotency keys

Every posting program derives its key from a stable business key on a disjoint LSEQ range, then CHAIN(EN)s that key before writing: if the row exists it increments SKIP and leaves; otherwise it writes. A re-run regenerates the identical key and is refused rather than double-posting.

F.3 The re-CHAIN pattern & composite keys

Two RPG idioms recur and are worth understanding before editing:

• Re-CHAIN after a side write. A subroutine reads the driver record, then CHAINs other files (the class, the ledger). Those chains move the file cursor off the driver record, so before it updates the driver the program re-CHAINs the driver on its captured key (e.g. WAST CHAIN(E) FAASSETR). Omitting the re-CHAIN would update whatever record the cursor last landed on.
• Composite-key KLIST chains. Where a file's key is composite — FADEPH (ASTNO, DPER), FAMAINT (ASTNO, MSEQ), FAREG (RYEAR, ASTNO) — the guard/re-CHAIN uses a KLIST of both parts. Chaining on the first part alone would match the asset's FIRST period (or first schedule line) and wrongly skip or update the wrong row; both key fields must be in the KLIST. This is called out explicitly in the FADEPRUN and FAMTSWP source.

Embedded SQL (FAGLPST). The one SQLRPGLE program uses free-form exec sql: a SELECT COUNT(*) INTO :wexist idempotency check, then an INSERT INTO ESTATE.FAGLDIST VALUES(...) per DR/CR row inside a begsr glrow subroutine, summing the period read through the period-keyed logical FADEPHR (accessed as FADEPLF).

F.4 Program status codes (result lines)

ESTATE/i signals no application SQLSTATEs; every program reports its outcome as a counted DSPLY line. The completion banners are sent by the CL cycles.

G. Glossary ↑ top

Accumulated depreciation (ACCDEP)

The running total of depreciation charged against an asset since it went into service. NBV is COST - ACCDEP.

Capitalisation

Bringing a pending asset into service: stamping the in-service date, setting NBV = cost, moving ASTAT P→A and posting a FALEDG 'C' row (FAACQ).

Cost centre (FACCTR)

An organisational unit an asset belongs to; transfers move an asset between two, and the register and GL distribution subtotal by them.

Data area (FADEPPER)

A small named object (*DTAARA) holding the depreciation period the parameterless monthly programs read, so a bare CALL can drive them for any month.

Declining-balance (D)

Depreciation applied to net book value at an annual rate (÷12 monthly), so the charge shrinks each period: (COST - ACCDEP) × DRATE / 12.

Depreciable base

COST - SALVAGE — the ceiling accumulated depreciation may never exceed. The invariant clamps every charge to what is left of it.

Depreciation history (FADEPH)

One row per asset per period (composite key ASTNO, DPER) carrying the charge, running accumulated and NBV; the key both accumulates history and guards same-period re-runs.

Disposal

Selling/retiring an asset for proceeds: NBV = cost−accumulated, gain/loss = proceeds−NBV, asset→'D', a signed FALEDG 'S' row (FADISPOS).

GL distribution (FAGLDIST)

Balanced double-entry rows the monthly depreciation feeds to the general ledger: DR depreciation expense (7100-DEPN), CR accumulated depreciation (1590-ADEP), per cost centre (FAGLPST).

Idempotent

Safe to run again with the same result. Every ESTATE/i posting is idempotent via a stable business key on a disjoint range (or a composite period/year key), so a re-run posts nothing.

Ledger (FALEDG)

The single accumulating audit trail every cycle contributes to (LTYPE C/X/S/P/F), with disjoint LSEQ ranges per program.

Net book value (NBV)

An asset's carrying value: COST - ACCDEP. Derived, and also carried on the master and on the inquiry screen; never below salvage while live, never negative.

Re-CHAIN

Re-reading the driver record on its captured key after a side write (to another file) moved the file cursor, so the driver update lands on the right record.

SBMJOB

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

Straight-line (S)

Equal depreciation each month over the asset's life: (COST - SALVAGE) / LIFEMT.

Subfile

A 5250 display construct listing many rows on one screen (DDS SFL/SFLCTL). FADEPIQ's period-charge list is a subfile with SFLPAG(0005) paging.

Units-of-production (U)

Depreciation by usage: USEUNIT × DRATE (units run this period × per-unit rate); no usage, no charge.