Storage team utilizing ADRDSSU (DFDSS) to move datasets to new volumes in a SHARED DASD complex experiencing an unexpected situation involving one particular file.
Expected an ADR410E message reporting it failed serialization.
[ADR410E (001)-DDFLT(01), DATA SET dddddddd.dddddddd IN CATALOG system.catalog ON VOLUME vvvvvv FAILED SERIALIZATION FOR DELETE.]
However, it failed in a different manner trying to move this one file. This one file is a HFS file and is currently allocated by OMVS on SYSB. The DFDSS job ran on SYSA.
The question is, why was it not ENQ protected like most other allocated datasets?
Release : 12.5
Component : MII
GDIINIT PROCESS=SELECT
IBM documentation shows that HFS datasets are serialized with SYSZDSN in addition to SYSDSN.
After checking with IBM it was determined that the results for the HFS file systems were expected based on the ENQ held for a mounted HFS file system.
The underlying logic for the HFS EXCL ENQ, when mounted R/W, is that HFS caches its data, and hardens it to disk on a timed (default of 60 seconds) schedule to maintain adequate performance AND that the EXCL ENQ prevents inadvertent mounts on another system that can cause physical corruption of the HFS.
Witnessed many MIM1038I/39I contention messages for various datasets which confirms that MII is making the SYSDSN ENQs global.
In fact, there is a cross system conflict for the problem dataset slightly after the IGD17060I failure message:
.09.47.07 JOB10714 IGD17060I DELETE/RENAME FAILED BECAUSE DATA SET IS OPEN 721
. 721 ON VOLUME WODR00
. 721 DATA SET IS SYSTEM.OMVS.SYSB.APPL.SECDATA
09.47.07 JOB10714 MIM1038I xxxxxxxx JOB10714 A=019A T=7F8680 contention with OMVS A=0010 T=7FEE88 OWNS SHR on SYSB
09.47.07 JOB10714 MIM1039I xxxxxxxx JOB10714 A=019A T=7F8680 needs EXCL SYSDSN SYSTEM.OMVS.SYSB.APPL.SECDATA
The Enqueue for the SYSZDSN QNAME needed to be made global.
Update MIMQNAME to include SYSZDSN with SCOPE=SYSTEMS.
This can be done dynamically using the ADDQNAME command: