Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!sdd.hp.com!samsung!munnari.oz.au!bruce!trlluna!m25!andrews
From: andrews@afflatus.trl.OZ.AU (Murray Andrews)
Newsgroups: comp.sys.apollo
Subject: Re: Is my SR 10.2 tape hosed?
Message-ID: <1789@trlluna.trl.oz>
Date: 13 Jun 90 00:43:26 GMT
References: <1990May31.202114.18004@groucho>
Sender: root@trlluna.trl.oz
Reply-To: andrews@afflatus.trl.oz.au
Organization: Telecom Research Labs, Melbourne Australia
Lines: 71

In article <1990May31.202114.18004@groucho>, simon@groucho (Mike Simon) writes:
> Fellow Apollo admin persons:
> 
> 	I'm trying to install SR 10.2 on a DN3500 for
> the first time (both it and myself are virgins
> at this point.)  All goes well through system testing
> and so forth until ....
	...
> 
>   **Stops with the following error message:
> 		**UID in block header does not match
> 		  those read from earlier blocks....
> 
> My question is: Should I consider this to be a tape 
> error, or should I look for some basic error that I
> am introducing in the installation process?

We have seen this problem on most (but not all) of the stuff Apollo have
sent us for 10.2 installation.  It didn't happen on the OS installation
but has happened on everything we have received since (including DSEE,
Framemaker, patch tapes).  Suspecting the tape drive or the 10.2 version
of rbak we tried to read it on the following machine/OS combinations and
all failed:

	DN570 + SR10.1
	DN3000 + SR10.1
	DN3000 + SR10.2
	DN10000 + SR10.1.p

Apollo made another copy of the tapes for us and (not bothering to test
them first) sent them to us.  We wasted more time trying to read these
but they were just as faulty as the first batch.  This process happened
a couple of times.  The fact that most of the tapes were sent out
untested when there was a known problem was particularly irritating.
Apollo wasted our time unnecessarily.  The whole process has dragged out
over a period of months and we are pretty sick of it.

Finally we managed to get them to send us the tapes they were copying
from and these loaded fine.  I assume these were their orignal
distribution tapes.  It seems whatever they are using to copy the tapes
is broken.  We can copy tapes with no problem.

We still can't get Apollo to supply us with some of the things we have
paid for and constantly have to chase them to get the latest versions
of software.  In particular they have proved unable to supply us with
10.2.p, NFS version 2.1 (for SR10.2) and Domain X.25 version 2.3. God
knows when we will get these and if we will be able to read the tapes
when we do :-(

I also found the problems people were having with their Omniback/exabyte
stuff amusing.  I wish we had such problems.  We tried to buy one for a
DN10000 many months ago.  Apollo assured us they could supply one and an
order was placed.  Months went by with no word from Apollo.  After many
phone calls from us trying to find out what was going on and being
promised that it would be delivered on a particular date etc etc still
no tape unit.  Eventually we discovered that the thing hadn't left the
US yet and we could get no definite information on what the hold up was
and when it would ship.  The order was then cancelled.  We now use an
exabyte attached to a SUN and `wbak -stdout | rsh ...  dd'.  We can
actually buy a SPARC 1+ and an exabyte for about the same money Apollo
wanted for the tape unit alone.

> I'll be working with HP/Apollo techs directly on this,

Good luck.

Murray Andrews	(andrews@afflatus.trl.oz.au)
Principal Engineer
Telecom Australia Research Labs.

*My opinions are my own and not necessarily those of Telecom Australia*