Runtime Considerations › Application Restartability › Restarting the Application After an Abend

Restarting the Application After an Abend

In central version, if the application abends, the runtime system automatically rolls back the database to its state at the time of the last database commit, which should have occurred at the time of the last checkpoint. (In local mode, you must use journals and rollback utilities to roll back the database.) Therefore, the database should already be set for restart.

Restart at the Highest Level Dialog

Your application should be restarted at the highest level dialog; the dialog can link to a dialog that performs the restart and then returns control to the highest level dialog.

Restart Steps

The restart should include the following steps:

1. Read the checkpoint record—Read the record, then, if the record is being stored in a sequential file, close the file.
2. Restore the variable fields—Move the saved variable fields from the checkpoint record to the appropriate records in dialog variable storage. You do not (and, in fact, cannot) restore the record count fields.
3. Set the input files' pointers—For each input file to be restored, link to a dialog whose sole function is to read the file until the file pointer is set at the proper position. The dialog determines how many records to read by using the record count field stored in the checkpoint record. After setting the file pointers, the dialog should close the file. The disposition of the restored file should be MOD.

   Note: If the file was accessed by several dialogs, you may have several checkpoint record fields for the file. If so, you should use the total count of the fields to determine how many records to read.

   If the file has multiple record layouts, you will have to use multiple dialogs to read the record and you must have an application structure that determines which dialog reads the various types of records.

4. Set the output and suspense files' pointers—For each output and suspense file to be restored, link to a dialog whose sole function is to copy the file to a new file, until the proper number of records have been written.

   Consider the following scenario. An application writes 100 records to an output file before taking a checkpoint. The application writes another 10 records to the file, then abends. The runtime system empties the buffer; as a result, 110 records have been physically written to the file. Your restart procedure must create a new file that consists of only the first 100 records.

   The dialog responsible for restoring the output file reads the file's records and writes them to a new file. The dialog determines how many records to copy by using the record count field stored in the checkpoint record. After the file has been restored, the dialog should close both files. The disposition of the new file should be MOD. The dialogs that will be writing to the new output or suspense file should specify the runtime label of the new file.

   Note: If the file was accessed by several dialogs, you may have several checkpoint record fields for the file. If so, you should use the total count of the fields to determine how many records to read.

   If the file has multiple record layouts, you will have to use multiple dialogs to copy the record and you must have an application structure that determines which dialog reads the various types of records.

5. Return to the highest level dialog and resume processing.