Can I use automation routines to manage my CA Datacom Log file spills on a z/OS system?

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


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.


Can I use automation routines to manage my CA Datacom Log file spills on a z/OS system?


Fortunately, the CA Datacom environment lends itself well to many aspects of automated operation, and specifically manages maintenance of the Log files (LXX files) quite well. By capturing specifically identified console messages, the automated routines can determine if a log file needs to be spilled, can build and submit the job to execute the spill function, and 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), CA Datacom will display messages in the following format:

Jobname:DB0xxxxI message text,

where Jobnameis 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, as most packages capture that information for every message. Also, with some automation tools, having these fields 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 ever 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 CA Datacom system will produce these message related to Log Spill processing (refer to the CA Datacom Message Guide for more details):

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

Typically, the automation routine should execute when it encounters the DB00308I message. 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 CA 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 guides:

CA Datacom/DB Version 14.02 Database and System Administration Guide, in the sections “Using Logging” and “Operating with Logging ActiveProcessing With an Inactive Recovery File

CA Datacom/DB Version 15.0 Database and System Administration Guide, in the sections, “Using Logging” and “Operating with Logging ActiveProcessing With an Inactive Recovery File

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