I was asked about the ability of our products to filter content within a journal. The problem is a common problem and one which affects us due to our policy of applying everything within the journal (some products will create a list of objects which is used to determine the need to apply journal content, we did not like that idea as we feel it is far more important to filter on the source than the target. After all why send across copious amounts of data just to ignore it?).
We have Object filters built in so that we can ignore certain objects within a library as part of the Audit Journal replication process but we cannot determine what is journaled on the source as we do not intercept the STRJRN requests. It has also become a common practice to use either the QDFTJRN Data Area or the STRJRNLIB command as a method of capturing the creation of new objects within a library and making sure they are journaled to the same journal used for the High Availability replication process. The reason for using these functions is to remove the possibility that some objects are not missed because of a programmer creating something and not adding it to the journal. There are lots of discussions I could have about the why this is wrong, but that’s for another day.
The STRJRNLIB is what most people should use, IBM has declared its intention to sunset the QDFTJRN method at sometime in the future. When you run the command there is the ability to set a number (20) of inheritance rules (rules which are applied to the object in terms of journaling) which allows you to set which objects are journaled and those which are not. Using these rules it is possible to add filters to the objects which are journaled so ignoring things like work files etc is possible. This ensures objects which are not required to be on the target are not journaled, saving the effort required to replicate them to the target and the bandwidth associated with sending across data which is just going to be ignored anyhow (I like that better than just ignoring it on the target using filter lists).
One important point you need to know is the LAST entry an object matches is used to determine its inclusion in the journal. When we developed filtering processes we always look for the FIRST match, that way we are not looking through list entries which may not be relevant, but IBM has done it differently. We should have read the manual first as it clearly states this, but as usual we were busy doing tests on the command line way before we looked at the manual :-). Once we had figured that out we successfully started journaling to the library and saw the filters worked as expected.
Here are the steps we took to set up a test where a library would be journaled to capture all operations against all objects but exclude the work file entries which just happened to start with WRK.
STRJRNLIB LIB(LVLT_DTA1) JRN(LVLT_JRN1/LVLTJRN) INHRULES((*ALL *ALLOPR *INCLUDE *OBJDFT *OBJDFT *OBJDFT *ALL) (*FILE *CREATE *OMIT *OBJDFT *OBJDFT *OBJDFT WRK*))
CRTPF FILE(LVLT_DTA1/WRKFILE) RCDLEN(100)
CRTPF FILE(LVLT_DTA1/CHRISH1) RCDLEN(100)
CRTDTAARA DTAARA(LVLT_DTA1/WRKDTA) TYPE(*CHAR) LEN(1)
The test showed that the WRKFILE object was not journalled but the CHRISH1 object was and so was the WRKDTA dataarea.
So if you are running a High Availability / Disaster Recovery solution and want to be able to capture most objects to a journal on create but ignore others the above solution gives you an idea where to start.
Chris…