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
