ADSM-L

Re: [ADSM-L] ADSM-L Digest - 24 Aug 2008 to 25 Aug 2008 (#2008-212)

2008-08-26 09:12:51
Subject: Re: [ADSM-L] ADSM-L Digest - 24 Aug 2008 to 25 Aug 2008 (#2008-212)
From: bob molerio <molerio AT YAHOO DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 26 Aug 2008 06:11:02 -0700
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 <LISTSERV AT VM.MARIST DOT 
EDU> wrote:

> From: ADSM-L automatic digest system <LISTSERV AT VM.MARIST DOT EDU>
> Subject: ADSM-L Digest - 24 Aug 2008 to 25 Aug 2008 (#2008-212)
> To: ADSM-L AT VM.MARIST DOT EDU
> 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"
> <jlepre AT SOLIXINC DOT COM>
> 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 <deehre01 AT LOUISVILLE DOT EDU>
> 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"
> <Karel.Bos AT ATOSORIGIN DOT COM>
> 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:ADSM-L AT VM.MARIST DOT EDU]
> On Behalf Of
> David E Ehresman
> Sent: maandag 25 augustus 2008 17:22
> To: ADSM-L AT VM.MARIST DOT EDU
> 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"
> <charles_hart AT UHC DOT COM>
> 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 <cookde AT COX DOT NET>
> 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:ADSM-L AT VM.MARIST DOT EDU]
> On Behalf Of
> Hart, Charles A
> Sent: Monday, August 25, 2008 3:59 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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 <info AT TSMBLOG DOT ORG>
> 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:
>
> tsm@face:/home/tsm $ chmod 755 testfile
>
> ----> The file is backed up incremental with this
> parameter:
>
> tsm@face:/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
> tsm@face:/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."
> <GEOFFREY.L.GILL AT SAIC DOT COM>
> 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: geoffrey.l.gill AT saic DOT com=20
>
> ________________________________
>
> 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: geoffrey.l.gill AT saic DOT com=20
>
> ________________________________
>
> 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: geoffrey.l.gill AT saic DOT com=20
>
> =20
>
> ------------------------------
>
> End of ADSM-L Digest - 24 Aug 2008 to 25 Aug 2008
> (#2008-212)
> *************************************************************

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [ADSM-L] ADSM-L Digest - 24 Aug 2008 to 25 Aug 2008 (#2008-212), bob molerio <=