Four tips for reducing journal size
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In the first three parts of this series on journaling we discussed how to manage and use journals to maintain data integrity, but we didn't give much thought to the physical size of the objects involved in journaling. Let's now take a quick look at how you can help minimize journal and journal receiver sizes.
Journal objects are only definitional objects; that is, they contain only a definition and not expanding amounts of data. Therefore, journal objects maintain a constant and very minimal size.
What can we do about object sizes? Plenty. If you recall, journal entries are written to journal receivers, so journal receivers are always expanding. There are several ways to reduce the size of your journal receivers. Most have to do with omitting certain types of entries or eliminating some of the information in the entries. If DASD is tight on your system, here are some things you can do to cut down on space requirements for journals and journal receivers:
- Specify OMTJRNE(*OPNCLO) on the STRJRNPF command when you start the journaling for a file.
By default, each time a program opens and closes a journaled file, the system records "OP" and "CL" entries. By specifying OMTJRNE(*OPNCLO), you will block the system from recording those entries (which are usually used only for security auditing purposes).
- Specify IMAGES(*AFTER) on the STRJRNPF command to record only after images.
You can configure journaling to record both a before image and an after image of any record that is updated. That is, the journal records a copy of the original record before it is actually updated in the file (before image) and a copy of the record as it appears after the update (after image). The default is after images only, and that is what you should use unless you have a specific need for the before images.
For the disaster recovery process we discussed in Part III of this series, only after images are necessary. Commitment control requires before images, but the system will start recording them automatically when commitment control is started and will cease recording them when commitment control is ended. You can use IMAGES(*BOTH) to manually record both before images and after images.
- Use RCVSIZOPT(*RMVINTENT) on the CHGJRN or CRTJRN commands.
This causes the system to automatically remove internal entries once they are no longer needed. For example, during IPL the system logs an entry to each journal, indicating whether the system is IPL-ing after a normal or abnormal end. After the next IPL, the entries associated with the previous IPL are no longer needed, and the system will automatically delete them if you specify RCVSIZOPT(*RMVINTENT) on the CHGJRN command when you create the journal. (You can also use the CHGJRN command to change an existing journal.) Note: Don't look for any miracles here. These internal entries represent a tiny fraction of all the entries of an normal active journal.
- Use RCVSIZOPT(*MINFIXLEN) on the CHGJRN or CRTJRN commands.
When *MINFIXLEN is used, the system shortens journal entries by not writing out the job, program and user profile information that normally accompanies each journal entry. This trick can add up to big DASD savings, since 46 bytes will be shaved off of each entry. Note: The job, program and user profile information is used for security auditing purposes, so you do not sacrifice any data-recovery abilities by not having them in the journal entries.
On a final note, remember that these techniques are not mutually exclusive. You can use any combination of them to fit your needs.
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.