Conference azur::mcc

3419.0. "Address not returned from DECnet/OSI entity" by OSLACT::BJORN (Woops, now I have to learn changing diper's) Thu Jul 23 1992 11:35

I'm running BMS V1.2, and DECnet/OSI BL10_L. When doing SHOW NODE from FCL I get
this output;

                              
MCC> show node .nwo.nwomcc all char

Node NORWAY_MCC:.nwo.nwomcc
AT 23-JUL-1992 16:19:24 Characteristics

Examination of attributes shows:
                                Version = T5.0.3
                         Implementation = { (
                                       Type = VMS,
                                    Version = "V5.5    " ),
                                            (
                                       Type =
%MCC-E-NOENTITY,  no corresponding entity instance exists
 ) }
%MCC-E-NOENTITY,  no corresponding entity instance exists

                      Maximum Listeners = 0
MCC>
'

What is missing in the "no corresponding entity instance exists".

The node is registered using DECNET_DNS_REGISTER.COM and given PhaseIV address.

From the IMPM, when entering the node in a domain, I get the add entity window
to fill in information about synonym name and so on, even if this information is
already entered into the NAmespace by DECNET_DNS_REGISTER.

When I'm from the Operations list box is doing a SHOW IDENT, the address field is
--NOT RETURNED--. From NCL> SHOW NODE 0 all IDENT, the address field is also 
blank. Could someone explain me this behaviour?

When I'm doing SHOW CHAR from the Operations List Box, I get a message saying
"no corresponding entity instance exists". What is missing?

Bj�rn Olav Haugom

Something is not setup correctly on your PhaseV node.  I would post
a question in the DECNET-OSI_FOR_VMS notes file asking how to correct
the problem.  Actually it looks like two problems.  One, the node is not
sending back its address information for a show request, and two, the
TYPE field of the Implementation set isn't being sent back.

Apparently NCL handles the second problem by displaying a question mark.
In MCC, the translation code expects this info to be returned so that it
can go to the MCC dictionary and decipher the data.  The message
"no corresponding entity instance exists" is the result of not having the
proper data returned by the entity.  I suppose that doesn't look very
pretty and I'll take a look at how difficult it would be to return a better
message.

In any event, it is the DECnet implementation which is not sending back
complete data.
    

I entered an entry in DECnet-osi conference, and I got an answer to this problem.
Something had been pulled out from BL10_L and put back in again in BL11_K. What
it was, I haven't got an answer to, yet. I'll upgrade to BL11_K asap.

Bj�rn Olav