Hi Walt.
The object id you're talking about is built from the values in the database tables. Changing the tables changes the object id (and by extension, the load ID).
In terms of 'utilities', I usually custom-build scripts (or sometimes I modify existing ones) for a particular purpose. Those scripts use the IBM ars* programs as much as possible to keep your system in a state that IBM will support -- but I collect information from DB2, TSM, and the filesystem to get the job done safely, quickly, and entirely automatically.
In this situation, I'd use arsadmin retrieve and arsadmin store to pick the items up, and put them into newly configured and defined TSM nodes. The database changes are made with SQL statements for speed, but can also be done with arsdoc for full logging.
There are a few opportunities to consider when making this move, because it's a major one:
- Giving each AG it's own node gives you very fine-grained control over retention without the hassle of implementing Records Manager.
- If you have a large system, this may present an opportunity to offload the TSM component to another system, like the purpose-built IBM DR550.
- If your system is more than a few years old, and you have data that isn't compressed with OD77, you could save a substantial amount of storage space by re-compressing your data.
- Since you're shuffling all this data around, it might be a good opportunity to improve performance by reviewing your retrieval patterns, and 'backfilling' your cache filesystem for Folders that hit TSM a lot.
Good luck!
