Re: [nv-l] Re: Rulesets

[Peter Chow <Peter.Chow@ca.ibm.com>]

Hi all.  We are running netview 7.1.3 on AIX 4.3.3
A few times over the last several months, events would just stop appearing on the event monitor for reasons unknown.  To get Netview operating properly again, we would recycle the application.
Would this be a symptom of the event socket being filled up and hanging the event subsystem?  How can we check if the event socket is being filled?

Thanks,

Peter Chow
IBM / TD Bank MNS
IBM Global Services
chowp@ca.ibm.com
Office: (905) 293-3006

James Shanks <jshanks@us.ibm.com> Sent by: owner-nv-l@lists.us.ibm.com 04/22/2004 10:15 AM Please respond to nv-l

To:        john@cosmos.dcmds.co.in         cc:        nv-l@lists.us.ibm.com         Subject:        [nv-l] Re: Rulesets

Hello John, 

I'm afraid you misunderstand the nature of the nv-l list and my role in it.  I am a volunteer there like all the other users, and IBM management permits me to answer questions there so long as I respect their guidelines.  I cannot take user problems, nor receive problem data, nor provide individualized assistance beyond answering questions.  Everything else requires that  you must open a formal problem to IBM support for that.  I hope you understand. 
If you do open a problem to Support, and the folks in your local area do not know how to answer your questions, then  they can escalate that problem report (PMR) to NetView Support in the US,  and if needed, then eventually I will be involved.  Otherwise you must confine your  questions to the public list.  That's the only place I can answer them. 

I will attempt to give you some broad guidelines but I cannot do much with your individual rulesets, except to say that they look all right, but I think they are incomplete.  They should probably either end in a Foward or an Action to be explicit about what you are doing.   UNIX has an implied "forward" action but this is very dangerous to rely on, especially for rulesets in ESE.automation.  I think the ones you have will eventually cause you a problem in ESE.automation because they should end in some kind of an action node, and not a "forward" operation, so please read on. 

UNIX: 
1. The secret to debugging rulesets on UNIX is to use the nvcorrd.trace.  You activate it by  issuing the command "nvcdebug -d all" and then looking in the nvcorrd.alog and blog for the results.  You'll see the eyecatcher "Received a trap" when a trap arrives and "Finished with the trap" when all processing is done. Everything that happens in between is nvcorrd processing that trap through your ruleset.  Every 1000 lines nvcorrd switches logs, from the alog to the blog and back again, to keep the log from getting too big.  You can turn tracing off again with the command "nvcdebug -r".   See the man pages about nvcorrd and nvcdebug. 

2.  Rulesets which run in ESE.automation should terminate in an action node of some kind, either an Action node (a  command or a script you write to be executed outside of the event flow to be run by actionsvr), an in-line action node  (executed by nvcorrd  - but be careful as when you script runs in-line all events wait until it is done), or the pager node, which is a special kind of action.  The rulesets are said to run "in the background" because they are independent of the GUI and what the operator sees.  Note that rulesets in ESE.automation should NEVER contain a Forward, Override, or Resolve node, because these are for the GUI only, and if used in ESE.automation, they will eventually cause the event subsystem to hang.  That's because they are run by the actionsvr daemon and he does not have a display to display events, so unless you give him an action to run they just fill up his socket and he will eventually hang.  For!
  the same reason the Event Stream should always be set to Block. 

3.  Rulesets can also be run in the event windows.  This is how they affect what the operator sees.  You simply open a new window using Create --> Dynamic Workspace and you'll be given a panel to specify what ruleset you want to use.  Only rulesets run in this fashion will affect what you see in the event window.  They should end in  Forward, Override, Block, or Resolve nodes.  You can also include actions and in-line actions here, but if you do, those actions will run for every copy of the ruleset that is being used.  So if two operators use the same ruleset, and it contains an action, that action will fire twice, once for each operator.  Thus it is often a good idea to separate rulesets by function, keeping those which affect the display separate from those which perform actions like paging in the background. 


4.  You can combine different  rulesets into one only by using the editor and editing one to contain the other.  There is no import feature, if that is what you are asking.  Each original ruleset just becomes a branch of the new one, but you must build that branch from scratch yourself.  I hope this is clear. 
  
