OBERMAN@ICDC.LLNL.GOV ("Kevin Oberman, LLNL, 422-6955, L-156", 415) (04/19/88)
> 1. Nowdays it should be possible to connect a VS2000 to a thick Ethernet > with a H4000 (or should it?). Have anybody done this with H4000 or > other trancievers. This is true of VS2000s manufactured after Jan. 15 of this year. Units manufactured prior to that date have only have thin-wire. Just which you have is made obvious by the presense (or absense) of the 15 pin AUI cable connector on the rear. > 2. I could't find how to interpreat the configuration ( that what TEST 50 > gives). I found what most of the fields stands for, exept hoe to > interpreat the "error code". For example I get for the NI device following > NI 00100.00001 V1.3 > and would like to know what 100 is for (it not marked as software > error ( ? ) or hardware error ( ?? ). The exact meaning of these bits is known to DEC, but varies greatly from device to device. DEC field service knows the meaning, but I've never seen any reference to them in any user documentation. 3. And the last one. I try to boot a satellitite ( Satellite_config has been run, and ethernet address is OK, and NCP database should be OK) but it will not succed. The bootmember's console displays an errormessage it from DECNET %%%%%%%%%%% OPCOM 15-APR-1988 14:01:22.29 %%%%%%%%%%% Message from user DECNET on XYZZY DECnet event 0.7, aborted service request From node 1.62 (XYZZY), 15-APR-1988 14:01:59.07 Circuit QNA-0, Line open error, Line communication error %SYSTEM-F-TIMEOUT, device timeout Node = 1.122 (ATEST) The other Satellite node boots correctly (no problem at all, its a MicroVax II) This looks like a hardware problem. The boot node is receiving the load request. It tried to respond to the request but the satellite did not respond (TIMEOUT). The node is known, but it can't be loaded. It looks a lot like a case of an NI that transmits but does not receive. This can be caused by either a failure in the NI or an improper configureation. The most common is the connection of a DEMPR to a DELNI. While this is supported, it is only legal if the DELNI is connected to the "backbone" by a non-heartbeat tranceiver. The H4000 has heartbeat. The H4000-B does not. Most third party transceivers are switchable. The problem is that if an H4000-B is used there will be no heartbeat for ANY device connected to the DELNI, and most devices want to see a heartbeat. Here we always connect DEMPRs to the backbone, never a DELNI. And to meet the Ethernet standard (actually IEEE-802.3), this connection should be by non-heartbeat tranceiver. (But it works either way.) If your not using a DELNI, please ignore this, but I'd bet that you are. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. -------
SCHOMAKE@HNYKUN53.BITNET (Lambert Schomaker) (05/27/88)
Hurray!
Finally we have received our VS2000 stations. Naturally I am very
pleased with such an enormous increase in functionality on my desktop.
But, as is invariably the case, there are some annoyances.
(1) One major gripe is that for several harmless features, one needs
SYSPRV privilege to activate them (e.g. DEF/SYS VT_ENABLE_OSC_STRINGS TRUE).
Furthermore, the system manager defines the set of fonts that can be loaded
by the user. What if I am very curious about the non-loaded fonts (some of the
WT fonts from UIS$SELECT_FONT are not too impressive), but I am no system
manager? Also, once, my BANNER got stuck in an RWAST state and I had
to ask the system manager to remove the process and restart it. Customizing
the BANNER also requires SYSPRV/SYSNAM privilege. Does anybody know why they
set it up like this?
(2) Probably related to (1). Is there any way to change the WT window title
from "VT220 Terminal" into something more informative, like a string containing
f$log("sys$node") and f$directory() ?
(3) We have 6 VS2000, all 4 MB +disk, local paging+swapping, in a cluster with
a VAX 750, 7 MB, 1xRA81, VMS 4.7. On the 750, the average number of users is 9,
working sets are (L/Q/E) 150,700,3000. Paging file 32k blocks. The 750 also
runs PSIACP and jNET and Alisatalk processes (about 15 total).
Since installation of the cluster, users on the 750 start complaining about
deteriorated response. Last week, the system "hung" in a strange way:
NULL took still 50%cpu, no excessive paging, swapping, topdio or topbio, only
"Mutex & Misc Resource Wait" was high (25) in MONITOR STATES. Eventually,
logging in or even breaking execution with ^Y was impossible on any terminal.
On the other hand, RA81 access from the satellites was not impaired in any way
during these problems, so workstation users didn't notice until they did a
SET HOST to the 750. We had to reboot, and did not experience big problems
since then. Who has any clues, given this limited system description?
Lambert Schomaker, SCHOMAKER@HNYKUN53.BITNET