Unveiling the IBM i Journal

Introduction

IBM i Journal Management allows you to keep track of the activity of specific objects in your system. When you use journal management, you create an object called a journal. IBM i Developers use journals to track files, system activity, and other important data. It enables auditing, recovery, and replication of changes by capturing and storing detailed logs of changes.

Understanding IBM i Journaling

An IBM i journaling feature allows objects and data to be tracked when changed. It provides a reliable and comprehensive audit trail, allowing for data recovery In IBM i, journaling refers to a feature that provides transaction logging and recovery capabilities for maintaining data integrity and protecting against data loss.

Journaling works by recording all database changes in a sequential log called a journal. The journal captures information about each transaction, including the before and after values of modified data, as well as metadata such as timestamps and user IDs. To ensure durability, journal entries are written to auxiliary storage, such as disks or tapes.

Benefits of Journal Management

Journal management is primarily useful for recovering changes to objects made since they were last saved. An unscheduled outage, such as a power outage, can be resolved with this ability.

In addition to powerful recovery functions, journal management also has the following benefits:

• Journal Management enhances system security. You can create an audit trail of activity that occurs for objects.
• If an object does not support journaling, you can still record activity with user-defined journal entries.
• Journal Management provides quicker recovery of access paths if your system ends abnormally.
• Journal Management provides quicker recovery when restoring from save-while-active media.
• Journal Management provides the means to recover an object that was saved with partial transactions.
  

How Journal Management Works

Journal management allows you to create an object called Journal. Using a journal, you can specify what objects you want to protect. You can have more than one journal on your system. A journal can define protection for more than one object.

You can journal the objects that are listed below:

• Libraries
• Database physical files
• Access paths
• Data areas
• Data queues
• Integrated file system objects (stream files, directories, and symbolic links).

Journal Entries

The system keeps a record of changes you make to objects that are journaled and of other events that occur on the system. These records are called journal entries. It is also possible to write journal entries for events that you wish to record, or for objects other than those you wish to protect with journaling.

Journal entries can include additional control information, such as the user, job, program, time, and date, which identifies the source of the activity. The entries that the system deposits for a journaled object reflect the changes made to that journaled object.

For example, the entries for changes to database records can include the entire image of the database record, not just the changed information.

Journal Receivers

The system writes entries to an object called a journal receiver. The system sends entries for all the objects associated with a particular journal to the same journal receiver.

You can attach journal receivers to a journal by using System i Navigator or the Create Journal (CRTJRN) and Change Journal (CHGJRN) commands. The system adds journal entries to the attached receiver. Journal receivers that are no longer attached to a journal and are still known to the system are associated with that journal. Use the Work with Journal Attributes (WRKJRNA) command to see a list of receivers associated with a journal.

The system adds an entry to the attached journal receiver when an event occurs to a journaled object. The system numbers each entry sequentially.

For example, it adds an entry when you change a record in a journaled database file member.

Journal entries contain information that identifies:

• Type of change
• A record that has been changed
• Change that has been made to the record.
• Information about the change (such as the job being run and the time of the change)

Whenever you journal an object, the receiver receives changes to the object. The system does not journal data that you retrieved but did not change. If the logical file record format of a database file does not include all the fields that are in the dependent physical file record format, the journal entry still includes all the fields.

Moreover, if you use journal access paths, those access paths are added to the journal. In the case of an update of a physical file image where the image after the update is the same as the image before the update, and the file has no variable length fields, journal entries are not deposited for that update. For data area updates if before and after images are not the same entries are not logged.

Setting up Journaling

1. Create a journal receiver using the create Journal Receiver (CRTJRNRCV) command.

It is a good habit to name the journal receiver the same as the journal, plus a numeric suffix such as 0 or 1.

Also, you should put journal receivers in the same library as the file.

2. Create a journal: Use the create Journal (CRTJRN) command to create a journal and specify the receiver created in step 1. Although you can journal multiple files to the same journal (and, in some cases, that is preferable), you will want to have a journal “serving” a single file.

3. Start Journaling the file: This is done by using the Start Journal Physical File (STRJRNPF) This is how you associate a file with a journal. Once the association is made, the system will record in the journal receiver a copy of any record added, updated, or deleted from the file. Other activities, such as when the file is opened and closed, can also be recorded in the journal receiver if you choose by selecting the appropriate options on the STRJRNPF command.

