ADSM-L

Re: cleanup backupgroups

2002-10-14 13:54:51
Subject: Re: cleanup backupgroups
From: Steve Roder <spr AT REXX.ACSU.BUFFALO DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 14 Oct 2002 13:51:58 -0400
> Matt,
>
> you got it right - there is a problem with SystemObject expiration
> introduced in v4.2.2 and you have to run CLEANUP BACKUPGROUP to prevent
> enourmous high space usage in DB and storage pool. This applies if you
> have many W2k nodes backing up to TSM. It would last until you upgrade to
> a version without the bug. It is expected in v4.2.3 the bug to be fixed.
> So without upgrade (in far future) to v5.1.x you still can apply v4.2.3
> (or later) maintenance.

The "Cleanup" command does not exist on 4.2.2.0.  Gee, I guess if it did,
then IBM would have introduced a bug, and the fix for it, in the same
release!  I don't think the bug came in 4.2.2.0.

Tivoli Storage Manager
Command Line Administrative Interface - Version 5, Release 1, Level 5.0
(C) Copyright IBM Corporation 1990, 2002 All Rights Reserved.

Session established with server MEMNOCH: AIX-RS/6000
  Server Version 4, Release 2, Level 2.0
  Server date/time: 10/14/02   13:47:04  Last access: 10/14/02   13:00:03


tsm: MEMNOCH>CLEANUP BACKUPGROUP
ANR2000E Unknown command - CLEANUP BACKUPGROUP.
ANS8001I Return code 2.

> I think I'm reading that there's a problem in 4.2.2.x versions of TSM
> which causes SYSTEM OBJECTS not to expire, requiring the CLEANUP
> BACKUPGROUPS.  I've seen some messages that indicate the cleanup
> needs to run after conversion to 5.1.
>
> We're running TSM 4.2.2.0 on Solaris.  We hope to upgrade to 5.1
> sometime, but probably not soon.  While we're still on 4.2.2.0, do we
> need to do this cleanup regularly?  We recently had a problem with
> TSM coming to a screeching halt after our database got 100% full, and
> we're not sure why a database that was supposedly way bigger than we
> would ever need has filled up before we've even got half our backups
> on it.  Is it possible that this systems objects problem is
> contributing to our db size problem?
> --
>
>
> Matt Simpson --  OS/390 Support
> 219 McVey Hall  -- (859) 257-2900 x300
> University Of Kentucky, Lexington, KY 40506
> <mailto:msimpson AT uky DOT edu>
> mainframe --   An obsolete device still used by thousands of obsolete
> companies serving billions of obsolete customers and making huge obsolete
> profits for their obsolete shareholders.  And this year's run twice as
> fast
> as last year's.
>
>

Steve Roder, University at Buffalo
HOD Service Coordinator
VM Systems Programmer
UNIX Systems Administrator (Solaris and AIX)
TSM/ADSM Administrator
(spr AT buffalo DOT edu | (716)645-3564)

<Prev in Thread] Current Thread [Next in Thread>