A checkpoint data set can be a sequential data set, a PDS, or a VSAM extended-format data set, but it cannot be a sequential extended-format data set, a PDSE, or a UNIX file.

When an application program has a checkpoint, the system records information about the status of that program in a checkpoint data set. Checkpoint data sets contain system data. To ensure integrity of this data, checkpoint data sets are, by default, permitted only on nonshared DASD and tape volumes. If a user could read a checkpoint data set (even one the user owns) then the user might be able to see information the user is not authorized to read. If a user could modify a checkpoint data set (including one the user owns) the user might be able to use it to bypass all security and integrity checks in the system.

On systems that assure data set integrity across multiple systems, you may be authorized to create checkpoints on shared DASD through the RACF facility class "IHJ.CHKPT.volser", where "volser" is the volume serial of the volume to contain the checkpoint data set. Data set integrity across multiple systems is provided when enqueues on the major name "SYSDSN", minor name "data set name" are treated as global resources (propagated across all systems in the complex) using multisystem global resource serialization (GRS) or an equivalent function.

If a checkpoint data set is on shared DASD, DFSMS issues the SAF RACROUTE macro requesting authorization against a facility class profile of IHJ.CHKPT.volser during checkpoint ("volser" is the volume serial number where the checkpoint data set resides).

If the system programmer cannot insure data set integrity on any shared DASD volumes, the system programmer need not take any further action (for instance, do not define any profile to RACF which would cover IHJ.CHKPT.volser). You cannot take checkpoints on shared DASD volumes.

If data set integrity is assured on all shared DASD volumes and the system programmer wants to perform a checkpoint on any of these volumes, build a facility class generic profile with a name of IHJ.CHKPT.* with UACC of READ.

If data set integrity cannot be assured on some of the volumes, build discrete profiles for each of these volumes with profile names of IHJ.CHKPT.volser with UACC of NONE. These "volume-specific" profiles are in addition to the generic profiles described above to permit checkpoints on shared DASD volumes for which data set integrity is assured.

If the system programmer wants to let some, but not all, users to create checkpoints on the volumes, build the generic profiles with UACC of NONE and permit READ access only to those specific users or groups of users.

Information in a checkpoint data set includes the location on the disk or tape where the application is currently reading or writing each open data set. If a data set that is open at the time of the checkpoint is moved to another location before the restart, you cannot restart the application from the checkpoint because the location-dependent information recorded by checkpoint/restart is no longer valid.

There are several system functions (for example, DFSMShsm or DFSMSdss) that might automatically move a data set without the owner specifically requesting it. To ensure that all checkpointed data sets remain available for restart, the checkpoint function sets the unmovable attribute for each SMS-managed sequential data set that is open during the checkpoint. An exception is the data set containing the actual recorded checkpoint information (the checkpoint data set), which does not require the unmovable attribute.

You can move checkpointed data sets when you no longer need them to perform a restart. DFSMShsm and DFSMSdss FORCECP(days) enable you to use operations such as migrate, copy, or defrag to move an SMS-managed sequential data set based on a number of days since the last access. DFSMShsm recall, and DFSMSdss restore and copy, are operations that turn off the unmovable attribute for the target data set.

See z/OS Security Server RACF Command Language Reference for information about RACF commands and z/OS Security Server RACF Security Administrator's Guide for information about using and planning for RACF options.

If you do not have RACF or an equivalent product, the system programmer can write an MVS router exit that is invoked by SAF and can be used to achieve the above functions. See z/OS MVS Programming: Authorized Assembler Services Guide for information about writing this exit.