Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

(Replying to my own post.) I looked more into the history BronzePlex. I think 
the first published definition was in 2002's Redbook "Merging Systems into a 
Sysplex" (SG24-6818-00). At one end is Platinum: everything that can be shared 
is actually shared. At the other end is Bronze (see below). Gold is somewhere 
in the middle. It's pretty clear that this distinction derived from IBM's 
crackdown on shops that were benefitting from sysplex pricing but did not 
qualify to the letter of the law: each qualifying CEC must host a portion of a 
single parallel sysplex such that each CEC's portion uses more than 50% of that 
CEC's CPU resources. There can be other mono- or parallel sysplexes in the 
configuration, but one parallel sysplex must dominate every CEC. 

In addition to the CPU test, the shop must certify that some parallel sysplex 
function(s) are actually in use. GRS star is one candidate. Another is DB2 data 
sharing. Also JES checkpoint in CF--not just a common JESplex. You didn't need 
all, but you needed (I think) at least one. Up to 2007 we had been informally 
grandfathered by virtue of early adoption in the mid-90s. Then the hammer came 
down. We brought out the power tools and bolted together two sysplexes that 
individually could meet the test. BronzePlex is no longer needed here, but it 
persists till now for economic reasons. The obverse side of the same old coin. 

"1.2.1 BronzePlex
"Some customers will want to move systems that are completely unrelated into a 
sysplex simply to get the benefits of PSLC or WLC "charging. In this case, 
there will be practically no sharing between the incoming system and the other 
systems in the target sysplex. This "is a typical outsourcing configuration, 
where the sysplex consists of systems from different customers, and there is no 
sharing of anything "(except the minimal sharing required to be part of a 
sysplex) between the systems. We have used the term “BronzePlex” to describe 
this "type of sysplex."

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Skip Robinson
> Sent: Saturday, January 30, 2016 06:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Deleting a dataset that GRS has enqueued.
> 
> I don't know of a 'classic' definition. To me bronze-plex is a fully 
> functional
> parallel sysplex that shares little or nothing more than what's required for
> sysplex, essentially the control data sets plus any others that might be 
> needed
> for 'qualifying' sysplex exploiters. JES is not on the list. My bronze-plex 
> does
> indeed contain two different JES(2) nodes that communicate via NJE as if they
> were 1000s of miles apart.
> 
> OTOH I have run configurations before parallel sysplex even existed that
> contained two separate JES2 nodes. Never had a special name for that other
> than primary/secondary. In my mind, bronze-plex is a configuration born, like
> mine, of the need to qualify for parallel sysplex pricing. That actual need 
> has
> long since disappeared due to configuration changes, but splitting the bronze-
> plex apart would require additional hardware resources--at least CF engines
> and maybe memory plus effort to accomplish--that so far have not seemed
> compelling.
> 
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> jo.skip.robin...@att.net
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Ed Jaffe
> > Sent: Saturday, January 30, 2016 03:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> >
> > On 1/30/2016 8:47 AM, Tom Marchant wrote:
> > > However, I believe that skip had written in an earlier append that hos
> > > bronzeplex was a combination of two sysplexes. If that is the case ...
> >
> > A "classic" bronzeplex is two or more JESplexes within a single sysplex.
> >
> > --
> > Edward E Jaffe
> > Phoenix Software International, Inc
> > 831 Parkview Drive North
> > El Segundo, CA 90245
> > http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Deleting a dataset that GRS has enqueued.

[Skip Robinson]

...individually could *not* meet the test...

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Skip Robinson
> Sent: Sunday, January 31, 2016 10:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> 
> (Replying to my own post.) I looked more into the history BronzePlex. I think
> the first published definition was in 2002's Redbook "Merging Systems into a
> Sysplex" (SG24-6818-00). At one end is Platinum: everything that can be
> shared is actually shared. At the other end is Bronze (see below). Gold is
> somewhere in the middle. It's pretty clear that this distinction derived from
> IBM's crackdown on shops that were benefitting from sysplex pricing but did
> not qualify to the letter of the law: each qualifying CEC must host a portion 
> of
> a single parallel sysplex such that each CEC's portion uses more than 50% of
> that CEC's CPU resources. There can be other mono- or parallel sysplexes in
> the configuration, but one parallel sysplex must dominate every CEC.
> 
> In addition to the CPU test, the shop must certify that some parallel sysplex
> function(s) are actually in use. GRS star is one candidate. Another is DB2 
> data
> sharing. Also JES checkpoint in CF--not just a common JESplex. You didn't need
> all, but you needed (I think) at least one. Up to 2007 we had been informally
> grandfathered by virtue of early adoption in the mid-90s. Then the hammer
> came down. We brought out the power tools and bolted together two
> sysplexes that individually could meet the test. BronzePlex is no longer 
> needed
> here, but it persists till now for economic reasons. The obverse side of the
> same old coin.
> 
> "1.2.1 BronzePlex
> "Some customers will want to move systems that are completely unrelated
> into a sysplex simply to get the benefits of PSLC or WLC "charging. In this 
> case,
> there will be practically no sharing between the incoming system and the
> other systems in the target sysplex. This "is a typical outsourcing 
> configuration,
> where the sysplex consists of systems from different customers, and there is
> no sharing of anything "(except the minimal sharing required to be part of a
> sysplex) between the systems. We have used the term “BronzePlex” to
> describe this "type of sysplex."
> 
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> jo.skip.robin...@att.net
> 
> 
> > -Original Message-----
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Skip Robinson
> > Sent: Saturday, January 30, 2016 06:09 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Deleting a dataset that GRS has enqueued.
> >
> > I don't know of a 'classic' definition. To me bronze-plex is a fully 
> > functional
> > parallel sysplex that shares little or nothing more than what's required for
> > sysplex, essentially the control data sets plus any others that might be
> needed
> > for 'qualifying' sysplex exploiters. JES is not on the list. My bronze-plex 
> > does
> > indeed contain two different JES(2) nodes that communicate via NJE as if
> they
> > were 1000s of miles apart.
> >
> > OTOH I have run configurations before parallel sysplex even existed that
> > contained two separate JES2 nodes. Never had a special name for that other
> > than primary/secondary. In my mind, bronze-plex is a configuration born, 
> > like
> > mine, of the need to qualify for parallel sysplex pricing. That actual need 
> > has
> > long since disappeared due to configuration changes, but splitting the
> bronze-
> > plex apart would require additional hardware resources--at least CF engines
> > and maybe memory plus effort to accomplish--that so far have not seemed
> > compelling.
> >
> > .
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > jo.skip.robin...@att.net
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > > On Behalf Of Ed Jaffe
> > > Sent: Saturday, January 30, 2016 03:16 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> > >
> > > On 1/30/2016 8:47 AM, Tom Marchant wrote:
> > > > However, I believe

Re: Deleting a dataset that GRS has enqueued.

[Paul Gilmartin]

On Fri, 29 Jan 2016 16:25:22 -0500, Jim Mulder wrote:
>
>"I worked on that project and wrote some of the code.  I think 
>that the reason that it does not apply to an SMS-managed data set is 
>that it conflicts with the concept that you cannot have two 
>SMS-managed data sets with the same name.  The project was designed for 
>the system programmer that is building another system.  For example he 
>might have multiple SYS1.MACLIBs."
>
>  So dealing with the situation of having separate catalogs and 
>SMS-plexes within the same sysplex (and thus allowing more than one
>SMS-managed data set with the same name in the same sysplex) was not
>a design consideration for that project. 
>  
They gotta fix that.  Reading this list the anguish is evident.

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.

