z/OS DFSMSdfp Checkpoint/Restart
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Preserving Data Set Contents

z/OS DFSMSdfp Checkpoint/Restart
SC23-6862-00

The system does not save and restore the contents of data sets. You must ensure that input data sets and system data sets contain all necessary data when restart occurs. If a data set on a direct access volume is open at the checkpoint, the data set's label (the DSCB in the VTOC) must have the same location and reflect the same extents upon restart as it did when the checkpoint was taken.

If your program reads records from a data set, updates them, and writes them back to their original locations, it may be useless to take a checkpoint before completing this processing. If a checkpoint is taken earlier, postrestart processing is unsuccessful under these circumstances:
  • Your program updates a record before abnormal termination and repeats the update after restart, and
  • The updated record contents depend on the original contents.

For example, suppose that the purpose of the update is to exchange the positions of two fields in each record. If the record is updated twice, the fields are returned to their original positions, and the results are invalid. In a different application, an update might place a value in a record field, regardless of the field's original contents. You could then restart the step at a checkpoint taken before or during the update procedure, because an updated record would not be changed if updated again after restart.

When data set records are processed in an update-in-place manner (records are read, changed, and written back into their original location in the data set), bad data can be prevented if records updated after the last checkpoint are restored to their original state or if your program keeps track of the records that are updated and avoids updating them again during restart.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014