JCL Internal Error

[Justme93]

Hi guys,

i am new to Mainframe and I have been trying to submit jobs so i can get a PDF output, it's the way we view our jobs at work.

However, i seem to be hitting a wall because i am seeing JCL internal error.

i must stress i am only a beginner, and there is no one left work that knows how to fix this error because they are retired and mainframe is no longer supported over here.

I have attached screenshots of the JCL, would greatly appreciate it if someone could help!

Also, if the issue is resolved, how would i set up the JCL and save it so it runs each time i submit a job? If anyone has a process or step by step..

i look forward to hearing from you guys.

Thanks

[prino]

The problem is in line 42!

FFS, how do you think we can see what's wrong if you don't show the output of the job, with the error?

[Justme93]

Like i said i'm just a beginner..

Just trying to ask for some help.

I've shown you what i can see on my screen, is there something else you would like to see?

No need for language like that!

[Justme93]

Attached above

[enrico-sorichetti]

the last message told nothing we did not know about

use sdsf to look at the job output and identify the REAL cause

wild guess... a dataset not found ???

[Justme93]

Just went on sdsf and took some screenshots.

can only attach 3 screenshots per message so 1-3 on here and 4-6 on the next message.

[Justme93]

following on from the above message

4-6 screenshots

[enrico-sorichetti]

what happened when You tried to read CAREFULLY all the sysout ?

the problem is clearly described by the messages
IEF344I, IGD17101I

go to ISPF 3.4 and try to delete the offending dataset


and ... NO REASON AT ALL to post screenshots
a plain TEXT cut and paste is more than enough

[Justme93]

How would i go about deleting the offending dataset? I have gone into 3.4 but not letting me delete it.

[steve-myers]

We've been through this before.

The CN(INTERNAL) in the message is a reference to the mechanism used to send the message to your work station. CN is an abbreviation for "console;" the message is sent using a mechanism an operator at some operator console or possibly another TSO user might use to send a message to your workstation. It does not imply there is some sort of internal error in the code that analyzes or processes JCL.

The actual error is in your JCL; as Mr. Sorichetti says, you will have to review your job's output through SDSF or whatever agent is used in your environment to review job output.

Sadly, JCL processing in z/OS is very convoluted and messages often appear in the oddest places. In the 1980s there was some effort to improve JCL related messages. If you think it's bad now get into your wayback machine to, say, 1985, and prepare to be horrified! Much of the code that scans your JCL goes back to the 1960s and has been patched to the point no one can really understand it. The whole mess really should be rewritten to modern standards, but no one wants to fund the effort. Many syntax errors point to something unrelated to the real syntax error. Usually it gets the correct statement! Most JCL related messages have a message ID IEFxxxx. Look for that and you should find the error.

Most, but not all, JCL related messages are in the JESYSMSG data set. Most syntax messages will be in the JESJCL data set. Look in both data sets.

Shortly after you submitted your job the JCL is analyzed and transformed into what is called "internal text." Most JCL errors are discovered in this phase. The actual JCL is discarded during this phase; the next step transforms the internal text into the control blocks used when the job is run. Some actual JCL errors are not detected until the job is actually run.