Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!oakhill!abair
From: abair@turbinia.oakhill.uucp (Alan Bair)
Newsgroups: comp.sys.apollo
Subject: Re: Apollo won't release rbak/wbak format.  grrr.
Message-ID: <ABAIR.89Oct6183915@turbinia.oakhill.uucp>
Date: 6 Oct 89 23:39:15 GMT
References: <26979@iuvax.cs.indiana.edu> <46080999.14df5@ulsoy.engin.umich.edu>
	<27200@iuvax.cs.indiana.edu> <460bf837.14df5@ulsoy.engin.umich.edu>
	<27264@iuvax.cs.indiana.edu>
Sender: news@oakhill.UUCP
Organization: SPS CAD, Motorola Inc., Austin, Texas.
Lines: 45
In-reply-to: sahayman@iuvax.cs.indiana.edu's message of 6 Oct 89 05:43:51 GMT

I have been following this discussion and seem to remember that one
of the problems had to do with the index and wbak data being mixed
on the stdout.  Well I just finished some monthly backups from our
Apollos to Sun 8mm tape.  Remebering this problem I checked the tapes
and they are fine.  Now I need to qualify what I did.

The latest version of SR10 states in the release notes that you can
use the '-remote node:device' option to write to a remote tape device.
Well on our DN4000, SR10.1.1.2, it accepts this option, but fails the
login.  I gave up after several ideas, need to call Apollo.  Our
DN10000, SR10.1, does not even recognize this option.  So I used a PD
rmt package to write two cat-like routines to go from stdin -> remote
tape and remote tape -> stdout.

So on the 10000 I made the monthly backups as follows.
1. In a script I do a little book keeping and then invoke wbak:
	wbak //node_id -ld -pdtu -nhi -full -stdout | rmtwrt sun:/dev/rst0
2. The script is run manualy :( as follows:
	backup-script |& tee month-log
From this setup, I get the wbak data written on the Sun 8mm drive and the
wbak index in the month-log file.  To check that this worked, I reversed
the process like so:
	rmtrd sun:/dev/rst0 | rbak -index -all -stdin
Which gave me a nice index as would be expected.

Now the catch!  When I try this from the DN4000, it fails badly.  The tape
seems to end up with either the index or bad data, which may be what
the previous complaint was about.  Apparently
the wbak option -stdout does not work, again I need to call Apollo.  To
confirm this, I just tried running wbak -stdout with no piping, which I 
would expect to dump bits all over my lap, but it just said it was dumping
the files.  I have no idea where the binary data was going.  On the 10000
this did what I expected, bits in my lap.

Now you may start wondering why the tape is not messed up, so was I. 
However, I think what happens is that wbak writes its messages to stderr and
the data to stdout if the -stdout option is used.

If anyone from Apollo would like to help enlighten us further, please do so.
I'll probably give them a call next week anyway.

Alan Bair
SPS CAD
Motorola, Inc.
UUCP cs.utexas.edu!oakhill!turbinia!abair