Hi there.
The first priority in dealing with a data-loss situation is to understand exactly how and why data was misplaced -- then resolve that issue. Hopefully you're past that stage. If you're not, help reduce the impact of the situation by preventing cache expiration by NOT running arsmaint with the -c and -m options.
Unfortunately, there's no direct analogy to 'Load ID' in TSM. Inside the TSM database, Application Groups are represented by 'Application Group ID Names', which aren't available in the Load ID. Additionally, while you're given the 'base' of the object name in the Load ID, you can't be sure how many objects CMOD split the load into, nor their names.
It is possible to get a list of contents from the TSM volumes by using the 'query content' command, but then you're up against the unenviable task of trying to reconcile that information against the contents of your DB2 database.
For folks in situations similar to yours, I recommend a CMOD Data Audit. I have some utilities that completely automate the detection (and in some cases, repair) of inconsistent archives, both for historical data loss, and as a preventative measure to ensure that inconsistencies don't re-occur.
