Sometimes, during the normal activity, CA7ONL can abnormally end S0C3 with message CA-7.MAIN - LENGTH CHECK FAILED, R0=nnnnnnnn R1=nnnnnnnn and a restart of the task can help bypassing the problem.
search cancel

Sometimes, during the normal activity, CA7ONL can abnormally end S0C3 with message CA-7.MAIN - LENGTH CHECK FAILED, R0=nnnnnnnn R1=nnnnnnnn and a restart of the task can help bypassing the problem.

book

Article ID: 8287

calendar_today

Updated On:

Products

CA 7 Workload Automation

Issue/Introduction

 

CA7ONL is the task which manages the CA 7 Central Control System. It performs an initialization process starting the functions that schedule and control the production environment. It is also responsible to process all the CA7 commands entered via Online Interface or batch job (like BTI or CCI Terminal).

 

Sometimes it can happen that during the normal activity CA7ONL abnormally terminates with the following messages and Symptom Dump:

16.25.02 JOB32954 IRR010I USERID CA72 IS ASSIGNED TO THIS JOB. 
16.25.03 STC24134 CA-7.MAIN - LENGTH CHECK FAILED, R0=00000804 R1=0009E140 
16.25.03 STC24134 CA-7.MAIN - R10=0001F5C8 R11=00008A68 R14=600784B0 
16.25.14 STC24134 IEA995I SYMPTOM DUMP OUTPUT 745 
745 SYSTEM COMPLETION CODE=0C3 REASON CODE=00000003 
745 TIME=16.25.03 SEQ=05717 CPU=0000 ASID=00E2 
745 PSW AT TIME OF ERROR 078D2000 0001F93E ILC 4 INTC 03 
745 ACTIVE LOAD MODULE ADDRESS=00007000 OFFSET=000 
745 NAME=UCC7 
745 DATA AT PSW 0001F938 - C4304400 A372D503 AC141000 
745 AR/GR 0: 00000000/00000000_00000804 1: 00000000/0000000 
745 2: 00000000/00000013_0009FBA0 3: 00000000/0000000 
745 4: 00000000/00000000_00000000 5: 00000000/0000000  
 

 

and after a task restart in ERST mode, all is ok.

 

What is the cause of this abend and how to prevent it from happening?

 

Environment

CA 7

Cause

 

This is the message text for CA-7.MAIN, as reported in the CA7 Workload Automation Message Reference Guide:

 

CA-7.MAIN

- LENGTH CHECK FAILED, R0=xxxxxxxx R1=xxxxxxxx

 

Reason:

A storage integrity violation is suspected.

 

Action:

Contact your installation specialist for assistance.

 

So, it should be investigated if any command or product activity could have caused this storage violation looking at the product log data that can be extracted using the SASSXTRK program spanning the timeframe of this abend.

 

TEC540443 can be consulted to obtain this CA7 internal log data.

 

 

 

Resolution

 

In the past some PTFs were published for old releases of CA7 in order to cure the error CA-7.MAIN - LENGTH CHECK FAILED, R0=nnnnnnnn R1=nnnnnnnn .

 

If all these PTFs are applied or there isn’t any PTF published for this abend, it is necessary to get the CA7 internal log data spanning the timeframe of the problem and research in it if any command looking like:

 

BT1 ..CANCEL,JOB=jobname,FORCE=YES 

 

has been issued at the same time of the abend.

 

Here a sample as it can be found in the CA7 log data:

 

...

Lª..«Ç..CCCCCCN1.p. ...ð.Ñ..ð./.....H............................... 
Lº..¼.BT1 ..CANCEL,JOB=CCCCCCN1,FORCE=YES 

...  

 

 

If this is the case, we can say that this command could have caused the abend S0C3.

 

In fact this possibility is documented in the CA 7 Command Guide, Chapter 2: Commands, 
Section 'CANCEL Command' - 'Request, Ready or Active Queue Jobs', 


FORCE 

(Optional) Specifies to force the cancellation of the job. If the job to dump the log data set is to be canceled, FORCE=YES must be specified to prevent the job from being resubmitted. FORCE=YES must be used when a job to be canceled shows a status of SKELETON or RETRY. FORCE=YES must be used to cancel a job with connected resources. 
Important! Use of this option can potentially cause CA Workload Automation SE to abend; therefore, it should only be used as a last resort 

 

If this is not applicable here, Please open a Case with CA Support.