Migrating to VADP with vAPP services groups

[Gee, Norman]

I have setup a new proxy server with TSM 6.2.2.  Custom install with
VMware support.  The VMware placed a number of VMs into vAPP services
group.

I can backup these VMs with my older VCB configuration, but the TSM
6.2.2 configuration cannot find these VMs.

Does VADP support vAPP pools of VMs?

Re: ADSM-L Digest - 28 Aug 2011 to 30 Aug 2011 (#2011-209)

[Stout, Susie (NIH/CIT) [E]]

Hi Charles, 

You are right, ALMS is required for LTO5 drives but not enhanced node cards; 
see 
http://www-01.ibm.com/common/ssi/rep_ca/1/877/ENUSZG10-0101/ENUSZG10-0101.PDF  
under 'TS3500 Features and Functions'.  You only need enhanced node cards to go 
to higher firmware levels.  We are positioning ourselves for LTO5 drives 
(currently have 10 LTO4's in an IBM 3584 lib) and have already learned some 
hard lessons.  

We turned on ALMS, then took the lib from 7420 code to 8430 (the highest level 
without enhanced node cards) and also took the LTO4 drive code to the most 
current level in that order, in one outage.  Enormous mistake, we're still 
battling a crippled library (it has somehow 'lost' at least 35 volumes 
inside...may still be a hardware issue, we've been having lots of robot/gripper 
problems; also if I go to any higher lib firmware, it loses all the drives, so 
I keep one drive at an ancient code level until this is resolved).

What we should probably have done was to boost the lib firmware to 7422 and 
take a brief outage for that, then apply ALMS and let it settle in for a few 
days (as you know ALMS switches the lib from 'slot-centric' to 'cart-centric'); 
you can run 7422 and ALMS fine...then later upgrade the drive and lib firmware. 
 FWIW, I'm told 8400 lib code is troublesome, 8430 is a better level.  If you 
look at the firmware levels in Fix Central, you will see 3 categories:   
firmware for machines with ALMS and enhanced node cards, machines with ALMS and 
standard node cards, and machines without ALMS; 8430 is as far as we can go 
without enhanced node cards.  

I think we erred in turning on ALMS before the code update and not giving it 
time to settle in; the result was a 2-day outage and a really screwed up 
library that pretty much works but not well AND now we can't seem to go to any 
higher code level without losing access to all (but one) of the drives.  

Hope that helps,
Susie



-Original Message-
From: ADSM-L automatic digest system [mailto:lists...@vm.marist.edu] 
Sent: Wednesday, August 31, 2011 12:03 AM
To: ADSM-L@VM.MARIST.EDU
Subject: ADSM-L Digest - 28 Aug 2011 to 30 Aug 2011 (#2011-209)

There is 1 message totalling 24 lines in this issue.

Topics of the day:

  1. NPPD -- IBM LTO5 Tape Drive question

--

Date:Tue, 30 Aug 2011 10:46:29 -0500
From:Lamb, Charles P. cpl...@nppd.com
Subject: NPPD -- IBM LTO5 Tape Drive question

Hi...

Has anyone been using IBM LTO5 tape drives in an IBM 3584-L32/D32s Tape Lib=
rary configuration which has fourteen IBM LTO4 tape drives??  We presently =
use new IBM LTO4 tape drives for replacements, however, new IBM LTO4 tape d=
rives will be hard to find in the future.  We started to look into new IBM =
LTO5 tape drives as replacements, however, ALMS and enhance node card must =
be installed, we think into our IBM 3584-L32/D32s Tape Library.

Does anyone have more information about what is needed so an IBM 3584-L32/D=
32 firmware V7422 configuration can be change to support new IBM LTO5 tape =
drives??

Tnx's a bunch...

--

End of ADSM-L Digest - 28 Aug 2011 to 30 Aug 2011 (#2011-209)
*

Re: checkout libvol on 3584 - says slots are full

[Richard Rhodes]

We figured out what was wrong, but no idea why/how.

The 3584 is running with virtualization, so the logical lib has virtual
I/O slots.  These virtual I/O slots were full and prevented the checkout
from working.

Previously in trying to figure out this problem  I had found a doc on
IBM's web site that talked about full virtual I/O slots and that the
solution was to run a checkin.  At that time we didn't know the virtual
slots were full, but I ran throught the  procedure and ran a checkin -
nothing came in (first a private checkin, then a scratch checkin).  The
problem persisted so I figured the virtual slots were empty.  I had tried
many things: multiple checkout/checkin cmds with various parms, running an
inventory, bouncing the library manager tsm instance . . . nothing worked.

Another team member took a q libvol and compared it against the volumes
the Specialist GUI said the library had.  There was a discrepancy - the
lib had vols that tsm didn't know about.  She saw that the element
addresses of these volumes were of the virtual I/O slots (from logical lib
details).  TSM did not know about these tapes and could not  check them
in.  It's like they were in a limbo/stranded state of some kind.  She used
the Specialist gui to remove the tapes from lib.  After this the checkout
we were trying to perform worked as expected.

This was very strange.

Rick



From:   Baker, Jane jane.ba...@clarks.com
To: ADSM-L@VM.MARIST.EDU
Date:   08/26/2011 08:40 AM
Subject:Re: checkout libvol on 3584 - says slots are full
Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Hiya -

Is the cover to the i/o station clicked shut, maybe it thinks this is
open?

Or library could have gone out of sync with TSM.  We've had this
recently.

We fixed it by:

Shutdown TSM servers (library manager  client).
Force inventory on library in question by opening and shutting door,
rescans barcodes.
Startup TSM library manager, then library client.
Run audit library on all virtual libraries in question.

This then worked ok for us, but might be worth checking the i/o station
door is clicked shut!

Hope you get it fixed, sounds like an annoying one!

Jane.



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf Of
Richard Rhodes
Sent: 25 August 2011 18:57
To: ADSM-L@vm.marist.edu
Subject: Re: [ADSM-L] checkout libvol on 3584 - says slots are full

tried that a bunch of times.  This is so frustrating!

oh well . . . .

Rick




From:   Ben Bullock bbull...@bcidaho.com
To: ADSM-L@VM.MARIST.EDU
Date:   08/25/2011 01:49 PM
Subject:Re: checkout libvol on 3584 - says slots are full
Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Could be the sensor for the IO slot still thinks the door is open. Might
try opening it and closing it to see if it clears.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Richard Rhodes
Sent: Thursday, August 25, 2011 10:36 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] checkout libvol on 3584 - says slots are full

I'm trying to checkout of a 3584 a bunch of tapes. THe 3584 has one
logical library.

I'm issuing cmd:

 checkout libvol 3584go J04432 remove=bulk checklabel=no
   (origionally had vollist=a,b,c,etc)

It's failing with q request:

 ANR8352I Requests outstanding:
 ANR8387I 026: All entry/exit ports of library 3584GO are full or
inaccessible.
 Empty the entry/exit ports, close the entry/exit port door, and make
the ports accessible.

Anything I try doesn't change this, other than canceling the request.

The door cap slots are empty.
I ran a checkin libvol 3584go search=yes status=scratch label=barcode
and it find no volumes to checkin, so the virtual slots are empty also.

I'm stumped . . . cap door slots are empty and there isn't anything in
the virtual cap slots.

Any help is appreciated!

Rick


-
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are hereby
notified that you have received this document in error and that any
review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.

The BCI Email Firewall made the following annotations
-
*Confidentiality Notice:

This E-Mail is intended only for the use of the individual or entity to
which it is addressed and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. If you
have received this communication in error, please do not distribute, and
delete the original message.

Thank you for your compliance.

You may 

Re: checkout libvol on 3584 - says slots are full

[Ehresman,David E.]

My recollection is that when I eject something to the bulk I/O drawer on our 
3584, I cannot check those tapes back in until I remove them from the I/O 
drawer, close the door, open the door, and reload them.  This sounds like the 
behavior you saw on your virtual I/O slots.

David Ehresman

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Richard Rhodes
Sent: Wednesday, August 31, 2011 9:02 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] checkout libvol on 3584 - says slots are full

We figured out what was wrong, but no idea why/how.

The 3584 is running with virtualization, so the logical lib has virtual I/O 
slots.  These virtual I/O slots were full and prevented the checkout from 
working.

Previously in trying to figure out this problem  I had found a doc on IBM's web 
site that talked about full virtual I/O slots and that the solution was to run 
a checkin.  At that time we didn't know the virtual slots were full, but I ran 
throught the  procedure and ran a checkin - nothing came in (first a private 
checkin, then a scratch checkin).  The problem persisted so I figured the 
virtual slots were empty.  I had tried many things: multiple checkout/checkin 
cmds with various parms, running an inventory, bouncing the library manager tsm 
instance . . . nothing worked.

Another team member took a q libvol and compared it against the volumes the 
Specialist GUI said the library had.  There was a discrepancy - the lib had 
vols that tsm didn't know about.  She saw that the element addresses of these 
volumes were of the virtual I/O slots (from logical lib details).  TSM did not 
know about these tapes and could not  check them in.  It's like they were in a 
limbo/stranded state of some kind.  She used the Specialist gui to remove the 
tapes from lib.  After this the checkout we were trying to perform worked as 
expected.

This was very strange.

Rick



From:   Baker, Jane jane.ba...@clarks.com
To: ADSM-L@VM.MARIST.EDU
Date:   08/26/2011 08:40 AM
Subject:Re: checkout libvol on 3584 - says slots are full
Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Hiya -

Is the cover to the i/o station clicked shut, maybe it thinks this is open?

Or library could have gone out of sync with TSM.  We've had this recently.

We fixed it by:

Shutdown TSM servers (library manager  client).
Force inventory on library in question by opening and shutting door, rescans 
barcodes.
Startup TSM library manager, then library client.
Run audit library on all virtual libraries in question.

This then worked ok for us, but might be worth checking the i/o station door is 
clicked shut!

Hope you get it fixed, sounds like an annoying one!

Jane.



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf Of 
Richard Rhodes
Sent: 25 August 2011 18:57
To: ADSM-L@vm.marist.edu
Subject: Re: [ADSM-L] checkout libvol on 3584 - says slots are full

tried that a bunch of times.  This is so frustrating!

oh well . . . .

Rick




From:   Ben Bullock bbull...@bcidaho.com
To: ADSM-L@VM.MARIST.EDU
Date:   08/25/2011 01:49 PM
Subject:Re: checkout libvol on 3584 - says slots are full
Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Could be the sensor for the IO slot still thinks the door is open. Might try 
opening it and closing it to see if it clears.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Richard Rhodes
Sent: Thursday, August 25, 2011 10:36 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] checkout libvol on 3584 - says slots are full

I'm trying to checkout of a 3584 a bunch of tapes. THe 3584 has one logical 
library.

I'm issuing cmd:

 checkout libvol 3584go J04432 remove=bulk checklabel=no
   (origionally had vollist=a,b,c,etc)

It's failing with q request:

 ANR8352I Requests outstanding:
 ANR8387I 026: All entry/exit ports of library 3584GO are full or inaccessible.
 Empty the entry/exit ports, close the entry/exit port door, and make the ports 
accessible.

Anything I try doesn't change this, other than canceling the request.

The door cap slots are empty.
I ran a checkin libvol 3584go search=yes status=scratch label=barcode
and it find no volumes to checkin, so the virtual slots are empty also.

I'm stumped . . . cap door slots are empty and there isn't anything in the 
virtual cap slots.

Any help is appreciated!

Rick


-
The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in 

Re: checkout libvol on 3584 - says slots are full

[Paul Fielding]

A completely off-topic side note - when checking in tapes from your i/o door
that you're not certain of status, I would recommend running your two
checkins in the opposite order - first run a checkin with a status of
'scratch', then run with a status of 'private'.

TSM will happily check scratch tapes in as private, which will then prevent
you from using them if you just use a common scratch pool.  It will not,
however, let you checkin private tapes as scratch.   So by doing the
scratch checkin first, you'll get the tapes that really are scratch,
checked in as scratch, and it will barf on the private tapes.  You can then
checkin the 'private' tapes, and they'll be checked in appropriately...

Paul


On Wed, Aug 31, 2011 at 7:01 AM, Richard Rhodes rrho...@firstenergycorp.com
 wrote:

 We figured out what was wrong, but no idea why/how.

 The 3584 is running with virtualization, so the logical lib has virtual
 I/O slots.  These virtual I/O slots were full and prevented the checkout
 from working.

 Previously in trying to figure out this problem  I had found a doc on
 IBM's web site that talked about full virtual I/O slots and that the
 solution was to run a checkin.  At that time we didn't know the virtual
 slots were full, but I ran throught the  procedure and ran a checkin -
 nothing came in (first a private checkin, then a scratch checkin).  The
 problem persisted so I figured the virtual slots were empty.  I had tried
 many things: multiple checkout/checkin cmds with various parms, running an
 inventory, bouncing the library manager tsm instance . . . nothing worked.

 Another team member took a q libvol and compared it against the volumes
 the Specialist GUI said the library had.  There was a discrepancy - the
 lib had vols that tsm didn't know about.  She saw that the element
 addresses of these volumes were of the virtual I/O slots (from logical lib
 details).  TSM did not know about these tapes and could not  check them
 in.  It's like they were in a limbo/stranded state of some kind.  She used
 the Specialist gui to remove the tapes from lib.  After this the checkout
 we were trying to perform worked as expected.

 This was very strange.

 Rick



 From:   Baker, Jane jane.ba...@clarks.com
 To: ADSM-L@VM.MARIST.EDU
 Date:   08/26/2011 08:40 AM
 Subject:Re: checkout libvol on 3584 - says slots are full
 Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



 Hiya -

 Is the cover to the i/o station clicked shut, maybe it thinks this is
 open?

 Or library could have gone out of sync with TSM.  We've had this
 recently.

 We fixed it by:

 Shutdown TSM servers (library manager  client).
 Force inventory on library in question by opening and shutting door,
 rescans barcodes.
 Startup TSM library manager, then library client.
 Run audit library on all virtual libraries in question.

 This then worked ok for us, but might be worth checking the i/o station
 door is clicked shut!

 Hope you get it fixed, sounds like an annoying one!

 Jane.



 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf Of
 Richard Rhodes
 Sent: 25 August 2011 18:57
 To: ADSM-L@vm.marist.edu
 Subject: Re: [ADSM-L] checkout libvol on 3584 - says slots are full

 tried that a bunch of times.  This is so frustrating!

 oh well . . . .

 Rick




 From:   Ben Bullock bbull...@bcidaho.com
 To: ADSM-L@VM.MARIST.EDU
 Date:   08/25/2011 01:49 PM
 Subject:Re: checkout libvol on 3584 - says slots are full
 Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



 Could be the sensor for the IO slot still thinks the door is open. Might
 try opening it and closing it to see if it clears.

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
 Richard Rhodes
 Sent: Thursday, August 25, 2011 10:36 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: [ADSM-L] checkout libvol on 3584 - says slots are full

 I'm trying to checkout of a 3584 a bunch of tapes. THe 3584 has one
 logical library.

 I'm issuing cmd:

  checkout libvol 3584go J04432 remove=bulk checklabel=no
   (origionally had vollist=a,b,c,etc)

 It's failing with q request:

  ANR8352I Requests outstanding:
  ANR8387I 026: All entry/exit ports of library 3584GO are full or
 inaccessible.
  Empty the entry/exit ports, close the entry/exit port door, and make
 the ports accessible.

 Anything I try doesn't change this, other than canceling the request.

 The door cap slots are empty.
 I ran a checkin libvol 3584go search=yes status=scratch label=barcode
 and it find no volumes to checkin, so the virtual slots are empty also.

 I'm stumped . . . cap door slots are empty and there isn't anything in
 the virtual cap slots.

 Any help is appreciated!

 Rick


 -
 The information contained in this message is intended only for the
 personal and confidential use of the recipient(s) named above. If the
 reader of this message is not 

BMR options for mainframe Linux

[Thomas Denier]

We are in the process of migrating from a single on campus data center
to a pair of collocation facilities.

The on campus data center has a TSM 5.5.4.0 server running under SLES 9
Linux in a mainframe LPAR. Z/OS runs in another LPAR. The Linux system
has the usual Linux file systems, file systems for the TSM database,
and file systems for the TSM recovery log on ECKD disk. File systems
for disk storage pools are on FCP disk. The Linux system has FCP tape
drives. The z/OS system has FICON tape drives. The disks containing
the usual Linux file systems are backed up to FICON tape by the z/OS
system, using FDR.

The DR plan for the on campus data center uses a SunGard hot site. The
Linux system is recreated with FDR restores running under a z/OS floor
system provided by SunGard. Once this is done, additional file systems
are created and populated with empty database and recovery log volumes.
The TSM database is restored to these volumes. The disk storage pools
are not recreated.

The first collocation facility has a TSM 6.6.2.0 server running under
SLES 11 Linux in a mainframe LPAR. There is no z/OS system. All disk
is FCP attached. The only tape drives currently available to Linux
are the on campus FCP drives. FCP is layered on top of DWDM for the
connection between data centers. The second collocation center, with
a similar configuration, is expected to be available in a couple of
months. We are not currently using z/VM, but we could do so if
necessary; we have an unused license that was in effect bundled with
the mainframe hardware.

Originally, the interim DR plan for the first collocation facility
(while we were waiting for the second collocation facility) was to
avoid using the facility for systems that needed fast restores after
a disaster. The long term plan was to recreate the destroyed TSM
server as a second instance on the Linux system at the surviving
collocation center. However, we have recently been asked to look
into the possibility of recreating a Version 6 TSM server at the
SunGard hot site after a disaster at one of the collocation centers.

We have looked into the possibility of using a variant of the on
campus data center DR plan, with CMS and DDR taking over the roles
of z/OS and FDR. This appears to be economically unattractive, with
a sizable capital expenditure and significant increases in network
charges to provide for sending the DDR backups over FICON layered
on top of DWDM. Thus far, potential DR plans based on the use of a
Linux rescue system have been dismissed as too slow, too unreliable,
and too hard to test.

Does anyone know of a proven bare metal recovery process for
mainframe Linux systems without FICON tape drives?

TSM using vSCSI adapters

[Bob Molerio]

Hi guys,

I'm trying to find out if TSM 6.x will work in POWERVM (VIOS) AIX setup.
I'm not sure if this is supported as I believe TSM usually requires FC
adapters or SCSI adapters to connect to a tape libraries and storage.

--
Sincerely,

Bob Molerio.

Re: TSM using vSCSI adapters

[Hart, Charles A]

I'm not the most AIX savvy, but we did recently build a p7 750 using
NPIV / VIO, still seperating the disk and tape data paths.  

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Bob Molerio
Sent: Wednesday, August 31, 2011 10:40 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] TSM using vSCSI adapters

