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:

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 REALOLDSAVEClosed To use an environment variable: On UNIX, $variableName; On Windows, %variableName% . 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:

  • Because T-DUMP and ST-DUMP are English commands, they decrypt encrypted data before saving to tape. However, the data on the tape can be encrypted by using a encrypted tape device.
  • The record size used with encrypted tape devices must be a multiple of 8.

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:

  1. Enter Q  to exit the save and return to TCL.
  2. Load another tape and repeat the save procedure.
  3. If the message still occurs, clean the tape heads. Refer to the cleaning instructions for your tape unit.
  4. Repeat the save procedure using a tape known to be in good condition.
  5. 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.