I love getting affirmation after all these years, but I'm still a bit queasy. All I did was change from GRS ring to star. No RNL changes. Is the 'QNAME=SYSZVVDS RNAME=volser' conversion still explained?
Note that, despite years of IBM recommendations, we do not convert RESERVE to ENQ because we have a handful of MIA data sets shared across sysplexes, across data centers. I have always been afraid to throw those guys to the wolves. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mark Zelden Sent: Friday, April 07, 2017 2:04 PM To: [email protected] Subject: (External):Re: RLS for catalogs On Thu, 6 Apr 2017 11:35:47 -0500, Mark Zelden <[email protected]> wrote: >On Thu, 6 Apr 2017 15:56:29 +0000, Jesse 1 Robinson <[email protected]> >wrote: > >>This goes back several years when CF and memory resources were more expensive >>and less flexible than today. Think standalone CF where a memory >upgrade was >>a huge PITA. We had one single-system parallel sysplex that I had refrained >>from turning over to GRS star. It was only one system, after all, so >what >>could be harm in running GRS ring? Star would be a waste of resources, I >>thought. >> >>One particular housekeeping job ran daily in every sysplex. It did a massive >>LISTCAT. We noticed that this job ran two or three times longer (!) on this >>one >system as compared with other sysplexes that made use of GRS star. I >>could not find any plausible difference other than GRS configuration. So on a >>hunch I >bit the bullet and implemented GRS star. Sure enough, the elapsed >>time for the big LISTCAT job immediately dropped to a value in line with the >>other >sysplexes. That's on a system that did not actually share resources >>with any other. Not a scientific observation, but I'm as convinced as any UFO >>witness ever >was. > >Wow! I believe you, but I'd love to hear the technical explanation for that >from an IBM >GRS and/or sysplex guru considering it was a single system. I can only guess >that >it was just a different code path taken that was more efficient and it >didn't have anything to do with delays in propagating ENQs. Or maybe >there were reserves involved that went away with GRS STAR, but I wouldn't >think so with just a LISTCAT. > >Going back to the "old days" if you really had a single system you >didn't want to gen the DASD as shared and that would avoid RESERVEs from being >issued. > >I'm feeling old now... :-) > I just ran a test in a sandbox MIM (MII) environment (2 system sysplex) and LISTCAT ALL does does cause the CATALOG address space to do reserves on QNAME=SYSZVVDS RNAME=volser for the volumes that have cataloged data sets. Makes complete sense now that I think about it, because how else could LISTCAT get VVR and NVR data for the LISTCAT. So going to GRS STAR and converting SYSZVVDS to a global ENQ would explain how much faster the LISTCAT job ran - even on a single system assuming the DASD is gen'd as shared. Mystery solved. :-) Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:[email protected] Cell: 847-602-6870 Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
