Why are jobs staying in the ready queue in CA 7?
CA 7 tracks work that it submits using SMF feedback. This technical document gives some tips on how to trouble shoot an issue with CA 7 not tracking the workload. There are many different ways that a case of CA 7 not tracking work is reported. Jobs that complete do not trigger their follow-on work, jobs hang in the ready queue, but these are symptoms of CA 7 not tracking the work it is submitting. If CA 7 is not tracking, here are some things to check.
If some jobs track and others don't, check to be sure that security is not causing the problem (look for 'job flushed' message on os/console).
When CA 7 submits a job it puts a hex '31' in column 71 of the first job card (this is the default for the CA71 instance, for other instances, check Tracking Instance Identifiers). When the job goes through the converter interpreter, the 31 is changed to 33 (2 is added to the identifier of the instance). You can go to SDSF in the held output queue, turn hex on and check for the 33 and the job card will also be shifted and repeated with an IBM message 'IEFC025I INSTALLATION MODIFIED JCL'. If the job card is not changed (still 31) and the message is not in the output, then the job did not run on a system calling our SASSUJV.
On the LQ output (LQ, LRDY, etc.) there is a SUB/START DATE/TIME for jobs in the queues. If this is *NONE* then the job is not submitted. If there is a date and time in this field, that is the time the JCL was written to internal reader or submit data set. LRDYP,JOB=,LIST=STATUS will show non-submittal reason if there is *NONE* in SUB/START time.
If using internal reader and there is a SUB/START date/time, then proceed...
Be sure that ICOM is active on the system that the job is running on. Check the data set pointed to by the UCC7CMDS for CA 7 and ICOM. They must be the same. When both programs start, there is a CA-7.INCD message which states what pack the COMMDS is on and if it is shared. Also, browse the COMMDS to see if there is a UCC7SUBx or UCC7IRDx - NOT UCC7NCFx (unless using NCF).
Check the SVCNO statement in the init deck for SASSVC=NO. For job tracking, CA 7 should have SASSSVC=YES.
If CA 7 was reinitialized with CAS9, it could be that ICOM and CA 7 need to be recycled.
Here are some diagnostic information for CA 7 and internal MVS job tracking that you will want to have available if calling into CA 7 Support:
Issue CAISMFU from =6 on TSO
CAS9001I Interface Summary:
CAS9002I
CAS9003I Name Vers Description Status
CAS9004I CAS9U83 S910 CAIRIM INTERCEPT Active
CAS9004I CAS9U84 S910 CAIRIM INTERCEPT Active
CAS9004I CAS9ATRT S910 CAIRIM INTERCEPT Active
CAS9004I SMFISDMP SF15 JARS/SMF INITIATOR Active
CAS9004I $IXRUJSI L141 IXR JOB INIT EXIT Active
CAS9004I TLMSSMFE TL55 TLMS SMF EXIT Active
CAS9004I SASSUJV L2C1 CA-7 JOB VAL EXIT Active
CAS9004I SASSU83 L2C1 CA-7 SVC 83 EXIT Active
CAS9004I SASSU84 L2C1 CA-7 SVC 84 EXIT Active
CAS9004I JR51SMFE 7.1 JARS ONLINE CHARGES Active
CAS9004I CASEJOB W110 CA-ENF Job Init Active
CAS9004I CASESM83 W110 CA-ENF Intercept Active
CAS9004I CASESM84 W110 CA-ENF Intercept Active
CAS9002I
CAS9005I Number of interfaces 13 Number of calls processed 684533
Issue a DEMAND,JOB=CA07SVCT in CA 7. You may have to do a DEMANDH and then edit the QJCL to route the job to various systems (if more than one). The messages produced by this job are documented in the CA 7 Message Reference Guide.
Run the CAL2ENVR program (SAMPJCL member ENVR) to get an environmental report.