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

Enscribe Queue File Issues
For ENSCRIBE queue files, a different method of obtaining the fuzzy copy is required. You must
use the FUP COPY command with the SHARE option specified, and with “FIRST 1” specified.
For example, the following command copies the contents of file QUEUE1 to QUEUE2.
FUP COPY QUEUE1, QUEUE2, FIRST 1, SHARE
To ensure that your target file, QUEUE2 in the above example, has the proper content, copy the
content of the target file to the screen by using the following command:
FUP COPY QUEUE2,, H
If the file is empty and contains zero records, you must reissue your original command again,
and recheck the contents of the target file.
FUP COPY QUEUE1, QUEUE2, FIRST 1, SHARE
FUP COPY QUEUE2,, H
The target file, QUEUE2 in this example, is not ready for synchronization until it has at least one
record in it. Therefore, you might need to repeat the above operation until a record appears.
You could also copy the empty file to the backup system, insert a record into the file on the
backup system, and delete the inserted record:
1. Start a transaction, do a WRITE to the empty queue file, and commit the transaction.
2. Start a new transaction, do a READUPDATELOCK on the record, and commit the transaction.
This procedure pops the inserted record from the file, but leaves the special “dummy” record
in the 0th position. You must do this operation before you start RDF updating.
For information about the special “dummy” record in Enscribe Queue Files, see the information
about queue files in the Enscribe Programmer’s Guide.
Different NonStop SQL/MP Product Versions
If you have different versions of the NonStop SQL/MP product on your primary and backup
systems, see the SQL/MP Version Management Guide for information about what you can do and
how to do it.
Three of the more common issues are:
• If your primary system has a higher version of the NonStop SQL/MP product than the
backup system, then the tables on the primary system must not make use of features not
supported by the lower product version. Failure to comply with this will result in errors
when attempting to create the duplicate tables.
• You can create the duplicate tables on the backup system and then load them over the
network from the primary system, but you must be knowledgeable about issues regarding
differences in table and catalog versions. See the SQL/MP Version Management Guide.
• You can create and load the duplicate tables on the primary system and then move them to
the backup system using SQLCI DUP commands or BACKUP/RESTORE and tapes. In either
case, however, the tables must be registered in a catalog on the backup system. Again, you
must be knowledgeable about issues regarding differences in table and catalog versions.
See the SQL/MP Version Management Guide.
Moving Duplicated Tables and Files to the Backup System
If you created the duplicate files and tables directly on the backup system and loaded them from
the primary system, you can start the RDF updaters without any further considerations.
If you created the duplicate files and tables on the primary system and then moved them over
to the backup system, however, you must be aware of the following:
• If you move duplicate partitioned Enscribe files whose volume mappings differ between
the primary and backup systems, you must use a FUP ALTER command to alter the file
160 Online Database Synchronization