Hmmm... I have to question the FIX=NO part, as that will only search for inconsistencies; it won't fix them. You should clarify with the engineer who answered your question, as there might be a typo.
Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. "ADSM: Dist Stor Manager" <[email protected]> wrote on 2005-08-18 08:01:22: > > Yesterday I posted to the list about an error message that was > generating when our TSM Server came back on-line after an upgrade to > 5.2.2. Those error messages were causing other error messages > during the Expiration process and seemed to be slowing down the > Expiration process (my hope is that getting rid of these errors will > solve the slow-down problem of the Expiration process...I won't be > sure however until I get rid of the messages :~) > We opened an ETR with IBM yesterday afternoon and there was > already a response when I came in this morning. Someone expressed > interest in the solution if we found one so I will post an edited > version of IBM's response. Because our TSM Server is on an MVS/ZOS > mainframe, some things are done differently than other platforms but > the gist of it is the same. > > The error messages are the result of a corrupt entry in the TSM > Server database. The ANR9999D's callchain indicates that the TSM > server's migration thread is working to try and calculate space in > the tapepool to run a disk to tape migration. In that process, the > TSM server must access the AF.Custers table. It is in this table > that there is an orphaned entry causing the error messages to be > logged in the activity log. > > To fix the problem, you will have to remove the orphaned entry. The > way to do this is with audit of the TSM server's database. This is > an off-line process, during which the TSM server is down. > > In short run an > > AUDITDB ARCHSTORAGE FIX=NO > > Once the process is complete, restart the server normally. > > I'm scheduling time to do this today, I have a regularly scheduled > Expiration process done on Fridays? before each weekend. I will > post the results on the list?. and if it really was affecting the > Expiration process time. > > As always, > Thank You > Shannon > > > > > > > Madison Gas & Electric Co > Operations Analyst -Data Center Services > Information Management Systems > [EMAIL PROTECTED]
