You can find it documented in the back of the Admin. Reference.  I did an
audit before upgrading from 4.1.1.5 to 5.1.1.2 and I had to do it again on
5.1.1.6. So if you are going to do an audit, I would recommend waiting until
you are on 5.1.1.6

On Wed, 2 Oct 2002, Johnn D. Tan wrote:

> 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.
> >
> >
> >============================================================
>