OpenVMS Alpha 8.3 DECnet Phase 4 file close delay

[Jim Geier_1]

I am seeing an unusual delay in DECnet phase IV activity when the source is one of our OpenVMS 8.3 systems. This delay takes place when copying files from a system named HCPT to any other OpenVMS system. All of the systems are running OpenVMS Alpha 8.3. I am confident that this problem did not exist when we were running OpenVMS Alpha 7.3-2.

Here is an example of the problem: I can copy a 93-block file called ucount.exe from HCPT to another system called HCPA. Using Control-T shows that 100% of the blocks are copied (93 blocks copied of 93), but on HCPA I see that the EOF is still at 0 and then there is an almost 30-second delay before the file is closed and the command completes. The target disk is not active, and if I copy the same file to a system with no users and almost no activity, the same delay occurs. If I repeat the command immediately to take advantage of the now-existing NETSERVER process, there is no change -- the same delay takes place.

If I copy the same file to HCPT, the command completes in about a second. The problem seems to be copying files from HCPT to any of the OpenVMS Alpha 8.3 systems, strongly suggesting that something is different with HCPT. When I copy the same file from any OpenVMS system other than HCPT to any other OpenVMS system, the command completes within about a second. All of the systems are in the same DECnet area, and I have verified that the DECnet name-to-address lists are consistent (ncp list known nodes, show known nodes).

How can I determine the cause and solution to this problem?

[Jim_McKinney]

DECnet's FAL object has a debug option which might be useful here. See http://www.decus.org/libcatalog/document_html/vs0174_39.html for details on activating it.

[Robert Gezelter · Accepted solution]

Jim,

Before going any further, I would recommend verifying that the duplex settings are correct on the network adapter AND the switch that the system is connected to.

In several client situations, I have seen Full/Half duplex mismatches produce "interesting" symptoms such as these. Small differences in the underlying software affect the collision rate.

Along this line, what are the error counters throughout the network path involved?

- Bob Gezelter, http://www.rlgsc.com

[Volker Halle]

Jim,

COPY uses RMS, so consider to compare the RMS sysgen parameters (SYSGEN> SHOW/RMS and $ SHOW RMS).

On the remote node, you could enable FAL logging:

$ DEFINE/SYSTEM FAL$LOG FFFF

Make sure the NETSERVER process has disappeared, then try the COPY command again. The FAL$LOG output will show up in the remote NETSERVER.LOG file in the login-directory of the remote user. Maybe you can at least spot the 30-second delay. Then it's time to think about what may be causing this.

Volker.

[Jim Geier_1]

Thanks Bob -- I have been focusing so much on isolating and defining the problem from the software and DECnet perspective that I had forgotten to check the duplex settings in LANCP, something so obvious. That was the problem: the switch ports are hard-coded to 100-full, and the adapter was set to autonegotiate, and that never (in my experience) results in a good match. LANCP reported that full duplex was enabled but not operational. I was able to correct the problem with no downtime using LANCP with the commands

> set ewa0 /noautonegotiate/full/speed=100
> set ewb0 /noautonegotiate/full/speed=100

This system, an AlphaServer ES40, had the system board replaced about 7-8 weeks ago, so my guess is that the ew* settings were not scrutinized as carefully as they should have been when the hardware testing was completed.

[Jim Geier_1]

Network adapter duplex setting was inconsistent with switch port setting as Bob suggested. Solution was applied with no downtime to system.