It was noted earlier that ADSM API backups do not normally sense
the size of the object they are backing up.

Actually, the dsmSendObj() call in the API _requires_ the caller to
send an estimate of the size of the object in a structure called the
ObjAttr.  The parameter description states "It is important that you
try to be as accurate as possible on this size, because the ADSM
server used this attribute for efficient space allocation and object
placement within its storage resources".  Therefore, if a poor
estimate is sent by the client, it is the clients fault.  The server will
do what it can do, but only when good data is presented.

Have you tried setting the MAXSIZE parameter on your 6.4GB
disk pool?  Set it to 3 or 4 Gb.  I don't know if this will help; it's
just an experiment.

Based on what you're seeing, and the fact that the other workaround
mentioned earlier today was to turn off caching on the pool, it looks
like the connect agent either isn't sending this size estimate, or
the server didn't detect that there isn't enough room in the disk
pool and it should start this object immediately to tape.  In either
case it seem an APAR is in order.

john