# IBM i Journal Receiver Growth and Retention Calculator

> Source: https://netray.co/tools/ibm-i-journal-receiver-growth-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate how fast journal receivers grow for a journaled ERP library and how much disk your retention policy needs, from daily row changes, record length, images and entry overhead.

## Category

developer

## Erp

IBM i

## Audience

- IBM i administrator
- HA administrator
- DBA

## Tool

**Kind:** calculator

**Inputs:**

#### Inserts per day

**Key:** inserts

**Type:** number

**Default:** 400000

**Min:** 0

**Step:** 10000

**Unit:** rows

#### Updates per day

**Key:** updates

**Type:** number

**Default:** 600000

**Min:** 0

**Step:** 10000

**Unit:** rows

#### Deletes per day

**Key:** deletes

**Type:** number

**Default:** 50000

**Min:** 0

**Step:** 1000

**Unit:** rows

#### Average record length

**Key:** rec_bytes

**Type:** number

**Default:** 450

**Min:** 1

**Step:** 10

**Unit:** bytes

**Help:** Weighted average record length of the journaled files (DSPFD or QSYS2.SYSTABLES ROW_LENGTH).

#### Journal images

**Key:** images

**Type:** select

**Default:** 1

**Options:**

##### *AFTER (1 entry per update)

**Value:** 1

##### *BOTH (before and after)

**Value:** 2

**Help:** *BOTH writes a before image (UB) and an after image (UP) for each update. Many HA products need *BOTH.

#### Entry overhead

**Key:** overhead

**Type:** number

**Default:** 150

**Min:** 0

**Step:** 10

**Unit:** bytes

**Help:** Fixed-length portion and headers per entry. Measure it (see the page) and lower it with RCVSIZOPT(*MINFIXLEN) and fewer FIXLENDTA options.

#### Update entry data kept

**Key:** minent_pct

**Type:** slider

**Default:** 100

**Min:** 10

**Max:** 100

**Step:** 5

**Unit:** %

**Help:** 100% for full images. MINENTDTA(*FILE) or (*FLDBDY) can journal only changed data on updates; measure the real saving.

#### Receivers kept online

**Key:** retention

**Type:** number

**Default:** 7

**Min:** 1

**Step:** 1

**Unit:** days

#### Receiver threshold

**Key:** threshold_gb

**Type:** number

**Default:** 5

**Min:** 0.1

**Step:** 0.5

**Unit:** GB

**Help:** THRESHOLD on CRTJRNRCV is in KB; 5 GB = 5242880 KB.

#### Other measured reduction

**Key:** reduction_pct

**Type:** number

**Default:** 0

**Min:** 0

**Max:** 90

**Step:** 5

**Unit:** %

**Help:** Leave at 0 unless you measured a saving, for example from omitting open and close entries with OMTJRNE(*OPNCLO).

**Outputs:**

#### Journal entries per day

**Key:** entries_per_day

**Expr:** inserts + deletes + updates * images

**Format:** integer

#### Bytes per day

**Key:** bytes_per_day

**Expr:** (inserts + deletes) * (rec_bytes + overhead) + updates * images * (rec_bytes * minent_pct / 100 + overhead)

**Format:** integer

#### Receiver growth per day

**Key:** gb_per_day

**Expr:** bytes_per_day / 1073741824 * (1 - reduction_pct / 100)

**Format:** decimal

**Primary:** true

**Description:** GB of journal receiver written per day.

#### Disk for retained receivers

**Key:** retained_gb

**Expr:** gb_per_day * retention

**Format:** decimal

**Primary:** true

**Description:** GB on disk if receivers are kept online for the retention period.

#### Receiver changes per day

**Key:** receivers_per_day

**Expr:** gb_per_day / threshold_gb

**Format:** decimal

**Description:** With MNGRCV(*SYSTEM) the system attaches a new receiver at the threshold.

#### Average bytes per entry

**Key:** bytes_per_entry

**Expr:** bytes_per_day / entries_per_day

**Format:** integer

**Chart:**

#### Retained receiver disk vs days kept

**Type:** line

**X:** retention

**From:** 1

**To:** 30

**Steps:** 30

**Series:**

- retained_gb

**Disclaimer:** 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.

## Content

**Intro:** 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.

**Sections:**

#### How to use it

**Body:** 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.

**Bullets:**

- 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

**Body:** 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

**Body:** 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

**Body:** 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.

**Cta:** 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.

**Faq:**

#### How do I check journal receiver size on IBM i?

**Answer:** 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?

**Answer:** *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?

**Answer:** *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?

**Answer:** 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.

## Search terms

ibm i journal receiver size, as400 journal receiver disk space, journal receiver threshold, rcvsizopt minfixlen, minentdta fldbdy, qsys2 journal_receiver_info, ibm i mngrcv system dltrcv

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json