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
DB2_ADMINGROUP=TSMHQ1\DB2ADMNS
C:\Program Files\Tivoli\TSM\db2\BIN>db2set
DB2_USERSGROUP=TSMHQ1\DB2USERS
14 Check settings ==> db2set -all
15 Execute
C:\Program Files\Tivoli\TSM\db2\BIN>db2set -g
DB2_EXTSECURITY=YES
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
Chavdar
On Mon, Apr 23, 2012 at 6:31 PM, Zoltan Forray/AC/VCU <zfor...@vcu.edu> wrote:
> 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 5.5.5.2 - 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
> zfor...@vcu.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 http://infosecurity.vcu.edu/phishing.html
