Journaling - *RMVINTENT: The preferred fork in the road for heavy journal traffic
Note: This is publication is now archived. For reference only.
Published 22 May 2006
View online
Authors: Hernando Bedoya
Abstract
Shops using remote journal have often found it particularly helpful to put a “fork in the road” thereby separating the resulting journal entries into two streams: those destined for the target side and those not. Configuring your journal in this fashion can save both disk space and transmission bandwidth.
Written by Larry Youngren and Christopher Kundinger
Contents
Two streams of journal data
*RMVINTENT, an often underutilized journal feature, enables you to separate your journal activity into two separate streams. One stream houses the normally visible journal entries. The second houses normally hidden journal entries. These two streams serve two quite distinct purposes.
The visible stream encompasses the journal entries produced to show before-and-after images of modified database row images. The normally hidden stream encompasses journal entries that are employed only at IPL time to recover the structural integrity of keyed access paths. The first stream is useful on a target machine. The second stream has no practical purpose on a target machine and hence is better left unsent.
Use of the RCVSIZOPT(*RMVINTENT) setting on a CHGJRN or CRTJRN command can help influence the route associated with the second stream, thereby instructing the journal to only send journal entries needed (i.e., the first stream of data) to the remote journal.
Although use of the *RMVINTENT journal attribute is almost always a wise choice in a remote journal environment, the question often arises: “How many fewer bytes am I going to refrain from sending down my communication line if I configure this option? (That is, is it really worth the effort?)”
This Technote lays out an approach for answering that question.
By how many bytes could I have reduced my journal receiver size if I had enabled *RMVINTENT?
The following steps answer that question:
1) Provided you have a journal that isn’t already employing *RMVINTENT, start by displaying the Journal to an outfile:
- DSPJRN JRN(LIB/JRN) OUTPUT(*OUTFILE) INCHIDENT(*YES) OUTFILFMT(*TYPE5) OUTFILE(LIB/OUTFILE)
Note: We deliberately specified INCHIDENT. Unless you specify INCHIDENT(*YES) on the DSPJRN CL command, you will not be able to see the hidden entries we are trying to refrain from sending.
2) Examine the resulting outfile with the following SQL query:
- SELECT SUM(JOENTL) FROM LIB/OUTFILE WHERE JOCODE = 'I'
Note: By specifying JOCODE = ‘I’ you are isolating your view to only the journal entries associated with the structural content of keyed access path indexes (the kinds of journal entries that make up the bulk of hidden entries).
3) In order to make a size comparison, we need to know how much total data resides within the journal receiver. To ascertain that answer we can run the following SQL query on the same outfile:
- SELECT SUM(JOENTL) FROM LIB/OUTFILE
Using this result and the previous one (divide the first result by the second) you can get a feel for the percent of data that can be reduced with *RMVINTENT.
Enabling the fork in the road
To enable this option, issue the following CHGJRN command against your source journal:
- CHGJRN JRN(LIB/JRN) JRNRCV(*GEN) RCVSIZOPT(*RMVINTENT) JRNRCV(*GEN)
When you have such a fork in the road, the hidden entries are written to a separate area on disk that enables the journal to perform a valuable task: aggressively recycling this space. Thus hidden entries residing here free up the disk space they occupy as soon as the underlying IPL recovery mechanism no longer needs them. The result is that such journal receivers normally consume far less disk space than had the fork in the road not been present.
Why would you not want to enable *RMVINTENT?
Great question. There is not a good reason not to use *RMVINTENT. It can be argued that there is a slight bit more computing where the road splits and during the recycle phase but this can be greatly outweighed by the benefits. In fact, because this is such a good option, it has become the default for newly created journals in V5R4.
If you have journals created prior to V5R4, you probably will want to insert the fork in the road yourself.
Related question: Why did the size of my journal receiver shrink when I performed a CHGJRN operation?
This is a common question among customers who use a fork in the road. The space oscillation witnessed for journal receivers can be explained by the presence of the *RMVINTENT option. As stated above, this option will divide the Journal entries into two categories. The second stream, being useful only during IPL, also has a limited shelf life. When a file is closed, the risk of IPL recovery is diminished and hence the journal entries providing such protection no longer serve a useful purpose. As a consequence, the space they consume is flagged as eligible for recycling. Such recycling often ensues when a CHGJRN operation takes place. As a consequence, the overall size of the journal receiver shrinks.
In a similar fashion, the act of saving the contents of a journal receiver to a tape recognizes the difference between visible entries that might be of interest during a subsequent recovery operation and those that are hidden and eligible for recycling. If the *RMVINTENT option has been specified, the hidden entries are not written to tape; hence the SAVOBJ operation completes more rapidly and takes up less space on tape.
Conclusion
Whether your desire is to save space on tape at save time, save disk space at run time, or merely to refrain from clogging your communication line in a remote journal environment, the use of *RMVINTENT to place a fork in the road can be a powerful and impressive tool.
Special Notices
This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.