After a system failure, the operator should perform a system
startup with system RECOVERY. If successful, User Logging has
its own Warmstart recovery process which opens each logfile that was
active at the time of the failure. It will write a crash
record to the end of the data in the logfile, move the end-of-file
pointer to the end of the last good block, and close the logfile.
This will place the file in a "good" state so it can be used by
the recovery program or by User Logging when the logging
process is restarted. If system RECOVERY is not done, the logfile can
still be read because, when User Logging opened the logfile for the
process, it moved the end-of-file pointer to the file
limit. All the records in the file can be read, even though those at
the end of the file are not valid data.
To handle this case, the program should check the CKSUM word of each
record. The CKSUM is calculated by XORing all of the
16-bit words in the
record using a base of -1. When the recovery program encounters
a record whose CKSUM is not valid, it will assume that it has
come to the end of valid data in the file.
The logfile being read should be accessed through the MPE file
system with FOPEN, FREAD, etc. There are no
User Logging intrinsics which allow users to read logfiles.
If more than one process accessed the logfile, each record must be
checked and a determination made to see if the record belongs to
the process being recovered.
To do this, check the file belonging to the process that contains
the user, group, and account accessing the logfile, the pin#
of the process, the fully qualified file name of the logfile,
the logid, and the date and time the logfile was opened
by the application.
Open the logfile, search the logfile for the logid, user,
group, and account which match in the OPENLOG record
(refer to Appendix B, "Record Formats"). Verify the match by using
the pin#, and the date and time of the open. When the
correct OPENLOG record has been found, obtain the log#.
All records with that log# belong to the process.
Backup copies of the application data structures will be needed
for the recovery process.
The recovery program should look for BEGINLOG and ENDLOG
records. When an ENDLOG record is found, the transaction has
been completed, and all actions represented
by the WRITELOG records within that
transaction should be applied to the backup data structures.
If a BEGINLOG is found without a matching ENDLOG, the
transaction was not complete, its actions should not be reapplied.
CONTINUATION Records |
 |
Each BEGINLOG, WRITELOG, and ENDLOG
record contains up to 119 words of user data. If more than
119 words were passed to the intrinsic, one or more CONTINUATION
records will contain the remainder of the data. The LEN
field will reflect the total number of words that were passed.
For example, if a length of 140 words was passed to the WRITELOG
intrinsic, the LEN field of the WRITELOG record
will contain 140 words.
There will be 119 words in the user data area
of the WRITELOG record and
21 words in the CONTINUATION record. The LEN field of the
CONTINUATION record will also reflect the total number of words (140).
A positive LEN indicates 16-bit words,
a negative LEN indicates 8-bit bytes.
CHANGELOG Records |
|
If the recovery program encounters a
CHANGELOG record with a code of
12, the record will contain the name and type of the next logfile
in the set; continue recovery with the next logfile. The first record
of the new logfile should be a CHANGELOG
record with a code of 11. It will
contain the name and type of the previous logfile, and may be used
as a check when the new logfile is opened.
