Re: [ADSM-L] V5.5 -> V6.2.3 Move - Chicken-and-Egg Question

2012-04-24 09:33:12
Subject: Re: [ADSM-L] V5.5 -> V6.2.3 Move - Chicken-and-Egg Question
From: Chavdar Cholev <chavdar.cholev AT GMAIL DOT COM>
Date: Tue, 24 Apr 2012 16:31:13 +0300
Hi Zoltan
If you change the hostname of the TSM after you install TSM 6 (DB2)
there is an issue  ...
here is steps how to fix it, if you REALLY need to change the hostname
of TSM server AFTER installation of TSM v6.x
1       disable client sessions
2       Backup TSM DB type=full
3       Halt TSM server
4       Set TSM service to maunal
5       Stop DB2 instance
6       Stop DB2 admin server
7       Open DB2 command prompt and execure:
                  db2set -g DB2SYSTEM=<new_host_name>
                  db2set -g DB2_EXTSECURITY=NO << switch back after reboot
8       Execute db2set -all to check settings
9       Change Windows system name to <new_host_name>
10      Reboot Server
11      Stop DB2 instance
12      Stop DB2 admin server
13      Execute:
                 C:\Program Files\Tivoli\TSM\db2\BIN>db2set
                 C:\Program Files\Tivoli\TSM\db2\BIN>db2set
14      Check settings ==> db2set -all
15      Execute
                  C:\Program Files\Tivoli\TSM\db2\BIN>db2set -g 
16      Reboot Server
17      Start TSM server
18      Change TSM service to authomatic
19      Edit dsm.opt file to reflect new hostname
20      Enabel sessions ==> enable ses

Best Regards

On Mon, Apr 23, 2012 at 6:31 PM, Zoltan Forray/AC/VCU <zforray AT vcu DOT edu> 
> I am having difficulty reconciling which order to do what based on
> documentation that says not to do it the way I have/need to do it.  I am
> getting ready to do a complete migration from an old 5.5 server (Linux) to
> a brand new box (both hardware and OS).
> I need to restore the 5.5 DB, volhist, devconfig and dsmserv.opt to the
> new box so I can do the conversion to 6.2.3.
> Problem is this.............the DB backup will be on an offsite TSM
> server, so server-to-server communications is required.
> To establish the server-to-server connection from the brand new 5.5
> install and the offsite backup server, I need to bring up the new, virgin
> 5.5 instance and do an "DEFINE SERVER ....  FORCESYNC=YES".
> The Administrator Guide section on "Recovering Your Server Using Database
> Backups - Restoring a Database to a Point-In-Time" says that after
> formatting the log and database files and BEFORE the "dsmserv restore":
> "Attention: Do not start the server until after you restore the database
> (the next step). Starting the server before the restore would destroy any
> existing volume history files."
> But since I have to start the new server to define the connection so I can
> restore the database........  Or am I simply reading this wrong and they
> are assuming the volhist on the machine I am restoring to has the original
> volhist (which it wouldn't, at this point).
> So, should I simply ignore this and restore the DB and then replace the
> volhist/devconfig/dsmserv.opt files on the restored server with the
> originals from the server I am replacing/upgrading after I restore the DB
> and before performing the upgrade?
> As you can tell, this is my first total server upgrade/replacement, so I
> am getting anxious about the details/processes/steps.
> My current steps are:
> Original Server:
> 1.  Disable client sessions, stop all admin schedules
> 2.  Empty and delete ALL disk volumes
> 3.  Backup DB, volhist, devconfig, dsmserv.opt  and HALT server
> New Server:
> 1.  Install - define/format DB volumes
> 2.  Bring up server and define connection to offsite server with DB backup
> 3.  Restore DB
> 4.  Replace volhist, devconfig, dsmserv.opt from backups of original
> server
> 5.  Install 6.2.3
> 6.  Run /opt/tivoli/tsm/server/bin/dsmupgdx to prepare, convert and insert
> 5.5 DB into 6.2.3 instance
> 7.  Change hostname and IP addresses to that of old 5.5 server
> 8.  Bring up 6.2.3 - redefine disk storage volumes - update server -
> forceresync other, library manager servers - update paths
> Thoughts, suggestions, ideas, corrections?
> Zoltan Forray
> TSM Software & Hardware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> zforray AT vcu DOT edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit