Renaming database files during CA Datacom/AD upgrade
search cancel

Renaming database files during CA Datacom/AD upgrade

book

Article ID: 115975

calendar_today

Updated On:

Products

Datacom DATACOM - AD CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services CA ECOMETER SERVER COMPONENT FOC Easytrieve Report Generator for Common Services INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA ON DEMAND PORTAL CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware

Issue/Introduction

In the current environment, we have database files and operational files with the version number in the dataset names. In implementing the upgraded version of CA Datacom/AD, we decided we would eliminate the version number. The new installation steps allowed me to create new files with my desired names, and now my question is how to get the current application data from the old MUF into new files.

The CA Datacom/AD database file names are stored in the CXX (Database catalog) for each MUF, and are carried along to the new version as part of the normal upgrade process. Likewise, in the Active Upgrade process, the same CXX and files are continued, and no new files are created, so the existing CXX will have the same existing names.

Environment

Release: DATABB00200-14.0-Datacom/AD
Component:

Resolution

Here is the recommended process to create new database files with the new filenames. This approach assumes that the upgrade tasks have been completed by running the "New Installation" jobs to create a new MUF that is distinct from the old MUF.
  • 1. Shut down the application that is using the databases to be migrated to the new version.
  • 2. Run a job to take a backup of the current application database. For example, with CA 11, you would run the CA 11 SAMPJCL member (AL7BKUP).
  • 3. Prevent inadvertent access to the "old" version database:
    • 3.a If this is the only application in this MUF, shut down the "old" MUF.
    • 3.b If there are multiple applications using this MUF, run a DBUTLTY job (like AD14CXXR) against the "old" MUF, with this input:
//SYSIN    DD  *
  ACCESS  DBID=601,STATUS=OFF,USERS=FAIL  (CA 11, for example)
/*
  • 4. Start the "new" MUF if it is not already running.
  • 5. Run an application job to define the database structure to the Datadictionary. For example, with CA 11, run CA 11 SAMPJCL member (AL7AD1). 
  • 6. Run an application job to allocate and initialize the new database files with the new names. You will want to be sure the allocations are at least as large as what is currently in use, or you can resize them as needed. For example, with CA 11, run CA 11 SAMPJCL member (AL7AD2). Note that for some applications, this step will be combined with the previous step.
  • 7. Run a job to load the data from the earlier backup into the new version database. For example, with CA 11, run CA 11 SAMPJCL member (AL7LD1) to load the data
  • 8. Create a new JCL member for the application, using the new CA Datacom/AD version loadlibs in the STEPLIB.
  • 9. Start the application with the new loadlibs and then test and use the application as desired.
Falling back to the old version is easy if you did not make any database updates or if you do not need to keep any updates made during this test phase. In this case, you would follow this process:
  • 1. Shut down the application that is using the "new" version loadlib, 
  • 2. Change the STEPLIB in the application JCL to the "old" MUF loadlibs (if using a single JCL member)
  • 3. Allow access to the database in the "old" MUF:
    • 3.a Start the "old" version MUF if it was shut down, or
    • 3.b Run a DBUTLTY job like the one above with this input:
//SYSIN    DD  *
  ACCESS  DBID=601,STATUS=WRITE  (CA 11, for example)
/*
  • Start the application as usual.

If you made changes to data in the database that you want to keep - for example after running several days - you would need to do the following process similar to the first process above, making sure to use the correct loadlibs and the correct MUF:
  • 1. Shut down the application that is using the databases to be reverted to the old version.
  • 2. Run a job to take a backup of the application database in the "new" MUF. For example, with CA 11, you would run the CA 11 SAMPJCL member (AL7BKUP), using the "new" version loadlibs.
  • 3. Prevent access to the database in the "new" version MUF:
    • 3a. If this is the only application in this MUF, shut down the "new" MUF.
    • 3b. If there are multiple applications active and using this MUF, run a DBUTLTY job (like AD14CXXR) against the "new" MUF, with this input:
//SYSIN    DD  *
  ACCESS  DBID=601,STATUS=OFF,USERS=FAIL  (CA 11, for example)
/*
  • 4. Start the "old" MUF if it is not already running.
  • 5. Run a job to load the "new" version data from the earlier backup into the "old" version database. For example, with CA 11, run CA 11 SAMPJCL member (AL7LD1) to load the data.
  • 6. If using a single JCL member for the application, change the STEPLIB to reflect the "old" CA Datacom /AD version .
  • 7. Start the application with the "old" loadlibs and then test and use the application as desired.
At a future time, if you will migrate once more to the "new" version, the same steps above can be followed as needed.
 

Additional Information

For more information about the ACCESS command, please refer to the DBUTLTY documentation for the ACCESS function.

For information about the backup and the load processing, please refer to the DBUTLTY documentation for the BACKUP function or the LOAD function as appropriate.

As always, please contact CA Technologies support for CA Datacom if you have further questions.