Re: Drive and Path Definition

2012-01-23 Thread Tailor, Mahesh C.
This is from TSM L2 supportbottom line, restart TSM.  No attempt to figure 
out why I cannot define the drives/paths even though AIX sees the drives 
through itdt.

=== SNIP ===

itdt -f /dev/smc0 inventory inv.out

from inv.out, you can see all drives ( at beginning of the output ) which are 
managed by /dev/smc0, if you don't see the drives from itdt then, there are no 
way you are going to see that via tsm.

If you see the drives as expected in inv.out, then starts TSM or re-initiate 
the TSM library, TSM should sync the library infor with device driver during 
starts up, confirm the infor via command show slots libraryname. If you see 
the new drives via show slots libraryname, then go ahead to define the 
drive/path.

The SANdiscovery will only be triggered during tsm starts up and when the 
device open failed ( with certain error) or when you run q san , Also, it 
will only correct wrong device during discovery for drives TSM sees in your 
defined library.

=== END ===

Had to get the servers in production, so just restarted TSM to continue with 
the define.

Thanks for everyone's input.

Mahesh


From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] On Behalf Of Shawn Drew 
[shawn.d...@americas.bnpparibas.com]
Sent: Thursday, January 19, 2012 10:53
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Drive and Path Definition

The only other option to restarting the library manager is removing and
redefining all drives,  library and paths.  This would technically leave
the TSM server up and would still reprobe the library.
The Audit libr command never worked for me on a scsi library for these
updates.

Regards,
Shawn

Shawn Drew





Internet
rrho...@firstenergycorp.com

Sent by: ADSM-L@VM.MARIST.EDU
01/19/2012 09:57 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Drive and Path Definition






ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 01/19/2012
08:42:26 AM:

  ...
  Our libraries are 3584 scsi libraries, which are different animals
from
  3494 libraries.  Sorry, I should have said that.
 
  Any time we have changed the physical library it has required us to
bounce
  TSM so the new slots EA and/or drive EA are available to TSM.  In our
  case, that's our library manager tsm instance.  We are still on v5.5,
but
  I've seen nothing that would indicate that v6+ is any different.

 Rick -

 Have you tried Audit Library as part of the change procedure?  It
 should perform a reconciliation with the reality of the library,
 using the same functionality that occurs when TSM restarts and
 checks the library.

Richard Sims

This is interesting discussion.

Here's my story . . .

Our 3584 libraries started out witn 3 frames.  They are now
at 8 frames. Sometimes a slot-only frame was added, other times
a frame with slots+drives.  The first time we added a frame I
took the drives offline while IBM worked, but didn't bounce the
library manager. I loaded up the new frame with new tapes
assigned to the Logical Lib. Running checkin would not see the
new tapes.   I also brought the new drives
in the new frame into AIX, created TSM drives, but failed on the
paths.   Now, it was a long time ago
and I don't exactly remember, but I believe I did an audit
(but maybe I didn't).  I also didn't know about show slots and
show libr cmds.I opened a case with support and was
told I needed to bounce the library manager.   That worked, all was good.
Since then after making any physical change I bounce the library manager.

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.



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.

Notice: The information and attachment(s) contained in this communication are 
intended for the addressee only, and may be confidential and/or legally 
privileged. If you have received this 

Re: Drive and Path Definition

2012-01-19 Thread Richard Rhodes
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 01/18/2012
06:28:41 PM:

   In the past we've never had to restart TSM to add a new drive.  As
   long as the drive was discovered and available at the AIX layer, we
   could define the new drive.  Has this changed with v6.2.x?
 
  It's my experience that any change to the library (adding slots or
drives)
  requires cycling TSM before it can access the new resource.

 Seriously?  Is this behavior due to changes in TSM 6.x, or has it
 always been this way for SCSI-style (smcX) libraries?

 I've never had this issue with my 3494 library and any TSM version
 from ADSM 2.1 through TSM 5.5.

Our libraries are 3584 scsi libraries, which are different animals from
3494 libraries.  Sorry, I should have said that.

Any time we have changed the physical library it has required us to bounce
TSM so the new slots EA and/or drive EA are available to TSM.  In our
case, that's our library manager tsm instance.  We are still on v5.5, but
I've seen nothing that would indicate that v6+ is any different.



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.


Re: Drive and Path Definition

2012-01-19 Thread Richard Sims
On Jan 19, 2012, at 8:19 AM, Richard Rhodes wrote:

 ...
 Our libraries are 3584 scsi libraries, which are different animals from
 3494 libraries.  Sorry, I should have said that.
 
 Any time we have changed the physical library it has required us to bounce
 TSM so the new slots EA and/or drive EA are available to TSM.  In our
 case, that's our library manager tsm instance.  We are still on v5.5, but
 I've seen nothing that would indicate that v6+ is any different.

Rick -

