Conference azur::mcc

The DNA5 problems are entered as QAR 2809.

The DNA4 problem is addressed (and resolved) in note 2790.

The answer to QAR 2809 indicates that the DNA5 AM problems will be
deferred until after V1.2 ships.

    The QAR 2809 is not solved in version V1.2! Both VMS and ULTRIX
    versions have the same problem with the IMPM and DNA5 AM:
    
    Double clicking on Routing subentity on a DECnet/OSI for ULTRIX node
    the following message appears:
    
    Look Into Entity Node GOYA_NS:.phv_node.spanix Routing IP Routing Protocols
    
         The requested operation cannot be completed
         Entity Existence Info      Entity Existence Cannot Be Determined
         VMS Routine Error          No children
    
    Due to that it is imposible to represent at the node entity level the
    subentity 'routing circuit', because it is not possible to get the
    Toolbox with the subentity 'routing circuit' in it.
    
    Does anybody detected the same behaviour?
    
    If it is really a problem, is there any plans to solve it?
    
    Angel.

According to the response in .-2, the QAR answer indicates that the
DNA5 portion of the problem was NOT addressed for V1.2, and will not
be fixed until a future release.

I have entered a QAR (#461) against DECnet Ultrix for this problem.
The response the AM gets back for this request is malformed which causes
the AM to believe it needs to take a path which it shouldn't.

I also tested this request against VMS DECnet/OSI (WaveII) and
the Wanrouter 500 and they both give the correct response.

The contents of the qar follow.

John

For the request:
MCC> show node glsair routing ip routing protocol
I get a malformed error response back with DECnet Ultrix v5.1.

IP ROUTING PROTOCOL is a module, with no instance (identifier)
defined in MSL.  When Ultrix forms a cmip error #33
(EntityClassNotSupported) for this request, it sends back
APPLICATION 29 (KNOWN) instead of Null (5).  This is incorrect.
It's my understanding that APPLICATION 29 should only be sent
with a request, it should not be returned with an exception.
In any case, we didn't even send it.  What I _should_ see here
is Null, just like the request sent, and like what is the
registered instance for this module.

This problem is causing the DNA5 AM in MCC to believe it needs to
build this instance into a dictionary spec which it in turn uses
to get information from the dictionary about it.  Well, that call
fails because there isn't an instance defined for this module.

	John Purretta



This is the request I'm sending.

[  1 ] (
    [  2 ] 00000001
    [  2 ] 00000003
    [  16 ] (
        [  0 ]         2b 0c 02 87 73 02 01 01 04 08
        [  3 ] (
            [  5 ]
            [  5 ]
            )
        [  11 ] (
            [  1 ]             01
            )
        )
    )


Incorrect response:
This is the response that Ultrix DECnet/OSI sends back.

[  3 ] (
    [  2 ] 00000001
    [  2 ] 00000021
    [  16 ] (
        [  0 ]         2b 0c 02 87 73 02 01 01 04 08
        [  3 ] (
            [  5 ]
            [ APPLICATION 29 ]
            )
        [ APPLICATION 17 ]         0c b5 70 dd b5 72 cb 01 b1 1f c2 07 00 00 78 10
        )
    )


Correct response:
This is the response that VMS DECnet/OSI and Wanrouter 500's send back.

[  3 ] (
    [  2 ] 00000001
    [  2 ] 00000021
    [  16 ] (
        [  0 ]         2b 0c 02 87 73 02 01 01 04 08
        [  3 ] (
            [  5 ]
            [  5 ]
            )
        [ APPLICATION 17 ]         b1 0c f8 07 b6 72 cb 01 9b ac 5c 00 00 00 10 1f
        )
    )

I agree  with  the  QAR  (but then I would because you said it works with my
code!) but I have one minor nit:

> It's my understanding that APPLICATION 29 should only be sent
> with a request, it should not be returned with an exception.

You will  get  "KNOWN"  back if that is what you send in the request and the
error  is  one which means no entity responded (no such entity, entity class
not  supported,  directive not supported, etc.).  If the directive never got
as far as an entity who could respond my implementation copies the entity ID
from  the request into the response.  In the case in the QAR you didn't send
"KNOWN" so I think you are right that you shouldn't see it in the response!

Graham

    Thanks Graham.  I guess that makes sense.  If a wildcard was sent
    then the exception returned could contain it.
    
    In the case mentioned here, there isn't an identifier defined so
    MCC would never have let one get passed down to the AM.
    
    I have since placed some defensive code in the AM to detect and handle
    the problem mentioned in .0
    
    John