While running my CA Datacom DBUTLTY SPILL job, I received an error DB13074E - ACTIVE JOB jjjjjjjj PREVENTING SPILL. What is causing this?

Document ID : KB000018968
Last Modified Date : 14/02/2018
Show Technical Document Details


While running my CA Datacom DBUTLTY SPILL job, I received an error DB13074E - ACTIVE JOB jjjjjjjj PREVENTING SPILL. The job then failed. What do I need to do to correct this problem?


First, here is the message text for the DB13074E message:

Explanation : The SPILL utility function was executed when the log had data, but none was spillable. The job name appears in the message text. This is an error situation and the utility abends.

User Response : Wait to attempt a spill until Multi-User indicates data is spillable.

Since the log file keeps records based on time, when it is time to spill, the utility will start at the "oldest" block that has not already been spilled, and will spill the log - block by block. This message indicates that the oldest block (or "first" block) eligible to be spilled could not, because some job was still running that had active log records in that block, and the block was held in case the job failed and needed to back out.

Consequently, this can happen at any time, and is best mitigated by having more frequent "COMIT" commands issued in the job (if it is known to be long-running), with some appropriate application checkpoint processing, or by breaking the job into smaller LUWs (logical units of work).

Alternatively, if this happens with some frequency, you could also allocate a larger LXX, which will hold more records before issuing the message that the threshold for starting a SPILL job has been exceeded.

This message could also be expected if you are scheduling jobs on a regular basis to SPILL the log file to the recovery files, rather than waiting for thethreshold exceeded messages. A solution for this is to automate the SPILL jobs based on the percentage full messages (from the CA Datacom/DB Message Guide):


The DB00308I message is issued as soon as the logfile reaches the threshold, or if the logfile is still greater than the threshold following a SPILL job. Your console automation tool should be set to respond to the DB00308I message and submit the SPILL job. It is possible that a long-running job/task could be preventing the spill, and you would then see the DB00309I message. This should prompt a warning and notification from your console automation that the job in the DB00309I message needs attention to allow the SPILL to run. You could set it up to trigger an operator alert, email, page, etc. when you have a DB00309I message and the percentage is 90% or greater, for example, so someone can intervene. Once the logfile hits 100% full, all activity will stop until the log is SPILLed. In addition, you could consider adding the following to your MUF Startup Options:

MESSAGE CRIT,DB00308,DB00309,DB00311
MESSAGE 1,DB00308,DB00309,DB00311

These say that the DB00308I, DB00309I and DB00311I messages will present to the console as highlighted and non-scrollable. In addition, the second one says that if any of these three messages is already highlighted on the console, and another of these messages comes out, it will delete the first one and this second one stays highlighted and non scrollable (this is to prevent the console from filling with all occurrences of these messages).

For more information about the Logging process, please consult the CA Datacom/DB Database and System Administration Guide, in the section "Operating with Logging Active › Opening the Log Area (LXX)."

For more information about the DBUTLTY SPILL process, please consult the CA Datacom/DB DBUTLTY Reference Guide, in the section "SPILL (Transfer Data to RXX)," or the section

"SPILLOPT (Transfer Data to RXX Using MAX/MIN)."

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