JCL DDNAME and the Program Filename Relationship
Part Two - Challenge #07


As you've seen in the previous challenges, JCL instructs the operating system to:

  • find a program to execute
  • allocate the input and output resources needed by the program
  • execute the program using the provided input and output resources

The EXEC statement

Every batch job or started task that gets executed in z/OS has at least one execute (EXEC) statement. Here's an example of perhaps the most minimal JCL possible:


Here's the same example JCL with an optional stepname of STEP1:


It is possible to execute more than one step. Here is an example of a job that has multiple steps, each one executing a different program:


The DD statement

The JCL Data Definition (DD) statement is the key to understanding the purpose of JCL. Inside z/OS programs, the developer chooses virtual names to represent input and output (I/O) sources. In fact, z/OS programs DO NOT "hard-code" physical filenames into the source code. To map virtual I/O to real I/O, the JCL DD statement is used.

For example, consider a hypothetical program called "PAY". Inside the source code for PAY, the programmer uses the virtual name "PAYROLL" to designate a source of input. In the course of execution of PAY, PAYROLL is opened and its contents are read into memory for further processing.

The JCL that is used to execute PAY would need to specify what PAYROLL actually represents. This is done with a DD statement. Here's an example of JCL that might be used to execute the PAY program:

//PAYROLL DD ...physical input filename and attributes...

The physical input filename and attributes designate the location of the resource and any access control methods or other information required.

For example, //PAYROLL DD DSNAME=ZOS.PUBLIC.DIV.PAYROLL,DISP=SHR maps PAYROLL to an MVS data set named ZOS.PUBLIC.DIV.PAYROLL. The disposition (DISP) attribute indicates that the physical file name already exists and the program wants shared (SHR) access; meaning other programs can read ZOS.PUBLIC.DIV.PAYROLL while this step is being executed.

DISP=OLD indicates that the resource already exists and the program wants exclusive access to the data set: no other program can read or write to the data set name during program execution.

Most batch jobs contain several DD statements. Imagine that the PAY program includes instructions to read PAYROLL and write to PAYSTUB. Since we're now dealing with two separate virtual resources, PAYROLL and PAYSTUB, the JCL used to execute PAY needs to map resources for both.

Here's an example of what this might look like:


Therefore, the same program can execute reading different physical input and writing different physical output without changing the program source code. Only the JCL needs to change.

Take note of the SYSOUT=* in the JCL.

The SYSOUT=* DD is a special physical resource known as the JES spool. The JES spool is a special data set that contains JCL queues such as input, output, and execution queues.

Did you know?
SPOOL is an acronym for Simultaneous Peripheral Operations On-Line. Often spools are used as holding areas for temporary data, or as a place to send logging and debugging messages. Whenever you look at the status of a job in SDSF, you are actually looking at the output spool.

Your challenge:

Modify some JCL to write a program's output into a new data set.

Enter the following ISPF primary command:


This submits member PAYROLL from your CC#####.JCL library. Open SDSF with =SD; ST.

Change the SDSF filter settings to show only your personal output by entering PREFIX; OWNER CC#####.

Tab to the left of PAYROLL in the NP column and enter S to select the output for viewing.

Scan through the output and then press F3 return to to the previous screen.

This time, enter ? to the left of PAYROLL, then tab to the left of PAYSTUB in the NP column and enter S to select the PAYSTUB DDNAME output for viewing.

PAYSTUB contains is output which was written to the JES spool using the JCL data definition SYSOUT=* and you are viewing the output in this JES spool.

Now, you need to modify the JCL to write PAYSTUBs output to a newly allocated data set instead of writing to the JES spool. Edit CC#####.JCL(PAYROLL) and look at the last four lines. Notice how they begin with "//*"? Any line in JCL that begins with these characters is treated as a comment and is not executed.

Delete the line containing //PAYSTUB DD SYSOUT=* and uncomment the last four lines by removing the * in column 3. It's important that there is no space between the // and PAYSTUB.

Notice that the last four lines are actually a single JCL DD statement continued on multiple lines. JCL is pretty particular about how you form these sorts of line continuations and you care read all about it in the z/OS MVS JCL Reference book.

This change to the JCL will result in PAYSTUB output to be written to a 'NEW' data set named CC#####.PAYSTUB. Because this is a brand new physical data set, z/OS needs additional data set attribute information after the JCL DD reserved word.

Once the JCL is changed, submit it for execution. Then return to SDSF and display your jobs. You should find a second PAYROLL job with an incremented JobID number. View this new jobs output and confirm that it executed successfully. If any error was encountered, the job output will include messages helping to identify syntax error that needs to be corrected.

If PAYROLL ran successfully, meaning you see a Return Code (RC) of 0, then jump over to the Data Set List Utility =3.4 and enter CC#####.PAYSTUB in the Dsname Level field.

Edit E or View V the CC#####.PAYSTUB data set and confirm that names, pay rate, and pay amount are present; then perform the following actions:

Copy the contents of the data set by typing C99 on line 1's command area. Then in the primary command line enter REPLACE P2.OUTPUT(#07). This results in all the CC#####.PAYSTUB lines to be copied to your P2.OUTPUT(#07) member.

Confirm that P2.OUTPUT(#07) contains the information and you're ready to move on to the next challenge!

Next: Challenge #08