I found the answer to my own question. The second file contains the
block size in some non-text oriented form which you can retreive with
chdev -a block_size=512 -l rmt0
tctl -f /dev/rmt0.1 rewind
tctl -f /dev/rmt0.1 fsf 1
dd if=/dev/rmt0.1 bs=512 count=2 of=./blkchk
strings ./blkchk | grep NONE
> Thanks. I have tested this and you are correct. Whatever size I set
> using chdev is the size used to write file 4 (rootvg). I can tell by
> setting the device to bs=256 and finding that I can only read it if it's
> set to 256 (just a bogus test size).
> But how does the mksysb know what to set the block size to during a real
> system restore - booting from tape, not using restore command ?
>>> From reading the mksysb/savevg script, I see that mksysb always writes with
>>> a block size of 512, whereas savevg uses whatever size the tape drive is
>>> currently set to.
>> *** not true. mksysb SAVES the original block size, changes to 512 to write
>> out 3 important files. The blocksize is then RESET to your default or changed
>> according to the block specification on the smit screen.
>>> How does one decide what block size to use for savevg (or for anything)?
>>> 512, 1024, 0, etc?
>>> Also I see that to read the tape with the restore command (instead of
>>> restvg), the block size must be either 0 or equal to the size that was
>>> used to write the tape. And that reading with 0 when the tape was
>>> written with non-0, is very slow. And that reading with 0, when the
>>> tape was written with 0 is ok. Would I ever want to write and read with
>>> --Chris Sites
>>> "Problems cannot be solved at the same level of awareness
>>> that created them." -Einstein
>> Norman Levin
"Problems cannot be solved at the same level of awareness
that created them." -Einstein