The UPGRADEDB parameter causes the server to update some of the database
meta-data.  It does not have to convert any database data.  Because of
this, it is not sensitive to the size of the actual database and should
take seconds to execute regardless of the database size.

-----------------------------------------------------------------------------------------------------------
Mike Kaczmarski
Mike Kaczmarski
Product Architecture
Tivoli Systems: Storage Software
mkaczmar AT tivoli DOT com



Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>@VM.MARIST.EDU> on 06/01/2001
05:39:58 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:  What, if anything, is wrong with this scenario....


I need to move our OS/390 ADSM to TSM 4.1 (especially since we called IBM
support for help with a client problem and they pretty much told us to come
back when we are running on a supported release of TSM, and not before
!!!).

I have tested running an UPGRADEDB on a small test ADSM. As before, it only
took a few seconds (never has taken very long ????).

Now I need to run it on my production, 14GB DB.

Management wants to know how long it will take. Since I can't answer that,
they want me to test it by replicating my ADSM DB in a test environment and
then doing the UPGRADEDB against the copy of the production DB.

This is what I am attempting to do. Can someone tell me if this will/won't
work, why, and how to get around the issues, if possible ?

The objective is to take the current TEST ADSM and rebuild it's
configuration to use a copy of the production DB and then run a UPGRADEDB
on it.
Note, the TEST ADSM is running on a TEST LPAR.

I have created and formatted 7-new DB volume/data sets.
I have performed a BACKUP DEVCONFIG and edited the TEST OPTIONS file to
include a DEVCONFIG statement pointing to this file.
I have update the DISKLOG file to include the names of the 7-new DB
volumes/data sets (and removed the TEST DB it was using !).
** I am going to perform a RESTORE DB pointing to the TEST DISKLOG and
OPTIONS and point to a current backup of the production DB, using the
following JCL snippet:
//RESTORDB  EXEC PGM=DSMSERV,DYNAMNBR=300,
//          PARM='/RESTORE DB DEV=DBBACKUP VOL=FILE:DD:TAPES'

Anything wrong with this approach ?

My biggest concern is that it will attempt to access the production ADSM
files (this is a sysplex) and hurt them !

===========================
Zoltan Forray
Virginia Commonwealth University
University Computing Center