Sam makes a good point. If we report on usage above 100% we should allow you to specify a value > 100%. Regarding Barbara's points about the ASM and XCF checks,, We will check into them (again, I presume). The ASM check intentionally is designed on an individual data set basis. And that is why adding an additional data set has no bearing on the exception. However, it is certainly within reason that we might provide a mechanism by which you could (in effect) indicate "I've seen this one, please don't tell me again"). For the XCF case, it is my understanding that Barbara did not want to use the check parameters to guide the check's processing. As those parameters are the intended mechanism for having a check do something other than its default, it is up to you to use that mechanism. We may be updating the check to 'improve' some of its usability problems.
I would like to hear what Barbara's other issues are (as she wrote "I could go on"). Feel free to respond directly rather than posting if you feel that would be better. Shane wrote >Like Barbara, I'd also like to see some justification for the alerts. >Some of them are just inane - especially for smaller sites that may lack >experienced staff. Could you please be specific? Lack of experienced staff does not seem like a good reason for HC to avoid telling where you are not following best practices. It's pretty obvious for most checks why not having the thing being checked for is a potential problem. Barbara added no matter if I can *do* something about it or not. In most cases I cannot. I really don't want to count the number of IPLs we did just to get the health checker to shut up. If you did not agree with the messages, then it probably would not have taken you multiple IPLs to get the health checker to shut up, as you would not have run health checker or would have deactivated the relevant checks. Therefore I conclude that you did agree with the messages, and however many IPLs it took you was what it took for you to get your system to the state it needed to be. I don't consider that a bad thing. Perhaps you were not in a position to be the one to do the "agreeing" but I cannot see blaming health checker for that. Barbara also added In addition, I had quite a fit when I attempted to setup exception notifications via email - supposedly all with the same message when the severity is the same, but that is unfortunately not the case Could you explain what the problem is? It is certainly the case that all exception messages with the same severity have a single message ID (HZSxxxx). The component's exception message is not a real message ID as far as WTO is concerned. It is just "text" so is sort of a "sub-message" under that ID. Barbara also added: the ASM messages aren't even documented in the 1.8 books, only in the 1.9 books, I wish I had some decent news about that. But I don't. The current position taken by IBM ID is that (except on an exception basis) there is at most one refresh of a release's books and after that, information is only put into a new release's books. Regarding deleting of checks, I do agree that checks should (in general) be tune-able so that you can get them to accept the setup you have put in place once you have ascertained that you have a valid reason for not going along with recommendations. Deleting or deactivating a check is less desirable than having it remain active, but active while checking for "your case" (which has the side benefit of alerting you if "your case" is unintentionally changed). Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- 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
