Yes I agree. We had to give up Netview and we installed AutoMan in its place, and had to do the same kind of thing. We wrote a counter script that counted the number of times the message was displayed for a resource and suppressed it until the counter was triggered for that resource. It is not a difficult script, you just have to think about exactly what you want to achieve first. Simply suppressing all occurrences is straight forward and takes no effort at all. But controlling it takes a bit more thought, because there are several different ways to do it, and the method chosen needs to be a model for other similar things that may crop up in future.
On Sat, Sep 5, 2009 at 3:40 PM, Patrick O'Keefe <[email protected]>wrote: > Sorry for the late response. I was out of town last week (and will be > again by the time this is read, probably). > > > On Sun, 30 Aug 2009 09:36:51 -0500, Chris Mason <[email protected]> > wrote: > > >... > > > >However, the right way to go about suppressing the IST663I message > >and all the following messages in the message group is first to work > >out why the messages are there in the first place and then deal with > >the problem which causes them to be created. > > But as Chris says in a later post, this may not be possible. > > >... > >I'm assuming that at some time in the past somebody noticed that >there > were a lot of IST663I messages and, rather than bother about > >why they were being created, ... > > ... or knew there was no easy or desirable way to eliminate their > creation ... > > >..."cleverly" recalled that the quick way to deal with unwanted > >messages was to use the NetView "Message Automation Table" (MAT), > >forgetting that the purpose of the NetView MAT was to get rid of > > messages which didn't really matter ... > > ... or perhaps "remembering" rather than "forgetting". > > The NetView solution, in fact, works well if NetView is running with its > Primary Programmer Operator function enabled. VTAM will pass most > its messages to NetView across the PPO interface rather than issuing > a WTO (thus keeping the messages from SYSLOG/OPERLOG). NetView > then has a number of message-handling options: it (rather than VTAM) > can issue a WTO for the message, and/or it can write the message to the > NetView log, and/or it can automate the message, etc. as specified in > NetView's automation table. > > In the past NetView's ability to reference information from multiple > lines of a multi-line message was very limited. This was improved > a few releases ago with the automation function ACQUIRE. > > One of the real advantages of using NetView to manage IST633I > messages is the ability reduce the number of the IST663Is displayed > based on the resource name or type: every 10th message for some > resources; every 100the for another; no IST633Is for yet another. > > Unfortunately, NetView provides no straightforward ability to request > (for example) one IST633I messages every 10 minutes for some > resource. Don't bother looking for it; it doesn't exist. THRESHOLD > sounds like the solution. It isn't. :-( > > Pat O'Keefe > > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- 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
