HP RMS Journaling for OpenVMS

HP RMS Journaling for OpenVMS SPD 27.58.16
commit protocol. RU journaling supports both a one-
phase and a two-phase commit protocol.
Remote RMS files (files accessed via the DAP/FAL pro-
tocol) that are marked for RU journaling can be modified
within a transaction and will be included in the atomic
unit of work defined by the transaction. Also, the mod-
ifications made to RMS files marked for RU journaling
can be combined with modifications made using any re-
source manager that supports DECdtm services into a
single atomic transaction.
The Recovery Unit Facility (RUF) services have been
superseded by DECdtm services. However, the RUF
services are still supported and are transparently emu-
lated using the DECdtm services. Existing applications
that were written using the RUF services continue to
work without recompilation or relinking.
Supported File Organizations
All RMS file organizations are supported by RMS
Journaling for OpenVMS. Any sequential, relative, or
Prolog 3 indexed file can use journaling. However, the
following restrictions apply:
• Prolog 1 and Prolog 2 indexed files are not supported
by RMS Journaling for OpenVMS.
• Sequential files have a maximum record size of
32,667 bytes.
• Files marked for RU journaling cannot be modified
with the DCL command WRITE.
• Stream files cannot be modified in shared mode in a
recovery unit.
• Sequential files having VFC record format do not al-
low shared access for RU journaling.
When using RU journaling with shared, fixed-length se-
quential files, any abort processing overwrites records
added to the recovery unit with zero bytes (null charac-
ters). This occurs because the record cannot be deleted
from the file.
All files that are marked for journaling must reside on
Files-11 On-Disk Structures 2 (ODS-2) and 5 (ODS-5)
disks. All journals must also reside on ODS-2 or ODS-
5 disks. It is recommended that journals used for AI
journaling reside on a disk volume that is different from
the disk volume where the data file that uses the journal
resides. Journaling across a network or to a tape device
is not supported.
Marking Files for Journaling
RMS Journaling for OpenVMS is enabled on a file-by-
file basis. Files marked for AI, BI, and RU journaling are
enabled by using qualifiers to the DCL command SET
FILE. You can use any combination of qualifiers with a
particular SET FILE command or series of SET FILE
commands.
The most recent SET FILE command for a given file
overrides all previous SET FILE commands for that file.
Successful marking of an RMS file for journaling re-
quires exclusive access to the file specified in the SET
FILE command. Exclusive access means the RMS file
being marked for journaling must be closed; that is, ap-
plication programs accessing that file must be shut down
before the file can be successfully marked for journaling.
No modifications to application programs are required
for long-term (AI or BI) journaling. Once a file has been
marked for long-term journaling, journal information will
be written to the journal each time the file is modified.
You must enter the SET FILE command to mark the file
for journaling before opening the file. All modifications
to the file are recorded in the journal until the file is
unmarked for journaling.
Modifications to application programs are required for
RU journaling. At a minimum, the program must spec-
ify the start and end of a recovery unit, using DECdtm
transactions or RU system services. When a file is
marked for recovery unit journaling, all modifications to
that file made by the application must be within a recov-
ery unit.
Journal File Maintenance
AI and BI journals require periodic maintenance. Be-
cause journals can expand indefinitely, and a journal
must reside on a single volume set, occasional remark-
ing of a file for journaling and all of the associated opera-
tions is required. This implies that applications access-
ing RMS files marked for AI or BI journaling, or both,
must be stopped periodically for journal maintenance
operations.
Recovering Data — Long-Term Journaling
In the case of long-term (either AI or BI) journaling, data
recovery is done using the RMS Recovery utility. Re-
covery is on a file-by-file basis and must be explicitly
requested; it is not done automatically. The RMS Re-
covery utility is invoked at DCL level to either roll forward
or roll back changes to the file. The Recovery utility
requires exclusive access to the file being recovered.
Changes can be rolled forward or rolled backward until
a time specified by the user.
Recovering Data — Recovery Unit Journaling
2