From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Subject: re: Non-Interactive dump for RISC Ultrix 4.2 [it is]
Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Organization: Digital Equipment Corporation
Date: Mon, 14 Sep 1992 19:39:05 GMT


In article <GEORGE.92Sep14023506@tusk.med.harvard.edu>, george@tusk.med.harvard.edu (George Planansky) writes:
>
>The Ultrix 4.2 dump paramater "B", it turns out, refers
>to the capacity in 1024 byte blocks of the dump tape.  Seems
>redundant to me.

The manual page entry for 'B' reads:

"Indicates that the next argument is a number that specifies the
 size, in 1024-byte blocks, of a storage medium, such as a
 diskette or removable disk cartridge."

Note the "diskette or removable disk cartridge".  I'd guess that
when dump(8) sees the 'B' option it begins believing the output
media is disk instead of tape.  Disk can after call have a fixed
number of 1 KB blocks.  On tapes the number 1 KB blocks can change
because of records skipped due to errors and such.

>This is NOT to be confused with the Sun's SunOS and SGI's IRIX dumps' 
>"b" parameter, which refers to a blocking factor.  (Why doesn't the
>Ultrix dump have this?)

Because little active improvement has been made on dump(8) over the
last few years.  Aside for support for new tape drivers, loader support
and the TA90, etc, there hasn't been much new.  I don't know WHY little
improvement has been made, but must assume it's because the people that
schedule engineering's time don't believe it needs to be updated.  This
has been a classic problem of ours and I'm not sure how to fix it.  Maybe
a concerted SPR or letter writting campaign to corporate executives...

Oh, the last time I looked the 'b' option for a blocking factor was
present in dump(8).  It just isn't documented.  The problem is that
there isn't corresponding support in restore.

>
>And why does the Ultrix dump ask me to mount a disk, when it computes
>that it has run out of tape?

As noted before, because it believes it is writting to disk instead
of tape.  Don't use the 'B' option on tapes. 
>
>The following (from Mountain Computer's exabyte manual) seems to work:
>
>   dump 0usdBf 346 4137733 2097152 /dev/nrmt1h /usr

It is always worth noting that ULTRIX dump(8) will use all of the
available and accessible tape (*).  For supported tapes, it should
have (but sometimes doesn't) reasonable parameters for estimating
the amount of tape needed.  Please recognize the estimates as just
that, ESTIMATES.  If the parameters are wrong, then the estimates
will be wrong.  It will still use all the tape.

However, if you specify other parameters to use as estimates, it
will trust you and work on the assumption that your estimate is
correct.  If you provide bad information, then you may end up
telling it to use only part of a tape.

>--
>George Planansky
>Department of Biological Chemistry & Molecular Pharmacology
>Harvard University Medical School, 240 Longwood Ave., Boston, MA 02115
>email: gplanansky@tusk.med.harvard.edu
>phone: (617) 432-3919
>fax:   (617) 432-4360
>
--
Alan Rollow				alan@nabeth.cxo.dec.com

Xref: sparky comp.sys.dec:4889 vmsnet.misc:807