Thanks for the help! Adding the Wait=Yes paremeter seems to have made a difference.
Holly L. Peppers Blue Cross Blue Shield of Fl 904-905-8481 Technical Services -----Original Message----- From: Andrew Raibeck [mailto:[EMAIL PROTECTED]] Sent: Friday, October 05, 2001 1:53 PM To: [EMAIL PROTECTED] Subject: Re: Expiration Problems Have you checked the activity log to see if the commands are really failing? Most likely the schedule definition for the EXPIRE INVENTORY doesn't include the WAIT=YES parameter, in which case the command is issued, and the scheduled event ends while the process runs in the background. If you want the event to wait for inventory expiration to comlete, change the schedule to include the WAIT=YES parameter. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS 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. "Peppers, Holly" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 10/05/2001 10:15 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: Expiration Problems see not below... Holly L. Peppers Blue Cross Blue Shield of Fl 904-905-8481 Technical Services -----Original Message----- From: Peppers, Holly Sent: Friday, October 05, 2001 10:37 AM To: '[EMAIL PROTECTED]' Subject: RE: Backupsets Hi, May I ask what problems you were having with your expire inventory please? I recently have discovered (for whatever reason) that my administrative schedules for expire inventory have not been working. When I execute 'q ev expiration type=admin f=d', tsm comes back and gives me a status completion of success, but the execution time is less than one minute. When I execute 'expire inventory' manually from the command line, the job runs continually for several hours. Does this sound anything like the problem you were having? Has anyone seen this before? Any ideas?? Holly L. Peppers Blue Cross Blue Shield of Fl 904-905-8481 Technical Services -----Original Message----- From: Pothula S Paparao [mailto:[EMAIL PROTECTED]] Sent: Friday, October 05, 2001 3:57 AM To: [EMAIL PROTECTED] Subject: Re: Backupsets Importance: High Hi floks, Why i wanted to know more about backupset ? Our setup : AIX4.3.3 , TSM 4.1.4.2 , 3575 Auto library. Recently i had a problem with Expire inventory . contacted IBM support (one to many). They suggested to apply fix 4.1.4.2, I have done it. Still expiration problem persists. One fine day my TSM server crashed. I tried to up the server and It never listen to me. Finally , i had to restore most recent backup. But, TSM keep crashing every day at mid night. I asked IBM support to escalate this problem (expiration and corrupted DB pages) to L2/L3, It took weeks time. They suggested me to AUDIT DB with fix=yes. nope. they again come up with UNLOADDB/LOADFORMAT/LOADDB.......after few days....... They asked me to EXPORT/IMPORT all nodes . Even this didnot worked out. After all this, they said its a known bug and asked us to find good copy of DB (which we dont have) or rebuild TSM from scratch. Yes, we have dicided to rebuild from scratch. (no other option) so *SMers, I would like to know more about backupset. i know little about it. can i create a backupset for each node and check out those tapes outside. rebuild TSM from scratch with leftover tapes. Later, check in those tapes having backup sets and make use of them with newly built TSM server. This way i may not loose much data except API related DB2 backups. Guys!!!!!!!! As im not clear on this option , i request you to give me more detailed information about this. Your reply in this regard is highly appriciated. Thanks in advance. Regards Sreekumar. Blue Cross Blue Shield of Florida, Inc., and its subsidiary and affiliate companies are not responsible for errors or omissions in this e-mail message. Any personal comments made in this e-mail do not reflect the views of Blue Cross Blue Shield of Florida, Inc. Blue Cross Blue Shield of Florida, Inc., and its subsidiary and affiliate companies are not responsible for errors or omissions in this e-mail message. Any personal comments made in this e-mail do not reflect the views of Blue Cross Blue Shield of Florida, Inc.
