Saving Private Info

V5R4 delivers functionality and performance enhancements to the journaling facility.

V5R4 delivers functionality and performance enhancements to the journaling facility.

Journaling is a critical function for many IBM* System i* customers. Journaling allows the System i platform to perform commitment-control operations and object recovery in the event of an outage, as well as provide detailed auditing records showing changes to the data. In this article, I'll outline many of the journaling facility's changes and new features introduced in i5/OS* V5R4.

Maximum Objects Per Journal

With V5R4, journals can now support up to 10 million objects per journal, up from 250,000 with V5R3. This is especially important for shops using popular ERP packages that often have libraries nearing the former 250,000-object limit and for shops using packages that tend to create new byte-stream files on the fly, since such packages regularly attempt to create millions of such byte-stream file objects. To allow a journal to grow beyond 250,000 objects, the new Journal Object Limit (JRNOBJLMT) parameter must be set to *MAX10M on either the Create Journal (CRTJRN) or Change Journal (CHGJRN) command. Once set to *MAX10M, the object limit can't be set back to *MAX250K. Also, once set to *MAX10M, the associated journal receivers can't be saved and restored or remote journaled to a target system lower than V5R4. No appreciable performance problems are related to simply setting a journal to be capable of growing to 10 million journal objects. However, the journal IPL recovery-processing times for such a journal grow exponentially, not linearly, when the number of journaled objects in need of recovery grows to a high value.

On the initial Work with Journal Attributes (WRKJRNA) screen, a summary of the number of items journaled and the maximum for that journal is shown in the right-hand column. To help manage and effectively view the larger number of objects journaled, a new option was added to the WRKJRNA, Display Journaled Objects (F19) screen. Option 40 will now show a summary of the count of each object type that's journaled. Keep in mind some subtle internal journaled objects such as journal receivers and some SMAPP-protected access paths aren't listed on this screen so the sum may not add up to the total on the first page.

QDFTJRN Enhancements

The QDFTJRN data area introduced with V5R3 is enhanced in V5R4. It allows users to control the automatic journaling of new database files when being created into a schema or library. With V5R4, the data area supports not only database files and SQL tables but also data queues and data areas. Also, instead of initiating journaling for such objects only at create time, these objects can be set to be automatically journaled when restored to or moved into the library or schema. When creating the QDFTJRN data area, the first 10 characters (positions 1 to 10) must be the journal's library in uppercase and the second 10 characters (positions 11 to 20) must be the journal name in uppercase. What follows are sets of tuples of data types and operations. Each of the two elements of the tuples must be in uppercase and on a 10-byte boundary (positions x1 to (x+1)0 - i.e., 21 to 30). The first element is the data type: *FILE, *DTAARA, *DTAQ, *ALL or *NONE (prevents automatic journaling even in schemas). The second element is the triggering option: *CREATE, *MOVE, *RESTORE or *ALLOPR.

Change Receiver Threshold

Prior to V5R4, if the journal receiver's threshold needed to be changed, a new journal receiver with the new threshold needed to be manually created with Create Journal Receiver (CRTJRNRCV) and then attached to the journal using the CHGJRN command. With V5R4, this can be done at the same time using only CHGJRN. By using CHGJRN with a Journal Receiver (JRNRCV) parameter set to Generate (*GEN) and the new Journal Receiver Threshold (THRESHOLD) parameter set to a valid value, the newly generated journal receiver is created with the new threshold value instead of inheriting the old value. This saves the hassle of manually creating the journal receiver first.

Minimized Entry-Specific Data

When a journaled file is changed, one or two copies of that record are written to the journal. Often, only one or a few fields are changed inside that record, which causes additional space to be taken up by non-changed fields in the entry-specific data section. By turning on minimized journal entries support for files, the system saves only the information from fields that changed. However, this data was broken up on internal byte boundaries and compressed, making it unreadable to humans. This lack of auditability prior to V5R4 of the record changes often forced users to not use this functionality.

With V5R4, the data area has been enhanced to support not only the database files and SQL tables but also data queues and data areas.

Robert Andrews is an advisory software engineer with IBM Global Services. Robert can be reached at



2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters