[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

523.0. "PROBLEM: Entities with Constructed Identifiers" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Wed Dec 05 1990 20:35

An entity with an identifier attribute that is a SEQUENCE OF SimpleName
doesn't quite work. If you're wondering why it matters, see the "Recursive
Entities" discussion in the EMA conference.

The first problem surfaces in the MIR lookup routines. I can create an
instance and store it in the MIR without error. But a lookup of the
same AES spec doesn't find it.

MCC> create branch lib cxn collection {Kittell,Fraggle}

Branch Library DEC:.CXN.S.DBS-AIM.MCC.RSK.cxn Collection (Kittell,Fraggle)
AT  5-DEC-1990 15:19:47

Entity successfully created.

MCC> show branch lib cxn collection {Kittell,Fraggle} all ident

Branch Library DEC:.CXN.S.DBS-AIM.MCC.RSK.cxn Collection (Kittell,Fraggle)
AT  5-DEC-1990 15:21:03 Identifiers

No such entity: Branch Library DEC:.CXN.S.DBS-AIM.MCC.RSK.cxn Collection
(Kittell,Fraggle)
                         Unknown Entity = Branch Library
                                          DEC:.CXN.S.DBS-AIM.MCC.RSK.cxn
                                          Collection (Kittell,Fraggle)

===

We know that it is in the MIR, because I can't create it again, and I can
do a wildcard lookup on it. But that is where the second problem arises.
In my SHOW entry point, after the mcc_mir_get_identifiers has found the
instance, I try to mcc_aes_set it into the out_entity parameter per the 
rules. That mcc_aes_set fails with INVDESC. This is the same descriptor
that mcc_mir_get_identifiers set.

If I bugger the status back to normal and proceed, the show completes
with only the first simplename in the sequence displayed as the
collection name.

So it seems that aes_set won't follow the descriptor chain that
get_identifiers returns. BTW, I was pleased to see how the descriptors
were chained, as it is exactly how I represent and store constructed
types in my proto system.
T.RTitleUserPersonal
Name		DateLines
523.1Are you using SynonymsBYBLOS::TAMERThu Dec 06 1990 12:5519
re .0

Rich,

I have a question unrelated to the problem in your note.
How do you get 

	Branch Library cxn 

to translate into   

	.CXN.S.DBS-AIM.MCC.RSK.cxn,

by using synonyms with the Register command ? or by some other way that I am 
not aware of ? If you are using synonyms, are they now available generically 
to all entities or did you do some 'hard-coding' ?

Thanks,
Phil
523.2MIR routines do not support Constructor DatatypesTOOK::GUERTINI have an in_e, you have an out_eThu Dec 06 1990 13:0834
    Richard,
    
    I believe this is a MIR bug, not an AES bug.  The MIR routines can be
    quite useful and even powerful, but they are also quite dumb.  For the
    most part, they look at the length and the pointer of the instance
    portion of the AES descriptor and store that as either a "string" or
    "integer" (it special cases the SimpleName datatype).  They are one of
    the few MCC common routines which do not know how to process
    constructor datatypes (ILV makes you explicitly PUT_CONS and GET_CONS). 
    I believe the routines are probably just storing the first descriptor
    being pointed to.  This non-support for constructor datatypes should
    have been in the release notes, sorry.
    
    Two suggestions:
    
    1) Quick and dirty:
       Perhaps you could ILV encode the instance and have the instance part
       of the AES point to it.  After you get it out you will have to
       decode it back into the "descriptor tree" structure.
    
    2) More difficult:
       The MIR routines really want to think of the "pieces" of an instance
       as alternate identifiers.  This is not the right model for what you
       want to do, but may work with a little tweeking.  The individual
       pieces of the Sequence may be (maybe) stored as separate alternate
       identifiers.  This may involve some tricky (perhaps hacky) modelling.
       One advantage would be that SimpleNames would still be case preserving
       and case insensitive for lookups.
    
    A third alternative would be to wait for the MIR routines to support
    constructor datatypes.  Meanwhile, I will QAR this so it doesn't get
    lost in the shuffle.
    
    -Matt.
523.3CLOSED: MIR doesn't support identifiers that are constructed datatypes.COOKIE::KITTELLRichard - Architected Info MgmtThu Dec 06 1990 13:563
Thanks for the reply Matt. I've got another way of doing what we need. Other
than QARing it, let's drop the issue for now.
523.4another exampleNAC::ENGLANDThu Dec 06 1990 23:016
    Someone might want to tell the Mail Transfer Agent folks about this,
    their MSL has an identifier which is a RECORD.  I just got 
    DNU NCL/CML to handle it, never imagined anyone would do this...
    
    					ben
523.5?MKNME::DANIELEFri Dec 07 1990 11:522
	Someone might want to explain to me the ramifications of the MIR
	not supporting constructed identifiers.
523.6Two major drawbacks...TOOK::GUERTINI have an in_e, you have an out_eFri Dec 07 1990 16:2510
    There are two major drawbacks:
    
    1) When using the MIR to manage private repositories, you cannot easily
       create/delete instances, and add/remove identifiers which are of
       a constructor datatype.
    
    2) Historian cannot record entities which have constructor identifier
       datatypes.
    
    -Matt.
523.7*I* wouldn't want to record this stuff anywayMKNME::DANIELEFri Dec 07 1990 16:398
>    2) Historian cannot record entities which have constructor identifier
>       datatypes.

	Like the SNMP address translation table and tcp connection table.
	Ah well...

	Thanks for the info Matt,
	Mike