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