CAMPBELL@UTOROCI.BITNET (01/22/88)
Over the past couple of weeks I made two postings detailing problems
we've been having with vms 4.6, and I'm happy to say that I got many
helpful responses, which I'll summarize below. To jog your memory, my
problems were, in short,
(1) ^C,^O and ^Y locked up terminals connected to a dhu11 emulator,
(2) A LAT queue was getting hung, stalled and generally confused, and
(3) Asynch decnet was refusing to transfer large files.
Jerry Leichter's response to the decnet problem was posted to the net,
so I won't repeat it here.
Many thanks to all who took the trouble to respond. Every one of the
messages has some information that isn't in any of the others.
===================================
From: Timothy R. Myers <trmst@cisunx>
Yes, we also have a 11/780 and ran into the same problem that you did
with CTRL C and CTRL Y. We also decided to live on the edge and bring
back the YFDRIVER from version 4.4.
This has been running with the v4.4 driver for about 6 weeks with no
noticable problems.
------------------------------------
From: cetron%ced@cs.utah.edu (Ed Cetron)
the DHV and DHU problems with terminals hanging and such on input of
^C,^Y,^O was due to the modification in YFDRIVER of the YF$ABORT code
for 4.6 and was a real mistake. As of 4.7, the YFDRIVER has the 4.6
YF$ABORT code replaced with the 4.4 code which works.
-------------------------------------
From: SEYMOUR@uwaphy.phys.washington.edu
as you've been told a mega times by now:
yes, that's the YFdriver bug fixed in vms v4.7.
dec replaced the yf$abort code with that previously used in v4.4
(just like you did)
it was specifically timeout errors induced by control-Y (-C, etc.).
dick seymour
---------------------------------
From: "Samuel J. Cole" <COLE@CHEMISTRY.UTAH.EDU>
Just to add to all the responses you're getting, YES, there was a bug
in the YFDRIVER.EXE shipped with VMS 4.6. The bug caused terminals
hooked into DHV-11s and DHU-11s to hang. I have an honest-to-DEC
DHU-11 on my VAX 8300, as well as an Able Computer MUX Master, which
masquerades as a DHU-11. Both muxs would hang with the VMS 4.6
YFDRIVER.
---------------------------------
From: Mike Scott <scott@stl.stc.co.uk>
We seem to have the same problem on the CS02 [do you mean this
board?].
It is caused by firmware problems being shown up under vms4.6,
cure seems to be new roms [at an inflated price!].
---------------------------------
From: Andrew Potter <AWPSYS@RITVAX>
The lat bugs you mentioned are known in 4.6. You can get a patch
for them from customer support. LATSYM and LTDRIVER are replaced.
VMS 4.7 also fixes them
----------------------------------
From: Mark Wadsworth <mw@ICS.UCI.EDU>
>> (2) Print jobs occasionally abort on error and are retained
This happens to us occasionally. I have an LN03 connected to a
Decserver 100. I set this up when 4.6 came, so I don't know if there
were any problems with earlier versions. I thought at first that
there was a problem with people doing network copies to the printer
(copy xxx mvax1::$printer:) but I don't think they do that any more
and it still happens every few days. We have two microvaxes, a 730,
and two decserver 100s on the ethernet, all within 30 feet of each
other. All three vaxes spool to this printer. Perhaps our volume is
low enough that the other problems haven't shown up yet.
-------------------------------
From: <BARRY@SERVAX>
We have had the same problem regarding hung queues under 4.6 VMS 4.6
has a new LATSYM symbiont that is now multi-threaded, ie. there is
only one symbiont process serving all LATSYM queues.
The only way we have found to restart a hung queue is to stop the
symbiont process with STOP/ID. You can find out which symbiont is out
of control by doing a SHO DEVICE/FULL LTAn: on the LAT port assigned
to the queue. (You can also do MONITOR PROC/TOPDIO and the hung
symbiont will be right there at the top.)
Regards,
Barry Branch
------------------------------
From: <adriaans@hnykun52.bitnet> (Tom Adriaansen URC Nijmegen)
Hi Chip,
I have had simular problems here with a laser-printer on a
DECserver-200. Before You do a SET DEVICE/NOSPOOL you have to cancel
the appropriate SYMBIONT_00x. This one makes the channels that are
stil attached to the device.
Our queue stands sometimes STALLED and the only thing to do is then
STOP the que, LOGOUT the port on the decserver and START the que.
Disclaimer, I take no responsibilities for software or sayings on this
list.
===============================
I have distilled these messages down to what I see as their essence in
each case, and while I don't think that I took any out of context,
it's possible in principle that some may come across in a different
light than the author intended. Likewise, they were not submitted by
the authors directly for public dissemination, and should be regarded
as private communications which I hope some of you will find of use.
It might be useful, and beyond a purely disclaiming nature, to point
out that as system managers or whatever it's up to us to determine the
suitability of a proposed solution before applying it to our systems.
Like VMS, for example... :-)
Chip Campbell
VAX System Manager
Physics Division, Ontario Cancer Institute
Toronto
bitnet/NetNorth: campbell@utoroci
Hope to meet many of you at Toronto DECUS next month.