Assignment 2 – JCL and Program Fetch 

CSCI 465 Assignment 2 – JCL and Program Fetch 
50 points
The primary purpose of this assignment is to give you some experience in writing and documenting simple
JCL. Program fetch is what we call the process of "fetching" a program object (now referred to by IBM as
a program object) from an existing load library and executing it. This is what happens in the real world
after a program is developed, tested thoroughly, and approved for promotion into production.
It would be ridiculous if we had to compile a COBOL program, assemble an Assembly language program,
or, for that matter, compile ANY program every time we need to execute it. Instead, the program is
compiled (or assembled) and then submitted to another IBM program known as the Binder.
If all goes well, the Binder produces a so-called "permanent" program object which is stored as a member
with the same name as the program itself (COBOL or Assembler ) in what we call a
load library, i.e., a PDSE set up with parameters to hold only what we program objects, the mainframe's
version of an executable, or .exe, file.
Once stored and ready for use at any time in the future, anyone with access to the appropriate load library
can "fetch" the program object and execute it. As an example, the following excerpted line of JCL is
"fetching" the COBOL Compiler:
In most cases, you have to tell the system where to find the executable, or program object, to which you
refer with the keyword parameter. This is done by adding a card to each of your job
steps. You can instead add a card just following the card in your JCL. If you code the
card, the system will first look in THAT PDSE for any fetched program objects referred to by
any of your job steps.
By the way, the so-called "common modules" like the COBOL Compiler, the high-level Assembler and the
Binder, do not require a because they are so commonly used – hence we refer to them as the
"common modules" – that a (or for any step fetching one of the common modules) is not
necessary. The programs you write – or Mr. Decker writes! – will require a card referencing
the where the executable program objects are stored.
Programming Instructions
First of all, do not think you will be writing code other than JCL in this assignment. You will NOT be
using the COBOL Compiler. That part of the process has already been done by Mr. Decker. You are
simply fetching two programs that he wrote, compiled, ran through the BINDER and stored as executables
in a load library so that you can fetch each and execute each at any point.
Write a complete job with two job steps. The first step will fetch and execute a program object named
stored in Mr. Decker's load library PDSE:
The second step will fetch and execute a program object named from the same load library.
The first step's program, , will read 80-byte records from a member named in your
instructor's PDS named:
CSCI 465 Assignment 2 – JCL and Program Fetch Page 2 of 3
and will write them out to a second data set defined with 80-byte records. Your JCL must indicate this
second output data set as a temporary data set that will be passed to the second step of your JCL.
Note that, when reading data from a specific member of a PDS or PDSE, you refer to it as:
with the member name in parentheses (also note there is no period before the open, or left, parenthesis).
Note that this is different than referring to a program object in a , though. You already indicate
the name of the program object with on the card.
The second step's program, , will read 80-byte records from the temporary data set your first step
passed to it.
It will then write the records out as "report records" to standard output as 133-byte records.
The input and output names for the first step are:
(used for input)
(used for output – this should be an 80-byte temporary data set)
The input and output names for the second step are:
(used for input – this should refer to the 80-byte temporary data set from step 1)
(used for output)
Also, add the following third card to each of the two steps. In the case of an abend, this will provide
you a large dump of storage with a PSW and registers:
Documentation
Follow the Coding and Documentation Guidelines for your JCL very carefully. They are found in Course
Documents on Blackboard.
Output
Your JCL should output the following lines, double spaced, although they will look single spaced in SDSF
(Press F10 to scroll 1 column to the left in SDSF Status Queue so that you can verify the carriage control):
CSCI 465 Assignment 2 – JCL and Program Fetch Page 3 of 3
Terminology
In the mainframe work environment, there is common use of both of the terms PDS (PDSs) and PDSE
(PDSEs) and perhaps even in this very document. Since implementation of the Enterprise COBOL
Compiler, v. 5.1.0, at Marist in May 2015, it has been necessary to use load libraries that are allocated as
PDSEs (Partitioned Data Sets Extended). Mr. Decker's load library, , is a
PDSE, and the one you created in Assignment 1 for your own use is also a PDSE.
Assignment Submission
When you are satisfied with your JCL, documentation, and report output, use Retrieve Jobs to download
and convert your output. Rename the .txt file as ASSIGN2.txt and submit the file on the assignment's page
on Blackboard. Please be sure your text file is named ASSIGN2.txt before submitting it.
Missing Output in Downloaded .txt File
Note that it is very important that, BEFORE you submit it, you open the .txt file to be sure that it is
all there and formatted as expected. Be sure to do this throughout the entire semester.
Missing output is common. You will sometimes see all of the output in TSO/ISPF's SDSF facility but
then it doesn't all show up in your .txt file. This often means that you have 1) forgotten the
PARM=ASA on an assembly step or 2) you have bytes of garbage somewhere in your 133-byte output
lines or they are not 133 bytes long.
To correct the second of these possible problems when you begin writing your own COBOL or
Assembler programs, make sure that each of your output lines is defined as exactly 132 bytes in
COBOL and that each length of bytes in between receiving fields is defined as spaces. For Assembly
language programs, make sure that each of your output lines is defined as exactly 133 (including the
first byte of carriage control) and that each length of bytes in between receiving fields is defined as
spaces.