Hi guys,

I'm trying to find out if TSM 6.x will work in POWERVM (VIOS) AIX setup.
I'm not sure if this is supported as I believe TSM usually requires FC
adapters or SCSI adapters to connect to a tape libraries and storage.

--
Sincerely,

Bob Molerio.

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.

Re: checkout libvol on 3584 - says slots are full

[Mark Mooney]

Invaluable Advice!  That's how I run 'em.

Mooney

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul 
Fielding
Sent: Wednesday, August 31, 2011 6:57 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: checkout libvol on 3584 - says slots are full

A completely off-topic side note - when checking in tapes from your i/o door 
that you're not certain of status, I would recommend running your two checkins 
in the opposite order - first run a checkin with a status of 'scratch', then 
run with a status of 'private'.

TSM will happily check scratch tapes in as private, which will then prevent you 
from using them if you just use a common scratch pool.  It will not,
however, let you checkin private tapes as scratch.   So by doing the
scratch checkin first, you'll get the tapes that really are scratch, checked 
in as scratch, and it will barf on the private tapes.  You can then checkin the 
'private' tapes, and they'll be checked in appropriately...

Paul


On Wed, Aug 31, 2011 at 7:01 AM, Richard Rhodes rrho...@firstenergycorp.com
 wrote:

 We figured out what was wrong, but no idea why/how.

 The 3584 is running with virtualization, so the logical lib has 
 virtual I/O slots.  These virtual I/O slots were full and prevented 
 the checkout from working.

 Previously in trying to figure out this problem  I had found a doc on 
 IBM's web site that talked about full virtual I/O slots and that the 
 solution was to run a checkin.  At that time we didn't know the 
 virtual slots were full, but I ran throught the  procedure and ran a 
 checkin - nothing came in (first a private checkin, then a scratch 
 checkin).  The problem persisted so I figured the virtual slots were 
 empty.  I had tried many things: multiple checkout/checkin cmds with 
 various parms, running an inventory, bouncing the library manager tsm 
 instance . . . nothing worked.

 Another team member took a q libvol and compared it against the 
 volumes the Specialist GUI said the library had.  There was a 
 discrepancy - the lib had vols that tsm didn't know about.  She saw 
 that the element addresses of these volumes were of the virtual I/O 
 slots (from logical lib details).  TSM did not know about these tapes 
 and could not  check them in.  It's like they were in a limbo/stranded 
 state of some kind.  She used the Specialist gui to remove the tapes 
 from lib.  After this the checkout we were trying to perform worked as 
 expected.

 This was very strange.

 Rick



 From:   Baker, Jane jane.ba...@clarks.com
 To: ADSM-L@VM.MARIST.EDU
 Date:   08/26/2011 08:40 AM
 Subject:Re: checkout libvol on 3584 - says slots are full
 Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



 Hiya -

 Is the cover to the i/o station clicked shut, maybe it thinks this is 
 open?

 Or library could have gone out of sync with TSM.  We've had this 
 recently.

 We fixed it by:

 Shutdown TSM servers (library manager  client).
 Force inventory on library in question by opening and shutting door, 
 rescans barcodes.
 Startup TSM library manager, then library client.
 Run audit library on all virtual libraries in question.

 This then worked ok for us, but might be worth checking the i/o 
 station door is clicked shut!

 Hope you get it fixed, sounds like an annoying one!

 Jane.



 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf 
 Of Richard Rhodes
 Sent: 25 August 2011 18:57
 To: ADSM-L@vm.marist.edu
 Subject: Re: [ADSM-L] checkout libvol on 3584 - says slots are full

 tried that a bunch of times.  This is so frustrating!

 oh well . . . .

 Rick




 From:   Ben Bullock bbull...@bcidaho.com
 To: ADSM-L@VM.MARIST.EDU
 Date:   08/25/2011 01:49 PM
 Subject:Re: checkout libvol on 3584 - says slots are full
 Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



 Could be the sensor for the IO slot still thinks the door is open. 
 Might try opening it and closing it to see if it clears.

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf 
 Of Richard Rhodes
 Sent: Thursday, August 25, 2011 10:36 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: [ADSM-L] checkout libvol on 3584 - says slots are full

 I'm trying to checkout of a 3584 a bunch of tapes. THe 3584 has one 
 logical library.

 I'm issuing cmd:

  checkout libvol 3584go J04432 remove=bulk checklabel=no
   (origionally had vollist=a,b,c,etc)

 It's failing with q request:

  ANR8352I Requests outstanding:
  ANR8387I 026: All entry/exit ports of library 3584GO are full or 
 inaccessible.
  Empty the entry/exit ports, close the entry/exit port door, and make 
 the ports accessible.

 Anything I try doesn't change this, other than canceling the request.

 The door cap slots are empty.
 I ran a checkin libvol 3584go search=yes status=scratch label=barcode
 and it find no volumes to checkin, so the virtual slots are empty also.

 I'm stumped . . . 