I know it's not easy.  They gotta fix it.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Clark Morris]

On 29 Jan 2016 20:48:15 -0800, in bit.listserv.ibm-main Skip wrote:

>I finally got TSO access. Yay for me. Meaning that I can experiment. I'm
>grateful to this thread for education on what to expect in a crunch. Here's
>what I found as a user who has access to the magic RACF profile. 
>
Could data sets be set up in different catalogs in the bronze-plex
with GRS told not to propagate the enqueue (i.e. local to each system)
in the 2 LPARS?  If that can be done, would the experiment work
differently?  Would any special access be needed?

Clark Morris
>
>1. Allocated two SMS managed data sets from two members of the bronze-plex.
>Same name, different volumes. Cataloged in two different user catalogs. That
>is, two entirely different datasets associated by name only. Allocated SHR
>on one system. Tried to rename on the other system. Got 'data set in use'
>with no opportunity to override GRS. Total failure.
>
> 
>
>2. Allocated two data sets as in #1 except HLQ SYS1, no SMS involved.
>Cataloged on both systems in two different master catalogs. Got the same
>failure: no can do. No opportunity to override GRS. I began to doubt the
>efficacy of the magic profile. 
>
> 
>
>3. Uncatalogued the data set in #2 on the second system. Still on the same
>volume, still enqueued. Note that this cannot be done with SMS data set.
>This time I got a whole nother sequence.
>
> 
>
>+---
>--+
>
>|   Rename Data Set In Use
>|
>
>| Command ===>
>|
>
>|
>|
>
>| Data Set Name . : SYS1.TEST.DELETE   |
>
>| Volume  . . . . : xx
>|
>
>|
>|
>
>|   The system detected that a data set with the above name is in use
>|
>
>|   (possibly on another system) but it cannot determine whether it is the
>|
>
>|   data set you wish to rename. If it is the same data set and any program
>|
>
>|   has it open, renaming it could cause serious system and data integrity
>|
>
>|   problems.
>|
>
>|
>|
>
>|   You have the extra security authority to rename the data set even though
>|
>
>|   its name is in use. Refer to the DFSMS documentation on the RENAME macro
>|
>
>|   for further information.
>|
>
>|
>|
>
>| Instructions:
>|
>
>|   Press ENTER to override data set name protection and rename the data
>|
>
>|   set.
>|
>
>|   Enter CANCEL or EXIT to cancel the rename request.
>|
>
>|
>|
>
>|
>|
>
>+---
>--+
>
> 
>
>I have to conclude from this experiment that cataloging makes all the
>difference. SMS is a factor only because it requires that all datasets be
>cataloged. If a dataset can be uncataloged, then the RACF profile allows
>that dataset to be renamed despite the GRS enqueue.
>
>.
>
>.
>
>.
>
>J.O.Skip Robinson
>
>Southern California Edison Company
>
>Electric Dragon Team Paddler 
>
>SHARE MVS Program Co-Manager
>
>323-715-0595 Mobile
>
>jo.skip.robin...@att.net
>
> 
>
>> -Original Message-
>
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>
>> On Behalf Of Jim Mulder
>
>> Sent: Friday, January 29, 2016 01:25 PM
>
>> To: IBM-MAIN@LISTSERV.UA.EDU
>
>> Subject: Re: Deleting a dataset that GRS has enqueued.
>
>> 
>
>> > We took the easy way out and brought down the two STCs that had the
>
>> > SMS dataset enqueued, then deleted the version of the dataset that was
>
>> > not being used.
>
>> >
>
>> > It was mentioned in this thread that GRS could have been modified to
>
>> > change the scope of the enqueue on the LPAR that the dataset was not
>
>> > being used on by making it local. Therefore no longer considered in
>
>> > use by GRS. I did not try this, but wonder if this was done for a
>
>> > dataset that was already enqueued if this would work... thoughts?
>
>> >
>
>> > I never found or saw mention a straight forward IBM supported way to
>
>> > delete or rename a SMS dataset in this situation.  If someone comes
>
>> > across a way please post I am curious.
>
>> 
>
>> I asked Wayne Rhoten about this.  He replied:
>
>> 
>
>> "I worked on that project and wrote some of the code.  I think that the
>reason
>
>> that it does not apply to an SMS-managed data set is that it conflicts
>with the
>
>> concept that you cannot have two SMS-managed data sets with the same
>

Re: Deleting a dataset that GRS has enqueued.

[Tom Marchant]

On Sat, 30 Jan 2016 11:26:30 -0400, Clark Morris wrote:

>Could data sets be set up in different catalogs in the bronze-plex
>with GRS told not to propagate the enqueue (i.e. local to each system)
>in the 2 LPARS?  If that can be done, would the experiment work
>differently?  Would any special access be needed?

I'm not sure what you are asking. Skip said that the data sets are in different 
catalogs on each system.

If GRS was told that the ENQ was to remain local, then the other system 
wouldn't 
know that it was enqueued, and would have no problem deleting the data set.

However, I believe that skip had written in an earlier append that hos 
bronzeplex 
was a combination of two sysplexes. If that is the case, telling GRS not to 
propagate
 the ENQ would have been a bad idea because some of the other systems in the 
sysplex would have shared DASD with the system holding the ENQ, but they 
wouldn't have known either.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

What Tom said. Running a parallel sysplex, even a bronze one, without GRS 
protection would be, as we observed here recently, 'inconceivable'. The fallout 
of my experiment indicates the need for a Plan B. It's either bypass enqueue 
(File 183 you say?) or, as OP actually did, bring down the enqueuing tasks long 
enough to rename a dataset. 

If it's sandbox, fire away. But in production, in the immortal words of Dirty 
Harry holding a .44, "you've gotta ask yourself one question: 'Do I feel 
lucky?'" OP did the right thing.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: Saturday, January 30, 2016 08:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> 
> On Sat, 30 Jan 2016 11:26:30 -0400, Clark Morris wrote:
> 
> >Could data sets be set up in different catalogs in the bronze-plex with
> >GRS told not to propagate the enqueue (i.e. local to each system) in
> >the 2 LPARS?  If that can be done, would the experiment work
> >differently?  Would any special access be needed?
> 
> I'm not sure what you are asking. Skip said that the data sets are in 
> different
> catalogs on each system.
> 
> If GRS was told that the ENQ was to remain local, then the other system
> wouldn't know that it was enqueued, and would have no problem deleting the
> data set.
> 
> However, I believe that skip had written in an earlier append that hos
> bronzeplex was a combination of two sysplexes. If that is the case, telling 
> GRS
> not to propagate  the ENQ would have been a bad idea because some of the
> other systems in the sysplex would have shared DASD with the system holding
> the ENQ, but they wouldn't have known either.
> 
> --
> Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Ed Jaffe]

On 1/30/2016 8:47 AM, Tom Marchant wrote:
However, I believe that skip had written in an earlier append that hos 
bronzeplex was a combination of two sysplexes. If that is the case ...


A "classic" bronzeplex is two or more JESplexes within a single sysplex.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

I don't know of a 'classic' definition. To me bronze-plex is a fully functional 
parallel sysplex that shares little or nothing more than what's required for 
sysplex, essentially the control data sets plus any others that might be needed 
for 'qualifying' sysplex exploiters. JES is not on the list. My bronze-plex 
does indeed contain two different JES(2) nodes that communicate via NJE as if 
they were 1000s of miles apart. 

