At 18:19 -0800 on 01/30/2016, Skip Robinson wrote about Re: Deleting
a dataset that GRS has enqueued.:
I'm not sure what ISPF function you're referring to. This happens all the
time in our bronze-plex. Editing SYS1.PARMLIB(ABC) on one system. Cannot
concurrently edit SYS1.PARMLIB(ABC)--different volume--on the other system
because of GRS.
I am thinking of SPFEDIT which uses an RNAME of DSN+MEMBER. There is
no valid reason IMO for the RNAME to not be DSN+VOLSER+MEMBER except
for "Foolish Consistency" (as in "Foolish Consistency is the
Hobgoblin of small minds") to make it match SYSDSN since the VOLSER
is ALWAYS known at the time the member is opened for editing and thus
the ENQ being issued.
It's an inconvenience but not a show stopper. Believe me, we
would not have a bronze-plex if our feet had not been put to the fire with
only months to dodge a pricing penalty in late 2007. I'm still amazed that
we pulled it off in such a short time.
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
[email protected]
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]]
On Behalf Of Robert A. Rosenberg
Sent: Saturday, January 30, 2016 05:54 PM
To: [email protected]
Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
At 14:53 -0600 on 01/30/2016, Paul Gilmartin wrote about Re: Deleting a
dataset that GRS has enqueued.:
>Even within a single system, to delete a data from one volume when a
>like named data set on a diferent volume is in use ENQ SHR on the same
>system.
This is a irresolvable design flaw (ie: The Volser is not part of the ENQ
- Only
the DSN) that is hard/impossible to fix based on the different times and
ways
the ENQ is issued. IOW: The Volume that the dataset resides on can at
times
be unknown until AFTER the ENQ is issued. Thus there is no way that an ENQ
on a dataset named DSN1 which is on VOLSER1 can be told from an ENQ for a
dataset named DSN1 residing on VOLSER2. JES3 made some allowance but
even it had to work on with DSN and ignore the VOLSERs. There are ENQs
such
as that used when SPF Editing which get issued with the knowledge of the
VOLSER where the dataset resides so they can have use the VOLSER to help
the ENQ be more specific and thus allow editing of members in different
datasets with the same DSN - I do not know if this occurs or if the
bare-bones
DSN-Only is used to be the consistent with SYSDSN's RNAME.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
