Re: GRS Ring complex on next generation of processors
Not to mention the pathetic performance of ring disruption/resync in non-XCF RING mode. On Tue, Aug 9, 2011 at 8:09 PM, Shane Ginnane wrote: > On Wed, Aug 10th, 2011 at 7:18 AM, Scott Rowe wrote: > > > I would consider using a base Sysplex across all your LPARs, and have GRS > > use XCF signalling over FICON CTC. This is a far superior solution over > > the older style of GRS-Ring, and it gets you all the other benefits of > > Sysplex. > > Absolutely agree. Works a treat - and makes the definition debacle a whole > lot easier to manage. > > Shane ... > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS Ring complex on next generation of processors
On Wed, Aug 10th, 2011 at 7:18 AM, Scott Rowe wrote: > I would consider using a base Sysplex across all your LPARs, and have GRS > use XCF signalling over FICON CTC. This is a far superior solution over > the older style of GRS-Ring, and it gets you all the other benefits of > Sysplex. Absolutely agree. Works a treat - and makes the definition debacle a whole lot easier to manage. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS Ring complex on next generation of processors
I would consider using a base Sysplex across all your LPARs, and have GRS use XCF signalling over FICON CTC. This is a far superior solution over the older style of GRS-Ring, and it gets you all the other benefits of Sysplex. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS Ring complex on next generation of processors
W dniu 2011-08-09 21:43, William Bishop pisze: As IBM has announced that the z196/z114 will be the last generation of processors that support ESCON channels, how do I get my GRS ring environment to use FICON? The documentation states that GRS Rings have to use ESCON and the documentation states that if I have LPARs not in a sysplex that share the GRS environment, they have to use a Ring. I have a production sysplex with several LPARs in it. I have seperate test and sandbox LPARs that share the GRS environment with production for dataset allocations, to include RMM and HSM. I do not have a couplling facility. I use dasd-based XCF for the production sysplex components. Anyone have any ideas? Or am I missing something else? Yes, you missed IBM intention to drop such configuration out of service. FICON is present for 10+ years (was it in 9672 G5 ?), some time later CTC support for FICON was released, but never ever GRS over such CTC. In fact, even in the pre-FICON times the support for GRS required quite ancient pseudo-devices. It was obsolete then. BTW: it's not the only ***-plex which now require parallel sysplex. In the very old days one could have JES2 MAS on non-sysplexed systems. Now it's impossible. Ideas: Analyze your configuration. And decide: 1. You can live without GRS ring. 2. You can connect the systems in parallel sysplex. 3. Buy CA-MIM product. HTH -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GRS Ring complex on next generation of processors
As IBM has announced that the z196/z114 will be the last generation of processors that support ESCON channels, how do I get my GRS ring environment to use FICON? The documentation states that GRS Rings have to use ESCON and the documentation states that if I have LPARs not in a sysplex that share the GRS environment, they have to use a Ring. I have a production sysplex with several LPARs in it. I have seperate test and sandbox LPARs that share the GRS environment with production for dataset allocations, to include RMM and HSM. I do not have a couplling facility. I use dasd-based XCF for the production sysplex components. Anyone have any ideas? Or am I missing something else? Thanks Bill Bishop Specialist Mainframe Support Group Server Development & Support Toyota Motor Engineering & Manufacturing North America, Inc. bill.bis...@tema.toyota.com (502) 570-6143 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hardware RESERVE vs GRS ENQ (was: No Subject)
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of john gilmore
>
> Scott Rowe wrote:
>
> | The linkedit/Binder still uses a hardware reserve.
>
> I has been a very long time since it did so, materially as opposed to
formally. For the Linkage
> Editor the reserve has been converted into a global enq using GRS for
many years. Moreover, whjil;e I
> cannopt prove it in this OCO era, I berlieve that the reserve itself
has disappeared. The Binder
> never did use a reserve. . . .
RESERVE is still alive and well (at least is was at z/OS 1.9). Got
"burned" by it while doing an "RVARY Dance" during repair of a RACF
database in late 2009. The "offending" utility was IRRUT200, against
which APAR OA30905 was taken and closed PRS ("Permanent Restriction").
-jc-
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS CNS troubles with z/OS 1.11 RSU1006
"Markus Haselbach" wrote in message news:... > There are some system with little weight in the sysplex, mostly the GDPS > controlling system. We've tried to place the CNS on one of the stronger > images (with setgrs cns= command after IPL). The issue is so far under > control as we have a problem record open with IBM support about this. > Markus Haselbach > GDPS K-systems with little weight??? You want them to receive all resources when they are trying to rescue your system (and enterprise). Under normal circumstances, they consume little CPU no matter their high weight. Kees. 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS CNS troubles with z/OS 1.11 RSU1006
There are some system with little weight in the sysplex, mostly the GDPS controlling system. We've tried to place the CNS on one of the stronger images (with setgrs cns= command after IPL). The issue is so far under control as we have a problem record open with IBM support about this. Markus Haselbach -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS CNS troubles with z/OS 1.11 RSU1006
The CNS is very dependent on timely responses to GQSCAN requests. If any of the systems in the sysplex cannot keep up with the volume of contention being generated, these ABEND09A's are possible as the requests are single threaded. Do all of the systems in the sysplex have enough weight? Chris Brooker GRS L3 Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GRS CNS troubles with z/OS 1.11 RSU1006
We had several times grs abend S009A RSN C50C and cns (contention notification system) switched to other system in GRS star. In some cases the sytem fall out of the sysplex, in other cases it recuperated. Does someone have such issues also? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High CPU for GRS after z/OS V1.11
If you are running in STAR mode, see APAR OA33898. ~Chris Brooker GRS L3 Team Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High CPU for GRS after z/OS V1.11
Yes, but caught us on 1.10 upgrade, and took quite a while to diagnose it was this that was causing the GRS uplift. NOZFS did calm things down. On 22 September 2010 20:57, Lizette Koehler wrote: > We have been seeing GRS being 3 times higher after our z/OS V1.11 upgrade. > > I have found APAR OA33049 which seesm to apply > > > After activation of RSU 0910 the cpu consumption of the GRS > address space increased by a factor of two. > > > LOCAL FIX: > Disable in RMF III the data gathering for ZFS, i.e. > F RMF,F III,NOZFS. > > > PROBLEM SUMMARY: > > * USERS AFFECTED: zFS Releases HZFS390 * > * and HZFS3A0 and HZFS3B0 * > ******** > * PROBLEM DESCRIPTION: HIGH CPU CONSUMPTION OF GRS * > * ADDRESS SPACE WHILE RMF III * > * OPTION IS ON* > > * RECOMMENDATION: * > > RMFGAT passed an fsid_mtname on a pfsctl > for FSOP_GETSTAT_PARMDATA, causing > find_owner() to make unnecessary calls to > grs_enq_query() > > > PROBLEM CONCLUSION: > Modify agsys_send_query_filesys_owner > to use fsid name or fsid aggrname or > fsid mtname. > > > Has anyone else seen this? > > Lizette > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
High CPU for GRS after z/OS V1.11
We have been seeing GRS being 3 times higher after our z/OS V1.11 upgrade. I have found APAR OA33049 which seesm to apply After activation of RSU 0910 the cpu consumption of the GRS address space increased by a factor of two. LOCAL FIX: Disable in RMF III the data gathering for ZFS, i.e. F RMF,F III,NOZFS. PROBLEM SUMMARY: * USERS AFFECTED: zFS Releases HZFS390 * * and HZFS3A0 and HZFS3B0 * * PROBLEM DESCRIPTION: HIGH CPU CONSUMPTION OF GRS * * ADDRESS SPACE WHILE RMF III * * OPTION IS ON* * RECOMMENDATION: * RMFGAT passed an fsid_mtname on a pfsctl for FSOP_GETSTAT_PARMDATA, causing find_owner() to make unnecessary calls to grs_enq_query() PROBLEM CONCLUSION: Modify agsys_send_query_filesys_owner to use fsid name or fsid aggrname or fsid mtname. Has anyone else seen this? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
thanks !! I will call IBM to help 2010/5/12 Rob Scott : > Unlikely... > > Rob Scott > Lead Developer > Rocket Software > 275 Grove Street · Newton, MA 02466-2272 · USA > Tel: +1.617.614.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf > Of Tommy Tsui > Sent: 12 May 2010 16:20 > To: IBM-MAIN@bama.ua.edu > Subject: Re: Help! Help! I got following GRS message, how to solve it > > is it work if I restart the TSO ? > > 2010/5/12 Rob Scott : >> If that is really the case, then a TSO user ASID has crashed and burned in >> such a bad way that the SYSZIGGI ENQ did not get flushed as part of >> task/ASID termination. The most likely solution is to CALLRTM the TCB in >> ASID(0001) - you can either : >> >> (1) Call IBM to verify and get them to help - they have a L2 program that >> can do the CALLRTM for you >> (2) If you feel brave - use your MVS Monitor software to "KILL" the TCB >> yourself. >> >> I would suggest (1) unless this is a test system. >> >> Rob Scott >> Lead Developer >> Rocket Software >> 275 Grove Street * Newton, MA 02466-2272 * USA >> Tel: +1.617.614.2305 >> Email: rsc...@rs.com >> Web: www.rocketsoftware.com >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf >> Of Tommy Tsui >> Sent: 12 May 2010 16:02 >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: Help! Help! I got following GRS message, how to solve it >> >> I type "D A,ALL" & "D A,A" ..but.cannot find any A=01AC >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >> Search the archives at http://bama.ua.edu/archives/ibm-main.html >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >> Search the archives at http://bama.ua.edu/archives/ibm-main.html >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
Unlikely... Rob Scott Lead Developer Rocket Software 275 Grove Street · Newton, MA 02466-2272 · USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui Sent: 12 May 2010 16:20 To: IBM-MAIN@bama.ua.edu Subject: Re: Help! Help! I got following GRS message, how to solve it is it work if I restart the TSO ? 2010/5/12 Rob Scott : > If that is really the case, then a TSO user ASID has crashed and burned in > such a bad way that the SYSZIGGI ENQ did not get flushed as part of task/ASID > termination. The most likely solution is to CALLRTM the TCB in ASID(0001) - > you can either : > > (1) Call IBM to verify and get them to help - they have a L2 program that can > do the CALLRTM for you > (2) If you feel brave - use your MVS Monitor software to "KILL" the TCB > yourself. > > I would suggest (1) unless this is a test system. > > Rob Scott > Lead Developer > Rocket Software > 275 Grove Street * Newton, MA 02466-2272 * USA > Tel: +1.617.614.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf > Of Tommy Tsui > Sent: 12 May 2010 16:02 > To: IBM-MAIN@bama.ua.edu > Subject: Re: Help! Help! I got following GRS message, how to solve it > > I type "D A,ALL" & "D A,A" ..but.cannot find any A=01AC > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
is it work if I restart the TSO ? 2010/5/12 Rob Scott : > If that is really the case, then a TSO user ASID has crashed and burned in > such a bad way that the SYSZIGGI ENQ did not get flushed as part of task/ASID > termination. The most likely solution is to CALLRTM the TCB in ASID(0001) - > you can either : > > (1) Call IBM to verify and get them to help - they have a L2 program that can > do the CALLRTM for you > (2) If you feel brave - use your MVS Monitor software to "KILL" the TCB > yourself. > > I would suggest (1) unless this is a test system. > > Rob Scott > Lead Developer > Rocket Software > 275 Grove Street * Newton, MA 02466-2272 * USA > Tel: +1.617.614.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf > Of Tommy Tsui > Sent: 12 May 2010 16:02 > To: IBM-MAIN@bama.ua.edu > Subject: Re: Help! Help! I got following GRS message, how to solve it > > I type "D A,ALL" & "D A,A" ..but.cannot find any A=01AC > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
If that is really the case, then a TSO user ASID has crashed and burned in such a bad way that the SYSZIGGI ENQ did not get flushed as part of task/ASID termination. The most likely solution is to CALLRTM the TCB in ASID(0001) - you can either : (1) Call IBM to verify and get them to help - they have a L2 program that can do the CALLRTM for you (2) If you feel brave - use your MVS Monitor software to "KILL" the TCB yourself. I would suggest (1) unless this is a test system. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui Sent: 12 May 2010 16:02 To: IBM-MAIN@bama.ua.edu Subject: Re: Help! Help! I got following GRS message, how to solve it I type "D A,ALL" & "D A,A" ..but.cannot find any A=01AC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
Is it works if I purged all initiators and start again? 2010/5/12 Tommy Tsui : > I type "D A,ALL" & "D A,A" ..but.cannot find any A=01AC > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
I type "D A,ALL" & "D A,A" ..but.cannot find any A=01AC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
Tommy Tsui wrote: >I checked. All asid does not exist already...what can I do??? Are you sure? Do this command: D A,ALL Yes, you will get a long list, but then you can search for A=01AC Perhaps you get one with *LOGON* ... HTH! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
I checked. All asid does not exist already...what can I do??? 2010/5/12 Tommy Tsui : > I got it from the HEX value ..thanks I will check it > > 2010/5/12 Tommy Tsui : >> Can I know why ASID "01AC" ? >> >> 2010/5/12 Rob Scott : >>> You need to examine ASID x'01AC' >>> >>> If TSO user - trying getting user to press enter or cancel the user >>> >>> Rob Scott >>> Lead Developer >>> Rocket Software >>> 275 Grove Street * Newton, MA 02466-2272 * USA >>> Tel: +1.617.614.2305 >>> Email: rsc...@rs.com >>> Web: www.rocketsoftware.com >>> >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf >>> Of Tommy Tsui >>> Sent: 12 May 2010 15:19 >>> To: IBM-MAIN@bama.ua.edu >>> Subject: Re: Help! Help! I got following GRS message, how to solve it >>> >>> Here are the output after input >>> D GRS,C,RES=(SYSZIGGI,*),hex >>> >>> ISG343I 21.09.59 GRS STATUS 753 >>> S=SYSTEM SYSZIGGI >>> 0A >>> 28299779 1C >>> SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS >>> PRODSYSD *MASTER* 0001 009E27E0 EXCLUSIVE OWN >>> PRODSYSD *MASTER* 0001 009E8220 EXCLUSIVE WAIT >>> PRODSYSD *MASTER* 0001 009E2380 EXCLUSIVE WAIT >>> PRODSYSD *MASTER* 0001 009E1E88 EXCLUSIVE WAIT >>> PRODSYSD *MASTER* 0001 009E1A38 EXCLUSIVE WAIT >>> PRODSYSD *MASTER* 0001 00962E88 EXCLUSIVE WAIT >>> PRODSYSD *MASTER* 0001 00962AC0 EXCLUSIVE WAIT >>> S=SYSTEM SYSZIGGI >>> 0B >>> 28299779 17 >>> SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS >>> PRODSYSD *MASTER* 0001 009EA440 EXCLUSIVE OWN >>> PRODSYSD *MASTER* 0001 009EAE88 EXCLUSIVE WAIT >>> PRODSYSD *MASTER* 0001 009EAAC0 EXCLUSIVE WAIT >>> PRODSYSD *MASTER* 0001 009E3908 EXCLUSIVE WAIT >>> PRODSYSD *MASTER* 0001 009E34B8 EXCLUSIVE WAIT >>> PRODSYSD *MASTER* 0001 009E8E88 EXCLUSIVE WAIT >>> PRODSYSD *MASTER* 0001 009E8AC0 EXCLUSIVE WAIT >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >>> Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >>> Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
I got it from the HEX value ..thanks I will check it 2010/5/12 Tommy Tsui : > Can I know why ASID "01AC" ? > > 2010/5/12 Rob Scott : >> You need to examine ASID x'01AC' >> >> If TSO user - trying getting user to press enter or cancel the user >> >> Rob Scott >> Lead Developer >> Rocket Software >> 275 Grove Street * Newton, MA 02466-2272 * USA >> Tel: +1.617.614.2305 >> Email: rsc...@rs.com >> Web: www.rocketsoftware.com >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf >> Of Tommy Tsui >> Sent: 12 May 2010 15:19 >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: Help! Help! I got following GRS message, how to solve it >> >> Here are the output after input >> D GRS,C,RES=(SYSZIGGI,*),hex >> >> ISG343I 21.09.59 GRS STATUS 753 >> S=SYSTEM SYSZIGGI >> 0A >> 28299779 1C >> SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS >> PRODSYSD *MASTER* 0001 009E27E0 EXCLUSIVE OWN >> PRODSYSD *MASTER* 0001 009E8220 EXCLUSIVE WAIT >> PRODSYSD *MASTER* 0001 009E2380 EXCLUSIVE WAIT >> PRODSYSD *MASTER* 0001 009E1E88 EXCLUSIVE WAIT >> PRODSYSD *MASTER* 0001 009E1A38 EXCLUSIVE WAIT >> PRODSYSD *MASTER* 0001 00962E88 EXCLUSIVE WAIT >> PRODSYSD *MASTER* 0001 00962AC0 EXCLUSIVE WAIT >> S=SYSTEM SYSZIGGI >> 0B >> 28299779 17 >> SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS >> PRODSYSD *MASTER* 0001 009EA440 EXCLUSIVE OWN >> PRODSYSD *MASTER* 0001 009EAE88 EXCLUSIVE WAIT >> PRODSYSD *MASTER* 0001 009EAAC0 EXCLUSIVE WAIT >> PRODSYSD *MASTER* 0001 009E3908 EXCLUSIVE WAIT >> PRODSYSD *MASTER* 0001 009E34B8 EXCLUSIVE WAIT >> PRODSYSD *MASTER* 0001 009E8E88 EXCLUSIVE WAIT >> PRODSYSD *MASTER* 0001 009E8AC0 EXCLUSIVE WAIT >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >> Search the archives at http://bama.ua.edu/archives/ibm-main.html >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >> Search the archives at http://bama.ua.edu/archives/ibm-main.html >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
Can I know why ASID "01AC" ? 2010/5/12 Rob Scott : > You need to examine ASID x'01AC' > > If TSO user - trying getting user to press enter or cancel the user > > Rob Scott > Lead Developer > Rocket Software > 275 Grove Street * Newton, MA 02466-2272 * USA > Tel: +1.617.614.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf > Of Tommy Tsui > Sent: 12 May 2010 15:19 > To: IBM-MAIN@bama.ua.edu > Subject: Re: Help! Help! I got following GRS message, how to solve it > > Here are the output after input > D GRS,C,RES=(SYSZIGGI,*),hex > > ISG343I 21.09.59 GRS STATUS 753 > S=SYSTEM SYSZIGGI > 0A > 28299779 1C > SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS > PRODSYSD *MASTER* 0001 009E27E0 EXCLUSIVE OWN > PRODSYSD *MASTER* 0001 009E8220 EXCLUSIVE WAIT > PRODSYSD *MASTER* 0001 009E2380 EXCLUSIVE WAIT > PRODSYSD *MASTER* 0001 009E1E88 EXCLUSIVE WAIT > PRODSYSD *MASTER* 0001 009E1A38 EXCLUSIVE WAIT > PRODSYSD *MASTER* 0001 00962E88 EXCLUSIVE WAIT > PRODSYSD *MASTER* 0001 00962AC0 EXCLUSIVE WAIT > S=SYSTEM SYSZIGGI > 0B > 28299779 17 > SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS > PRODSYSD *MASTER* 0001 009EA440 EXCLUSIVE OWN > PRODSYSD *MASTER* 0001 009EAE88 EXCLUSIVE WAIT > PRODSYSD *MASTER* 0001 009EAAC0 EXCLUSIVE WAIT > PRODSYSD *MASTER* 0001 009E3908 EXCLUSIVE WAIT > PRODSYSD *MASTER* 0001 009E34B8 EXCLUSIVE WAIT > PRODSYSD *MASTER* 0001 009E8E88 EXCLUSIVE WAIT > PRODSYSD *MASTER* 0001 009E8AC0 EXCLUSIVE WAIT > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
You need to examine ASID x'01AC' If TSO user - trying getting user to press enter or cancel the user Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui Sent: 12 May 2010 15:19 To: IBM-MAIN@bama.ua.edu Subject: Re: Help! Help! I got following GRS message, how to solve it Here are the output after input D GRS,C,RES=(SYSZIGGI,*),hex ISG343I 21.09.59 GRS STATUS 753 S=SYSTEM SYSZIGGI 0A 28299779 1C SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS PRODSYSD *MASTER* 0001 009E27E0 EXCLUSIVEOWN PRODSYSD *MASTER* 0001 009E8220 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E2380 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E1E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E1A38 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 00962E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 00962AC0 EXCLUSIVEWAIT S=SYSTEM SYSZIGGI 0B 28299779 17 SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS PRODSYSD *MASTER* 0001 009EA440 EXCLUSIVEOWN PRODSYSD *MASTER* 0001 009EAE88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009EAAC0 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E3908 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E34B8 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E8E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E8AC0 EXCLUSIVEWAIT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
Here are the output after input D GRS,C,RES=(SYSZIGGI,*),hex ISG343I 21.09.59 GRS STATUS 753 S=SYSTEM SYSZIGGI 0A 28299779 1C SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS PRODSYSD *MASTER* 0001 009E27E0 EXCLUSIVEOWN PRODSYSD *MASTER* 0001 009E8220 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E2380 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E1E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E1A38 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 00962E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 00962AC0 EXCLUSIVEWAIT S=SYSTEM SYSZIGGI 0B 28299779 17 SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS PRODSYSD *MASTER* 0001 009EA440 EXCLUSIVEOWN PRODSYSD *MASTER* 0001 009EAE88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009EAAC0 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E3908 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E34B8 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E8E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E8AC0 EXCLUSIVEWAIT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
On Wed, 12 May 2010 08:00:34 -0500, Patrick Lyon wrote: >On Wed, 12 May 2010 20:48:13 +0800, Tommy Tsui > wrote: > >>Hi all, >>I got the following messages in our production LPAR, D GRS,C, I can't >>find who enqueue the *MASTER*, how can I find it??? >>Please help!! > >Try a D GRS,AN,BLOCKER command Tommy > I had never seen that SYSZIGGI major ENQ name before. I checked the z/OS 1.10 diagnosis manual and didn't find it documented. However, it is documented in the 1.11 version (without a "new bar" next to it). The doc says it is TSB - IGC0009C, IGG09302 I guess IGG09302 is a CSECT for IGC009C (SVC 93 - TGET/TPUT) and must be used for some (TSB) terminal status block serialization. Even though I had never heard of this one, it isn't new. Search IBMLINK for SYSZIGGI and you'll find plenty of hits including a user error leading to a problem (large number of messages sent to a TSO user who did not hit enter). Do you have any "tso app" running under master? (perhaps an automation product or TSSO)? Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
On 05/12/10 09:08, Tommy Tsui wrote: Also, I always got following messages, our system upgraded to z/os 1.11 last week and we can't find any errors on z/os 1.9 ISG376I GLOBAL RESOURCE SERIALIZATION FREEING STORAGE BUFFERS DUE TO BUFFER THRESHOLD EXCEEDED DIAG=0004 ISG376I GLOBAL RESOURCE SERIALIZATION FREEING STORAGE BUFFERS DUE TO BUFFER THRESHOLD EXCEEDED DIAG=0002 ISG376I GLOBAL RESOURCE SERIALIZATION FREEING STORAGE BUFFERS DUE TO BUFFER THRESHOLD EXCEEDED DIAG=0005 Take a look at apar OA2932. -- Mark Jacobs Time Customer Service Tampa, FL It is impossible to make anything foolproof, because fools are so ingenious. -- Robert Heinlein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
Also, I always got following messages, our system upgraded to z/os 1.11 last week and we can't find any errors on z/os 1.9 ISG376I GLOBAL RESOURCE SERIALIZATION FREEING STORAGE BUFFERS DUE TO BUFFER THRESHOLD EXCEEDED DIAG=0004 ISG376I GLOBAL RESOURCE SERIALIZATION FREEING STORAGE BUFFERS DUE TO BUFFER THRESHOLD EXCEEDED DIAG=0002 ISG376I GLOBAL RESOURCE SERIALIZATION FREEING STORAGE BUFFERS DUE TO BUFFER THRESHOLD EXCEEDED DIAG=0005 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui > Sent: Wednesday, May 12, 2010 7:48 AM > To: IBM-MAIN@bama.ua.edu > Subject: Help! Help! I got following GRS message, how to solve it > > Hi all, > I got the following messages in our production LPAR, D GRS,C, I can't > find who enqueue the *MASTER*, how can I find it??? > Please help!! > S=SYSTEM SYSZIGGI > SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS > PRODSYSD *MASTER* 0001 009E27E0 EXCLUSIVEOWN > PRODSYSD *MASTER* 0001 009E8220 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 009E2380 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 009E1E88 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 009E1A38 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 00962E88 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 00962AC0 EXCLUSIVEWAIT > S=SYSTEM SYSZIGGI > SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS > PRODSYSD *MASTER* 0001 009EA440 EXCLUSIVEOWN > PRODSYSD *MASTER* 0001 009EAE88 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 009EAAC0 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 009E3908 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 009E34B8 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 009E8E88 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 009E8AC0 EXCLUSIVEWAIT > PRODSYSD *MASTER* 0001 009E8670 EXCLUSIVEWAIT > S=SYSTEM SYSZIGGI *MASTER* is the master address space. The main address space in z/OS. >From a fast scan of IBMLink, there are two possibilities: First - do you have >a DDR swap going on? This usually happens when a tape drive has an error. Put >the tape on the new drive and that might fix the problem. The second was a cross memory TPUT to a hung TSO user. This was a very old error. I don't know any other possibilities. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
You have "OPER SEND" problems Issue the following : D GRS,C,RES=(SYSZIGGI,*),HEX >From the output you should be able to see the ASID in the minor name (careful >how you read it) Then get the user to hit enter or (most likely) cancel the ASID Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui Sent: 12 May 2010 13:48 To: IBM-MAIN@bama.ua.edu Subject: Help! Help! I got following GRS message, how to solve it Hi all, I got the following messages in our production LPAR, D GRS,C, I can't find who enqueue the *MASTER*, how can I find it??? Please help!! S=SYSTEM SYSZIGGI SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS PRODSYSD *MASTER* 0001 009E27E0 EXCLUSIVEOWN PRODSYSD *MASTER* 0001 009E8220 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E2380 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E1E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E1A38 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 00962E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 00962AC0 EXCLUSIVEWAIT S=SYSTEM SYSZIGGI SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS PRODSYSD *MASTER* 0001 009EA440 EXCLUSIVEOWN PRODSYSD *MASTER* 0001 009EAE88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009EAAC0 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E3908 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E34B8 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E8E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E8AC0 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E8670 EXCLUSIVEWAIT S=SYSTEM SYSZIGGI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
thanks all information. I got the following message after type D GRS,AN,BLOCKER D GRS,AN,BLOCKER ISG349I 21.02.34 GRS ANALYSIS 099 LONG BLOCKER ANALYSIS: ENTIRE SYSPLEX BLOCKTIME SYSTEM JOBNAME E/S SCOPE QNAMERNAME 57:59:28 PRODSYSD *MASTER**E* SYS SYSZIGGI OTHER BLOCKERS: 0 WAITERS: 34 27:40:47 PRODSYSD *MASTER**E* SYS SYSZIGGI OTHER BLOCKERS: 0 WAITERS: 7 25:33:42 PRODSYSD *MASTER**E* SYS SYSZIGGI OTHER BLOCKERS: 0 WAITERS: 6 What I can dot now? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help! Help! I got following GRS message, how to solve it
On Wed, 12 May 2010 20:48:13 +0800, Tommy Tsui wrote: >Hi all, >I got the following messages in our production LPAR, D GRS,C, I can't >find who enqueue the *MASTER*, how can I find it??? >Please help!! Try a D GRS,AN,BLOCKER command Tommy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Help! Help! I got following GRS message, how to solve it
Hi all, I got the following messages in our production LPAR, D GRS,C, I can't find who enqueue the *MASTER*, how can I find it??? Please help!! S=SYSTEM SYSZIGGI SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS PRODSYSD *MASTER* 0001 009E27E0 EXCLUSIVEOWN PRODSYSD *MASTER* 0001 009E8220 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E2380 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E1E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E1A38 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 00962E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 00962AC0 EXCLUSIVEWAIT S=SYSTEM SYSZIGGI SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS PRODSYSD *MASTER* 0001 009EA440 EXCLUSIVEOWN PRODSYSD *MASTER* 0001 009EAE88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009EAAC0 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E3908 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E34B8 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E8E88 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E8AC0 EXCLUSIVEWAIT PRODSYSD *MASTER* 0001 009E8670 EXCLUSIVEWAIT S=SYSTEM SYSZIGGI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
W dniu 2010-01-22 23:31, Glen Gasior pisze: Thank you for all the replies. The 3390 devices are defined as SHARED, and the SHAREOPTIONS on the user catalogs are (3,4). * My RTFM still leaves me with a question regarding how SHAREOPTION of (3,3) would affect access to a user catalog on a 3390 shared between two lpars, connected to two different MASTER catalogs? My memory is definitely not very good and I have no manual in hand, however what I remember is: 1. Do not even try to share BCS with SHR(3,3), 2. to be safe always define your dasd as shared. HTH -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
>Maybe a senior moment, but it could have been SYSVSAM and not SYSIGGV2 that >was converted by MIM. I'm pretty sure we had the problem with IMS 1.2 - we >were still running LOGPLUS for DASD Logging. It was definitely before MVS ESA. We had this problem in a non-IMS shared environment (Parallel SYSPLEX). And, maybe SYNCHRES was out before OS/390 2.7, but IBM recommended against it, at first. It was not well documented, at the time, and there were performance/reliability issues, at the time. We finally implemented it along with V2R10. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
Ted, Maybe a senior moment, but it could have been SYSVSAM and not SYSIGGV2 that was converted by MIM. I'm pretty sure we had the problem with IMS 1.2 - we were still running LOGPLUS for DASD Logging. It was definitely before MVS ESA. Problem 7:04/02 (PMR 15737,379,000) -- IMS 7.1 , MIM Deadly embrace on the RECON1 pack. Contention display showed one DBRC task with a hardware reserve on DSPURI01 for the RECON1 dataset and waiting for the RECON1 catalog under SYSVSAM. A second DBRC task owned the catalog under SYSVSAM and was waiting for the RECON1 dataset under DSPURI01. MSGPWSRES01 showed long waits for the pack. MSGIOS071I was indicating start pending. Customer Resolution: They needed to use SYNCHRES. Refer to apar OW26833 . * Additional Keywords PWSRES01 IOS071I HANG HUNG WAIT * > -Original Message- > From: Ron Hawkins [mailto:ron.hawkins1...@sbcglobal.net] > Sent: Saturday, January 23, 2010 1:15 AM > To: 'IBM Mainframe Discussion List' > Subject: RE: [IBM-MAIN] SHARING USER CATALOGS WITHOUT GRS > > Ted, > > Sorry Ted. I did not you there. > > The choice was to remove SYSIGGV2 from MIM or convert the reserve for the > RECON datasets to a Global ENQ. We chose the latter and the problem never > happened again. > > This was actually a fairly common problem for IMS sites after converting > SYSIGGV2 reserves with MIM or GRS. > > Ron > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf > Of > > Ted MacNEIL > > Sent: Friday, January 22, 2010 11:46 AM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: [IBM-MAIN] SHARING USER CATALOGS WITHOUT GRS > > > > >I must respectfully disagree with the idea that shared DASD using Reserve > > constitutes risk of any magnitude, and eventually will lead to deadly > > embraces. > > > > I respectfully disagree with your disagreement. > > There used to be a major issue with SYSVTOC/SYSVVDS, User Cats & IXVTOCs. > > > > The 'fix' from IBM was SYNCHRES=YES as a GRS parm. > > This came out with OS/390 V2R7, but didn't work properly for a couple of > > releases. > > IIRC, NO is still the default and, in that case, the deadly embrace is still > a > > possibility. > > > > It has nothing to do with MIM, since local ENQ/RES are still handled by GRS. > > MIM, in this case, is just the propagator of globals, just as GRS is. > > > > - > > Too busy driving to stop for gas! > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
Ted, Sorry Ted. I did not you there. The choice was to remove SYSIGGV2 from MIM or convert the reserve for the RECON datasets to a Global ENQ. We chose the latter and the problem never happened again. This was actually a fairly common problem for IMS sites after converting SYSIGGV2 reserves with MIM or GRS. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Ted MacNEIL > Sent: Friday, January 22, 2010 11:46 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] SHARING USER CATALOGS WITHOUT GRS > > >I must respectfully disagree with the idea that shared DASD using Reserve > constitutes risk of any magnitude, and eventually will lead to deadly > embraces. > > I respectfully disagree with your disagreement. > There used to be a major issue with SYSVTOC/SYSVVDS, User Cats & IXVTOCs. > > The 'fix' from IBM was SYNCHRES=YES as a GRS parm. > This came out with OS/390 V2R7, but didn't work properly for a couple of > releases. > IIRC, NO is still the default and, in that case, the deadly embrace is still a > possibility. > > It has nothing to do with MIM, since local ENQ/RES are still handled by GRS. > MIM, in this case, is just the propagator of globals, just as GRS is. > > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
Thank you for all the replies. The 3390 devices are defined as SHARED, and the SHAREOPTIONS on the user catalogs are (3,4). * My RTFM still leaves me with a question regarding how SHAREOPTION of (3,3) would affect access to a user catalog on a 3390 shared between two lpars, connected to two different MASTER catalogs? * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
Good point, but it is the opposite of what you are saying. The catalog should be defined to VLF via COFVLFxx in both systems. If the catalog is not defined to VLF, it will be in ISC.With ISC, if a change is made from one system, the entire cache will be purged on the other. So if both systems are updating this catalog, all the cache will keep getting purged. With VLF, the changes will be communicated and only those changes will get purged from the CDSC (Catalog Data Space Cache). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html On Fri, 22 Jan 2010 14:02:10 -0800, Guy Gardoit wrote: >One more point - keep the catalog(s) out of your COFVLFxx parmlib members! > >On Fri, Jan 22, 2010 at 8:43 AM, Glen Gasior wrote: > >> * >> I have a requirement to share a production USER CATALOG with a test (not >> development) lpar. Both lpars are MONOPLEX. >> * >> There is no GRS and will not be. No aliases on the test lpar will be >> assigned to >> this production lpar USER CATALOG. >> * >> I want to be certain serialization of the catalog takes place. I assume >> this will >> be via reserves. I want to be certain serialization is taking place between >> the >> two lpars on the USER CATALOG. >> * >> Please tell me of what must be in place for this to occur, especially any >> gotchas that would bypass serialization. >> * >> No new program products will be purchased. >> * >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >> Search the archives at http://bama.ua.edu/archives/ibm-main.html >> > > > >-- >Guy Gardoit >z/OS Systems Programming > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
One more point - keep the catalog(s) out of your COFVLFxx parmlib members! On Fri, Jan 22, 2010 at 8:43 AM, Glen Gasior wrote: > * > I have a requirement to share a production USER CATALOG with a test (not > development) lpar. Both lpars are MONOPLEX. > * > There is no GRS and will not be. No aliases on the test lpar will be > assigned to > this production lpar USER CATALOG. > * > I want to be certain serialization of the catalog takes place. I assume > this will > be via reserves. I want to be certain serialization is taking place between > the > two lpars on the USER CATALOG. > * > Please tell me of what must be in place for this to occur, especially any > gotchas that would bypass serialization. > * > No new program products will be purchased. > * > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- Guy Gardoit z/OS Systems Programming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
W dniu 2010-01-22 17:43, Glen Gasior pisze: * I have a requirement to share a production USER CATALOG with a test (not development) lpar. Both lpars are MONOPLEX. * There is no GRS and will not be. No aliases on the test lpar will be assigned to this production lpar USER CATALOG. * I want to be certain serialization of the catalog takes place. I assume this will be via reserves. I want to be certain serialization is taking place between the two lpars on the USER CATALOG. * Please tell me of what must be in place for this to occur, especially any gotchas that would bypass serialization. BTDT. No deadly embraces, no gotchas, no surprises. It is supported method. I always take care to share as little as possible and as inactive datasets/catalogs as possible, but got never a problem. Of course my experience is limited. BTW: Working as a consultant in foreign (not always well-managed) shops I sometimes observed such "deadly embraces". Sometimes it wasn't related to cross-sysplex sharing. Just poor configuration/amangement plus silly actions taken. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
>Once upon a time, deadly embraces were a way of life. >Operators were trained to watch for and react to OMEGAMON alarms by cancelling >one of the jobs in the chain. >We survived most with no more than a failed >job. IPL's were rare, but they happened. As I stated in another post, the new GRS option SYNCHRES=YES solved a lot of them. Instead of turning on the RESERVE bit on the next CCW scheduled to the device, the new option forced a CCW to have the bit turned on to be sent immediately. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
I report my own experiences which appear to be a bit different than yours. I also tuned my response to my perception of the OP's specific situation. Once upon a time, deadly embraces were a way of life. Operators were trained to watch for and react to OMEGAMON alarms by cancelling one of the jobs in the chain. We survived most with no more than a failed job. IPL's were rare, but they happened. The OP asked if there were gotchas. And I think the best answer is not only 'yes', but those 'gotchas' can draw undesired attention. But, as you point out, YMMV :-) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Friday, January 22, 2010 1:28 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SHARING USER CATALOGS WITHOUT GRS Hal, I must respectfully disagree with the idea that shared DASD using Reserve constitutes risk of any magnitude, and eventually will lead to deadly embraces. I operated sites with two and three production LPARS and no GRS for over 12 years without any problems caused by reserve, and never a deadly embrace. This included IMS, CICS and DB2. The first " embrace" problem we ever had was after MIM was introduced and we had soft embrace between the IMS RECON and the - resolved by converting both reserves, not just one. In my site now we run 10-16 LPARS, all with shared DASD and no GRS or MIM. Most of the x-system access is catalog, TSO and DFSMShsm backup and migration (DFSMShsm runs on one LPAR only). No performance issues (except the ones I create on purpose), and no Deadly Embraces. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Hal Merritt > Sent: Friday, January 22, 2010 9:38 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] SHARING USER CATALOGS WITHOUT GRS > > Presumably, more than just the catalog is to be shared. > > Often, reserves are issued against more than just the catalog volume(s). This > can (and eventually will) lead to 'deadly embraces' which can bring your shop > down. (BTDT) > > Sharing any DASD (be it catalogs or whatever) without global coordination is > not something one does unless one knows exactly what they are doing. But, if > one does know what they are doing, then they wouldn't do that in the first > place :-) > > If RESERVE were a viable alternative, then a lot of us would be doing just > that. > > Basically, you have two choices: > > 1. Use GRS (or equivalent) > 2. Don't share DASD. > > The good news is that implementing GRS should not cost much (if anything). > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Glen Gasior > Sent: Friday, January 22, 2010 10:43 AM > To: IBM-MAIN@bama.ua.edu > Subject: SHARING USER CATALOGS WITHOUT GRS > > * > I have a requirement to share a production USER CATALOG with a test (not > development) lpar. Both lpars are MONOPLEX. > * > There is no GRS and will not be. No aliases on the test lpar will be assigned > to > this production lpar USER CATALOG. > * > I want to be certain serialization of the catalog takes place. I assume this > will > be via reserves. I want to be certain serialization is taking place between > the > two lpars on the USER CATALOG. > * > Please tell me of what must be in place for this to occur, especially any > gotchas that would bypass serialization. > * > No new program products will be purchased. > * > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > NOTICE: This electronic mail message and any files transmitted with it are > intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or privileged > information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, please > immediately advise the sender by reply email and delete all copies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@ba
Re: SHARING USER CATALOGS WITHOUT GRS
>I must respectfully disagree with the idea that shared DASD using Reserve constitutes risk of any magnitude, and eventually will lead to deadly embraces. I respectfully disagree with your disagreement. There used to be a major issue with SYSVTOC/SYSVVDS, User Cats & IXVTOCs. The 'fix' from IBM was SYNCHRES=YES as a GRS parm. This came out with OS/390 V2R7, but didn't work properly for a couple of releases. IIRC, NO is still the default and, in that case, the deadly embrace is still a possibility. It has nothing to do with MIM, since local ENQ/RES are still handled by GRS. MIM, in this case, is just the propagator of globals, just as GRS is. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
Hal, I must respectfully disagree with the idea that shared DASD using Reserve constitutes risk of any magnitude, and eventually will lead to deadly embraces. I operated sites with two and three production LPARS and no GRS for over 12 years without any problems caused by reserve, and never a deadly embrace. This included IMS, CICS and DB2. The first " embrace" problem we ever had was after MIM was introduced and we had soft embrace between the IMS RECON and the - resolved by converting both reserves, not just one. In my site now we run 10-16 LPARS, all with shared DASD and no GRS or MIM. Most of the x-system access is catalog, TSO and DFSMShsm backup and migration (DFSMShsm runs on one LPAR only). No performance issues (except the ones I create on purpose), and no Deadly Embraces. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Hal Merritt > Sent: Friday, January 22, 2010 9:38 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] SHARING USER CATALOGS WITHOUT GRS > > Presumably, more than just the catalog is to be shared. > > Often, reserves are issued against more than just the catalog volume(s). This > can (and eventually will) lead to 'deadly embraces' which can bring your shop > down. (BTDT) > > Sharing any DASD (be it catalogs or whatever) without global coordination is > not something one does unless one knows exactly what they are doing. But, if > one does know what they are doing, then they wouldn't do that in the first > place :-) > > If RESERVE were a viable alternative, then a lot of us would be doing just > that. > > Basically, you have two choices: > > 1. Use GRS (or equivalent) > 2. Don't share DASD. > > The good news is that implementing GRS should not cost much (if anything). > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Glen Gasior > Sent: Friday, January 22, 2010 10:43 AM > To: IBM-MAIN@bama.ua.edu > Subject: SHARING USER CATALOGS WITHOUT GRS > > * > I have a requirement to share a production USER CATALOG with a test (not > development) lpar. Both lpars are MONOPLEX. > * > There is no GRS and will not be. No aliases on the test lpar will be assigned > to > this production lpar USER CATALOG. > * > I want to be certain serialization of the catalog takes place. I assume this > will > be via reserves. I want to be certain serialization is taking place between > the > two lpars on the USER CATALOG. > * > Please tell me of what must be in place for this to occur, especially any > gotchas that would bypass serialization. > * > No new program products will be purchased. > * > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > NOTICE: This electronic mail message and any files transmitted with it are > intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or privileged > information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, please > immediately advise the sender by reply email and delete all copies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
>What do you think people did before GRS? We used SDSI, MSX/MSI, MIM, and others. DuQuesne/Morino/CA. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
Hal Merritt wrote: If RESERVE were a viable alternative, then a lot of us would be doing just that. This depends on your definition of "viable". RESERVE works to protect integrity. But, it is a performance "drag". -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
On Fri, 22 Jan 2010 11:37:37 -0600, Hal Merritt wrote: >Presumably, more than just the catalog is to be shared. > >Often, reserves are issued against more than just the catalog volume(s). This can (and eventually will) lead to 'deadly embraces' which can bring your shop down. (BTDT) > What leads to a deadly embrace with RESERVE is having more than one product / file on the same volume that can be reserved. >Sharing any DASD (be it catalogs or whatever) without global coordination is not something one does unless one knows exactly what they are doing. But, if one does know what they are doing, then they wouldn't do that in the first place :-) > What do you think people did before GRS? But I do agree that you have to know what you are doing and what you are sharing and the potential for corruption. We have shared a single catalog between production / sandbox to facilitate moving data easily (disk to disk) for years. Mostly for VSAM since it has to be cataloged. 1) Copy from prod to temp move hlq in prodplex 2) Copy from temp hlq to test hlq from testplex These days, we share some 3390-27s, a catalog, and a single HLQ for installing products across many sysplexes and monoplexes. Those using these volumes and HLQs is a very isolated group of MVS sysprogs that understand the caveats. We've never had a problem nor corruption. > >If RESERVE were a viable alternative, then a lot of us would be doing just that. > It still is, any many still do. Also, the OP didn't say what he was doing, only what the requirement was. But again, I agree that there could be a problem depending on what the intentions are, so it's okay to spell it out. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html >Basically, you have two choices: > >1. Use GRS (or equivalent) >2. Don't share DASD. > >The good news is that implementing GRS should not cost much (if anything). > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Glen Gasior >Sent: Friday, January 22, 2010 10:43 AM >To: IBM-MAIN@bama.ua.edu >Subject: SHARING USER CATALOGS WITHOUT GRS > >* >I have a requirement to share a production USER CATALOG with a test (not >development) lpar. Both lpars are MONOPLEX. >* >There is no GRS and will not be. No aliases on the test lpar will be assigned to >this production lpar USER CATALOG. >* >I want to be certain serialization of the catalog takes place. I assume this will >be via reserves. I want to be certain serialization is taking place between the >two lpars on the USER CATALOG. >* >Please tell me of what must be in place for this to occur, especially any >gotchas that would bypass serialization. >* >No new program products will be purchased. >* > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
Presumably, more than just the catalog is to be shared. Often, reserves are issued against more than just the catalog volume(s). This can (and eventually will) lead to 'deadly embraces' which can bring your shop down. (BTDT) Sharing any DASD (be it catalogs or whatever) without global coordination is not something one does unless one knows exactly what they are doing. But, if one does know what they are doing, then they wouldn't do that in the first place :-) If RESERVE were a viable alternative, then a lot of us would be doing just that. Basically, you have two choices: 1. Use GRS (or equivalent) 2. Don't share DASD. The good news is that implementing GRS should not cost much (if anything). -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Glen Gasior Sent: Friday, January 22, 2010 10:43 AM To: IBM-MAIN@bama.ua.edu Subject: SHARING USER CATALOGS WITHOUT GRS * I have a requirement to share a production USER CATALOG with a test (not development) lpar. Both lpars are MONOPLEX. * There is no GRS and will not be. No aliases on the test lpar will be assigned to this production lpar USER CATALOG. * I want to be certain serialization of the catalog takes place. I assume this will be via reserves. I want to be certain serialization is taking place between the two lpars on the USER CATALOG. * Please tell me of what must be in place for this to occur, especially any gotchas that would bypass serialization. * No new program products will be purchased. * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARING USER CATALOGS WITHOUT GRS
On Fri, 22 Jan 2010 10:43:13 -0600, Glen Gasior wrote: >* >I have a requirement to share a production USER CATALOG with a test (not >development) lpar. Both lpars are MONOPLEX. >* >There is no GRS and will not be. No aliases on the test lpar will be assigned to >this production lpar USER CATALOG. >* >I want to be certain serialization of the catalog takes place. I assume this will >be via reserves. I want to be certain serialization is taking place between the >two lpars on the USER CATALOG. >* >Please tell me of what must be in place for this to occur, especially any >gotchas that would bypass serialization. >* >No new program products will be purchased. >* RESERVE will protect it. Assuming one of the environments isn't changing SYSIGGV2 (and SYSZVVDS) to a global ENQ. Since you say these are 2 monoplex LPARs, I assume that is not the case. Also make sure your DASD is gen'd as shared or no reserve will take place at all. If one of the LPARs was in a sharing environment (GRS complex or MIIplex), you would have to make sure you didn't have a generic entry that would cause the RESERVE to be converted to a global ENQ for that specific catalog. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SHARING USER CATALOGS WITHOUT GRS
* I have a requirement to share a production USER CATALOG with a test (not development) lpar. Both lpars are MONOPLEX. * There is no GRS and will not be. No aliases on the test lpar will be assigned to this production lpar USER CATALOG. * I want to be certain serialization of the catalog takes place. I assume this will be via reserves. I want to be certain serialization is taking place between the two lpars on the USER CATALOG. * Please tell me of what must be in place for this to occur, especially any gotchas that would bypass serialization. * No new program products will be purchased. * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Converting CA-MIM to GRS
-- I'm writing a procedure to convert CA-MIM to GRS. Are there any tools to work with? I found some old hits on this but I was hoping to hear something newer. --- There used to be a gent at IBM/WSC that would provide you with a pretty good GRS equivalent of your GRS parms, and help you get them in place and exactly tweaked the way you want things. Check with your IBM Marketting Rep. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Converting CA-MIM to GRS
IBM offers a service to convert the MIM entries to GRS syntax. I seem to remember that it was free - or at least very low cost. > -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Clemmons > Sent: Thursday, December 17, 2009 10:34 AM > To: IBM-MAIN@bama.ua.edu > Subject: Converting CA-MIM to GRS > > I'm writing a procedure to convert CA-MIM to GRS. Are there > any tools to work with? I found some old hits on this but I > was hoping to hear something newer. > Thanks. > "Email Firewall" made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Converting CA-MIM to GRS
> I'm writing a procedure to convert CA-MIM to GRS. Are there any tools to > work with? I found some old hits on this but I was hoping to hear something > newer. > Thanks. > We did the MIM to STAR GRS way back in 99 so the material below is farly old but might be useful. I though that after the conversion of 22 lpars in plex mode to GRS back in 1999 was going to be the last I would see of MIM--but no. We received 18 new lpars over the summer from another Boeing site, most running MIM. So I'm learning about MIM all over again. Not that there's anything wrong about MIM http://www.share.org/Portals/0/archives/proceedings/SF_Feb99/DATA/S2819A.PDF for SHARE presentation from Deb Carnes George Fogg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Converting CA-MIM to GRS
I'm writing a procedure to convert CA-MIM to GRS. Are there any tools to work with? I found some old hits on this but I was hoping to hear something newer. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS Ring VSAM Datasets
On Wed, 29 Jul 2009 13:02:17 -0500, Hale, Bob wrote: >I am confused by the following statement in an IBM Manual. > > > >" To make a VSAM data set a local resource, include an entry for the >VSAM > >data set that is to be a local resource. To make all VSAM data sets >local > >resources, use a generic qname entry for SYSVSAM. SYSVSAM and > >SYSDSN data set serialization must be consistent." > > > >I am confused by the ending sentence that they must be consistent. Can >anyone enlighten me what is meant by that? > > > Include / exclude entries for both. IOW, there will be a SYSDSN and SYSVSAM ENQ issued for open of a VSAM data set and you want to treat both the same way for the same data set(s). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GRS Ring VSAM Datasets
I am confused by the following statement in an IBM Manual. " To make a VSAM data set a local resource, include an entry for the VSAM data set that is to be a local resource. To make all VSAM data sets local resources, use a generic qname entry for SYSVSAM. SYSVSAM and SYSDSN data set serialization must be consistent." I am confused by the ending sentence that they must be consistent. Can anyone enlighten me what is meant by that? Bob This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
"Mark Zelden" wrote in message news:... > On Mon, 15 Jun 2009 10:28:58 +0200, Vernooij, CP - SPLXM > wrote: > > > > >We already discovered that the MIM command character was used for > >several purposes in MIM, a.o. for creating the name of the MIM SSI > >subsystem en for custructing the ISG exit names (for what purpose, can I > >have 2 MIM's in 1 system?). > > Yes. For different components. For example, MII, MIA and MIC. Some > shops run them all in different address spaces. > > We separated out MIA from MII/MIC years ago for 2 reasons: > > 1) System integrity / stability: Tape problems (virtual) sometimes > required a recycle of MIA. Usually not the fault of MIA, but that's not > to say there haven't been MIA bugs over the years. Also if there > was a MIA abend, it would only affect tape and not the other components > sharing the address space. > > 2) MII/MIC run at SYSTEM priority x'FF' / 255. MIA only needs to run at > SYSSTC (x'FE' / 254). > > Mark > -- > Mark Zelden Ok, this makes sense. Thanks, Kees. ** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
On Mon, 15 Jun 2009 10:28:58 +0200, Vernooij, CP - SPLXM wrote: > >We already discovered that the MIM command character was used for >several purposes in MIM, a.o. for creating the name of the MIM SSI >subsystem en for custructing the ISG exit names (for what purpose, can I >have 2 MIM's in 1 system?). Yes. For different components. For example, MII, MIA and MIC. Some shops run them all in different address spaces. We separated out MIA from MII/MIC years ago for 2 reasons: 1) System integrity / stability: Tape problems (virtual) sometimes required a recycle of MIA. Usually not the fault of MIA, but that's not to say there haven't been MIA bugs over the years. Also if there was a MIA abend, it would only affect tape and not the other components sharing the address space. 2) MII/MIC run at SYSTEM priority x'FF' / 255. MIA only needs to run at SYSSTC (x'FE' / 254). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
"Vernooy, C.P. - SPLXM" wrote in message news:<3310ac9d797ec94db8d89ccabdea47a7c6b...@kl1221tc.cs.ad.klmcorp.net> ... > > > "McKown, John" wrote in message > news:. > .. > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vernooy, C.P. - SPLXM > > > Sent: Wednesday, June 10, 2009 1:41 AM > > > To: IBM-MAIN@bama.ua.edu > > > Subject: Re: MIM - GRS conversion in practice > > > > > > > > > > > > "McKown, John" wrote in message > > > news: > > cnrh.dom>. > > > .. > > > > > -Original Message- > > > > > From: IBM Mainframe Discussion List > > > > > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dennis Trojak > > > > > Sent: Tuesday, June 09, 2009 11:08 AM > > > > > To: IBM-MAIN@bama.ua.edu > > > > > Subject: Re: MIM - GRS conversion in practice > > > > > > > > > > Did you ever get around this hurdle? We wanted to try moving > > > > > from MIM to > > > > > GRS also. > > > > > Dennis > > > > > > > > > > > > > I run MIM/Integrity and GRS=nn. We need the ECMF and EDIF > > > functionality without the global ENQ. We do this by having a > > > PARM member > > > with > > > > > > > > MIMINIT GDIF=OFF > > > > > > > > That leaves MIMIT up without the Gloabal ENQ. You might want to > try > > > that and see if it helps, > > > > > > > > -- > > > > John McKown > > > > > > We want to stop and remove MIM entirely. > > > > > > Kees. > > > > I wonder if you bring up MIMIT with EDIF=OFF, will it remove the exits > you mentioned in GRS? If so, then you could just stop MIMIT after its > initialization has removed the exits. But I don't kown if that will work > or not. Can you try? > > > > -- > > I think we already have the trick working and it is not as complicated > as it seemed. > More news by the end of the week (probably). > > Kees. Well, we found the working procedure and it was not as simple as we thought, but well doable. Chronology: We stopped MIM and did the first conversion and we received: ISG881I SET GRSRNL COMMAND CANCELED. AN ISGNQXITBATCH OR AN ISGNQXITBATCHCND EXIT IS CURRENTLY ACTIVE. The active exits were from the GRS ENQmonitor (modname ISGASTUB) on Exit ISGNQXITBATCH and the 2 MIM exits on Exit ISGNQXITBATC. Information from IBM told us that the MIM exits were no problem and needed not be removed. However this did not work, after stopping the GRS Enqmonitor (which removed its exit) we again received ISG881I, so now for the MIM exits only. We already discovered that the MIM command character was used for several purposes in MIM, a.o. for creating the name of the MIM SSI subsystem en for custructing the ISG exit names (for what purpose, can I have 2 MIM's in 1 system?). We then changed the MIM command character and reIPL'd the system. We checked that the GRS Enqmonitor was stopped, stopped MIM and tried the conversion again and again received ISG881I, complaining only about the 2 MIM exits. Then we also DELeted the MIM Exits (SETPROG EXIT,DELETE,EN=ISGNQXITBATCHCND,MOD=) and retried the conversion and then it succeeded. We ran this testsystem for the rest of the day and did not notice problems caused by dynamically DELete-ing the MIM exits. So the trick is to have no exits on the above mentioned GRS exits and to achieve that, you must create standardized MIM exit names by choosing a alphanumeric or national command character or, as we did, choose something like "MIM". This action is now planned for the production sysplex at the end of this month. If new information comes up then, I will let you know here. Kees. ** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
Scott, That's it! That is the line I was thinking about and wrongly attributing to Fagin. Thanks for figuring out the reference I really meant to convey. I still have a faint memory of the actor's voice uttering "More" that played Mr. Bumble. Wasn't "More" repeated several times with increasing volume? :-) Time for me to rent the movie! Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Fagen Sent: Thursday, June 11, 2009 1:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GRS Sorry, Bob - it was the Soup Nazi...although I'm pretty sure that the "Oliver" reference would have been, Mr. Bumble, not Fagin :) Oliver: "Please, sir, I want some ... more?" Mr. Bumble: "More?!?!?" End of OT... Scott Fagen (not Fagin) Enterprise Systems Management CA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
Sorry, Bob - it was the Soup Nazi...although I'm pretty sure that the "Oliver" reference would have been, Mr. Bumble, not Fagin :) Oliver: "Please, sir, I want some ... more?" Mr. Bumble: "More?!?!?" End of OT... Scott Fagen (not Fagin) Enterprise Systems Management CA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
> Hal, > > After receiving some offline replies, I am convinced Scott is referring > to "The Soup Nazi" line. While I like my version that ties "Fagin" with > the line, I am not even sure that Ron Moody actually uttered that > phrase. Old memories sometimes morph over time! . > > Bob Hi Bob. See http://en.wikipedia.org/wiki/The_Soup_Nazi George Fogg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
Hal, After receiving some offline replies, I am convinced Scott is referring to "The Soup Nazi" line. While I like my version that ties "Fagin" with the line, I am not even sure that Ron Moody actually uttered that phrase. Old memories sometimes morph over time! . Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hal Merritt Sent: Thursday, June 11, 2009 11:11 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GRS Wikipedia gives credit to an episode of Seinfeld titled 'The Soup Nazi': http://en.wikipedia.org/wiki/The_Soup_Nazi I thought I heard the line in a Saturday Night Live skit, but I could not find any references. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Thursday, June 11, 2009 5:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GRS Scott, Your reply made me smile. I am assuming the reference is to a line from the Broadway play "Oliver!", by the character named Fagin. Am I correct? I saw that play on Broadway forty-five years ago. Unfortunately, it is also the last play I have seen on Broadway. Good to know that GRS is having a longer run! Bob >You seem to know a lot about GRS for an ISV guy. > >-- >Mark Zelden NO SOUP FOR YOU! Scott Fagen Enterprise Systems Management CA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
Wikipedia gives credit to an episode of Seinfeld titled 'The Soup Nazi': http://en.wikipedia.org/wiki/The_Soup_Nazi I thought I heard the line in a Saturday Night Live skit, but I could not find any references. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richards, Robert B. Sent: Thursday, June 11, 2009 5:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: GRS Scott, Your reply made me smile. I am assuming the reference is to a line from the Broadway play "Oliver!", by the character named Fagin. Am I correct? I saw that play on Broadway forty-five years ago. Unfortunately, it is also the last play I have seen on Broadway. Good to know that GRS is having a longer run! Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Fagen Sent: Wednesday, June 10, 2009 4:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GRS On Wed, 10 Jun 2009 14:59:28 -0500, Mark Zelden wrote: >You seem to know a lot about GRS for an ISV guy. > >-- >Mark Zelden NO SOUP FOR YOU! Scott Fagen Enterprise Systems Management CA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
Scott, Your reply made me smile. I am assuming the reference is to a line from the Broadway play "Oliver!", by the character named Fagin. Am I correct? I saw that play on Broadway forty-five years ago. Unfortunately, it is also the last play I have seen on Broadway. Good to know that GRS is having a longer run! Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Fagen Sent: Wednesday, June 10, 2009 4:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: GRS On Wed, 10 Jun 2009 14:59:28 -0500, Mark Zelden wrote: >You seem to know a lot about GRS for an ISV guy. > >-- >Mark Zelden NO SOUP FOR YOU! Scott Fagen Enterprise Systems Management CA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
"Mark Zelden" wrote in message news:... > On Wed, 10 Jun 2009 14:08:09 -0500, Scott Fagen wrote: > > >This is documented in the GRS Planning Guide: > > > >SYSDSN: > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G460/1.2 .9?SHELF=EZ2ZO10K > > > >SPFEDIT: > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G460/1.2 .8.7?SHELF=EZ2ZO10K > > > >Scott Fagen > >Enterprise Systems Management > >CA > > > > You seem to know a lot about GRS for an ISV guy. > > -- > Mark Zelden They also do something in the area of serialising global resources... Then again, what is it that they don't? Kees. ** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
"McKown, John" wrote in message news:. .. > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vernooy, C.P. - SPLXM > > Sent: Wednesday, June 10, 2009 1:41 AM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: MIM - GRS conversion in practice > > > > > > > > "McKown, John" wrote in message > > news: > cnrh.dom>. > > .. > > > > -Original Message- > > > > From: IBM Mainframe Discussion List > > > > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dennis Trojak > > > > Sent: Tuesday, June 09, 2009 11:08 AM > > > > To: IBM-MAIN@bama.ua.edu > > > > Subject: Re: MIM - GRS conversion in practice > > > > > > > > Did you ever get around this hurdle? We wanted to try moving > > > > from MIM to > > > > GRS also. > > > > Dennis > > > > > > > > > > I run MIM/Integrity and GRS=nn. We need the ECMF and EDIF > > functionality without the global ENQ. We do this by having a > > PARM member > > with > > > > > > MIMINIT GDIF=OFF > > > > > > That leaves MIMIT up without the Gloabal ENQ. You might want to try > > that and see if it helps, > > > > > > -- > > > John McKown > > > > We want to stop and remove MIM entirely. > > > > Kees. > > I wonder if you bring up MIMIT with EDIF=OFF, will it remove the exits you mentioned in GRS? If so, then you could just stop MIMIT after its initialization has removed the exits. But I don't kown if that will work or not. Can you try? > > -- I think we already have the trick working and it is not as complicated as it seemed. More news by the end of the week (probably). Kees. ** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
On Wed, 10 Jun 2009 14:59:28 -0500, Mark Zelden wrote: >You seem to know a lot about GRS for an ISV guy. > >-- >Mark Zelden NO SOUP FOR YOU! Scott Fagen Enterprise Systems Management CA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
On Wed, 10 Jun 2009 14:08:09 -0500, Scott Fagen wrote: >This is documented in the GRS Planning Guide: > >SYSDSN: >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G460/1.2.9?SHELF=EZ2ZO10K > >SPFEDIT: >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G460/1.2.8.7?SHELF=EZ2ZO10K > >Scott Fagen >Enterprise Systems Management >CA > You seem to know a lot about GRS for an ISV guy. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
This is documented in the GRS Planning Guide: SYSDSN: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G460/1.2.9?SHELF=EZ2ZO10K SPFEDIT: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G460/1.2.8.7?SHELF=EZ2ZO10K Scott Fagen Enterprise Systems Management CA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
>From what I see in the GRSRNLXX all the SYSDSN is commented out and the EXCL is still inplace for SPFEDIT From: "McKown, John" To: IBM-MAIN@bama.ua.edu Date: 06/10/2009 12:19 PM Subject: Re: GRS Sent by: IBM Mainframe Discussion List I propogate SYSDSN and SPFEDIT. This gives the same protection as within a single z/OS image. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Wells > Sent: Wednesday, June 10, 2009 12:10 PM > To: IBM-MAIN@bama.ua.edu > Subject: GRS > > Is there a parm. in GRS that needs to be set to prevent a PDS > ..or any > file for that matter..from being edited from (2) diff. lpar's ..? > > -- > Email Disclaimer > This E-mail contains confidential information belonging > to the sender, which may be legally privileged information. > This information is intended only for the use of the > individual or entity addressed above. If you are not the > intended recipient, or an employee or agent responsible > for delivering it to the intended recipient, you are hereby > notified that any disclosure, copying, distribution, or the > taking of any action in reliance on the contents of the > E-mail or attached files is strictly prohibited. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS
I propogate SYSDSN and SPFEDIT. This gives the same protection as within a single z/OS image. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Wells > Sent: Wednesday, June 10, 2009 12:10 PM > To: IBM-MAIN@bama.ua.edu > Subject: GRS > > Is there a parm. in GRS that needs to be set to prevent a PDS > ..or any > file for that matter..from being edited from (2) diff. lpar's ..? > > -- > Email Disclaimer > This E-mail contains confidential information belonging > to the sender, which may be legally privileged information. > This information is intended only for the use of the > individual or entity addressed above. If you are not the > intended recipient, or an employee or agent responsible > for delivering it to the intended recipient, you are hereby > notified that any disclosure, copying, distribution, or the > taking of any action in reliance on the contents of the > E-mail or attached files is strictly prohibited. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GRS
Is there a parm. in GRS that needs to be set to prevent a PDS ..or any file for that matter..from being edited from (2) diff. lpar's ..? -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vernooy, C.P. - SPLXM > Sent: Wednesday, June 10, 2009 1:41 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: MIM - GRS conversion in practice > > > > "McKown, John" wrote in message > news: cnrh.dom>. > .. > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dennis Trojak > > > Sent: Tuesday, June 09, 2009 11:08 AM > > > To: IBM-MAIN@bama.ua.edu > > > Subject: Re: MIM - GRS conversion in practice > > > > > > Did you ever get around this hurdle? We wanted to try moving > > > from MIM to > > > GRS also. > > > Dennis > > > > > > > I run MIM/Integrity and GRS=nn. We need the ECMF and EDIF > functionality without the global ENQ. We do this by having a > PARM member > with > > > > MIMINIT GDIF=OFF > > > > That leaves MIMIT up without the Gloabal ENQ. You might want to try > that and see if it helps, > > > > -- > > John McKown > > We want to stop and remove MIM entirely. > > Kees. I wonder if you bring up MIMIT with EDIF=OFF, will it remove the exits you mentioned in GRS? If so, then you could just stop MIMIT after its initialization has removed the exits. But I don't kown if that will work or not. Can you try? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
"McKown, John" wrote in message news:. .. > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dennis Trojak > > Sent: Tuesday, June 09, 2009 11:08 AM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: MIM - GRS conversion in practice > > > > Did you ever get around this hurdle? We wanted to try moving > > from MIM to > > GRS also. > > Dennis > > > > I run MIM/Integrity and GRS=nn. We need the ECMF and EDIF functionality without the global ENQ. We do this by having a PARM member with > > MIMINIT GDIF=OFF > > That leaves MIMIT up without the Gloabal ENQ. You might want to try that and see if it helps, > > -- > John McKown We want to stop and remove MIM entirely. Kees. ** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
Probably yes, we are doing the last tests this week and I will post the results here. Kees. "Dennis Trojak" wrote in message news:<4352a7f6d3ff1b4389fee073f946a90b0555c...@ntbxapb.corp.radioshack.n et>... > Did you ever get around this hurdle? We wanted to try moving from MIM to > GRS also. > Dennis > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Vernooy, C.P. - SPLXM > Sent: Tuesday, June 02, 2009 6:21 AM > To: IBM-MAIN@bama.ua.edu > Subject: MIM - GRS conversion in practice > > Hello group, > > > > With the information from several discussions in the last year or so and > the new ability to convert from GRSRNL=EXCLUDE to GRSRNL=xx without a > Sysplex wide downtime, we had everything in place to execute the > scenario on our Testsysplex. > > > > There we ran into a sneaky MIM problem. MIM has implemented GRS exit > ISGNQXITBATCHCND with 2 modules named "MIM=XXBC" and "MIM=QXFX". > Stopping MIM will not deactivate the exit and blocks the GRSRNL > conversion and because of the non-standard modulenames, the exit cannot > be deactivated either with a SET PROG=xx scenario. > > > > Any ideas to tackle this hurdle? > > > > Thanks, > > Kees. > > > > > > ** > 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...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dennis Trojak > Sent: Tuesday, June 09, 2009 11:08 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: MIM - GRS conversion in practice > > Did you ever get around this hurdle? We wanted to try moving > from MIM to > GRS also. > Dennis > I run MIM/Integrity and GRS=nn. We need the ECMF and EDIF functionality without the global ENQ. We do this by having a PARM member with MIMINIT GDIF=OFF That leaves MIMIT up without the Gloabal ENQ. You might want to try that and see if it helps, -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
Did you ever get around this hurdle? We wanted to try moving from MIM to GRS also. Dennis -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vernooy, C.P. - SPLXM Sent: Tuesday, June 02, 2009 6:21 AM To: IBM-MAIN@bama.ua.edu Subject: MIM - GRS conversion in practice Hello group, With the information from several discussions in the last year or so and the new ability to convert from GRSRNL=EXCLUDE to GRSRNL=xx without a Sysplex wide downtime, we had everything in place to execute the scenario on our Testsysplex. There we ran into a sneaky MIM problem. MIM has implemented GRS exit ISGNQXITBATCHCND with 2 modules named "MIM=XXBC" and "MIM=QXFX". Stopping MIM will not deactivate the exit and blocks the GRSRNL conversion and because of the non-standard modulenames, the exit cannot be deactivated either with a SET PROG=xx scenario. Any ideas to tackle this hurdle? Thanks, Kees. ** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
> There we ran into a sneaky MIM problem. MIM has implemented GRS exit > ISGNQXITBATCHCND with 2 modules named "MIM=XXBC" and "MIM=QXFX". > Stopping MIM will not deactivate the exit and blocks the GRSRNL > conversion and because of the non-standard modulenames, the exit cannot > be deactivated either with a SET PROG=xx scenario. Well, well, well - CA dropping exits all over the place that can't be managed properly. Who'da thought ?. No doubt done for our convenience. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MIM - GRS conversion in practice
Kees, You have a couple of options that I can think of : (1) Ask CA for assistance - maybe the MIM team have an official or un-official utility to help you. (2) If you are comfortable with assembler, code up a quick+dirty pgm to invoke the CSVDYNEX service to delete the exit modules. Rob Scott Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vernooy, C.P. - SPLXM Sent: 02 June 2009 12:21 To: IBM-MAIN@bama.ua.edu Subject: MIM - GRS conversion in practice Hello group, With the information from several discussions in the last year or so and the new ability to convert from GRSRNL=EXCLUDE to GRSRNL=xx without a Sysplex wide downtime, we had everything in place to execute the scenario on our Testsysplex. There we ran into a sneaky MIM problem. MIM has implemented GRS exit ISGNQXITBATCHCND with 2 modules named "MIM=XXBC" and "MIM=QXFX". Stopping MIM will not deactivate the exit and blocks the GRSRNL conversion and because of the non-standard modulenames, the exit cannot be deactivated either with a SET PROG=xx scenario. Any ideas to tackle this hurdle? Thanks, Kees. ** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
MIM - GRS conversion in practice
Hello group, With the information from several discussions in the last year or so and the new ability to convert from GRSRNL=EXCLUDE to GRSRNL=xx without a Sysplex wide downtime, we had everything in place to execute the scenario on our Testsysplex. There we ran into a sneaky MIM problem. MIM has implemented GRS exit ISGNQXITBATCHCND with 2 modules named "MIM=XXBC" and "MIM=QXFX". Stopping MIM will not deactivate the exit and blocks the GRSRNL conversion and because of the non-standard modulenames, the exit cannot be deactivated either with a SET PROG=xx scenario. Any ideas to tackle this hurdle? Thanks, Kees. ** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS and Generic vs Specific
--- If I have the following in my GRS member of parmlib RNLDEF RNL(CON) TYPE(GENERIC) QNAME(SYSVTOC) RNLDEF RNL(CON) TYPE(SPECIFIC) QNAME(SYSVTOC) RNAME(DCXCF1) RNLDEF RNL(CON) TYPE(SPECIFIC) QNAME(SYSVTOC) RNAME(DCXCF2) RNLDEF RNL(CON) TYPE(SPECIFIC) QNAME(SYSVTOC) RNAME(DCXCF3) Does not the GENERIC for SYSVTOC do the same thing as the three specific definitions? I am thinking I do not need the three specific ones so long as I have the GENERIC for SYSVTOC. You are correct.. -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GRS and Generic vs Specific
If I have the following in my GRS member of parmlib RNLDEF RNL(CON) TYPE(GENERIC) QNAME(SYSVTOC) RNLDEF RNL(CON) TYPE(SPECIFIC) QNAME(SYSVTOC) RNAME(DCXCF1) RNLDEF RNL(CON) TYPE(SPECIFIC) QNAME(SYSVTOC) RNAME(DCXCF2) RNLDEF RNL(CON) TYPE(SPECIFIC) QNAME(SYSVTOC) RNAME(DCXCF3) Does not the GENERIC for SYSVTOC do the same thing as the three specific definitions? I am thinking I do not need the three specific ones so long as I have the GENERIC for SYSVTOC. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: grs
Thanks to those who replied. Drain init worked perfect. Bill -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Doug Henry Sent: Tuesday, March 24, 2009 8:45 AM To: IBM-MAIN@bama.ua.edu Subject: Re: grs On Tue, 24 Mar 2009 07:38:30 -0400, Carroll, William wrote: >. Is there anyway to release the exclusive? Job obviously will not >executed because of the exclusive. I would drain the init that the job ran in and see if that released the enqueue. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: grs
On Tue, 24 Mar 2009 07:38:30 -0400, Carroll, William wrote: >. Is there anyway to release the exclusive? Job obviously will not executed because of the exclusive. I would drain the init that the job ran in and see if that released the enqueue. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: grs
Bill Is job PRDGIWEB still active in the system GPSYS01? That is what is holding the file. If it is, then you need to possibly cycle that job. If this is the job that abended, then it is possible that you may have to IPL to clean this up. Or contact IBM and see if they can provide a solution. Is this a unix file? Perhaps there is still a process running holding the file in BPX. See if D OMVS,F can help. If there is a process, then terminate that ID. Lizette > > Over the weekend we upgraded to zos 1.9. Last night during batch, we had a job > abend, and now grs holds > The dataset. Is there anyway to release the exclusive? Job obviously will not > executed because of the exclusive. > Thank you for your help. > > D GRS,RES=(SYSDSN,ADS*) > ISG343I 07.25.14 GRS STATUS 935 > S=SYSTEMS SYSDSN ADS.G0002156.D090323.INVC.P1652999.S.PDF > SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS > GPSYS01 PRDGIWEB 0038 00AFF358 EXCLUSIVEOWN > S=SYSTEMS SYSDSN ADS.G0003300.D090323.NOTC.P6288019.S.PDF > SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS > GPSYS01 PRDGCWEB 0037 00AFF358 EXCLUSIVEOWN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
grs
Over the weekend we upgraded to zos 1.9. Last night during batch, we had a job abend, and now grs holds The dataset. Is there anyway to release the exclusive? Job obviously will not executed because of the exclusive. Thank you for your help. D GRS,RES=(SYSDSN,ADS*) ISG343I 07.25.14 GRS STATUS 935 S=SYSTEMS SYSDSN ADS.G0002156.D090323.INVC.P1652999.S.PDF SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS GPSYS01 PRDGIWEB 0038 00AFF358 EXCLUSIVEOWN S=SYSTEMS SYSDSN ADS.G0003300.D090323.NOTC.P6288019.S.PDF SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS GPSYS01 PRDGCWEB 0037 00AFF358 EXCLUSIVEOWN Bill Carroll DISCLAIMER: The information contained in this message may be privileged or confidential and is protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS outbound requests
On Tue, 17 Mar 2009 14:38:35 -0500, Brian Peterson wrote: >For example, what if your automation package is issuing a command like D >GRS,C at hourly intervals? > >What if that automation was written to issue the command at exactly the same >time on every LPAR in the sysplex? > >Just a thought I really hate automation like that. But I have seen it in most shops I've been at - including here. I don't mind it while trying to diagnose a problem but over the years this sort of thing grows and gets out of control. Especially when you have all the "situation managment" and postmortems that dictate an action must be taken to prevent a problem from re-occurring. Everybody needs their own display command at some nn interval. I've often wondered just how many meaningless indication of processor speed thingies are wasted by this sort of thing contributing to the (perceived?) expense of our platform and are written of to the cost of doing business. Of course staggering these commands helps, but most of the ones I have seen aren't needed at all. Some ... like JES2 purge commands are needed and we have at least staggered those across the different JESplexes. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS outbound requests
You might want to check syslog on each LPAR and see what might be happening that correlates with the spike in performance your stats are reporting. For example, what if your automation package is issuing a command like D GRS,C at hourly intervals? What if that automation was written to issue the command at exactly the same time on every LPAR in the sysplex? Just a thought Brian On Tue, 17 Mar 2009 05:45:20 -0500, Tomas Larsson wrote: >We have a 6 way sysplex. I'm looking at some performance issues for XCF >traffic. When I look at the outbound requests, I notice that every hour (15 >min interval) group SYSGRS (all members), SYSENF (only one member, CNS >system) and IXCLO012 (all members) has a very high rate of outbound >requests. It's between 2-6 times more outbound req. than the other three 15- >min intervals on an hourly basis. Every hour looks the same. I have looked at >this forum and some other manuals/forums, but don't find a clear answer. GRS >doing something, application related? Any idea or related >documentation I can look at. >/Tomas > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS outbound requests
Take a look at the GRS monitoring tool (MVS Planning: Global Resource Serialization - SA22-7600). It will give you an insight into what GRS is doing. (GRS may not be your problem!) John >We have a 6 way sysplex. I'm looking at some performance issues for XCF >traffic. When I look at the outbound requests, I notice that every hour (15 >min interval) group SYSGRS (all members), SYSENF (only one member, CNS >system) and IXCLO012 (all members) has a very high rate of outbound >requests. It's between 2-6 times more outbound req. than the other three 15- >min intervals on an hourly basis. Every hour looks the same. I have looked at >this forum and some other manuals/forums, but don't find a clear answer. GRS >doing something, application related? Any idea or related >documentation I can look at. >/Tomas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GRS outbound requests
We have a 6 way sysplex. I'm looking at some performance issues for XCF traffic. When I look at the outbound requests, I notice that every hour (15 min interval) group SYSGRS (all members), SYSENF (only one member, CNS system) and IXCLO012 (all members) has a very high rate of outbound requests. It's between 2-6 times more outbound req. than the other three 15- min intervals on an hourly basis. Every hour looks the same. I have looked at this forum and some other manuals/forums, but don't find a clear answer. GRS doing something, application related? Any idea or related documentation I can look at. /Tomas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS CNS policy
On Fri, 9 Jan 2009 09:24:36 +0100, Tidy, David (D) wrote: My 2 questions are: >1) does anyone have a policy on GRS CNS positioning in their sysplex >(and if so what is it and why)? >2) otherwise does anyone have any opinion on whether it might make sense >to position CNS in either the busiest or the quietest system in the >sysplex (the former on the basis of reduced traffic, the latter on >better CPU allocation)? No hard and fast recommendations here, but you also want to consider: Proximity to the GRS lock structure (ISGLOCK) - internal links are faster than external (caveat: zero experience with Infiniband) CF CPU utilization and other structures in the CF LPAR that houses ISGLOCK Whether DYNDISP is ON or OFF for the CF LPAR housing ISGLOCK IBM recommends DYNDISP OFF, but we're in sort of a catch-33 with our configuration for now... Regards, Art Gutowski Ford Motor Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GRS CNS policy
Hi all, I've just noticed the ability to position the GRS contention notification in a GRS star (OA11382). I did notice that the reasoning for the ability to do this is to better balance workload in a sysplex, but can't find any recommendations as to the positioning. We are running sysplex mostly as a DB2 server, but not particularly as a load balancer, so do have busier systems than others. We run many DB2 systems per image. We have also had CPU contention problems, where GRS appears high in the mix (together with DB2 systems). My 2 questions are: 1) does anyone have a policy on GRS CNS positioning in their sysplex (and if so what is it and why)? 2) otherwise does anyone have any opinion on whether it might make sense to position CNS in either the busiest or the quietest system in the sysplex (the former on the basis of reduced traffic, the latter on better CPU allocation)? Best regards, David Tidy Tel:(31)115-67-1745 IS Technical Management/SAP-Mf Fax:(31)115-67-1762 Dow Benelux B.V. Mailto:dt...@dow.com Inkoop Gbw (427) H. H. Dowweg 5 4542 NM Hoek The Netherlands Handelsregisternr. 24104547 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS Entries with CON or EXCL requests
On Sun, 7 Sep 2008 20:07:46 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>BTW, just sorting by CPU-TIME descending, here is what I see as the top 20 since the last IPL (note that CICS regions get recycled). MII is #11. > >It's not the total CPU-TIME consumed that matters. >Rather, it's the pecentage in use. >Some tasks do a lot of work at IPL time, then just coast. Over a long period of time those that only used cycles at IPL time would not show up at the top of the list. If you looked at the names I posted you would see that none of them fell into that category. Anyway, my purpose for posting them was to show that MII did show up as #11 in the list. It is higher in the list on other systems that don't run busy production online subsystems. But if it only increases it's current CPU usage by 10% (not CPU percent, MIM's percentage of increase), then that probably is ok. At #11, it has used 1/8 the amount of CPU time than the #1 task on the list (a production DB2 DBM1 asid).But then I have to think about that increase across 8 LPARs. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS Entries with CON or EXCL requests
>BTW, just sorting by CPU-TIME descending, here is what I see as the top 20 >since the last IPL (note that CICS regions get recycled). MII is #11. It's not the total CPU-TIME consumed that matters. Rather, it's the pecentage in use. Some tasks do a lot of work at IPL time, then just coast. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS Entries with CON or EXCL requests
On Sat, 6 Sep 2008 21:58:47 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>In a MIM environment? How many systems? I know you like to measure things, so did you measure it or was it just a "gut feel". > >It was a 5-way MIMplex that matched the SYSPLEX and the MAS. Control dataset in the CF. >All processors were maxed out. > >MIM was using about 2% of each image. >After the conversion, it went up to about 2.2% > >OS/390 in 64-bit mode. > >I recall the figures, because my management (at the time) were micro-managers. >- Thanks. Although as I said, I am more worried about any possible performance impact - especially during batch. But my gut feel is that it wouldn't be noticed. I could see someone noticing it if there was some long string of batch jobs that all allocated hundreds of files each and they all ran sequentially. BTW, just sorting by CPU-TIME descending, here is what I see as the top 20 since the last IPL (note that CICS regions get recycled). MII is #11. (prod DB2 #1 DBM1) DFHSM (prod datacom) NET EXHPDM (prod DB2 #2 DBM1) (prod DB2 #1 DIST) CATALOG TCPIP OMIICMS MII VANTAGE XCFAS MIA (prod db2 #2 MSTR) RMFGAT *MASTER* NETVIEW WLM I haven't opened a call with CA yet. I plan on doing so to see what information they have and to see if they have any performance data from in-house benchmarks. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS Entries with CON or EXCL requests
>In a MIM environment? How many systems? I know you like to measure things, >so did you measure it or was it just a "gut feel". It was a 5-way MIMplex that matched the SYSPLEX and the MAS. Control dataset in the CF. All processors were maxed out. MIM was using about 2% of each image. After the conversion, it went up to about 2.2% OS/390 in 64-bit mode. I recall the figures, because my management (at the time) were micro-managers. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS Entries with CON or EXCL requests
On Sat, 6 Sep 2008 20:01:06 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>I will probably dynamically add those QNAMES to MIM to manage for a night during batch, monitor and turn them off again in the morning. > >MIM (and GRS) is a lot more efficient in handling SYSVTOC and SYSVVDS, now. >When I first started using MIM (long before CA [or even Legent]), we were told to stay away from converting those reserves, along with the catalogue ones. The manual / QNMAE examples still says to not convert them. > >But, in the past few years, I have done it, with no performance, and negligible CPU, impact. > In a MIM environment? How many systems? I know you like to measure things, so did you measure it or was it just a "gut feel". >If you don't convert them, you could slow down the LMDF migration. > It has nothing to do with speed. It is an integrity issue with the mirror. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GRS Entries with CON or EXCL requests
On Sat, 6 Sep 2008 12:09:46 -0700, Ron Hawkins <[EMAIL PROTECTED]> wrote: >Mark, > >I converted SYSVTOC, SYSVVDS and SYSIGGV2 on a three way MAS back when we >were still on parallel channels. The MIM file was on 3880-23 and really >loved that cache, but the benefits were substantial, especially during the >batch run hardware reserves on VTOCs and catalogs were a major pain. >Converting SYSIGGV2 was to solve some soft embrace issues we were hitting. > Ron, SYSIGGV2 is being converted. You have to or you will run into deadly embraces as you already saw. This has been documented since MVS/ESA. >Did the same thing on a two way MAS a few years later at two sites that also >had a lot of the same contention. One with GRS and the other with MIM using >the Turbo option. This was on ESCON and the benefits were noticeable but not >as substantial. > >I would think that converting these three Reserves would be one of the first >things you do if you go MIM or GRS, Star or ring. While they are very high >in the overall count of reserves, the rate is actually quite low. 1,000,000 >reserves in day is only 11 per second. I would think twice before doing this >beyond three systems in a GRS ring though. > >Ron As I said I have 8 systems involved. I would never consider it with GRS RING, but MIM works more like a star configuration the way data is passed around the MIMplex. And I agree that not all reserves are the same - some are much more expensive than others. I see about 50,000,000 for SYSZVVDS on one of the busiest LPARs in this MIMplex and that system was IPLed last weekend. I indicated in a planning meeting that I suspect we could live with converting those resources but I still want to be cautious and only turn them on for 1 evening and see what happens. And then only if I have to (we may not require the use of LDMF at all since this particular environment has 1-2 scheduled outages a month). But just to illustrate that you can't just start changing reserves to ENQs at will in an environment that is not GRS STAR (or MIM in a CF), we once changed the STK resource name that controls access to their CDS for HSC and VTCS. Virtual tape processing didn't come to a halt but things really backed up and batch fell hours behind before I figured out what was going on. This was in this same environment (8 systems in the MIMplex across 2 sysplexes). Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
