Conference azur::mcc

    Catherine, There is a mismatch of expectations here. You are
    assuming that you will get the behavior that if you define
    an attribute, you can use the DEPENDS ON that is defined in
    the Entity Model to provide variant class support.
    
    I don't believe that the DECMCC MSL translator supports the
    DEPENDS ON syntax, and I seriously doubt that the PMs implement
    any intelligent variance that uses it.
    
    I would recommend a discussion with Jim Lemmon before using the
    modelling that you are attempting to use. 
    
    DNA5 node has many children of the global entity node which may
    or may not be present in any particular node and we have never
    had the registration problem you are encountering. You might
    want to consider using a similar model as DNA5 so that you
    do not have the problem. We depend on the Node giving us a response
    of "no such entity" which you would have to implement in your AM.
    
    wally

    re: .0   Your model looks ok.  I believe REGISTER directive always 
    	     issues a SHOW PBX xxx Central * ALL CHAR.  If an error
    	     is encountered, it should still continue.  
    
    	     The DECelms team had a similar problem with REGISTER
    	     last summer and it was qared.  I included the 
    	     qar below.   It was deferred for v1.2 and may have
    	     fallen through the cracks for v1.3.  I will check
    	     into it.
                                                                   
    /Jim                        
    
    --------
    
QAR> 3207  MCC012_INT

QAR # St Sev Pub Cat Maintainer   Component  T Entered-by   Date in     Answer
----- -- --- --- --- ------------ ---------- - ------------ ----------- -----------
03207 DF  M  Yes FN  QD_LEMMON    REGISTRATI M QD_CHILDS    24-JUN-1992  6-JUL-1992
REGISTRATION FM + DEPENDS ON

Site name:        CC303, LAN SOFTWARE, 1753
Product/Version:  ?          V5.4-2             CPU type:  VAXSTATION
Op Syst/Version:  VAX/VMS 5. 5.4
Fixed in release: V1.      Date fixed:

QAR 03207  Version V5.4-2    24-JUN-1992 10:39:30.9

-- Submitted by --                      -- DIGITAL contact --
ED CHILDS                               SLINK::CHILDS
CC303, LAN SOFTWARE, 175339             .
SLINK                                   .
TAY2
227-3509, TAY2-2/B4

Attachments: NONE                               Customer severity: S
Reproducible at will: Y

CPU        Memory     System device
VAXSTATION 24         .

    This is a SHOW STOPPER problem with the IMPM's handling of the MSL
    DYNAMIC modifier.

    The Forwarding Database and Protocol Database child entities of the
    Bridge AM are not handled properly by the Iconic Map PM.  The FCL PM
    has no problem with them.

    For both Forwarding Database and Protocol Database, DYNAMIC=TRUE was
    used in the MSL for these child entities.  With the latest IMPM code it
    was not possible to create a STATIC ENTRY (child of Forwarding
    Database) with the IMPM.  The error message "Forwarding Database must
    be registered" appeared.  I registered the Forwarding Database with the
    dialog box that appeared, and I then had *two* Forwarding Databases on
    my map.  This is clearly a problem -- you should not be able to have
    two entities with the exact same name on your map.

    Per Jim Lemmon's advice I changed my MSL file to DYNAMIC=FALSE for both
    the Forwarding Database and Protocol Database child entities.  This
    supposedly registers the Forwarding Database and Protocol Database each
    time a bridge is registered.  I mentioned to Jim that LAN Bridge
    100/150 bridges do not have Protocol Databases, but Jim said this would
    not be a problem as long as the DEPENDS ON clause is set up correctly.
    Well, I'm having problems and I think I have everything set up
    correctly.

MCC> reg bridge debet100 addr 08-00-2b-0a-c9-39

Bridge LOCAL_NS:.debet100
AT 23-JUN-1992 15:24:22

Partial registration success. Please retry later to complete the registration.
        Reason for Partial Registration = No such entity: Bridge LOCAL_NS:.debet100 Protocol Database *
                         Unknown Entity = Bridge LOCAL_NS:.debet100 Protocol Database *
MCC>

    We are unable to register any LAN Bridge 100s or 150s because of this.

    Here is the section of MSL.  Notice the DEPENDS ON clause.

(************************************************************)
(*                                                          *)
(*   Entity:  BRIDGE PROTOCOL DATABASE                      *)
(*                                                          *)
(************************************************************)

    CHILD ENTITY Protocol Database =    11 :
        IDENTIFIER = (),
        DYNAMIC = FALSE,
        DEPENDS ON = "Hardware Type IN SET (
                 DEBAM LAN Bridge 200, DEWGB DECbridge 90,
                 DEFEB DECbridge 500, DEFEB DECbridge 510, DEFEB DECbridge 518,
                 DEFEB DECbridge 520, DEFEB DECbridge 524, DEFEB DECbridge 526,
                 DEFEB DECbridge 528, DEFEB DECbridge 600, DEFEB DECbridge 610,
                 DEFEB DECbridge 618, DEFEB DECbridge 620, DEFEB DECbridge 624,
                 DEFEB DECbridge 626, DEFEB DECbridge 628,DEFEB DECbridge 505)",
        SYMBOL = CLASS_PROTODB,

    I realize you are all busy getting MCC V1.2 out the door, but we too
    need to get our kits delivered.  Please let me know how I can fix this
    problem.

    /* Ed Childs */


Answer for QAR #03207:
------ --- ------- -------
Thank you for your QAR.

The registration of child entities is not currently tied
to the DEPENDS ON qualifier, I agree that it should be.
Until this problem is fixed a work around is to write the
MSL so that the child entities are not autoregistered.