Re: TSM using vSCSI adapters

[Remco Post]

Hi,

TSM will not be able to use vSCSI, but will be able to access tape using 
NPIV/virtual FC adapters. I'm not convinced that you'd really want to go that 
way, but the AIX specialists that I currently work with seem not to be too 
concerned about the performance impact. Then again, they never bother to tune 
any LPAR for performance, so YMMV.

On 31 aug. 2011, at 17:40, Bob Molerio wrote:

 Hi guys,
 
 I'm trying to find out if TSM 6.x will work in POWERVM (VIOS) AIX setup.
 I'm not sure if this is supported as I believe TSM usually requires FC
 adapters or SCSI adapters to connect to a tape libraries and storage.
 
 --
 Sincerely,
 
 Bob Molerio.

-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622

TSM Client Return Codes - Failed or partial failed

[Botelho, Tiago (External)]

 

Hello, 

 

 

I have a 160  (daily backup) environment and I need to perform a daily
report. 

 

Several Client Nodes  report Status: Failed  Result: Errors.

 

In those cases I have to login in the TSM Node and check dsmsched.log
and dsmerror.log to check if it fails completed or not.

 

In some situations, the client Backup fails completed. Others the
errorlog.log / dsmsched.log report open files or files not found ( but
in the report send by TSM Management console I cannot see the
difference).

 

