If checkpointing is enabled, the access module reads messages from the queue, then copies the data into a fallback file before delivering the data to the Data Connector. If the load utility decides to restart at an earlier point in the data stream, it directs the Data Connector to issue the File Set Position command to the access module. The module then supplies data from the fallback data file until the restart is complete.
After a position request is made to the access module, additional processing by the client (and probably the database) occurs. A checkpoint request is considered successful only after a subsequent request from the client is received by the access modules. A checkpoint followed by a function request for a reposition is considered successful by virtue of the contents of the position information provided at the reposition. Support for a previous checkpoint is not removed until the most recent checkpoint is successful. This approach allows recovery from a checkpoint failure. On workstation platforms, a temporary file named MQAMtmp.<pid> may be created and resides in the same directory as that of the checkpoint file (specified by the CKFILE keyword).
When a reposition request immediately follows an open request, a restart is conducted. In this case, one or more messages are retrieved from the checkpoint file before the messages are sent back to WebSphere MQ.
Attempting restarts with multi‑volume checkpoint files (checkpoint file allocated on multiple disk volumes) can result in the loss or corruption of data. To ensure proper restarts, make sure that the dataset for the DD statement MQCHKPT in the WebSphere MQ job step resides entirely on one single disk volume.