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. 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
