we went from 5.4.1 to 5.5.0 and we had to upgrade to 5.5.1 because we encountered a bug when someone attempted a restore while reclaimation was running. So far no problems with 5.5.1 ( on aix 5.3.0.0)
Thank you, Bob Molerio --- On Tue, 8/26/08, ADSM-L automatic digest system <[EMAIL PROTECTED]> wrote: > From: ADSM-L automatic digest system <[EMAIL PROTECTED]> > Subject: ADSM-L Digest - 24 Aug 2008 to 25 Aug 2008 (#2008-212) > To: [email protected] > Date: Tuesday, August 26, 2008, 12:00 AM > There are 7 messages totalling 575 lines in this issue. > > Topics of the day: > > 1. upgrading to TSM 5.5.1 > 2. audit volume (2) > 3. Migration Process Question (2) > 4. Updated VS Backed Up > 5. RSM type Library (HP 1/8 G2 Autoloader) > > ---------------------------------------------------------------------- > > Date: Mon, 25 Aug 2008 11:13:39 -0400 > From: "Lepre, James" > <[EMAIL PROTECTED]> > Subject: Re: upgrading to TSM 5.5.1 > > Hello Everyone, > > =20 > > We are currently at TSM v5.4.1.1 and are planning on > upgrading to > v5.5.1. Can anyone let me know if there are any caveats > that I should > be aware of, or any new features that people like in this > version. =20 > > =20 > > Thank you=20 > > =20 > > James Lepre > > =20 > > =20 > > > =A0=20 > =A0=20 > --------------------------------------------------------------- > Confidentiality Notice: The information in this e-mail and > any attachments = > thereto is intended for the named recipient(s) only. This > e-mail, includin= > g any attachments, may contain information that is > privileged and confident= > ial and subject to legal restrictions and penalties > regarding its unauthor= > ized disclosure or other use. If you are not the intended > recipient, you a= > re hereby notified that any disclosure, copying, > distribution, or the takin= > g of any action or inaction in reliance on the contents of > this e-mail and = > any of its attachments is STRICTLY PROHIBITED. If you have > received this e= > -mail in error, please immediately notify the sender via > return e-mail; del= > ete this e-mail and all attachments from your e-mail > system and your compu= > ter system and network; and destroy any paper copies you > may have in your p= > ossession. Thank you for your cooperation. > > ------------------------------ > > Date: Mon, 25 Aug 2008 11:21:54 -0400 > From: David E Ehresman <[EMAIL PROTECTED]> > Subject: audit volume > > I've done an "audit volume fix=3Dyes" on a > copy pool volume and damaged fil= > es were deleted. Will a "Backup Stgpool" re-copy > them, or have they been d= > eleted from the primary pool also? > > David > > ------------------------------ > > Date: Mon, 25 Aug 2008 17:28:28 +0200 > From: "Bos, Karel" > <[EMAIL PROTECTED]> > Subject: Re: audit volume > > This is a multi-part message in MIME format. > > ------=_NextPart_000_ED6C_01C906D7.FD19EDC0 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Audit vol on a copy stg volume will not delete files on the > primary stg > volume(s). Damaged files marked as deleted will be copied > on the next > backup stg run. > > Regards/Met vriendelijke groet, > > Karel > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] > On Behalf Of > David E Ehresman > Sent: maandag 25 augustus 2008 17:22 > To: [email protected] > Subject: audit volume > > I've done an "audit volume fix=3Dyes" on a > copy pool volume and damaged > files were deleted. Will a "Backup Stgpool" > re-copy them, or have they > been deleted from the primary pool also? > > David > > > ------=_NextPart_000_ED6C_01C906D7.FD19EDC0 > Content-Type: text/plain; > name="disclaimer.txt" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; > filename="disclaimer.txt" > > //5EAGkAdAAgAGIAZQByAGkAYwBoAHQAIABpAHMAIAB2AGUAcgB0AHIAbwB1AHcAZQBsAGkAagBr > ACAAZQBuACAAawBhAG4AIABnAGUAaABlAGkAbQBlACAAaQBuAGYAbwByAG0AYQB0AGkAZQAgAGIA > ZQB2AGEAdAB0AGUAbgAgAGUAbgBrAGUAbAANAAoAYgBlAHMAdABlAG0AZAAgAHYAbwBvAHIAIABk > AGUAIABnAGUAYQBkAHIAZQBzAHMAZQBlAHIAZABlAC4AIABJAG4AZABpAGUAbgAgAGQAaQB0ACAA > YgBlAHIAaQBjAGgAdAAgAG4AaQBlAHQAIAB2AG8AbwByACAAdQAgAGkAcwAgAGIAZQBzAHQAZQBt > AGQALAANAAoAdgBlAHIAegBvAGUAawBlAG4AIAB3AGkAagAgAHUAIABkAGkAdAAgAG8AbgBtAGkA > ZABkAGUAbABsAGkAagBrACAAYQBhAG4AIABvAG4AcwAgAHQAZQAgAG0AZQBsAGQAZQBuACAAZQBu > ACAAaABlAHQAIABiAGUAcgBpAGMAaAB0ACAAdABlAA0ACgB2AGUAcgBuAGkAZQB0AGkAZwBlAG4A > LgANAAoAQQBhAG4AZwBlAHoAaQBlAG4AIABkAGUAIABpAG4AdABlAGcAcgBpAHQAZQBpAHQAIAB2 > AGEAbgAgAGgAZQB0ACAAYgBlAHIAaQBjAGgAdAAgAG4AaQBlAHQAIAB2AGUAaQBsAGkAZwAgAGcA > ZQBzAHQAZQBsAGQAIABpAHMAIABtAGkAZABkAGUAbABzAA0ACgB2AGUAcgB6AGUAbgBkAGkAbgBn > ACAAdgBpAGEAIABpAG4AdABlAHIAbgBlAHQALAAgAGsAYQBuACAAQQB0AG8AcwAgAE8AcgBpAGcA > aQBuACAAbgBpAGUAdAAgAGEAYQBuAHMAcAByAGEAawBlAGwAaQBqAGsAIAB3AG8AcgBkAGUAbgAg > AGcAZQBoAG8AdQBkAGUAbgANAAoAdgBvAG8AcgAgAGQAZQAgAGkAbgBoAG8AdQBkACAAZABhAGEA > cgB2AGEAbgAuAA0ACgBIAG8AZQB3AGUAbAAgAHcAaQBqACAAbwBuAHMAIABpAG4AcwBwAGEAbgBu > AGUAbgAgAGUAZQBuACAAdgBpAHIAdQBzAHYAcgBpAGoAIABuAGUAdAB3AGUAcgBrACAAdABlACAA > aABhAG4AdABlAHIAZQBuACwAIABnAGUAdgBlAG4ADQAKAHcAaQBqACAAZwBlAGUAbgAgAGUAbgBr > AGUAbABlACAAZwBhAHIAYQBuAHQAaQBlACAAZABhAHQAIABkAGkAdAAgAGIAZQByAGkAYwBoAHQA > IAB2AGkAcgB1AHMAdgByAGkAagAgAGkAcwAsACAAbgBvAGMAaAAgAGEAYQBuAHYAYQBhAHIAZABl > AG4AIAB3AGkAagANAAoAZQBuAGkAZwBlACAAYQBhAG4AcwBwAHIAYQBrAGUAbABpAGoAawBoAGUA > aQBkACAAdgBvAG8AcgAgAGQAZQAgAG0AbwBnAGUAbABpAGoAawBlACAAYQBhAG4AdwBlAHoAaQBn > AGgAZQBpAGQAIAB2AGEAbgAgAGUAZQBuACAAdgBpAHIAdQBzACAAaQBuACAAZABpAHQADQAKAGIA > ZQByAGkAYwBoAHQALgANAAoAoAANAAoATwBwACAAYQBsACAAbwBuAHoAZQAgAHIAZQBjAGgAdABz > AHYAZQByAGgAbwB1AGQAaQBuAGcAZQBuACwAIABhAGEAbgBiAGkAZQBkAGkAbgBnAGUAbgAgAGUA > bgAgAG8AdgBlAHIAZQBlAG4AawBvAG0AcwB0AGUAbgAgAHcAYQBhAHIAbwBuAGQAZQByAA0ACgBB > AHQAbwBzACAATwByAGkAZwBpAG4AIABnAG8AZQBkAGUAcgBlAG4AIABlAG4ALwBvAGYAIABkAGkA > ZQBuAHMAdABlAG4AIABsAGUAdgBlAHIAdAAgAHoAaQBqAG4AIABtAGUAdAAgAHUAaQB0AHMAbAB1 > AGkAdABpAG4AZwAgAHYAYQBuACAAYQBsAGwAZQANAAoAYQBuAGQAZQByAGUAIAB2AG8AbwByAHcA > YQBhAHIAZABlAG4AIABkAGUAIABMAGUAdgBlAHIAaQBuAGcAcwB2AG8AbwByAHcAYQBhAHIAZABl > AG4AIAB2AGEAbgAgAEEAdABvAHMAIABPAHIAaQBnAGkAbgAgAHYAYQBuACAAdABvAGUAcABhAHMA > cwBpAG4AZwAuAA0ACgBEAGUAegBlACAAdwBvAHIAZABlAG4AIAB1ACAAbwBwACAAYQBhAG4AdgBy > AGEAYQBnACAAZABpAHIAZQBjAHQAIABrAG8AcwB0AGUAbABvAG8AcwAgAHQAbwBlAGcAZQB6AG8A > bgBkAGUAbgAuAA0ACgCgAA0ACgBUAGgAaQBzACAAZQAtAG0AYQBpAGwAIABhAG4AZAAgAHQAaABl > ACAAZABvAGMAdQBtAGUAbgB0AHMAIABhAHQAdABhAGMAaABlAGQAIABhAHIAZQAgAGMAbwBuAGYA > aQBkAGUAbgB0AGkAYQBsACAAYQBuAGQAIABpAG4AdABlAG4AZABlAGQAIABzAG8AbABlAGwAeQAN > AAoAZgBvAHIAIAB0AGgAZQAgAGEAZABkAHIAZQBzAHMAZQBlADsAIABpAHQAIABtAGEAeQAgAGEA > bABzAG8AIABiAGUAIABwAHIAaQB2AGkAbABlAGcAZQBkAC4AIABJAGYAIAB5AG8AdQAgAHIAZQBj > AGUAaQB2AGUAIAB0AGgAaQBzACAAZQAtAG0AYQBpAGwADQAKAGkAbgAgAGUAcgByAG8AcgAsACAA > cABsAGUAYQBzAGUAIABuAG8AdABpAGYAeQAgAHQAaABlACAAcwBlAG4AZABlAHIAIABpAG0AbQBl > AGQAaQBhAHQAZQBsAHkAIABhAG4AZAAgAGQAZQBzAHQAcgBvAHkAIABpAHQALgANAAoAQQBzACAA > aQB0AHMAIABpAG4AdABlAGcAcgBpAHQAeQAgAGMAYQBuAG4AbwB0ACAAYgBlACAAcwBlAGMAdQBy > AGUAZAAgAG8AbgAgAHQAaABlACAASQBuAHQAZQByAG4AZQB0ACwAIAB0AGgAZQAgAEEAdABvAHMA > IABPAHIAaQBnAGkAbgAgAGcAcgBvAHUAcAANAAoAbABpAGEAYgBpAGwAaQB0AHkAIABjAGEAbgBu > AG8AdAAgAGIAZQAgAHQAcgBpAGcAZwBlAHIAZQBkACAAZgBvAHIAIAB0AGgAZQAgAG0AZQBzAHMA > YQBnAGUAIABjAG8AbgB0AGUAbgB0AC4AIABBAGwAdABoAG8AdQBnAGgAIAB0AGgAZQANAAoAcwBl > AG4AZABlAHIAIABlAG4AZABlAGEAdgBvAHUAcgBzACAAdABvACAAbQBhAGkAbgB0AGEAaQBuACAA > YQAgAGMAbwBtAHAAdQB0AGUAcgAgAHYAaQByAHUAcwAtAGYAcgBlAGUAIABuAGUAdAB3AG8AcgBr > ACwAIAB0AGgAZQAgAHMAZQBuAGQAZQByAA0ACgBkAG8AZQBzACAAbgBvAHQAIAB3AGEAcgByAGEA > bgB0ACAAdABoAGEAdAAgAHQAaABpAHMAIAB0AHIAYQBuAHMAbQBpAHMAcwBpAG8AbgAgAGkAcwAg > AHYAaQByAHUAcwAtAGYAcgBlAGUAIABhAG4AZAAgAHcAaQBsAGwAIABuAG8AdAAgAGIAZQANAAoA > bABpAGEAYgBsAGUAIABmAG8AcgAgAGEAbgB5ACAAZABhAG0AYQBnAGUAcwAgAHIAZQBzAHUAbAB0 > AGkAbgBnACAAZgByAG8AbQAgAGEAbgB5ACAAdgBpAHIAdQBzACAAdAByAGEAbgBzAG0AaQB0AHQA > ZQBkAC4ADQAKAKAADQAKAE8AbgAgAGEAbABsACAAbwBmAGYAZQByAHMAIABhAG4AZAAgAGEAZwBy > AGUAZQBtAGUAbgB0AHMAIAB1AG4AZABlAHIAIAB3AGgAaQBjAGgAIABBAHQAbwBzACAATwByAGkA > ZwBpAG4AIABzAHUAcABwAGwAaQBlAHMAIABnAG8AbwBkAHMAIABhAG4AZAAvAG8AcgANAAoAcwBl > AHIAdgBpAGMAZQBzACAAbwBmACAAdwBoAGEAdABlAHYAZQByACAAbgBhAHQAdQByAGUALAAgAHQA > aABlACAAVABlAHIAbQBzACAAbwBmACAARABlAGwAaQB2AGUAcgB5ACAAZgByAG8AbQAgAEEAdABv > AHMAIABPAHIAaQBnAGkAbgANAAoAZQB4AGMAbAB1AHMAaQB2AGUAbAB5ACAAYQBwAHAAbAB5AC4A > IAANAAoAVABoAGUAIABUAGUAcgBtAHMAIABvAGYAIABEAGUAbABpAHYAZQByAHkAIABzAGgAYQBs > AGwAIABiAGUAIABwAHIAbwBtAHAAdABsAHkAIABzAHUAYgBtAGkAdAB0AGUAZAAgAHQAbwAgAHkA > bwB1ACAAbwBuACAAeQBvAHUAcgAgAHIAZQBxAHUAZQBzAHQALgANAAoAoAANAAoAQQB0AG8AcwAg > AE8AcgBpAGcAaQBuACAATgBlAGQAZQByAGwAYQBuAGQAIABCAC4AVgAuACAALwAgAFUAdAByAGUA > YwBoAHQADQAKAEsAdgBLACAAVQB0AHIAZQBjAGgAdAAgADMAMAAxADMAMgA3ADYAMgA= > > ------=_NextPart_000_ED6C_01C906D7.FD19EDC0-- > > ------------------------------ > > Date: Mon, 25 Aug 2008 15:58:32 -0500 > From: "Hart, Charles A" > <[EMAIL PROTECTED]> > Subject: Migration Process Question > > We noticed today that a migration for a virtual tape pool > was migrating > to itself not the "Next Stgpoool" ? Has anoyomn > seen such a thing? > > Thanks,=20 > > Charles=20 > > > This e-mail, including attachments, may include > confidential and/or=20 > proprietary information, and may be used only by the person > or entity to=20 > which it is addressed. If the reader of this e-mail is not > the intended=20 > recipient or his or her authorized agent, the reader is > hereby notified=20 > that any dissemination, distribution or copying of this > e-mail is=20 > prohibited. If you have received this e-mail in error, > please notify the=20 > sender by replying to this message and delete this e-mail > immediately. > > ------------------------------ > > Date: Mon, 25 Aug 2008 16:10:24 -0500 > From: Dwight Cook <[EMAIL PROTECTED]> > Subject: Re: Migration Process Question > > Might I ask how you have determined it is going to itself > rather than the > "next" storage pool? (by the volume assignment > of the destination volume?) > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] > On Behalf Of > Hart, Charles A > Sent: Monday, August 25, 2008 3:59 PM > To: [email protected] > Subject: [ADSM-L] Migration Process Question > > We noticed today that a migration for a virtual tape pool > was migrating > to itself not the "Next Stgpoool" ? Has anoyomn > seen such a thing? > > Thanks, > > Charles > > > This e-mail, including attachments, may include > confidential and/or > proprietary information, and may be used only by the person > or entity to > which it is addressed. If the reader of this e-mail is not > the intended > recipient or his or her authorized agent, the reader is > hereby notified > that any dissemination, distribution or copying of this > e-mail is > prohibited. If you have received this e-mail in error, > please notify the > sender by replying to this message and delete this e-mail > immediately. > > ------------------------------ > > Date: Tue, 26 Aug 2008 00:26:09 +0200 > From: Tommy Hueber <[EMAIL PROTECTED]> > Subject: Updated VS Backed Up > > The DISABLEATTRIBUPDATE client parameter can be utilized to > force the resend > of a file of which a file system object (for example, file > permissions) were > changed. This is described here: > > > <http://tsmblog.org/serendipity/index.php?/archives/101-UPDATED-vs-BACKED-UP > -revisited-how-to-use-DISABLEATTRIBUPDATE-to-force-the-resend-of-a-changed-f > ile-on-AIX.html> > http://tsmblog.org/serendipity/index.php?/archives/101-UPDATED-vs-BACKED-UP- > revisited-how-to-use-DISABLEATTRIBUPDATE-to-force-the-resend-of-a-changed-fi > le-on-AIX.html > > An extract of the article: > > As a matter of fact, this can be done. But it is not stated > in the IBM > documentation, nor in the IBM KB. > > ----> The permissions of a file are changed: > > [EMAIL PROTECTED]:/home/tsm $ chmod 755 testfile > > ----> The file is backed up incremental with this > parameter: > > [EMAIL PROTECTED]:/home/tsm $ dsmc i -testflags=DISABLEATTRIBUPDATE > testfile > > IBM Tivoli Storage Manager > Command Line Backup/Archive Client Interface > Client Version 5, Release 4, Level 0.0 > Client date/time: 08/25/08 09:19:50 > (c) Copyright by IBM Corporation and other(s) 1990, 2007. > All Rights > Reserved. > > Node Name: FACE_TSMCL > Session established with server HANNIBAL: AIX-RS/6000 > Server Version 5, Release 4, Level 1.0 > Server date/time: 08/25/08 09:19:50 Last access: 08/25/08 > 09:18:57 > > > Incremental backup of volume 'testfile' > Successful incremental backup of > '/home/tsm/testfile' > > > Total number of objects inspected: 6 > Total number of objects backed up: 1 > Total number of objects updated: 0 > Total number of objects rebound: 0 > Total number of objects deleted: 0 > Total number of objects expired: 0 > Total number of objects failed: 0 > Total number of bytes transferred: 37 B > Data transfer time: 0.00 sec > Network data transfer rate: 76.22 KB/sec > Aggregate data transfer rate: 0.01 KB/sec > Objects compressed by: 0% > Elapsed processing time: 00:00:02 > [EMAIL PROTECTED]:/home/tsm $ > Shell will time out in 60 seconds. > ksh: Timed out waiting for input. > > The file is 'backed up' (instead of > 'updated'). By using the > -testflags=DISABLEATTRIBUPDATE parameter you're telling > the TSM client to > resend the file, instead of updating it. This is what you > want; the previous > version became INACTIVE, and the last one - with the new > permission - the > ACTIVE one. Now the behaviour it the same as a Windows > Client, which is not > too bad in this case. > > When you want this to work for all your AIX clients, you > can include the > -testflags=DISABLEATTRIBUPDATE parameter in a client option > set with > FORCE=YES, or add it as a client option to the schedule for > your clients. > > Hopefully, in a next release of the TSM Client the > -testflags=DISABLEATTRIBUPDATE parameter will become an > normal, documented > and supported parameter. It would be nice to have in > dsm.sys, for example, a > client option 'DISABLEATTRIBUPDATE YES'. > > ------------------------------ > > Date: Mon, 25 Aug 2008 15:53:07 -0700 > From: "Gill, Geoffrey L." > <[EMAIL PROTECTED]> > Subject: Re: RSM type Library (HP 1/8 G2 Autoloader) > > From what I can tell nobody responded to this but I did > manage to get it > worked out. Since I am used to using IBM devices I never > ran in to this > and since this is an HP device in order to get it to work I > needed to > change the driver to point to the TSM driver instead of it > using the > delivered HP drivers that were installed when I set up the > system. I > also had to disable the Remote Storage service.=20 > > =20 > > Once that was changed I had to remove the library TSM > initially found > when it was installed and redefine the library and drive to > TSM. I was > then able to label and checkin tapes and migrate data and > backup the db. > > =20 > > =20 > > Geoff Gill=20 > TSM Administrator=20 > PeopleSoft Sr. Systems Administrator=20 > SAIC M/S-G1b=20 > (858)826-4062 (office) > > (858)412-9883 (blackberry) > Email: [EMAIL PROTECTED] > > ________________________________ > > From: Gill, Geoffrey L.=20 > Sent: Sunday, August 24, 2008 7:05 PM > To: Gill, Geoffrey L.; 'ADSM: Dist Stor Manager' > Subject: RE: RSM type Library (HP 1/8 G2 Autoloader) > > =20 > > I know it was late Friday when I sent this so probably most > everyone was > gone and missed it. I would certainly like to hear from > anyone who might > have an idea what to look at. So far everything I have > looked at agrees > with what I implemented but I'm still looking. > > =20 > > Geoff Gill=20 > TSM Administrator=20 > PeopleSoft Sr. Systems Administrator=20 > SAIC M/S-G1b=20 > (858)826-4062 (office) > > (858)412-9883 (blackberry) > Email: [EMAIL PROTECTED] > > ________________________________ > > From: Gill, Geoffrey L.=20 > Sent: Friday, August 22, 2008 2:06 PM > To: ADSM: Dist Stor Manager > Subject: RSM type Library (HP 1/8 G2 Autoloader) > > =20 > > I have a system I just received that I am going to use for > testing. It > is running Windows 2003 Enterprise and TSM 5.5.1.0. It has > attached an > HP autoloader with an LTO3 drive in it. Seems it is > considered an RSM > Library so dealing with tapes isn't something I know > how to do yet. I > have tapes in the unit and when trying to migrate data to > them the > autoloader does seem to load tapes but it looks like almost > an immediate > unload.=20 > > =20 > > While using the mmc I can see tapes mounted, dismounted and > I have seen > message in the mmc that seem to indicate the tapes are not > labeled. > Labeling isn't something that works and I have no idea > why yet. Not sure > if that is handled automatically but a manual label and > checkin as > scratch certainly doesn't work, at least yet, and maybe > that needs > modifying or just isn't supposed to work using TSM > commands for this > type of library. > > =20 > > So far it has cycled through every tape mounting and > dismounting. TSM > commands for q dr and path show nothing and I assume it > isn't supposed > to with this type of library. Q pr during migration shows > the process > but it is waiting for a scratch tape to be mounted. > Originally when I > set things up in the MMC the tapes were in > "Unrecognized' but I moved > them to 'Free' manually. The changer in TSM under > Removable Storage also > shows the tapes mounting and dismounting. It seems to just > cycle through > the tapes over and over. > > =20 > > I'm wondering if anyone can tell me what I'm doing > wrong. So far I have > not seen much in any documentation that helps so hopefully > someone out > there can. The activity log shows mount failures but while > watching the > mmc it seems to indicate tapes are mounting. > > =20 > > =20 > > =20 > > 08/22/2008 13:43:40 ANR0985I Process 15 for MIGRATION > running in > the > > BACKGROUND completed with > completion state > FAILURE at > > 13:43:40. (PROCESS: 15) > > 08/22/2008 13:43:40 ANR1002I Migration for storage > pool DISKPOOL > will be > > retried in 60 seconds. > > 08/22/2008 13:44:40 ANR1003I Migration retry delay > ended; checking > migration > > status for storage pool DISKPOOL. > > 08/22/2008 13:44:40 ANR0984I Process 16 for MIGRATION > started in > the > > BACKGROUND at 13:44:40. (PROCESS: > 16) > > 08/22/2008 13:44:40 ANR1000I Migration process 16 > started for > storage pool > > DISKPOOL automatically, > highMig=3D0, = > lowMig=3D0, > duration=3DNo. > > (PROCESS: 16) > > 08/22/2008 13:46:42 ANR9999D_3061027814 > (mmsrsm.c:1335) Thread<41>: > Mount > > volume failed, rc =3D 30(PROCESS: > 16) > > 08/22/2008 13:46:42 ANR9999D Thread<41> issued > message 9999 from: > (PROCESS: > > 16) > > 08/22/2008 13:47:24 ANR9999D_2231172434 > (asvolmnt.c:4003) > Thread<37>: Unknown > > result code (30) from pvrOpen. > (PROCESS: 16) > > 08/22/2008 13:47:24 ANR9999D Thread<37> issued > message 9999 from: > (PROCESS: > > 16) > > 08/22/2008 13:47:24 ANR1032W Migration process 16 > terminated for > storage pool > > DISKPOOL - internal server error > detected. > (PROCESS: 16) > > 08/22/2008 13:47:24 ANR9999D Thread<36> issued > message 1032 from: > (PROCESS: > > 16) > > 08/22/2008 13:47:24 ANR0985I Process 16 for MIGRATION > running in > the > > BACKGROUND completed with > completion state > FAILURE at > > 13:47:24. (PROCESS: 16) > > 08/22/2008 13:47:24 ANR1002I Migration for storage > pool DISKPOOL > will be > > retried in 60 seconds. > > 08/22/2008 13:48:24 ANR1003I Migration retry delay > ended; checking > migration > > status for storage pool DISKPOOL. > > 08/22/2008 13:48:26 ANR0984I Process 17 for MIGRATION > started in > the > > BACKGROUND at 13:48:26. (PROCESS: > 17) > > 08/22/2008 13:48:26 ANR1000I Migration process 17 > started for > storage pool > > DISKPOOL automatically, > highMig=3D0, = > lowMig=3D0, > duration=3DNo. > > (PROCESS: 17) > > 08/22/2008 13:50:21 ANR9999D_3061027814 > (mmsrsm.c:1335) Thread<41>: > Mount > > volume failed, rc =3D 30(PROCESS: > 17) > > 08/22/2008 13:50:21 ANR9999D Thread<41> issued > message 9999 from: > (PROCESS: > > 17) > > 08/22/2008 13:51:03 ANR9999D_2231172434 > (asvolmnt.c:4003) > Thread<37>: Unknown > > result code (30) from pvrOpen. > (PROCESS: 17) > > 08/22/2008 13:51:03 ANR9999D Thread<37> issued > message 9999 from: > (PROCESS: > > 17) > > 08/22/2008 13:51:03 ANR1032W Migration process 17 > terminated for > storage pool > > DISKPOOL - internal server error > detected. > (PROCESS: 17) > > 08/22/2008 13:51:03 ANR9999D Thread<36> issued > message 1032 from: > (PROCESS: > > 17) > > 08/22/2008 13:51:03 ANR0985I Process 17 for MIGRATION > running in > the > > BACKGROUND completed with > completion state > FAILURE at > > 13:51:03. (PROCESS: 17) > > =20 > > =20 > > Geoff Gill=20 > TSM Administrator=20 > PeopleSoft Sr. Systems Administrator=20 > SAIC M/S-G1b=20 > (858)826-4062 (office) > > (858)412-9883 (blackberry) > Email: [EMAIL PROTECTED] > > =20 > > ------------------------------ > > End of ADSM-L Digest - 24 Aug 2008 to 25 Aug 2008 > (#2008-212) > *************************************************************
