Dealing with DB00110W FORCED SPILL, DB00109W BACKOUT... WAITING TO COMPLETE messages and a WAIT E/C ... ROLBK Status

book

Article ID: 35284

calendar_today

Updated On:

Products

CA Datacom - DB CA Datacom CA Datacom - AD CA Datacom - Server CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA Datacom/AD CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware

Issue/Introduction

Introduction

Some long-running jobs with many add, update or delete maintenance transactions can cause a log file (LXX) to fill up. In the event the LOG reaches 100% full, or the value of the MUF Startup Option LOGSPILL “d” value is reached, the older Log file entries are “Force Spilled” to the Recovery File (RXX), and a message is issued in the MUF log:
DB00110W - FORCED SPILL  JOB-jjjjjjjj NUMBER-nnnnn  TSN-xxxxxxxx

When using the recommended default setting of “RXXROLLBACK YES” in the MUF Startup Options, a situation could arise where this long-running job fails and needs to rollback to undo the changes. When the rollback encounters a forced spill, a message is written to the MUF log and displayed on the console:
DB00109W - BACKOUT JOB jjjjjjjj NUMBER-nnnnn TSN-xxxxxxxx WAITING TO COMPLETE.

In this scenario, the backout process cannot complete, because all the transactions are not in the LXX, having been SPILLed previously to one or more RXX files. A COMM STATUS command will show the following for this job:
WAIT E/C DBSTXB ROLBK

When this happens, you can execute the following procedure to undo all the changes for this task/jobstep.

Instructions: 

  1. Run a SPILL job to ensure that all the changes have been moved from the LXX to the RXX files.
  2. Note the TSN value in the DB00109W message as shown above.
  3. Execute a DBUTLTY RECOVERY OPTION=BACKWARD,TSN=xxxxxxxx,… function, specifying all the RXX files from the one preceding the problem job through the one taken in Step 1, above. The files must be listed in the RXX DD concatenation from the oldest to the most recent.
  4. Once the RECOVERY completes successfully, the COMM STATUS function should show that the problem job is no longer running. The DB00109W message will still be displayed on the console, and once the recovery is done, this message must be manually cleared.

Due to the complex nature of logging and recovery, and due to the possibility of encountering other problems in this process, this article addresses only the basic operation. If you need to process a Backward Recovery for your system, and have any question about what to do, we recommend you contact your CA Support team for assistance.

Additional Information:

For an overview of the Recovery process, please refer to the Knowledge Base article TEC608180, titled “An overview of CA Datacom Forward Recovery and Backward Recovery processing, using RXX files.”

For more information about Logging and Spilling the logfile to RXX, about the Log file becoming full, about a Forced Spill and about the Recovery process, please refer to the following Guides:

CA Datacom/DB version 14.02 Database and System Administration Guide:

CA Datacom/DB Version 15.00 CA Datacom/DB Database and System Administration Guide:

CA Datacom/DB version 14.02 DBUTLTY Reference Guide:

CA Datacom/DB version 15.00 DBUTLTY Reference Guide:

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

Environment

Release:
Component: DB