ADSM-L

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

2012-04-24 10:28:48
Subject: Re: [ADSM-L] V5.5 -> V6.2.3 Move - Chicken-and-Egg Question
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 24 Apr 2012 10:25:30 -0400
Chavdar,

Thank you for this important info.  I was not aware of this
situation/"problem".  I will rename the server BEFORE I install DB2/V6.  I
will save your procedure in case this comes up in the future.


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 http://infosecurity.vcu.edu/phishing.html



From:   Chavdar Cholev <chavdar.cholev AT GMAIL DOT COM>
To:     ADSM-L AT VM.MARIST DOT EDU
Date:   04/24/2012 10:08 AM
Subject:        Re: [ADSM-L] V5.5 -> V6.2.3 Move - Chicken-and-Egg
Question
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



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 <zforray AT vcu DOT 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
> 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 http://infosecurity.vcu.edu/phishing.html