DECmessageQ 3.2 and TCPIP 5.0 Problem

dwlc — Sat, 14 Sep 2019 20:21:52 GMT

Greetings.

I am supporting a legacy OpenVMS applications that makes extensive use of DECmessageQ 3.2 over TCP/IP with communications to WIndwos PC systems and also to other DEC VAX and Alpha systems. These systems have been running for 20+ years with no software upgrades during that time. The Alpha systems are running OpenVMS 7.2.

Recently there was a complete power failure at the site including the UPS system so that all sysems lost power and needed to be restarted. After performing an orderly startup of the systems we determined that there was a problem with the DECmessageQ communications between the Alpha and PC systems, but NOT between the VAX and PC systems. There are also no apparent communication problems between the VAX and Alpha systems (which would use DECmessageQ over DECnet). The VAX and Alpha ssytems make extensiev use of DECmessageQ broadcast messages including ethernet broadcasts.

The problem is seen at the application layer as regular delays in messages being processed on the Alpha systems. The Alpha systems are not at all busy, but messages appear to be "stuck" in the pending queue of both the TCPIP_LD queue on the Alpha and also on at least one Alpha application queue. These messages appear to be stuck in the pending queue for up thirty or more seconds and then they are processed. It does not appear that we are losing any messages, but messages are being delayed by a minute or longer and this causes communication faults to be reported. The PC systems are reporting "PAMS__TIMEOUT, Timeout period expired".

I have checked various DMQ, TCP/IP and application logs and not found anyc clues to the cause of the underlieing problem. The various network counters I have looked at do not indicae any TCP/IP errors. It is unclear why this problem would start now, falling this particular complete network shutdown. I cannot recall the last time that the entire network was offline but it was likely ten or more years ago. The VMS systems and PC systems have been restared periodically over the years without any of these problems.

I have tried isolating the network and that made no difference on the behaviour. I have also tried setting the time back to verify that the problem is not related to some time bug. I have verified that the systems are synchronized so it is not some time-differential problem.

This problem appers to be a DECmessageQ/application problem specific to the communications between the OpenVMS Alpha applications and the Windows PC applications, but does not affect Alpha to VAX or VAX to PC communications. It is unclear why the problem started following he complete network shutdown.

Is there anyone out there familiar with DECmessgeQ (3.2)?

Dan

Re: DECmessageQ 3.2 and TCPIP 5.0 Problem

Jur van der Burg — Sun, 15 Sep 2019 07:20:18 GMT

Generally these delays can be caused by failed dns lookups. I would concentrate on changed dns settings or changed nodenames.

Jur.

Re: DECmessageQ 3.2 and TCPIP 5.0 Problem

dwlc — Mon, 16 Sep 2019 04:43:24 GMT

Well, your answer appears correct. When querying known hosts from the Alpha systems we appear to get a timeout from the Windows DNS server. I have added the key windows PC systems to the local Alpha and Vax TCP/IP host databases. These mysterious time delays have gone away. I am not sure what the problem is with the DNS server or whether it is a problem with the Alpha TCP/IP configy. In any case adding the Windows nodes to the VMS local databases has done the trick.

Thank you for your much appreciated advice.

Dan

topic DECmessageQ 3.2 and TCPIP 5.0 Problem in Operating System - OpenVMS

DECmessageQ 3.2 and TCPIP 5.0 Problem

Re: DECmessageQ 3.2 and TCPIP 5.0 Problem

Re: DECmessageQ 3.2 and TCPIP 5.0 Problem