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.