OTOH I have run configurations before parallel sysplex even existed that 
contained two separate JES2 nodes. Never had a special name for that other than 
primary/secondary. In my mind, bronze-plex is a configuration born, like mine, 
of the need to qualify for parallel sysplex pricing. That actual need has long 
since disappeared due to configuration changes, but splitting the bronze-plex 
apart would require additional hardware resources--at least CF engines and 
maybe memory plus effort to accomplish--that so far have not seemed compelling. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Saturday, January 30, 2016 03:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> 
> On 1/30/2016 8:47 AM, Tom Marchant wrote:
> > However, I believe that skip had written in an earlier append that hos
> > bronzeplex was a combination of two sysplexes. If that is the case ...
> 
> A "classic" bronzeplex is two or more JESplexes within a single sysplex.
> 
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Paul Gilmartin]

On Sat, 30 Jan 2016 20:54:20 -0500, Robert A. Rosenberg wrote:

>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. ...
>
I said it was hard.  I said also that it's important.  I don't believe it's
impossible.

> ...  IOW: The Volume that the
>dataset resides on can at times be unknown until AFTER the ENQ is
>issued. ...
>
This does not preclude issuing additional ENQs, SHR, incorporating the
VOLSERs in the RNAME at the point in time that the VOLSERs become
known.

Note that I see this as in addition to, not instead of the current ENQ
performed at allocation time which does not incorporate any VOLSER.

> ...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. ...
>
You are postulating that no ENQ can be deferred until the VOLSER is knowns
This is just current practice, not axiomatically true.

Then deleting a data set or scratching an extent could issue ENQs EXC on
similar VOLSERs+DSN combinations.  If one of those ENQs fails, the data
set is on the same volume and can not be safely deleted.  If all those ENQs
succeed, the data set is on (a) separate volume(s) and may safely be
deleted.

There would be a hazard that the only instance of a DSN could be scratched
before another job opens it.  I believe this is preferable to the current
situation.  I was accustomed to this, DATA SET NOT FOUND, when a data
set was scratched but left catalogued.

>... 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.
> 
I believe ISPF EDIT issues:
o ENQ SHR on DSN (always done by allocation)
o ENQ EXC on member+DSN
... but VOLSER is not involved.  Skip's followup appears to agree with
this (or at least not to contradict it).

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Robert A. Rosenberg]

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Robert A. Rosenberg]

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
jo.skip.robin...@att.net



 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Robert A. Rosenberg
 Sent: Saturday, January 30, 2016 05:54 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

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
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Robert A. Rosenberg
> Sent: Saturday, January 30, 2016 05:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Jeffrey Holst]

On Wed, 27 Jan 2016 09:00:05 -0600, Peter Ten Eyck 
 wrote:

>A question about deleting a dataset that GRS (z/OS 1.13) has enqueued.
>
>We have two LPARs in a sysplex, each with their own catalog structure. There 
>is a dataset named the same and cataloged in each LPAR on two different 
>volumes.
>
>I would like to delete the dataset in one of the LPARs, but the name is in use 
>by the other LPAR and enqueued by GRS. Any suggestions of how to delete the 
>dataset in the LPAR (and on the volume) that is not being used? 
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

I have used the BYPASSNQ program, which is available in FILE183 of the CBTTAPE. 
It front ends IDCAMS or IEHPROGM and, as the name implies, bypasses the ENQ. I 
have found it quite useful over the years.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

I finally got TSO access. Yay for me. Meaning that I can experiment. I'm
grateful to this thread for education on what to expect in a crunch. Here's
what I found as a user who has access to the magic RACF profile. 

 

1. Allocated two SMS managed data sets from two members of the bronze-plex.
Same name, different volumes. Cataloged in two different user catalogs. That
is, two entirely different datasets associated by name only. Allocated SHR
on one system. Tried to rename on the other system. Got 'data set in use'
with no opportunity to override GRS. Total failure.

 

2. Allocated two data sets as in #1 except HLQ SYS1, no SMS involved.
Cataloged on both systems in two different master catalogs. Got the same
failure: no can do. No opportunity to override GRS. I began to doubt the
efficacy of the magic profile. 

 

3. Uncatalogued the data set in #2 on the second system. Still on the same
volume, still enqueued. Note that this cannot be done with SMS data set.
This time I got a whole nother sequence.

 

+---
--+

|   Rename Data Set In Use
|

| Command ===>
|

|
|

| Data Set Name . : SYS1.TEST.DELETE   |

| Volume  . . . . : xx
|

|
|

|   The system detected that a data set with the above name is in use
|

|   (possibly on another system) but it cannot determine whether it is the
|

|   data set you wish to rename. If it is the same data set and any program
|

|   has it open, renaming it could cause serious system and data integrity
|

|   problems.
|

|
|

|   You have the extra security authority to rename the data set even though
|

|   its name is in use. Refer to the DFSMS documentation on the RENAME macro
|

|   for further information.
|

|
|

| Instructions:
|

|   Press ENTER to override data set name protection and rename the data
|

|   set.
|

|   Enter CANCEL or EXIT to cancel the rename request.
|

|
|

|
|

+---
--+

 

I have to conclude from this experiment that cataloging makes all the
difference. SMS is a factor only because it requires that all datasets be
cataloged. If a dataset can be uncataloged, then the RACF profile allows
that dataset to be renamed despite the GRS enqueue.

.

.

.

J.O.Skip Robinson

Southern California Edison Company

Electric Dragon Team Paddler 

SHARE MVS Program Co-Manager

323-715-0595 Mobile

jo.skip.robin...@att.net

 

> -Original Message-

> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]

> On Behalf Of Jim Mulder

> Sent: Friday, January 29, 2016 01:25 PM

> To: IBM-MAIN@LISTSERV.UA.EDU

> Subject: Re: Deleting a dataset that GRS has enqueued.

> 

> > We took the easy way out and brought down the two STCs that had the

> > SMS dataset enqueued, then deleted the version of the dataset that was

> > not being used.

> >

> > It was mentioned in this thread that GRS could have been modified to

> > change the scope of the enqueue on the LPAR that the dataset was not

> > being used on by making it local. Therefore no longer considered in

> > use by GRS. I did not try this, but wonder if this was done for a

> > dataset that was already enqueued if this would work... thoughts?

> >

> > I never found or saw mention a straight forward IBM supported way to

> > delete or rename a SMS dataset in this situation.  If someone comes

> > across a way please post I am curious.

> 

> I asked Wayne Rhoten about this.  He replied:

> 

> "I worked on that project and wrote some of the code.  I think that the
reason

> that it does not apply to an SMS-managed data set is that it conflicts
with the

> concept that you cannot have two SMS-managed data sets with the same

> name.  The project was designed for the system programmer that is building

> another system.  For example he might have multiple SYS1.MACLIBs."

> 

>   So dealing with the situation of having separate catalogs and SMS-plexes

> within the same sysplex (and thus allowing more than one SMS-managed data

> set with the same name in the same sysplex) was not a design consideration

> for that project.

> 

> Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

> 

> 

> --

> For IBM-MAIN subscribe / signoff / archive access instructions, send email
to

>  <mailto:lists...@listserv.ua.edu> lists...@listserv.ua.edu with the
message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Tom Marchant]

On Fri, 29 Jan 2016 13:46:32 -0600, Peter Ten Eyck wrote:

>It was mentioned in this thread that GRS could have been modified 
>to change the scope of the enqueue on the LPAR that the dataset 
>was not being used on by making it local. Therefore no longer 
>considered in use by GRS. I did not try this, but wonder if this was 
>done for a dataset that was already enqueued if this would work... 
>thoughts?

No. According to "Changing the RNL" in "MVS Planning: Global Resource 
Serialization", "If a job currently holds one or more of the affected 
resources, 
the change is delayed until that job frees any affected resources."

