Datacom DB13074E PREVENTING SPILL
search cancel

Datacom DB13074E PREVENTING SPILL

book

Article ID: 18968

calendar_today

Updated On:

Products

Datacom DATACOM - AD CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services CA ECOMETER SERVER COMPONENT FOC Easytrieve Report Generator for Common Services INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA ON DEMAND PORTAL CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware

Issue/Introduction



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?

Environment

z/OS

Resolution

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):

DB00308I LOG AREA IS nnn% FULL, nnnnnn BLOCKS SPILLABLE
DB00309I LOG AREA IS nn% FULL, JOB jjjjjjjj PREVENTING SPILL
DB00311I LOG AREA IS nn% FULL, SPILLING BLOCK nnnnn, OUT OF nnnnn

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).
 

Additional Information

For more information about the Logging process, please consult CA Datacom Core - 15.1 section "Operating with Logging Active › Opening the Log Area (LXX)." 
https://docops.ca.com/ca-datacom/15-1/en/administrating/ca-datacom-db-database-and-system-administration/operating-with-logging-active

For more information about the DBUTLTY SPILL process, please consult the CA Datacom Core - 15.1, in the section "SPILL (Transfer Data to RXX)," or the section "SPILLOPT (Transfer Data to RXX Using MAX/MIN)."
https://docops.ca.com/ca-datacom/15-1/en/reference/dbutlty-reference/utility-function-summary/spillopt-transfer-data-to-rxx-using-max-min