Cluster Resource Services Job Structure

Cluster Resource Services consists of a set of multi-threaded jobs. When clustering is active on an iSeries,^(TM) the jobs will be run in the QSYSWRK subsystem. The jobs run using the QDFTSVR job description. All Cluster Resource Services jobs automatically provide a joblog to aid in problem determination. For these jobs, the LOG parameter of the job description is overridden. An exit program job may or may not produce a joblog. To provide a joblog, change the LOG parameter of the job description to a level that will produce a joblog.

1. Cluster Control consists of one job. The job is named QCSTCTL and runs under the QSYS user profile.
2. Cluster Resource Group Manager consists of one job. The job is named QCSTCRGM and runs under the QSYS user profile.
3. Cluster Resource Groups consists of one job per cluster resource group object. The job name is the same as the cluster resource group name and runs under the QSYS user profile.

When using clustering, the multithreaded job action (QMLTTHDACN) system value must be set to either 1 or 2. See Display System Value (DSPSYSVAL) command for more information.

Most cluster resource group APIs result in a separate job being submitted using the user profile specified when the cluster resource group was created. The exit program defined in the cluster resource group is executed in the submitted job. The job is submitted to the job queue defined in the job description specified in the user profile for the cluster resource group. By default, the jobs are submitted to the QBATCH JOBQ. In general, this job queue is used for production batch jobs and will delay or prevent completion of the exit programs. In order to allow the APIs to run effectively, create a separate user profile, job description, and job queue for use by cluster resource groups. Specify the new user profile for all cluster resource groups created. The same program is executed on all nodes within the recovery domain defined for the cluster resource group using the distributed activity group support provided by Cluster Resource Services.

One or more batch jobs are also submitted for a device cluster resource group if devices must be varied off or on. Varying a device off or on can occur as a result of a failover event or because the Initiate Switchover API was called. In the case of the Initiate Switchover (QcstInitiateSwitchOver) API, the batch job runs under the same user profile as the one that called the API. During a failover event this job runs under the QSYS user profile. To determine the subsystem this job runs under look at the job description associated with the QSYS user profile.

To reactivate a cluster resource group job with a cluster version of 4 or less required clustering to be ended and restarted on the node. Cluster version 5 allows a cluster user to activate the cluster resource group job through the Change Cluster Recovery (CHGCLURCY) command with ACTION(*STRCRGJOB) provided clustering is still active on the node. A CRG job can now be reactivated without ending and starting the cluster on the node.

Behavior of Cluster Resource Services APIs

Most Cluster Resource Services APIs have an asynchronous behavior. In general, whenever a user program calls a Cluster Resource Services API, the API will:

• Check the status of the Cluster Resource Services that will be used to process the API request. If Cluster Resource Services is not active, the API will fail. See the specific API to determine if this condition applies.
• Validate the API parameters and check authorities.
• Validate that a restricted API is not being called from a cluster resource group exit program (see the description of each API to see if this applies).
• Assign a handle to the request. The handle is defined by the Request Handle parameter on the Cluster Resource Services APIs.
• Send the request handle and request to the Cluster Resource Services for processing.
• Return to the API caller with the request handle.
• Process the request on the caller's behalf. When the processing is complete, one or more messages are sent to the user queue specified by the Results Information parameter. Messages indicate whether the processing was successful or unsuccessful. Each message that Cluster Resource Services sends has a specific format. See Cluster APIs Use of User Queues for more information on this format. Part of the message key will be the Request Handle which is returned to the API user.
• Run the API on the originating node, one or more remote nodes, or both.
• Respond to the API request by returning messages to the requestor's user queue on the originating node.

If the node originating a request fails, the request will not be handled on any nodes in the cluster.