Scheduler Job Management returns messages: CACM191E and CACM192I.

Products

• Scheduler Job Management

Issue/Introduction

This Knowledge Document explains why the following messages are issued and what actions need to be taken:

CACM191E SUB STATUS UNKNOWN JOB jobname jobno schedname SYS id XCF FLAGS ffffffff.

CACM192I UNABLE TO SUB JOB jobname jobno schedname SYS id XCF FLAGS ffffffff, RETRYING.

 

Resolution

These messages may be issued in a MCPU=YES environment with SUBDIST=YES option. (The SUBDIST=YES option enables the secondary Schedulers to submit jobs.)    When the primary Scheduler distributes submission to a secondary Scheduler and the response is slow from the secondary Scheduler, the primary Scheduler issues either the CACM191E or CACM192I message.

CACM191E is issued when Scheduler cannot tell if the submission request was received by the target system. Scheduler will mark the job UNKNOWN. If the target system does submit the job, then the job will be marked SUBMITTED and tracked normally. If the target system does not submit the job then manual intervention will be necessary (use the SUBMIT command).

CACM192I is issued when Scheduler believes the target system did not receive the submission request. The submission request will be retained until it can be processed by copy of Scheduler.

Additional Information

CACM191 and CACM192I are documented in the Scheduler Message Reference Guide as follows: 

CACM191

SUB STATUS UNKNOWN JOB xxxxxxxx nn xxxxxxxx SYS xxxx XCF FLAGS nnnnnnnn
Reason:
The master copy of CA Scheduler tried to send a submission request to a child copy running on another LPAR in the same SYSPLEX. Not enough information is available to determine whether the target system received the submission request.
SYS xxxx identifies the target system.
The message lists job name, JNO, and schedule involved.
The flags as presented by XCF in the MNPL parameter list are displayed in hexadecimal. The flags are documented in IBM macro IXCYMNPL.
The target system running extremely slowly can cause this problem, typically due to excessive CPU use by some other address space on the target system. XCF cannot acknowledge receipt of the submission request fast enough before the XCF send times out.
The problem can also occur because the target system is in the process of failing.
Because CA Scheduler does not know whether the target system received the submission request, it places the job in question in UNKNOWN status.
Action:
Determine the condition of the target system. If the target system is having a problem with excessive CPU being used, take no action. CA Scheduler on the target system eventually gets enough CPU cycles to complete the submission request.
If, however, the target system has failed, use the CA Scheduler SUBMIT JOB command on the job in the message to restart the submission process.
Important! If you use the CA Scheduler SUBMIT JOB command to re-drive submission, and the target system has not failed, it is possible (likely) that the job is submitted and executed twice.
When the target copy of CA Scheduler completes the submission request, other symptoms may manifest in the job history, such as the "Job submitted" entry listed after the job has completed.
Note: The root cause of this problem is the extreme slow response on the target system. The performance problem should be addressed.

 

CACM192
UNABLE TO SUB JOB xxxxxxxx nn xxxxxxxx SYS xxxx XCF FLAGS nnnnnnnn, RETRYING
Reason:
The master copy of CA Scheduler tried to send a submission request to a child copy running on another LPAR in the same SYSPLEX. An error was returned indicating that the submission request could not be sent to the target system. CA Scheduler passes the submission request to a different copy of CA Scheduler.
The target system is identified by SYS xxxx.
The messages list the job name, JNO, and schedule involved.
The flags as presented by XCF in the MNPL parameter list are displayed in hexadecimal. The flags are documented in IBM macro IXCYMNPL.
Action:
None.