Hello everyone! After using Health Checker for z/OS for several months now, I'm having doubts about some checks, so please feel free to comment :)
Check: ASM_LOCAL_SLOT_USAGE Comment: This one pops up regularly on LPAR's with Websphere software. It's almost impossible to keep the usage below 30%. Documentation says: "To maximize the efficiency of ASM slot management, you should keep the slot usage on all local page data sets below 30%." We're using 4 page data sets in our test LPAR's, which are ~540k tracks. Adding additional is always an option, but is it worth it? Maybe to change the warning threshold? Thoughts? Check: GRS_CONVERT_RESERVES Comment: Still haven't used the GRS ENQ/DEQ/RESERVE Monitor to check what reserves our systems are using. I was wondering has anyone tried to convert all RESERVEs to ENQs? Were any applications problematic? Check: XCF_SIG_STR_SIZE Comment: This one just a raised a wonder in my head. It's not showing an exception rather a few warnings in the text of the check - that our signaling structures can't support the configuration specified with MAXSYSTEM. This is beacuse the sysplex where this occurs was big once, but now it's just a few LPARs. How could one reduce the MAXSYSTEM value while preserving other data in the CDSs? If I format a new CDS with a smaller MAXSYSTEM number, it won't play nice with the existing ones. Check: IXGLOGR_ENTRYTHRESHOLD Comment: Another "regular" check that pops up. Almost always from the RRS MAIN logstream. Whenever I see this, I check the CF structure which always shows around 40-60% entries in use. Also, the structure is stuck at the inital size and AUTOALTER is disabled (by some recommendation, I think..). Will RRS structure auto expand if needed without z/OS (AUTOALT) intervention? Any best practices to recommend here? Also, sometimes when I check the "Count" column in the checks text, it's empty (no number is shown), but the exception is there... O.o ? Check: RRS_MUROFFLOADSIZE Comment: This check warns that RRS MAIN offload data set isn't big enough to hold everything from the structure (which is a result of enlarging the structure). Solution is to update the LS_SIZE paramater, but I'm having problems with updating it while there are open connections to it (IXG014E by using IXCMIAPU). "Updating a log stream's attributes" from "Setting Up a Sysplex" says: "Pending updates will take effect at different points for each log stream attribute as follows: The LS-DATACLASS, LS_SIZE, LS_MGMTCLASS, and LS_STORCLASS attribute updates will remain pending until a new offload data set is allocated (data set switch event) or the subsequent first connection to the log stream." This seems just fine, but I'm getting an error, not a warning that the change will be effective upon the new offload data set allocation. What's wrong here? (LOGR CDS FORMAT LEVEL: HBB6603) Check: XCF_CDS_SPOF Comment: For this one, I just want to confirm my understanding of the messages. I'm seeing component indicators = 30000000_00000000_00000000 on all the messages which cause this check to generate a high severity (by default) exception. By checking the DOC APAR OA28958, it seems that indicator is telling me that IBM thinks owning a single book in the CEC is a single point of failure (well, it is in some way, but... hmh?). Am I reading this right? Adding a book is defenetly not an option, so if that is the case, this one will need to stay disabled. Thoughts and ideas welcome! Regards, IP ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