Four Basic Journal Entry Categories

The most common journal entry falls into four basic categories (J, F, R, C). Within each category, there are several different journal entry types represented by a two-character entry code (e.g., PR, NR for journal entry J).

• Journal and Journal Receiver Operations (J): These include such things as references to the previous receiver (PR) or the next receiver (NR) in a chain. Also, at IPL time, as an entry is made (e.g., an IN entry for IPL after the normal end) marking a critical chronological boundary in the file activity.

• FILE Operations (F): This category includes file opens (OP) and file closes (CL).
  

• Record Operations (R): Record updates (UP), deletes (DL), and new records written (PT and PX) all fall into this category.
  

• Commitment Control (C): Anything related to commitment control falls into this category. Some examples are beginning commitment control (BC), starting a commit cycle (SC), commit operation (CM), and rollback operation (RB).
  

Journal Management and System Performance

Journal management prevents transactions from being lost if your system ends abnormally or must be recovered. Journal management writes changes to journaled objects immediately to the journal receiver in auxiliary storage. Journaling increases the disk activity on your system and can have a noticeable effect on system performance.

Additionally, journaling increases the overhead associated with opening and closing objects, so as the number of objects you are journaling increases, the overall performance of the system can slow down. The time it takes to perform an IPL on your system or vary on of an independent auxiliary storage pool (ASP) can also increase, particularly if your system or independent ASP ends abnormally.

The system takes measures to minimize the performance effect of using journaling features. For example, the system packages before-images and after-images, and any access path changes for a record in a single write operation to auxiliary storage.

Therefore, journaling access paths, and before-images and after-images, usually do not cause additional performance overhead. However, they do add to the auxiliary storage requirements for journaling.

The system also spreads journal receivers across multiple disk units to improve performance. If you do not specify a maximum receiver-size option, then the system can place the journal receiver on up to ten disk units in a disk pool. If you specify a maximum receiver-size option, and a matching sufficiently large journal size threshold then the system can place the journal receiver on up to one hundred disk units in a disk pool.

Planning for Journal Management

To journal an object, you must decide how you will create journals and receivers, what objects to journal, and how you will journal them.

These decisions include:

1. Whether to use System i Navigator to set up your journaling environment.
2. What objects to protect with journaling?
3. Whether to journal other objects that the system does not journal.
4. Whether to combine journaling with the save-while-active function.
5. How many journals do you need, and which objects must be assigned to each journal?
6. Whether to journal after-images only or both before-images and after-images.
7. Whether your application programs must write journal entries to assist with recovery.
8. What type of disk pool in which to store your journal receiver?
9. Whether to use the remote journal function to replicate the journal entries and receivers to one or more additional systems.
10. Whether to omit the optional open, close, or force entries for your objects.

Journal Management Command

The IBM i provides command-line tools for managing journals and journal receivers. With these commands, you can create journals, start, and stop journalling, manage receivers, switch active receivers, delete receivers, and perform other journal-related tasks.

• CRTJRNRCV: Use this command to create a journal receiver.
• CRTJRN: Use this command to create a journal.
• STRJRNPF: Use this command to start journaling for the physical file.
• DSPJRN: This command displays or prints the journal entries that are in the journal receivers associated with the specified journal. This command has outfile support so you can list the journal entries to a database output file for further processing or analysis.
• DSPJRNRCVA: Use this command to display the attributes of a journal receiver.
• CHGJRN: Use this command to change the attributes of a journal or to attach new journal receivers to a journal.
• WRKJRN: This command displays a menu from which you can perform many journal-related functions, such as the system-assisted recovery of journaled files.
• WRKJRNA: This command displays the attributes of a journal and the associated receivers.
• ENDJRNPF: This command ends journaling for the specified physical file.
• DLTJRN: Use this command to delete a journal.
• DLTJRNRCV: Use this command to delete a journal receiver.
  

Conclusion

A journal management system allows you to keep track of all the changes to a database file. You can then use the journal for recovery. Overall, journal management in IBM i/AS400 Systems is an essential aspect of data integrity, auditing, and recovery in the system. It helps organizations track and protect critical information, maintain data consistency, and enable efficient recovery in the event of failure or errors.