As was suggested by another person on the list server, I recommend that you
perform a "dsmserv format" operation on your test server before performing
the restore operation.  This will initialize your new database and recovery
log data sets and write the information to the new disk log (yes, please
point to the new disk log).

The restore operation will not perform I/O to your disk data sets or tape
storage pools, but after you have performed your UPGRADEDB, the test server
will attempt to access the storage pool data sets.  If the production
server has them open/allocated, the access will fail and nothing bad will
happen.  If the test server does not move data or backup/archive operations
that store data on the server, you should be OK, - not damage will be done.
Please let me know if you have any other questions.

-----------------------------------------------------------------------------------------------------------
Mike Kaczmarski
Mike Kaczmarski
Product Architecture
Tivoli Systems: Storage Software
(520)799-2318
mkaczmar AT tivoli DOT com



Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>@VM.MARIST.EDU> on 06/01/2001
09:17:42 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:  Re: What, if anything, is wrong with this scenario....


Thank you for the explaination.  I did not think it was an issue.

However, my management still wants me to try the restore scenario, just to
see if we can do it, since as they say, if you have never restored from a
backup, how do you know the backup is any good ?

So, will what I suggested, work ?

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



                    Mike Kaczmarski
                    <Michael_Kaczmarski@T        To:
ADSM-L AT VM.MARIST DOT EDU
                    IVOLI.COM>                   cc:
                    Sent by: "ADSM: Dist         Subject:     Re: What, if
anything, is wrong with this scenario....
                    Stor Manager"
                    <ADSM-L AT VM.MARIST DOT EDU
                    >


                    06/01/2001 09:13 AM
                    Please respond to
                    "ADSM: Dist Stor
                    Manager"






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