Restores a database to the condition it was in at the time a
    full or incremental backup operation was performed with an
    RMU Backup command. In addition, if after-image journal (.aij)
    files have been retained, RMU Restore attempts to apply any pre-
    existing .aij files to recover the database completely. See the
    Description help entry under this command for details on the
    conditions under which RMU Restore attempts an automatic .aij
    file recovery as part of the restore operation.

    When you use the RMU Restore command to restore the database
    to a system with a more recent version of Oracle Rdb software,
    an RMU Convert command with the Noconfirm and Commit qualifiers
    is automatically executed as part of RMU Restore. Therefore, by
    executing the RMU Restore command, you convert that database
    to the current version. See the Oracle Rdb Installation and
    Configuration Guide for the proper backup procedure prior
    to installing a new release of Oracle Rdb and restoring (or
    converting) databases.

    When you use the RMU Restore command to restore a database that
    was recently RMU/Converted but with the /NoCommit qualifier,
    the behavior is different than that stated above. /Commit is
    the default for an RMU Restore of an uncommited database (a
    database that contains both current and previous versions of the
    metadata that was converted by specifying RMU/CONVERT/NOCOMMIT or
    RMU/RESTORE/NOCOMMIT) but ONLY if the noncommited database being
    restored is NOT of the current Rdb version. RMU/RESTORE/COMMIT
    and RMU/RESTORE/NOCOMMIT only take effect if RMU/RESTORE needs
    to call RMU/CONVERT because the database being restored is of a
    previous Rdb version.

    If the /COMMIT is specified or defaulted for the Restore of a
    database of the current level, it is ignored. In this case, an
    RMU/CONVERT/COMMIT must be used to commit the previous uncommited
    restore or conversion.

                                   NOTE

       When you restore a database, default or propagated OpenVMS
       access control entries (ACEs) for the database root (.rdb)
       file take precedence over any Oracle RMU database access you
       might have.

       Therefore, if default or propagated entries are in use,
       you must use the RMU Show Privilege and RMU Set Privilege
       commands after a restore operation completes to verify and
       correct the Oracle RMU access. (You can tell if default or
       propagated entries are in use because RMU Restore displays
       the warning message "RMU-W-PREVACL, Restoring the root ACL
       over a pre-existing ACL". This is a normal condition if the
       RMU Restore command was invoked from the CDO utility.)

       To use RMU Show Privilege and RMU Set Privilege commands,
       you must have the rights to edit the access control
       list (ACL) using RMU$SECURITY access (which is VMS BIT_
       15 access in the access control entry (ACE)) and also
       (READ+WRITE+CONTROL) access. (Note that you can grant
       yourself BIT_15 access by using the DCL SET ACL command
       if you have (READ+WRITE+CONTROL) access.

       If you do not have the required access after a restore
       operation to make the needed changes, someone with the
       required access or OpenVMS BYPASS or SECURITY access must
       examine and correct the ACL.

       This behavior exists in Oracle RMU to prevent someone from
       using Oracle RMU to override the existing OpenVMS security
       policy.