Have you tried Audit Library as part of the change procedure?  It should 
perform a reconciliation with the reality of the library, using the same 
functionality that occurs when TSM restarts and checks the library.

   Richard Sims


Re: Re: Drive and Path Definition

2012-01-19 Thread Allen S. Rout

On 01/18/2012 06:28 PM, David Bronder wrote:

Richard Rhodes wrote:



In the past we've never had to restart TSM to add a new drive.  As
long as the drive was discovered and available at the AIX layer, we
could define the new drive.  Has this changed with v6.2.x?


Seriously?  Is this behavior due to changes in TSM 6.x, or has it
always been this way for SCSI-style (smcX) libraries?

I've never had this issue with my 3494 library and any TSM version
from ADSM 2.1 through TSM 5.5.



Me too; 3494 and 3584 both, I've not needed to restart TSM to begin
accessing new devices.

- Allen S. Rout


Re: Drive and Path Definition

2012-01-19 Thread Allen S. Rout

On 01/19/2012 01:37 AM, Roger Deschner wrote:


Pay attention to the fact that typically rmtN, mtN, and TSM driveN
device numbers will be different. Make sure the serial numbers in TSM Q
DRIVE F=D are correct.



... This, a whole bunch.I'll drop a few scripts here I use to
automate the process.

First, I've got a file which associates TSM drive names with serial
numbers.  In my scripts it's referenced as
'/var/tsm/base/etc/device-correspondence.csv', but of course you can
store it anywhere.   It looks like this:

DRIVE0,07892730,460,new
DRIVE1,07892835,470,new
DRIVE2,07892870,480,new

The third field there is me keeping track of how the 3494 sees the
drive.  Useful to communicate with SE, who'll tell you that drive 300
had an intervention.  My scripts only use the first two fields;
unfinished plans, et. alia.


Then I've got the attached script 'tape-config', which looks at all of
your tape devices and ties them, through the serial number, to your TSM
drive label.  It drops a bunch of files in ., each one of which holds
all the lsdev output for devices attached to that serial.

The last step is the attached script 'tape-paths', which takes all the
collected devices, and then dumps path updates (or if you tell it to,
defines) to stdout.  It expects to be run in the directory where you
collected tape-config.  Its output looks something like this:

root@tsm4 tapes-2011-12 # ./tape-paths  -server foo -define
define path foo DRIVE9 srct=server destt=drive libr=3592lib
device=/dev/rmt8
define path foo DRIVE6 srct=server destt=drive libr=3592lib
device=/dev/rmt4
define path foo DRIVE8 srct=server destt=drive libr=3592lib
device=/dev/rmt9
[...]

or
root@tsm4 tapes-2011-12 # ./tape-paths  -server foo
update path foo DRIVE9 srct=server destt=drive libr=3592lib
device=/dev/rmt8
update path foo DRIVE6 srct=server destt=drive libr=3592lib
device=/dev/rmt4
update path foo DRIVE8 srct=server destt=drive libr=3592lib
device=/dev/rmt9
[...]



 All in all, it's sufficiently easy that I approach even broad
renumbering and fabric changes with equanimity.   We recently split our
fiber into two independant fabrics, and I basically:

+ set all drives offline.

+ recabled the last few links.

+ rmdev -d -l every rmt device

+ cfgmgr

+ instAtape -a to get multipath data in place

+ run tape-config

and then at the bash prompt:

# for server in int ext glmail01 glmail02 whole list of servers; \
  tape-paths -server $server


which gives output you can just paste into your library manager.


- Allen S. Rout



#!/usr/local/bin/perl

use FileHandle;
use Data::Dumper;

my $verbose =1;
my $in = new FileHandle;
my $drives = {};

my $out = {};

$in-open(/var/tsm/base/etc/device-correspondence.csv);

while ($in)
  {
#print;
chomp;
my ($tsm,$sn) = split(/,/);
$drives-{$sn} = $tsm;
  }

# print Dumper($drives);


$in-open(/usr/sbin/lscfg | grep rmt |);

while ($in)
  {
my ($junk,$rmt,@junk) = split;
#print $rmt,\n;
my (@tape) = `/usr/sbin/lscfg -vl $rmt`;
my ($snline) = grep{/Serial Number\.+(\d+)$/}  @tape;
#print $snline;
my ($sn) = $snline =~ /Serial Number\.+(\d+)$/;
my $drive = $drives-{$sn};

$verbose  print $rmt:\tNew entry for '$drive'\n;
$out-{$sn} = new FileHandle(./serial-$sn-$drive) unless 
defined($out-{$sn});

$out-{$sn}-print(@tape);
$out-{$sn}-print( `/usr/sbin/lsdev -l $rmt` );


}




#!/usr/local/bin/perl

use FileHandle;
use Data::Dumper;
use Getopt::Long;

my $verbose =1;
my $in = new FileHandle;
my $drives = {};
my $rmts = {};
my $define = undef;

