# Infor XA History File Growth and Purge Retention Simulator

> Source: https://netray.co/tools/infor-xa-history-file-growth-and-purge-simulator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Estimate how big your XA inventory, MO and CO history files are today, how big they settle at for a chosen retention period, and how much disk a purge plus RGZPFM gives back.

## Category

other-erp

## Erp

Infor XA

## Audience

- ERP administrator
- IBM i administrator
- IT manager

## Tool

**Kind:** calculator

**Inputs:**

#### Current rows in IMHIST

**Key:** imhist_rows

**Type:** number

**Default:** 8000000

**Min:** 0

**Step:** 100000

**Unit:** rows

**Help:** NUMBER_ROWS from QSYS2.SYSTABLESTAT

#### IMHIST record length

**Key:** len1

**Type:** number

**Default:** 600

**Min:** 1

**Step:** 10

**Unit:** bytes

**Help:** From DSPFD AMFLIB/IMHIST

#### New IMHIST rows per month

**Key:** imhist_monthly

**Type:** number

**Default:** 120000

**Min:** 0

**Step:** 1000

**Unit:** rows

#### MO history rows per month (MOHMST + MOHDTA + MOHTRN)

**Key:** mo_monthly

**Type:** number

**Default:** 40000

**Min:** 0

**Step:** 1000

**Unit:** rows

#### Average MO history record length

**Key:** len2

**Type:** number

**Default:** 500

**Min:** 1

**Step:** 10

**Unit:** bytes

#### CO history rows per month (MBFBREP + MBDRREP)

**Key:** co_monthly

**Type:** number

**Default:** 30000

**Min:** 0

**Step:** 1000

**Unit:** rows

#### Average CO history record length

**Key:** len3

**Type:** number

**Default:** 700

**Min:** 1

**Step:** 10

**Unit:** bytes

#### Retention kept after purge

**Key:** retention

**Type:** slider

**Default:** 36

**Min:** 6

**Max:** 120

**Step:** 6

**Unit:** months

#### Months of MO and CO history on file today

**Key:** months_on_file

**Type:** number

**Default:** 120

**Min:** 1

**Step:** 6

**Unit:** months

#### Access path (logical file) overhead

**Key:** idx

**Type:** number

**Default:** 40

**Min:** 0

**Max:** 200

**Step:** 5

**Unit:** %

**Outputs:**

#### Size factor including access paths

**Key:** factor

**Expr:** 1 + idx / 100

**Format:** decimal

#### Current estimated history size

**Key:** current_gb

**Expr:** (imhist_rows * len1 + (mo_monthly * len2 + co_monthly * len3) * months_on_file) * factor / 1000000000

**Format:** decimal

**Description:** GB. IMHIST from actual rows; MO and CO history from monthly rate x months on file.

#### Steady-state size after purge

**Key:** steady_gb

**Expr:** (imhist_monthly * len1 + mo_monthly * len2 + co_monthly * len3) * retention * factor / 1000000000

**Format:** decimal

**Primary:** true

**Description:** GB. Monthly rows x retention months x record length, plus access path overhead.

#### Disk returned after purge and RGZPFM

**Key:** freed_gb

**Expr:** max(0, current_gb - steady_gb)

**Format:** decimal

**Primary:** true

**Description:** GB. Only returned once the files are reorganised.

#### Rows removed by the purge

**Key:** rows_removed

**Expr:** max(0, imhist_rows - imhist_monthly * retention) + max(0, months_on_file - retention) * (mo_monthly + co_monthly)

**Format:** integer

#### Growth per month at steady state

**Key:** growth_gb_month

**Expr:** (imhist_monthly * len1 + mo_monthly * len2 + co_monthly * len3) * factor / 1000000000

**Format:** decimal

**Description:** GB per month that the next purge has to remove.

**Chart:**

#### Steady-state history size (GB) by retention months

**Type:** line

**X:** retention

**From:** 12

**To:** 120

**Steps:** 10

**Series:**

- steady_gb

**Disclaimer:** Planning estimate only. Access path overhead varies with the number and keys of logical files; take real sizes from QSYS2.SYSTABLESTAT and DSPFD before and after a test purge.

## Content

