HP 3000 Manuals HP 3000 Manuals
Recovery After System Failure 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.