I'm looking a solution that can see the difference between a complete
failure and a partial failure (like open files or files not found) to
use on TSM Management console (SQL statements).

 

There are any SQL query that can show me the difference?

 

Any event that can be disable on the TSM Server to prevent this.

 

Any ideas?

 

 

Thank you for your delp

 

 

Cumprimentos / Best regards 

Tiago Botelho
T_Systems at Volkswagen 

 

Re: TSM using vSCSI adapters

[Richard Rhodes]

We run StorageAgents on VIO based tape drives (not tsm servers).  They
seem to work just fine.

We did/do  have problems we are working throught:
- needed a patch to latest VIO server code to allow enough tape targets
- added memory to VIO server (from 1gb to 2gb) to allow enough tape
targets
- upgraded  StorageAgents from v5.4 to v5.5 (NPIV tape support was added
in v5.5)
- we are getting many TAPE_ERR4 errors (working with support)
- just started getting FSCSI_ERR4 errors
- are getting some scsi reservation errors

Rick






From:   Bob Molerio bobmole...@gmail.com
To: ADSM-L@VM.MARIST.EDU
Date:   08/31/2011 12:01 PM
Subject:TSM using vSCSI adapters
Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Hi guys,

I'm trying to find out if TSM 6.x will work in POWERVM (VIOS) AIX setup.
I'm not sure if this is supported as I believe TSM usually requires FC
adapters or SCSI adapters to connect to a tape libraries and storage.

