|
View previous topic :: View next topic
|
| Author |
Message |
surupab
New User
Joined: 13 Feb 2008
Posts: 4
Location: Kolkata
|
|
|
|
Hi,
I was trying to check my JCL whether it was correct or not and used PRS option in TSO, then option J - CA JCLCHK and got MAXCC 64. But there are no error messages in the log. Any idea what is MAXCC 64. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Google is your friend. Googling ca-jclcheck return code 64 returns , among other things, a link to this:
| Quote: |
Knowledge Base Article
Bookmark | Email | Print
Show Technical Document Details Click here to show details
Document ID: TEC428346
Tech Document
Title: JCLCheck returns CC=64 without an error message
Description:
Condition code 64 is introduced in v7.1 SP1 to alert the user that an embedded null JCL statement (// ) has been found and that all statements after // will be flushed.
Solution:
Remove the null JCL statement. If this cannot be done and you do not want to receive CC 64, use JCLCheck runtime option FLUSHRC(nn). (nn is the overriding return code with value from 1-256.)
Note: If FLUSHRC(4) is specified and JCLCheck issues an error message with a return code 8, JCLCheck will terminate using the greater value.
Other Relevant Information:
See the Reference Guide for a description of the JCLCheck runtime options.
|
You need to learn to use the vendor support site for questions like this -- much faster answers than asking a public forum! |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
good chance that when you get an error msg,
if you PF1 you will get a longer message.
if not, use PF1 to learn about JCLCHK. |
|
| Back to top |
|
|
surupab
New User
Joined: 13 Feb 2008
Posts: 4
Location: Kolkata
|
|
|
|
Thank you. I removed all statements from the null statem,ent and did JCLCHK and now its fine. Thank you
| Robert Sample wrote: |
Google is your friend. Googling ca-jclcheck return code 64 returns , among other things, a link to this:
| Quote: |
Knowledge Base Article
Bookmark | Email | Print
Show Technical Document Details Click here to show details
Document ID: TEC428346
Tech Document
Title: JCLCheck returns CC=64 without an error message
Description:
Condition code 64 is introduced in v7.1 SP1 to alert the user that an embedded null JCL statement (// ) has been found and that all statements after // will be flushed.
Solution:
Remove the null JCL statement. If this cannot be done and you do not want to receive CC 64, use JCLCheck runtime option FLUSHRC(nn). (nn is the overriding return code with value from 1-256.)
Note: If FLUSHRC(4) is specified and JCLCheck issues an error message with a return code 8, JCLCheck will terminate using the greater value.
Other Relevant Information:
See the Reference Guide for a description of the JCLCheck runtime options.
|
You need to learn to use the vendor support site for questions like this -- much faster answers than asking a public forum! |
|
|
| Back to top |
|
|
Dale Robertson
New User
Joined: 21 Jun 2013
Posts: 44
Location: U.S.A.
|
|
|
|
surupab,
No offense but you should try to live life without JCL Check. It's like taking crutches to a track meet. Just run yer job fer 'crissake!!
r
"I'm afraid of fallout." [when I should be afraid of the blast and heat!]
--from the 1950's. |
|
| Back to top |
|
|
coxdavi
New User
Joined: 12 Mar 2009
Posts: 30
Location: usa
|
|
|
|
| One word: Auditors. That's the only reason we are forced to use a product like this. ASG's Jobscan was ok and easy to maintain, but JCK is a pain. |
|
| Back to top |
|
|
shatruk125
New User
Joined: 22 May 2014
Posts: 1
Location: india
|
|
|
|
check your JCL carefully you might have left statment after // empty.
close it //* if you are not adding any jcl stmt. |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| Shatruck125, I guss the problem was resolved in August 2012. Also, it was clearly stated that it was due to a end-of-job statement (// on a line by itself). Changing it to a comment (//*) (not 'closed') is only a viable option if the line was meant to be a comment in the first place otherwise you could be executing programs that were nothing to do with the job. |
|
| Back to top |
|
|
|
|