Otherwise, you could have a confused state. A job in CPU A issues an ENQ on 
resource X with SCOPE=SYSTEMS (plural). Both CPU A and CPU B have resource 
X as enqueued.

Now, if CPU A were to change the exclusion list to include resource X, when 
CPU A issues the DEQ, it behave as if it was SCOPE=SYSTEM (singular) and 
would not propagate the DEQ to CPU B, and the resource would still appear 
to be held there.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Jim Mulder]

> We took the easy way out and brought down the two STCs that had the 
> SMS dataset enqueued, then deleted the version of the dataset that 
> was not being used.
> 
> It was mentioned in this thread that GRS could have been modified to
> change the scope of the enqueue on the LPAR that the dataset was not
> being used on by making it local. Therefore no longer considered in 
> use by GRS. I did not try this, but wonder if this was done for a 
> dataset that was already enqueued if this would work... thoughts?
> 
> I never found or saw mention a straight forward IBM supported way to
> delete or rename a SMS dataset in this situation.  If someone comes 
> across a way please post I am curious.

I asked Wayne Rhoten about this.  He replied:

"I worked on that project and wrote some of the code.  I think 
that the reason that it does not apply to an SMS-managed data set is 
that it conflicts with the concept that you cannot have two 
SMS-managed data sets with the same name.  The project was designed for 
the system programmer that is building another system.  For example he 
might have multiple SYS1.MACLIBs."

  So dealing with the situation of having separate catalogs and 
SMS-plexes within the same sysplex (and thus allowing more than one
SMS-managed data set with the same name in the same sysplex) was not
a design consideration for that project. 
 
Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Doug Henry]

I will admit that I haven't followed this entire thread but this facility is 
designed to rename datasets that exist on multiple volumes (like ipl volumes). 
For SMS managed datasets they must be cataloged and therefore can't exist on 
multiple volumes.
Therefore the enq is held because that dataset is the one it is held for.
Am I missing something ?

Doug

On Thu, 28 Jan 2016 08:37:36 -0800, Skip Robinson  
wrote:

>I for one would appreciate a comment from someone in DFSMS on this topic. It's 
>really important to know *in advance* whether the RACF approach will work for 
>an SMS managed dataset. Or an experiment by someone who can actually try it. 
>(Unfortunately I cannot at the moment.)
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Walt Farrell
>>  wrote:
>> 
>> >I thought from discussions here a few years ago that IBM has provided a
>> >facility that supports renaming of an ENQUEUEd DSN, in the VTOC, after
>> >requesting confirmation from the operators' console that that DSN on
>> >that volume is *not* the one to which the ENQ pertains.
>> >
>> >Don't know how it interacts with catalog, SMS, indexed VTOCs, automated
>> >operations, ...  This amounts to institutionalizing the technique of
>> >zapping the VTOC while placing the integrity burden on a human being.
>> 
>> Yes, via the RACF profiles previously mentioned. But someone else pointed out
>> the line in the documentation stating "Does not work for SMS-managed data
>> sets."
>> 
>> I have no idea why that restriction exists. I don't recall hearing about it 
>> when
>> we in RACF designed our part of that support.
>> 
>> --
>> Walt
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

I for one would appreciate a comment from someone in DFSMS on this topic. It's 
really important to know *in advance* whether the RACF approach will work for 
an SMS managed dataset. Or an experiment by someone who can actually try it. 
(Unfortunately I cannot at the moment.)

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Walt Farrell
> Sent: Thursday, January 28, 2016 06:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> 
> On Wed, 27 Jan 2016 18:40:45 -0600, Paul Gilmartin
> <paulgboul...@aim.com> wrote:
> 
> >I thought from discussions here a few years ago that IBM has provided a
> >facility that supports renaming of an ENQUEUEd DSN, in the VTOC, after
> >requesting confirmation from the operators' console that that DSN on
> >that volume is *not* the one to which the ENQ pertains.
> >
> >Don't know how it interacts with catalog, SMS, indexed VTOCs, automated
> >operations, ...  This amounts to institutionalizing the technique of
> >zapping the VTOC while placing the integrity burden on a human being.
> 
> Yes, via the RACF profiles previously mentioned. But someone else pointed out
> the line in the documentation stating "Does not work for SMS-managed data
> sets."
> 
> I have no idea why that restriction exists. I don't recall hearing about it 
> when
> we in RACF designed our part of that support.
> 
> --
> Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

What you're missing is that the world can be more complicated than the playbook 
indicates. We for example created a 'bronze-plex' some years ago. (Please lower 
your flame throwers.) We bolted together two different sysplexes in order to 
satisfy an IBM requirement for sysplex pricing. These sysplexes had different 
histories representing different workloads and different users. Simply mushing 
everything together into one mud pie was out of the question. So the systems 
share as little as required for sysplex to function.

This means that the systems have multiple datasets of the same name residing on 
different volumes. GRS however is a sysplex function, so there's only one. GRS 
does not know from volume, only dataset name. Hence an enqueue on one system 
creates a 'false contention' on the other system for that DSN. We have managed 
through process tweaks and user education to live with this discomfort. But if 
we needed to whack one of the datasets for whatever reason, we would hit this 
very problem. Does SMS complicate cleanup?

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Doug Henry
> Sent: Thursday, January 28, 2016 08:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> 
> I will admit that I haven't followed this entire thread but this facility is
> designed to rename datasets that exist on multiple volumes (like ipl volumes).
> For SMS managed datasets they must be cataloged and therefore can't exist
> on multiple volumes.
> Therefore the enq is held because that dataset is the one it is held for.
> Am I missing something ?
> 
> Doug
> 
> On Thu, 28 Jan 2016 08:37:36 -0800, Skip Robinson
> <jo.skip.robin...@att.net> wrote:
> 
> >I for one would appreciate a comment from someone in DFSMS on this
> >topic. It's really important to know *in advance* whether the RACF
> >approach will work for an SMS managed dataset. Or an experiment by
> >someone who can actually try it. (Unfortunately I cannot at the
> >moment.)
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> >> On Behalf Of Walt Farrell <paulgboul...@aim.com> wrote:
> >>
> >> >I thought from discussions here a few years ago that IBM has
> >> >provided a facility that supports renaming of an ENQUEUEd DSN, in
> >> >the VTOC, after requesting confirmation from the operators' console
> >> >that that DSN on that volume is *not* the one to which the ENQ pertains.
> >> >
> >> >Don't know how it interacts with catalog, SMS, indexed VTOCs,
> >> >automated operations, ...  This amounts to institutionalizing the
> >> >technique of zapping the VTOC while placing the integrity burden on a
> human being.
> >>
> >> Yes, via the RACF profiles previously mentioned. But someone else
> >> pointed out the line in the documentation stating "Does not work for
> >> SMS-managed data sets."
> >>
> >> I have no idea why that restriction exists. I don't recall hearing
> >> about it when we in RACF designed our part of that support.
> >>
> >> --
> >> Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Ed Gould]

On Jan 28, 2016, at 8:51 AM, Walt Farrell wrote:

On Wed, 27 Jan 2016 18:40:45 -0600, Paul Gilmartin  
 wrote:


I thought from discussions here a few years ago that IBM has  
provided a
facility that supports renaming of an ENQUEUEd DSN, in the VTOC,  
after
requesting confirmation from the operators' console that that DSN  
on that

volume is *not* the one to which the ENQ pertains.

Don't know how it interacts with catalog, SMS, indexed VTOCs,  
automated
operations, ...  This amounts to institutionalizing the technique  
of zapping

