Thanks for the responses!
Original message:
>I apologize if there are some of you that feel this is inappropriate for this
>group. But with the recent mail to this list explaining no HP/Apollo discussion
>lists available, I thought I would give you a try.
>
>
>We are cursed with 2 rings of Apollo Domain/OS machines and no realistic way
>to dump their filesystems. The ideal solution would be to write to our EXA-
>8500 on one of our Sparcstations. Here are my problems/questions:
>
>1) problem: wbak appears to only work when writing to a local tape drive. If
> I could somehow pipe this data to our Sparc, that would be great
>
>2) problem: I tried to use tar (local tar command on Apollo, piped to an rsh
> command directed at the sun then executing a dd to the 8mm), but there
> are system mailbox files on the apollo that hang the tar processing when
> the process attempts to write them
>
>3) problem: bar also looks like a good utility to use since there is an X
> qualifier that allows you to target files for exclusion (those nasty
> mailbox files), but it is not available on my Domain/OS SR10.3 systems.
> question: does anyone know where there is Domain/OS compatible source
> for bar?
>
>4) problem: using NFS would be great, but, it doesn't look like NFS is
> available with Domain/OS but as a layered product that (and this I got
> according to HP Direct) is only compatible with SR10.4 (which we don't
> have and couldn't go to due to ancient software we are running on this
> ancient hardware).
>
>5) question: are there EXA-8500 device drivers available for the Apollo
> Domain/OS platform?
>
>6) question: are there any solutions/suggestions to the quandary that I am in?
>
>
>The only tape drive that we have for these Domain/OS rings are QIC drives with
>30MB capacity. Backing up 1GB of data takes alot of time and many more tapes
>than anyone would have patience to manually load. Suggestions for this problem
>would be greatly appreciated!!
I received many similar responses.
Using NFS, tar, bar and pax doesn't always work due to the loss of Apollo
specific file attributes (i.e. ACLs).
I mentioned above having problems with using the -stdout switch to the wbak
command. I can get it to work fine on my 10.3 node but not my 10.1 nodes. On
the SR10.1 nodes I cannot get anything from stdout for the wbak command.
Whether I pipe to the dd command to a local file or remote tape drive the
results are the same, 0 records in and 0 records out. Some responses lead me
to believe that it had been accomplished before, so I am not sure why this is
causing me so much grief.
Use of the -rem switch to the wbak command is great, when it works. It is
pretty flaky and not available until SR10.3.
Special thanks for sending the entire FAQ from comp.sys.apollo goes to
valdes@geosun.uchicago.edu. Here is an extract regarding 8mm and Apollos.
****
from comp.sys.apollo:
28a) Do I need to buy Omniback to use my Exabyte 8mm tape drive?
Answer:
Apollo's earlier tape utilities, including "wbak", "rbak", and "rwmt" access
the tape drive directly via calls to either the magtape driver or the
cartridge tape driver, depending on whether you use "-dev mt" (the default)
or "-dev ct". These calls are made via the unreleased "tfp_$" calls, which
then branch out to either the unreleased "mt_$" or the "ct_$" calls. All of
these library routines are in /lib/tfp. When Apollo introduced their 8mm
Exabyte drive, they wrote a new tape library to support the drive; and they
did *not* add support for the drive to the existing "tfp_$" library. Thus,
the older Apollo programs can not access Apollo's 8mm drive. Only programs
which use the new tape library can access the drive, and Omniback is the
only Apollo utility that I'm aware of which does use the new library.
The standard Unix utilities, such as "tar", "dd", "mt" and the like, all
access the tape drive via a Unix device file (eg. /dev/rmt0). As of SR10.x,
Apollo has supplied device files for SCSI tape drives attached to either the
native SCSI port of the DN2500 or the SCSI port of the multi-function WD7000
disk controller used on most DN3500 and DN4500 machines. These device files
are /dev/rmts8 and /dev/rmts12 (rewind and no-rewind) for SCSI tape device
0, and /dev/rmts9 and /dev/rmts13 (rewind and no-rewind) for SCSI tape
device 1 [note: hardware hackers, feel free to correct me! this explanation
is getting long enough to publish as an article -- I'd *hate* to get this
wrong in print!!]. These device files invoke the *new* Apollo tape library,
and therefore can access the 8mm Exabyte drive in addition to SCSI cartridge
tapes and SCSI 9-track tapes. The device files /dev/rmt8 and /dev/rmt12, on
the other hand, access the old tape library for 9-track drives; and
/dev/rct8 and /dev/rct12 access the old tape library for non-SCSI cartridge
tape drives.
Now, there *is* a way to use "wbak" and "rbak" with the 8mm Exabyte drive:
you use the "wbak -to" and "rbak -from" options to redirect I/O to a file
instead of old tape library, and you use either /dev/rmts8 or /dev/rmts12 as
the file name. There is a minor drawback to this: the ANSI labeled tape
options such as "-fid" (file ID), "-vid" (volume ID), and "-f NN" (write to
the NNth file on the tape) won't work -- you can only write an unlabled file
to the current position on the tape.
...
(etc)
...
Either way, your Apollo sales person is mis-informed. Exabyte drives *can*
be used on the Apollos under SR10 with DN2500/3500/4500 machines via the
SCSI tape device files; or under either SR9.7 or SR10 via either the magtape
library calls or the old, non-SCSI, device files with Workstation Solutions'
package on DN2500/3500/4500 with SCSI ports, or on DN3000/4000 machines with
an AT-BUS SCSI adaptor card.
-- David Krowitz <krowitz@richter.mit.edu>
****
weingart@inf.ethz.ch
richmond@atria.com
rl@uebemc.siemens.de
jonb@tiuk.ti.com
shandelm@jpmorgan.com
steenl@kentrox.com
strombrg@uci.edu
sl@os.se
Jason.Hargis@PII.COM
dal@gcm.com
valdes@geosun.uchicago.edu
S.Rezsutek@baloo.gsfc.nasa.gov
markh@analogy.com
rtaylor@ait.nrl.navy.mil
dewicki@taurus.dnet.ge.com
camm@fmlrnd.co.uk
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:19 CDT