Notes on Save and Restore
Reality Files on Foreign Databases
Although these files can be saved using the Reality save commands, it is unlikely that you would want to do this. If a Reality application is storing its data on a foreign database, it is recommended that this data is secured by saving the SQL database in whatever way is appropriate.
If you do save a file on a foreign database using a Reality save command, the File Definition Item is saved with no amendments, so that when the file is restored it is restored onto that foreign database.
It is possible to restore files saved from a Reality database onto a foreign database. Use the FDB-SET command to indicate that subsequent uses of restore commands should restore files onto the specified foreign database.
Excluding Accounts/Files from Backup
To save time and tapes, before running a FILE-SAVE, you should check to see if there are any accounts, files, or data sections of files that can be excluded from the backup. Typical examples of this are:
- Static files/accounts, that is, those with contents that do not change. If you make one tape copy of these, you can then exclude them from the regular FILE-SAVE backup.
- Special accounts saved by their owners.
- Files containing batch-type data which does not require saving. You can save the dictionary without the data.
To exclude an account or file(s) from a FILE-SAVE, use EDITOR or Screen Editor to modify the appropriate definition item, as described in the following table.
To Exclude: | Procedure: |
---|---|
A complete account | Append an X to attribute 1 of the account definition item. Use ED or SE SYSTEM account-name. |
A file (DICT and all data sections) | Append an X to attribute 1 of the file definition item. Use ED or SE MD file-name from the account on which the file is defined. |
Data from all data sections of a file (and save the empty data sections) | Append a Y to attribute 1 in the file definition item. Use ED or SE MD file-name from the account on which the file is defined. |
Data from one data section (and save the empty data section) | Append a Y to attribute 1 in the data level descriptor for that data section. Use ED or SE DICT file-name data-section-name from the account on which the file is defined. |
Note
You cannot exclude account, files or data sections from a physical save.
Transferring Data between Different Versions of Reality
Reality 8.1 introduced a new hashing algorithm that can better handle item IDs longer than 28 characters. Reality saves taken from databases that use the new hashing algorithm are incompatible with older versions of Reality (Reality 8.0, RealityX and proprietary Reality on Series 18/19 hardware), because the group numbers on the save will not match the older hashing algorithm.
If you need to restore a save from Reality V9.0 or later onto an earlier version of Reality, you can produce a save that is compatible with the earlier version by setting the environment variable
. This will cause the resize field (if empty) to be set to the true file size, and the true file size to 1,1. This will force the older system to always do a resizing file restore, thus ensuring that the tape is read correctly. The resize field will not be modified if it is not empty.File saves taken from earlier releases of RealityX or Series 19 will restore onto a Reality database that uses the new hashing algorithm without difficulty. However, because the hashing algorithm has changed, the restore will take longer than usual.
Notes:
- A patch is available for RealityX 5.0 to enable it to read a standard file save from a database that uses the new hashing algorithm. This patch should be installed if file saves will continually be moved between V9.0 or later and RealityX 5.0.
- Moving data between a database on Reality V9.0 or later and a pre-7.0 Reality database (for example, Release 5.3 or 6.0) requires the use of migration utilities described in the User's Guide to the Reality Migration Utilities.
Data Encryption
None of the save procedures described in this section, whether logical or physical, decrypt encrypted data before saving to tape. Refer to Copying Encrypted Data to another Host for details of how to restore encrypted data.
Notes:
Error Messages
The following error messages may appear on the screen when carrying out save procedures.
Write Error
Tape operation failed (after retries) Bad Tape - unable to continue. Type "Q" to Quit
This message is displayed when a write failure occurs during a save procedure such as, ACCOUNT-SAVE, FILE-SAVE, F-S, M-A-S or SAVE, and indicates that the tape or tape unit is probably faulty. Proceed as follows:
- Enter
Q
to exit the save and return to TCL. - Load another tape and repeat the save procedure.
- If the message still occurs, clean the tape heads. Refer to the cleaning instructions for your tape unit.
- Repeat the save procedure using a tape known to be in good condition.
- If the message still occurs, call NEC Software Solutions.
Missing Data
If the system detects missing data during a VERIFY-SAVE, the following message prompt is displayed:
(C)ONTINUE, (R)ESYNCHRONISE, OR (Q)UIT
You can enter one of the following:
C
Causes the next tape segment to
be checked and you are informed whether or not the verify-save can continue from
that point.
R
Causes the system to
check the next (and subsequent) tape segment(s) for errors, and begins
verification from the next good segment. You are not informed if there are any
intermediate bad segments.
Q
Stops the verification
and returns to the TCL prompt.
Read Error
Tape operation failed (after retries) (A)CCEPT (R)ETRY, (D)ISPLAY, OR (Q)UIT
This message is displayed when a read failure occurs, for example, during VERIFY-SAVE, indicating that there is an error (such as a parity error) in the data. You can enter one of the following:
A
Continues with the
verification procedure.
R
Retries the data in
error.
D
Displays the data item
in error.
Q
Stops the verification
and returns the TCL prompt.