the VTOC while placing the integrity burden on a human being.


Yes, via the RACF profiles previously mentioned. But someone else  
pointed out the line in the documentation stating "Does not work  
for SMS-managed data sets."


I have no idea why that restriction exists. I don't recall hearing  
about it when we in RACF designed our part of that support.




Walt:

As a guess. All SMS datasets must be cataloged.

Although in all reality you could catalog a  "dummy" entry and zap  
the dsn to the dummy entry and sms would not know the difference.
Of course you would have to disable new allocations (DISNEW) to the  
volume while you did this (forgot to mention in my entry).

After the zap was done you would re-enable the vol volume.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Gibney, David Allen,Jr]

Gilbert's BYPASSNQ would be my choice if SMS prevents the newer RACF controlled 
RENAME/DELETE path. I only temporarily APF the loadlib long enough to get the 
job done. Haven't needed to in years.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Peter Ten Eyck
> Sent: Wednesday, January 27, 2016 7:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Deleting a dataset that GRS has enqueued.
> 
> A question about deleting a dataset that GRS (z/OS 1.13) has enqueued.
> 
> We have two LPARs in a sysplex, each with their own catalog structure. There
> is a dataset named the same and cataloged in each LPAR on two different
> volumes.
> 
> I would like to delete the dataset in one of the LPARs, but the name is in use
> by the other LPAR and enqueued by GRS. Any suggestions of how to delete
> the dataset in the LPAR (and on the volume) that is not being used?
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Joel C. Ewing]

On 01/28/2016 10:37 AM, Skip Robinson wrote:
> I for one would appreciate a comment from someone in DFSMS on this topic. 
> It's really important to know *in advance* whether the RACF approach will 
> work for an SMS managed dataset. Or an experiment by someone who can actually 
> try it. (Unfortunately I cannot at the moment.)
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> jo.skip.robin...@att.net
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Walt Farrell
>> Sent: Thursday, January 28, 2016 06:52 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
>>
>> On Wed, 27 Jan 2016 18:40:45 -0600, Paul Gilmartin
>> <paulgboul...@aim.com> wrote:
>>
>>> I thought from discussions here a few years ago that IBM has provided a
>>> facility that supports renaming of an ENQUEUEd DSN, in the VTOC, after
>>> requesting confirmation from the operators' console that that DSN on
>>> that volume is *not* the one to which the ENQ pertains.
>>>
>>> Don't know how it interacts with catalog, SMS, indexed VTOCs, automated
>>> operations, ...  This amounts to institutionalizing the technique of
>>> zapping the VTOC while placing the integrity burden on a human being.
>> Yes, via the RACF profiles previously mentioned. But someone else pointed out
>> the line in the documentation stating "Does not work for SMS-managed data
>> sets."
>>
>> I have no idea why that restriction exists. I don't recall hearing about it 
>> when
>> we in RACF designed our part of that support.
>>
>> --
>> Walt
>
There seems to have been all sorts of impediments put in place to
prevent one from touching SMS data sets from a system on which they are
not properly cataloged.  My recollection is that it was not possible to
allocate and actually open even an un-enqueued SMS library on a
specified volume from a running system whose catalogs indicated a
different volume without getting a failure.  Renaming an
apparently-enqueued data set would be a more unnatural act than this,
yet there obviously should be a better way to do this than with kludges.

There ought to be some restricted way (assuming it's not there already
and just unadvertised), with IDCAMS commands and without the kludges
everyone has been describing here and with proper RACF authorization,
for a System Programmer to rename, delete, or create an SMS data set on
a specific Volume and in a specific Catalog that belong to another
*inactive* system, even though the name may be enqueued on the running
system and the name of the data set is such that there is no way to make
it properly catalog-accessible on the running system; and since the SMS
definitions on the two systems could be incompatible, it would have to
be possible for assignment of SMS attributes on a created target data
set to be explicitly assigned and bypass any SMS definitions on the
running system.

It seemed to take decades for IBM to come up with decent  support to
allow SysProgs to rename apparently-but-not-really-enqueued data sets,
but from this thread that fix appears incomplete when SMS data sets are
involved, and an extended solution is obviously required.


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Walt Farrell]

On Thu, 28 Jan 2016 10:46:41 -0600, Doug Henry  wrote:

>I will admit that I haven't followed this entire thread but this facility is 
>designed to rename datasets that exist on multiple volumes (like ipl volumes). 
>For SMS managed datasets they must be cataloged and therefore can't exist on 
>multiple volumes.
>Therefore the enq is held because that dataset is the one it is held for.
>Am I missing something ?

It's certainly true that an SMS-managed data set must be cataloged, but we're 
also talking in the OP's scenario of data sets on different systems in the 
sysplex. As each system can (must?) have its own catalog it's certainly the 
case that you could have multiple SMS-managed data sets with the same name, and 
ENQed, within the sysplex. So the facility to delete or rename one of them is 
still needed, even when they're SMS-managed.

In a single-system environment the restriction makes sense, but not in a 
multi-system environment.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Walt Farrell]

On Wed, 27 Jan 2016 18:40:45 -0600, Paul Gilmartin  wrote:

>I thought from discussions here a few years ago that IBM has provided a
>facility that supports renaming of an ENQUEUEd DSN, in the VTOC, after
>requesting confirmation from the operators' console that that DSN on that
>volume is *not* the one to which the ENQ pertains.
>
>Don't know how it interacts with catalog, SMS, indexed VTOCs, automated
>operations, ...  This amounts to institutionalizing the technique of zapping
>the VTOC while placing the integrity burden on a human being.

Yes, via the RACF profiles previously mentioned. But someone else pointed out 
the line in the documentation stating "Does not work for SMS-managed data sets."

I have no idea why that restriction exists. I don't recall hearing about it 
when we in RACF designed our part of that support.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Walt Farrell]

On Wed, 27 Jan 2016 19:18:26 +, Vernooij, CP (ITOPT1) - KLM 
 wrote:

> What is wrong with this solution, it is the easiest in my opinion: update 
> parmlib- set grs - delete.
>
>You can tell GRS to keep the ENQ for that DSNAME local in the GRSRNLxx parmlib 
>member. In that case the name must be available only 
>in the LPAR where you do the delete.
>
>Example:
>RNLDEF RNL(EXCL) TYPE(SPECIFIC)  
>QNAME(SYSDSN)
>RNAME(SYS1.DAE) 

Will GRS allow you to change the RNL specifications for a resource that is 
already ENQ'd? Or, perhaps a more accurate question: will the change take 
effect before the resource becomes DEQ'd everywhere?

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Robert A. Rosenberg]

At 10:32 -0600 on 01/27/2016, Tom Marchant wrote about Re: Deleting a 
dataset that GRS has enqueued.:



On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote:


Try disabling the VVDS on the volume
amaspzap the dataset to change the name.
delete the dataset with iehprogm
enable the vvds on the volume


ITYM disable the VTOC index. I wouldn't want to do it that way.
I think that what Kees suggested is a better solution. Tell GRS
not to propagate the ENQ.

--
Tom Marchant


If you are going to go the amaspzap route but do not want to 
disable/enable the vvds, there is a simpler way of cleaning up the 
vvds. There is a "VVDS is Dirty" bit in the VTOC Format 4 record. Use 
Superzap to display its current state (there is a special Dataset 
Name that accesses the needed Format 4 record and gives you full 
access to the VTOC). Now do the Dataset rename, run IEHPROGM, and zap 
the byte to flip the bit on. The operating system will see the bit 
set and rebuild the VVDS for you. Note that the dirty bit might be 
for a dirty VTOC but I think that the VVDS will will be rebuilt in 
this case. Also the Dataset's Format 1 record can be ZAPPED which 
will delete it for you and the VTOC will be updated to compensate due 
to the dirty flag.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Paul Gilmartin]

