File identifier considerations for working with integrated file system entries

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...

Collecting the information for mapping file IDs

You can use different methods to determine the file IDs:

Use local journaling on the target system where you restore the object.
Use the object's path to find its file ID with the Get Attributes (Qp0lGetAttr()) API on the source system.
Use the object's file ID to find its path with the Get Path Name of Object from Its File ID (Qp0lGetPathFromFileID()) API on the source system.

Using local journaling on the target system

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:

Media file identifier--the file ID of the object on the media. This file ID is the same as the object's file ID on the source system.
Restored file identifier--the object's new file ID after it is restored to the target system.
Restored over file identifier--the file ID of the object that was restored over.

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.

Using the object's path to find its file ID with the Qp0lGetAttr() API

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.

Using the object's file ID to find its path with the Qp0lGetPathFromFileID() API

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.

Maintaining the table as the replicator job applies journal entries

Once you have the table created, 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.

Parent topic:

Getting information about remote journal entries

Related tasks
Changing the state of local journals