Internet interface disappeared - cant stop tcpip

[Mike Smith_33]

Hey guys, strange one here. I have been making a sysconfigdb change to each member in a 3 node cluster. We have done one a day and stopped and restarted tcpip with no problem. Today, on the last node when I went to shutdown tcpip it gave

Begin Shutdown...


%TCPIP-I-INFO, TCP/IP Services shutdown beginning at 15-AUG-2007 09:36:23.10
%TCPIP-E-INETERROR, internet interface error
-TCPIP-E-NOINET, the internet driver is not loaded

This through me and after a couple of checks I discovered that my tcpip license was not loaded. I loaded the license and then tried again, samme problem. I can't start tcpip because it is up and I can't shut it down because of this. I went through the configuration of the interface again and the correct settings were there so I used them again. Still got same error. I finally decided to go for the reboot as the natives were getting restless.

Any insights on what happened. VMS 7.3-2 tcpip 5.4 Eco 4 or 5

[Hoff · Accepted solution]

This appears to be what is usually known as a degenerate failure case. More specifically, this is a bug in the implementation of the TCP/IP Services startup and shutdown and one that would only be rarely seen.

Arguably the exposure to this error is greatly reduced within OpenVMS I64 (though inclusion of TCP/IP Services in the OE licenses), this would be fodder for a bug report against OpenVMS Alpha TCP/IP Services.

The hack approach would be an iterative process of connecting together enough of what would occur in the startup (manually) to get the shutdown to run to completion, or to disconnect enough of the tests in shutdown to get it to run to completion.

Or reboot.

[Mike Smith_33]

Apparently TCPIP was in some sort of limbo state between going down and actually running.
A reboot, of course, got me going again. A reboot to correct this issue turned out to be a better path than spending a lot of time tracing through the parts of tcpip.

[Willem Grooters]

A reboot, of course, got me going again. A reboot to correct this issue turned out to be a better path than spending a lot of time tracing through the parts of tcpip.

That's right - but have you taken the opprotunity to make a crashdump and send that to HP for examination? As liong as there is no data available, HP won't be able to trigger the issue - for another customer!