JCL Jobs and SDSF Revisited
Part Two - Challenge #06

Background:

In this challenge, JCL and SDSF is revisited from a different perspective. The different wording and repeated explanation of JCL and SDSF gives you, the contestant, a more concrete understanding of the concepts.

Working in ISPF directly is also known as "foreground" processing, and this is a very useful way to perform tasks. But when a program takes a long time to execute, running it in the foreground means you can't do anything else with your interactive session until the program completes. The solution to this is to submit long-running programs to process in the background. Then you can continue to work interactively while your program runs. z/OS will let you know when your long-running program has completed.

In mainframe-speak, a "job" is 1 or more programs that run in the background. In order to cause work to run in the background (that is, to submit a job), you need to instruct z/OS through JCL. When you submit your JCL, it is passed to the Job Entry Subsystem (JES). JES then allocates the necessary resources for your job, then executes the work when the resources are available. z/OS background job processing is commonly referred to as "batch" processing.

Understanding JCL is a very important skill to have, so you'll be seeing more of it throughout the rest of Parts 2 and 3. Plus, IBM customers are always impressed by applicants who know something about JCL, so you can brag on your resume! Woot!

JCL is quite different from any other programming language. Most systems and applications programmers will find a piece of existing JCL code that does something very close to what they want to do, and then make a few little changes to it so that it fits their needs. You're going to do the same thing in this challenge.

As a systems programmer, you will be doing lots of work with JCL. If you make a simple JCL error, such as forgetting a comma or putting a character in column 72, your job will, in most cases, end very quickly, and the system will inform you of a JCL error. Even very experienced system programmer will make plenty of JCL errors. They know the system does a good job of explaining the mistake. So, they may not spend much time checking JCL syntax before submitting, because the system will check it for them.

Your challenge:

Submit JCL to execute a SORT program. This JCL will fail with a simple error. Success is to correct the JCL error.

Note: While most of z/OS is not case sensitive, you must use UPPERCASE letters in JCL (with a few exceptions such as comments and UNIX file system paths).

Edit CC#####.JCL(BADJCL). On the ISPF Editor primary command line, enter SUB (this is short for submit).

This will send your JCL, which you can also call your job, to JES for processing. JES manages all jobs submitted to the z/OS system. JES will put your job on an initiator queue, which helps decide when to submit your job for execution, and allocates the resources needed for the job. When your job runs, JES manages output from your job (and all other jobs that are submitted) in a special set of data sets called the spool.

Press enter to see the results of your submission. Note the "JCL ERROR" inside the system generated message? This is not good news: your job failed to run. Press enter again to dismiss the message and return to your JCL.

Let's check the output in SDSF try to identify the error. To get to SDSF from the edit session, enter =SD on the ISPF editor primary command line. This will jump directly to SDSF Primary Option Menu. At the SDSF Primary Option Menu, enter the following command:

OWNER CC##### ; PREFIX ; ST

The above stacked SDSF commands will result in display of all CC#### output with any jobname prefix.

Enter S to the left of BADJCL.

SDSF is now displaying entire BADJCL output.

To view all of the output, use the function keys F7 and F8 to scroll up and down, and F10 and F11 to scroll left and right.

The JCL job output assigns line numbers to the JCL statements read. When a JCL error occurs, then a specific JCL error message near the bottom of the output will start with the line number most closely associated with the error.

Hint: The messages displayed for the error encountered are fairly cryptic. If you'll recall, the error here has been encountered previously in the contest, and there exists an ISPF Editor line command: UC. Entering UC in the appropriate location will correct the error in one easy step.

Once you have identified the problem in the JCL, jump back to the ISPF Editor (=3.4) and correct the JCL error in CC#####.JCL(BADJCL).

Once corrected, enter SUBMIT and return to SDSF status queue (=SD;ST). Remember that entering P to the left of unwanted jobs will purge those jobs. This will be useful in later challenges.

Important: To get credit on this challenge, only the SORTOUT DDNAME output from a successful execution should be written to P2.OUTPUT(#06).

To copy the SORTOUT output to your P2.OUTPUT data set, enter ? to the left of your successful BADJCL job and select S the SORTOUT DDNAME. If you see sorted records in the output, then things are good! Press F3 to return to the list of DDNAMES. Enter XDC to the left of SORTOUT DDNAME. XDC is used to write the selected output to a specified data set name.

On the XDC menu, enter the following:

  • Data set name: P2.OUTPUT
  • Member to use: #06
  • Disposition: (SHR)

Accept all the other defaults, then Enter.

Return to your P2.OUTPUT data set and you should find a new member #06. Guess what? You just knocked out another challenge!

Note on purging job output: z/OS will automatically purge jobs older than 24 hours, so XDC anything you'd like to keep long-term.

Next: Challenge #07