RDF System Management Manual for H-Series RVUs (RDF 1.8)

How an Updater Manages Filename Collisions
If you inadvertently map two subvolumes on the primary system to the same subvolume on the
backup system for an updater, the updater detects the filename collision, logs EMS event 927,
and abends. This approach prevents possible data corruption or disk failure.
To illustrate how a filename collision might occur, assume that the mapping string for the updater
that replicates from $DATA01 on the primary system to $DATA01 on the backup system is:
MAP NAMES TEST1.* TO TEST2.*
Assume that the file $DATA01.TEST1.FILE on the primary system is modified. RDF applies the
mapping rule on this file and replicates its changes to the file $DATA01.TEST2.FILE on the
backup system.
Next, the file $DATA01.TEST2.FILE on the primary system is modified. RDF determines that
the mapping rule does not apply. If RDF had to replicate the changes, they would be replicated
to the file $DATA01.TEST2.FILE on the backup system. If this situation occurred, changes to the
files $DATA01.TEST1.FILE and $DATA01.TEST2.FILE on the primary system would be replicated
to the same file, $DATA01.TEST2.FILE, on the backup system. Instead, RDF detects the filename
collision, logs error 927, and abends.
The updater might not be able to prevent filename collisions when it:
• Closes files on the backup system because their corresponding source files on the primary
system have not been modified for at least ten minutes
• Triggers a restart
• Undergoes a process takeover
• Is stopped with a user-supplied STOP RDF/UPDATE command
• Is stopped for other reasons
If the updater is restarted under any of these circumstances, it cannot detect a filename collision
until and unless the files from both subvolumes on the primary system that are mapped to the
same subvolume on the backup system have both been modified within ten minutes.
Creating a Maplog to Log Subvolume Name Mapping
Maplog is an optional EDIT file into which the updater logs source filenames from the primary
system and their mapped destination filenames on the backup system. The updater logs the
entry of the data file only once until the time that the data file is open on the backup system.
However, if the data file is closed and reopened on the backup system, the updater logs multiple
entries for the same data file.
If the maplog file already exists at the cold start, it will be emptied with a Purgedata operation.
If the maplog does not exist, the RDFCOM ADD and ALTER VOLUME MAPLOG commands
will create an empty maplog file on the backup system.
Use the RDFCOM SET command to specify the maplog filename and path in the updater's
configuration record, as described in “Adding a Mapfile and Maplog to an Updater's Configuration
Record”. You can turn off logging to the maplog by altering the maplog to none.
NOTE: The updater closes files on the backup system when their corresponding source files
on the primary system have not been modified for at least ten minutes. When this occurs, the
updater will also forget the filename collision information described in “How an Updater Manages
Filename Collisions”.
Use RDFCOM ALTER to turn off maplog logging. For example:
ALTER VOLUME $DATA01 MAPLOG
In this example, $DATA01 is the name of the volume on the primary system, and MAPLOG is
the keyword. Because MAPLOG is followed by end of line, it indicates that the maplog file on
the backup system be turned off.
How an Updater Manages Filename Collisions 267