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:[EMAIL PROTECTED]] > >Sent: Wednesday, October 02, 2002 9:30 AM > >To: [EMAIL PROTECTED] > >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 > >* [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > > >-----Original Message----- > >From: John Naylor [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, October 02, 2002 8:53 AM > >To: [EMAIL PROTECTED] > >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 <[EMAIL PROTECTED]> on 10/02/2002 01:34:26 PM > > > >Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > > >To: [EMAIL PROTECTED] > >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: > >[EMAIL PROTECTED] > > 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. > > > > > >============================================================ >