IBM Mainframe Forum

Hi All,

I wanted to know in which language is JCL written?
How do the internals of JCL work? Is it an interpreter or a compiler?

PLease help me find answers to these questions.

Thanks.

You are not clear in your question -- are you asking what language JCL is written in, or are you asking what language is used by the system to interpret and process JCL statements? JCL is written in JCL statements -- and the JCL Language Reference manual details exactly what the format is for each possible statement. The interpretation of these JCL statements is done by the system, and unless you work for IBM you're not likely to ever have a need to know more details -- probably it is done by assembler, but there are other possibilties. JCL is an interpreted, not compiled, language and JES (JES2 or JES3, depending upon the site) interprets the statements when the job is read into the system. What are you wanting to know about the internals of JCL -- while some details are available, IBM does not release a lot about internals of their system these days.

Hello and welcome to the forum,

JCL is a language. . .

Is it an interpreter or a compiler?

No. JCL is JCL. While the system "interprets" submitted JCL, JCL itself is not an interpreter.

How do the internals of JCL work?

This answer most likely will not appear in any forum/discussion site. There is simply too much of it and much is proprietary.

If you have something rather specific you want to learn, someone may have an answer.

This answer most likely will not appear in any forum/discussion site. There is simply too much of it and much is proprietary.

any interested party can lurk at the converter/interpreter sources for MVS 3.8 !
( old but still interesting )

Thanks for your response Robert and Dick.

My question was regarding the internal working - i.e what happens once we run a JCL? Does an interpreter or a compiler get invoked?
Is the JCL converted to machine code (ready to be executed) or some intermediate level code?
When we call a cobol program from a jcl, we invoke the cobol compiler. At this point, does the interpreter invoke the compiler? Does the compiler pass the result/machine code back to the interpreter?
Or is there something that im missing?

You do not "run" a JCL -- you submit it. Once submitted, it goes through the JES converter / interpreter, which validates the JCL, issues locks (enqueues) on the data sets as required, and then calls the program(s) invoked by the JCL in sequence. If you have 7 steps in the job, there will be 7 programs executed (unless you have condition codes set). JCL is not converted to machine code although machine code is executed as part of the interpretation process. JCL is interpreted to determine what your job is doing, but there's no language to JCL in the sense of having statements to do certain things (such as COBOL ADD, MOVE, READ, WRITE). The things done by JCL are accomplished by the statements and parameter used.
// EXEC PGM=ABC,REGION=8M,TIME=(2,30) is a JCL statement that the system interprets to mean execute program ABC and allow it to use up to 8 megabytes of memory and run for up to 2 minutes 30 seconds of CPU time.

A compile is a different thing. The COBOL source code, for example, is translated into assembler statements that generate machine code plus other things (such as external program addresses for subroutines being executed). A compiled program is, by itself, useless. You must run the compiled code through the linkage editor / binder to generate a load module from the compiled code. A load module is a machine-executable program. When you invoke that program in JCL (by using // EXEC PGM=ABC in your job), the load module is located -- by STEPLIB, JOBLIB, or system library -- then loaded into memory and control passed to the program to start execute. Once the program is complete, it may (or may not) set a return code which is passed back to the system and is available in the job for later JCL steps to test for conditional execution. The program may not complete due to an abend, in which a dump may be produced to facilitate debugging -- but that depends upon the precise JCL used.

Mr. Sample has a few details out of order.

JESx does some analysis of JCL while it reads the job. It has to detect // JOB statements and // DD * and // DD DATA statements. It does more analysis of the // JOB statement; it extracts the jobname, the accounting parameters and keywords like CLASS=, USER=, PASSWORD=, and MSGCLASS=.

Shortly after JESx has read the job it is processed by the converter. Most JCL syntax checking is done here. Part of the output from the converter is a JESx dataset containing what is called internal text, which is the JCL (including any cataloged procedures) in a tokenized format. This dataset disappears after the job completes. JESx gets to look at the internal text and it may modify it before it is written to the dataset.

The job then goes to the JESx job queue for execution.

When the job is selected for execution, the internal text is "interpreted" to generate the control blocks in the "Scheduler Work Area (SWA)" that are used to run the job. The SWA disappears after the job completes. The dataset names specified in the JCL are then controlled using the ENQ facility, and the first job step executes.

One more thing: a program executed by JCL always passes a return code back to the operating system. The return code may be garbage, but it is still a return code.

Much of this code was written in the 1960s and early 1970s, before compiler syntax analysis libraries existed. Most of it (and all the JES2 code) is in real Assembler. I suspect some of the interpreter code has been rewriiten in IBM's PL/S (or is it PL/X now) language. Many years ago I looked at the JES2 code that analyzes the // JOB statement. Frankly, I think it is pretty poor stuff, though it works. It is clearly very ad hoc code.

Asking "What language is Job Control Language in?" is like, "Who is buried in Grant's Tomb?"

The simplest answer to your other questions is that JCL is a scripting language, primarily (but not exclusively) for performing non-interactive work.

I used to "run" JCL. I don't care that I submitted it to run it, run it is what we did. I don't think this is an occasion where there is strict terminology involved.

JCL is a language (however limited as such - ie it is very specific, not in any way general purpose). Is it compiled? No. So we all know really that it is interpreted, at least in the sense that if it is one or the other, it sure ain't compiled.

I like Steve's answer, and Enrico can back it up with the data.

I'm not sure I'd ever call JCL a "scripting language", even though that wasn't even the question asked originally (or asked in the first part of MrH's post).

neha.sinha wrote:When we call a cobol program from a jcl, we invoke the cobol compiler. At this point, does the interpreter invoke the compiler? Does the compiler pass the result/machine code back to the interpreter?

At each job-step, the JCL processor will cease working for a short while while the program specified is executed. Then the JCL processor will pick up again. The "syntax" of the JCL has been validated up-front, and you whole job will simply be tossed out if that is wrong, so maybe we can say it is a two-stage interpreter?

The program that is executed, by the JCL, has no, well, OK, some, real communication with the JCL. The Cobol compile will take your source, syntax-check-and-covert-it and store it on disk as an "object" and give you an output listing that you can print or whatever. All the resources used by the Cobol compiler have to be established in the JCL, the disk files to read/write, the location of the output list, the disk which contains the library with the compiler on it, etc. Withouth the JCL, you'd have to manually get all these things ready, with physical switches, and stuff like that. Guess how JCL evolved....

When we call a cobol program from a jcl, we invoke the cobol compiler.

No! When we 'call' a COBOL program we execute the named program - nothing to do with the compiler unless it is the program being called - and I bet it isn't written in COBOL!