Conference azur::mcc

    
    At this point I know that it isn't in the 1.1 plans. As to futures,
    anything is possible. Though there are many items on the table already
    for consideration.
    
    

    
    Rich -
    
    The ALARMS team has given thought to complex mathematical expressions. 
    By this I mean expressions that will allow you to nest expressions, use
    math functions, and use logical operators aswell.
    
    We do not have this planned into our schedule right now, but we would
    like to provide this in the future.  If you have any other ideas on
    ways for us to enhance our expressions, please send them along to us.
    
    As for the expression you mentioned in your note:
    
    EXPRESSION = (... FILE DATE_LAST_MODIFIED > ... FILE DATE_LAST_BACKUP)
    
    You mentioned that "these exoressions are accepted without error today...)
    Do you mean that you can create rules with expressions like this?  I do
    realize that the ... is a full entity spec.  Could you pleas send me a 
    copy of a terminal session where you are able to do this, and the
    pieces of the MS where these attributes are defined?  I am interested
    in looking into this.
    
    aud... (ALARMS team member)

RE: .2

Here's a SHOW ALL ATTR of the rule:

                               Category = "container threshold crossed"
                            Description = "this doesn't look like Kansas"
                      Exception Handler = DISK$SYSTEM_4:[MCC]MCC_ALARMS_MAIL_EXC
                                          EPTION.COM;1
                             Expression = (pbd aug16 container mumble framis >=
                                                         pbd aug16 container
                                          mumble threshold, at every 0:02)
                              Parameter = "kittell"
                              Procedure = DISK$SYSTEM_4:[MCC]MCC_ALARMS_MAIL_ALA
                                          RM.COM;1
                                  Queue = "sys$batch"

    
    Hi Rich,
    
    If I were to take a guess, I would say that "... framis" is defined as an
    enumerated datatype and that "... threshold"  is an enumerated value.
    
>>> Expression = (pbd aug16 container mumble framis >= 
>>>               pbd aug16 container mumble threshold, at every 0:02)
    
    If this is not what you have defined, I will still need to see the pieces 
    of your MSL where you define "pdb aug16 container mumble ..."
    
    ALARMS uses routines from the Forms & Command Line to help parse the
    alarm expession.  When the attribute "framis" is parsed, these routines
    return to us the datatype that you gave it when you wrote your MSL.
    Then a PARSE_VALUE routine is called.  This routine takes as input the
    datatype of the value we are parsing for.  If a value with a different
    datatype is entered on the command line, you should see a message from 
    ALARMS that says:
    
    "Alarm expression value does not match its attribute datatype."

    I am explaining this to you so you can see how your MSL can affect the
    parsing of an expression.  Please enter you MSL peices here so that
    those following this note can watch.
    
    aud...

They were both MCC_K_DT_UNSIGNED32. I'm sorry but I cobbled up the MSL for 
the test and deleted it afterwards. I've given myself a stern talking to
about reporting problems and then deleting the evidence.

I'll have a demo running in the next week or so where I can try it again. 
If I can reproduce the scenario I'll post the details.

  RE: <<< Note 303.5 by COOKIE::KITTELL "Richard - Architected Info Mgmt" >>>
      -< Unsigned32 >-


> They were both MCC_K_DT_UNSIGNED32.

Are you positive?  We just discovered a problem with parsing COUNTER48 values.
Seems that mostly anything is getting accepted.  Could you check and let us
know?  Thanks in advance...

                                                                       - Jerry

A fetched the MSL out of the CMS library, and they were both Unsigned64.

  RE: <<< Note 303.7 by COOKIE::KITTELL "Richard - Architected Info Mgmt" >>>
      -< lo and behold, it wasn't either >-


> A fetched the MSL out of the CMS library, and they were both Unsigned64.

  Yes!  We have just discovered that the problem also exists with COUNTER64
  and UNSIGNED64 data type values!

  Thanks for your help on this problem.  This one was a tough one to crack!

  BTW, don't expect this to be fixed in v1.0.  There is a simple workaround
  (translated: priority 4) to these problems and the v1.0 SSB kit is just 
  about ready to be delivered.  We'll have to settle for this to be fixed in
  the v1.1 timeframe.

                                                                     - Jerry

  We have completed our investigation into this problem and here's the scoop:

  There is a problem parsing COUNTER48, COUNTER64, UNSIGNED48 and UNSIGNED64
  values.

  When using attributes of these datatypes in an alarm expression, one must be
  sure to include a proper value terminator after the value.  In this case, the
  terminator is a `,' (which proceeds the optional AT time clause) or a `)'
  which terminates the expression.

  Any extraneous characters after the value but before the `,' or `)' will
  be ignored.  Thus, if there is no comma before the time clause, the time
  clause specified will be ignored and the default of EVERY 00:15:00
  (15 minutes) will be used.  A valid value will be parsed properly.
  Invalid values will not be caught by the parser.

  This problem also affects WITH clauses that utilize attributes of these
  datatypes from the FCL interface.  It also affects SET commands for 
  attributes of type UNSIGNED48/64 (Counters, by definition, are not settable).
 
  As long as valid alarm expressions, WITH clauses and SET commands are
  specified, everything works fine.  Reporting errors when invalid values 
  are entered is the problem. 

  This has been documented in the release notes and a QAR has been
  filed in the NACQAR database - #1228.

                                                                    - Jerry