Conference azur::mcc

    
    I will leave most of this to Samuil to answer, but regarding "generic"
    historian functions...it still requires that you augment your entity
    in the dictionary with the historian commands. As to how generic
    Historian is, I don't really know enough about it.
    
    

    This is just a placeholder until Samuil returns from his vacation
    Monday.
    
    Until then, a few comments:
    
    1) Historian creates all required repository automatically (so you
       did not miss anything in this regard).
    
    2) The recording requests are stored in the repositories created by
       the FM (so you definitely should be able to delete recordings
       without aby concern for DNS).
    
    3) Historian FM is designed to be generic, however what Jill wrote
       in .-1 is correct. Historian sw should work with your AM as is,
       but you do have to augment your entity.
    
    Samuil will answer you in more detail (perhaps you are using an older
    FM version with known bugs that you noticed), in the mean time you could
    check other recent entries here that address related symptoms.
    
    Regards,
    Alex

    Hello,
    
�    1) Historian creates all required repository automatically (so you
�       did not miss anything in this regard).
�  
�    2) The recording requests are stored in the repositories created by
�       the FM (so you definitely should be able to delete recordings
�       without aby concern for DNS).

    Where are the repositories created, and how can I check them ?
    Obviously, the FM does not find them and is not too happy about
    it ...  In my case, it seems they were not created. I am running
    the latest IFT 1.1 DECmcc BMS system, It is the first version of
    the Historian FM that (to my knowledge) has been made available
    to the field.
       
�    3) Historian FM is designed to be generic, however what Jill wrote
�       in .-1 is correct. Historian sw should work with your AM as is,
�       but you do have to augment your entity.

    I suppose this means I have to update my MSL with the Historian
    directives. Do I also have to add the corresponding entry points
    in the AM service interface component ?
    
    As a general rule, will we have to update MSL's every time a new
    generic FM comes out ? If so, how do AM developpers generally feel
    about this ? Doesn't this somewhat reduce the notion of genericity?
    Or is this a temporary feature?

    Thanks for your help,
    
    Philippe.

    (Note : I will be away all of next week, non-responses from me
    do not mean I have lost interest in the matter ... :-) 

    

   Here's what I know...

 > I suppose this means I have to update my MSL with the Historian
 > directives. Do I also have to add the corresponding entry points
 > in the AM service interface component ?

   Yes, you do have to update your MSL with the Historian directives
   at this time.  I hope that someone on the Historian team will publish
   a pointer to it so that it can be automatically included into everyone's
   MSL.  

   I don't believe that you have to add any corresponding entry points
   into your AM.  The last time I talked to Sam he didn't mention anything to
   me about adding any entry points - just include his MSL into yours.
 
 > As a general rule, will we have to update MSL's every time a new
 > generic FM comes out ?

   As a general rule - I hope not!  Alarms is generic and it does not 
   require any additional MSL.

 > If so, how do AM developpers generally feel about this ? 
 
   I don't develop AMs, so I can't answer this question.

 > Doesn't this somewhat reduce the notion of genericity?
 > Or is this a temporary feature?

   I agree, but as I explain below there are some possible solutions.

 ******************************************************************************

   The problem stems from the management specification (sometimes incorrectly
   referred to as "entity model") chosen for the generic FM.  Historian chose
   to model its recordings as attributes (and directives) of the entity that is being 
   recorded.  Thus, each of those entities must update their MSLs to allow
   the recording functions to work.

   Alarms, for example, chose to model its detection rules as separate entities. 
   These rule entities have their own attributes to describe the entity upon
   which detection will take place.  Thus, there is no need to append any Alarms
   MSL to the MSL of the other entities (node, bridge, etc.).

   Which approach is better?  The answer to that question is not easy, but
   I can tell you that there are problems with both!

   The problem with Historian's approach is precisely the one you are concerned 
   with - if left unchecked, the process of updating MSLs can turn into an 
   administrative nightmare!

   The problem with Alarms' approach is that, being a separate entity, there
   is no relationship between the alarm rule entity and the entity that is 
   associated with the alarm rule (i.e., the entity that the rule refers to).
   The lack of this relationship is painfully evident through the IMPM interface
   because at this time the IMPM only manipulates containment relationships.

   As it turns out, the strength of the Historian's approach is the weakness 
   of the Alarms' approach and the strength of the Alarms's approach is the 
   weakness in the Historian's!  Ahhh..., the irony of it all!!! ;)

   Anyway, the Director/Entity models do not give any guidance in this area 
   that I know of - both methods are "legal".

   So, what's the solution?  I think there may be two solutions - one for 
   each of the problems:

     1.) First, we need some way to update the dictionary *ONCE* with the
         Historians MSL and allow these definitions to be inherited (OO buzz-
         word) automatically by other entities.  This will cut-down on the
         size of the dictionary too!

     2.) Secondly, we need a way for alarm rules to be "related" to other 
         entities without having to depend on the containment realtionship.
         This is especially important in the IMPM.  For example, it would be
         nice to point to a bridge on the map, pull down a menu bar that says:
         "Alarm rules" and then see a list of all the rules associated with 
         that entity.  Then the user should be able to manipulate those rules
         (i.e., CREATE new ones, DELETE, ENABLE, DISABLE, SHOW old ones).

         This concept is similar to Hyper card for those of you familiar with
         that product.  Another product that comes to mind is Bookreader.  Its
         "HOT SPOT" feature is another good example of this kind of capability.

         I refer to this capability as entity navigation through non-containment
         relationships.  The Topology FM will require this capability also.

  Finally, I believe that DECmcc requires both capabilities.  Implemeting both
  inheritance and relationship capabilities in DECmcc will truely make the 
  product the best in the industry!

                                                                       - Jerry   
      

