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
Deleting a dataset that GRS has enqueued.
...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
Re: Deleting a dataset that GRS has enqueued.
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.
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
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.
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.
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.
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.
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.
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.
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... 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? and >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. No, this is WAD! There is not a way to tell GRS you want to bypass it. You're just trying to bypass the integrity of z/OS. Please reread Lizette's good advice. She is a serious expert, trust me! I would suggest that you stop that owner, get rid of the offending dataset by RENAMING (not delete) it and catalog it if needed and start that owner. If the owner is running fine, you can then delete that offending dataset. And no, as a RACF admin, I will not give access with a special profile to delete that reserved dataset. Groete / Greetings Elardus Engelbrecht -- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Re: Deleting a dataset that GRS has enqueued.
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.
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.
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.
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.
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.
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 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: 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.
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.
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.
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 > 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.
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.
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 > 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 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.
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.
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.
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.
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 >> 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.
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.
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. Thanks for the help. -- 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.
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.
> 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.
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.
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 w
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.
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.
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.
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.
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.
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.
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.
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.
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.
(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