ADSM-L

Re: Space reclamation runs, but tapes don't free up

2002-10-02 21:01:30
Subject: Re: Space reclamation runs, but tapes don't free up
From: "Johnn D. Tan" <jdtan AT MED.CORNELL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 2 Oct 2002 21:02:25 -0400
Paul:

What is the exact syntax for auditdb? I've seen you mention it twice
now. I'm on 4.1.3 server (migrating to 5.1.1.6 tomorrow!) and don't
see this mentioned anywhere. This is part of 4.2 and later?

johnn


My recommendations is for people to get to 4.2.2.12 or higher for those of
us on 4.2 and get the backupgroups cleaned up before attempting a 5.1.1.6
migration.  This probably includes running an auditdb before starting the
ugprade as well.

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


-----Original Message-----
From: Burton, Robert [mailto:robert.burton AT RBC DOT COM]
Sent: Wednesday, October 02, 2002 9:30 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Space reclamation runs, but tapes don't free up


There is a known problem opened with IBM on this...  We were told to upgrade
to tsm 4.2.2.4 or higher...this seemed to clean up most but not all these
problems...  If you q content on the tape it is empty, yet if you try to do
reclamation or delete it you are informed that there is still data on it....
We were told we would have to issue an auditdb to clean it up...this would
knock our production server off the air for over 27 hrs...so we opted no to
do this....

When we tried to upgrade from tsm 4.2.2.4 to tsm 5.1.0.0 we experienced the
following problem:

Item PQ64254



  APAR Identifier ...... PQ64254       Last Changed..02/09/12
  ANR9999D IMINIT.C  GROUP.MEMBERS ERROR 8 UPGRADEDB

We were informed to upgrade to 5.1.1.4 or higher and run a cleanup
backupgroups command....this also fixed nothing....

I have an additiona PMR opened with IBM on this problem and am waiting to
hear back...

thanks
Robert Burton
Enterprise Storage Network Analyst
Royal Bank of Canada
315 Front St West
Toronto, On, M5V 3A4
* 416-348-3849
* Robert.Burton AT rbc DOT com <mailto:Robert.Burton AT rbc DOT com>



-----Original Message-----
From: John Naylor [mailto:john.naylor AT SCOTTISH-SOUTHERN.CO DOT UK]
Sent: Wednesday, October 02, 2002 8:53 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Space reclamation runs, but tapes don't free up


Michael,
Why has your tape got a status of filling ?
That would be a reason why it would not return to scratch
Are all your problem tapes like that?




Michael Moore <michael_moore AT vfc DOT com> on 10/02/2002 01:34:26 PM

Please respond to "ADSM: Dist Stor Manager" <adsm-l AT vm.marist DOT edu>

To:   adsm-l AT vm.marist DOT edu
cc:    (bcc: John Naylor/HAV/SSE)
Subject:  Re: Space reclamation runs, but tapes don't free up



We are having a similar problem with our server (v4.2.2.12, on OS/390
v2.10).

Here is my problem:

The reclaim runs, and ends, but the tapes are not being updated as empty. If
I run an audit of the tape volume, it will then go to empty, and be deleted
during our next MOVEDRMEDIA command.  Here is an expamle of one tape that we
ran the audit on:



Before Audit query:
                  Volume Name: 321343
            Storage Pool Name: DEV_TAPEOS
            Device Class Name: 3590_OFFSITE_COPY
      Estimated Capacity (MB): 9,216.0
                     Pct Util: 0.0
                Volume Status: Filling
                       Access: Offsite
       Pct. Reclaimable Space: 100.0
              Scratch Volume?: Yes
              In Error State?: No
     Number of Writable Sides: 1
      Number of Times Mounted: 2
            Write Pass Number: 1
    Approx. Date Last Written: 08/01/2002 01:20:28
       Approx. Date Last Read: 08/01/2002 00:31:52
          Date Became Pending:
       Number of Write Errors: 0
        Number of Read Errors: 0
              Volume Location: TSM390
ast Update by (administrator): MOOREH
        Last Update Date/Time: 08/01/2002 01:34:34


After Audit query:
                   Volume Name: 321343
             Storage Pool Name: DEV_TAPEOS
             Device Class Name: 3590_OFFSITE_COPY
       Estimated Capacity (MB): 0.0
                      Pct Util: 0.0
                 Volume Status: Empty
                        Access: Offsite
        Pct. Reclaimable Space: 0.0
               Scratch Volume?: Yes
               In Error State?: No
      Number of Writable Sides: 1
       Number of Times Mounted: 2
             Write Pass Number: 1
     Approx. Date Last Written: 08/01/2002 01:20:28
        Approx. Date Last Read: 08/01/2002 00:31:52
           Date Became Pending:
        Number of Write Errors: 0
         Number of Read Errors: 0
               Volume Location: TSM390
Last Update by (administrator): MOOREH
         Last Update Date/Time: 09/27/2002 09:49:11


I do have an ETR open with IBM on this issue.



Michael Moore
VF Services Inc.
121 Smith Street
Greensboro,  NC  27420-1488

Voice: 336-332-4423
Fax: 336-332-4544




                      "Brazner, Bob"
                      <Bob.Brazner@JCI.        To:
ADSM-L AT VM.MARIST DOT EDU
                      COM>                     cc:
                      Sent by: "ADSM:          Subject:  Space reclamation
runs,
but tapes don't free up
                      Dist Stor
                      Manager"
                      <[email protected]
                      .EDU>


                      10/01/02 08:13 PM
                      Please respond to
                      "ADSM: Dist Stor
                      Manager"






System is TSM 4.1.2.0 on AIX 4.3.3.  I run reclamation daily on my tape
backup copy pool, but the backlog of unreclaimed tapes continues to grow (as
determined by SQL select looking for volumes in the pool that meet my
reclamation threshold - 60%).  The space reclamation process mounts a number
of tapes, and a good number of bytes get moved, but the count continues to
grow.  My onsite tape backup pool does not suffer from this problem.  I'm
not seeing the number of ANR1341I messages (Scratch volume <volume name> has
been deleted from storage pool <storage pool name>) that I would expect.
Nor, am I seeing the expected number of ANR1342I messages (Scratch volume
<volume name> is now pending - volume will be deleted from storage pool
<storage pool name> after the reuse delay period for this storage pool has
elapsed).  I should be seeing one or both messages for each offsite volume
reclaimed, right?  Because my offsite tapes are not getting reclaimed in a
timely fashion, I'm faced with a lack of scratch tapes every day.  Any ideas
anyone?

Bob Brazner
Johnson Controls, Inc.
(414) 524-2570








**********************************************************************
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern Energy
plc. It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it, is prohibited and may be unlawful. Any unauthorised
recipient should advise the sender immediately of the error in transmission.

Scottish Hydro-Electric, Southern Electric, SWALEC and S+S
are trading names of the Scottish and Southern Energy Group.
**********************************************************************

------------------------------------------------------------
This e-mail may be privileged and/or confidential, and the sender does not
waive any related rights and obligations. Any distribution, use or copying
of this e-mail or the information it contains by other than an intended
recipient is unauthorized. If you received this e-mail in error, please
advise me (by return e-mail or otherwise) immediately.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux
droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou
copie de ce message ou des renseignements qu'il contient par une personne
autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez
ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de
courriel ou par un autre moyen.


============================================================