IBM Mainframe Forum

by **enrico-sorichetti** » Thu Mar 10, 2011 10:34 pm

My question was regarding the internal working - i.e what happens once we run a JCL?

appropriate credits given and copyright allowances made ...
os/360

$JobFlow-OS360-CPO-08.jpg

OS VS2/MVS

$JobFlow-MVS-CPO-10-CLP.jpg

by **MrH** » Fri Mar 11, 2011 2:07 am

BillyBoyo wrote: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....

I don't think that using incorrect terminology and concepts helps anyone trying to learn here:

1) You don't run JCL... you run the job that the JCL describes.

2) There is no "real communication with the JCL." It is read. If it's not rejected outright, the job steps get executed.

3) There is no "JCL processor." It's called JES.

by **enrico-sorichetti** » Fri Mar 11, 2011 2:29 am

I don't think that using incorrect terminology and concepts helps anyone trying to learn here:

strongly agree

3) There is no "JCL processor." It's called JES.

a long history of IBM OS' family systems strongly DISagree

JES is the Job Entry Subsystem
( different flavors along the history of OSes, ASP HASP JES2 JES3 )

JCL is the formalism/<language> used to define a JOB
the components which process the JCL are the interpreter and the converter

by **enrico-sorichetti** » Fri Mar 11, 2011 2:45 am

for a deeper insight of jcl see

Y27-7128-0_Control_Program_With_Option_2_MFT_PLM_1966.pdf 06-Sep-2009 18:20 7.2M
Y28-6604-1_Sequential_Access_Methods_PLM_Jan67.pdf 06-Sep-2009 18:20 14M
Y28-6605-2_Introduction_To_Control_Program_Logic_PLM_Sep66.pdf 06-Sep-2009 18:20 1.7M
Y28-6609-1_Input_Output_Support_PLM_Feb67.pdf 06-Sep-2009 18:20 3.4M
Y28-6610_LinkEdit_E_PLM_Jun67.pdf 06-Sep-2009 18:20 7.3M
Y28-6612-2_Fixed-Task_Supervisor_PLM_Sep67.pdf 06-Sep-2009 18:21 8.8M
Y28-6613-1_Job_Management_PLM_Mar67.pdf 06-Sep-2009 18:21 10M
Y28-6614-4_Utilities_PLM_Nov68.pdf 06-Sep-2009 18:21 14M
Y28-6616-1_IO_Supervisor_PLM_Apr67.pdf 06-Sep-2009 18:22 9.9M
Y28-6617-3_BDAM_PLM_Jul67.pdf 06-Sep-2009 18:22 3.9M

at
http://bitsavers.org/pdf/ibm/360/os/plm_1966-67/

historical documents, , quite interesting anyway

by **BillyBoyo** » Fri Mar 11, 2011 3:26 am

MrH wrote:I don't think that using incorrect terminology and concepts helps anyone trying to learn here:

1) You don't run JCL... you run the job that the JCL describes.

2) There is no "real communication with the JCL." It is read. If it's not rejected outright, the job steps get executed.

3) There is no "JCL processor." It's called JES.

1) Human language is about communication. When "we" at places I worked, submitted things, we called it "running". We "ran" jobs, even though we used some sort of submit command to do it... Didn't cause us any sort of errors, or any sort of confusion. Hint. We were probably in a different country than you are now. If it still causes you a problem, I don't care, sorry. Show me a manual that tells you how to talk and maybe I'll take notice.

Terminology is very important. Failing to understand someone and blaming that on their alleged lack of undestanding of terminology is odd.

2) Really? Having severely qualified it, because someone was going to come up with "what about PARM=" and "what about return codes" and "what about UPSI" and, goodness, "what about data cards", I think you can read a bit better and get off your high horse. Even your example, no the step does not get executed, not if I have set a return code in the program and code the JCL to only execute the step for a lesser return code. Yes? Good.

3). There is no JCL processor? And then you name it? Or one of them, anyway. Don't understand your point.

by **dick scherrer** » Fri Mar 11, 2011 3:32 am

Hi Enrico,

Thanks

d

by **steve-myers** » Fri Mar 11, 2011 8:01 am

Communication between JCL and the executing program.

As has been noted, there is no active communication between JCL and the executing program, but JCL leaves behind control information the program must use (and, in a very limited sense, alter) to run. Some of these things are -

The program name, from the EXEC statement PGM= parameter.
Any parameter data specified by the EXEC statement PARM= parameter.
The value specified by the EXEC statement REGION= parameter.
The maximum CPU time for the step, based on a complex iteration of the EXEC statement TIME= parameter, the JOB statement TIME= parameter, and the CPU time used by preceding steps
Information from DD statements as well as allocation decisions made by step initiation that are outside the direct purview of the user program.
Actual step CPU usage, which may effectively alter time limits in subsequent steps
Dataset changes, which may affect allocation decisions in subsequent steps.
The program return code, which may affect running of subsequent job steps.
Assembler programs can alter, in a limited sense, information specified by DD statements, that can affect later steps as well as the current step.
Programs have access to dynamic allocation that can effectively add or remove DD statements as the program executes. This capability was added with MVS and in a limited sense, with TSO in TSO regions very late in the days of OS/360. In MVS, dynamic allocation makes about 90% (my guess, others may disagree) of the capabilities of JCL DD statements available to programs. In a very real sense, dynamic allocation is active communication between a user program and JCL.

by **BillyBoyo** » Fri Mar 11, 2011 12:58 pm

And the DOS-based systems. Still JCL, but a bit different.

On DOS you don't have the interpreter throw out your JCL if it is bad. The bad statement pops up on the operator console and they can attempt to fix it on-the-fly. You also have a PAUSE statement, whereby, via JCL comments, you can ask OPS to do something (even add some extra JCL lines). "Power"ful stuff, eh? :-)

I did see a job requirement for "JCL script writing" recently. I also, seriously, saw a job requirement which included experience using of "IEFBR14" :-)

IBM Mainframe Forum

JCL is written in which language

Re: JCL is written in which language

Re: JCL is written in which language

Re: JCL is written in which language

Re: JCL is written in which language

Re: JCL is written in which language

Re: JCL is written in which language

Re: JCL is written in which language

Re: JCL is written in which language