DB2

DB2 solutions are designed to establish a link between DB2 and Control-M jobs. This link is established using IOA prerequisite conditions that reflect DB2's status (up or down) and Quantitative resources that indicate on which computer DB2 is running (for follow-me support). This connection enables Control-M to schedule certain jobs only when DB2 is active. Optionally, in a multi-CPU data center, jobs requiring DB2 services (follow-me jobs) can be submitted by Control-M to the same CPU (that is, MVS system) where DB2 is operated. DB2 solutions also "shout" messages notifying the database administrator (DBA) of problems in the DB2 environment.

All messages (DO SHOUT actions) in DB2 rules are sent to an INCONTROL user named U-SYSDBA. A user with this name must be defined in the IOA Dynamic Destination table (CTMDEST). For more information, see the Dynamic Destination Table chapter of the INCONTROL for z/OS Administrator Guide.

In many cases, rule definitions make use of the inverse IN condition feature. This feature activates rules only if the specified IN conditions are not set. (For more information about using inverse IN conditions, see SolveWare Implementation Considerations.

Solutions Provided

SolveWare subject DB2 contains the following solutions:

DB2 Startup and Termination

Intercepts all messages related to DB2 initialization or termination and updates the appropriate IOA prerequisite conditions.
DB2 Follow-me Job Management

Enables Control-M to submit DB2-related jobs to the same CPU (that is, MVS system) where DB2 is operating.
DB2 Problem Alerts

Intercepts important DB2 error messages and notifies the database administrator of the problems.
DB2 Rule Thresholds

Handles exceeded thresholds of other DB2 rules.

DB2 Startup and Termination

At sites operating both Control-M and DB2, the status of DB2 (up or down) impacts the start of jobs that run under Control-M. Therefore, for the production DB2 in the system, the site must maintain two prerequisite conditions indicating DB2 status – CTO-DB2-UP STAT and CTO-DB2-DOWN STAT.

These two conditions are updated by Control-O according to DB2 initialization and termination messages and are used as prerequisite conditions for jobs run under Control-M that require DB2 status information.

IOA DB2 prerequisite conditions and quantitative resources must also be updated at time of IPL to indicate that the various DB2 subsystems are down. For more information, see SolveWare Initialization.

Rules

The DB2 Startup and Termination solution includes the following rules:

Notify Control-M That DB2 Is Up
Notify Control-M That DB2 Is Down

Rules Structure

The following tables describe the structures of the DB2 Startup and Termination solution rules.

Table 86 Notify Control-M That DB2 Is Up Rule Structure

Item	Description
Title	Notify Control-M That DB2 Is Up
Name	DSN9022I
Table	DB2
Message	DSN9022I DSNYASCP `verb' NORMAL COMPLETION where verb is – START DB2.
Message Description	Synchronous processing for command – START DB2 ended without error. DB2 is up and ready. "–" is a one-character identifier that identifies the DB2 subsystem.
Basic Scheduling Parameters	Always schedule this rule.
Runtime Scheduling Parameters	No special considerations.
Global Variables	None.
Rule Logic	This rule, triggered by the above message, sets the IOA conditions that indicate DB2's status (up or down). This way, jobs in Control-M that are waiting for DB2 to be up can be submitted and jobs that require DB2 to be down are not submitted.
Rule Actions	Deletes condition or date CTO-DB2-DOWN STAT Adds condition or date CTO-DB2-UP STAT Deletes condition or date CTO-DB2-DOWN-smfid STAT Adds condition or date CTO-DB2-UP-smfid STAT smfid is the SMF ID of the CPU.
Activating the Rule
Activating the Rule	Once scheduled, the rule is triggered whenever the above message is issued by the DB2 subsystem.
Recommended Mode or Category	During the testing period, activate the rule in LOG mode. Once you are satisfied with the results of the rule, change the mode to PROD to avoid log messages for the rule. The SolveWare category for this rule is 2—some customization is required before implementation.
Customization	Each DB2 subsystem in the installation has a 1-character identifier and all commands that refer to this DB2 subsystem must start with this character. Adapt "–" in command –START DB2 (inside the rule definition) to identify the relevant (production) DB2 subsystem in your installation. If a different mechanism to control DB2 status (utility IOACND, Control-M Event Manager, and so on) is already implemented, the mechanism must be removed before implementing this rule. Change the condition names either in this rule or in the existing job scheduling definitions, if both of the following are true: The IOA environment already uses prerequisite conditions indicating that DB2 is up or down. For example, if such conditions are already referenced by Control-M job scheduling definitions. The prerequisite conditions have different names than the ones indicated in this rule. As noted earlier, IOA DB2 prerequisite conditions must also be updated at time of IPL to indicate that the various DB2 subsystems are down. For details, see SolveWare Initialization.

Table 87 Notify Control-M That DB2 Is Down Rule Structure

Item	Description
Title	Notify Control-M That DB2 Is Down
Name	DSN3100I
Table	DB2
Message	Any of the following messages: DSN3100I csect SUBSYSTEM ssss READY FOR START COMMAND DSN3104I csect - TERMINATION COMPLETE DSN3106I csect SUBSYSTEM STOPPED. COMMAND cmd IGNORED
Message Description	DB2 subsystem is down. It can be started by issuing a start command.
Basic Scheduling Parameters	Always schedule this rule.
Runtime Scheduling Parameters	No special considerations.
Global Variables	None.
Rule Logic	This rule, triggered by any of the above messages, sets the IOA conditions that indicate DB2's status (up or down). This way, jobs in Control-M that are waiting for DB2 to be down can be submitted and jobs that require DB2 to be up are not submitted.
Rule Actions	Deletes condition or date CTO-DB2-UP STAT Adds condition or date CTO-DB2-DOWN STAT Deletes condition or date CTO-DB2-UP-smfid STAT Adds condition or date CTO-DB2-DOWN-smfid STAT] smfid represents the SMF ID of the CPU.
Activating the Rule
Activating the Rule	Once scheduled, the rule is triggered whenever one of the above messages is issued by the DB2 subsystem.
Recommended Mode or Category	During the testing period, activate the rule in LOG mode. Once you are satisfied with the results of the rule, change the mode to PROD to avoid log messages for the rule. The SolveWare category for this rule is 2—some customization is required before implementation.
Customization	If a different mechanism to control DB2 status (utility IOACND, Control-M Event Manager, and so on) is already implemented, the mechanism must be removed before implementing this rule. Change the condition names either in this rule or in the existing job scheduling definitions, if both of the following are true: The IOA environment already uses prerequisite conditions indicating that DB2 is up or down. For example,if such conditions are already referenced by Control-M job scheduling definitions. The prerequisite conditions have different names than the ones indicated in this rule. As noted earlier, IOA DB2 prerequisite conditions must also be updated at time of IPL to indicate that the various DB2 subsystems are down. For details, see SolveWare Initialization.

DB2 Follow-me Job Management

In a multi-CPU configuration operating both Control-M and DB2, certain jobs must run on the same CPU on which DB2 is operating because they require DB2 services. These jobs are referred to as follow-me jobs.

For each CPU on which DB2 may operate, Quantitative resource CTO-DB2-CPU-ID is maintained by rules in this solution (ID is a 1-character identifier of the CPU). A quantity of 9999 is assigned to the resource corresponding to the CPU on which DB2 is operating; a quantity of 0000 is assigned to the corresponding resources on all other CPUs.

Control-M job scheduling definitions for "follow-me" jobs must contain Quantitative resource CTO-DB2-CPU-$. The $ character is a mask. Control-M replaces the $ character with the identifier of the CPU whose resource CTO-DB2-CPU-ID has a quantity of 9999. This CPU identifier is also assigned to the Control-M AutoEdit system variable %%$SIGN, which is used in the JCL of the follow-me jobs to establish the class on which the job is submitted (on the same CPU where DB2 is operated).

For more information on Quantitative resources containing a $ sign, see the Job Production Parameters chapter in the Control-M for z/OS User Guide. The technique of controlling the target computer by AutoEdit system variable %%$SIGN is described in the JCL and AutoEdit Facility chapter in the Control-M for z/OS User Guide.

Rules

The DB2 Follow-me Job Management solution includes the following rules:

Set the Follow-me Quantitative Resource
Reset the Follow-me Quantitative Resource

Rules Structure

The following tables describe the structures of the DB2 Follow-me Job Management solution rules.

Table 88 Set the Follow-me Quantitative Resource Rule Structure

Item	Description
Title	Set the Follow-me Quantitative Resource
Name	DB2UP
Table	DB2
Event	DB2UP
Event Description	This event rule sets the quantity of resource CTO-DB2-CPU-id (used by follow-me jobs) to 9999.
Basic Scheduling Parameters	Always schedule this rule.
Runtime Scheduling Parameters	No special considerations
Global Variables	%%CPUSEQ_smfid For each computer's SMF ID, a one-character identifier of the corresponding system. For example: %%CPUSEQ_SYS1 = 1 %%CPUSEQ_SYS2 = 2
Rule Logic	This rule is triggered when DB2 starts operating. The one-character identifier of the CPU is obtained from the SMF ID and the quantity of resource CTO-DB2-CPU-id for the current CPU is set to 9999.
Rule Actions	Sets Quantitative resource CTO-DB2-CPU-id to 9999.
Activating the Rule	Once scheduled, the rule remains active until deleted from Control-O.
Recommended Mode or Category	During the testing period, activate the rule in LOG mode. Once you are satisfied with the results of the rule, change the mode to PROD to avoid log messages for the rule. The SolveWare category for this rule is 2—some customization is required before implementation.
Customization	For each CPU on which Control-O is active, define a Global variable in the Global Variable list. Each variable must be defined in the format %%CPUSEQ_smfid=c, where smfid is the SMF ID of the CPU and c is a unique, 1-character identifier of the CPU. These variables can be defined manually by adding the variables to the Control-O $GLOBAL member and issuing operator command F CONTROLO, LOADGLOBAL, or they can be defined by adding corresponding DO SET statements to a rule in the INITSLV rule table (see STARTSYS). Control-M job scheduling definitions and JCLs for follow-me jobs must be modified to enable Control-M to dynamically determine the job target computer. SOLVSCHD and SOLVJCL libraries contain, respectively, a sample job scheduling definition and a sample JCL that serve as examples for defining such jobs. These samples can be adapted to site conventions and requirements.

Table 89 Reset the Follow-me Quantitative ResourceRule Structure

Item	Description
Title	Reset the Follow-me Quantitative Resource
Name	DB2DOWN
Table	DB2
Event	DB2DOWN
Event Description	This event rule resets the quantity of resource CTO-DB2-CPU-id (used by follow-me jobs) to 0000.
Basic Scheduling Parameters	Always schedule this rule.
Runtime Scheduling Parameters	No special considerations
Global Variables	%%CPUSEQ_smfid For each computer's SMF ID, a one-character identifier of the corresponding system. For example: %%CPUSEQ_SYS1 = 1 %%CPUSEQ_SYS2 = 2
Rule Logic	This rule is triggered when DB2 stops operating. The one-character identifier of the CPU is obtained from the SMF ID and the quantity of resource CTO-DB2-CPU-id for the current CPU is reset to 0000.
Rule Actions	Reset Quantitative resource CTO-DB2-CPU-id to 0000.
Activating the Rule	Once scheduled, the rule remains active until deleted from Control-O.
Recommended Mode or Category	During the testing period, activate the rule in LOG mode. Once you are satisfied with the results of the rule, change the mode to PROD to avoid log messages for the rule. The SolveWare category for this rule is 2—some customization is required before implementation.
Customization	For each CPU on which Control-O is active, define a Global variable in the Global Variable list. Each variable must be defined in the format %%CPUSEQ_smfid=c, where smfid is the SMF ID of the CPU and c is a unique, 1-character identifier of the CPU. These variables can be defined by manually by adding the variables to the Control-O $GLOBAL member and issuing operator command F CONTROLO,LOADGLOBAL, or by adding corresponding DO SET statements to a rule in the INITSLV rule table (see STARTSYS). Control-M job scheduling definitions and JCLs for follow-me jobs must be modified to enable Control-M to dynamically determine the job target computer. SOLVSCHD and SOLVJCL libraries contain, respectively, a sample job scheduling definition and a sample JCL that serve as examples for defining such jobs. These samples can be adapted to site conventions and requirements.

DB2 Problem Alert

The rules in this solution notify the database administrator of important problems in the DB2 environment.

Rules

The DB2 Problem Alert solution includes the following rules:

Table Space Problem
Threads Are Unavailable

Rules Structure

The following tables describe the structures of the DB2 Problem Alert solution rules.

Table 90 Table Space ProblemRule Structure

Item	Description
Title	Table Space Problem
Name	DSNU086I
Table	DB2
Message	DSNU086I csect ttttt I/O ERRORS ON SPACE=dddddddd. DATASET NUMBER=nnn. I/O ERROR PAGE RANGE=aaaaaa,bbbbbb
Message Description	One or more I/O errors occurred while accessing a table space.
Basic Scheduling Parameters	Always schedule this rule.
Runtime Scheduling Parameters	No special considerations
Global Variables	None.
Rule Logic	This rule is triggered by the above DB2 message. The rule "shouts" a message identifying the problematic table space name to the database administrator.
Rule Actions	Extracts the problematic table space name from the DB2 message. Extracts the dataset number from the DB2 message. "Shouts" a message notifying U-SYSDBA that the named table space is problematic (and probably full).
Activating the Rule	Once scheduled, the rule is triggered whenever the above message is issued by the DB2 subsystem.
Recommended Mode or Category	During the testing period, activate the rule in LOG mode. Once you are satisfied with the results of the rule, change the mode to PROD to avoid log messages for the rule. The SolveWare category for this rule is 1—little or no customization is required before implementation.

Table 91 Threads Are Unavailable Rule Structure

Item	Description
Title	Threads Are Unavailable
Name	DSNC011I
Table	DB2
Message	DSNC011I xxxx TRANSACTION ABENDED BECAUSE THREADS ARE UNAVAILABLE
Message Description	The transaction identified by xxxx abended because a thread connection to DB2 was not available for the transaction. This indicates that the maximum number of thread connections had already been reached before the current transaction.
Basic Scheduling Parameters	Always schedule this rule.
Runtime Scheduling Parameters	No special considerations
Global Variables	None.
Rule Logic	This rule is triggered when the above DB2 message is issued. The rule "shouts" the DB2 message text to the database administrator.
Rule Actions	"Shouts" message text notifying U-SYSDBA of the thread-unavailability problem.
Activating the Rule	Once ordered, the rule remains active until message DSNC011I exceeds a predefined threshold. (For more information regarding threshold handling, see the following section.)
Recommended Mode or Category	During the testing period, activate the rule in LOG mode. Once you are satisfied with the results of the rule, change the mode to PROD to avoid log messages for the rule. The SolveWare category for this rule is 1—little or no customization is required before implementation.

DB2 Rule Thresholds

This solution handles message overload – situations in which a message appears on the console more times than is acceptable. If a DB2 message appears too often on the system console, threshold rules deactivate the relevant DB2 rule until the source of the problem is found and the problem corrected.

For more information regarding threshold handling, see SolveWare Implementation Considerations.

Rules

The DB2 Rule Thresholds solution includes the following rules:

Handling Exceeded DB2 Thresholds
Resetting DB2 Rule Threshold Conditions

Rules Structure

The following tables describe the structures of the DB2 Rule Thresholds solution rules.

Table 92 Handling Exceeded DB2 Thresholds Rule Structure

Item	Description
Title	Handling Exceeded DB2 Thresholds
Name	DSNC011I
Table	DB2
Message	Either of the following messages: DSNC011I xxxx TRANSACTION ABENDED BECAUSE THREADS ARE UNAVAILABLE DSNU086I csect ttttt I/O ERRORS ON SPACE=dddddddd. DATASET NUMBER=nnn. I/O ERROR PAGE RANGE=aaaaaa,bbbbbb
Message Description	Messages handled by other rules comprising the DB2 solutions.
Basic Scheduling Parameters	Always schedule this rule.
Runtime Scheduling Parameters	No special considerations
Global Variables	None.
Rule Logic	To avoid message overload situations, this rule deactivates DB2 rules whose messages have exceeded a predetermined number of appearances in a period of time. These threshold values are defined for every message included in this rule in the threshold parameter APPEARED ### TIMES IN #### MINUTES. (The default is 5 times in 720 minutes.) To synchronize threshold handling correctly, this rule is assigned a higher PRIORITY value than the message rules that it monitors, and has a CONTINUE SEARCH value of Y (Yes). Deactivation of a message rule is achieved by adding the inverse IN prerequisite condition that is defined for the rule. To reactivate the deactivated message rule, the threshold conditions must be deleted. This can be done either manually or automatically by Control-O (see the following section). Threshold conditions must be specified in the IGNORE list of the Control-M CONTDAY procedure (see SSolveWare Implementation Considerations).
Rule Actions	Notifies user U-SYSDBA that the message that has exceeded its threshold is no longer handled by Control-O. Sets the appropriate IN condition to deactivate the rule. The format of this condition is: CTO-msgid-THRESH where msgid is the message ID of the specific message.
Activating the Rule	Once scheduled, the rule is triggered whenever one of the above messages exceeds its threshold.
Recommended Mode or Category	During the testing period, activate the rule in LOG mode. Once you are satisfied with the results of the rule, change the mode to PROD to avoid log messages for this rule. The SolveWare category for this rule is 2—some customization is required before implementation.
Customization	Review each DB2 message monitored by this rule and determine appropriate threshold values. For each message included in this rule, adapt to site requirements the APPEARED ### TIMES IN #### MINUTES value, which specifies a number of appearances in a time period.

Table 93 Resetting DB2 Rule Threshold ConditionsRule Structure

Item	Description
Title	Resetting DB2 Rule Threshold Conditions
Name	RESDB2
Table	DB2
Event	RESDB2
Event Description	This Event rule deletes all threshold conditions for all DB2 rules.
Basic Scheduling Parameters	Always schedule this rule.
Runtime Scheduling Parameters	No special considerations
Global Variables	None.
Rule Logic	Using the INTERVAL parameter, this rule periodically deletes the threshold conditions of all DB2 rules in order to reactivate DB2 rules that exceeded their thresholds. For more information regarding the resetting of threshold conditions, see Customization in this table.
Rule Actions	Deletes condition or date CTO-DSNC011I-THRESH STAT Deletes condition or date CTO-DSNU086I-THRESH STAT
Activating the Rule	Once scheduled, the rule is triggered periodically according to the INTERVAL parameter specification.
Recommended Mode or Category	During the testing period, activate the rule in LOG mode. Once you are satisfied with the results of the rule, change the mode to PROD to avoid log messages for this rule. The SolveWare category for this rule is —some customization is required before implementation.
Customization	Adapt the INTERVAL parameter to site requirements: If you use the INTERVAL parameter without the TIME FROM parameter, the threshold conditions are deleted when the rule is ordered. Threshold conditions must also be deleted at time of IPL (see SolveWare Initialization). Threshold conditions must be specified in the IGNORE list of the Control-M CONTDAY procedure (see SolveWare Implementation Considerations ).