If you plan to replay the integrated file system operations in the remote journal to objects on the target system, and if you primed that target system with objects that were restored from the source system, then some additional considerations apply to replaying those journal entries.
Integrated file system journal entries on remote journals are only identified by the file identifier in the object name field. They are not identified by path name. When you restore an integrated file system object on a remote system, the remote system does not maintain the same file identifier that was used on the source system. It assigns that object a new file ID. However, the journal entries in the remote journal receiver refer to that object's original file ID. Therefore when you replay the journal entries you cannot use the file ID on the remote journal to find the path of the object. That file ID will either not exist or be the file ID for the wrong object.
To prevent potential problems, it is recommended that you create a table that maps the old and new file IDs with the object's path. The map can be something like the following table:
| Object path | Source file ID | Target file ID |
|---|---|---|
| /myFolder/subFolder/MyObject | 123456... | 789123... |
| /myNextFolder/anotherFolder/MyObject2 | 654321... | 321987... |
You can use different methods to determine the file IDs:
If an object is journaled when you restore it to the target system, a B FR journal entry is deposited on the target system's local journal receiver. The entry-specific data of the B FR journal entry contains the following:
If you are concerned about the demand that journaling puts on the remote system's resources and storage space, you can put the journal in *STANDBY state. Even though the journal is in standby state, the system still deposits B FR entries.
On the source side, if you know the object's path but do not know its file ID, you can use the Qp0lGetAttr() API to get the file ID. This is especially helpful if you do not want to use journaling on the remote system. You then need to send that information over to the target system to update the table which must exist on the target system.
On the source side, if you know the object's file ID, but do not know it's path, you can find it using the Qp0lGetPathFromFileID() API. You can then use this path to replay the journal entries on the target system, assuming that the path on the target system is the same as the path on the source system. This API will only return an absolute path name of the object. If the object has more than one path name, the API only returns one path. You then need to send that information over to the target system to build the table which must exist on the target system.
Once you have the table created, you must keep it updated. One way to keep the table updated is to update the table as the replicator job applies journal entries. On the target system, when the replicator job applies entries to do operations such as creating objects, adding links, or removing links, the journal entry information in these entries has the path name and file ID in it at that time. As the operation is replayed you can use this information to build the table on the target system.