July 13, 2020 | IBM i

Database and Security Journaling on the IBM i

NOTE: Don’t forget to register for our Database Journaling webinar on July 16, 2020!

IBM i journaling is one of IBM i’s most incredible features. Since the database has always been integrated with the operating system, IBM i users can do some really amazing things with journaling. Let’s look at what IBM i journaling is, what benefits it offers IBM i shops, and the history of IBM i journaling.

The history of journaling

IBM journal management has been around in one form or the other since at least the 1980s. In its pre-AS/400 days, journaling served as a primitive disaster recovery option, where data objects would be restored from a backup tape and then have journal entries reapplied from another tape to make the data current.

Journaling was in full bloom by the time IBM announced the AS/400 in 1989 (IBM did not start using the IBM i OS name until 2008). Throughout the 1990s and 2000s, IBM continued to refine journal management. I even recently found an article on journaling from 1996 that discussed a number of basic functions facilitated by journaling, including Save While Active, SMAPP, Backup and Recovery Strategies, and Commitment Control. These items made the AS/400 more resilient and increased backup and recovery speeds. Commitment control was a major addition, as it allowed customers to roll back changes to multiple related files for a specific function (such as all the records entered for a particular order), removing corrupt or damaged records.

Since the 1990s, IBM added a number of other functions to its journaling capabilities. With IBM i security journaling (QAUDJRN), journaling is now a key component in auditing and forensic analysis. Remote journaling allows shops to export journal entries to other IBM i systems where they can be used in a number of disaster recovery, high availability, and system restore scenarios and in availability products sold by IBM and other vendors. Remote journaling allows us to perform cloud disaster recovery, high availability, and business continuity today.

Journaling was ahead of its time in the 1980s and it is still going strong almost 40 years later.

What is IBM i journaling?

IBM i journaling provides a means where you can record the chronological activity of system objects. IBM offers two types of journals on the IBM i.

Database journals that track libraries, files, access paths, data areas, data queues, and Integrated File System activity. Database journals must be set up for any IBM i objects you want to track. There are no limits on the number of data objects you can track or the number of database journals you can set up.
The Security Audit Journal (QAUDJRN) that tracks security event information on your system. QAUDJRN is an IBM-supplied journal, but it must be set up before it starts tracking security events. QAUDJRN can generally be set up to track security events and other items that are not tracked by IBM i database journals.

IBM records system activity using two system objects: Journals and Journal Receivers. Journaled objects are associated with a particular journal. Journals receive journal entries detailing activity from their associated journaled objects, and a single journal can monitor many different objects.

Journal entries contain detailed information about any changes made to the objects the journal monitors. Depending on how their associated journal is configured, the system will produce journal entries detailing what the object looked like after a change or alternatively, before and after journal entry snapshots of what the object looked like before and after it was changed.

After receipt, the journal stores the journal entries in an attached journal receiver. Journal receivers are created and attached to their parent journals, as needed, and they are swapped out for a new receiver when they reach their capacity. Each journal receiver is linked to the receivers that were created directly before and after it was created, and there can only be one active journal receiver receiving entries at a time. Old journal receivers can be managed and deleted from the system manually or automatically, according to its journal’s parameters.

Journals and journal receivers must be set up locally for their monitored objects (local journal management). You can also set up remote journal and journal receivers on remote systems (remote journal management) that are associated with local journals. Journal entries on the local system are then replicated to their associated remote journal receiver.

Inside IBM i, Journal entries can be reviewed in one of three ways.

By using the Display Journal command (DSPJRN).
By using the Copy Audit Journal Entries command (CPYAUDJRNE) to copy selected entries into an IBM i file, and then use a custom-written program to analyze the entries.
Using SQL to extract audit journal entry data by using the DISPLAY_JOURNAL function

Be warned that is difficult to extract and analyze journal entries using these native commands. Several companies offer auditing products such as SEA’s iSecurity Audit that can produce auditing reports from IBM journal entries.

For more information on setting up and configuring IBM i journaling, see the IBM i Knowledge Center entry on Journal Management.

What functions are available with IBM i journaling?

Here are the functions and features you can access with IBM i journaling.

Tracking changes to data and non-data objects–Journaling takes before and after images of changes as they occur (database journaling and security journaling: QAUDJRN)
Recovering changes to data objects that have occurred since the object was last saved (Object restoration)
Creating and accessing an audit trail of QAUDJRN object activity. The audit trail allows you to perform forensic analysis for auditing security violations, program modifications, IBM i command access, and more (system auditing)
Generating user-defined journal entries to record activity for items that are not journaled in the operating system (user-defined journaling)
Enabling backups to occur when objects are in use (Save While Active)
Providing quicker object restores when restoring objects from Save While Active media (Restoration)
Recovering objects while they are in use (Restore-While-Active)
Rolling back modifications to multiple-related files, using commitment control (Commitment Control)
Reducing the IPL time to restart a system or vary on an independent disk, after an abnormal system end (System-managed-access-path-protection, SMAPP)
Replicating journal entries to another system for use in system restores, high availability systems, and disaster recovery in wide area networks and in the cloud (remote journal management)