--
Sincerely,

Bob Molerio.




-
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

TSM/VE column name containing DOMAIN.VMFULL ?

[Keith Arbogast]

This question is about the TSM for Virtual Environments architecture. 

Is a table and column available which contains the DOMAIN.VMFULL option for a 
backup instance? DOMAIN.VMFULL contains the name of the ESX host which is to be 
backed up by the backup instance. That would ease the management of backup 
instances.


Thank you,
Keith Arbogast

Re: TSM Client Return Codes - Failed or partial failed

[Richard Sims]

One thing you can do is query the ACTLOG for client-sent message ANE4959I 
telling of more than 0 files failed, which may correlate with previous ANE4037E 
messages about files changing during processing, ANE4005E file not found, and 
the like.  (If the same files show up day after day, then it's likely that the 
client administrator is not reviewing logs for issues, where the server 
administrator should best notify them.)
Similarly, the SUMMARY table contains a FAILED count.

Note that you can also do like
  select NODE_NAME, RESULTS from EVENTS where NODE_NAME is not null
to react to the return code from the client operation.

 Richard Sims  at Boston University

TSM6 and Hardware Replication

[Shawn Drew]

Last year there was a short discussion on TSM 6.1 and hardware replication
(SVC/SRDF/etc) but I can't find if there was any consensus.