On Wed, 27 Jan 2016 17:33:47 -0600, Walt Farrell wrote:
>
>Will GRS allow you to change the RNL specifications for a resource that is 
>already ENQ'd? Or, perhaps a more accurate question: will the change take 
>effect before the resource becomes DEQ'd everywhere?
> 
I thought from discussions here a few years ago that IBM has provided a
facility that supports renaming of an ENQUEUEd DSN, in the VTOC, after
requesting confirmation from the operators' console that that DSN on that
volume is *not* the one to which the ENQ pertains.

Don't know how it interacts with catalog, SMS, indexed VTOCs, automated
operations, ...  This amounts to institutionalizing the technique of zapping
the VTOC while placing the integrity burden on a human being.

--- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[TonyB]

Years ago I recall a young sys prog asking for advice on this forum. She 
qualified her request by stating "but please, no system programmer tricks."
I don't call her issue but clearly a risk averse solution was desired.

Sent from BlueMail



On Jan 27, 2016, 10:26 PM, at 10:26 PM, Skip Robinson 
<jo.skip.robin...@att.net> wrote:
>I have no answer for SMS involvement, but I'm uncomfortable with
>geek-heavy
>proposals that involve unnatural acts performed under the aura of
>special
>knowledge and privilege. Zapping production volumes? Puh-lease. Even
>the GRS
>tweak has a risk. RNL can be modified dynamically, but once that's
>done, the
>next system to IPL must come up with an RNL that exactly matches the
>running
>GRSplex or it will wait state. This requirement complicates the task
>and,
>depending on the end state, may leave the DSN in question with no cross
>system protection at all. Surely that's not an intended result.
>
>As a professional group, we sysprogs need to edge away from doing
>things
>just because we know how and have the power. The king will behead a
>loose-cannon magician in favor of a semi-droll jester. (Been devouring
>Gallivant.)
>
>.
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>jo.skip.robin...@att.net
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Robert A. Rosenberg
>> Sent: Wednesday, January 27, 2016 04:59 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
>>
>> At 10:32 -0600 on 01/27/2016, Tom Marchant wrote about Re: Deleting a
>> dataset that GRS has enqueued.:
>>
>> >On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote:
>> >
>> >>Try disabling the VVDS on the volume
>> >>amaspzap the dataset to change the name.
>> >>delete the dataset with iehprogm
>> >>enable the vvds on the volume
>> >
>> >ITYM disable the VTOC index. I wouldn't want to do it that way.
>> >I think that what Kees suggested is a better solution. Tell GRS not
>to
>> >propagate the ENQ.
>> >
>> >--
>> >Tom Marchant
>>
>> If you are going to go the amaspzap route but do not want to
>disable/enable
>> the vvds, there is a simpler way of cleaning up the vvds. There is a
>"VVDS
>is
>> Dirty" bit in the VTOC Format 4 record. Use Superzap to display its
>current
>> state (there is a special Dataset Name that accesses the needed
>Format 4
>> record and gives you full access to the VTOC). Now do the Dataset
>rename,
>run
>> IEHPROGM, and zap the byte to flip the bit on. The operating system
>will
>see
>> the bit set and rebuild the VVDS for you. Note that the dirty bit
>might be
>for a
>> dirty VTOC but I think that the VVDS will will be rebuilt in this
>case.
>Also the
>> Dataset's Format 1 record can be ZAPPED which will delete it for you
>and
>the
>> VTOC will be updated to compensate due to the dirty flag.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

I have no answer for SMS involvement, but I'm uncomfortable with geek-heavy
proposals that involve unnatural acts performed under the aura of special
knowledge and privilege. Zapping production volumes? Puh-lease. Even the GRS
tweak has a risk. RNL can be modified dynamically, but once that's done, the
next system to IPL must come up with an RNL that exactly matches the running
GRSplex or it will wait state. This requirement complicates the task and,
depending on the end state, may leave the DSN in question with no cross
system protection at all. Surely that's not an intended result.

As a professional group, we sysprogs need to edge away from doing things
just because we know how and have the power. The king will behead a
loose-cannon magician in favor of a semi-droll jester. (Been devouring
Gallivant.) 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Robert A. Rosenberg
> Sent: Wednesday, January 27, 2016 04:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> 
> At 10:32 -0600 on 01/27/2016, Tom Marchant wrote about Re: Deleting a
> dataset that GRS has enqueued.:
> 
> >On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote:
> >
> >>Try disabling the VVDS on the volume
> >>amaspzap the dataset to change the name.
> >>delete the dataset with iehprogm
> >>enable the vvds on the volume
> >
> >ITYM disable the VTOC index. I wouldn't want to do it that way.
> >I think that what Kees suggested is a better solution. Tell GRS not to
> >propagate the ENQ.
> >
> >--
> >Tom Marchant
> 
> If you are going to go the amaspzap route but do not want to
disable/enable
> the vvds, there is a simpler way of cleaning up the vvds. There is a "VVDS
is
> Dirty" bit in the VTOC Format 4 record. Use Superzap to display its
current
> state (there is a special Dataset Name that accesses the needed Format 4
> record and gives you full access to the VTOC). Now do the Dataset rename,
run
> IEHPROGM, and zap the byte to flip the bit on. The operating system will
see
> the bit set and rebuild the VVDS for you. Note that the dirty bit might be
for a
> dirty VTOC but I think that the VVDS will will be rebuilt in this case.
Also the
> Dataset's Format 1 record can be ZAPPED which will delete it for you and
the
> VTOC will be updated to compensate due to the dirty flag.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Tom Marchant]

On Wed, 27 Jan 2016 19:59:13 -0500, Robert A. Rosenberg wrote:

>At 10:32 -0600 on 01/27/2016, Tom Marchant wrote about Re: Deleting a
>dataset that GRS has enqueued.:
>
>>On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote:
>>
>>>Try disabling the VVDS on the volume
>>
>>ITYM disable the VTOC index.
>
>If you are going to go the amaspzap route but do not want to
>disable/enable the vvds, 

What does "Disable the VVDS" mean?

>there is a simpler way of cleaning up the
>vvds. There is a "VVDS is Dirty" bit in the VTOC Format 4 record. 

FSVO "simpler". and ITYM VTOCIX

>Use
>Superzap to display its current state (there is a special Dataset
>Name that accesses the needed Format 4 record and gives you full
>access to the VTOC). Now do the Dataset rename, run IEHPROGM, and zap
>the byte to flip the bit on. 

Yeah, that's simpler than BUILDIX. Or not.

>The operating system will see the bit
>set and rebuild the VVDS for you. Note that the dirty bit might be
>for a dirty VTOC but I think that the VVDS will will be rebuilt in
>this case.

Again, VTOC Index, not VVDS. The information in the VVDS cannot be rebuilt 
automatically in the case of a failure. The VTOC Index is optional and can be 
rebuilt from the VTOC.

-- 
Tom Marhant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Ed Gould]

On Jan 27, 2016, at 10:43 PM, TonyB wrote:

Years ago I recall a young sys prog asking for advice on this  
forum. She qualified her request by stating "but please, no system  
programmer tricks."

I don't call her issue but clearly a risk averse solution was desired.

Sent from BlueMail


That is fine but in *THIS* entry the author asked a question with no  
such pre qualifications.

