Conference azur::mcc

>    The error is that the datatype of the input signals and output signals
>    is not supported by the alarms FM.

  Do you know what the attribute datatype is? 

  What is the Rule Expression you are using?

  /keith

    
    My alarm rule was:
    
    CREATE MCC 0 ALARMS RULE port_LIVING1 -
      EXPRESSION=(term mx300 station decmux_a1 port 5 output signals <>
      DTR, AT EVERY 00:02:00), -
      PROCEDURE=MCC_COMMON:MCC_ALARMS_log_ALARM.COM, -
      EXCEPTION HANDLER=MCC_COMMON:MCC_ALARMS_log_EXCEPTION.COM, -
      DESCRIPTION="The port is living.", -
      QUEUE="SYS$BATCH", -
      PERCEIVED SEVERITY =  Critical,-
      PARAMETER="WELNUT::MCCALLUM", -
      in domain Welwyn
    
    The trouble is that the attribute type can supply different strings
    depending on the signals. Sometimes you get { DTR } and sometimes 
    { DTR RTS }, so it is some extendable ASCII string. Sorry I don't know
    the internal data type name. DAP shows this
      Class (1) : TERMINAL_SERVER
         Subclass (2) : PORT
    -----> Attribute (5) : INPUTSIGNALS
             Definition (3) : CONSTRUCTOR_DATA_TYPE
             Definition (3) : VALUE_DATA_TYPE
             Definition (3) : VALUE_LENGTH
             Definition (3) : PRESENTATION_NAME
             Definition (3) : ACCESS
             Definition (3) : DISPLAY
             Definition (3) : PREDICTABLE
             Definition (3) : DEFAULT_ALLOWED
             Definition (3) : CATEGORIES
        
    Is this enough ?
    
    Dave
    

  Dave,

  Alarms supports Latin1 Strings and Enumerations.  The 'output signals'
  attribute could be one of theses.

  I do not have the Terminal Server MM installed .. could you get me a bit
  more information from your Dictionary?

>      Class (1) : TERMINAL_SERVER
>         Subclass (2) : PORT
>    -----> Attribute (5) : INPUTSIGNALS
>             Definition (3) : CONSTRUCTOR_DATA_TYPE
>             Definition (3) : VALUE_DATA_TYPE
>             Definition (3) : VALUE_LENGTH
>             Definition (3) : PRESENTATION_NAME
>             Definition (3) : ACCESS
>             Definition (3) : DISPLAY
>             Definition (3) : PREDICTABLE
>             Definition (3) : DEFAULT_ALLOWED
>             Definition (3) : CATEGORIES

  Can you get the value_data_type for these attributes?

	DAP> show definition value_data_type

  And post the output here ?

  Thanks,

  Keith

    
    Here it is
    
    DAP>  use class terminal_server subclass port
    DAP> use attribute inputsignals
    DAP> show definition value_data_type
    
       Definition Name = VALUE_DATA_TYPE
       Type = L   Length = 4   Count = 1   Defined = TRUE   Class = S
       value[1] = 52
    
    DAP>
    
    Is this any help ?
    
    Thanks for trying to help.
    
    Dave.
    

RE: .5

>    DAP>  use class terminal_server subclass port
>    DAP> use attribute inputsignals
>    DAP> show definition value_data_type
>    
>       Definition Name = VALUE_DATA_TYPE
>       Type = L   Length = 4   Count = 1   Defined = TRUE   Class = S
>       value[1] = 52

  Dave,

  The datatype for 'input signals' is a Set Of (code 52).  The Set-of
  datatype is fairly complex, and most definitly not supported by the
  v1.2 Alarms FM.

RE: .0

>    The error is that the datatype of the input signals and output signals
>    is not supported by the alarms FM.
>    
>    Is this area likely to change for the shipping product or do I have to
>    use another solution ?

  Sorry about this, you'll have to find another way of doing this.

  Could someone from the Terminal Server group offer any help ??

  /keith
    

Dave-

Sorry for the delay, I saw alarms in the title of your note and passed
right over it.  The field test version of TSAM you have does not work
with DECmcc BL15.  I'm surprised you got anything to work on TSAM, let alone the
alarms.

Also, in your last note, you have extracted the dictionary description
for subclass port, not subclass station subclass port, which is what
you use for the MS300.

Maybe the alarms people can help here, the actual definition for the
field you are trying to test is a SET OF enumerated types.  Can this
be tested using the alarms?  Does the alarm expression need to be changed?

