|
I was not aware that there were two different Ethernet controllers
supported for the VAXstation 3100 model 38 systems -- the SVA
series, ESA0:, normally refers to a LANCE-based controller. The
ISA series refers to EZA0, an SGEC- or TGEC-based controller.
The former is far more common on the VAXstation 3100 series.
The latter is more common as an integrated controller, and is
particularly found on later systems. Can you confirm the Ethernet
hardware and system type of the failing system?
If you are using NCP> CONNECT and getting this error, TSM is not
likely involved.
Check for network errors on the failing system -- NCP> SHOW KNOWN
LINE COUNT, look for increasing of collisions, defers, and send
failures. (ZERO the counters, and watch the values over time.)
Look for cable faults, transceiver-related problems (heartbeat,
etc), and fir mis-wired Ethernet. Does other network activity to
this failing system show any errors, pauses, or slowness?
As for TSM support and for information on TSM on V5.5-2H4, check the
TSM notes conference and TSM SPD.
Please upgrade from OpenVMS VAX V5.5-2H4 -- the current release is V7.1.
(Without a prior-version support contract, versions of OpenVMS as old as
V5.5-2H4 are no longer supported.)
--
PS: be aware that there is also a MicroVAX 3100 line, excessive
abbreviation can render a question entirely ambiguous. The only
`model 38' shipped was in the VAXstation 3100 series, however.
|
|
While in NCP on both systems, do a
show known lines
Please check results. If you ONLY have the two systems you mentioned,
then it's possible that the circuit database (and possibly others) is
from a legacy node. If you're talking about a cluster using the same
DECnet node databases, but different "style" Ethernet adapters on
different nodes, then you should look more at the definition of the
terminal server in the node database than for a problem. If the two
VAXstations are the only systems in question and they're NOT clustered,
then it's possible that the entry in the node database for the terminal
server on the failing system is from another system that DID have an
ISA-0. From both systems do a
list node (DS90TL address/name) char
to be sure that one of them isn't pointing to a "service circuit
ISA-0." If that's the case, you _should_ be able to force a connection
by entering the following from NCP (fill in correct addresses...)
connect via sva-0 physical address 08-00-2b-XX-XX-XX
That SHOULD bypass any particular node definitions that may be in
conflict and "validate" the connection from a particular station to
the terminal server. Could they possibly be on different networks?
bob
|