>DELAYING DUMPS IF NEEDED, total_size 46743613, tape length 35840000 mark 1931 > delay: Dump too big for tape: ... > delay: Total size now 35786141.
So planner did the right thing, reducing the total estimated dump size down below your tape size. >Does this give any idea why it hits EOT? Nope. Now you'll have to go through the rest of the amdump.1 file and find out which file system lied and dumped a lot more than the estimate said it would. Look at the GENERATING SCHEDULE section. The number after the first datestamp (the one with colons, e.g. 1970:1:1:0:0:0) is the estimated size. Then look for the "from taper: DONE" lines and the "kb NNNN" value. Here's an example: DUMP HHH AAA 20020401 1 0 1970:1:1:0:0:0 11772 11 DUMP HHH BBB 20020401 1 0 1970:1:1:0:0:0 1092 5 This say disk AAA on host HHH is expected to need 11772 KBytes and disk BBB is expected to need 1092 KBytes. Later ... driver: result time 11.986 from taper: DONE ... kb 1120 ... driver: result time 32.317 from taper: DONE ... kb 11776 ... Pretty close (1120 vs. 1092 and 11776 vs. 11772). The taper lines include some rounding to 32 KByte boundaries and I think the header is in one of these but not the other. >Dick John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
