ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

CA Dispatch bundle recovery process is slow

book

Article ID: 187591

calendar_today

Updated On:

Products

Dispatch Output Mgmt

Issue/Introduction

During CA Dispatch startup, bundle recovery processing is taking 30 or more minutes on a daily basis.

 

Example of CA Dispatch bundle recovery messages being received in the CA Dispatch logs during startup: 

2020.087 17:06:07 DC970052 Recovery Termination Manager Started                

2020.087 17:06:12 DC970170 Storage Pool Data Space Created and Initialized     

2020.087 17:06:13 DC970056 Bundle Structure Restore Starting                   

2020.087 17:06:13 DC970057 Restoring from Bundle Recovery Dataset              

2020.087 17:52:16 DC970059 Bundle Structure Restore Successful                 

2020.087 17:52:16 DC970041 Main Region Initialization Complete...

 

What if anything can be done to prevent these startup delays due to bundle recovery processing?

Cause

The Bundl Recovery process is:

In the event that the product shuts down or abnormally terminates and logical bundles still exist, the bundle backup and recovery function writes the logical bundle structures to a dynamically allocated physically sequential file. Upon restarting the product, the function recreates the bundle structures and deletes the recovery files.

- The delay that a customer sees at startup, due to the Bundl Recovery process, is a normal condition. The time it takes to complete the process is based on the number and complexity of active/open bundles that you have in CA Dispatch at the time the product is shutdown/terminated.

Environment

Release : 11.6 or 11.7

Component : CA Dispatch

Resolution

If your goal is to limit the time it takes to complete the Bundl Recover process, then the way to do that would be for you to have CA Dispatch automatically close and release all of the active open bundles that  it has BEFORE you issue the STOPCADS command to bring it down.

** This can be accomplished by implementing better bundle management control processes. Which is in essence, making adjustments to a MAILDROP's maximum "TIME/PAGES" values or adding a "RELEASE TOD" value to a MAILDROP, on the CA Dispatch "VSGMU130 - Maildrop Sysgen Screen". (Option 9.3 from the main menu).

     *NOTE*  - That in order for the bundles to actually be written out to JES, your CA Dispatch "RPO" subtask must be active.

- To obtain a listing that will show you what bundle management values you currently have defined for your maildrops, you can run the DSEXCULP job with the MEMBER symbolic set as MEMBER=DSCULP04. This will produce the Report Distribution Maildrop Listing. If this listing does not show you all of the individual MAILDROP defined values, then CA Dispatch will use the DEFAULT "Max Time" and "Max Page" values, which are defined on the "VSGMU110 - Sysgen Control Information Screen". (Option 9.1 from the main menu).

- If it turns out that you have to make bundle management adjustments to a LOT of your MAILDROPS, you can use the "Database LOAD/UNLOAD" batch utility (DSEXLOD or DSEXLODL) to make those adjustments. The bundle management values defined for a MAILDROP on the VSGMU130 screen are available to this utility in the form of a TYPE 5 record. You can find additional information and details on executing this utility in your Dispatch System Programmers guide - Chapter 12: Using the Database Update Utility.