Newsgroups: comp.sys.apollo
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
From: system@aurum.chem.utoronto.ca (System Admin (Mike Peterson))
Subject: SR10.3.p is big trouble
Message-ID: <1991Jan18.203853.1893@alchemy.chem.utoronto.ca>
Sender: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Organization: University of Toronto Chemistry Department
Date: Fri, 18 Jan 1991 20:38:53 GMT

We upgraded our DN10020 to SR10.3.p 2 days ago, and in general our
experience so far has not been good:

1) vi still hangs in a DM pad after the first use; it will work once
after the pty's are rebuilt, then hangs ever after. Since we run
X Windows, this is not a high priority issue on the DN10000, but we have
2 DN580's that have sat useless for 8 months already because X takes too
long to do anything, yet you can't use vi in a DM pad on SR10.2 either.
If this problem still exists in SR10.3(.m), the 580's might as well be pushed
over the edge of the loading dock into the dumpster (some would argue
that is where they should have gone long ago :-) ).

2) SR10.3.p almost ran for 2 hours before the tcpd hung and started
eating 100% of the cpu time. While we have had SR10.2.p hang after less
than 10 minutes, this was NOT a good sign. After shutting down from
this hang, the front panel LEDs went to 'PFbF' and the keyboard was
dead. Pressing 'reset' didn't help - went back to 'PFbF' after running
the self-tests. Shutting off the power let it reboot.

3) about an hour ago, the whole system just froze, with 'c d.r t.' in
the LEDs - I crashed it and rebooted, but no idea what caused this one
(though it acts just like TCP hanging did at SR10.2.x.x..p).

4) saving the best for last, NONE OF THE WORKSTATIONS SOLUTIONS 9 TRACK
TAPE DRIVE SOFTWARE WORKS ON SR10.3.p - we get 'absolute load address
already occupied (process manager/loader)' errors. This leaves us with
no backup/restore capability, which is not joyful (we have 4 760 MB
disks on our DN10000, plus over 1 GB of disk on other nodes,
so c-tape is not a useful alternative).

If any one has any ideas what causes the 'load address' problem, I would
like to hear about it ASAP - either e-mail, post or phone me PLEASE.
If any one has any Workstations Solutions stuff that runs on SR10.3.p at
all, I'd like to hear about that too - no one there seems to know what
is wrong, which is somewhat surprising since at least some of them are
ex-Apollo employees.
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775