Managing Datacom Log file (LXX) spills with automation (Automated Operations) routines

Products

• Datacom
• Datacom/AD
• Datacom/DB

Issue/Introduction

As more companies are moving toward a fully automated environment ("lights out"), automated operations monitoring and management tools are taking on greater roles. Many of these tools respond to console messages from application jobs and system tasks, and can contain complex logic to perform analysis and execute commands that a human operator would perform. This article discusses how to use these routines to manage Datacom Log file spills on a z/OS system.

Environment

Release : All

Component : Datacom/DB

Component : Datacom/AD

Resolution

The Datacom software is well-suited to many aspects of automated operation, including management of the Log files (LXX files). By capturing specifically identified console messages, the automated routines can determine if a Log file needs to be spilled to a recovery file (RXX) and can build and submit the job to execute the spill function. As other circumstances arise, these routines can determine if exceptional processing needs to take place to resolve a problem with the normal spill processing.

In order for automated processing to successfully manage log files, certain questions need to be answered, and configuration changes made to support this.

Do I have special requirements for managing log spills for different MUFs, or is the process essentially the same for each of them?

By default (using the default MUF Startup option MUFMSG YES,NO,NO), Datacom will display messages in the following format:

Jobname:DB0xxxxI message text,

where Jobname is the name of the job or started task that is running the MUF. From an automation perspective, there is no real advantage to having the jobname in the message, since most automation tools capture that information for every message. Also, with some automation tools, having these fields in the message ID means that you would have to have different processing scripts for each MUF, even if the processing is the same.

You might experience easier coding of automation routines if the jobname is turned off, and let the automation routine manage a single message for all MUFs, making logic distinctions based on the job issuing the message. Turning off the display of these fields is done by using MUF Startup Option MUFMSG NO,NO,NO and recycling the MUF.

Have I appropriately tuned my thresholds for the Log Full percentages, to accommodate recovery, contingency planning, and other business data retention requirements?

Unless altered by the MUF startup option LOGSPILL, messages are displayed on the console when the Log Area becomes 75% full, then every 5% until the Log Area is 90% full, where messages are then displayed every 1%. There are several components to this startup option, affecting messages displayed and actions taken.

Once all of the MUFs that you plan to manage with automation have been configured, you will need to configure your automation software to respond to the appropriate messages.

The Datacom system will produce these messages related to Log Spill processing (refer to the Datacom Messages documentation for more details):

• DB00308I LOG AREA IS nnn% FULL, nnnnnn BLOCKS SPILLABLE
• DB00309I LOG AREA IS nn% FULL, JOB jjjjjjjj [ID=monitor] PREVENTING SPILL
• DB00310I LOG SPILL rrrrr-ccccc, BLOCKS xxxxx-xxxxx, TIMES ccyy/mm/dd hh.mm.ss-ccyy/mm/dd hh.mm.ss
• DB00311I LOG AREA IS nn% FULL, SPILLING BLOCK nnnnn, OUT OF nnnnn

Automation routines should typically execute when the DB00308I message is displayed. At this time, the automation routine can submit a predefined JCL member for the MUF which issued the message, or there may be a "skeleton" JCL member that is customized by the automation routine before being submitted. During the spill process, the other messages may be issued by the MUF; each site will need to determine if and how they want the automation processing to handle them.

In summary, using automation routines to handle this critical operations process of the Datacom MUF is one way to provide a consistent, timely method of reducing the data center's reliance on ever-shrinking human resources.

Additional Information

For further information about the use of the Log Area (LXX) please refer to the following documentation:

Datacom/DB Version 15.1 Database and System Administration, in the sections, “Using Logging” and “Operating with Logging Active" (paragraph Processing With an Inactive Recovery File)

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