EXEC Statement

Q. What is the EXEC Statement in JCL used for?

The EXEC Statement in JCL, represents one step. You would code one EXEC Statement in your Job, for each step. If your job has a dozen steps, you must code a dozen EXEC Statements in your JCL.  One step executes(runs) one Program. A Program consumes data from Input Files and produces results data to be written to Output Files. In JCL, you code a DD Statement to refer to Input Files or Output files. Buckle up you seatbelts now..  One EXEC Statement runs a Program, DD Statements tell you what input/output files this Program uses. And then comes the second EXEC Statement, that runs another Program, followed by corresponding DD Statements that refer to the files used by the second Program, and then the third EXEC Statement, followed by its corresponding DD Statements(files) and so on.. //   EXEC program-1 //   DD file-1 //   DD file-2 //   EXEC program-2 //   DD file-1 //   DD file-2 //   EXEC program-3 //   DD file-1 //   DD file-2 ...

Q. Well, I got what EXEC Statement does? Could you show me how to code it in a real Job? That would be like awesome!

Just like all JCL Statements, an EXEC Statement has got to begin with a name. You can assign a name of up to eight characters, with the first letter as an Alphabet. The names of steps are also important, because this is how the MVS Operating System refers to them. A job may have gazillions of steps, how do you distinguish them, tell one step apart from the other – by assigning a unique name to each step. In the above JCL, I have assigned the step-name //STEP010. A popular convention is to often use meaningful step-names, by looking at which you could easily figure out, what the step does. For example, if in a particular step you use the IBM’s ready-made program IEBGENER, to copy the contents of 1 file to another, you can give the name //COPYSTP to this step. The simplest EXEC Statement is the one that has a name and uses either a PGM= or PROC=. PROC= is used to execute Catalogued Procedures. If you don’t code a PGM= or a PROC=, by default it assumes that you are trying to run a Catalogued Procedure.

Q. What happens when you code an EXEC PGM=?

The PGM= parameter is used to run a Program. This is the Binary Machine Language Program or Load Module. You can run IBM supplied free Programs such as IEBGENER, SORT, IEFBR14, IEBPTPCH, IEBCOPY and more. Apart from these ready-made programs that IBM supplies, you can also run your very own programs which you have written. Every program or Load Module that you run, is stored as a member of Partitioned Dataset(PDS) or Folder(Library). A Partitioned Dataset(PDS) that houses Load Modules is called Load Library. Code an EXEC PGM= Statement in JCL, and the MVS Operating System tries to find, where the program/Load Module to be run is stored. The question is, how does the Mainframe Computer know the location of the program to be run? In other words, how does the Mainframe know in which library your program is kept? Well, when you are executing a ready-made programs supplied by IBM like IEBGENER or SORT(like on Windows, you run Notepad and Paint), you don’t have to tell the Mainframe Computer where these programs are housed. If you don’t tell anything, the Mainframe computer looks up the default Load library(PDS) or folder. The default Load Library on Mainframes is SYS1.LINKLIB.   Your project or your installation may define additional such libraries to the MVS Operating System. The default libraries like the one above apply to these ready-made pre-written COBOL programs like IEBGENER or SORT. But what about the COBOL programs that you have custom-written? How does the Mainframe computer know, in which Load Library to look for them?  Well, the first thing that you do, is to create your very own Load Library – a place where the Load Modules of all COBOL programs you write would go. Like, I have created one for my Loads – AGY0157.DEMO.LOADLIB. Once, you've put your Load Module into your Load Library, you must tell the Mainframe computer, about your personal Load Library. You can specify your own Personal Load Libraries in the //JOBLIB or //STEPLIB file while writing a job. I've shown this below. I want to run my own custom COBOL Program(Load) PROGRAM1, the Load is housed in my Personal Load Library AGY0157.DEMO.LOADLIB.

Q. How do you code TIME Parameter on the EXEC Statement?

When you code a TIME on an EXEC Statement, you are specifying an upper bound, an upper limit on the amount of CPU time a program gets. For example, if you specify TIME=6 seconds, you are telling Mainframe Computer, the maximum time for which this program is allowed to run on the CPU is 6 seconds. Thus, TIME Parameter allows you to specify the maximum CPU Time, for which a Program can run. Remember, that on a real Mainframe, 6 seconds a lot of time pal! A Mainframe can process a huge volume of data in 6 CPU Seconds. But then, you might wonder, what good is it to set an upper time limit? Imagine, that you have written a program that contains a serious fault. Sometimes, the program runs into an endless loop. This is where TIME parameter helps you big-time. If the program goes into a bad loop, and exceeds its maximum time-limit, it is automatically terminated. The TIME Parameter has this syntax – TIME=(min,sec). Check it out below, the way I’ve done for my step.   What happens, when a program exceeds its maximum allotted CPU time limit? The Step leaves behind a System Complete Code 322, commonly known as S322. S322 code implies that the step failed, because it exceeded the upper CPU time limit.

Q. How do you code REGION Parameter on the EXEC Statement?

When you code a REGION Parameter on the EXEC Statement, you are specifying an upper limit on the amount of Memory Space, that the program can use. Take a look at the following example : K stands for Kilobytes. In the above job, I have set an upper limit of 2048 Kilobytes of memory, for my step to run. On the same lines, M stands for Megabytes.   If you don’t code a REGION Parameter, mostly your project or installation will have defined a default value like 1024K. If you code REGION on the JOB Statement and on EXECs, the JOB limit overrides any REGIONs which are larger. In the earlier days, it was common to code a REGION parameter to avoid Programs from hogging over excess Memory Space. Coding REGION parameter had relevance only before 1973, when Virtual Storage had not been introduced. If a program exceeds the upper boundary of the memory, set by you, it leaves behind a System Completion code 804 or 80A.