On Mon, 28 Jan 2013 03:12:32 -0600, Elardus Engelbrecht
<[email protected]> wrote:
>Barbara Nitz kindly wrote:
>
>> Also, I seem to remember that the checkpoint is always serialized via
>> RESERVE.
>
>True. See JES2 Init and Tuning Guide (z/OS v1.12):
>
>"For the checkpoint data set(s) that reside on a DASD volume, JES2 processing
>uses RESERVE and RELEASE logic with a software checkpoint lock to prevent JES2
>members from simultaneously referencing and updating information kept in the
>checkpoint data set."
>
>>I don't see any reason not to change the RNLS, as then JES shouldn't have any
>>reason to even be aware that there is another JES on another system.
>
>Perhaps, but also from same book, this quote:
>
>"For checkpoint data sets residing on DASD, IBM suggests that you add the
>checkpoint data set(s) to the RESERVE conversion resource exclusion name list
>(RNL) to prevent global resource serialization (GRS) from limiting access to
>that data set and degrading performance."
A little more digging revealed the following:
1. We have "back-level DSNs" for the JES checkpoint datasets in our RNL EXCL
list;
2. The updated DSNS are unique to each image;
3. Each image has two JES checkpoint datasets, each of which is the only
dataset on its respective volume.
Thus, there are a total of six JES checkpoint datasets, with six unique DSNs,
on six different volumes.
It would appear that the only way checkpoint lock contention could arise
between z/OS images would be if GRS uses only the QNAME (SYSZJES2) but not the
RNAME, or a "wildcard" RNAME (*). The RESERVE by one system should not have
any effect on the other systems, right?
Any further insights would be appreciated.
-jc-
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
