After some difficulties we have now managed to create an IFS replication process which allows IFS objects to be replicated from one system to another using a selection panel on the source system. This is the start of the new IFS replication process which we expect to replace the Journal based replication used by RAP today.
The reason for the new technology is to allow a new filtering functionality we are testing to function correctly. One side effect of the RAP technology is the locking of all journalled objects on the target side by the IBM APYJRNCHG process. If you have many libraries associated with the target journal this could create some conflicts so we have developed an alternative process which allows the libraries to be defined for the APYJRNCHG request. This in-turn creates its own side effect because the IFS entries are ignored when the technique developed is used. So we needed to have an alternative IFS replication process which would sit alongside the Object replication process available in V4R1 of RAP.
After many hours of resolving what in the end turned out to be stupid coding issues we now have a fully working solution which allows single objects to be selected on the source and not have to worry about the path on the target, it is built automatically to allow the restore to work. This functionality will be included as a standalone command and interface within the product but will also form the basis of the automated IFS replication routines we will build.
The new functionality will be added in the next PTF which should be available at the end of this quarter.
Chris…