Professional Documents
Culture Documents
Filtering capabilities, automatic restart, and more! IBM i 7.1, officially released last April 23, provides enhancements that help ensure System i will be a robust and reliable platform for many years to come. One of the greatest features of IBM i 7.1 is its capability of journaling and remote journaling, the cornerstones of many high availability (HA) solutions currently available on the market. This article examines the IBM i 7.1 enhancements to journal and remote journal and includes practical examples.
On this new release, when you're journaling libraries using the Start Journal Library (STRJRNLIB) command, you can now select or omit objects to automatically start journaling based on the name of the object (name filter). This allows you to automatically start journaling new production files in the library (but not journal temporary work files if they are named uniquely). The name filter support is available via the INHRULES parameter for the STRJRNLIB and Change Journaled Object (CHGJRNOBJ) commands. You may specify both include and omit filters. The order in which the filters are implemented matters: the last filter defined for the object is the one applied. The name filter rules apply to objects that are created, moved, or restored to the specified library. Renaming an existing object after the filter rule is implemented will cause journaling to not start for this object. The following code will start journaling for all objects added to the library except files whose names start with WRK or TMP. STRJRNLIB LIB(MYLIBD) JRN(MYLIBA/JRN) INHRULES((*ALL *ALLOPR *INCLUDE *OBJDFT *OBJDFT *OBJDFT *ALL) (*FILE *ALLOPR *OMIT *OBJDFT *OBJDFT *OBJDFT WRK*) (*FILE *ALLOPR *OMIT *OBJDFT *OBJDFT *OBJDFT TMP*))
1/9
On this new release, the operating system will attempt to restart the remote journal after a recoverable error. You can specify the number of attempts to be made and the time delay between them (in seconds) using the Change Remote Journal (CHGRMTJRN) command or the Change Journal State (QjoChangeJournalState) API. The restarts will happen in the QSYSWRK subsystem under jobs named QJORESTART. If restarts happen, message CPI7027 will be sent to the journal message queue for each attempt; if all restart attempts fail, message CPI7028 will be sent to the journal message queue. The following code will attempt a restart 20 times, every 60 seconds. CHGRMTJRN RDB(MYSYS) SRCJRN(MYLIB/JRN) TGTJRN(MYLIBT/JRN) JRNSTATE(*ACTIVE) DELIVERY(*ASYNC) RESTART(20 60) You can verify the maximum restart attempts associated with a remote journal by entering the following command and selecting PF16 and then option 5=Display remote journal details. WRKJRNA JRN(SSCABRAL/JRN)
2/9
Figure 1: Verify restart attempts. (Click images to enlarge.) Another associated an easy way important with to do a particular addition this. in remote this release journal. is None the capability of the previous to verify operating the total retransmissions system releases had From the above screen, page down twice to the following screen:
3/9
4/9
- Before imagesfor files and data areas, even before images in R/DL (Record deleted in the physical file member) and R/DR (Record deleted for rollback operation) entries - Individual objectsfiles, data areas, data queues - Program nameswith qjoChangeJournalState API only Before Images This remote journaling filtering criteria will allow before image journal entries to not be sent to the remote journal. This is especially useful when the local journal has applications using commitment control, which require before images to exist on the source system for rollback operations. On the target system, the before image journal entries may not be of any application, so implementing this filtering option should enhance the throughput between source and target systems. CHGRMTJRN RDB(HERA1A) SRCJRN(TEAM77/JRN) TGTJRN(TEAM77A/JRN) JRNSTATE(*ACTIVE) DELIVERY(*ASYNC) FTRIMAGES(*BEFORE) Note: You cannot use a before image filtered receiver for the RMVJRNCHG command because it needs the before images to roll back the changes. The remote journaling filtering rules can be verified by using the following command and selecting PF18. WRKJRNA JRN(TEAM77A/JRN)
5/9
Figure 3: Verify remote journaling filtering rules (no filtering by object, filter before images).
Individual Objects This remote journaling filtering criteria indicates which journal entries associated with a given object are not to be sent to the remote journal. The default is off (i.e., by default, all entries associated with a journaled object will be sent to the remote journal). The object attribute indicates that journal entries for it should be filtered with remote journaling. The object filtering criteria can be implemented via CHGJRNOBJ or the INHRULES on STRJRNLIB commands . CHGJRNOBJ OBJ((LIBA/WRKFILE *FILE)) ATR(*RMTJRNFTR) RMTJRNFTR(*YES) CHGRMTJRN RDB(CHICAGO) SRCJRN(LCLLIB/JOURNAL1) TGTJRN(RMTLIB/JOURNAL1) JRNSTATE(*ACTIVE) FTROBJ(*YES)
6/9
The remote journaling filtering rules can be verified by using the following command and then PF18. WRKJRNA JRN(TEAM77B/JRN)
Figure 4: Verify remote journaling filtering rules (filtering by object, no filter images).
Program Names This remote journaling filtering criteria indicates which journal entries deposited on behalf of any program(s) should not be sent to the remote journal. It is implemented via the qjoChangeJournalState API using the format CJST0500 (find information about the qjoChangeJournalState API in the Infocenter ). You cannot use a filtered receiver for APYJRNCHG when journal receiver entries were filtered
7/9
by object or program, but before-image filtering is allowed. Remote Journaling Latency Replicating a journal entry asynchronously means that the journal entry is replicated to the target system after control is returned to the application depositing the journal entry on the source system. Journal entry latency might occur when remote journals are asynchronously maintained (Remote Journal Delivery Mode = *ASYNC). Journal entry latency is the difference between journal entries existing in the remote journal on the target system and those residing in the journal on the source system. From a recovery standpoint, the source system might be some number of journal entries ahead of the journal entries on the target system. In this new release, active asynchronous remote journaling on the target system will now report an estimate of how many hundredths of a second it is behind, the maximum time behind since the connection was started, and when that maximum time behind occurred. Use the following command: WRKJRNA JRN(TEAM77B/JRN)
8/9
9/9