While I  appreciate  the  problems  with  the Alarms approach, the Historian
approach seems completely unworkable.

The problem is that there is no way to know whether a Historian directive or
attribute  conflicts  with one defined for an entity.  Even if the Historian
directives  and  attributes  were all listed today (which they don't seem to
be),  you  can't  add  another  one tomorrow without checking *all* entities
(including  ones being developed by people unrelated to MCC) to make sure it
doesn't  conflict.   Note  that  all  DNA  entity  directive  and  attribute
assignments  are  controlled  by  the  DSSR.  As far as I know, they are not
aware of any need to reserve some keywords for use by the Historian.

I do not believe this FM can be released to customers in this form: once you
ship  it  you  have to support it for the future.  You cannot do that as you
don't have the buy-in you need from all the other entity developers!

This is  completely  ignoring  the unacceptable, but at least theorectically
solvable,  technical isssue that everyone would have to include (the correct
version  of?)  the  Historian MSL in their MSL compilations.  We have enough
problems  with  asynchronous  updating  of  the  MCC data dictionary without
having to worry about incorporating other people's MSLs in our product!

Graham

    re: .5
    Graham, you are making a supposition (about the registry) and then
    drawing conclusions based on that supposition.
    Part of the registration process (for MCC) will take into account that
    Functions have directives (and maybe attributes and events) that apply
    to a class - the class definitions (that ends up in the dictionary) is
    not a definition of the AM interface!  Thus, if you would attempt to 
    define your own RECORD operation on your entity class, with the intent of
    supplying an AM entry point, I expect the registry to deny your request
    to register the operation as named - and certainly, any code assignment
    would not conflict with one assigned for an FM.
    
    It is certainly true that the "manual inheritance" that we have in
    place in MCC right now is less than optimal. We have decided that it is
    not worth the additional work, right now, to put a hack (or interim
    solution) in place, but to go for the long term solution as soon as
    feasible. This will involve inheritance concepts.
    
    One thing that this series of notes has highlighted (or hilit, if you're
    American?) is that we have done a poor job of getting the information
    out to those who need it. Specifically, we need to document what an AM
    writer needs to know and do around generic FM support, eg.:
    	1/ add some MSL, but no entry points (eg. RECORD)
    	2/ add both MSL and supporting code (eg. REGISTER for *some* classes)
    I hope that we will get this written down soon and distributed.
    
    Colin

   In this note I see at least three different problems:

    1. The easiest:

 >    2) From the FCL, I started recording on a DECnet Phase IV node,
 >   with the following command ;
 >
 >   MCC>record node4 netman partition = "counters", in domain CCEI_1
 >
 >   The other problem is that I cannot delete the recording I started,
 >   I cannot show, yet I try to re-enter the same command , I get a
 >   "recording already exists for specified entity".

   According to release notes "it is recommended that you always enter
   Phase4Name using upper case letters". As I know in the next release
   of the DNA Phase IV AM this is fixed.

   2. Known problem:

>    The background then failed with "Repositories do not exist"