I know HADR is the officially supported replication option, but is there
anyone successfully using any of these block replication for TSM6 ?
Any tricks to it or docs that I can be pointed to?

Regards,
Shawn

Shawn Drew


This message and any attachments (the message) is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.

Re: TSM Client Return Codes - Failed or partial failed

[Huebschman, George J.]

* A client can have failed objects in the Schedule Summary report
without having a failed backup.
The Return Codes from the Client RC 0, RC 4, RC 8, and RC 12 determine
whether or not a Scheduled backup fails.
A Scheduled backup can FAIL with NO failed files.  That used to drive me
crazy, but that is a short trip for me.


* Messages like these in the Client's dsmerror log should NOT cause RC
12 return codes (FAIL):
date_time ANS4037E Object \\...\\ changed during processing. Object
skipped.
date_time ANS4005E Error processing '\\path\to\file.tmp': file not
found
date_time ANS1228E Sending of object
'\\path\to\file_important_Workbook.xlsx' failed
date_time ANS4987E Error processing
'\\path\to\file_important_Workbook.xlsx': the object is in use by
another process

A file... changed during processing error (ANS4037E) happens
when a file has changed between the inventory and actually backup
attempt.  TSM skips it but does not fail the backup event.
A file not found error (ANS4005E)occurs because the client can
not find a file that was inventoried at the beginning of the backup
event.  The client starts the Incremental backup by checking to see what
new or changed objects exist. It makes a list and then backs them up.
If the file is deleted or moved between the creation of the list and the
backup of the object, (as with the .tmp files above), you get a message,
but not a failed backup.
A file in use error (ANS4987E) is regarded as a minor issue by
TSM as well. TSM feels it should tell you about it, but since it is not
in a state where a good backup can be taken, it is not a fatal event.
Your TSM Server CopyGroup serialization settings determine if
TSM will try to back it up again.
The CHAngingretries option for the Client in the dsm.sys or
dsm.opt file determines how many times a client should retry the file.
You may see Retry messages such as these for objects in that
situation:
08/30/2011 01:27:43 Retry # 1  Normal File-- 2,992,622
\\CIFS_Filer_name\Long\long\path\to\file_Report.pdf [Sent]

* Actual FAILure of the scheduled backup event is often from an
inability to access a path or (Client) domain, from inability to perform
a specific option in an options file (such as an include statement, or a
pre-scheduled command), or from permissions errors:
08/22/2011 15:34:30 ANS4013E Error processing '\\Path\to\some_file:
invalid file handle

08/22/2011 15:43:02 ANS1512E Scheduled event '6PM-DAILY-INCR' failed.
Return code = 12

08/30/2011 01:27:43 ANS4007E Error processing
'\\rrstore11a\assetmgmt\Users\ADoyle\IEfavs\Links\Customize Links.url':
access to the object is denied
These ANS4007E messages are a pain for me.  Often they indicate
that the Client is running from a profile with insufficient permissions
to access the file.  In my case these are files on a CIFS share.  The
filer, CIFS, VSCAN, and Virus software and not working together well.

On Windows clients if you are backing up SystemState and there are VSS
errors...welcome to the club.  They will fail your Scheduled backup
event.  Looking at one of mine that I see failed for VSS/SystemState
errors, there is no mention of the VSS error/failure in the TSM Server
Actlog.

