morrison@nucs.OZ (David Morrison) (05/01/87)
We have recently (January) replaced two VAX 11/780s by two VAX 8550s. This
also meant replacing nice predictable DZ11s with an Ethernet and DECserver
200s. We also have a Micom Micro 600 port selector. For various reasons,
most of the DECservers have temporarily been connected in place of the DZ11s
on the back of the Micom, and set to be transparent to the users.
However, we have taken advantage of the ability in LATplus V1.1 to have serial
printers (LA120s) shared between the two machines. Certain terminals which
only access our library circulation system have been connected directly to
servers, with the server configured as dedicated to that machine. (They are
VT100s and lookalikes used with Fortran and FMS for enquiries, etc.)
Since January, we have had no problems with the DECservers connected to the
Micom. However, we have had no end of problems with the DECservers used
directly. Appeals to DEC software and hardware support have been no help at
all. Can anyone offer any suggestions on the following problems?
1. Most of the library terminals jam up about once a fortnight for no apparent
reason. The symptoms are that any character typed is not echoed, and a beep
sounds. If it were connected to a DZ, I would say that it was input buffer
overflow on a terminal with NOHOSTSYNC. However, the terminal characteristics
are explicitly set to HOSTSYNC, and in any case, the server was configured
for XON/XOFF flow control. Strangely, the job running at that terminal
disappears! Even more strange is that fact that the server still thinks that
something is using the terminal, since its status display shows the port still
connected to the host. The only way to clear this is to connect to the
server's remote console with NCP and manually logout the port.
(I'm not sure what the relationship of HOSTSYNC is to the DECserver software.
It appears that the server attempts to emulate the behaviour of a DZ line for
buffer overflow, that is, if HOSTSYNC is set, send an XOFF to the terminal (ie,
lock the keyboard), otherwise, reply with a beep for every character lost. For
a DZ, you can unlock the keyboard and type a Ctrl/Y to interrupt whatever is
going on. For a DECserver, nothing can get through until the host issues a
read. For NOHOSTSYNC, Ctrl/Y interrupts the program on both DZ and DECserver.
All this in spite of the DECserver being configured for XON/XOFF flow control!)
2. The queues for the serial printers that are heavily used often appear in the
stalled state, and eventually stop. They then have to be manually restarted.
We have observed this behaviour on printers connected to DZ11s when there has
been a paper jam or something else that caused the printer to send an XOFF. In
this case, it looks as though the queue gets stalled because the other VAX is
using the printer. This is not always the case. Sometimes it stalls in the
middle of a print job, and the queue stops, leaving the job checkpointed. The
other VAX cannot get the printer because the server still thinks it is
connected to the machine with the stopped queue.
Surely the LAT symbiont must be able to recognise that it is in a queue for the
printer, and avoid stopping the queue.
3. I wanted to be able to login to a local Unix machine and copy files around,
so I set up an applications port with LATCP. I first tried using SET HOST/DTE
LTAxx: just to see if I had everything set correctly. I found that even though
the line was set to 4800 baud, the output was coming back to me at about 30
characters per second. Later on, it picked up a bit, but after about 1 - 2
minutes, it locked up and nothing had any effect except exiting from SET HOST
with Ctrl/\. So I tried Kermit, which at least gave reasonable speed, but it
eventually locked up also. I suspect that it is again a synchronisation
problem. Changing the line to NOHOSTSYNC made no difference to SET HOST (since
it sets HOSTSYNC itself!!), but caused Kermit to lose incoming characters.
(This cannot be attributed to Unix since I tried connecting the line to the VAX
I was using with the same results. (Is this incest? :-))
Someone suggested disabling the flow control at the DECserver, and this seemed
to work, but I wonder what will happen at high baud rates when the Ethernet is
busy. 19.2Kbaud = about 150 characters in 80 milliseconds which is the time
between messages on the Ethernet. Has the server got enough buffer space?
The first problem could possibly be triggered by noise on the lines to the
terminals, since we haven't got enough money yet to extend the Ethernet to the
library. (We have had remarkably few problems driving RS232 signals up to 4800
baud for over 2 kilometres.) However, I cannot see why this results in the
behaviour we have seen.
PS Has anyone any experience with DEC's Terminal Server Manager software?
Thanks in advance for any help
David Morrison, Computing Centre, Uni of Newcastle, Australia
ARPA: morrison%nucs.oz@seismo.css.gov
UUCP: {seismo,hplabs,mcvax,ukc,nttlab}!munnari!nucs.oz!morrison