Conference azur::mcc

    
    Well like anything in modeling, there are multiple ways to do things.
    But, what you are trying to do first needs to be better solidified.
    
    To do what you have described is not to my knowledge achievable
    in MCC. An MSL can not be dynamically modified while running. This
    means that you would need to define all of your relationships up
    front.
    
    In defining the relationships there is no way to define an entity
    as both a peer and a child of that entity. Maybe Colin can shed
    some light on some new enhancment of some future change that might
    allow for what you are describing, but the current model does not
    support it. 
    
    What you would have to do is to define, using your example, 3/4/5
    as children of 1 (Node), and then make copies of these same definitions
    3a/4a/4b which you place in your MSL as children of 6/7/8. You would
    also have to copy the definition of 8 to co-exisit as a peer and
    a child of 6.
    
    Up until now you are the first one I have heard ask about coexistence
    of an entity definition as a peer and a child. I have heard of
    subentities that exist under multiple global entities, but that
    is as close as it comes.
    
    I don't know if this helps, hope so.
    

    re: .0
    As we discussed when we met, MCC does not currently have any
    inheritance mechanisms at all. This will get added in in some future
    version. It seems likely that we will address multiple inheritance at
    the same time as we address inheritance.
    
    Thus in the meantime, you should define multiple classes, some of which
    will look surprisingly similar, in most respects, to other classes,
    but from MCCs point of view they are distinct classes. This will
    involve judicious use of an editor (such as one with cut and paste
    capabilities) to duplicate the appropriate parts of the MSL. You will
    also need to register each class - if you do it right (hint - watch
    out for the uniqueness rules listed in chapter 7 of the SRM) you will
    be able to use exactly the same names and codes for all (well, maybe
    I should not say >all<, but it ought to be close) classes that are
    really the same.
    
    Colin

Colin,

We are trying to build the model based on the approach taken with
HDLC and DDCMP in Phase IV you discussed briefly at the meeting.
Another feature we would like to borrow from the model is that of
"dynamic" entities used to represent circuit instances (obviating 
the need to REGISTER them), because of their potentially large 
number at a given time.

I must have misunderstood what you said since I was getting 
really dense (in my head 8-) )!!!

I am reproducing the section from my sketchy notes:

				------------
                                |          |
                                |  Node    |
                                |          |
				------------
                                     |
                                     |
  <--------------------------------------------------------------------------
        |                   |                 |                  |          |
        |                   |                 |                  |          |
    -------------      -------------      -------------     -------------   |
    |           |      |           |      |           |     |           |   |
    | Modem     |      |   HDLC    |      |   DDCMP   |     |   Line    |   |
    | Control   |      |           |      |           |     |           |   |
    -------------      -------------      -------------     -------------   |
                             |	                |              /\ /\
                             |                  ---------------/  /
                             |                                   /
                             -----------------------------------/


I thought that HDLC, DDCMP, and LINE were peers, but LINE can also
be a child of HDLC and DDCMP.  Looks like this is currently not
possible with MSL.

Colin,  if you don't mind, would you please shed some light on the
correctness of the above sketch, and how it has been implemented in
MSL?

Thanks,

Muhammad

    
    I am not certain but I think you may have a wrong assumption. If
    this is the case then it might clarify things a bit. 
    
    When I stated the you would have to copy the msl definitions for
    each of your 3,4,5 entities in two locations, I meant copy only
    those parts that you wanted duplicated. Since it is up to the MSL
    writer to determine if a directive is supported for an entity or
    child entity, it means that when you copy 3,4,5 to under 6 you DON"T
    have to copy the register directive. Every child entity does not
    have to support a register command (for example look at the MCC
    child entities, they support null identifier partitions, but no
    register directive) it is up to you to decide.
    
    In your case it looks like you want 3,4,5 to all support register,
    but as children of 6 you don't want them to.

    

Instead of using an Editor's Cut/Paste, you can use MSL INCLUDE statements.

I expect we'll be using a lot of this in defining the VMS entities.  I've given 
it a quick try.

Create a separate MSL file for the sub-entities.  This file contains the bulk 
the MSL for the entity, but is does NOT include the ENTITY statement, nor any 
of the entity header info.  Looking at the BNF for the definition of the entity 
in the SRM, you can include only the <entity-body> in the include file.  

Then in your main MSL file, do the 

	SUBORDINATE ENTITY  name = code
	IDENTIFIER =
	DYNAMIC =
	SYMBOL =

	INCLUDE file.msl

	END ENTITY name;

It seems like you ought to be able to put the DYNAMIC and SYMBOL in the inlcude
file, but this didn't work.

Then the include file contains all the attribute definitions.

    re: .3
    Sorry if I confused you. Your notes don't match what I meant, but it is
    quite conceivable that they matched what I said (inadvertently).
    
    With reference to your picture, in reality there is a line class
    defined under HDLC and under DDCMP and under CSMACD etc.  (Some may be
    called ports rather than lines). The line class, in the case of Phase V
    is not exactly the same, as each datalink likely has some different
    attributes - consult the appropriate Phase V specs (or contact me
    via mail to get the name of the Phase V project leader who can get you
    more accurate, and up to date, information).
    The management model for terminal servers also has the "same" class 
    (in this case I believe the same definition is used - ie. copied) in
    more than one place in the containment hierarchy. But, they really are
    copies of each other - they do not inherit anything from a common
    superclass.
    
    Does this make it clearer?
    
    Colin

    
    Present MSL only allows include files to contain whole definitions
    as defined in the SRM (excluding most 'END [<definition-name>]'
    statements and possibly a couple of other exceptions).
    
    If MSL needs to change to allow more freedom in where to place INCLUDE
    statements, please enter a QAR.  
    
    								Larry 
    

