Quote:
# uname -a
OSF1 sigbrrd V5.1 2650 alpha
#
# mt -f /dev/tape/tape0 rewind
#
# tar cvf /dev/tape/tape0 *032006*
a 01032006Tarjeta.dat.Z 2 Blocks
a 01032006aamcc.dat.Z 14 Blocks
a 01032006aamcg.dat.Z 19 Blocks
a 01032006aamcu.dat.Z 17 Blocks
a 01032006acmbc.dat.Z 91 Blocks
a 01032006ahmbc.dat.Z 1 Blocks
The rest deleted...
# mt -f /dev/tape/tape0 rewind
#
# tar tvf /dev/tape/tape0
blocksize = 256
-rw-r--r-- 202/0 977 Mar 3 06:37:57 2006 01032006Tarjeta.dat.Z
-rw-r--r-- 202/0 7088 Mar 2 05:48:20 2006 01032006aamcc.dat.Z
-rw-r--r-- 202/0 9393 Mar 2 02:02:55 2006 01032006aamcg.dat.Z
#
The main problem you have is that your tar program seems to have malfunctioned. 01032006aamcg.dat.Z has 9393 bytes but was recorded in 19 tape blocks. That means it had to use a blocksize of 512 writing 18 full blocks followed by one partial block. When tar reads a tape, it is supposed to figure out the blocksize. Your tar figured wrong. It picked 256 as it reported. I suspect that to be the problem. I don't understand how that choice is even possible. Blocksize is a multiple of 512. It has picked a blocking factor of one half or something like that.
Try specifying a blocking factor. 20 is considered a very safe choice.
tar cvbf 20 /dev/tape/tape0 *032006*
tar tvbf 20 /dev/tape/tape0
Since you are backing up .Z files, hardware compression won't buy you much. But you seem to think you're using hardware compression. A quick reading of the tru64 man pages suggests that you are not. /dev/tape/tape0c would be specifying compression. I got lost on the tru64 device naming docs and I can't test anything. You may or may not have other device naming troubles... I'm not sure.