[adrotate group=”3,7,8″]
One of the major concerns we see from HA installations is the bandwidth that is required to send the data from the source system to the target system using the remote journal process. Its not that the remote journal function is adding lots of overhead to the journal data but that a lot of people imply do not understand what you can do with a remote journal. So here is a quick overview of the actions you should take to reduce the bandwidth overhead between the systems for remote journalling.
1. The journal was not developed for transporting data between systems, it was developed as a tool which could be used to rebuild the system in the event of a failure. This is the reason you can use that same data to keep the data in synch between systems but it has a lot of information which is simply not required just for updating that data. As part of this the journal also carries a LOT of data about access paths, it requires this data to ensure the IPL times are kept to a minimum, if you have a system failure and access paths were not journaled you could be in for what they say is “the long wait”. But that information is not required or used on the target system for your HA product so the first things you should do is tell the remote journal function to ignore it! This just requires the *RMVINTENT setting on the journal to achieve and from V6R1 onwards is automatically set when you create a new journal. The problem is most companies have migrated old journals so the condition will not be set. This could save you a lot of bandwidth especially in customers who have large files and lots of logical files built over them (most ERP customers have this without question).
2. The journal can be setup to capture both before and after images, the standard today for all HA software is to only require the *AFTER image. If you have commitment control the OS forces you to use *BOTH for any object which comes under commitment control so it will set it automatically to *BOTH.
3. The journal adds a further 96 bytes of data to every entry in the journal, 56 bytes of this is not required on the target system by the apply processes and can be discarded without any problems. To remove these 56 bytes of data simply change the journal to use *MINFIXLEN in the RCVSIZOPT setting. For users with millions of entries being transported per hour this can significantly reduce the bandwidth requirements. This setting also improves the journal performance because it reduces the overhead required to collect the data, specifically the program information.
4. There is one other setting which can be used to reduce the amount of data being transferred, this is the MINENTDTA setting. This will tell the journaling function to only store the changed data in the journal entries and not the entire record. For those with applications that do a lot of updates this can reduce the data stored but those applications that do mostly adds its probably not going to show much improvement because the entire record is new. If you are not going to need to see the data in the journal entries use the *FILE and *DTAARA settings as this should give the biggest benefit. Using *FLDBDY will allow the data to be seen at the field boundary so there will still be some padding in the data.
Once you have done all of this you should see some significant gains in the bandwidth requirements. If you have already these setting you are on the right track, make sure you are using the new *MAXOPT2 setting or greater as this provides some performance improvements for journaling as well.
Chris…