RE: .4, .5, .6

Thanks for your insights into this problem.

RE: .4

>>    Every child entity does not
>>    have to support a register command (for example look at the MCC
>>    child entities, they support null identifier partitions, but no
>>    register directive) it is up to you to decide.
    
Does this mean that you need to 'register' an entity (or a child 
entity) only when it should support an associated directive?  I went
through SRM, Chap. 7 on Registration once again, and am still fuzzy 
about how it relates to the entity model and MSL, since there is no 
explicit registration directive within MSL.  Or is this the REGISTER
directive to record entity information, which Sec. 7.4 tells me not
to confuse with the registration process?

RE: .5

>> Instead of using an Editor's Cut/Paste, you can use MSL INCLUDE statements.

>> Then the include file contains all the attribute definitions.

This sounds like a very useful feature of MSL!  Is this documented
anywhere?

RE: .6

>>    With reference to your picture, in reality there is a line class
>>    defined under HDLC and under DDCMP and under CSMACD etc.

So there is a virtual entity model and a physical entity model!  How
about a logical entity model?  ;-)

The methodology then seems to consist of first developing a 'virtual'
entity model through information modeling, or the entity determination
process.  This gives a static, graphic view of manageable objects.
MSL may or may not be able to represent this view.  If it does not, 
then based on the limitations of MSL and the nature of interrelationships
between the entities in the object, go through a tranformation 
process (i.e., include or cut-and-paste) to produce another view, that
can be translated into MSL syntax.  

Is this the correct approach?

    RE: .7
    
    Since MCC claims to monitor, control, and test manageable "objects"
    (called entities), I envision MSL to evolve into supporting the
    following key features of object-oriented languages:
    
    	-    Encapsulation
    		for instance, INCLUDE should be able to weld 
    		entities-directives into a single object.  A general case
    		would be for the MSL syntax to support this directly so
    		multiple instances of such objects can be defined in the
    		hierarchy.
    
        -    Inheritance
    		To provide for commonality of functions while allowing as
    		much specialization as needed.  Ideal case would be to
    		provide for multiple inheritance.
    
    	-    Polymorphism
    		By providing virtual functions with late binding, so many 
    		versions of the same function can be used throughout the 
    		entity hierarchy.
    
    	-    Overloading
    		I guess this is already implemented.  Such commands as SET
    		and SHOW can be made to work on various entities.
    
    Let's hope for the best!!! 8-)
    
    Muhammad

    
    Okay, RE my comment in .4, the "register" in question there was the
    directive, not the registration process. You register through the
    registration process ALL entities and child entities you plan on
    managing; but you support the register verb (the command to enter
    an entity, parent or child, into the configuration) only on those
    child entities where you need it (and all global entities). An example
    of where you wouldn't support the register directive is on the bridge
    child entity called the forwarding database, it has no identifier
    associated with the child entity class and therefore a register
    directive would not make sence.
    
    In regards to .9, as Colin had mentioned there are a lot more things,
    especially relationships, that still need to develope more before
    MSL matures. Keep the ideas coming.
    
    jill
    

Hmm, I've read Muhammad's questions and think I understand what you want.

First I suggest you read up on the entity model, and in particular the paper 
I wrote that gives guidelines on how to write your management spec for your
entities. [by the way, you are not writing an entity model. There's only one
of those. MCC developers keep screwing this up, what is documented
in an MSL file is a Management Specification, not an entity model. Flame off.]
There is a long white paper describing how inheritance will be added to the
entity model and EMA. You can presume when that is done, MSL will be changed
to support it as well. Until that time, there are lots of other techniques
for dealing with variation and similarity between entities. Rather than wait
for those, I suggest you use what's available today.

Start with FILES::EMA$:[Public] 
look at README.FIRST as a starting point.
You want in particular
	WP-Object-Oriented.ps		for OOPL like features
	ENTITY_ARCH_GUIDELINES.PS	for guidelines on how you can do a good
					design of an entity's management spec.

Mark

    re: .9
    I concur with Mark's .11 reply.
    
    However, a nit on your .9 - I believe we are likely to implement
    allomorphism, rather than polymorphism.  Hopefully, you won't need
    to know the difference.  If you care, you might wish to consult the OSI
    Management specifications.
    
    Colin

    RE: <<< Note 181.10 by GOSTE::CALLANDER >>>
    
>   ...An example
>    of where you wouldn't support the register directive is on the bridge
>    child entity called the forwarding database, it has no identifier
>    associated with the child entity class and therefore a register
>    directive would not make sence.
    
    Maybe this is just a nit, but...
    
    It turns out that the REGISTER directive *is* supported for BRIDGE
    FORWARDING DATABASE.
    
    It must be in order for individual PHYSICAL and MULTICAST ENTRIES to
    get REGISTERED (since they are children of FORWARDING DATABASE).
    
    It is not *automatically* REGISTERed when the BRIDGE is, due to some
    problems that will hopefully be addressed in V1.1 (with VARIANT
    support).

    OOPS, not a good example, should have checked first. But hopefully
    the point was not lost.
    

    
    .14>>>  OOPS, not a good example
    
    I now have a fairly good idea about the capabilities (or is it current
    incapabilities? :-) ) of MSL (I think)!!!  Pointers provided by Mark in
    .11, and those in EMA conference, particularly the DDA Phase II 
    Management Spec. by Ed Marison have been very useful in providing ideas 
    about implementation methodology, and some sense of future direction 
    for EMA and DECmcc.
    
    Now if DECmcc Toolkit can provide a tool to automagically translate
    those ideas into a Management Spec. ;-)  Till such time back to the
    drawing board!!!
    
    Thanks for the tips.
    
    Muhammad