Antwort: Re: Antwort: Re: Healthcheck System logger
Sam, thanks for replying. I misunderstood the ALL parameter, you're right that it still shows the last 16 exceptions. I changed my parmlib member and added the mentioned date/time to the check, restarted HC and the check ended with RC0. Thanks for your help, Werner Kuehnel Spezialist in der Abteilung Betrieb/Support IMD-Gesellschaft für Informatik und Datenverarbeitung mbH Augustaanlage 66 68165 Mannheim Tel: +49.621.457-4885, Fax: -4046 E-Mail: [EMAIL PROTECTED] IMD-Gesellschaft für Informatik und Datenverarbeitung mbH Sitz Mannheim, Amtsgericht Mannheim HRB 7460 Geschäftsführer: Norbert Koch IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU schrieb am 12.05.2008 00:58:56: Well this reply is rather late but I don't see that any others. I understand ALL to be the last 16 exceptions saved in memory in the z/OS System Logger (IXGLOGR) asid not the Health Checker (HZSPROC) asid. So stopping and restarting Health Checker does nothing by default. You can get what you want but it takes some user action. An example. Here Health Checker is just stopped and restarted. CHECK(IBMIXGLOGR,IXGLOGR_STAGINGDSFULL) START TIME: 05/11/2008 18:41:41.939281 CHECK DATE: 20071106 CHECK SEVERITY: LOW CHECK PARM: ALL Immediately trips an exception from two days previous which is included in the ALL criteria. Time of Last Log Stream StructureCount Condition (GMT) GSVX115.SYSDATA.PLOT.HSYS *DASDONLY* 1 05/09/2008 14:00:01 END TIME: 05/11/2008 18:41:41.964858 STATUS: EXCEPTION-LOW You can get the behavior you want by adding an update to the check in HZSPRM00 like so ADDREPLACE POLICY STMT(LOGR1) UPDATE CHECK(IBMIXGLOGR,*) PARM('TIME(MON/DAY/YR4 HR:MIN:SEC)') REASON('allow to discard LOGR checks by recycle of Health Checker') DATE(20080511) This will mean when you stop and restart HZSPROC you will not report on exceptions which occurred prior to the current start time for HZSPROC. CHECK(IBMIXGLOGR,IXGLOGR_STAGINGDSFULL) START TIME: 05/11/2008 18:54:27.784840 CHECK DATE: 20071106 CHECK SEVERITY: LOW CHECK PARM: TIME(05/11/2008 22:54:27) This system has not encountered any log stream staging data set full conditions since 05/11/2008 22:54:27 (GMT). END TIME: 05/11/2008 18:54:27.789075 STATUS: SUCCESSFUL Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -- 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: Antwort: Re: Healthcheck System logger
Well this reply is rather late but I don't see that any others. I understand ALL to be the last 16 exceptions saved in memory in the z/OS System Logger (IXGLOGR) asid not the Health Checker (HZSPROC) asid. So stopping and restarting Health Checker does nothing by default. You can get what you want but it takes some user action. An example. Here Health Checker is just stopped and restarted. CHECK(IBMIXGLOGR,IXGLOGR_STAGINGDSFULL) START TIME: 05/11/2008 18:41:41.939281 CHECK DATE: 20071106 CHECK SEVERITY: LOW CHECK PARM: ALL Immediately trips an exception from two days previous which is included in the ALL criteria. Time of Last Log Stream StructureCount Condition (GMT) GSVX115.SYSDATA.PLOT.HSYS *DASDONLY* 1 05/09/2008 14:00:01 END TIME: 05/11/2008 18:41:41.964858 STATUS: EXCEPTION-LOW You can get the behavior you want by adding an update to the check in HZSPRM00 like so ADDREPLACE POLICY STMT(LOGR1) UPDATE CHECK(IBMIXGLOGR,*) PARM('TIME(MON/DAY/YR4 HR:MIN:SEC)') REASON('allow to discard LOGR checks by recycle of Health Checker') DATE(20080511) This will mean when you stop and restart HZSPROC you will not report on exceptions which occurred prior to the current start time for HZSPROC. CHECK(IBMIXGLOGR,IXGLOGR_STAGINGDSFULL) START TIME: 05/11/2008 18:54:27.784840 CHECK DATE: 20071106 CHECK SEVERITY: LOW CHECK PARM: TIME(05/11/2008 22:54:27) This system has not encountered any log stream staging data set full conditions since 05/11/2008 22:54:27 (GMT). END TIME: 05/11/2008 18:54:27.789075 STATUS: SUCCESSFUL Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Werner Kuehnel Sent: Thursday, April 24, 2008 3:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Antwort: Re: Healthcheck System logger Sam, I took option B to activate the fix. I applied the fix (SYS1.LINKLIB) and did an LLA refresh, deleted and added the exit, restarted HEALTHC STC. I didn't define any additional parms nor changed any parms for the checks. According to the HOLD DOC the TIME parameter defaults to ALL, that means it's set to the starttime of HC. Did I do anything wrong? Werner Kuehnel This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
Antwort: Re: Healthcheck System logger
Sam, I took option B to activate the fix. I applied the fix (SYS1.LINKLIB) and did an LLA refresh, deleted and added the exit, restarted HEALTHC STC. I didn't define any additional parms nor changed any parms for the checks. According to the HOLD DOC the TIME parameter defaults to ALL, that means it's set to the starttime of HC. Did I do anything wrong? Werner Kuehnel IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU schrieb am 23.04.2008 14:54:45: Hi Werner, This may be dumb questions but if you did not IPL did you follow exactly the steps outlined in the APAR to activate the new CHECK code? -- Option A: Refresh the logger checks 1. First issue these SETPROG commands from a MVS console after this support is applied: SETPROG EXIT,DELETE,EXITNAME=HZSADDCHECK,MODULE=IXGHC1DE ,FORCE(YES) SETPROG EXIT,ADD,EXITNAME=HZSADDCHECK,MODULE=IXGHC1DE 2. Then refresh the health checks by issuing this command from an MVS console: F hzsproc,REFRESH,CHECK(IBMIXGLOGR,*) If you do not delete and redefine the exit (step 1), but simply refresh the health checks (step 2), the checks may end in a parameter error. -- Option B: Restart Health Checker 1. First issue these SETPROG commands from a MVS console after this support is applied: SETPROG EXIT,DELETE,EXITNAME=HZSADDCHECK,MODULE=IXGHC1DE ,FORCE(YES) SETPROG EXIT,ADD,EXITNAME=HZSADDCHECK,MODULE=IXGHC1DE 2. Then issue the following commands to stop and restart the IBM Health Checker for z/OS address space: F HZSPROC,STOP START HZSPROC If you do not delete and redefine the exit (step 1), but simply restart health checker (step 2), the checks may end in a parameter error. -- Option C: IPL the system. Did you create a PARMLIB member something like this SYS1.PARMLIB(HZSPRMIX) - 01.00 Columns 00 === Scroll * Top of Data /* */ /* */ /* GEICO z/OS Health Checker Reset LOGR Checks*/ /* */ /* The LOGR checks by default stay around forever once tripped*/ /* This provides a way to move the window forward on what to */ /* report. Issue the command to invoke this member to discard */ /* old exceptions.*/ /* */ /* F HZSPROC,ADD,PARMLIB=IX */ /* */ /* This only works on z/OS 1.7 to 1.9 with PTFs for APAR OA22255 */ /* installed. It is included in z/OS 1.10 at base. */ /* */ /*APAR Identifier .. OA22255 Last Changed */ /*08/01/02 */ /* SYSTEM LOGGER HEALTH CHECKS UPDATED WITH PARAMETERS: ALLOWS */ /* INSTALLATIONS TO HIDE CONDITIONS AFTER AN INPUTTED TIME.*/ /* */ /* Symptom .. NF NEWFUNCTION Status ... CLOSED */ /*UR1 */ /* Severity ... 3 Date Closed . */ /*07/12/07 */ /* Component .. 5752SCLOG Duplicate of */ /* Reported Release . 740 Fixed Release */ /*999 */ /* Component Name SYSTEM LOGGERSpecial Notice */ /*ATTENTION */ /* Current Target Date ..08/02/01 Flags */ /* SCP ...NEW FUNCTION */ /* Platform SYSPLXDS */ /* */ /* */ /* Status Detail: SHIPMENT - Packaged solution is available for*/ /*shipment. */ /* */ /* PE PTF List:*/ /* */ /* PTF List: */ /* Release 720 : UA38454 available 07/12/27 (F712 ) */ /* Release 730 : UA38455 available 07/12/27 (F712 )
Antwort: Re: Healthcheck System logger
Hi Sam, thanks for pointing me to APAR OA22255. I've just installed it, unfortunately there is no change in behaviour for this check. Werner Kuehnel IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU schrieb am 22.04.2008 12:49:43: Hi, Dave Danner has posted about this before... Search the archives for the thread with a subject Problems with checks IXGLOGR_*. Here is the post I saved. I don't think anything is available beyond what he discussed here. Thanks, Sam Sorry for the late reply... What Jorge describes has been a known problem with the IBMIXGLOGR checks from the beginning that I and others have complained about. Apar OA22255 (which just closed on Friday) will improve the situation somewhat. -- 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: Healthcheck System logger
HZSPROC,ADD,PARMLIB=IX) to update the checks on a system where you had older checks tripping and does the check display reflect your update to the CHECK PARM? Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Werner Kuehnel Sent: Wednesday, April 23, 2008 6:39 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Antwort: Re: Healthcheck System logger Hi Sam, thanks for pointing me to APAR OA22255. I've just installed it, unfortunately there is no change in behaviour for this check. Werner Kuehnel IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU schrieb am 22.04.2008 12:49:43: Hi, Dave Danner has posted about this before... Search the archives for the thread with a subject Problems with checks IXGLOGR_*. Here is the post I saved. I don't think anything is available beyond what he discussed here. Thanks, Sam Sorry for the late reply... What Jorge describes has been a known problem with the IBMIXGLOGR checks from the beginning that I and others have complained about. Apar OA22255 (which just closed on Friday) will improve the situation somewhat. This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
Healthcheck System logger
Some days ago we moved over to z/OS 1.8. Since then the health check IXGLOGR_STAGINGDSFULL ends with RC4, saying: Check Reason: Logger staging dataset full conditions should be investigated to determine if application performance is being impacted Time of Last Log Stream StructureCount Condition ATR.SYS1.RM.DATA *DASDONLY* 1 04/14/08 04:50:31 END TIME: 04/22/2008 10:23:48.134741 STATUS: EXCEPTION-LOW Offloading basically works, the last offload data set of RM.DATA was created yesterday, Any idea how to get rid of this exception? Werner Kuehnel -- 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: Healthcheck System logger
Hi, Dave Danner has posted about this before... Search the archives for the thread with a subject Problems with checks IXGLOGR_*. Here is the post I saved. I don't think anything is available beyond what he discussed here. Thanks, Sam Sorry for the late reply... What Jorge describes has been a known problem with the IBMIXGLOGR checks from the beginning that I and others have complained about. Apar OA22255 (which just closed on Friday) will improve the situation somewhat. From the apar: System logger health checks have been enhanced to allow parameters to update the checks behavior. The 'TIME(mm/dd/ hh:mm:ss)' parameter allows installations to set a time to report from. Conditions before the inputted time will be suppressed. The 'ALL' parameter, which is the default, will allow the previous behavior and show up to the most recent 16 conditions for the system logger health checks. Unfortunately, due to a restriction in the HC infrastructure, you can't simply pass a parameter of 'REFRESH'. The check developer suggested this: create a HZSPRMxx parmlib member like: UPDATE CHECK(IBMIXGLOGR,*) PARM('TIME(MON/DAY/YR4 HR:MIN:SEC)') Then issue the command: F HZSPROC,ADD,PARMLIB=xx. This should clear all outstanding exceptions. I believe that my friends at IBM are aware of the 'REFRESH' requirement so hopefully this will be a future HC enhancement. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Werner Kuehnel Sent: Tuesday, April 22, 2008 5:14 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Healthcheck System logger Some days ago we moved over to z/OS 1.8. Since then the health check IXGLOGR_STAGINGDSFULL ends with RC4, saying: Check Reason: Logger staging dataset full conditions should be investigated to determine if application performance is being impacted Time of Last Log Stream StructureCount Condition ATR.SYS1.RM.DATA *DASDONLY* 1 04/14/08 04:50:31 END TIME: 04/22/2008 10:23:48.134741 STATUS: EXCEPTION-LOW Offloading basically works, the last offload data set of RM.DATA was created yesterday, Any idea how to get rid of this exception? Werner Kuehnel -- 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 This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: Healthcheck System logger
Check Reason: Logger staging dataset full conditions should be investigated to determine if application performance is being impacted Time of Last Log Stream StructureCount Condition ATR.SYS1.RM.DATA *DASDONLY* 1 04/14/08 04:50:31 The message talks about the *staging* data sets, not about the offload data sets. Are the former of reasonable size? -- Peter Hunkeler Credit Suisse -- 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: Healthcheck System logger
The message talks about the *staging* data sets, not about the offload data sets. Are the former of reasonable size? Even if they aren't, LOGR should start an offload as soon as the staging dataset gets full (the equivalent of a structure-full-condition), no matter if a structure exists or if it is a DASDONLY logstream. Good thing we don't use staging datasets here - that check would get deleted because of uselessness. :-) Regards, Barbara Nitz -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- 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
Antwort: Re: Healthcheck System logger
Peter, Yes, I know that the msg refers to staging data sets, but if offload doesn't work as expected the staging data sets fill up. Well, the staging ds are not that big, they are just 9 tracks, however, that seems to be sufficient. The last two offload data sets were created on April,14 and April, 21. Werner Kuehnel The message talks about the *staging* data sets, not about the offload data sets. Are the former of reasonable size? -- Peter Hunkeler Credit Suisse -- 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: Healthcheck System logger
The message talks about the *staging* data sets, not about the offload data sets. Are the former of reasonable size? Even if they aren't, LOGR should start an offload as soon as the staging dataset gets full (the equivalent of a structure-full- condition), no matter if a structure exists or if it is a DASDONLY logstream. Sure. The message doesn't say it wouldn't offload but it indicates that too small staging data set might cause more frequent offloads, which in turn might decrease logging performance. -- Peter Hunkeler Credit Suisse -- 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