Re: [nv-l] Re: Rulesets

[James Shanks <jshanks@us.ibm.com>]

netstat -a   will show you all
the sockets and the send and receive queues.  The queues should be
zero or have very small numbers in them.  Very large numbers, into
the thousands, indicates a problem.  On your level of AIX the "full"
number is 32767.

Are you running rulesets in ESE.autromation?

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

Peter Chow <Peter.Chow@ca.ibm.com>
Sent by: owner-nv-l@lists.us.ibm.com

04/23/2004 12:28 PM

Please respond to
nv-l

To	nv-l@lists.us.ibm.com
cc
Subject	Re: [nv-l] Re: Rulesets

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]