I believe that prior to z/OS 2.1 the enqueue would *never* be downgraded. This
is also the default behavior in z/OS 2.1.
However in z.OS 2.1 the option to downgrade the enqueue exists with some JCL
changes. I haven't looked for the JCL keywords/syntax,
but here is a quote from the z/OS 2.1 Announcement letter.
<quote>
z/OS V2.1 Global Resource Serialization (GRS) supports synchronously changing
an exclusive enqueue to a shared enqueue, in addition to the existing support
for changing an enqueue from shared to exclusive. Corresponding support is
available in JCL for a new JOB statement keyword to enable you to specify that
access to data sets can transition from exclusive to shared after the last step
in which they are allocated with a disposition of OLD, NEW, or MOD. Also,
support is available for a JES2 initialization statement to specify whether
this function should be allowed, and whether it should be used by default if
not specified in JCL. This function is intended to permit more parallelism in
resource processing by allowing resources to be available for read access
before the process that originally requested exclusive use ends in
single-system and GRS Star environments.
</quote>
HTH,
<snip>
Suppose:
ALLOCATE DD(DDSHR) DSN(FOO.BAR) SHR
There is now an ENQ SHR SYSDSN FOO.BAR
Then:
ALLOCATE DD(DDEXC) DSN(FOO.BAR) OLD
The ENQ is upgraded to EXC
... some stuff ... Then:
FREE DD(DDEXC)
is the ENQ downgraded back to SHR? Why or why not?
</snip>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
