Conference azur::mcc

    Steve,
    
    Does the following command provide you the info you're looking 
    for?
    
    show mcc alarms rule 'rule_name' all status
    
    This should let you know if the rule is enabled/disabled. MCC alarms
    can be looked at in the same fasion as other entities (ie. Identifiers,
    Characteristics, Status, etc.).
    
    ...brad

Steve:

  Good note.  My comments are marked with `jrp>' below.

                                                   - Jerry

HI,

From my observation (I'm hoping I'm wrong) with the current mcc design,  alarm
activation is within an instance of an mcc session and it's activation can't
be detected by other mcc sessions.
In my opionion there should be a way for one mcc session to at least detect
if an alarm has been enabled.

jrp> Unfortunately you are correct.  The evaluation of an alarm expression 
     over time occurs in the process in which the rule was enabled.  It's 
     activation (or deactivation) cannot be detected by other MCC sessions.
     This is because MCC v1.0 does not operate in a distributed (across 
     processes or systems) fashion.  When distributed MCC is available, the
     command:

       MCC> SHOW MCC foo ALARMS RULE x ALL STATUS

     will operate as you would expect.  Brad was on the right track in .1,
     but the MCC instance ("foo" in the example above) needs to be specified.

     Please note that we are preparing to provide MCC instances in the EFT
     update timeframe.  This does not mean that distributed MCC will be 
     implemented.  Naming of MCC instances is just the first step.  Please 
     contact product management for more information on the timing of the 
     distributed MCC feature.

Here's a couple of scenarios where this is a problem.

  For our network, ACTnet, I planned to submit a daily mcc batch file to enable
  circuit alarms. However, once I've done this the only way I know if any of
  the rules are enabled is to check that the batch job is running and know that
  the rule is in the com file. And this isn't really a guarantee; A rule can
  fail and to detect this I have to examine the alarm log file. Given all this
  I don't recommend batching alarms rules.

jrp> For EFT update, the Alarms product will provide a new feature that can
     help you solve the problem you describe above.  You can specify a second
     command procedure, called the exception handler, that will be executed 
     when an error occurs during the processing of an alarm expression.  If
     the error has caused the rule to be disabled automatically (not manually)
     by the software, the P6 parameter passed into this command procedure 
     will contain the string "The rule has been disabled."

  Another scenario is where mulitple people are monitoring a network and/or
  system (this will be especially true with domains). One person detects a
  problem and activates an alarm rule to "monitor" the situation. And then a
  second person detects the problem and activites the same alarm rule becaue
  he/she can't detect that it has already been activated.

jrp> The feature described above will not help in this case.  There is no way
     for one user of MCC to tell whether another user (running MCC in another
     session) has a rule enabled or not.  This is currently a drawback of MCC 
     Alarms v1.0.  Again, the command:

       MCC> SHOW MCC * ALARMS RULE x ALL STATUS

     would come in handy!

I consider this to be a serious drewback. It does make a lot of sense for
multiple mcc sessions to be able to enable an alarm rule but sessions do need
to be able to detect prior alarm rule activation.

jrp> MCC Alarms v1.1 requirements have yet to be developed.  I will make sure
     that this requirement is on the list.  At this point I can do no more... 

===Steve

P.S. - These constraints are documented in the DECmcc Alarms Use manual (small
       help that is - I know! ;) ).

	What does this have to do with distributed MCC?

	It sounds to me like .0 is requesting that Alarms maintain some 
	centralized knowledge about Rules, and take appropriate action when
	problems occur, or even "multiplex" data returned in response to
	polls for similar rules.  (You know, another global section ;^)

	This may not be easy, but I think it's approachable...

>	What does this have to do with distributed MCC?

>	It sounds to me like .0 is requesting that Alarms maintain some 
>	centralized knowledge about Rules, and take appropriate action when
>	problems occur, or even "multiplex" data returned in response to
>	polls for similar rules.  (You know, another global section ;^)

>	This may not be easy, but I think it's approachable...

Mike:

  Are you suggesting that Alarms update some sort of centralized database 
  everytime a rule changes the values of it's status attributes?  Remember,
  a rule's status includes: whether it is enabled or disabled, result of the
  last evaluation, number of times the rule evaluated to TRUE, FALSE and ERROR, 
  the time of the last evaluation, etc.

  What would the scope of this database be?  One per system? Per cluster?
  Per domain? Per network?

  I don't think that this is reasonable.

  This situation is analogous to asking any entity what its status is.  In the
  case of Alarms, the entity is MCC foo ALARMS RULE bar.  Your entity might
  be NODE4 foo CIRCUIT bar.  You would never expect NODE4 not to have an
  instance!

  Is this clearer?  

                                                                       - Jerry

  P.S. Remember - RULES are entities too!  ;)

	I'm talking about an implementation that does what customers expect
	it to do, regardless of our architecture.

	For instance, one might expect that if 20 different users on a system
	all create and enable a rule that results in polling entity X every
	5 minutes, the actual poll occurs once, and the results are disseminated
	"to each alarm rule".  Now we worry about whether that would happen
	in the AM, in Alarms, in the kernel, etc.  Customers don't, they just
	worry about if it happens at all.

	I think we all agree that rules should exist somehow independent of
	user processes.  I'm just saying that I don't see how distributed MCC
	will fix this.  A detached Alarms server process might...

	Alarms is a very visible and crucial part of the system.

	( P.S. - Show me ONE customer who cares that rules are entities, and
		 I'll eat this note  ;^)

RE: .5

Mike:

  I think we agree too.

  There seem to be two different problems being discussed here.

    o What is the scope of the status (and/or) counters of an alarm rule?
    o Will polling operations be optimized when the same rule is enabled
      on the same system (or for that matter on different systems).

  Let me address the second one first.  I agree wholeheartedly with your
  statement:

    "For instance, one might expect that if 20 different users on a system
     all create and enable a rule that results in polling entity X every
     5 minutes, the actual poll occurs once, and the results are disseminated
     "to each alarm rule".  Now we worry about whether that would happen
     in the AM, in Alarms, in the kernel, etc.  Customers don't, they just
     worry about if it happens at all."

  To be clear this problem has not yet been solved in any component of MCC.
  It is a system problem - Alarms, Historian and PMs (yes, even PMs when they
  process repetitive commands) share this problem.  More FMs are likely to 
  join this set in the future.

  ---------------------------------------------------------------------------

  The first question is somewhat harder to answer.  I don't claim to have all
  the answers, but right now an alarm rule is enabled per process to fulfill
  the "Rules should not be enabled more than once for any MCC instance." 
  requirement.  This is all that was "chewed off" for the v1.0 effort.
  As we move ahead to future versions, we will be faced with additional 
  requirements.  For example:

    "Rules should not be enabled more than once on any system."
    "Rules should not be enabled more than once on any cluster."
    "Rules should not be enabled more than once in any domain."
    "Rules should not be enabled more than once in any network."

  We're probably going to have to be flexible enough to handle all of these
  requirements, since we want MCC and Alarms to provide all the capabilities
  that our users need.  I assure you that we will do "what customers expect it
  to do, regardless of our architecture."  

  *** But, distributed MCC will help us to meet these requirements! ***

  It is a way for us to provide client/server capabilities (i.e., One MCC
  instance serves as the client and the other acts as the server.).  For
  example, suppose we want to satisfy the "Rules should not be enabled more 
  than once on any system." requirement.  Every time a rule is enabled, the 
  MCC Alarms instance that wants the rule enabled (client) could forward the 
  enable request to a "system central" instance of MCC Alarms (server) where
  the rule will get processed (if it isn't already enabled).  

  This is one possible way that we could fulfill that requirement.  I know 
  there are others.  For example, Alarms could implement a private solution -
  that is, not use distributed MCC.  The advantage of using distributed MCC
  is that the "per system", "per cluster, "per domain" and "per network" 
  requirements get solved at the same time!  Also, any private solution might
  just be duplicating the efforts of the distributed MCC effort.  The dis-
  advantage to using a distributed MCC solution is, of course, the timing. 
  Will it be too late in coming?  I don't know the answer to that one, and I
  refuse to discuss it in this conference, but I do intend to ask the people 
  involved before I make any decisions.
   
                                                                      - Jerry

  P.S. "Alarms is a very visible and crucial part of the system."

       I haven't been able to decide whether this is a curse or a blessing! ;)

I also agree with the discussion in this note about DECmmc needing to
be more distributed.  Users really don't care about the architecture
or how difficult it is to maintain internal structures across a network.
They just want to manage the network with the least amount of pain
and the most consistency.  Why can't the rules be kept in DNS with
a designate node (sink) doing the actual 'bookkeeping' on the alarm
with pointers in DNS to that sink?   Remember that DNS will cache lots
of objects and attributes (in Phase V) so that the designated nodes 
performance to access objects and attributes associated with the 
alarm (if kept in DNS) should OK.   I am not suggesting keeping the
volatile data in DNS, just the relatively static rules.

/Claudia

RE: .7

> Why can't the rules be kept in DNS with
> a designate node (sink) doing the actual 'bookkeeping' on the alarm
> with pointers in DNS to that sink?   Remember that DNS will cache lots
> of objects and attributes (in Phase V) so that the designated nodes 
> performance to access objects and attributes associated with the 
> alarm (if kept in DNS) should OK.   I am not suggesting keeping the
> volatile data in DNS, just the relatively static rules.

Claudia:

  I hear you.  This possibility was considered for v1.0 of Alarms (after the 
  DNS decision was made(), but it was suggested, at the time, that DNS might
  not be "efficient" enough considering the possible large number of rules
  that might get created.

  Then again, we did not know all that much about DNS at that point either. ;)

  I'm sure this problem will be revisited for future releases.  Any pros/cons
  that you might know about using DNS would be helpful - I'm not really all
  that familiar with DNS and need all the advice I can get...

                                                                     - Jerry

HI,

In my opionion,
DNS is not a global database for ALL distributed applications! Yes it makes
sense for every node and every "person" but NOT for MCC to keep all its XXXX.
RSM tryed that and everyone stomped on them.
===Steve

    By the way Jerry, in case no one has said it recently, you guys (gals
    too) are do a great job keeping a positive attitude about comments and
    future needs. Thanks!!!
    
    re; .-1
    Steve, DNS is the only Enterprise wide data structure we have and it
    is a good place for stuff that doesn't change very often. How about the
    case where you have network operation centers (NOCs) spread over the
    world and they cover for each other during sleep periods. In these
    cases, they just extend their domain to include the other domains. They
    should be able to pick up alarms too.
    
    Perhaps there needs a construct that permits a rule to be defined as
    local to the current director so it can be tested and when it is ready
    for production, or general distributed use, THEN is gets loaded into
    DNS so it becomes widely accesible?
    
    s/rob

As previosly discuss in a precedent note the Alarm Functional Module does not 
give the possibility to keep enable alarms rules when the MCC session is 
concluded. This mean that the rule is automatically disabled when you exit 
from MCC. We are in a situation where it is very important to ghater the 
alarms coming from some networks Elements (node,bridge ....). 

The following example shows  one of the possible work around 

BEGIN MCC_USER_INTERFACE

	CASE START
		Vms Process creation
		setting the sys$input of the process to MBX
		run MCC_MAIN into VMS process

	CASE COMMAND
		setting the MBX cannel to sys$input of MCC process
		write mcc command to MBX
	END CASE
END




 let me know about the result

 Luciano

This is a creative temporary solution for detached processes!

If someone out there has the time to write some code that would be great.
But you can't expect something like this from MCC engineering -- We have 
our hands full finishing up EFT 1.1 -- Sorry

/keith

Here it is the code :

--------------------------------------------------------------------------------

SAMPLE OF  AUTOMATIC INTERFACE FOR DECmcc ENVIRONMENT.

Conventions:

    MbxMccInput	    =   Input mailbox for DECmcc process


1]   MAILBOX CREATION THROUGHOUT 3GL LANGUAGE 
--------------------------------------------------------------------------------

    Ex. C Language 
    --------------

    #include <stdio>
    #include <ssdef>
    #define DSC$K_DTYPE_T	14  /* char-coded txt;  a single char or a string */
    #define DSC$K_CLASS_S	1   /* scalar or string descriptor */
    /************************************************************************
    *   Descriptor								*
    ************************************************************************/
    typedef struct
    {
	unsigned short  length_F;
	unsigned char   type_F;
	unsigned char   class_F;
	char	    *pointer_F;
    } DESCRIPTOR;
    #define $DESCRIPTOR(name,address,dim)   DESCRIPTOR name = {dim,DSC$K_DTYPE_T,DSC$K_CLASS_S,address}

    main()
    {
	short 	    chanId_V;
	int	    retcode_V;
	$DESCRIPTOR	    (dname_V,"MbxMccInput",strlen("MbxMccInput"));
	if((retcode_V = SYS$CREMBX(1
				,&chanId_V
				,100
				,100
				,0
				,0
				,&dname_V)) != SS$_NORMAL)
	{
	    printf("Error in SYS$CREMBX: code %d\n",retcode_V);
	    exit(0);
	}
	printf("OK.\n\n");
    }
--------------------------------------------------------------------------------
    


2]   RUN OF DETACHED PROCESS
--------------------------------------------------------------------------------
    Start of detached  process with MCC_MAIN immage running

    Es.  DCL Command

    $ run   /process	    = MCC -
	    /input	    = [yourdir]start_mcc.com -
	    /output	    = {[yourdir]filename.log | NL:} -
	    /file_limit	    = 40	-
	    /enqueue	    = 512	-
	    /io_direct	    = 18	-
	    /io_buffered    = 36	-
	    /subprocess	    = 2		-
	    /ast_limit	    = 48	-
	    /buffer_limit   = 50000	-
	    /page_file	    = 20000	-
	    /working_set    = 2048	-
	    /priv	    = setprv	-
	    /detach
	    sys$system:loginout 
--------------------------------------------------------------------------------

    START_MCC.COM

    $	set proc/priv=all
    $	define/table=lnm$process_directory lnm$temporary_mailbox lnm$system
    $	define sys$input MbxMccInput
    $	management/enterprise
--------------------------------------------------------------------------------


This process could be interfaced with MCC command sent to MbxMccInput mailbox 

    Ex. Dcl command

    $ open/write MbxMcc MbxMccInput
    $ write MbxMcc "DIR NODE4 *"


I hope this example could be usefull. 


Luciano