>    Where are the repositories created, and how can I check them ?
>    Obviously, the FM does not find them and is not too happy about
>    it ...  In my case, it seems they were not created. I am running
>    the latest IFT 1.1 DECmcc BMS system, It is the first version of
>    the Historian FM that (to my knowledge) has been made available
>    to the field.

  This is a known problem. When you start a very first recording in
  the specified domain background process fails with "Repositories do
  not exist". In note 377.2 there is a procedure how to restart Historian
  after this error. 

	Restart procedure:

	 a. stop background process

	 b. do SHOW DOMAIN domain_name ALL CHAR
	    it gives you domain_directory(all repositories are created in 
	    this directory !!)

	 c. exit from MCC

	 d. delete files [domain_directory]*.MCC_HIST*.*
	    Note: it deletes history about all domain were
	          created in this directory.

	 e. start background process

	 f. invoke MCC


   3. Is Historian FM generic:

 >    3) A question: I thought the historian FM was generic, yet I cannot
 >   issue RECORD commands for my home-brewed AM.  Does the historian
 >   FM require specific functions to support non-dec entities ? or is
 >   this a temporary IFT feature ?
 >
 >   I suppose this means I have to update my MSL with the Historian
 >   directives. Do I also have to add the corresponding entry points
 >   in the AM service interface component ?

     Answer exist in the reply #4.
     You DO HAVE to include Historian directives in your MSL.
     You DO NOT HAVE to add the corresponding entry points in the AM service 
     interface component.

     Historian does not require any specific functions to support entities.
     The only requirement is - entity has to support SHOW ALL IDENT and
     SHOW attribute partition you want to record.
         

	Sam

Re: .6.

Sorry, Colin, I still don't see what I am missing.

Suppose that  tomorrow  I  start  to  register  (with the DSSR) some new DNA
entities  for  Hastings.  Suppose that one of those entities has a directive
that  I  decided  I  would  call RECORD.  As far as I know, Bob Lynch has no
knowledge  of  any  verbs  which  are  prohibited  for  entities  to  use as
directives except those mentioned in the NCL architecture.  So, he allows me
to register it.  Someone then tries to add this entity to MCC.  What happens
then?

Even if Bob is given the list of Historian FM verbs today, what happens when
they  want  to add another one? By the way, I am not concerned with the code
number  issue:  that is purely an MCC internal interface issue and is easily
solved in a number of ways.  I am concerned with the user interface issue.

>    Part of the registration process (for MCC) ...

WHAT?? Is  there  some  other  registration process I have to go through *as
well as* DSSR?  Tell me I have misunderstood!

> the long term solution ... will involve inheritance concepts.

The problem  is  that  all  these  schemes  fall  down  with  a flat command
interface.   This  is  analogous  to  the  problem Mark highlighted with ISO
management  attribute  names at the last OSI management review.  Inheritance
requires  that the user qualify each name he uses with the name of the class
from  which  it was inherited (to resolve ambiguities).  This really doesn't
work too well with a command line interface.

By the  time  you  have  inheritance you will have a powerful icon interface
which should be able to handle these things much more easily.  Until then, I
still don't think you should go with your manual inheritance.  If you insist
on  going ahead then you absolutely have to address the registration problem
(a process issue not a technical issue).

Graham

    Thank you all for your comments.
    
    re: Pb 1 : I still cannot get the Historian to work, but the log
    file now includes the following message :
    
    %QFILE-E-CREATERR, unable to create or open queue file.
    
    Re : the generic function inheritance problem :
   
    Despite the immediate slight inconvenience, I tend to agree with Colin
    (.6) that in the long-term inheritance + relationship concept is better
    than a short-term hack, as long as we don't have to re-write the MSL
    for all the generic functions we want to support on specific AM's !! So
    the work-around may be to facilitate the "manual inheritance" process
    by providing .MS include files in the toolkit.
    
    short-term problem: where can I pick up a .MS include file which
    will define historian functions ? (if there is one ?) so that I
    can carry on working on my AM ?
    
    Thanks for your help,
    
    Philippe.
    

    Philippe,
    
 >   re: Pb 1 : I still cannot get the Historian to work, but the log
 >   file now includes the following message :
 >   
 >   %QFILE-E-CREATERR, unable to create or open queue file.
    
     This message means that Historian background process can not
     create a file in the domain_directory.
     The first thing to do is to check this directory protection.
     
     To find the domain directory you can do

	SHOW DOMAIN domain_name ALL CHAR


 >  short-term problem: where can I pick up a .MS include file which
 >  will define historian functions ? (if there is one ?) so that I
 >  can carry on working on my AM ?
    
    Please, contact Dave Moore (TOOK::D_MOORE)


	Sam
	

    Ok, I've got the first part sorted out. In fact , I was using a
    wildcard (MCC>RECORD NODE4 *, in domain CCEI) thinking (wrongly) that
    the in-domain qualifier would restrict the wildcard to those nodes in
    the domain. When I started the recording node by node, everything ran
    fine.
    
    As far as the MSL is concerned, I sent some mail to Dave Moore but got
    no reply. Is there someone else who can help me get the .MS for the
    historian commands ?
    
    Thanks,
    
    Philippe.

    RE .11
    
 >      Ok, I've got the first part sorted out. In fact , I was using a
 >   wildcard (MCC>RECORD NODE4 *, in domain CCEI) thinking (wrongly) that
 >   the in-domain qualifier would restrict the wildcard to those nodes in
 >   the domain. 
    
    
    Note such a bad assumption, it is actually an EFT deliverable that
    the in domain filter/limit the wildcard.