Monitoring and retrying shunted transactions

All shunted transactions are automatically retried by DFSMStvs every 15 minutes. If the retry is unsuccessful, another retry occurs after 15 minutes. For each transaction that is successfully retried, DFSMStvs issues message IGW892I.

All shunted transactions are automatically retried by DFSMStvs every 15 minutes until the retry is successful. For each transaction that is successfully retried, DFSMStvs issues message IGW892I. You can also manually retry a shunted transaction, using the access method services SHCDS command.

Because DFSMStvs automatically retries transactions that are in the shunt log, you need to make sure that the log does not contain anything that cannot be retried. For example, if you delete a data set for which recovery is owed, VSAM RLS releases all of the locks associated with the data set. Suppose you then allocate a data set with the same name as the deleted data set. If the shunt log still contains outstanding work for the deleted data set, DFSMS might automatically retry this work on the new data set of the same name, without any locks.

Recommendation: Before you delete a data set, use the the SHCDS PURGE command to rid the shunt log of any outstanding work for the data set.

Various levels of authorization are required to use the SHCDS parameters. For information about this autorization, see z/OS DFSMS Access Method Services Commands.

Alternatively, if you have units of recovery that were shunted due to backout failures, you can resolve those units of recovery by following these steps:

Use the access method services SHCDS LISTSHUNTED(dsname) command to list all the shunted entries for a particular data set.
Make certain that the problem that caused the failure has been corrected. This might involve ensuring that the volume is available or that the data set has been recovered.
Determine whether the shunted entries should be retried.
If the shunted entries should be retried, use the access method services RETRY command to request that DFSMStvs take action on them.
If the shunted entries should not be retried, use the access method services SHCDS PURGE command to request that DFSMStvs delete the shunted information.
It might also be necessary to use interfaces provided by RRS to inform RRS that the unit of recovery has been resolved.

If you used the access method services SHCDS RESETLOCKS command to reset the locks for a data set, the reset causes any attempt to take action on shunted log entries for the data set to fail.

The same is true if you delete the data set without unbinding the locks. If you used the access method services SHCDS FRUNBIND command, followed by the access method services SHCDS RFDELETEUNBOUNDLOCKS command to reset the locks for a data set, it causes any attempt to take action on shunted log entries for the data set to fail.

Both problems cause DFSMStvs to see a unit of recovery that has log records but no locks, which can be referred to as suspended state. A unit of recovery that is in a suspended state cannot be retried because it is not safe to do so without the locks. Use the access method services SHCDS command to purge the unit of recovery.