Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!UTOROCI.BITNET!CAMPBELL From: CAMPBELL@UTOROCI.BITNET Newsgroups: comp.os.vms Subject: 4.6 problems - responses summarized Message-ID: <8801230232.AA16642@ucbvax.Berkeley.EDU> Date: 21 Jan 88 17:03:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 149 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 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" 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 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 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 >> (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: 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: (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.