----- Shannon Bach wrote: -----

>We recently received the okay to move our current TSM Server off the
>MVS/ZOS mainframe to a Windows server. Along with this, we will be
>getting an IBM 3584 Library with (6)TS1120 Jaguar tape drives ...this
>will be exclusive to TSM and may be located at an offsite location
>(still waiting for decision from above). And I'll have 800 GB's of
>disk from an IBM DS6800. I'll have to export/move the current date
>from a 3594 Magstar ATL and some older archived data on a VTL to the
>Jaguar. That will consist of moving date from 3590e carts with
>around 20 GB's of data to cartridges with a capacity of 300 GB's.
>
>Having always been a "mainframer" :~)... I am wondering if anyone
>else here has gone through this transition and wouldn't mind passing
>on some useful tips. I have been browsing on the Internet for a
>redbook or white paper... even a checklist of considerations, but
>haven't found much as yet.

We moved TSM from z/OS to mainframe Linux, which raises most of the
same issues.

Most of our backups were moved by doing full backups to the new
server and keeping the old server around until all inactive backups
aged off. This was usually faster than export/import. We used
export/import for archives (because they had much longer retention
periods than inactive backups) and for backups from a few clients
that no longer existed.

In cases where export/import is necessary, server to server
export/import is much more convenient than tape import/export.
The documentation indicates that the server to server facility
was introduced with the 5.2 server code. In point of fact, it
is also available under later 5.1 maintenance levels.

What kind of automation facilities are you using to manage TSM
server operations? Depending on the answer, you may have a
significant software porting effort ahead of you.

Tape handling is likely to be a significant culture shock. The
z/OS implementation of TSM relies heavily on the host operating
system for tape management facilities. The other implementations
are much more dependent on facilities internal to TSM. If you
move tapes between the ATL and an offsite vault you will also
need to figure out how to integrate the new library into your
operations procedures.

If you have DR procedures that involve rebuilding the TSM server
on replacement hardware you will need to arrange for a new set
of replacement hardware.

I am guessing that the new server will have a different IP
address and DNS name than the old one. If you have a large
number of clients managing the necessary client configuration
changes will be a significant undertaking. We had a couple of
hundred clients when we migrated. I wrote a script to generate
customized instructions for each client. It took into account
the following dichotomies:

1.Windows versus Unix/Linux
2.AIX versus other Unix/Linux (different location for dsm.sys)
3.DMZ network versus secure network (numeric server address for
DMZ clients)
4.Able to run a full backup in one day versus needing two or
more days (the later situation requires a scheduler process for
each TSM server)

In retrospect, I wish I had set up a spreadsheet to keep track of
client characteristics and migration dates in a more systematic
way.