On 2014-11-17 11:05, Rich Alderson wrote:

> We have a crumbling DELUA in the VAX-11/780-5 at LCM. There is a > copy of the *User's* Manual at Bitsavers, but not the *Technical* > Manual. Does anyone happen to have a copy lining the hamster cage > floor, vel sim.?

Don't have the manual. I *might* have the diagnostics. I need to check when I'm back in Seattle in a couple of days.

What is "crumbling" about the DELUA?

from the latest console log:

As far as I know, CMU/IP was a vallient attempt to create a TCP/IP stack that runs exclusively in user mode. I've never known it to work satisfactorily for any length of time in any sort of production environment. Typical problems include processes hanging or exiting for reasons that are difficult to debug and harder to solve. If the version of VMS and available disk space allows, maybe you could install Multinet from Process Software? Even recent versions of Multinet will install on VAX/VMS as far back as V5.0. Other possibilities include TCPWare and TCPIP Services. I have little experience of either of the latter but in my opinion they wouldn't have to do much to beat CMU/IP for reliability, performance, usability and documentation. And I'm sure none of them would make the interactive response slow and painful the way CMU/IP used to either. There is a certain argument for preserving the user experience in a museum environment but maybe there are some experiences that are best not preserved :-) You can generally find out what a VMS status code is telling you by just giving it as argument to an EXIT command at the dollar prompt. Here's the result from OpenVMS Alpha V8.3 - some things just don't change: $ EXIT %X1C %SYSTEM-F-EXQUOTA, process quota exceeded IIRC this was a fairly standard CMU/IP failure mode. Unfortunately, VMS has lots of different process quotas and any one of them could be running out. Prime suspect is pagefile quota (virtual memory). If the process hasn't exited, SHOW PROCESS /QUOTA /ID=<process id of IPACP process> may show what the problem is but my bet is that if the relevant quota is increased, it will run out again. I remember having that sort of grief with CMU/IP on a VAX 6410 more than 20 years ago. The problems persisted until it was possible to convince the management to spend the money on a proper TCP/IP stack that ran in kernel mode. That cured it completely and made life so much easier. I would suspect CMU/IP before the hardware. The increased frequency of the problems may be due to differing conditions on your network. If the network adaptor is really having hardware problems, it will probably be making entries in the error log. Use SHOW ERROR to make a quick check for devices which are clocking up errors and ANALYZE /ERROR_LOG to format the error log in human readable form. HELP ANALYZE should give hints on what command qualifiers to use to select the error log entries of interest. If you've already got all sorts of stuff in the error log that you are not interested in, you can RENAME SYS$ERRORLOG:ERRLOG.SYS ERRLOG.OLD for example and the system will start a new error log the next time it has something to log or in a few minutes if nothing happens. If there is nothing of interest in the renamed error log, you can delete it after the new log is started if it is large and disk space is an issue for example. If your network adaptor is attached to a network transceiver that doesn't have SQE test enabled, you will clock up errors similar to "collision detect carrier check failed" every few seconds. This is highly unlikely to represent a real problem and can be ignored if you can put up with the irritation. Using a tranceiver with SQE test enabled should get rid of it. Regards, Peter Coghlan.

There is a poorly phrased entry in the CMU/IP FAQ which could give the impression that CMU/IP uses it's own error codes that are entirely different from VMS status codes. What I think it is really trying to say is that like many VMS applications, CMU/IP defines _additional_ status codes that VMS does not already have suitable messages defined for and the text messages associated with these are not available unless the appropriate CMU/IP provided message files are loaded. Low numbered error codes such as 1C (and another favourite - 0C which is %SYSTEM-F-ACCVIO, access violation) come from system services and runtime library functions that are part of VMS and the message texts are made available automatically by VMS. It is not the case that CMU/IP reporting an error code of 1C means something different to some part of VMS reporting it. They both mean process quota exceeded. Directly underneath that entry in the FAQ, I found the following: about Looks like my pagefile quota guess was wrong and the culprit is BYTLM. However, I suspect the underlying cause of this problem has never been fully addressed and increasing the quota will not help, or worse, will help for about a week before the problem returns even more frequently. I cannot overemphasise how much relief will be experienced on the replacement of CMU/IP by something that works properly or even by something that doesn't mess up as badly. Problems that you didn't even know you had will go away, even ones which seemed unrelated to networking. On sunny days, the sun will seem brighter and the sky bluer :-) In my previous posting, I forgot to mention that you can also try: $ MCR NCP SHOW KNOWN LINE COUNTERS if running DECnet. This will give DECnet's view on any network media problems including those relating to other protocols going through the same network adapter. It probably won't have much to say about hardware failures in the network adapter though. Remember that on a half duplex ethernet, collisions are normal and expected but late collisions indicate a problem. Regards, Peter Coghlan.