by steve-myers » Mon Oct 14, 2019 6:11 pm
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.