> > UNDOCUMENTED OPTIONS FOR EXPIRE INVENTORY: > There are two undocumented/unsupported options for EXPIRE INV; > BEGINNODEID and ENDNODEID. > > These accept the decimal node number of a node and can be used to > expire a specific node's filespaces, or a specific range. > > > > WHY WOULD YOU EVER WANT TO USE THESE? > EXPIRE INV won't check for filespace lock before parsing a filespace. >
We are currently using the CLEANUP EXPTABLE cmd with the BEGINNODEID/ENDNODEID options . . . . . . UNDER THE DIRECTION OF TSM SUPPORT. We are on TSM V5.3.2. Back when we were V5.1 (last year), we were getting ANR9999 messages that prevented us from deleted old nodes out of TSM. We did bunches of stuff with support, but the fix was to move to v5.3. This we were planning, and did. As part of migrating to v5.3 we ran the cleanup procedure for Win system objects. After upgrading we still couldn't delete the nodes out of TSM. The solution was to run the CLEANUP EXPTABLE command. We did this on our test system for each of our production databases. Once started, this command cannot be stopped without halting the TSM server. Running it against a production DB on our test server ran well over 2 weeks for one TSM server, and just about 2 weeks for our other TSM server. After running, we were able to delete the nodes. Ok, now we are told by the support center to run it on production. Remember . . . . you cannot run expiration while this is running. We told them we could not go without expiration for that long, and we can't just halt our TSM server at anytime to stop it!!!!!! The answer was to get the NODEID's for all the nodes and run CLEANUP EXPTABLE for one node at a time using the BEGINNODEID/ENDNODEID. We tried this on one node . . . it worked, but we have well over 500 nodes on each TSM server. I've writtes a script that automatically works through a file of nodeid's. After each node is cleaned up, it runs expiration for some amount of time. The longer the cleanup runs, the longer expiration runs. I run this script Monday thru Friday, cleaning up one node at a time with some normal expiration between each cleanup. On the weekend I put our normal expiration processing back in place to get a couple good full expiration runs. It took several months to work through the first TSM server. If I understand the output of the command, it fixed almost 15 million errors on this TSM server. The 2nd TSM server has been going through this process since Feb 1st is finally getting close to finishing - it's processed 509 out of 526 nodes. Anyway, this is one reason to use these options. If anyone has a similar problem, I would be happy to send them this script (ksh). It's highly specific to our environment, but could be adapted easily. rick ----------------------------------------- The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
