IBM i Journal Receiver Growth and Retention Calculator
This calculator estimates how many gigabytes of journal receivers a journaled IBM i ERP library writes per day and how much disk your retention policy needs, for commitment control, audit or HA replication. It is a transparent engineering estimate you calibrate against one day of your own receivers.
Your numbers
Weighted average record length of the journaled files (DSPFD or QSYS2.SYSTABLES ROW_LENGTH).
*BOTH writes a before image (UB) and an after image (UP) for each update. Many HA products need *BOTH.
Fixed-length portion and headers per entry. Measure it (see the page) and lower it with RCVSIZOPT(*MINFIXLEN) and fewer FIXLENDTA options.
100% for full images. MINENTDTA(*FILE) or (*FLDBDY) can journal only changed data on updates; measure the real saving.
THRESHOLD on CRTJRNRCV is in KB; 5 GB = 5242880 KB.
Leave at 0 unless you measured a saving, for example from omitting open and close entries with OMTJRNE(*OPNCLO).
Your results
This is an engineering estimate, not an IBM formula. Calibrate entry overhead from your own receivers (SIZE and NUMBER_OF_JOURNAL_ENTRIES in QSYS2.JOURNAL_RECEIVER_INFO) before sizing disk.
Retained receiver disk vs days kept
Sweeps Receivers kept online from 1 to 30, holding your other inputs fixed.
Get your journal sizing checked
Send one day of JOURNAL_RECEIVER_INFO output and your retention rules and we will return a calibrated sizing and receiver settings to review.
Optional. The tool and every export work without this. No spam.
How to use it
Enter daily inserts, updates and deletes across the journaled files, the average record length, and whether files are journaled with *AFTER or *BOTH images. Keep entry overhead at 150 bytes until you measure it, and leave the update data slider at 100% unless you use MINENTDTA. Set how many days of receivers you keep online and the receiver threshold. The result gives GB per day, disk for the retained receivers, how many receiver changes a day to expect, and the average bytes per entry, which you can compare directly with a measured receiver.
- Row counts per day can come from DISPLAY_JOURNAL summaries or application statistics
- Use a weighted average record length if file sizes differ a lot
- Add journals for other libraries separately and sum the results
The formula and its basis
Each insert writes one PT entry and each delete one DL entry, counted here as one record image plus overhead. Each update writes one UP entry with *AFTER, or a UB and a UP entry with *BOTH, so updates are multiplied by the image count. Bytes per day = (inserts + deletes) x (record length + overhead) + updates x images x (record length x kept% + overhead). GB per day divides by 1,073,741,824, retained disk multiplies by days kept, and receiver changes divide by the threshold. The fixed-length portion of each entry (job, user, program, timestamps and other FIXLENDTA items) is why overhead is an input: it varies with RCVSIZOPT and FIXLENDTA settings, so IBM gives a manual estimation method rather than one number.
Worked example and calibration
With the defaults: inserts and deletes give 450,000 x 600 = 270,000,000 bytes, updates give 600,000 x 600 = 360,000,000 bytes, so 630,000,000 bytes or about 0.59 GB per day across 1,050,000 entries, an average of 600 bytes per entry. Kept for 7 days that is about 4.1 GB, and a 5 GB threshold means a receiver change roughly every eight days. Switching to *BOTH adds about 0.34 GB per day. To calibrate, run SELECT JOURNAL_RECEIVER_NAME, SIZE, NUMBER_OF_JOURNAL_ENTRIES FROM QSYS2.JOURNAL_RECEIVER_INFO for a detached receiver: SIZE x 1024 / NUMBER_OF_JOURNAL_ENTRIES is your real bytes per entry. Adjust overhead until the calculator matches.
Receiver management and gotchas
Create receivers with a THRESHOLD in KB and the journal with MNGRCV(*SYSTEM) so the system attaches a new receiver at the threshold. DLTRCV(*YES) lets the system delete detached receivers, but only when nothing else needs them. RCVSIZOPT(*MINFIXLEN) reduces the fixed-length data per entry; *RMVINTENT removes internal entries; *MAXOPT1, *MAXOPT2 and *MAXOPT3 raise the maximum receiver size and sequence number limits. MINENTDTA(*FILE) or (*FLDBDY) can minimise update entries, but check that your HA product and any audit use support minimised entries first. Never delete receivers that HA software such as MIMIX, iTERA or QuickEDD, or your save strategy, has not yet processed.
Frequently Asked Questions
How do I check journal receiver size on IBM i?
Run SELECT JOURNAL_RECEIVER_NAME, SIZE, NUMBER_OF_JOURNAL_ENTRIES, STATUS FROM QSYS2.JOURNAL_RECEIVER_INFO WHERE JOURNAL_RECEIVER_LIBRARY = 'YOURLIB'. SIZE is in kilobytes. QSYS2.JOURNAL_INFO gives the total size and count of receivers per journal. On a green screen, WRKJRNA and WRKJRNRCV show the same information.
What does RCVSIZOPT(*MINFIXLEN) do?
*MINFIXLEN keeps the fixed-length portion of each journal entry to a minimum, which makes receivers smaller and journaling slightly cheaper. The trade-off is that entries carry less identifying data such as job, user and program, so check that audit and HA tools do not rely on it. The FIXLENDTA parameter controls which items are kept.
Should I journal with *AFTER or *BOTH images?
*AFTER is enough for recovery forward with APYJRNCHG and halves update entries. *BOTH adds before images, which you need to back changes out with RMVJRNCHG. Commitment control uses before images for rollback, and the system journals them for changes made under commitment control even with *AFTER, so those files grow faster than the *AFTER figure. Many HA products require *BOTH. Use the calculator to see the extra disk.
How many days of journal receivers should I keep?
Keep receivers at least until they are saved and every consumer has processed them: HA replication, audit extraction and any recovery point you promised. Many shops keep 3 to 14 days online and older receivers on backup media. The chart shows how retained disk grows with each extra day kept.
If you want your admins to ask how fast journals are growing, which files drive it and what is safe to delete, in plain English against your own IBM i, we can run that assistant on your servers.
Related Tools
IBM i Services (QSYS2 and SYSTOOLS) SQL Reference
Searchable list of IBM i Services you can query with SQL from Run SQL Scripts, STRSQL or ODBC, with the CL command each replaces and a ready-to-run statement.
ERP OperationsIBM i Disk Capacity Runway Calculator
Enter total and used disk, your yearly growth and a threshold to see how many months of headroom you have left.
ERP OperationsIBM i (AS/400) Disaster Recovery Runbook Template
Fill-in recovery runbook for an IBM i production partition: objectives, restore sequence, contacts, validation steps and drill history.
OracleAS/400 Disk Storage Growth Forecast Calculator
Estimate how many years of disk you have left on IBM i given data growth, journal receivers and your safe utilisation threshold.
More Developer Tools tools
See all- IBM i Query/400 (WRKQRY) Record Selection Tests and Result Field Reference
- IBM i ILE RPG Status Codes and Common Error Messages Reference
- IBM i RPGLE Fully Free Program Skeleton Generator (SQL, MONITOR)
- IBM i RPGLE Service Program Generator (NOMAIN, Binder Source, CRTSRVPGM)
- SAP Sales Order ABAP SELECT Generator (VBAK, VBAP, VBFA)
- SAP Sales Order Create BAPI ABAP Generator (BAPI_SALESORDER_CREATEFROMDAT2)
- SAP ABAP Open Items SELECT Generator
- SAP ACDOCA SQL Query Generator
- SAP QM Inspection Lot ABAP SELECT Generator
Keep exploring
Free tools
- AS/400 Disk Storage Growth Forecast CalculatorEstimate how many years of disk you have left on IBM i given data growth, journal receivers and your safe utilisation threshold.
- IBM i Disk Growth and Capacity Forecast CalculatorForecast how many months until IBM i auxiliary storage reaches your threshold, using current use, capacity and monthly growth.
- Records Retention Cost CalculatorModel your annual records retention cost across storage growth, legal hold overhead, and the savings available from defensible disposition.
ERP fixes and how-tos
- ERP Data Archiving Strategy: What to Archive and What to PurgeHow to decide what ERP data to archive or purge: find the big tables, set retention by record type, keep reports and audits working, and test restores first.
- How to Add a Private AI Layer to JD Edwards World on IBM iAdd AI to JD Edwards World without moving data: DB2 for i access, journal-based replication, rebuilt row security, local GPUs and approved batch write-back.
- How to Add AI to an IBM i (AS/400) RPG Application Without Moving ItHow to add a private AI assistant to custom RPG applications on IBM i: Db2 for i access, field names, journals, RCAC security, local LLM, sizing and rollout.
Guides
- ERP Audit Trails and Logging: What to Capture and KeepDesign ERP audit trails and logging that satisfy auditors: what to log in SyteLine and Infor LN, retention periods, SIEM forwarding, and tamper-evident records.
- How to Fix SyteLine Posting FailuresResolve SyteLine posting failures for journal entries, inventory transactions, and production completions with GL account validation, batch error analysis, and recovery procedures.
- How to Fix SyteLine Posting Out of Balance ErrorsResolve SyteLine GL posting imbalance errors including 'Journal entry is out of balance' and debit/credit mismatches. Step-by-step fix for financial posting issues.
Integrations
- How to use Claude with Infor XA on IBM iHow to use Claude with Infor XA on IBM i: MCP connectors, Anthropic API versus Bedrock or Vertex, enterprise data handling, and an on-prem alternative.
- How to add AI agents to Infor XA on IBM iHow to add AI agents to Infor XA on IBM i: a tool layer over Db2 for i and RPG programs, approval gates, on-prem models, and realistic expedite and exception flows.