Windows: 
           Rulesets on Windows are implemented entirely differently.   I would stay away from them at least until you have a clear understanding of how they work on UNIX. 

1.  There is no ruleset editor on Windows.  You must modify them with Wordpad.  The changes should be kept simple and the you will have to create new ones on UNIX and ftp them over to Windows if you do anything other than what the samples do.  Editing them is not simple nor easy.  For this reason alone most users shy away from rulesets on Windows. 

2. Rulesets on Windows work entirely differently than on UNIX.  Since trapd on Windows stores all events in the ODBC database directly, there is no event flow to the operator screen.  The Event Browser reads only stored events from the ODBC database.  So the correlation daemon on Windows (called nvcord, with only one "r" to differentiate it) works on copies of events after they have been stored.  When he correlates an event, he must send a new copy of that event back to trapd to be stored so that the operator can see it.  This copy is slightly different than the original because it has a correlation id placed in the first variable of the trap.  This is so that the Event Browser can pull up just the events correlated by each ruleset from the database.  And that is the primary purpose of ruleset on Windows -- they are intended as custom Event Browser filters.  They do NOT have the same robust functionality that is available on !
 UNIX. 
        Rulesets on Windows do not support Actions Nodes (there is no actionsvr) nor the pager node (for the same reason).  If you want to send a page from a ruleset, then you must use a script or bat file launched from an in-line action.  In-line actions run by nvcord on Windows can take longer than they do on UNIX and not hurt anything because nvcord does not disrupt the flow of events to the ODBC database -- he is on the sidelines of the event flow rather than part of it. 
        Rulesets on Windows also do not support SetState Nodes (no executable to launch), nor Resolve nor Block (nvcord cannot remove events that have already been stored in the ODBC database) nodes, and Override nodes only partially because there is no way to change the severity of a stored event. 
        Since the way rulesets on Windows work is to send near-duplicate copies of the existing events to the ODBC database, the operator can see both the original AND the near-duplicate event if he runs the Event Browser with no filters and just sets it to "All Events" (which is the default).  This is another reason why most users do not use rulesets on Windows.  The near-duplicate events fill up their event database quicker and many users do not like to see them, but they are a normal part of the process. 

3.  Rulesets on Windows are implemented only by specifying them in the configuration of the Correlation Daemon, nvcord.  You must pick them out of the drop-down list in Serversetup (nvsetup.exe) and also select what tracing options you want when you start the daemon.  Changing rulesets or tracing means that you must recycle the daemon.  There is no other way. 

My advice is to stay away from rulesets on Window altogether because of their many limitations, but if you must have them, then you should try to become familiar with them on UNIX first, because that implementation is easier to use. 

I sincerely hope this helps. 

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group

john@cosmos.dcmds.co.in
Sent by: SomenDas@cosmos.dcmds.co.in

04/22/2004 02:44 AM

To	James Shanks/Raleigh/IBM@IBMUS
cc
Subject	Rulesets

Hi Shanks
    Thanks for your guidance for creating Rulesets.
I had created few rulesets as per your guidance.I have both AIX and Windows
platfom in which I had installed Netview-7.1.3
I had few more queries in this regard.who I will activate the rulesets in
Windows platform and how I will able to know the partcular rulesets output,
I had activated 6 rulesets in AIX by putting them in ESE.automation file,Is
there any method to taste the rulset individually,and where the output are
written.
Also I am attaching two rulesets created by me for your verification,pl.
let me know whether these are the right one or not
Is there any method to integrate all these 6 rulesets to one ruleset

The ndnu.rs for node down/node up events and iuid.rs for interface
down/interface up events
and the time period is 5 minutes

I will be greatfull to you if you please guide me

With Regards
John(See attached file: ndnu.rs)(See attached file: iuid.rs)

---------------------------------------------------------------------------
The information in this e-mail is the property of DCM DataSystems and may
be confidential and privileged. It is intended solely for the addressee and
access of this email by anyone else is unauthorised. If you are not the
intended receipient, any disclosure, copying, distribution or any action
taken in reliance of this message is prohibited and may be unlawful. If you
receive this message by error, please notify the sender immediately and
delete all copies of this message.
---------------------------------------------------------------------------

[attachment "ndnu.rs" deleted by James Shanks/Raleigh/IBM] [attachment "iuid.rs" deleted by James Shanks/Raleigh/IBM]