Conference csc32::consolemanager

Hi,
   this is really an OpenVMS issue not PCM. PCM just taakes the
data that appears on the console line.

If you don't want OPCOM outputting on certain nodes of a cluster
issue a reply/disable during the startup for thst node. If you
only want the OPCOM messages far easch node on it's respective
console then you need to talk to an OpenVMS guru who will be able
to tell you if it is possible.

Cheers Simon....

         David

         I am not a VMS guru

         Your question divides into two parts: is one source per event
         preferred, or is one action per event preferred?

         If one source per event is required the following needs to be
         considered. I don't beleive that there is any way to stop
         OPCOM acting in a clusterly manner, nor that there is any way
         to filter OPCOM messages based on source node. You must,
         therefore, stop all messages to all but one node.
         reply/disable will work during startup as long as OPA0: is
         SYS$OUTPUT, the workaround is documentedly unsupported. Read
         SYS$MANAGER:SYLOGICALS.TEMPLATE for a discussion of the
         supported method. (There is another way, but surely scorn and
         retribution would follow me all the days of my life if I
         posted it here...) If you were to stop OPCOM output on some
         nodes in a cluster, then you would have to provide a failover
         mechanism...

         If one action per event is required then an easier method
         lies within PCM, within the definition of a filter. Set Event
         Interval to >0 and you stop identical events occurring within
         that timeframe from triggering the same action. One second
         does for almost all cluster situations.

         Hope this helps

         Tony Sherrard

    >How in a cluster environnement is it possible not to recieve the OPCOM
    >messages of all the node when he connects to the console of one of the 
    >cluster's member?
    
    It simply is not possible to make OPCOM not send it's messages
    clusterwide. Several suggestion SPR'S have been made over the years
    (since V1.0 of VCS) and at one time there was talk of a totally new
    OPCOM component but it never came to pass. To augment what -1 said, 
    you can also use the OPC$* logicals to turn on only certain operator
    classes on different nodes e.g., turn on NETWORK messages for say two
    nodes only, turn on Security messages for two nodes etc. The point is
    you spread the different operator classes and the load to different
    nodes. You can then use filters as -1 said to prevent multiple event
    triggers. 
    
    The only rHthe bottom line and only real solution to this issue is for 
    OpenVMS engineering to provide us with an enhanced OPCOM that allows
    the customer to turn off clusterwide OPCOM broadcasts.
    
    Regs,
      Dan

> Read SYS$MANAGER:SYLOGICALS.TEMPLATE for a discussion of the supported method.

Please, please, please use *ONLY* the SYLOGICALS method for setting the
state of OPCOM!!!

I made the original clusterwide OPCOM for V4.0, and did the rewrite in V5.2
to use the SYLOGICALS.TEMPLATE method.

When the
	$ DEFINE SYS$COMMAND OPA0: /USER    !not SYS$OUTPUT
	$ REPLY /...

method is used in startup, there are lots of windows where inconsistent
information is sent around the cluster.  My analysis of those windows led me
to believe that the only hope of getting it right is to make sure that
OPCOM initially comes up with the right set of enables.  If it comes
up with the wrong set, and REPLY /... is used, various confusion can occur.

****

Why can't you filter based on the presence of the

	"%%%%%    (from node MTFORT at 21-JUN-1995 08:52:48.59)"

portion of the header to ignore remote messages?

****

-cw

    >Why can't you filter based on the presence of the
    
    >        "%%%%%    (from node MTFORT at 21-JUN-1995 08:52:48.59)"
    
    >portion of the header to ignore remote messages?
    
    cw,
       It's so much as the event filtering that is issue so much as
    redundant console traffic and logging. Even if you use the logicals
    to assign enabled classes to various nodes your still logging the same
    data more than once. 
    
    Regards,
       Dan

    I have the same problem.  I have tried to use a filter to disable the
    events as suggested in reply 2.  It does not seem to have any effect,
    so possibly I am doing something incorrect.
    
    The cluster has 10 AlphaVMS systems in a cluster, all managed by the
    same PCM Alpha Workstation (running OpenVMS 6.1 and PCM 1.6).
    
    I go into the Modify Filter screen from the DEC Windows editor, create
    a filter leaving all of criteria selected (i.e. all systems, all
    events, etc.)  I set the Event interval timer to 10 seconds.
    
    What I would expect to see any duplicate event coming in within 10
    seconds ignored.  Effectively, this means that it should see the first
    OPCOM message and ignore the other 9 (because they all are the same
    event arriving within 10 seconds).  This does not happen.  I still
    get 10 lines blasted out of ENS and all 10 icons change the same color.
    
    What am I doing wrong??
    
    Question: Does the filter as set up only apply to defined dispatches
    (there are none in my filter) as opposed to the default action to
    log a line in ENS and change the icon color?
    
    I can live with the multiple lines in ENS but the fact that anytime an
    OPCOM message appears on any one node, all of the nodes change color
    and this is unacceptable to the customer.
    
    Any suggestions are appreciated.
    
    Larry
    

    It sounds like you might have more than one wildcard filter defined and the
    other filter is still sending the messages to the eventlist window.
    
    And yes, filters apply only to defined dispatches. All events are sent
    to all C3's - thats the way it works.
    
    REgards,
       Dan

OpenVMS v7.0 has some features that control the issuing of OPCOM messages on
different cluster nodes. There are logical names (OPC$ALLOW_INBOUND &
OPC$ALLOW_OUTBOUND) defined in SYS$MANAGER:SYLOGICALS.COM.

regards,

Jim

    WAY COOL!!! It's about time we got this kind of functionality.
    
    Thanks much for the info!
    
    Regs,
      Dan