* You can look for these message codes in the TSM Server ACTLOG to
determine Failed (and Missed) backups:
***MISSED/FAILED
FAILED: q ac begint=-24 msg=2579
MISSED: q ac begint=-24 msg=2578
You can also do them as selects.

Checking for this with a TSM Server query actlog msg=4959 will NOT
tell you if the backup failed
08/30/2011 20:58:23  ANE4959I (Session: 4580433, Node:
Some_Client_Name)  Total
  number of objects failed:   4
(SESSION: 4580433)
For example, in the summary information reported the the TSM Server by
the Client (and logged in the Actlog) there are 15 objects failed, but
the backup was successful
  4579578)
08/30/2011 18:27:02  ANE4952I (Session: 4579578, Node:
SOME_CLIENT_NAME)  Total
  number of objects inspected:   44,415
(SESSION: 4579578)
08/30/2011 18:27:02  ANE4954I (Session: 4579578, Node:
SOME_CLIENT_NAME)  Total
  number of objects backed up:3,360
(SESSION: 4579578)
08/30/2011 18:27:02  ANE4958I (Session: 4579578, Node:
SOME_CLIENT_NAME)  Total
  number of objects updated:  0
(SESSION: 4579578)
08/30/2011 18:27:02  ANE4960I (Session: 4579578, Node:
SOME_CLIENT_NAME)  Total
  number of objects rebound:  0
(SESSION: 4579578)
08/30/2011 18:27:02  ANE4957I (Session: 4579578, Node:
SOME_CLIENT_NAME)  Total
  number of objects deleted:  0
(SESSION: 4579578)
08/30/2011 18:27:02  ANE4970I (Session: 4579578, Node:
SOME_CLIENT_NAME)  Total
  number of objects expired:  7
(SESSION: 4579578)

08/30/2011 18:27:02  ANE4959I (Session: 4579578, 

Activity Log search via Firefox

[Vandeventer, Harold [BS]]

I'm using Firefox 3.6.20 as the interface to Tivoli Integrated Portal for TSM 
6.2.x.  I gave up trying to use IE 7 due to slow performance; it's the only 
allowed version of IE.

I'm seeing two problems in Firefox:

1: some searches display the results in random order; I have to click the Date 
and Time column to get the order correct. This may be search by msg number; 
don't think I've seen it on text search.

2: if a search (text or msg number) provides more than one page, clicking the 
next page arrow, or entering the page value and clicking go usually changes 
the search parameters to something I did earlier.  As far back as a few hours 
ago.

Is this my firefox version or something IBM controls within the Admin Center?

Harold Vandeventer

Re: TSM/VE column name containing DOMAIN.VMFULL ?

[Keith Arbogast]

Here is the long version of my question. I hope it's clear.  

Recommendations for Scheduling with TSM for VE in the TSMVE wiki recommends 
including the ESX server that is processed in the name of options files, and 
by examples, the backup instance names too.  We did that, and were quite happy 
with the model until we learned that our ESX hosts are sometimes moved between 
clusters for load balancing. When that happens, host specific names will create 
side-effects.  Specifically, the backup instance which processes that host will 
no longer be in the same cluster as the host it backs up --which will degrade 
its backup performance, and its processing will have to be moved to a backup 
instance on the new cluster. 

Our testing has shown that a backup instance needs to live in the same VMware 
cluster as the ESX host it processes for best performance. We don't let LUNs 
mix between clusters, so we can't put all our backup instances on one host and 
zone it to see all the LUNs in a datacenter.  

We are installing multiple (4) backup instances per virtual machine. Each one 
will process one ESX host which is named in the DOMAIN.VMFULL option in its 
dsm.opt. 
  
For backup instance names, we could use specific names as recommended, like 
TSMVE03-ESX01; or generic names, like TSMVE03-A  (where TSMVE03 is the name of 
the virtual machine underlying the backup instance, 'A' is anything, and ESX01 
is the host processed.)  

If we use specific names, it should be easy to see which backup instance was 
affected by a host move, since the host is part of its name.  But, it will be 
complicated to manage after that.The old backup instance will have to be 
removed, since it can't be reused, and a new backup instance with a new 
specific name installed on the new cluster. Hooray for dsmcutil, but it can be 
moody.
 
If we use generic names, it will be difficult to see which backup instance was 
affected by the host move, since generic names are meaningless. But, once it is 
found, perpetuating the backup process will be easy to manage. Just stop CAD on 
the old backup instance. It can even be reused for another ESX host by 
modifying its DOMAIN.VMFULL option. A handy generic backup instance on the new 
cluster will be put into use for the moved host.
 
Each naming scheme has strengths and weaknesses. If a table and column is 
available which contains the DOMAIN.VMFULL option we could use a select 
statement to find the backup instance affected by a host move. Being able to do 
this would allow us to use generic names for backup instances which should make 
management of host moves easier than if backup instances had host-specific 
names. 

I would be glad to hear if I have missed the point somewhere in absorbing the 
TSMVE documentation. 

With best wishes,
Keith Arbogast

IA64 vs x64

[Jim Neal]

Hi All,



I would like to know if it makes any difference if you
install the IA64 or x64 version of TSM on a Windows client?   Specifically,
does it cause issues to install IA64 on an AMD based system or vice versa?
If you are using and i7 Core system, can you use both?  I have tried to find
clear answers to this in the documentation, but it does not seem to be
specifically addressed in either the readme files or the client
documentation.   Thanks much!





Jim Neal

Sr. TSM Administrator

U.C. Berkeley

Storage and Backup Group

Re: IA64 vs x64

[Skylar Thompson]

IA64 is for Itanium systems, x64 is for 64-bit x86-style systems (aka
x86_64, AMD64, etc. depending on whom you ask).

--
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

Re: IA64 vs x64

[Remco Post]

IA64==Itanium, usually not what you have.

On 31 aug. 2011, at 23:42, Jim Neal wrote:

 Hi All,
 
 
 
I would like to know if it makes any difference if you
 install the IA64 or x64 version of TSM on a Windows client?   Specifically,
 does it cause issues to install IA64 on an AMD based system or vice versa?
 If you are using and i7 Core system, can you use both?  I have tried to find
 clear answers to this in the documentation, but it does not seem to be
 specifically addressed in either the readme files or the client
 documentation.   Thanks much!
 
 
 
 
 
Jim Neal
 
Sr. TSM Administrator
 
 U.C. Berkeley
 
Storage and Backup Group

-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622

Re: TSM/VE column name containing DOMAIN.VMFULL ?

[Storer, Raymond]

Keith, I added a column to my vCenter for the TSM Node name, assigned a generic 
TSM Node name to each vm (I use 4 nodes), and then used PowerCli to write out 
four batch files to get my hosts backed up. In this way, it doesn't matter 
which host the vm lives on (or moves to), the TSM Node name will never 
change--and, I can know the TSM Node name for any vm from the vShere Client by 
adding my new column to the display. I also wrote a few reporting scripts to 
check what backed up etc.

Anyway, I guess I say all that to say I prefer the generic TSM Node name 
approach.

Good luck!

Ray

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Keith 
Arbogast
Sent: Wednesday, August 31, 2011 1:59 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] TSM/VE column name containing DOMAIN.VMFULL ?