my $server = [];
my @servers;
my $script = 0;

my $libr=3592lib;


$result = GetOptions
(
 verbose   = \$verbose,
 server=s  = $server,
 define!   = \$define,
 script!= \$script,
 );


if ($#{$server}  -1 ) {@servers = @{$server} ;} else {@servers = ( CTRL ) }


my $out = {};

$in-open(/var/tsm/base/etc/device-correspondence.csv);

while ($in)
  {
#print;
chomp;
my ($tsm,$sn,$lib) = split(/,/);
$drives-{$sn} = {
  'TSM' =  $tsm,
  'LIB' =  $lib,
  };
  }

$in-close;  $in-open(/usr/sbin/lsdev -Cc tape|);
while ($in)
  {
chomp;
#print;
my ($rmt,$stat,$loc,@crap) = split(/\s+/);
my @junk = split(/-/,$loc);

$rmts-{$rmt} = { pri = pop(@junk) };
  }


# print Dumper($rmts);


foreach $drive (keys %$drives)
  {
my @lines = `/usr/local/bin/grep rmt ./serial-$drive-*`;
my $pri = ;
foreach $line (@lines)
  {
my ($crap,$dev,@crap) = split(/\s+/,$line);
my $p = $rmts-{$dev}-{pri};

if ($p eq PRI)
  {
   if ($pri ne ) { die Multiple primay devices for '$drive' ?? }
   $pri = $dev;
  }
  }

if  ($pri eq ) { die No primary device for '$drive' ?? }

#print $drive: $pri \n;
$drives-{$drive}-{pri} = $pri;


  }

# print Dumper($drives);

if (0)
  {

foreach $drive ( keys %$drives)
  {


Re: Re: Drive and Path Definition

2012-01-19 Thread Howard Coles
I'm with Allen.  In 10 years of TSM work with both SCSI and FC Libraries and 
drives, I've never had to restart TSM on AIX to add drives and paths one by one.

I also don't mess with TSM Devices since TSM 4.2 on AIX either.  I just run 
cfgmgr, then define the drives and paths.

I have used an Exabyte Library (well, that's using the term used loosely, it 
stunk), and several 3584's.  Something isn't getting adjusted right in the TSM 
database, or it's having a hard time picking up the device serial number and/or 
WWN (at least that's what I would suspect).


See Ya'
Howard Coles Jr.
John 3:16!


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Allen 
S. Rout
Sent: Thursday, January 19, 2012 8:07 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Re: Drive and Path Definition

On 01/18/2012 06:28 PM, David Bronder wrote:
 Richard Rhodes wrote:

 In the past we've never had to restart TSM to add a new drive.  As
 long as the drive was discovered and available at the AIX layer, we
 could define the new drive.  Has this changed with v6.2.x?

 Seriously?  Is this behavior due to changes in TSM 6.x, or has it
 always been this way for SCSI-style (smcX) libraries?

 I've never had this issue with my 3494 library and any TSM version
 from ADSM 2.1 through TSM 5.5.


Me too; 3494 and 3584 both, I've not needed to restart TSM to begin
accessing new devices.

- Allen S. Rout
DISCLAIMER: This communication, along with any documents, files or attachments, 
is intended only for the use of the addressee and may contain legally 
privileged and confidential information. If you are not the intended recipient, 
you are hereby notified that any dissemination, distribution or copying of any 
information contained in or attached to this communication is strictly 
prohibited. If you have received this message in error, please notify the 
sender immediately and destroy the original communication and its attachments 
without reading, printing or saving in any manner. Please consider the 
environment before printing this e-mail.


Re: Drive and Path Definition

2012-01-19 Thread Richard Rhodes
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 01/19/2012
08:42:26 AM:

  ...
  Our libraries are 3584 scsi libraries, which are different animals
from
  3494 libraries.  Sorry, I should have said that.
 
  Any time we have changed the physical library it has required us to
bounce
  TSM so the new slots EA and/or drive EA are available to TSM.  In our
  case, that's our library manager tsm instance.  We are still on v5.5,
but
  I've seen nothing that would indicate that v6+ is any different.

 Rick -

 Have you tried Audit Library as part of the change procedure?  It
 should perform a reconciliation with the reality of the library,
 using the same functionality that occurs when TSM restarts and
 checks the library.

Richard Sims

This is interesting discussion.

Here's my story . . .

Our 3584 libraries started out witn 3 frames.  They are now
at 8 frames. Sometimes a slot-only frame was added, other times
a frame with slots+drives.  The first time we added a frame I
took the drives offline while IBM worked, but didn't bounce the
library manager. I loaded up the new frame with new tapes
assigned to the Logical Lib. Running checkin would not see the
new tapes.   I also brought the new drives
in the new frame into AIX, created TSM drives, but failed on the
paths.   Now, it was a long time ago
and I don't exactly remember, but I believe I did an audit
(but maybe I didn't).  I also didn't know about show slots and
show libr cmds.I opened a case with support and was
told I needed to bounce the library manager.   That worked, all was good.
Since then after making any physical change I bounce the library manager.

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.


Re: Drive and Path Definition

2012-01-19 Thread Shawn Drew
The only other option to restarting the library manager is removing and
redefining all drives,  library and paths.  This would technically leave
the TSM server up and would still reprobe the library.
The Audit libr command never worked for me on a scsi library for these
updates.

Regards,
Shawn

Shawn Drew





Internet
rrho...@firstenergycorp.com

Sent by: ADSM-L@VM.MARIST.EDU
01/19/2012 09:57 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Drive and Path Definition






ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 01/19/2012
08:42:26 AM:

  ...
  Our libraries are 3584 scsi libraries, which are different animals
from
  3494 libraries.  Sorry, I should have said that.
 
  Any time we have changed the physical library it has required us to
bounce
  TSM so the new slots EA and/or drive EA are available to TSM.  In our
  case, that's our library manager tsm instance.  We are still on v5.5,
but
  I've seen nothing that would indicate that v6+ is any different.

 Rick -

 Have you tried Audit Library as part of the change procedure?  It
 should perform a reconciliation with the reality of the library,
 using the same functionality that occurs when TSM restarts and
 checks the library.

Richard Sims

This is interesting discussion.

Here's my story . . .

Our 3584 libraries started out witn 3 frames.  They are now
at 8 frames. Sometimes a slot-only frame was added, other times
a frame with slots+drives.  The first time we added a frame I
took the drives offline while IBM worked, but didn't bounce the
library manager. I loaded up the new frame with new tapes
assigned to the Logical Lib. Running checkin would not see the
new tapes.   I also brought the new drives
in the new frame into AIX, created TSM drives, but failed on the
paths.   Now, it was a long time ago
and I don't exactly remember, but I believe I did an audit
(but maybe I didn't).  I also didn't know about show slots and
show libr cmds.I opened a case with support and was
told I needed to bounce the library manager.   That worked, all was good.
Since then after making any physical change I bounce the library manager.

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.



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: Drive and Path Definition

2012-01-18 Thread Shawn Drew
You did the itdt against rmt0, but you are defining the path to rmt11. I'm 
assuming this is happening for all drive and that discrepancy doesn't 
actually mean anything. 

The problem is most likely with the library device smcX, not the drives. 
- I can't remember the commands, but can you probe the library device with 
itdt?  I think its smc0 with atape.
- is Drive 11 actually in library kvtl1p1?
- is the path to the library device for kvtl1p1 is already defined and 
online?
- Was this drive a recent addition to the library? 
- If so, was the TSM instance restarted since it was added? (restarting 
the instance will repprobe the library for new elements, drives/slots, 
etc)
- Are all drives in the library not working or only drive 11?



Regards, 
Shawn

Shawn Drew





Internet
mctai...@carilionclinic.org

Sent by: ADSM-L@VM.MARIST.EDU
01/18/2012 09:41 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] Drive and Path Definition






Hello.

I have a PMR on this, but not making much progress on it so thought I 
would send this out on the User List to see if anyone else encountered 
this issue and can suggest a fix.

Here's what I have:

TSM 6.2.3.100
AIX 7.1 (oslevel: 7100-00-04-1140)
IBM FC 5729 8-Gbps FC adapters

SAN Switch: IBM SAN-768A (Brocade DCX)

Atape 12.1.5.0
Sepaton VTL emulating 3584L22 and 3592 tape drives
SANDISCOVERY ON

We define a tape drive on the VTL and present it to the TSM server.  AIX 
discovers the tape drive and I can use itdt (tapeutil) to query the drive. 
 For example...

./itdt -f /dev/rmt0 inquiry
Issuing std inquiry...
Inquiry Data,  Length 96
0 1  2 3  4 5  6 7  8 9  A B  C D  E F   0123456789ABCDEF
 - 0180 0302 3300 1130 4942 4D20 2020 2020  [.�..3..0IBM ]
0010 - 3033 3539 324A 3141 2020 2020 2020 2020  [03592J1A]
0020 - 3035 3039 3638 3030 5347 3131 3032 3330  [05096800SG110230]
0030 - 3031 2030 0500 0181      [01 0...�]
0040 -          []
0050 -          []

Exit with code: 0
./itdt -f /dev/rmt0 inquiry 80
Issuing inquiry for page 0x80...
Inquiry Page 0x80,  Length 14
0 1  2 3  4 5  6 7  8 9  A B  C D  E F   0123456789ABCDEF
 - 0180 000A 5347 3131 3032 3330 3031   [.�..SG11023001  ]

Exit with code: 0

I log into TSM and define the drive.

01/17/12   11:55:36  ANR2017I Administrator ADMIN issued command: 
DEFINE DRIVE
  kvtl1p1 rmt11 serial=autod elem=autod  (SESSION: 
15)
01/17/12   11:55:36  ANR8404I Drive RMT11 defined in library KVTL1P1. 
(SESSION:
  15)

Then I try to define the path.

01/17/12   11:56:16  ANR2017I Administrator ADMIN issued command: 
DEFINE PATH
  tsmprd01 rmt11 srct=server destt=drive autod=yes
  devi=/dev/rmt11 library=kvtl1p1 online=yes 
(SESSION: 15)
01/17/12   11:56:16  ANR8972E DEFINE PATH: Unable to find the element 
number
  for drive RMT11 in library KVTL1P1.  (SESSION: 
15)
I stop and restart TSM and issue the same command.

01/17/12   12:00:00  ANR2017I Administrator ADMIN issued command: 
DEFINE PATH
  tsmprd01 rmt11 srct=server destt=drive autod=yes
  devi=/dev/rmt11 library=kvtl1p1 online=yes 
(SESSION: 1)
01/17/12   12:00:00  ANR8955I Drive RMT11 in library KVTL1P1 with 
serial number
   is updated with the newly discovered serial 
number
  SG11023012. (SESSION: 1)
01/17/12   12:00:00  ANR1720I A path from TSMPRD01 to KVTL1P1 RMT11 
has been
  defined. (SESSION: 1)
Has anyone else seen this problem?  Any ideas?

TIA

Mahesh


Notice: The information and attachment(s) contained in this communication 
are intended for the addressee only, and may be confidential and/or 
legally privileged. If you have received this communication in error, 
please contact the sender immediately, and delete this communication from 
any computer or network system. Any interception, review, printing, 
copying, re-transmission, dissemination, or other use of, or taking of any 
action upon this information by persons or entities other than the 
intended recipient is strictly prohibited by law and may subject them to 
criminal or civil liability. Carilion Clinic shall not be liable for the 
improper and/or incomplete transmission of the information contained in 
this communication or for any delay in its receipt.




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 

Re: Drive and Path Definition

2012-01-18 Thread Tailor, Mahesh C.
Drew,

Thanks for the reply.

- Yes, this is happening with all drives.  The RMT1 was just and example that 
the drives are accessible.
- We are adding drives one at a time having to go through this process.  At one 
time we had add sixty drives discovered at the AIX layer (rmt0-rmt59), started 
up TSM, and ran into the same issue.

In the past we've never had to restart TSM to add a new drive.  As long as the 
drive was discovered and available at the AIX layer, we could define the new 
drive.  Has this changed with v6.2.x?

Mahesh


From: ADSM: Dist Stor Manager [ADSM-L@VM.MARIST.EDU] On Behalf Of Shawn Drew 
[shawn.d...@americas.bnpparibas.com]
Sent: Wednesday, January 18, 2012 10:43
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Drive and Path Definition

You did the itdt against rmt0, but you are defining the path to rmt11. I'm
assuming this is happening for all drive and that discrepancy doesn't
actually mean anything.

The problem is most likely with the library device smcX, not the drives.
- I can't remember the commands, but can you probe the library device with
itdt?  I think its smc0 with atape.
- is Drive 11 actually in library kvtl1p1?
- is the path to the library device for kvtl1p1 is already defined and
online?
- Was this drive a recent addition to the library?
- If so, was the TSM instance restarted since it was added? (restarting
the instance will repprobe the library for new elements, drives/slots,
etc)
- Are all drives in the library not working or only drive 11?



Regards,
Shawn

Shawn Drew





Internet
mctai...@carilionclinic.org

Sent by: ADSM-L@VM.MARIST.EDU
01/18/2012 09:41 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] Drive and Path Definition






Hello.

I have a PMR on this, but not making much progress on it so thought I
would send this out on the User List to see if anyone else encountered
this issue and can suggest a fix.

Here's what I have:

TSM 6.2.3.100
AIX 7.1 (oslevel: 7100-00-04-1140)
IBM FC 5729 8-Gbps FC adapters

SAN Switch: IBM SAN-768A (Brocade DCX)

Atape 12.1.5.0
Sepaton VTL emulating 3584L22 and 3592 tape drives
SANDISCOVERY ON

We define a tape drive on the VTL and present it to the TSM server.  AIX
discovers the tape drive and I can use itdt (tapeutil) to query the drive.
 For example...

./itdt -f /dev/rmt0 inquiry
Issuing std inquiry...
Inquiry Data,  Length 96
0 1  2 3  4 5  6 7  8 9  A B  C D  E F   0123456789ABCDEF
 - 0180 0302 3300 1130 4942 4D20 2020 2020  [.�..3..0IBM ]
0010 - 3033 3539 324A 3141 2020 2020 2020 2020  [03592J1A]
0020 - 3035 3039 3638 3030 5347 3131 3032 3330  [05096800SG110230]
0030 - 3031 2030 0500 0181      [01 0...�]
0040 -          []
0050 -          []

Exit with code: 0
./itdt -f /dev/rmt0 inquiry 80
Issuing inquiry for page 0x80...
Inquiry Page 0x80,  Length 14
0 1  2 3  4 5  6 7  8 9  A B  C D  E F   0123456789ABCDEF
 - 0180 000A 5347 3131 3032 3330 3031   [.�..SG11023001  ]

Exit with code: 0

I log into TSM and define the drive.

01/17/12   11:55:36  ANR2017I Administrator ADMIN issued command:
DEFINE DRIVE
  kvtl1p1 rmt11 serial=autod elem=autod  (SESSION:
15)
01/17/12   11:55:36  ANR8404I Drive RMT11 defined in library KVTL1P1.
(SESSION:
  15)

Then I try to define the path.

01/17/12   11:56:16  ANR2017I Administrator ADMIN issued command:
DEFINE PATH
  tsmprd01 rmt11 srct=server destt=drive autod=yes
  devi=/dev/rmt11 library=kvtl1p1 online=yes
(SESSION: 15)
01/17/12   11:56:16  ANR8972E DEFINE PATH: Unable to find the element
number
  for drive RMT11 in library KVTL1P1.  (SESSION:
15)
I stop and restart TSM and issue the same command.

01/17/12   12:00:00  ANR2017I Administrator ADMIN issued command:
DEFINE PATH
  tsmprd01 rmt11 srct=server destt=drive autod=yes
  devi=/dev/rmt11 library=kvtl1p1 online=yes
(SESSION: 1)
01/17/12   12:00:00  ANR8955I Drive RMT11 in library KVTL1P1 with
serial number
   is updated with the newly discovered serial
number
  SG11023012. (SESSION: 1)
01/17/12   12:00:00  ANR1720I A path from TSMPRD01 to KVTL1P1 RMT11
has been
  defined. (SESSION: 1)
Has anyone else seen this problem?  Any ideas?

TIA

Mahesh


Notice: The information and attachment(s) contained in this communication
are intended for the addressee only, and may be confidential and/or
legally privileged. If you have received this communication in error,
please contact the sender immediately, and delete this communication 

Re: Drive and Path Definition

2012-01-18 Thread Ehresman,David E.
What you describe sounds like normal behavior to me.  AIX can dynamically 
recognize new devices and can talk to them.  TSM Define Drive does not try to 
communicate with a device.  The Define Path does try to connect to the device 
but in my experience TSM has to be cycled before it will recognized newly 
defined devices.

David

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Tailor, Mahesh C.
Sent: Wednesday, January 18, 2012 9:41 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Drive and Path Definition

Hello.

I have a PMR on this, but not making much progress on it so thought I would 
send this out on the User List to see if anyone else encountered this issue and 
can suggest a fix.

Here's what I have:

TSM 6.2.3.100
AIX 7.1 (oslevel: 7100-00-04-1140)
IBM FC 5729 8-Gbps FC adapters

SAN Switch: IBM SAN-768A (Brocade DCX)

Atape 12.1.5.0
Sepaton VTL emulating 3584L22 and 3592 tape drives
SANDISCOVERY ON

We define a tape drive on the VTL and present it to the TSM server.  AIX 
discovers the tape drive and I can use itdt (tapeutil) to query the drive.  For 
example...

./itdt -f /dev/rmt0 inquiry
Issuing std inquiry...
Inquiry Data,  Length 96
0 1  2 3  4 5  6 7  8 9  A B  C D  E F   0123456789ABCDEF
 - 0180 0302 3300 1130 4942 4D20 2020 2020  [.�..3..0IBM ]
0010 - 3033 3539 324A 3141 2020 2020 2020 2020  [03592J1A]
0020 - 3035 3039 3638 3030 5347 3131 3032 3330  [05096800SG110230]
0030 - 3031 2030 0500 0181      [01 0...�]
0040 -          []
0050 -          []

Exit with code: 0
./itdt -f /dev/rmt0 inquiry 80
Issuing inquiry for page 0x80...
Inquiry Page 0x80,  Length 14
0 1  2 3  4 5  6 7  8 9  A B  C D  E F   0123456789ABCDEF
 - 0180 000A 5347 3131 3032 3330 3031   [.�..SG11023001  ]

Exit with code: 0

I log into TSM and define the drive.

01/17/12   11:55:36  ANR2017I Administrator ADMIN issued command: DEFINE 
DRIVE
  kvtl1p1 rmt11 serial=autod elem=autod  (SESSION: 15)
01/17/12   11:55:36  ANR8404I Drive RMT11 defined in library KVTL1P1. 
(SESSION:
  15)

Then I try to define the path.

01/17/12   11:56:16  ANR2017I Administrator ADMIN issued command: DEFINE 
PATH
  tsmprd01 rmt11 srct=server destt=drive autod=yes
  devi=/dev/rmt11 library=kvtl1p1 online=yes  (SESSION: 
15)
01/17/12   11:56:16  ANR8972E DEFINE PATH: Unable to find the element number
  for drive RMT11 in library KVTL1P1.  (SESSION: 15)
I stop and restart TSM and issue the same command.

01/17/12   12:00:00  ANR2017I Administrator ADMIN issued command: DEFINE 
PATH
  tsmprd01 rmt11 srct=server destt=drive autod=yes
  devi=/dev/rmt11 library=kvtl1p1 online=yes  (SESSION: 
1)
01/17/12   12:00:00  ANR8955I Drive RMT11 in library KVTL1P1 with serial 
number
   is updated with the newly discovered serial number
  SG11023012. (SESSION: 1)
01/17/12   12:00:00  ANR1720I A path from TSMPRD01 to KVTL1P1 RMT11 has been
  defined. (SESSION: 1)
Has anyone else seen this problem?  Any ideas?

TIA

Mahesh


Notice: The information and attachment(s) contained in this communication are 
intended for the addressee only, and may be confidential and/or legally 
privileged. If you have received this communication in error, please contact 
the sender immediately, and delete this communication from any computer or 
network system. Any interception, review, printing, copying, re-transmission, 
dissemination, or other use of, or taking of any action upon this information 
by persons or entities other than the intended recipient is strictly prohibited 
by law and may subject them to criminal or civil liability. Carilion Clinic 
shall not be liable for the improper and/or incomplete transmission of the 
information contained in this communication or for any delay in its receipt.


Re: Drive and Path Definition

2012-01-18 Thread Richard Rhodes

 In the past we've never had to restart TSM to add a new drive.  As
 long as the drive was discovered and available at the AIX layer, we
 could define the new drive.  Has this changed with v6.2.x?

It's my experience that any change to the library (adding slots or drives)
requires cycling TSM before it can access the new resource.

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.


Re: Re: Drive and Path Definition

2012-01-18 Thread David Bronder
Richard Rhodes wrote:

  In the past we've never had to restart TSM to add a new drive.  As
  long as the drive was discovered and available at the AIX layer, we
  could define the new drive.  Has this changed with v6.2.x?

 It's my experience that any change to the library (adding slots or drives)
 requires cycling TSM before it can access the new resource.

Seriously?  Is this behavior due to changes in TSM 6.x, or has it
always been this way for SCSI-style (smcX) libraries?

I've never had this issue with my 3494 library and any TSM version
from ADSM 2.1 through TSM 5.5.

If it's a 6.x change, it makes me nervous about the upgrade from 5.5.
If a SCSI library limitation, it makes me hesitant to give up my 3494
(looking at dedupe VTL appliances and/or newer physical libraries).
Getting TSM downtime is like pulling teeth, as our DBAs run log backups
for Oracle and MS-SQL servers almost continuously, 24x7.

--
Hello World.David Bronder - Systems Architect
Segmentation Fault  ITS-EI, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bron...@uiowa.edu


Re: Drive and Path Definition

2012-01-18 Thread Roger Deschner
I used to believe in all sorts of hokus-pokus in this regard, but I have
found that if you do things in an organized way in the correct order,
everything just works, without restarting dsmserv, on both TSM 5.5 and
6.2. See the TSM for AIX Administrator's Guide.

I recently moved a library from a simple configuration with one server,
to a Library Manager configuration with multiple server clients, which
involved a lot of undefining and redefining of paths and drives, and it
all just worked. The Library Manager is TSM 6.2, and it has a 5.5 client
and a 6.2 client. There were surprisingly few surprises.

Add the drive, run AIX cfgmgr, go into smit and add Tivoli Storage
Manager devices, define the drive and path in TSM, and it just works.
Pay attention to the fact that typically rmtN, mtN, and TSM driveN
device numbers will be different. Make sure the serial numbers in TSM Q
DRIVE F=D are correct.

Do things in the wrong order, and sometimes restarting dsmserv or even
AIX can make up for your disorganization, making it appear that those
restarts were necessary. In my experience, this is an area that has
become a lot more stable and predictable in recent releases of TSM 5.5
and 6.2.

Roger Deschner  University of Illinois at Chicago rog...@uic.edu
== You will finish your project ahead of schedule. ===
= (Best fortune-cookie fortune ever.) ==


On Wed, 18 Jan 2012, David Bronder wrote:

Richard Rhodes wrote:

  In the past we've never had to restart TSM to add a new drive.  As
  long as the drive was discovered and available at the AIX layer, we
  could define the new drive.  Has this changed with v6.2.x?

 It's my experience that any change to the library (adding slots or drives)
 requires cycling TSM before it can access the new resource.

Seriously?  Is this behavior due to changes in TSM 6.x, or has it
always been this way for SCSI-style (smcX) libraries?

I've never had this issue with my 3494 library and any TSM version
from ADSM 2.1 through TSM 5.5.

If it's a 6.x change, it makes me nervous about the upgrade from 5.5.
If a SCSI library limitation, it makes me hesitant to give up my 3494
(looking at dedupe VTL appliances and/or newer physical libraries).
Getting TSM downtime is like pulling teeth, as our DBAs run log backups
for Oracle and MS-SQL servers almost continuously, 24x7.

--
Hello World.David Bronder - Systems Architect
Segmentation Fault  ITS-EI, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bron...@uiowa.edu



Re: Drive and Path Definition

2012-01-18 Thread Prather, Wanda
I think the answer can be it depends, or yes it has always worked that way 
for SCSI libraries, or maybe, depending on exactly the situation.  I don't 
believe there is any difference between what happens in TSM 6.any and 5.5.

*   For 3494 libraries, TSM doesn't manage the slot locations, the 3494 
does.  TSM just tells the 3494 what cartridge it wants mounted in which drive, 
and the 3494 software is responsible for locating the cartridge via its 
on-board data base and moving it around.

*   TSM has a much more intimate relationship with SCSI libraries.  TSM has 
to actually know the slot locations and pass them to the library when it wants 
something done.   What it sends down the wire to the robot is the equivalent of 
go to slot 1428, grab cartridge, move to the drive in position 256, load 
cartridge.  It maintains the cartridge slot locations and drive positions 
(called element numbers) in the TSM DB.  You can also see them if you look at 
your devconfig file.  They get updated by checkin/checkout, or a library audit.

   TSM gets the available slot locations from the SCSI library at start up 
time, when you see the library bubba is ready for operations message in the 
activity log.  Even the mid-sized libraries like the TS3310/ADIC 500/Quantum 
I500 come with different configurations with different numbers of 
drawers/frames/drives/slots/IO ports, so the only way TSM can know what's 
actually out there, and what drive is in which physical position, is to ask the 
library.

Thus, if you are deleting/defining drives and paths, or replacing a failed 
drive - things that change just from TSM's point of view - you can  do that in 
a SCSI library without restarting TSM.  (Although in a Windows environment, if 
you are recabling stuff it also isn't too hard to get yourself in a situation 
where you have to reboot Windows to clear a hung or error condition on the bus, 
which really isn't TSM's fault but it gets restarted anyway.  Oh, for the days 
I had an AIX TSM server...)

But if you make a change to the actual hardware configuration of the tape 
library ( adding a new frame/drawer, licensed slots, adding a physically new  
drive in a library position where there was no drive before), certainly 
anything that requires a library reboot/rescan, you have to restart TSM so it 
will pick up the new config from the robot's point of view.

*   Change what the 3494 sees - no restart
*   Change what TSM and the OS see - no restart needed from TSM's point of 
view
*   Change what the SCSI tape robot sees inside the library - gotta restart 
TSM

There are other situations that vary a lot.  You can usually update drive 
firmware without a TSM restart.  You can sometimes update library firmware 
without a TSM restart, but if you have a problem the first thing you'll need to 
try is a TSM restart (and a host reboot on Windows) so just plan on it anyway.  
There are some libraries - the TS3500 I know in particular - that will let you 
force a drive reset from the library panel, without a host/TSM restart.

I'm sure there are other cases I've missed.
But this may help explain why you get different answers, depending on the 
context and the situation.





-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Roger 
Deschner
Sent: Thursday, January 19, 2012 1:38 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Drive and Path Definition

I used to believe in all sorts of hokus-pokus in this regard, but I have found 
that if you do things in an organized way in the correct order, everything just 
works, without restarting dsmserv, on both TSM 5.5 and 6.2. See the TSM for AIX 
Administrator's Guide.

I recently moved a library from a simple configuration with one server, to a 
Library Manager configuration with multiple server clients, which involved a 
lot of undefining and redefining of paths and drives, and it all just worked. 
The Library Manager is TSM 6.2, and it has a 5.5 client and a 6.2 client. There 
were surprisingly few surprises.

Add the drive, run AIX cfgmgr, go into smit and add Tivoli Storage Manager 
devices, define the drive and path in TSM, and it just works.
Pay attention to the fact that typically rmtN, mtN, and TSM driveN device 
numbers will be different. Make sure the serial numbers in TSM Q DRIVE F=D are 
correct.

Do things in the wrong order, and sometimes restarting dsmserv or even AIX can 
make up for your disorganization, making it appear that those restarts were 
necessary. In my experience, this is an area that has become a lot more stable 
and predictable in recent releases of TSM 5.5 and 6.2.

Roger Deschner  University of Illinois at Chicago 
rog...@uic.edumailto:rog...@uic.edu
== You will finish your project ahead of schedule. === 
= (Best fortune-cookie fortune ever.) ==


On Wed, 18 Jan 2012, David Bronder wrote:

Richard Rhodes wrote:

  In the past we've never