We are receiving a SB37 abend during shutdown of CA Dispatch.
search cancel

We are receiving a SB37 abend during shutdown of CA Dispatch.


Article ID: 11086


Updated On:


Dispatch Output Mgmt


After issuing a STOPCADS command to bring down CA Dispatch, a review of the logs is showing that you are receiving a SB37 abend on a dataset with a low level qualifier of either ".BRVY" or ".CNTL". 

What causes these SB37 abends and how can we prevent them?




These ".BRVY" or ".CNTL" datasets are dynamically allocated by CA Dispatch during shutdown as part of CA Dispatch's BUNDLE RECOVERY process. We store control information in these datasets that lets us know if we need to rebuild print bundles that were still actively being worked on at the time the STOPCADS command was issued.

The amount of storage space we need is pre-determined in the CA Dispatch code. Since these files are dynamically allocated, there is no place for a client to specify any type of space allocation parameters for dictating the amount of storage we will need to use.

The SB37 at shutdown occurs when the STATUS file (.RDS) is full or very close to being full. This file contains historical records only. The status records are those that you see when you select option 4 from the main menu. When the file fills, the method for recovery is to bring CA Dispatch down and execute the DSEXSFIX job out of the CADSJCL library to initialize the .RDS file. The DSEXSFIX job will run in 5 minutes as opposed to trying to run the DSEXPSST or DSEXPURG job to delete the expired entries after the status file is already full. Clients simply don't have a maintenance window large enough for the DSEXPSST or DSEXPURG jobs to complete and will end up having to CANCEL the cleanup process and execute DSEXSFIX anyway.

If the STATUS information is something that you need, you can run the CADSJCL library job DSEXCULP with the 'member' symbolic set to MEMBER=DSCULP06. This will produce a hard copy listing of all of the status information that can be saved and used for reference in case someone needs to see these historical status records. Execution of the DSEXSFIX job deletes all records out of the STATUS file.

As a follow up, you need to keep this STATUS file clean. You should be running a DSEXPSST or DSEXPURG job as part of your nightly batch cleanup processing to delete the expired entries out of the STATUS file.

Review your nightly schedule and see which job you are running. Then determine which control member (set by the MEMBER= symbolic) is being pulled in from the CADSOPTN library for that job. Make sure that your control member has a valid PURGE date range. Typically, the "TO" date would be set to 12312059 indicating that all records in the STATUS file up until the year 2059 will be eligible for deletion if their retention has expired.