Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!felix!info-ultrix
From: yba@sabre.bellcore.com (Mark Levine)
Newsgroups: comp.unix.ultrix
Subject: Re: ULTRIX 3.0
Message-ID: <81559@felix.UUCP>
Date: 30 Jan 89 20:55:45 GMT
References: <76661@felix.UUCP>
Sender: info-ultrix@felix.UUCP
Reply-To: yba@sabre.bellcore.com (Mark Levine)
Organization: Bellcore, Red Bank NJ
Lines: 58
Approved: zemon@felix.UUCP
Reply-Path:

Reply-to: yba@sabre.bellcore.com (Mark Levine)


In article <76661@felix.UUCP> hubcap@hubcap.UUCP (Mike Marshall) writes:
>It's got an obsolete version of BIND (4.7something) with "DEC enhancements"...
>kinda scary if you think about it. Who knows though... maybe the enhancements 
>are fixes for whatever it was that made everyone eschew 4.7.
>
>Looking forward to what everyone else has to say...

Our biggest problem with 3.0 is we got it before customer support....

I run BIND on an 8650, and it works well except for the case where the
secondary server loses the primary for longer than the cache time,
after which you get wonderful "Cannot find initialize address for
server" messages and dead lossage -- examining the dump and cache files
(we specify one in /etc/named.boot) confused me -- it didn't seem to
read them except at boot and then they got shorter....  Anybody else
play with this?

Anyone tried replacing the Ultrix 4.7 with Berkeley's latest (is it 4.8)?

Installation of the 3-tape set on a VS2/GPX was interesting: despite
the /etc/motd proclaiming it was "Ultrix 3.0 (Rev. 64) UWS 2.0 (BL 10)"
the folks in Atlanta claimed that it couldn't be workstation software
because UWS wasn't released yet.  It seems there is a program called
/bin/btd in the standalone memory only UNIX which is supposed to return
the unit it booted from -- on an MVII this returns nothing, on my GPX
it returns tms0 -- if you are unlucky enough to get "tms0", the shell
script will neglect to honor its obligation to change tapes to the
SUPPORTED tape (2 of 3) and drive you crazy (this can be fixed by
replacing /bin/btd with a shell script that does not return a valid
device to "install.1").  Customer support claims this is because if I
really had UWS, the standalone system should appear on the same tape as
the Supported software (with the root dump).  Using the MIT X11
software with 3.0 gets a bit tough if it only works with DECWindows.

Using the 8650 as an RIS server also loses -- BIND and /etc/ris really
don't understand each other: ris strips off the domain qualifier, the
documentation tells you you must supply it, and rsh gives you
permission denied when you try to use setld, since the client name is
not qualified in ~ris/.rhosts.  This looks hack-able but bothersome.

My other problem is that mop_download seems to no longer work; DEC
claims no other 8650 server has this problem, so I am looking for the
experience of others.  My syslog get messages saying either that the
tertiary load file is too large, or that the load timed out.  This same
network was using Ultrix 2.3 happily, so I'm inclined to think the
problem lies with 3.0.  I was suprised to hear that 6 MB of core was
required on a workstation for 3.0, which is what the support folks
asked me to check first (someone apparently was unable to net boot
because of insufficient memory!?).

And have you noticed that when using the man command on a vt100, the
underlined or bolded program names (.PN macro?) seem to get eaten?
Works on xterm, so I guess the page/more filtering or termcap is
wrong somewhere (fix appreciated, as I doubt this will reach the
top of my queue anytime soon).