> Sorry Hans if I was unclear, but for you that haven't upgraded to version > 4.2, this problem doesn't exist. > > The system object bug was first introduced with version 4.2.2.0. For > thoose of you using a lower version, my suggestion is to not upgrade to > version 4.2.2, as you will also get this bug.
It sure would be nice if someone from IBM could step in here and say definitively what level this bug was introduced. Andy? I am running 4.2.2.0, and do not see evidence of this problem. I know this because I added the following to my Windows cloptset: include.systemobject ALL 2versions and all my SYSTEM OBJECT filepsaces got rebound, and the verisons greater than 2 removed, as demonstrated by: show version nodename "SYSTEM*" namet=uni -tabdelimited -outfile > node.ver and then looking at node.ver for evidence. > > Regarding 4.2.3, i'm uncertain if this bug will be solved. I know that > development and support has been talking about implementing the bug > solution in version 4.2.3. I also know that they are making some > adjustments to the cleanup backupgroups command, so that it will run as a > normal process, and also fix some minor bugs with the command. > > Also, as far as I know, this problem is only related to environments using > Windows 2000. If you don't have any W2K servers in your environment, you > shouldn't be affected by this bug. > > Sorry if I was unclear about this. > > Best Regards > > Daniel Sparman > ----------------------------------- > Daniel Sparrman > Exist i Stockholm AB > Propellervägen 6B > 183 62 HÄGERNÄS > Växel: 08 - 754 98 00 > Mobil: 070 - 399 27 51 > > > > > Hans Hedlund <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 2002-10-14 16:05 > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject: Re: cleanup... (was: upgrade from TSM 4.1.3 to TSM 5.1.5) > > > Just to add to the total confusion, you can (will?) experience the same > (similar?) problem in a 4.2.2.x server which I don't see properly > clearified > on ADSM-L. Everyone's talking about this appearing when trying to upgrade > to > 5.1.x, but I have the problem in a plain 4.2.2 environment too: SYSTEM > OBJECTS not expiring properly, and CLEANUP BACKUPGROUP returning strange > error messages. > > The fix for 4.2.x should be in 4.2.3 which according to Tivoli support > should appear any time now. At least I hope so since I don't want to > upgrade > to 5.1 - yet. > > -Hans > > -----Original Message----- > From: Daniel Sparrman [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 14, 2002 12:48 PM > To: [EMAIL PROTECTED] > Subject: Re: upgrade from TSM 4.1.3 to TSM 5.1.5 > > > Hi > > The cleanup backupgroups is intended for one reason only, to fix a bug in > prior versions. In version 4.2.2.X, there was a bug that had the effect > that system objects wasn't expired. What happens is that when you upgrade > from version 4.2.2.X to version 5.1, the installation will be unable to > convert the 4.2.2.X database to version 5.1 format. > > When upgrading, the installation will go well. However, after the DB > upgrade, it will tell you to either run a db audit, or run the cleanup > backgroups. The cleanup backupgroups can run with TSM online, which is not > > possible with an audit. The only thing it will do, is to manually deleted > expired system objects from the database. > > Also, you will not see it running as a process. You will only see that the > > database utilization, and the used pages, will go down. When cleanup > backupgroups has completed, it will leave a message in your activity log. > > I have done this a couple of times, and it isn't a problem. As long as you > > know that you have to run cleanup backupgroups, upgrading to TSM 5.1, wont > > be a problem. Also, after the db upgrade, you will be able to start the > server. Also, it will function correctly, even if you haven't run cleanup > backupgroups. BUT, it is highly recommended that you run the cleanup > command, as the expired system objects will take up both DB space, and > storage space, which is unnecessary. > > The cleanup command will run for a longer period, depending on the size of > > your database, the amount of W2K clients in your environment, and > depending on how long you have been running backups with version 4.2.2.X. > > !!! AS FAR AS I KNOW, THIS PROBLEM IS ONLY RELATED TO VERSION 4.2.2.x OF > TSM, AND NOT 4.1.3.X. > > Best Regards > > Daniel Sparrman > ----------------------------------- > Daniel Sparrman > Exist i Stockholm AB > Propellervägen 6B > 183 62 HÄGERNÄS > Växel: 08 - 754 98 00 > Mobil: 070 - 399 27 51 > > > > > "[EMAIL PROTECTED]" <kurt.beyers > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 2002-10-14 11:23 > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject: Re: upgrade from TSM 4.1.3 to TSM 5.1.5 > > > >I'm not too sure about the whole cleanup backupgroups myself. I > >understand that Tivoli has re-done the way the database handles > >Windows SYSTEM OBJECTS. So if you don't delete them, then the CLEANUP > >BACKUPGROUPS, as I understand, cleans that up for you > > Is this change in system object storage somewhere discussed. I don't find > anything about it anywhere (except in the ADSM discussion group). > > So either you delete the system objects prior to the upgrade (with the > risk that you don't have a backup of the system objects till the next > backup of the clients) or either you use the 'cleanup backupgroup' after > the upgrade so that the system objects backed up in TSM 4.x can be > restored in TSM 5.x. Or thus the 'cleanup backupgroups' just deletes the > system objects as well? And in that case, why don't ITMS tells you to > delete the system objects prior to the upgrade? > > Kurt > > Is this > > *********************************************************** > Confidentiality Notice > > The content of this e-mail is intended only for the > confidential use of the person(s) to whom it is addressed. > If the reader of this message is not such a person, you are > hereby notified that you have received this communication > in error and that reading it, copying it, or in any way > disseminating its content to any other person, is strictly > prohibited. If you have received this message in error, > please notify the author by replying to this e-mail > immediately. > > =========================================================== > > Steve Roder, University at Buffalo HOD Service Coordinator VM Systems Programmer UNIX Systems Administrator (Solaris and AIX) TSM/ADSM Administrator ([EMAIL PROTECTED] | (716)645-3564)