My answer would have been different if the author had said so.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Ed Gould]

Skip:

I somewhat agree with your entry, however until IBM comes up with an  
legit way of accomplishing the task you do what must be done to get  
the job done.


Ed

On Jan 27, 2016, at 10:26 PM, Skip Robinson wrote:

I have no answer for SMS involvement, but I'm uncomfortable with  
geek-heavy
proposals that involve unnatural acts performed under the aura of  
special
knowledge and privilege. Zapping production volumes? Puh-lease.  
Even the GRS
tweak has a risk. RNL can be modified dynamically, but once that's  
done, the
next system to IPL must come up with an RNL that exactly matches  
the running
GRSplex or it will wait state. This requirement complicates the  
task and,
depending on the end state, may leave the DSN in question with no  
cross

system protection at all. Surely that's not an intended result.

As a professional group, we sysprogs need to edge away from doing  
things

just because we know how and have the power. The king will behead a
loose-cannon magician in favor of a semi-droll jester. (Been devouring
Gallivant.)

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Robert A. Rosenberg
Sent: Wednesday, January 27, 2016 04:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.

At 10:32 -0600 on 01/27/2016, Tom Marchant wrote about Re: Deleting a
dataset that GRS has enqueued.:


On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote:


Try disabling the VVDS on the volume
amaspzap the dataset to change the name.
delete the dataset with iehprogm
enable the vvds on the volume


ITYM disable the VTOC index. I wouldn't want to do it that way.
I think that what Kees suggested is a better solution. Tell GRS  
not to

propagate the ENQ.

--
Tom Marchant


If you are going to go the amaspzap route but do not want to

disable/enable
the vvds, there is a simpler way of cleaning up the vvds. There is  
a "VVDS

is

Dirty" bit in the VTOC Format 4 record. Use Superzap to display its

current
state (there is a special Dataset Name that accesses the needed  
Format 4
record and gives you full access to the VTOC). Now do the Dataset  
rename,

run
IEHPROGM, and zap the byte to flip the bit on. The operating  
system will

see
the bit set and rebuild the VVDS for you. Note that the dirty bit  
might be

for a
dirty VTOC but I think that the VVDS will will be rebuilt in this  
case.

Also the
Dataset's Format 1 record can be ZAPPED which will delete it for  
you and

the

VTOC will be updated to compensate due to the dirty flag.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Dan Little]

If it is SYS1 there is a FACILITY class STGADMIN profile that will allow
you to bypass the enqueue in 3.4 for rename only if you have access to the
profile.

On Wednesday, 27 January 2016, Peter Ten Eyck 
wrote:

> Yes. The owner (in use) of the dataset is known. GRS has an enq on that
> dataset name. I am trying to delete "that dataset name" in a different LPAR
> on a different volume. I am wondering if there is a way to "notify” GRS
> that it is OK to let me delete this "version" of the dataset.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with the message:
> INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Lizette Koehler]

GRS serializes resources so datasets are protected.

When you say the OWNER IS KNOWN, who is the owner?  Some owners require special 
actions to be able to do what you do.

If you do this incorrectly, you might cause an application to come down or an 
IPL.  

By not providing the information that is requested, you might not get a 
complete process for what you want to do.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Ten Eyck
> Sent: Wednesday, January 27, 2016 8:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Deleting a dataset that GRS has enqueued.
> 
> Yes. The owner (in use) of the dataset is known. GRS has an enq on that
> dataset name. I am trying to delete "that dataset name" in a different LPAR on
> a different volume. I am wondering if there is a way to "notify” GRS that it
> is OK to let me delete this "version" of the dataset.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Vernooij, CP (ITOPT1) - KLM]

You can tell GRS to keep the ENQ for that DSNAME local in the GRSRNLxx parmlib 
member. In that case the name must be available only in the LPAR where you do 
the delete.

Example:
RNLDEF RNL(EXCL) TYPE(SPECIFIC)  
QNAME(SYSDSN)
RNAME(SYS1.DAE)  

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Ten Eyck
Sent: Wednesday, January 27, 2016 4:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Deleting a dataset that GRS has enqueued.

Yes. The owner (in use) of the dataset is known. GRS has an enq on that dataset 
name. I am trying to delete "that dataset name" in a different LPAR on a 
different volume. I am wondering if there is a way to "notify” GRS that it is 
OK to let me delete this "version" of the dataset.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Norbert Friemel]

On Wed, 27 Jan 2016 09:00:05 -0600, Peter Ten Eyck wrote:

>A question about deleting a dataset that GRS (z/OS 1.13) has enqueued.
>
>We have two LPARs in a sysplex, each with their own catalog structure. There 
>is a dataset named the same and cataloged in each LPAR on two different 
>volumes.
>
>I would like to delete the dataset in one of the LPARs, but the name is in use 
>by the other LPAR and enqueued by GRS. Any suggestions of how to delete the 
>dataset in the LPAR (and on the volume) that is not being used? 


1. Create RACF facility class profile STGADMIN.DPDSRN.olddsname, rename the 
dataset (ISPF 3.4), delete the renamed dataset
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2s382/2.6.3.4

or 

2.  Use program BYPASSNQ ( File183 http://www.cbttape.org/cbtdowns.htm )

Norbert Friemel

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Skip Robinson]

I vote for the RACF profile. This is what that mechanism was designed for. The 
dataset does not just disappear. In ISPF, you get a very explicit prompt that 
what you're doing is potentially dangerous and requires extra care. 
Furthermore, you don't need any special cleanup process afterwards as you would 
with tweaking GRS.

In my shop, creation of a special, even temporary RACF profile requires 
approval. As a senior sysprog, I'm blessed with access to profile 
STGADMIN.DPDSRN.* . This allows me to handle any dataset without hoopla. I do 
this responsibly and very infrequently. 'False contention' within GRS can cause 
production failures, not just inconvenience. I believe that a shop needs a 
process in place to fix these problems before they become Sev 1 incidents. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: Wednesday, January 27, 2016 08:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued.
> 
> On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote:
> 
> >Try disabling the VVDS on the volume
> >amaspzap the dataset to change the name.
> >delete the dataset with iehprogm
> >enable the vvds on the volume
> 
> ITYM disable the VTOC index. I wouldn't want to do it that way.
> I think that what Kees suggested is a better solution. Tell GRS not to 
> propagate
> the ENQ.
> 
> --
> Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Ed Gould]

Try disabling the VVDS on the volume
amaspzap the dataset to change the name.
delete the dataset with iehprogm
enable the vvds on the volume

Ed

On Jan 27, 2016, at 9:00 AM, Peter Ten Eyck wrote:


A question about deleting a dataset that GRS (z/OS 1.13) has enqueued.

We have two LPARs in a sysplex, each with their own catalog  
structure. There is a dataset named the same and cataloged in each  
LPAR on two different volumes.


I would like to delete the dataset in one of the LPARs, but the  
name is in use by the other LPAR and enqueued by GRS. Any  
suggestions of how to delete the dataset in the LPAR (and on the  
volume) that is not being used?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Tom Marchant]

On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote:

>Try disabling the VVDS on the volume
>amaspzap the dataset to change the name.
>delete the dataset with iehprogm
>enable the vvds on the volume

ITYM disable the VTOC index. I wouldn't want to do it that way.
I think that what Kees suggested is a better solution. Tell GRS 
not to propagate the ENQ.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Tom Marchant]

On Wed, 27 Jan 2016 09:51:56 -0600, Norbert Friemel wrote:

>1. Create RACF facility class profile STGADMIN.DPDSRN.olddsname, rename the 
>dataset (ISPF 3.4), delete the renamed dataset
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2s382/2.6.3.4

