I finished testing the fix on the 18th, and finally found out the APAR
number today, hence the post made now.  This one isn't publicly
available yet, so I can't read the actual text of the APAR, but here's
the only explanation I was given so far - "they found a bug in how we
generate entries into the active data pool when an aggregate contains
both active and inactive objects".  The result is that a PIT backupset
fails in a cloud of of 9999s. - 
 
ANR0985I Process 686 for GENERATE BACKUPSET running in the FOREGROUND
completed with completion state FAILURE at 11:48:58.
ANR2032E GENERATE BACKUPSET: Command failed - internal server error
detected.
ANR9999D ThreadId <49> issued message 2032 from:
ANR9999D ThreadId <49>  0x00000001000255cc outRptf
ANR9999D ThreadId <49>  0x0000000100852c58 AdmGenerateBkSet
ANR9999D ThreadId <49>  0x000000010015b224 AdmCommandLocal
ANR9999D ThreadId <49>  0x000000010015c080 admCommand
ANR9999D ThreadId <49>  0x00000001006e2c78 SmAdminCommandThread
ANR9999D ThreadId <49>  0x000000010000fe5c StartThread
ANR9999D ThreadId <49>  0x09000000002ed448 _pthread_body
ANS8001I Return code 4.
 

Anyway, until a build comes out that has APAR IC58173 in the fixed list,
if you get a result like the above, you can get your backupset made by
making activedata unavailable for the duration of the backupset
generation.  Pretty ironic since one of the reasons I often see given
for having activedata is backupset generation.
 
 
73,
 
Tim Conway
sysadmin, TSM admin
Swift & Company
9705067998