Re: New z/OS 1.13 Health Checks - Friday Rant
Dave, see Mark Brooks' responses. While I see this as more of a cosmetic change than anything, based on this thread, my 2% of messages that didn't fit, wanting to satisfy the health check without deleting it and lastly - because it can't hurt... I have added transport class definitions to my monoplex production and sandbox LPARs. For the production LPARs I made the changes dynamically with SETXCF. // /* MONOPLEX CLASSDEF FOR XCF MESSAGES */ // CLASSDEF CLASS(DEFAULT) CLASSLEN(956) GROUP(UNDESIG) MAXMSG(2000) CLASSDEF CLASS(XCF4K) CLASSLEN(4028) GROUP(UNDESIG) MAXMSG(2000) CLASSDEF CLASS(XCF8K) CLASSLEN(8124) GROUP(UNDESIG) MAXMSG(2000) Below is a display from a sandbox LPAR where I IPLed with the changes over the weekend: D XCF,CD,CLASS=ALL IXC344I 09.28.34 DISPLAY XCF 360 TRANSPORT CLASSDEFAULT ASSIGNED CLASS LENGTH MAXMSG GROUPS DEFAULT 956 2000 UNDESIG XCF4K 4028 2000 UNDESIG XCF8K 8124 2000 UNDESIG DEFAULT TRANSPORT CLASS USAGE FOR SYSTEM M108 SUM MAXMSG: 2000IN USE: 2 NOBUFF: 0 SEND CNT: 3392 BUFFLEN (FIT): 956 XCF4K TRANSPORT CLASS USAGE FOR SYSTEM M108 SUM MAXMSG: 2000IN USE: 0 NOBUFF: 0 SEND CNT: 1255 BUFFLEN (FIT): 4028 XCF8K TRANSPORT CLASS USAGE FOR SYSTEM M108 SUM MAXMSG: 2000IN USE: 0 NOBUFF: 0 SEND CNT: 19 BUFFLEN (FIT): 8124 -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ On Sun, 1 Apr 2012 10:18:31 +0200, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: XCF works only within a sysplex. D XCF,G tells you which groups have been created. D XCF,G,groupname,ALL tells you who has connected to the group and how much traffic has travelled in the group. Kees. Gibney, Dave gib...@wsu.edu wrote in message news:0de6a9840123e547b061ac5b6765c0263e1...@exmb-05.ad.wsu.edu... I run monoplexs. Like I expect most other small shops. 4 LPARS, only shared DASD, no CTC connections. There are TCPIP Hipersocket links, but as far as I know, XCF is not aware of these links. What/Who are the typical users of XCF signaling in a monoplex. How would I know if they are experiencing degraded or inefficient signaling? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
With regard to GRS, ENQs also apply to monoplexes. Through RNL processing it is largely the installation that determines an ENQ's scope. AUTHQLVL(2) is the means to migrate to a larger list of Qnames that are considered Authorized by the system. Bryan Childs GRS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
On Mon, 2 Apr 2012 10:47:44 -0500, Bryan Childs bchi...@us.ibm.com wrote: With regard to GRS, ENQs also apply to monoplexes. Through RNL processing it is largely the installation that determines an ENQ's scope. AUTHQLVL(2) is the means to migrate to a larger list of Qnames that are considered Authorized by the system. When the system is IPLed with GRS=NONE? I thought RNL processing was skipped in that case. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/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: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
The list of authorized Qnames applies to all scopes of ENQs, regardless of RNLs, regardless of mode. Whether an ENQ's resolved scope is SYSTEMS, SYSTEM, or even STEP, only authorized programs can use authorized Qnames. In fact we recommend that authorized programs ALWAYS use authorized Qnames. It prevents an unauthorized program from creating contention on an authorized program's resource. However that means when we increase this list, we need to provide a migration path. That migration path with its corresponding health check is still applicable to a NONE-mode monoplex. Bryan Childs GRS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
XCF works only within a sysplex. D XCF,G tells you which groups have been created. D XCF,G,groupname,ALL tells you who has connected to the group and how much traffic has travelled in the group. Kees. Gibney, Dave gib...@wsu.edu wrote in message news:0de6a9840123e547b061ac5b6765c0263e1...@exmb-05.ad.wsu.edu... I run monoplexs. Like I expect most other small shops. 4 LPARS, only shared DASD, no CTC connections. There are TCPIP Hipersocket links, but as far as I know, XCF is not aware of these links. What/Who are the typical users of XCF signaling in a monoplex. How would I know if they are experiencing degraded or inefficient signaling? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Saturday, March 31, 2012 2:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: New z/OS 1.13 Health Checks - Friday Rant R.S. r.skoru...@bremultibank.com.pl wrote in message news:4f776fe9.80...@bremultibank.com.pl... W dniu 2012-03-30 16:24, Mark Brooks pisze: Hi, The XCF signalling services are available in all sysplex environments, including monoplex. The rationale that motivates the defining of transport classes applies to them all. What for? The classes are for traffic on sysplex links, are they? No links, no need for traffic priorities. -- Radoslaw Skorupka Lodz, Poland Read well: they are for XCF signalling links. Keep a couple of things separated: 1. XCF signalling is used between members that connect to an XCF group. The advantage is that the members don't have to worry where the other members are and how to reach them. XCF will take care of that. 2. A members can be anywhere in a sysplex, so also on the same LPAR. This means that XCF signalling is used/usable in a monoplex and that is why signalling control and tuning is needed in any sysplex, also a monoplex. 3. XCF will communicate via XCF signalling paths, which are internal within the lpar and via CF structures and/or CTC connections between LPARs and machines. So, classes are not for sysplex links, but for XCF transportation. Maybe XCF decides to sends messages over sysplex links, maybe not. 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: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe
Re: New z/OS 1.13 Health Checks - Friday Rant
To all participating in this thread ... The XCF signalling services are available in all sysplex environments, including monoplex. There are TCPIP Hipersocket links, but as far as I know, XCF is not aware of these links. Based upon these two comments I wonder if it is worth pointing out that the DYNAMICXCF parameter of the IPCONFIG statement applies as much to *HiperSockets* as it does to XCF - curiously enough! See the section 1.8.1.2.5, HiperSockets in the z/OS Communications Server IP Configuration Guide manual: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3b0/1.8.1.2.5 Chris Mason On Sun, 1 Apr 2012 03:18:11 +, Gibney, Dave gib...@wsu.edu wrote: I run monoplexs. Like I expect most other small shops. 4 LPARS, only shared DASD, no CTC connections. There are TCPIP Hipersocket links, but as far as I know, XCF is not aware of these links. What/Who are the typical users of XCF signaling in a monoplex. How would I know if they are experiencing degraded or inefficient signaling? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
W dniu 2012-03-30 16:24, Mark Brooks pisze: Hi, The XCF signalling services are available in all sysplex environments, including monoplex. The rationale that motivates the defining of transport classes applies to them all. What for? The classes are for traffic on sysplex links, are they? No links, no need for traffic priorities. -- 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, www.brebank.pl, 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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
R.S. r.skoru...@bremultibank.com.pl wrote in message news:4f776fe9.80...@bremultibank.com.pl... W dniu 2012-03-30 16:24, Mark Brooks pisze: Hi, The XCF signalling services are available in all sysplex environments, including monoplex. The rationale that motivates the defining of transport classes applies to them all. What for? The classes are for traffic on sysplex links, are they? No links, no need for traffic priorities. -- Radoslaw Skorupka Lodz, Poland Read well: they are for XCF signalling links. Keep a couple of things separated: 1. XCF signalling is used between members that connect to an XCF group. The advantage is that the members don't have to worry where the other members are and how to reach them. XCF will take care of that. 2. A members can be anywhere in a sysplex, so also on the same LPAR. This means that XCF signalling is used/usable in a monoplex and that is why signalling control and tuning is needed in any sysplex, also a monoplex. 3. XCF will communicate via XCF signalling paths, which are internal within the lpar and via CF structures and/or CTC connections between LPARs and machines. So, classes are not for sysplex links, but for XCF transportation. Maybe XCF decides to sends messages over sysplex links, maybe not. 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: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
Hi, Transport Classes are all about segregation of message traffic by size. Such segregation is beneficial regardless of whether messages are being sent between XCF members on the same system (which would always apply in the case of a monoplex) or between members that reside on different systems. If messages are being sent between members on different systems, and you don't have a signalling path for the selected transport class, then you effectively lose your segregation by size (so we have a health check for that). The impact of the loss of segregation usually surfaces on the target system. In general it makes the signalling service less resilient in terms of handling bursts of signals or sluggish target member message exits. Mark A. Brooks z/OS Sysplex design and development 845-435-5149 T/L 8-295-5149 Poughkeepsie, NY mabr...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
I run monoplexs. Like I expect most other small shops. 4 LPARS, only shared DASD, no CTC connections. There are TCPIP Hipersocket links, but as far as I know, XCF is not aware of these links. What/Who are the typical users of XCF signaling in a monoplex. How would I know if they are experiencing degraded or inefficient signaling? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Saturday, March 31, 2012 2:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: New z/OS 1.13 Health Checks - Friday Rant R.S. r.skoru...@bremultibank.com.pl wrote in message news:4f776fe9.80...@bremultibank.com.pl... W dniu 2012-03-30 16:24, Mark Brooks pisze: Hi, The XCF signalling services are available in all sysplex environments, including monoplex. The rationale that motivates the defining of transport classes applies to them all. What for? The classes are for traffic on sysplex links, are they? No links, no need for traffic priorities. -- Radoslaw Skorupka Lodz, Poland Read well: they are for XCF signalling links. Keep a couple of things separated: 1. XCF signalling is used between members that connect to an XCF group. The advantage is that the members don't have to worry where the other members are and how to reach them. XCF will take care of that. 2. A members can be anywhere in a sysplex, so also on the same LPAR. This means that XCF signalling is used/usable in a monoplex and that is why signalling control and tuning is needed in any sysplex, also a monoplex. 3. XCF will communicate via XCF signalling paths, which are internal within the lpar and via CF structures and/or CTC connections between LPARs and machines. So, classes are not for sysplex links, but for XCF transportation. Maybe XCF decides to sends messages over sysplex links, maybe not. 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: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
New z/OS 1.13 Health Checks - Friday Rant
Rant of the day... This isn't the first and I'm sure it won't be the last... but why do I have to go and delete GRS and XCF health checks on my monoplex LPARs??? Sure I can add AUTHQLVL(2) to GRSCNF00, but I pick up the default from IBM.PARMLIB. We don't need no stinkin' XCF transport classes on these monoplex LPARs either! How hard is it to check for PLEXCFG=MONOPLEX There, now I feel better. :-) Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/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: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
Mark Zelden wrote: Rant of the day... Rant of the month? :-D but why do I have to go and delete GRS and XCF health checks on my monoplex LPARs??? Sure I can add AUTHQLVL(2) to GRSCNF00, but I pick up the default from IBM.PARMLIB. We don't need no stinkin' XCF transport classes on these monoplex LPARs either! What about making [persistent] changes to HZSPRMxx to get in 'good feel better' mode? :-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
On Fri, 30 Mar 2012 08:36:50 -0500, Elardus Engelbrecht
elardus.engelbre...@sita.co.za wrote:
Mark Zelden wrote:
Rant of the day...
Rant of the month? :-D
but why do I have to go and delete GRS and XCF health checks on my monoplex
LPARs??? Sure I can add AUTHQLVL(2) to GRSCNF00, but I pick up the default
from IBM.PARMLIB. We don't need no stinkin' XCF transport classes on these
monoplex LPARs either!
What about making [persistent] changes to HZSPRMxx to get in 'good feel
better' mode? :-)
That's what I was referring to. What good would it have been to just issue a
P
command in SDSF.But I wouldn't have to do stuff like this if IBM
put a little more thought into some of these checks. Just sayin
ADDREPLACE POLICY STMT(GRS_AUTHQ_POL)
DELETE CHECK(IBMGRS,GRS_AUTHQLVL_SETTING)
REASON('GRS not used in monoplex')
DATE(20120330)
ADDREPLACE POLICY STMT(XCF_MONOPLEX)
DELETE CHECK(IBMXCF,XCF*)
REASON('Deleted XCF checks for monplex.')
DATE(20120330)
Overall, I like Health Checker and have used it since day one.
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/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: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
Hi, The XCF signalling services are available in all sysplex environments, including monoplex. The rationale that motivates the defining of transport classes applies to them all. Mark A. Brooks z/OS Sysplex design and development 845-435-5149 T/L 8-295-5149 Poughkeepsie, NY mabr...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
Mark Zelden wrote: What about making [persistent] changes to HZSPRMxx to get in 'good feel better' mode? :-) That's what I was referring to. I did not see it, but Ok... What good would it have been to just issue a P command in SDSF.But I wouldn't have to do stuff like this if IBM put a little more thought into some of these checks. Good idea about that 'P' command. It is there [ and PF command too ], but I think you meant something else which is not there. Something like the 'H' command, but including extra goodies to suit you? ... Perhaps you could 'check' Big Blue up on its 'unhealthy checks'. [ pun intended ;-D ] Just sayin It is all right, this is what IBM-MAIN made for - sharing ideas and rants... Overall, I like Health Checker and have used it since day one. Agreed. We used it after major changes and IPL and sometimes just for the 'fun' of it. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
On Fri, 30 Mar 2012 10:24:54 -0400, Mark Brooks mabr...@us.ibm.com wrote: Hi, The XCF signalling services are available in all sysplex environments, including monoplex. The rationale that motivates the defining of transport classes applies to them all. Mark A. Brooks z/OS Sysplex design and development 845-435-5149 T/L 8-295-5149 Poughkeepsie, NY mabr...@us.ibm.com Really? You're the expert, so I'll go with that. :-)The transport classes was just one example of an (old) check I thought didn't apply to a monoplex.I see by removing my generic delete there are other XCF checks intelligently disabled. I take back my rant from your component. :-) Can you provide a little more detail though? Just for local messages - correct? Here is a sample from one of my monoplex systems: D XCF,CD,CLASS=ALL IXC344I 11.21.48 DISPLAY XCF 731 TRANSPORT CLASSDEFAULT ASSIGNED CLASS LENGTH MAXMSG GROUPS DEFAULT 956 2000 UNDESIG DEFAULT TRANSPORT CLASS USAGE FOR SYSTEM SUM MAXMSG: 2000IN USE: 2 NOBUFF: 0 SEND CNT: 324666 BUFFLEN (FIT): 956 SEND CNT: 7268 BUFFLEN (BIG): 4028 So I should tune for those 2%? Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/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: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
On Fri, 30 Mar 2012 10:28:23 -0500, Mark Zelden m...@mzelden.com wrote:
On Fri, 30 Mar 2012 10:24:54 -0400, Mark Brooks mabr...@us.ibm.com wrote:
The XCF signalling services are available in all sysplex
environments, including monoplex. The rationale that motivates the
defining of transport classes applies to them all.
I take back my rant from your component. :-)
But not for this component...
Again, this isn't new, but while playing in my monoplex I had a typo
and accidentally re-enabled the check below which goes back to my
original rant.I normally have this check set up with
PARM('NOPLEX') but a little coding effort on IBM's part
would keep me from having to do anything.
The component that wrote the check could have looked at the IPA for
PLEXCFG=MONOPLEX (which means sysplex file system sharing would
be impossible) or since they already knew I had SYSPLEX(NO)
in BPXPRMxx, why run the check with a parm of SYSPLEX?
CHECK(IBMUSS,USS_FILESYS_CONFIG)
START TIME: 03/30/2012 12:29:35.511624
CHECK DATE: 20040217 CHECK SEVERITY: MEDIUM
CHECK PARM: SYSPLEX
BPXH003I z/OS UNIX System Services was initialized using OMVS=(xx),
where each 2-character item is a BPXPRMxx suffix.
* Medium Severity Exception *
BPXH002E There are inconsistent sysplex parameters. In BPXPRMxx,
SYSPLEX(NO) is being used, but the owner specified SYSPLEX
for the parameter of check USS_FILESYS_CONFIG in
HZSPRMxx.
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/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: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
Hi, Your point about whether it is worth defining the second class for 2% of the traffic applies to all sysplexes, not just monoplex. As is the case for many of our health checks, they are designed to incorporate principles/experiences gained over the years. Installations with at least the two classes generally have fewer problems. But some installations may need more classes, some less. The check simply looks at the transport classes that are defined to see if the required number of effective sizes have been set up. The check has a parameter to allow the installation to indicate how many sizes should be configured. The IBM default is two per the aforementioned history. The check does not monitor the system to determine whether the specified number of class sizes is appropriate for the installation. The choice of an appropriate number still requires human judgment. As with any check, the installation must look at the exceptions that are raised, understand the ramifications for their particular installation, and make a determination as to what action should be taken: fix the problem, adjust the check inputs so it raises exceptions per what you believe to be best practice for your own installation, or disable the check if you deem it inappropriate for your installation. Mark A. Brooks z/OS Sysplex design and development 845-435-5149 T/L 8-295-5149 Poughkeepsie, NY mabr...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New z/OS 1.13 Health Checks - Friday Rant
And, as more than a few members of this list are already aware, you can now also enjoy the pleasures of HC on Linux. Primarily aimed at those of you with zLinux ... ;-) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
