Thanks to everyone who responded so quickly and provided helpful information:
Alan Rollow <alan_at_nabeth.cxo.dec.com>
Dr. Tom Blinn <tpb_at_zk3.dec.com>
John Deacon <jrd_at_star.ucl.ac.uk>
Rainer Landes <rlandes_at_fphws01.physik.uni-karlsruhe.de>
Robert L. McMillin <rlm_at_syseca-us.com>
My full original question is at the bottom of this summary since it is a bit
long, but my basic questions/problems were:
1) The dump command will no longer write to standard output, what can I do?
2) The rdump command isn't working to non-DecUnix systems.
The choices/solutions for 1) are:
a) Copy over the dump command from a v3.2 system and use that instead.
(This is what I did, and it works like a charm.)
b) Use the vdump command instead of dump.
(I didn't try this. I'm guessing you need to install one of the AdvFS
subsets to get the vdump command, because it wasn't on my system. Also, you
can only use vrestore, not restore, when you use vdump and I didn't like that
limitation.)
The choices/solutions for 2) are:
a) Copy over the rdump command from a v3.2 system and use that instead.
(This is what I did, and it also works like a charm.)
b) DEC has a patch for rdump which I received but haven't tried yet.
The Patch ID is OSF410-400079
=================== FULL ORIGINAL MESSAGE FOLLOWS =============================
Hello,
I recently installed DecUnix v4.0B on an Alpha that had been running v2.0, and
it seems to have broken my ability to do backups to remote systems. Backups
still work fine on my systems running OSF/1 v2.0 and DecUnix v3.2.
I use the BudTool backup product to do my site's backups, which runs on a
Solaris 2.3 system. All my other systems are backed up to this server which
has an attached jukebox. I believe BudTool runs dump in a remote shell on the
other systems and sends the output to standard output so it can trap it.
There is one line in the DecUnix v4.0B Release Notes that says: "Copying
files to stdout using the dump command is not supported in this release." No
explanation if this is a bug, was done on purpose, or what the workaround is
if you depend on it (as I do)!
I also tried manually using rdump to dump from the DecUnix v4.0B system to the
remote tape drive on my Solaris system. The following happens:
# rdump -0f cirss1:/dev/rmt/2mn /
rdump: Dumping from host intsv2
rdump: Date of this level 0 dump: Fri Jan 24 09:10:15 1997 EST
rdump: Date of last level dump: the start of the epoch
rdump: Dumping /dev/rrz0a (/) to /dev/rmt/2mn on host cirss1
rdump: Mapping (Pass I) [regular files]
rdump: Mapping (Pass II) [directories]
rdump: Remote system is not known to be compatible for magtape
functions, output being treated as regular file
rdump: Estimate: 43299 tape blocks on disk
The available blocks(14072),is less than the estimated blocks(43299)
Dump is being aborted
rdump: SIGTERM received
rdump: The ENTIRE dump is aborted
Again, this works fine on my v2.0 and v3.2 systems. The man page on rdump
says something about non-Dec remote systems need to be able to run the uname
command (Solaris can) for rdump to work, and if not, to setenv
OSF_RDUMP_SIMP_RCMD (although it doesn't say if you're supposed to set it TO
something). I tried just setting it to nothing, like the man page shows, but
that didn't make a difference.
My v4.0B system does not have a local tape drive, so I have to do backups to a
remote drive. Has anybody else ran across this and know a workaround or
solution? I called Digital support but have not heard back yet. (I am not
using AdvFS, by the way.)
Thank you.
Elaine Lolos
email: lolosep_at_cdm.com
Received on Sat Jan 25 1997 - 17:39:33 NZDT