One of the conditions to be able to do this:
"The data set is not SMS-managed."

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Peter Ten Eyck]

Yes. The owner (in use) of the dataset is known. GRS has an enq on that dataset 
name. I am trying to delete "that dataset name" in a different LPAR on a 
different volume. I am wondering if there is a way to "notify” GRS that it is 
OK to let me delete this "version" of the dataset.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Tom Brennan]

I did that zap a few times until I found the BYPASSNQ program from 
Gilbert Saint-Flour.  I believe he used the old method of SVC screening 
to replace the ENQ SVC with a BR14 just for the running task, then he 
called the program specified on the parm.  A genius method, but of 
course this was before the RACF option was available.


//BYPASSNQ EXEC PGM=BYPASSNQ,PARM=IEHPROGM
//STEPLIB  DD   DSN=SOME.APFAUTH.LOAD.LIBRARY,DISP=SHR 


//VOL  DD   UNIT=DISK,VOL=SER=R16RES,DISP=OLD
//SYSPRINT DD   SYSOUT=*
//SYSINDD   *
 RENAME DSNAME=SYS1.SCSQANLE,VOL=3390=R16RES,NEWNAME=SYS2.SCSQANLE

Ed Gould wrote:

Try disabling the VVDS on the volume
amaspzap the dataset to change the name.
delete the dataset with iehprogm
enable the vvds on the volume

Ed

On Jan 27, 2016, at 9:00 AM, Peter Ten Eyck wrote:


A question about deleting a dataset that GRS (z/OS 1.13) has enqueued.

We have two LPARs in a sysplex, each with their own catalog  
structure. There is a dataset named the same and cataloged in each  
LPAR on two different volumes.


I would like to delete the dataset in one of the LPARs, but the  name 
is in use by the other LPAR and enqueued by GRS. Any  suggestions of 
how to delete the dataset in the LPAR (and on the  volume) that is not 
being used?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Peter Ten Eyck]

Good info thanks. Sadly the dataset is SMS managed. So reading the 
documentation you provided, it does not seem like that will work. Scratching 
head still..

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Vernooij, CP (ITOPT1) - KLM]

What is wrong with this solution, it is the easiest in my opinion: update 
parmlib- set grs - delete.

You can tell GRS to keep the ENQ for that DSNAME local in the GRSRNLxx parmlib 
member. In that case the name must be available only in the LPAR where you do 
the delete.

Example:
RNLDEF RNL(EXCL) TYPE(SPECIFIC)  
QNAME(SYSDSN)
RNAME(SYS1.DAE)  

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Ten Eyck
Sent: Wednesday, January 27, 2016 4:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Deleting a dataset that GRS has enqueued.

Yes. The owner (in use) of the dataset is known. GRS has an enq on that dataset 
name. I am trying to delete "that dataset name" in a different LPAR on a 
different volume. I am wondering if there is a way to "notify” GRS that it is 
OK to let me delete this "version" of the dataset.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Ed Gould]

On Jan 27, 2016, at 9:53 AM, Elardus Engelbrecht wrote:


Ed Gould wrote:


Try disabling the VVDS on the volume
amaspzap the dataset to change the name.
delete the dataset with iehprogm
enable the vvds on the volume


You're a dangerous fella!  ;-)

Good advice, but that is not for the faint hearted...



SNIP


Of course you are correct. But each person should know his  
environment and I do mean know.


I expect the person asking on here to know his job and part of the  
job is to be able situations like this.


If he/she doesn't then he should state his expertise (or lack there of).

If he/she is not knowledgeable then they should say so.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Peter Ten Eyck]

Yes, this is good. I will try that. Thanks.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Ed Gould]

On Jan 27, 2016, at 11:24 AM, Tom Brennan wrote:

I did that zap a few times until I found the BYPASSNQ program from  
Gilbert Saint-Flour.  I believe he used the old method of SVC  
screening to replace the ENQ SVC with a BR14 just for the running  
task, then he called the program specified on the parm.  A genius  
method, but of course this was before the RACF option was available.


//BYPASSNQ EXEC PGM=BYPASSNQ,PARM=IEHPROGM
//STEPLIB  DD   DSN=SOME.APFAUTH.LOAD.LIBRARY,DISP=SHR
//VOL  DD   UNIT=DISK,VOL=SER=R16RES,DISP=OLD
//SYSPRINT DD   SYSOUT=*
//SYSINDD   *
 RENAME DSNAME=SYS1.SCSQANLE,VOL=3390=R16RES,NEWNAME=SYS2.SCSQANLE


I abhor any front ending PERIOD even from vendors.
I ask vendors before buying their product if they do so and reject  
any that do.


Ed


Ed Gould wrote:

Try disabling the VVDS on the volume
amaspzap the dataset to change the name.
delete the dataset with iehprogm
enable the vvds on the volume
Ed
On Jan 27, 2016, at 9:00 AM, Peter Ten Eyck wrote:
A question about deleting a dataset that GRS (z/OS 1.13) has  
enqueued.


We have two LPARs in a sysplex, each with their own catalog   
structure. There is a dataset named the same and cataloged in  
each  LPAR on two different volumes.


I would like to delete the dataset in one of the LPARs, but the   
name is in use by the other LPAR and enqueued by GRS. Any   
suggestions of how to delete the dataset in the LPAR (and on the   
volume) that is not being used?
 
--

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM- 
MAIN
- 
-

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM- 
MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Deleting a dataset that GRS has enqueued.

[Peter Ten Eyck]

A question about deleting a dataset that GRS (z/OS 1.13) has enqueued.

We have two LPARs in a sysplex, each with their own catalog structure. There is 
a dataset named the same and cataloged in each LPAR on two different volumes.

I would like to delete the dataset in one of the LPARs, but the name is in use 
by the other LPAR and enqueued by GRS. Any suggestions of how to delete the 
dataset in the LPAR (and on the volume) that is not being used? 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Lizette Koehler]

Could you do a D GRS,RES=(*,datasetname) and show the results?

GRS reports owners, so it would help to know what tasks (like LLA) might be 
holding the resource.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Ten Eyck
> Sent: Wednesday, January 27, 2016 8:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Deleting a dataset that GRS has enqueued.
> 
> A question about deleting a dataset that GRS (z/OS 1.13) has enqueued.
> 
> We have two LPARs in a sysplex, each with their own catalog structure. There
> is a dataset named the same and cataloged in each LPAR on two different
> volumes.
> 
> I would like to delete the dataset in one of the LPARs, but the name is in use
> by the other LPAR and enqueued by GRS. Any suggestions of how to delete the
> dataset in the LPAR (and on the volume) that is not being used?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Deleting a dataset that GRS has enqueued.

[Leonardo Vaz]

First, make sure the one you are deleting is not the one I use, then you can 
3.4 passing the VOLSER so you rename the dataset on the volume level (not 
catalogued), to any DSN that is not in use. Then you can delete the renamed 
dataset.

Again, make sure the one you are deleting is not the one I use.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Ten Eyck
Sent: Wednesday, January 27, 2016 10:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting a dataset that GRS has enqueued.

A question about deleting a dataset that GRS (z/OS 1.13) has enqueued.

We have two LPARs in a sysplex, each with their own catalog structure. There is 
a dataset named the same and cataloged in each LPAR on two different volumes.

I would like to delete the dataset in one of the LPARs, but the name is in use 
by the other LPAR and enqueued by GRS. Any suggestions of how to delete the 
dataset in the LPAR (and on the volume) that is not being used? 
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN