tony1131 wrote:the txt file attached above seems helpful. I'm trying to figure out how to execute a program properly in the jcl now
Not at all difficult. Some or all of this may already be known to you; I'm trying to be all-inclusive here.
When you compiled your COBOL source
code, the compiler generated a object module
, unsurprisingly placed in an object library
. This object module, together with others that represent statically-linked subroutines, and a host of machine-language routine are linked
into a load module
by a program called the linkage editor
(do not confuse this last with the process of binding a DB2 package). Again unsurprisingly, the load module is placed in a load library
Your JCL will then look like this:
//PATIENCE JOB other parameters
//STEPN EXEC PGM=RORA
//STEPLIB DD DS=YOUR.LOADLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//FOO DD DSN=HLQ.INFILE,DISP=SHR
//BAR DD DSN=HLQ.OUTFILE,other parameters
//CEEDUMP DD SYSOUT=x
The JOB card establishes this as a job
(often miscalled a "JCL" by the ill-educated), a batch unit of work. The "other parameters" can vary greatly from
site to site; it is best to acquire a job card from a working job at your site, to ensure compliance with local standards.
The EXEC card establishes a job step
, the execution of a program. I've named this step STEPN; you don't have
to give a step a name, but you may well want or need to refer to it late in the job.
The DD cards are "data definition" cards (although seldom referred to by that name), each defining a data resource to be used by the step. The names are significant:
- STEPLIB defines the load library to be searched first for the program. System utilities and, often, production programs are in libraries or memory areas know to the operating system; steps running them may therefore not use a STEPLIB.
- SYSPRINT defines a data set to which messages are written and is usually allocated to the system spool (SYSOUT=*). Most system programs write to SYSPRINT, so its use is pretty standard.
- FOO and BAR are data sets used by your program (you will of course have established your own names when writing the program). Again, "other parameters" vary greatly depending on what you're trying to do).
- CEEDUMP. It's a sad fact of life that abends -- unrecoverable errors -- are likely to occur when testing a program (one of my professors at university said that any program that worked properly the first time it was run was too trivial to have been worth writing). When this happens, CEEDUMP provides a formatted dump -- printing of selected memory locations -- that can aid you in diagnosing and correcting the error.
There is of course a great deal more to JCL than this, but this may get you started.
"You have sat too long for any good you have been doing lately ... Depart, I say; and let us have done with you. In the name of God, go!" -- what I say to a junior programmer at least once a day