-Dave

Ooops notes collision, well that answer came before my question!

Dave M., I'll try to look at this a bit, but my impression is that
TSAM would have to create an enumerated list of every possible combination
of modemsignals to support this.  That is unlikely to happen.

Are there no other fields you can alarm on to provide equivelent
support?

-Dave F.

    I think the DAP command you want to enter is
    DAP> dump class TERMINAL_SERVER subclass STATION subclass PORT -
         attribute OUTPUTSIGNALS
    
    If the VALUE_DATA_TYPE is 52, then it is a Constructor Datatype.
    Asking Alarms to support complex datatypes like this is asking a lot. 
    It comes close to asking for run-time recompilation. Datatypes are
    supported by hard-coding.  Generally, when new datatypes are added,
    new code is added.  Alarms would be have to "interpret" the datatype
    arguments at run-time.  For example a set-of datatype may have any
    number of a specific datatype, including the set-of datatype.  Even
    with a simple Latin1String member datatype, what if you had 20 of
    them?  They could be in any order, so how would you do comparisons? 
    Okay, so let's say that you came up with an algorithm.  That's new
    code for just 1 datatype.  There are many many more complex datatypes. 
    And new ones are being added all the time.  If the TSAM group could
    use a simpler datatype, they should, and I'm sure they would.  So, I
    would agree with Keith, I don't think you can easily alarm on that
    attribute.
    
    -Matt.
    

    
    There are always several solutions if it is very important and you are
    willing to look at "creative" problem solving techniques.
    
    For example, you could have your own tiny FM, which calls the Terminal
    Server AM to reformat the data into a datatype that Alarms can handle.
    Then set up Rules on your tiny FM's attribute data.  I'm sure people
    can give you other possibilities, if you are willing to spend some
    physical (and emotional) effort.
    
    -Matt.

I don't want to make any promises, but given this is a status attribute,
and one that seems like a reasonable candidate for alarming, I'll look
in to what it would take to change its data type.  This change will not
make it in to the field test update coming up though.

I might even just add a new attribute which duplicates the current
attribute, but is a latin1string.

-Dave

The idea of having a mini-FM to do alarming on attributes such as this
sounds like something that if done should have its source code come
with DECmcc (if someone writes it)

    Thanks for your help and creative suggestions.
    
    It sounds like the problem is caused history and a possible slight
    oversight in the entity modelling/alarms capabilites.
    
    Is there a clear definition of what data-types can be alarmed and what
    can't, so that people can design there entities to allow standard FMs
    to use them? 
    
    I used terminal server subclass port instead of station subclass port
    as I thought that DECserver 200 ports were the same as DECmux ports.
    This same problem applies to DECserver 200,300,500,700. I also mixed
    the use of inputsignals and outputsignals, they logically the same.
    I really want alarms on input signals - ie loss of Data Set Ready (DSR)
    indicating the modem has gone away for some reason.
    
    Writing an FM sounds complex but would be a useable solution.
    How much time would it take if I could find a person with experience of
    writing modules ? One month, three months, six months?
    
    If not I'm stuck with whats running on site at the moment - dumping the
    status to a file and manipulating the ascii data.
    
    Dave.
     

    
    Hello,
    
    I've just read the previous replies and I simply want to submit the same
    kind of problem about DECnet IV AM and the process id attribute of the
    child entity object of class node4.
    
    Depending of the way of assigning the object by a VMS process (ex.
    DNS$BACK & DNS$TA of DNS, or PCFS of PATHwork), this process id
    attribute can not be expressed in an alarm rule expression (it seems to
    be an octet string...).
    
    Even trying to change the dictionary definition (ie from octet string
    to latinstring1 for example), I only get an Internal Software Error
    after the rule has been started.
    
    It would be interesting to follow a VMS process via NODE4 object entity
    in specific case in customer environment (ie DNS server processes,
    PATHwork server processes...).
    
    R.VISTA
    
    PS : I had written few weeks ago a description as my problem in note
    2429.0, and Rob Spence replied by a QAR reference number 02462.
    
    
    PS : 
    

It is too late in the development cycle for us to add further datatype
support to the Alarms FM.  However, octet string made it in just under
the wire, and will be available in the EFT update.

Dave M,

Yes, the same data type was used for the vanilla ports also.  That said,
the two subclasses are very similar, but not identical, and I always look
before assuming they are the same.

-Dave F.