ADSM-L

Re: Cleanup backupgroups, system objects

2002-11-21 14:42:06
Subject: Re: Cleanup backupgroups, system objects
From: "William F. Colwell" <bcolwell AT DRAPER DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 21 Nov 2002 14:41:19 -0500
Matt - I recently did the same server upgrade and got the same
result doing cleanup backupgroups -- 0 anything deleted.

I have never been clear on the history of the problem, that is
what server levels caused it.  So I have to wonder if the cleanup
command still has a bug in it for the OS/390 server, in that it didn't
find any problems.  I am thinking of calling in a problem to IBM/tiv.

My server level history is -

4.2.1.9 (for quite a while)
4.2.2.10 (a month?)
4.2.2.12 (a month?)
4.2.3.1 (starting 11/16)

Just before going to 4.2.2.12 I suppressed all system object backups
because of severe performance problems.

Bill


At 01:41 PM 11/21/2002, you wrote:
>We assumed we had the dreaded "system objects" problem because we
>were running 4.2.2.0, we have a bunch of Windows clients, and our
>database was growing at a rate that we didn't like.
>
>So a couple of days ago, we upgraded to 4.2.3, and ran CLEANUP BACKUPGROUPS.
>It didn't seem to accomplish anything.  It finshed fairly quickly,
>compared to some of the reports I've read here, and finished with the
>message:
>
>ANR4730I CLEANUP BACKUPGROUPS evaluated 28729 groups and deleted 0
>orphan groups with  0 group
>members deleted with completion state  'FINISHED'.
>
>
>Somebody on this list suggested using the command
>QUERY OCC * "SYSTEM OBJECT"
>
>to get an idea of how bad the problem was.  I tried that, before and
>after the upgrade, and got the same result: zip
>
>tsm: UKCCSERVER1>QUERY OCC * "SYSTEM OBJECT"
>ANR2034E QUERY OCCUPANCY: No match found using this criteria.
>ANS8001I Return code 11.
>
>
>This doesn't seem to make sense to me, because if I pick a client at
>random and issue a query occ for that client, I see some system
>object filespaces.
>
>tsm: UKCCSERVER1>q occ grabthar *
>
>Node Name     Type    Filespace      FSID    Storage       Number of
>Physical      Logical
>                      Name                   Pool Name         Files
>Space        Space
>
>Occupied     Occupied
>
>(MB)         (MB)
>----------    ----    ----------    -----    ----------    ---------
>---------    ---------
>GRABTHAR      Bkup    \\grabtha-        1    BACKUPOFF-           11
>0.03         0.03
>                       r\f$                   SITE
>GRABTHAR      Bkup    \\grabtha-        1    BACKUPONS-           11
>0.03         0.03
>                       r\f$                   ITE
>GRABTHAR      Bkup    \\grabtha-        2    BACKUPOFF-      698,512
>115,597.0    115,411.1
>                       r\e$                   SITE
>8            5
>GRABTHAR      Bkup    \\grabtha-        2    BACKUPONS-      698,512
>115,987.1    115,411.1
>                       r\e$                   ITE
>8            9
>GRABTHAR      Bkup    \\grabtha-        3    BACKUPOFF-       20,558
>4,651.16     4,570.71
>                       r\c$                   SITE
>GRABTHAR      Bkup    \\grabtha-        3    BACKUPONS-       20,558
>4,642.22     4,570.71
>                       r\c$                   ITE
>GRABTHAR      Bkup    SYSTEM            4    BACKUPOFF-      106,465
>13,598.76    13,598.76
>                       OBJECT                 SITE
>GRABTHAR      Bkup    SYSTEM            4    BACKUPONS-      106,465
>13,598.76    13,598.76
>                       OBJECT                 ITE
>
>
>The pieces just don't seem to be fitting together. What am I missing?
>--
>
>
>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.

----------
Bill Colwell
C. S. Draper Lab
Cambridge Ma.

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