RP/MSQ 4.0A (UNIX,NTJ) - DECnet - LD_PROTOERR when initiating connection from VMS to UNIX (Doc ID 776025.1)

Last updated on JANUARY 16, 2023

Applies to:

Goal

Products:  MessageQ for OpenVMS, v4.0A-RP61 
        DECnet I
        Tru64 UNIX 4.0D, BEA MessageQ V4.0A RP36
        DECnet V

First I've started MQ group 2051 on the UNIX side. Following two files were created at that time.

 DMQTRC.PID1
 DMQTRC.PID2

Then I've started MQ group 2021 on VMS side. Following two files were created each time I got the LD_PROTOERR message on VMS side.

  DMQTRC.PID3
  DMQTRC.PID4

Following two files were created when LD connections were finally established.

  DMQTRC.17798
  DMQTRC.17810

Everytime I start MQ group 2021 on VMS side, LD_PROTOERR message is logged. This is reproducible.

I have analyzed the traces.

What I do not understand is why an LDPROTOERR is being returned to the VMS side.  From the link driver source code, the only time the link listener (in this case pid PID4) sends an LD_PROTOERR if the LD_MESSAGE_TYPE !=LD_CONNECT_REQ:

   965           if (LD_MESSAGE_TYPE(message) != LD_CONNECT_REQ) {
   966               LD_MESSAGE_STATUS(message) = LD_PROTOERR;
   967               LD_MESSAGE_TYPE(message) = LD_CONNECT_RESP;
   968
   969           /* write the response out here, who cares  what
   970              goes  wrong,   we  are  killing  him  anyway */

But from the traces, you can see that that the message type is an LD_CONNECT_REQ.  So why does the LD_CONNECT_RESP
sends back a -16:

LD 17798,          LD_trace_message, received {
LD 17798,             sHeader.nType, LD_CONNECT_REQ
LD 17798,             sHeader.nStatus, 0

After two such cycles of returning LD_PROTOERR, the link listener finally accepts and establishes the connection.

What makes it fail the first two times?

Is there anything else that can be gleaned from the logs?

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.