RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

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
• Encounters a restart condition (for example, file system error 122)
• 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 ADD VOLUME 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” (page 273).
Use RDFCOM ALTER to turn off maplog logging. For example:
ALTER VOLUME $DATA01 MAPLOG
How an Updater Manages Filename Collisions 273