Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!CAEN.ENGIN.UMICH.EDU!markg
From: markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida)
Newsgroups: comp.sys.apollo
Subject: Re: GETTING RID OF APOLLO
Message-ID: <4653bf071.0017b5e@caen.engin.umich.edu>
Date: 19 Oct 89 21:14:28 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 48


	We are getting ready to SHIT CAN Apollo. We have formed a committee to find
	an alternative to Apollo as soon as possible. Our main uses of Apollo are
	E-mail and some file sharing. We converted from DPSS mail to Unix mail
	a couple of months ago and we have had nothing but problems since.

Let me guess, "Unknown mailer error #<n>". The big problem is that /bin/mail
assumes it can always attach to its mailbox (i.e., its not mounted and never
locked) and plop in the msg.  And since Berkeley doesn't like to make changes to
sendmail, its likely only to get fixed by the vendor.  Since the vendor, Apollo,
doesn't use sendmail internally, they are not likely to even see the problem.
Your only recourse here is to do what we did and thats to make the modifications
to /usr/lib/sendmail,/bin/mail,/usr/ucb/mail yourselfs.  The changes are small,
yet understanding sendmail is not.  Of course we are working on (yes, I know I
said this a few months ago) a public release version of our changes.

But let me tell you.  Once it is set up correctly on the Apollos, you have 1
/usr/spool/mail directory, not N of them (where N equals the number of nodes in
your network).  And not through NFS.  If you think you have problems now, then
try setting up your spool directory through nfs and you'll see the joys of
maintaining hundreds of mounts points with these non-apollo unix workstations
you are planning to buy.  Apollos can work to your advantage if set them up
correctly.

	Apollo's solution to all of our problems is to convert to SR10. We figured
	that it would cost us in excess of 1 million dollars and we're not sure 
	that will solve our problems.

This is not the solution.  The solution is to get corrected code.  But I am
still confused over what you are implying.  Do you really want to run the same
version of the os when there is a newer one available?  Do you think that
switching vendors is going to alleviate the particular problem of being told to
run the next release of their OS.  Every vendor enhances their OS and schedules
new releases.  They vary from a few months to every year or so. This is *every*
Vendor.  Get used to it.  If you don't want to "keep up" and upgrade, then buy
all PC's or all Mac's or something that a system administrator is not needed for.
I'm also willing to bet you have software maintenance through Apollo which means
you are *paying* them to enhance your os.  Now that sounds like a waste of money
to me.


------------------------------------------------------
Mark Giuffrida
University of Michigan
markg@caen.engin.umich.edu

Naturally, these comments are strictly my own views.
------------------------------------------------------