**Intro:** This simulator estimates the disk used by Infor XA history files on IBM i (inventory transaction history in IMHIST, MO history and CO history) and the size they settle at for a chosen retention period. It shows how much space a purge followed by RGZPFM gives back, with a chart of steady-state size against retention months.

**Sections:**

#### How to use it

**Body:** Take the current row count of IMHIST from QSYS2.SYSTABLESTAT (NUMBER_ROWS) and the record length from DSPFD AMFLIB/IMHIST. Estimate monthly rows by comparing two row counts a month apart, or by counting rows for a recent month by transaction date. Do the same for MO history (MOHMST, MOHDTA and MOHTRN, plus MOHRTG if your volumes there are large) and CO history (MBFBREP and MBDRREP), using a weighted average record length. Enter the retention your finance and quality teams have agreed, and the number of months of MO and CO history already on file. The access path overhead covers the logical files built over each physical.

#### The formula behind it

**Body:** The rule is simple: after a purge to a fixed retention, a history file holds about monthly rows x retention months, and from then on each purge removes roughly the rows added since the last one. Size in bytes is rows x record length, multiplied by (1 + overhead %) for access paths. Current size uses the actual IMHIST row count and, for MO and CO history, the monthly rate x months on file. Space freed is current minus steady-state size, never below zero.

**Bullets:**

- Steady GB = (IMHIST/month x len1 + MO/month x len2 + CO/month x len3) x retention x (1 + idx/100) / 1e9
- Current GB = (IMHIST rows x len1 + (MO/month x len2 + CO/month x len3) x months on file) x (1 + idx/100) / 1e9
- Freed GB = max(0, current - steady)

#### Worked example

**Body:** With the defaults (8,000,000 IMHIST rows at 600 bytes, 120,000 new rows a month, 40,000 MO history rows a month at 500 bytes, 30,000 CO history rows a month at 700 bytes, 120 months on file and 40% access path overhead) the history files hold about 13.6 GB today. Purging to 36 months leaves about 5.7 GB, so roughly 7.9 GB comes back once the files are reorganised, and the files then grow by about 0.16 GB a month until the next purge. The chart shows that each extra year of retention adds about 1.9 GB at these volumes, which helps when finance asks for seven years instead of three.

#### Gotchas: purge is not the same as free space

**Body:** XA has purge functions per application (inventory history, MO history, CO history), and running them deletes records, but on IBM i deleted records stay in the file until it is reorganised with RGZPFM or new records reuse the space because the file has REUSEDLT(*YES). Plan RGZPFM in a window with XA stopped, after a backup, and allow time for access paths to rebuild on the larger files. Check whether restored history (IMHGEN) or old copies of history libraries are still on disk. Confirm retention with finance, audit and quality before purging, because restoring purged history is a manual job.

**Cta:** If you want old XA history kept searchable for audits through a private assistant while the live files stay small, we can set that up on your own servers.

**Faq:**

#### Why did disk space not go down after an XA purge?

**Answer:** On IBM i a purge deletes records, but the space stays allocated to the file as deleted records. It is only returned when the file is reorganised with RGZPFM, or reused by new records if the file has REUSEDLT(*YES). Check NUMBER_DELETED_ROWS in QSYS2.SYSTABLESTAT to see how much space is waiting to be reclaimed.

#### Which XA history files grow fastest?

**Answer:** Usually IMHIST, the inventory transaction history file, followed by shop activity transaction history in MOHTRN and CO history line items in MBDRREP. The exact order depends on how many transactions you post and how long you have run XA. Query QSYS2.SYSTABLESTAT for the library to see the real ranking.

#### How many months of history should we keep in XA?

**Answer:** That is a business decision, not a technical one. Finance, tax, customer contract and quality record requirements set the minimum, often several years for some records. A common approach is to keep a shorter period in the live files and archive older history to a separate library or a reporting database before purging.

#### Does moving to XA Release 10 change history file sizes?

**Answer:** The upgrade itself does not shrink history. It is often a good moment to purge and reorganise first, because smaller files make the upgrade conversion and the backup before it faster. Check the XA 10 documentation for any file changes in your installed applications.

## Search terms

infor xa erp, infor xa tables, infor xa release 10, infor xa support, mapics imhist purge, xa history file retention, ibm i rgzpfm disk space, mapics history purge

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