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
