The procedure to increase the size of a database file is a 7 step process that not only increases the size of the file but also updates the Dispatch DICTIONARY and the Dispatch LOAD LIBRARY with the new database file size. The purpose of this document is to provide an OUTLINE of the migration process, to point out some very specific considerations, and to provide additional information so our customers can avoid some of the common "gotcha's" when increasing the size of the CA Dispatch database files.
You will find most of the information that you need as well as the step by step instructions for increasing the size of your database file in the Dispatch 11.7 System Programmers guide, chapter 6, entitled MIGRATING THE REPORT DISTRIBUTION DATABASE.
The procedure to increase the size of a database file is a 7 step process that not only increases the size of the file but also updates both the Dispatch DICTIONARY and the Dispatch LOAD LIBRARY with the new database file size. The FILE, DICTIONARY and LOADLIB all have to be in sync.
You will want to read from the beginning of Chapter 6 right up through to the end of chapter 6 where we document the remaining migration steps 3 through 7.
- To assist you with identifying the current size of your existing database files so that you can determine how much larger you want to make them, please refer to the following Knowledge Document:
Document ID: 63218 - "How can I determine the size (number of blocks allocated) of our CA-Dispatch database files?"
- To further enforce the information provided in this knowledge article, please also refer to the following Knowledge Document:
Document ID: 29096 - "Two important steps to migrating to a bigger database."
The basic procedure outline and additional considerations for increasing the size of a database file are as follows:
* With Dispatch down clean, make sure you have good backups of BOTH the database files and the load library. We would suggest using a pack backup utility such as DSFSS or FDR since they work based on a high level qualifier and make selectively backing up and restoring specific files easier.
* Execute the appropriate DSEX??X job. If you have ANY problem during the execution of the DSEX??X job, you MUST RESTORE the DICTDB, DLODDB, DMSGDB and affected database file (AR, OV, RD, etc…). You must also RESTORE the LOAD LIBRARY. You will also need to manually DELETE the renamed "hlq.OLD" FILE in order to avoid duplicate DSN errors upon rerunning the job. Once you have RESTORED the DB files and LOADLIB and deleted the "hlq.OLD" file, resubmit the DSEX??X job again and let it execute from the beginning.
* After successful execution of the DSEX??X job, you must execute the DSEXDBEX job.
* If you have OLVO regions you need to execute the DSEXVDM and DSEXVST jobs. Execution of these two jobs is "ONLY REQUIRED" if you have OLVO regions installed.
* Run NEW backups of both the database files and the LOADLIB to capture everything at the new size.
* Update the additional Dispatch utility jobs JCL (See STEP 7) symbolics to reflect the new database file size.
* Run another DSEXSTAT job (as mentioned in Article Id: 63218) to verify the size increase to the specific database area was successful and that the utilization percentage went down.
Other things you should be aware of are:
A. The most common problem encountered when running the DSEX??X jobs are SPACE related problems. Before running the DSEX??X migration job, consider increasing "ALL" of the temporary "SPACE=" allocation parameters, including those for the //SORTWORK DD statements, in the the appropriate CADS??X procs. Since this is only temporary space that will be freed upon the job ending, allocate space in CYLS and be as generous as possible. On average there are about 44 occurrences of the "SPACE=" parameters within each of the CADS??X procs.
B. Make sure that you have STEPLIB statements in the proc. that point to the LOADLIB you are running the migration against. Since this job creates and punches members into the LOADLIB, you cannot run it against a LINKLISTED library.
C. Because the job creates NEW members during execution, if you perform a JCLCHECK or similar scan against the job before you run it, the scan will result in messages indicating that modules/members are MISSING from the libraries. These warnings can be ignored.
D. Make sure that after a successful DSEX??X job execution, you run STEPS 4 thru 7 of the migration process documented at the end of chapter 6 (i.e. Job DSEXDBEX, new backups and updating the utility jobs JCL are required). As previously indicated, STEP 5 (Jobs DSEXVDM and DSEXVST) is required only if you have online viewing only regions installed.
E. Again, CRITICAL!! If any problems are encountered when running the DSEX??X job, DO NOT attempt to RESTART the job without first restoring BOTH the database files and the load library and deleting the "hlq.OLD" file.