ADSM-L

TSM 4.2.2.12 and 3590H1A drives Solaris

2003-09-02 09:55:13
Subject: TSM 4.2.2.12 and 3590H1A drives Solaris
From: Farren Minns <fminns AT WILEY.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 2 Sep 2003 14:52:42 +0100
Hi TSMers

Ok, I have been asking questions about this recently and am trying to work
out what the best order of actions would be. Firstly, the TSM set-up is as
follows :-

TSM Server 4.2.2.12 running on a Solaris 2.7 server. This is connected to
one IBM 3494 library containing two 3590B1A tape drives. We have an upgrade
of our tape drives planned to go from B1A to H1A format drives.

Now, I have looked on the IBM site and can see that H1A drives are
supported for the TSM server 4.2.2 (though I see nothing in the Server
README file for 4.2.2), release and upwards. However, I am also aware that
the 4.2 version of TSM is now out of support. I understand that I will
still be able to get help, but maybe not enough in the event of a big
disaster, and here is my dilemma.

Do I ?

a) Upgrade the drives first? The reason this is very important indeed is
that we are about to run out of free slots in the library. From what I
gather, the drives will work with the 4.2.2 version of TSM (I can't really
understand why it matters to TSM in the first place as it's the drives that
take care of compression etc). I understand that this will mean upgrading
the IBMtape device driver (not sure how easy this is or if there are
possible pitfalls, especially as we are running Solaris 2.7).

Also, let's say we upgrade the drives and then find that we can't get TSM
to see/utilize them properly. This would put us in the position of having
to quickly upgrade the TSM server from 4.2.2 to 5.1.6 etc. Now imagine if
we had a problem here! We wouldn't have any available tape drives to work
with in the event of recovering the server. This would be very bad me
thinks.

However, if anyone out there can tell me that upgrading the drives and
having them attached to a Solaris 2.7 OS with TSM 4.2.2.12 is a doddle and
should cause any problems, I may just go ahead anyway. I guess I'm asking
if anyone out there has had any real problems within this kind of thing.

b) Upgrade the TSM server from 4.2.2.12 to 5.1.6+ first. This may be the
most simple solution to make sure we are covered in the event of a big
problem during the tape upgrade process. But, we are so short on tape slots
in the lib that I would hate to have to take this route if the tape upgrade
process is a bit of a doddle.

The plan for the tape upgrade is as follow.

a) Mark all tapes in the on site TAPEPOOL as read-only.
b) Create a new sequential media primary storage pool for use with new H
formatted tapes and point our diskpool migration to migrate to this pool
instead of the current pool. Maybe even create a new media class for the H
formatted tapes.

This, along with some manual move data processes for eventually move all
data from the old 3590B formatted volumes to the new 3590H ones.

So any advice on what would be best here. Should I bite the bullet and go
for the tape upgrades as it should be easy. Or should I hold off, get the
TSM server upgraded first and take it from there?

I'm sorry this is such a long email, but any advice any of you can give
will be very helpful indeed.

All the best and thanks again

Farren Minns - TSM and Solaris System Admin
*****************************************************************************

This email transmission is confidential and intended for the person or
organisation it is addressed to. If you are not the intended recipient, you
must not copy, distribute, or disseminate the information, open any
attachment, or take any action in reliance of it. If you have received this
message in error please notify the sender.

Any views expressed in this message are those of the individual sender,
except where the sender specifically states otherwise.

Although this email has been scanned for viruses you should rely on your
own virus check, as the sender takes no responsibility for any damage
arising out of any bug or virus infection.
*****************************************************************************

<Prev in Thread] Current Thread [Next in Thread>