Conference azur::mcc

>    I would like to know exactly what can be recorded in DECmcc version
>    1.1.  In the docs that I have, there is no indication of what can be or
>    what can;t be.  For example, I would desperately like to:
>    
>    	MCC> 	record node4 phx25 area 4 partition status, in domain
>    		upper_merion
>    
>    however this returns a %MCC-W-ARGUNKNOWN, unknown argument AREA, BUT...
>    
>    	MCC> 	record node4 phx25 remote node V01 paritition status, in 
>    		domain upper_merion
>    
>    works just fine.  

	The Historian Fm is a generic FM and can record any entity
   which supports Show directive but DECmcc V1.1 requires this entity 
   be augmented in the data dictionary by Historian's directives.

	In your case it looks like node4 area is not augmented. To 
   verify this, please:

	1. invoke DAP - manage/tool/dict 
	2. DAP> show class node4 subclass area
    
	To augment an entity by Historian's directive you should use
   MCC_HIST_AUG.COM file which is located in MCC_SYSTEM directory
   (I assume that you use VMS). In the header of this file you can find 
   a description how to use it.
	After the data dictionary augmentation you have to rebuild parse
   tables.

   BTW: all above is correct for the Exporter FM; command file name is
        MCC_EXP_AUG.COM	
	
>                 ...  Additionally I have previously asked about the
>    recording of alarm counters, so will all this work in V1.2?


	Alarm's information exists only within the MCC process running
  Alarm's rules. 
	The Historian FM performs recording operation in the separate
  background process which allows the user to exit from MCC. So Alarm's
  information is not visible to the Historian. 
	As far as I know there is no plans to change this in V1.2.


	SAm
    

                    <<< Note 1665.1 by TOOK::SHMUYLOVICH >>>

>	The Historian Fm is a generic FM and can record any entity
>   which supports Show directive but DECmcc V1.1 requires this entity 
>   be augmented in the data dictionary by Historian's directives.

	But weren't there some issues around support of certain data types,
	or constructed data types?  Perhaps that is what .0 refers to.

    
    	RE .2:
    
    The Historian FM stores information in MIR and does not depend on data
    types.
    
    SAm

	Sam,

	Sorry.
	Then is it Exporter that didn't do constructed identifiers?
	Memory fading fast,

	Mike

The MIR has some restriction on what datatypes are supported.  Since the 
Historian uses the MIR, the same restrictions apply.  The MIR does not 
support Identifier attributes that are of Constructed Datatypes.

Also, I would question whether either of the relational db used by the 
Exporter would support constructed types for keys.  Identifier 
attributes would most certainly be used as keys to the instance 
relations.

...kjn

RE .5:

>The MIR has some restriction on what datatypes are supported.  Since the 
>Historian uses the MIR, the same restrictions apply.  The MIR does not 
>support Identifier attributes that are of Constructed Datatypes.

  To be more accurate I'd say that MIR does not support entity instances
  presented by constructed data types. Identifiers attributes (and all 
  others attributes) are supported for all MCC data types.

  As far as I understand, MIR works with constructed instance (instance
  whose data type is constructed) as with collection of bits. Therefore
  it is possible to find such an instance only if you specify it exactly 
  as it was done in the creation time (Matt, please, correct me if I'm 
  not right). 
  
  When Historian FM writes historical data into the MIR it creates 
  instances with all identifiers supported by this entity.
  
  In the case of,for example, Bridge which has two Identifiers attributes
  (address - datatype SET OF and name - datatype FULL NAME) you can retrieve
  data using name as bridge instance.

>Also, I would question whether either of the relational db used by the 
>Exporter would support constructed types for keys.  Identifier 
>attributes would most certainly be used as keys to the instance 
>relations.

  We are working on this problem but it will be not in V1.2.

  SAm  
  
    

    
    Sorry to interrupt the stream (or thread) of converstion.  Just want to
    say thanks to SAm for providing the solution to my problem. BTW, this
    is not the first time I have been in a situation where the solution was
    not apparent with MCC.   I recently was involved in the problem with
    the bad translan install and with the guidance of you  guys, performed
    all sorts of parse table rebuilds, dispatch table rebuilds, dumps, etc.
    I would like to know where all this information is.  I look through the
    docs that I have and do not find clear reference to these procedures. I
    got to say, though I may be alone in this, that these solutions
    are not intuitive, at least for me.  After this go around, I did
    locate a reference in the release notes to the augmentation procedures
    for the SNMP module.  I have potential needs to re-design the reference
    information attributes.  Also the translan module does not create
    reference information for the lines, which would be very helpful
    to have and it is also desired to change or augment this stuff.
    
    Any info or pointers anyone can give me will be greatly appreciated
    and thanks again for the help.
    
    Dave Comfort