How can I "debug" JCL? Is there any way to show error or caution messages? When I submit my JOB the output is MAXCC=8. But how can I get why or must I search for where the "error" is?
How to debug JCL
6.3k views Asked by Lukas Fink AtThere are 4 answers
You can't "debug" JCL since there is hardly anything in the JCL that is actually executed - it is mainly for starting a sequence of programs and define their respective environments. The condition-codes result from the programs executed, so to get to the source of your error:
- check your joblog which step produces the condition-code 8 - this might depend on your JES-version, in our environment each step produces an
IEF142I
-message that shows the respective CC. - identify the program that is executed in this step
- check the programs output for any error-messages
How can I "debug" JCL?
JCL is not easy. There are many, many messages and codes manuals to take a look at for this all encompassing question. Essentially you should do your best to be very familiar with fundamentals. Always be well grounded in the fundamentals of the operating system - z/OS - that you write your JCL in order to control.
Is there any way to show error or caution messages?
Yes indeed. They are ALL over your output - from your operating system to your program to even the messages you yourself can create for debugging purposes.
When I submit my JOB the output is MAXCC=8.
This particular message is obviously from the utility called IDCAMS. That's actually a good thing that you understood that that is the place to begin your troubleshooting. In time you will get better. No need to panic.
But how can I get why or must I search for where the "error" is?
Fundamentals. Always fundamentals. Since this is IDCAMS realize that along with IEFBR14, they NEVER, EVER FAIL once they begin. Now that you know that realize that by never failing they will absolutely NEVER display an ERROR message. An ERROR message is only if it fails. Therefore you will only get return codes. Those return codes from IDCAMS are usually fairly clear. Just do your best to get used to them.
Good luck.
First of all, you should know return code's means.
knows these,after you can learn how to fix JCL's error(not debug) if you find error by return code,first,you should check your syntax. job name's place,add typrun=scan,you can check your syntax. if TYPRUN=SCAN not return error message,you can see joblog in SDSF.
press S to see detailed information. because JCL including a or lots steps,you must check which step occur error.ensure which step,you can see detailed information.
in command line input M to reach bottom. it has a lots of error in area,it shows detailed information of error.
You don't actually have a JCL problem.
Firstly, to deal with the MAXCC, since that causes a lot of confusion.
For experienced people, MAXCC only exists in IDCAMS (a utility for file and catalog manipulation, defining VSAM files and stuff associated with those types of things).
MAXCC does not exist in JCL, or in any output you will receive from your JOB.
Where the MAXCC comes from is the NOTIFY statement on your JOB card. We've seen the notify arrive so many times, we never read it, but it does indeed show MAXCC. It's just that MAXCC only occurs in IDCAMS and from the NOTIFY, so telling us what it was will confuse many.
The CC bit is the Condition Code. Each jobstep will produce a Condition Code. Usually the CC will be 00, nothing to report, 04, some situation, not necessarily serious, 08, some situation probably serious, 12, some serious situation and 16, something really bad.
Those are only conventional uses, but most utilities from IBM and Independent Software Vendors (ISVs) stick to the convention. You'll occasionally see a 20, perhaps. Probably during an Earthquake.
For instance, if you compile a COBOL program, 00 will mean the compiler spotted no problems. This does not mean your program works. It just means the syntax is OK. 04 means there are "warnings". You should check those always, as some warnings are actually problematic. 08 are serious errors and although object-code is generated (unless not requested through compiler option), it is foolish to try to execute it (except for fun). 12 and 16, the compiler has just given up and will not generate code.
There is a similar hierarchy with the linkeditor/binder. 00 is all ready to run (but no guarantee it will do anything approaching what you want), 04 is a small problem, but you'll want to know what, 08 is a problem which probably means you won't be able to execute the program.
The short of all this is that if you have MAXCC=08 as the result of your NOTIFY then you have at least one step in your JOB which has a CC of 08. You may have more than one step with 08, and you may also have step(s) with 00 or 04.
This is nothing to do with JCL. The CC has been determined by the program you are running, and what the CC means in each case can differ in the specifics (compiler to linkeditor/binder for instance) although the grading will generally be about equivalent.
You can also set the CC from an application program. In COBOL you would use the RETURN-CODE "special register".
When executed, would, assuming RETURN-CODE receives no other value later, get you a CC of 04 from the execution of that program.
You local site standards will dictate how applications indicate errors: it is quite possible you'll never use RETURN-CODE.
The further short is that you have a program error, and you need to do what piet.t has suggested.
You will likely have error messages associated with the step which produces a CC. A quick and easy way to find out more about the message (apart from COBOL compiler messages, which are self-explanatory(!)) is to use the IBM LookAt web-service: http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/
Paste your message in, click on the GO button. Sometimes you'll need to specify the z/OS version. You can do it always as a beginner.
For debugging JCL itself, to the extent you can, you can use TYPRUN=SCAN on your JOB card, or perhaps your site has a JCL-checker product, although these tend to get a lot of false positives as they are updated years behind for where they try to understand the impact of control cards to standard utilities (TYPRUN=SCAN ignores control cards).
The real test of whether your JCL actually works is to toss it in and run it, creating the conditions which actually test what you have coded. No product can check that the relationships you create in the JCL (through conditional checking of the... CC, it's back again) are correct.