                          Software           Product            Description   M           ___________________________________________________________________   M           PRODUCT NAME:  RMS Journaling for OpenVMS, Version 6.2 SPD 27.58.10   G           Note: This is the Software Product Description (SPD) for the  !           following two products:   +           o  RMS Journaling for OpenVMS VAX   -           o  RMS Journaling for OpenVMS Alpha   M           Except where specifically noted, the features described in this SPD M           apply to both products. The license and part number information is  J           architecture specific. Please refer to the Ordering Information 2           section of this SPD for further details.             DESCRIPTION   J           RMS Journaling for OpenVMS helps maintain the data integrity of N           OpenVMS RMS files and protects this file data from becoming lost or E           inconsistent in the event of a number of failure scenarios.   L           RMS Journaling for OpenVMS provides the following three methods of           journaling:   N           o  After-image (AI) journaling provides the ability to redo a seriesN              of modifications to a file. This type of journaling helps recoverP              lost or corrupted files. After-image recovery restores the contentsO              of the file from the point of the latest backup copy of that file.   O           o  Before-image (BI) journaling provides the ability to undo a series N              of modifications to a file. This type of journaling allows a fileM              to be returned to a previous known state. This is useful in the  >              event that a file is updated with erroneous data.    M                                         DIGITAL                      May 1995   M                                                                   AE-PY1KC-TE            L           RMS Journaling for OpenVMS, Version 6.2               SPD 27.58.10    P           o  Recovery unit (RU) journaling helps maintain transaction integrity,O              where a transaction consists of a group of related operations that M              must be "atomic". That is, either all of the operations complete O              in their entirety or none of the operations complete. This type of P              journaling helps prevent data from becoming inconsistent due to the3              incomplete execution of a transaction.   M           Journaling is applied on a file-by-file basis. A file can be marked M           for after-image, before-image, or recovery unit journaling, or any  P           combination of these methods. Within a given application, any combina-1           tion of journaling methods can be used.   N           RMS Journaling for OpenVMS stores the information necessary for dataN           recovery in files known as journals. Multiple files can use the same           journal.  >           RMS Recovery Unit Journaling and DECdtm Transactions  P           Transactions are defined and managed using the DECdtm transaction ser-N           vices available within OpenVMS. An RMS recovery unit is a set of RMSO           record operations, performed in the context of a single process, that N           are part of a transaction coordinated by DECdtm services. RMS recov-P           ery units are started automatically by RMS, and RMS recovery units areM           committed or aborted along with the transaction of which they are a            part.   N           RMS Journaling for OpenVMS functions as a resource manager in trans-L           actions that use DECdtm services. DECdtm services are implemented O           using a two-phase commit protocol as described in the OpenVMS Operat- O           ing System Software Product Description (SPD 25.01.xx). Recovery unit O           journaling supports both a one-phase and a two-phase commit protocol.   M           Remote RMS files (files accessed via the DAP/FAL protocol) that are M           marked for recovery unit journaling can be modified within a trans- M           action and will be included in the "atomic unit of work" defined by O           the transaction. Also, the modifications made to RMS files marked for K           recovery unit journaling can be combined with modifications made  P           using any resource manager that supports DECdtm services into a single           "atomic" transaction.     ,                                            2           L           RMS Journaling for OpenVMS, Version 6.2               SPD 27.58.10    L           The Recovery Unit Facility (RUF) services have been superseded by M           DECdtm services. However, the RUF services are still supported and  I           are transparently emulated using the DECdtm services. Existing  L           applications that were written using the RUF services continue to 2           work without recompilation or relinking.  &           Supported File Organizations  I           All RMS file organizations are supported by RMS Journaling for  N           OpenVMS. Any sequential, relative, or Prolog 3 indexed file can use @           journaling. However, the following restrictions apply:  J           o  Prolog 1 and Prolog 2 indexed files are not supported by RMS $              Journaling for OpenVMS.  I           o  Sequential files have a maximum record size of 32,667 bytes.   N           o  Files marked for recovery unit journaling cannot be modified with#              the DCL WRITE command.   O           o  Stream files cannot be modified in shared mode in a recovery unit.   K           o  Sequential files having VFC record format do not allow shared  1              access for recovery unit journaling.   G           When using recovery unit journaling with shared fixed-length  M           sequential files, any abort processing overwrites records added to  K           the recovery unit with zero bytes (null characters). This occurs  =           because the record cannot be deleted from the file.   K           All files that are marked for journaling must reside on Files-11  L           Structure Level 2 disks. All journals must also reside on Files-11L           Structure Level 2 disks. It is recommended that journals used for O           afterimage journaling reside on a disk volume that is different from  L           thedisk volume where the data file that uses the journal resides. K           Journaling across a network or to a tape device is not supported.         ,                                            3           L           RMS Journaling for OpenVMS, Version 6.2               SPD 27.58.10  &           Marking Files for Journaling  N           RMS Journaling for OpenVMS is enabled on a file-by-file basis. FilesP           marked for after-image, before-image, and recovery unit journaling areM           enabled by using qualifiers to the DCL command SET FILE. Any combi- M           nation of qualifiers can be used with a particular SET FILE command )           or series of SET FILE commands.   I           The most recent SET FILE command for a given file overrides all 3           previous SET FILE commands for that file.   M           Successful marking of an RMS file for journaling requires exclusive I           access to the file specified in the SET FILE command. Exclusive O           access means the RMS file being marked for journaling must be closed; M           that is, application programs accessing that file must be shut down D           before the file can be successfully marked for journaling.  M           No modifications to application programs are required for long-term O           (after-image or before-image) journaling. Once a file has been marked N           for long-term journaling, journal information will be written to theP           journal each time the file is modified. The file must have been openedM           after the issuance of the SET FILE command that marked the file for H           journaling. All modifications to the file are recorded in the <           journal until the file is unmarked for journaling.  N           Modifications to application programs are required for recovery unitN           journaling. At a minimum, the program must specify the start and endM           of a recovery unit, using DECdtm transactions or recovery unit sys- O           tem services. When a file is marked for recovery unit journaling, all M           modifications to that file made by the application must be within a            recovery unit.  "           Journal File Maintenance  M           After-image and before-image journals require periodic maintenance. O           Because journals can expand indefinitely and a journal must reside on M           a single volume set, occasional re-marking of a file for journaling M           and all of the associated operations is required. This implies that E           applications accessing RMS files marked for after-image or  M           before-image journaling, or both, must be stopped periodically for  )           journal maintenance operations.     ,                                            4           L           RMS Journaling for OpenVMS, Version 6.2               SPD 27.58.10    0           Recovering Data - Long-Term Journaling  H           In the case of long-term (either after-image or before-image) L           journaling, data recovery is done using the RMS Recovery utility. P           Recovery is on a file-by-file basis and must be explicitly requested; O           it is not done automatically. The RMS Recovery utility is invoked at  M           DCL level to either roll forward or roll back changes to the file.  K           The Recovery utility requires exclusive access to the file being  N           recovered. Changes can be rolled forward or rolled backward until a %           time specified by the user.   4           Recovering Data - Recovery Unit Journaling  O           No user intervention is required to roll back a recovery unit that is N           incomplete. The rollback of an incomplete transaction is started andM           completed automatically the next time a user attempts to access the            file.   -           Interaction with the Backup Utility   M           To recover data using after-image journaling, a backup copy of the  I           file must be available. This copy must be made with the Backup  M           utility (BACKUP); a copy of the file made with the COPY or CONVERT  K           command cannot be used. The backup copy of the file must be made  N           after the SET FILE/AI_JOURNAL command is issued but before the file P           is opened for update. BACKUP requires exclusive access to files being N           backed up. No user or application program can access the file until !           the backup is finished.   M           The use of BACKUP/RECORD is recommended. If the file is then rolled N           forward, the modifications that have been made since the most recent           backup are applied.   M           If a backup copy of a file is rolled forward with the RMS Recovery  O           utility, users must re-mark the file for after-image journaling with  N           the SET FILE/AI_JOURNAL command. A backup copy of that file must be N           made after it has been marked for after-image journaling and before *           application updates are allowed.  M           A backup copy of the file must be re-marked for journaling if it is 3           to be used in place of the original file.   ,                                            5           L           RMS Journaling for OpenVMS, Version 6.2               SPD 27.58.10    7           Interaction with Volume Shadowing for OpenVMS   M           Volume Shadowing for OpenVMS can be used in conjunction with after- M           image journaling. After-image journaling helps recover data in the  H           following cases not addressed by Volume Shadowing for OpenVMS:  E           o  Mistaken deletion of a file by a system user or operator   3           o  Corruption of the file system pointers   M           o  RMS file corruption due to a software error or incomplete bucket 0              write operations to an indexed file  @           Failures Not Addressed by RMS Recovery Unit Journaling  I           Recovery unit journaling alone does not provide recovery when a O           multiblock bucket write operation to an indexed file is in progress,  I           leaving the bucket in the indexed file in a corrupt state. Use  N           after-image journaling in conjunction with recovery unit journaling G           to recover from the following failed multiblock bucket write             operations:   H           o  Failure of the VAX or Alpha host during a multiblock write O              operation, such as a system crash, halt, power failure, or system                shutdown.  J           o  Permanent loss of path to the disk during a multiblock write               operation.   L           o  Cancellation of a multiblock write operation in progress. This P              operation is possible only with disks that use the DUDRIVER or thatL              access a disk drive through the MSCP server. Other disk drives A              ignore the cancellation of I/O and are not affected.              HARDWARE REQUIREMENTS   M           Refer to the OpenVMS Operating System Software Product Description  L           (SPD 25.01.xx) for hardware requirements and supported processors.        ,                                            6           L           RMS Journaling for OpenVMS, Version 6.2               SPD 27.58.10               CLUSTER ENVIRONMENT   L           This layered product is fully supported without restrictions when N           installed on any valid and licensed OpenVMS Cluster* configuration. O           The Hardware Requirements section of this product's Software Product  I           Desscription and the OpenVMS Operating System Software Product  P           Description (SPD 25.01.xx) list any special hardware required by this            product.  N           *  OpenVMS Cluster configurations are fully described in the OpenVMSP              Cluster Software Product Description (SPD 29.78.xx) and include CI,I              Ethernet, DSSI, FDDI, and Mixed Interconnect configurations.              SOFTWARE REQUIREMENTS   P           RMS Journaling for OpenVMS Version 6.2 is an OpenVMS System Integrated4           Product that requires OpenVMS Version 6.2.  L           For additional information, refer to the OpenVMS Operating System 6           Software Product Description (SPD 25.01.xx).             OpenVMS Tailoring   M           For OpenVMS Version 6.2 the following OpenVMS class is required for :           full features of this system integrated product:  &              OpenVMS Required Save Set  P           For more information about OpenVMS classes and tailoring, refer to theO           OpenVMS Operating System Software Product Description (SPD 25.01.xx).              GROWTH CONSIDERATIONS   O           The minimum hardware and software requirements for any future version H           of this product may be different from the requirements for the           current version.          ,                                            7           L           RMS Journaling for OpenVMS, Version 6.2               SPD 27.58.10    '           DISTRIBUTION AND INSTALLATION   H           RMS Journaling for OpenVMS Version 6.2 is a System Integrated O           Product that is distributed and installed with the OpenVMS operating             system Version 6.2.              ORDERING INFORMATION  ,           For RMS Journaling on OpenVMS VAX:  (           Software Licenses: QL-VDVA*-**-           Software Documentation: QA-VDVAA-GZ 0           Software Product Services: QT-VDVA*-**  .           For RMS Journaling on OpenVMS Alpha:  (           Software Licenses: QL-0VHA*-**-           Software Documentation: QA-VDVAA-GZ 0           Software Product Services: QT-0VHA*-**  M           *  Denotes variant fields. For additional information on available  P              licenses, services, and media, refer to the appropriate price book.             SOFTWARE LICENSING  N           This software is furnished under the licensing provisions of DigitalJ           Equipment Corporation's Standard Terms and Conditions. For more P           information about Digital's licensing terms and policies, contact your           local Digital office.E  %           License Management Facility2  F           This system integrated product supports the OpenVMS License            Management Facility.  J           License units for this product are sold on a capacity (per CPU)            basis.        ,                                            8 a         L           RMS Journaling for OpenVMS, Version 6.2               SPD 27.58.10    N           For more information about the License Management Facility, refer toD           the OpenVMS Operating System Software Product Description M           (SPD 25.01.xx) or the OpenVMS License Management Utility Manual in h(           the OpenVMS documentation set.  M           For more information about Digital's licensing terms and policies,  ,           contact your local Digital office.  #           SOFTWARE PRODUCT SERVICESr  K           A variety of service options are available from Digital. For moreg9           information, contact your local Digital office.              SOFTWARE WARRANTY   M           Warranty for this software product is provided by Digital with the  K           purchase of a license for the product as defined in the Software  (           Warranty Addendum of this SPD.  O           The previous information is valid at the time of this release. PleasevP           contact your local Digital office for the most up-to-date information.  .           1995 Digital Equipment Corporation.              All rights reserved.  J           [TM] The DIGITAL logo, CI, DECdtm, Digital, DSSI, MSCP, OpenVMS,J                OpenVMS RMS, OpenVMS Volume Shadowing, VAX, VAXcluster, andJ                VMScluster are trademarks of Digital Equipment Corporation.                          ,                                            9