This question is about the TSM for Virtual Environments architecture.

Is a table and column available which contains the DOMAIN.VMFULL option for a 
backup instance? DOMAIN.VMFULL contains the name of the ESX host which is to be 
backed up by the backup instance. That would ease the management of backup 
instances.


Thank you,
Keith Arbogast


CONFIDENTIALITY NOTICE:  This email and any attachments are for the
exclusive and confidential use of the intended recipient.  If you are not
the intended recipient, please do not read, distribute or take action in
reliance upon this message. If you have received this in error, please
notify us immediately by return email and promptly delete this message
and its attachments from your computer system. We do not waive
attorney-client or work product privilege by the transmission of this
message.

Re: IA64 vs x64

[Andrew Raibeck]

Addendum (to my prior response):

If you go to the URL in my sig, look in Featured Links, and click on
Client Requirements, you will find the Windows requirements page which
outlines the processor support.

Best regards,

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Hartford/IBM@IBMUS
Internet e-mail: stor...@us.ibm.com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager

ADSM: Dist Stor Manager ADSM-L@vm.marist.edu wrote on 2011-08-31
17:42:28:

 From: Jim Neal jrn...@berkeley.edu
 To: ADSM-L@vm.marist.edu
 Date: 2011-08-31 17:54
 Subject: IA64 vs x64
 Sent by: ADSM: Dist Stor Manager ADSM-L@vm.marist.edu

 Hi All,



 I would like to know if it makes any difference if you
 install the IA64 or x64 version of TSM on a Windows client?
Specifically,
 does it cause issues to install IA64 on an AMD based system or vice
versa?
 If you are using and i7 Core system, can you use both?  I have tried to
find
 clear answers to this in the documentation, but it does not seem to be
 specifically addressed in either the readme files or the client
 documentation.   Thanks much!





 Jim Neal

 Sr. TSM Administrator

 U.C. Berkeley

 Storage and Backup Group

Re: IA64 vs x64

[Andrew Raibeck]

Hi Jim,

The IA64 client is intended for Windows systems running on Itanium
processors and using a version of Windows targeted for the Itanium
processor.

If you are running a version of Windows targeted for x64 (AMD) processors
then you must use the x64 client.

Best regards,

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Hartford/IBM@IBMUS
Internet e-mail: stor...@us.ibm.com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager

ADSM: Dist Stor Manager ADSM-L@vm.marist.edu wrote on 2011-08-31
17:42:28:

 From: Jim Neal jrn...@berkeley.edu
 To: ADSM-L@vm.marist.edu
 Date: 2011-08-31 17:54
 Subject: IA64 vs x64
 Sent by: ADSM: Dist Stor Manager ADSM-L@vm.marist.edu

 Hi All,



 I would like to know if it makes any difference if you
 install the IA64 or x64 version of TSM on a Windows client?
Specifically,
 does it cause issues to install IA64 on an AMD based system or vice
versa?
 If you are using and i7 Core system, can you use both?  I have tried to
find
 clear answers to this in the documentation, but it does not seem to be
 specifically addressed in either the readme files or the client
 documentation.   Thanks much!





 Jim Neal

 Sr. TSM Administrator

 U.C. Berkeley

 Storage and Backup Group