----- 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.