IBM i Journalling

Getting Started

If you've spent any time managing an IBM i server, you've probably heard the term "journaling" thrown around in conversations about high availability, disaster recovery and database integrity.

Journaling is one of the most powerful and most underused, features built into IBM i.

It's the backbone of commitment control, remote journaling and most third-party replication tools.

Let's walk through what it is, why it matters and how to set it up.

What Is Journaling, Exactly?

At its core, journaling is a mechanism that records changes made to database files as they happen.

Every insert, update and delete gets written to a journal receiver, chronological log of activity.

This gives you:

• Recovery to a specific point in time after a failure
• Auditing of who changed what and when
• Replication support for high availability solutions
• Commitment control, allowing groups of changes to be treated as a single transaction

Without journaling, if your system goes down mid-transaction, you're relying on save/restore backups alone.

Which usually means losing hours of work.

With journaling, you can often recover right up to the last committed transaction.

The Core Building Blocks

Two objects sit at the heart of journaling:

• Journal (*JRN) — the object that ties everything together and controls journaling
• Journal Receiver (*JRNRCV) — where the actual entries are stored

Think of the journal as the control tower and the receiver as the logbook.

Receivers fill up and get swapped out periodically (either automatically or manually), so you always have a fresh one capturing new activity while older ones are archived or deleted.

Setting Up Journaling: Step by Step

Here's a typical sequence for journaling a physical file.

1. Create a Journal Receiver

CRTJRNRCV JRNRCV(MYLIB/JRNRCV0001) TEXT('Initial journal receiver')

2. Create the Journal

CRTJRN JRN(MYLIB/MYJRN) JRNRCV(MYLIB/JRNRCV0001) TEXT('Production journal')

3. Start Journaling on a File

STRJRNPF FILE(MYLIB/CUSTMAST) JRN(MYLIB/MYJRN) IMAGES(\*BOTH)

The IMAGES(\*BOTH) parameter is important. It tells the system to capture both the before and after image of a record change, which is essential if you ever need to reverse a transaction or do detailed auditing.

4. Verify Journaling Status

DSPFD FILE(MYLIB/CUSTMAST) TYPE(\*ALL)

Look for the journaling section in the output to confirm the file is actively being journaled and to which journal.

Managing Journal Receivers

Left unmanaged, journal receivers can grow large and eat up disk space fast.

Here are a few practices to keep things healthy:

• Change receivers regularly using CHGJRN with a threshold or on a schedule, so no single receiver grows unbounded
• Automate receiver management with MNGRCV(\*SYSTEM) on the CRTJRN or CHGJRN command, letting the system handle receiver swaps automatically
• Save and delete old receivers once they're no longer needed for recovery, using standard save commands before deletion
• Monitor disk usage with WRKJRNA (Work with Journal Attributes) to keep an eye on receiver sizes and journal status

CHGJRN JRN(MYLIB/MYJRN) JRNRCV(*GEN) MNGRCV(*SYSTEM) DLTRCV(*NO)

This command tells the system to automatically generate new receivers as needed while retaining old ones until you're ready to remove them yourself — a safer default until you're comfortable with the retention policy.

Commitment Control: Journaling's Best Friend

Journaling alone gives you a change log, but pairing it with commitment control gives you true transactional integrity. Wrapping a series of updates in a commit boundary means either all the changes happen, or none do.

STRCMTCTL LCKLVL(*CHG)

\* application logic performing multiple updates */

COMMIT

If something goes wrong mid-transaction, you issue a ROLLBACK instead and every change since the last commit point is undone.

This is exactly how banking systems ensure a debit and a credit both post together, or not at all.

Using Journals for Recovery

When disaster strikes, journal receivers become your lifeline.

The APYJRNCHG command lets you apply journaled changes to a restored file, bringing it forward from your last backup to the point of failure:

APYJRNCHG JRN(MYLIB/MYJRN) FILE(MYLIB/CUSTMAST) TOTIME(*LASTENTRY)

There's also RMVJRNCHG for removing changes (useful for rolling back unwanted transactions after the fact) and RCVJRNE for retrieving specific journal entries programmatically if you want to build your own audit reports.

A Few Practical Tips

• Always journal your critical business files, not just for recovery but for audit and compliance requirements
• Consider remote journaling if you run a high-availability setup. It ships journal entries to a backup system in near real time
• Test your recovery procedures periodically; a journal you've never practiced restoring from is a gamble
• Keep journal receivers on a separate ASP (Auxiliary Storage Pool) when possible, to isolate I/O and protect against storage contention

Wrapping Up

Journaling on IBM i isn't just a checkbox for compliance, it's a foundational piece of a resilient system architecture.

Once you have journals and receivers in place, layering in commitment control and remote journaling opens the door to near-zero data loss and robust auditing.

If you haven't turned it on for your critical files yet, there's no better time to start than now.