After contention on one of the Recon data sets, a Database Copier for IMS for z/OS (DBCOPY) image copy job timed out with an S522 abend.
A number of IOS071I and IOS431I were issued identifying the device where the contention occurred. D U,VOL and D GRS,DEV commands
were then automatically issued to display the name of the job holding the reserve.
IOS071I IOS1071I devn,chp,jobname,text[STATUS:statustext]
IOS431I DEVICE dev RESERVED TO CPU={serialmodn | UNKNOWN},LPAR ID={lparid | NONE | UNKNOWN} SYSTEM=sysname[,sysname1,sysname2, sysname3,... sysname6] | UNKNOWN
Does DBCOPY place a reserve or an enqueue on the IMS Recon data sets? If so can this be the cause of contention on the Recon data sets?
DBCOPY itself does not reserve or enqueue the Recons directly, these are done by IMS in the processing of requests such as signon and database authorization.
When a contention problem occurs, the D GRS,C command can be used to display further system wide detail on the contention.
Check for contention on the Catalog containing the Recon data sets. To eliminate deadlocks on the RECON data sets, they must be the only objects cataloged in their respective catalogs.
To avoid deadlocks on the Recon data sets we recommend reading the following IBM document:
'Avoiding RECON data set deadlock situations for serial access mode'.