[Sorry to keep replying to my own posts, but things keep occurring to me 
after I've sent the last one! :-]

> But I'm puzzled as to why, after 15+ hours of working on the 
> same DLE, the dump hasn't timed out??

These are the Amanda processes on the client side of a second DLE that 
gives the same illusion of hanging forever:

     UID   PID  PPID  C    STIME TTY       TIME COMMAND
  amanda  3520     1  0 00:36:45 ?         0:02 
/opt/amanda/libexec/sendbackup
  amanda  3526  3525  0 00:36:48 ?         0:00 sh -c /opt/gnu/bin/tar 
-tf - 2>/dev/null | sed -e 's/^\.//'
  amanda  3525  3520  0 00:36:48 ?         3:45 
/opt/amanda/libexec/sendbackup
  amanda  3528  3526  0 00:36:48 ?         0:01 sed -e s/^\.//
  amanda  3527  3526  0 00:36:48 ?         0:38 /opt/gnu/bin/tar -tf -

The fact that it's doing a 'tar -tf -', though, in conjunction with the 
errors from amstatus when I finally killed it, indicated that it was 
still in the estimate stage:

FAILURE AND STRANGE DUMP SUMMARY:
  s3sme      /var/opt/ignite/recovery RESULTS MISSING
  s3sme      /var/opt/patch/master_11X_patches/PHSS_^2 RESULTS MISSING
  s3sme      /var/opt/patch/master_11X_patches/PHSS_25-29 RESULTS 
MISSING
  s3sme      /var/opt/patch/master_10X_patches/PHSS RESULTS MISSING

So it hadn't even _gotten_ to the point of dumping these DLEs.  *sigh*  
But still, the 10,800-second etimeout was supposed to have been in 
effect, and it had long lapsed.

Does anyone have any idea why _this_ timeout didn't take effect, either?

Thanks!
-- Mark