wasserroth@fokus.berlin.gmd.dbp.de (Stephan Wasserroth) (05/12/88)
Hello, world!
The following is a short story of ethernet problems, a kind of solution and
a (moderate) flame to the "supporting" companies.
Chapter 1: The Problem
---------
We have a central VAX/VMS-machine, a pure VAXBI based 8530 system, with the
newest version of the DEBNA - BI-Ethernet-Adapter. This system runs in an
Ethernet-based DECnet. Almost all of our terminals (some 50) are connected
to DECserver 200 and therefore the LAT-protocol is used for terminal
access to our (main) VAX. The VAX ran VMS V4.5. This environment was
working fine.
But we have also a bunch of SUN workstations, which are communicating over
the ethernet using TCP/IP protocols. So we decided to use the TCP/IP
protocols on the VAX as well. We got the WIN TCP/IP and WIN NFS package from
Wollongong, which is distributed in Germany by "danet GmbH". We wanted
to use the "shared BI-driver" software, so no new hardware was necessary.
We installed the WIN TCP/IP, configured it according to the manuals and
fired it up.
--- but it did not work ---
Eventually, we found out that the "shared BI-driver" was the problem. It
died with something like "insufficient virtual memory".
Chapter 2: The Search for a Solution
---------
We called "danet". Some phone-calls (and some weeks) later, they had the
answer: "There is a patch to the ETDRIVER.EXE for VMS 4.5 and 4.6". [The
ETDRIVER.EXE is the ethernet driver of DEC which is used by the "shared
BI-driver" as well. The error message above originated from this software.]
We got the patch. --- but it did not work ---
"danet": "Do You have the newest release of the DEBNA?" Our friendly DEC-
service-person installed the latest FCOs. Some weeks (and some phone
calls) later, we tried again. --- but it did not work ---
We got VMS V4.7, did the upgrade --- but it did not work ---.
More phone calls (to "danet", DEC and "GEC" [the distributor of the WIN
packages in Europe, they deliver it to "danet" which delivers the
software to the customers :-} ].
"danet": "The problem is the DEC-supplied ETDRIVER, so call them!"
DEC: "If third parties are using our drivers, it is there problem, call them!"
"GEC": "The problem is solved in VMS V5.0" [sic ...]
"danet" + "GEC": "Don't use LAT" [A great laughter ...]
All in all: Nobody knows anything, nobody was able or willing to help,
everybody told us: "It is not our problem, it is Your problem".
THIS IS NOT THE SUPPORT FOR WHICH WE ARE PAYING A LOT OF MONEY!!
(That was the flame!)
Chapter 3: The REAL solution
---------
Again some weeks (and phone calls) later. We found out (with nobodies help!):
Environment: VMS V4.7, "shared BI-driver"
running software: DECnet, LAT and
--> the Ethernet Configurator Module <--
We stopped the Configurator (NCP SET CONF KNOW CIRC SURV DISABLE),
started the WIN TCP/IP package === and it WORKED === (finally)!
Now why nobody (especially DEC) was not able or willing to tell us that
the number of buffers in the ETDRIVER is too small to run more than
DECnet, LAT and the Configurator (or any other three systems, i.e.
DECnet, LAT and TCP/IP or DECnet, Configurator and TCP/IP ...)
concurrently? I really don't know!
Now the error message "insufficient virtual memory" is generated, if
the ethernet Configurator is started, but this is acceptable till V5.0.
Chapter 4: Conclusion
---------
If You have an BI-Ethernet-Adapter and VMS 4.5 or 4.6: obtain a patch
for ETDRIVER.EXE, then three "software-systems" may use the ETDRIVER
concurrently.
If You have VMS 4.7: You don't need a special patch, but the limit again
seems to be three products. [I am waiting for a further patch anyway ;-)].
If You have VMS 5.x (?huh?): You shouldn't have a problem.
In any case: Look for "hidden" users of ETDRIVER-buffers (Configurator...).
Please send comments directly to the address below, because I am
currently not on these mailing lists.
DFN-EAN: <wasserroth@fokus.berlin.gmd.dbp.de>
ARPA: <wasserroth%fokus.berlin.gmd.dbp.de@relay.cs.net>
/ GMD-FOKUS
Stephan Wasserroth \_ _ _ _ _ _ _ _ _ _/ Hardenbergplatz 2
System Manager for / \ D-1000 Berlin 12
VAXes and Sun-WS \ Fed. Rep. of Germany
-------DLQ@UGA.UGA.EDU (David Quarterman) (05/20/88)
Your problem sounds like the following note in the installation guide for the Fusion TCP for VMS: "The ETDRIVER allocates a maximum of 26 buffers for use by all clients. If FNS (the Fusion TCP) will be sharing the DEBNT with DECnet, as many as 24 buffers may already be in use. Because the ETDRIVER allocate a minimum of four buffers per channel and FMS/TCP requires two DEBNT channels, there may not be enough available. The number of channels actually in use may depend on the DEcnet families in use. If FNS is unable to successfully allocate channels to the DEBNT, the FNSACP process will fail with an Insufficient Dynamic Memory omplaint. (This problem is NOT, however, related to the size of NonPaged Pool.) To correct this problem, it is necessary to patch the ETDRIVER to allocate a larger number of buffers. Please contact Digital Equipment Corporation for assistance in patching the ETDRIVER."