Object replication is standard in High Availability products and is provided using a variety of technologies that capture the change of an object and trigger a replication request. In our RAP product we use the Audit Journal to capture the changes and use our own replication tools to copy and restore the object to the target system.
This is all well and good for us as we have the in house skills to create the replication programs, what about those smaller shops who have no such skills? Usually they would have to rely on a process which will save an object to a save file, send it to the remote system and restore it on the remote system. FTP doesn’t work any better because you still have to save the object to the save file and FTP it before restoring it again from the save file, FTP of i/OS objects such as files,programs etc is not allowed..
There is a solution, we had recently looked at the Object Connect programs as the transport method, but it seemed like it required Opti Connect to be installed for it to work! We sent a request off to IBM asking for a change to allow normal TCP/IP devices to be used to carry the request as not many smaller shops could afford to run opti-connect! IBM came back and said this functionality was already provided in the OS in the form of the Enterprise Extenders.
A little research later and we now have objects being saved from the source system and restored to the target automatically, it even has library re-direction built in! Now there are some caveats with the process (there usually are) such as message queue content and data queue content is not carried across as part of the transfer, but thats no big deal for most shops.
Enterprise Extenders are touted as IBM’s replacement for AnyNet support, it allows APPN traffic to flow between systems over a TCP/IP network. To set this up between two of our systems we just had to configure the network attributes, create a controller on each system and the use commands to replicate the objects and it all worked. We created the link between our SHIELD2 and SHIELD3 systems using the following steps
First we changed the network attributes to support HIPR.
CHGNETA LCLCPNAME(SHIELD2) LCLLOCNAME(SHIELD2) ALWHPRTWR(*YES)
CHGNETA LCLCPNAME(SHIELD3) LCLLOCNAME(SHIELD3) ALWHPRTWR(*YES)
Then we created the controllers on each system
CRTCTLAPPC CTLD(APPCCTL) LINKTYPE(*HPRIP) RMTINTNETA(SHIELD3) RMTCPNAME(SHIELD3) USRDFN1(128) USRDFN2(128) USRDFN3(128)
CRTCTLAPPC CTLD(APPCCTL) LINKTYPE(*HPRIP) RMTINTNETA(SHIELD2) RMTCPNAME(SHIELD2) USRDFN1(128) USRDFN2(128) USRDFN3(128)
After varying on the controllers we tried out a replication request from Shield2 to Shield3.
SAVRSTOBJ OBJ(FILEb) LIB(RAPDTA2) RMTLOCNAME(APPN.SHIELD3) OBJTYPE(*FILE)
The object was successfully saved and restored to the target system without any problems!
Looking at the process it looks like IBM is using a save and restore process but in the manuals it states the object is not interrupted by the process, we take that to mean it is not locked but we have yet to prove that! The process was certainly slower than our replication process but in the end it works! This solution can be used on any V5R4 or upwards system and is probably a lot better than using a FTP process where you are saving and restoring the object around the FTP request. I think this will add another element to the HA on a Shoestring process which looks after the replication of journal data, you will of course have to build a method of detecting object changes but at least the save and restore to the remote system is handled for you.
We did try to find out where the Enterprise Extenders were installed (LPP?) but could not find any information, however you do have to specifically install the Object Connect LPP option for this to work at the very least.
Hope that adds another interesting option to those do it yourself DR projects out there who need to be able to add object replication to their journal replication set up!