JCL: Specifying Job Information: Text-only Version

JCL: Specifying Job Information


Unit 1. Jobnames and Stepnames



In this course, you will learn how to specify JCL job information.
In this unit, you will learn the pieces of information that identify a job. You'll learn how to use different parameters on JOB and EXEC statements to specify both a jobname and a stepname.
You'll also learn how to handle job identification by using JES2 format to code the JOB statement and by using JES2 and JES3 statements.

After completing this unit, you should be able to:


Topic 1.1: Conventions

*Control Statements
Many of the sections in this course address specific JES2 and JES3 control statements used in job processing.
JES2 and JES3 are job entry subsystems in MVS that support job entry functions.
The syntax rules for coding these control statements are similar to the syntax rules for JCL statements.
Let's look briefly at the rules for coding JES2 and JES3 JCL control statements.

*JES2 Control Statements
JES2 control statements are used with JCL statements to control the input and output processing of jobs. With a few exceptions, these general rules for coding JCL statements apply to JES2 control statements:


*Format JES2 Statements
The basic format of JES2 statements is
/*name  parameter,<parameter>...
Most JES2 control statements should be coded after the JOB statement. JES2 ignores most control statements that appear before the JOB statement.
Some JES2 control statements have additional requirements. You should refer to your JCL manuals for information on specific JES2 control statements.

*JES3 Control Statements
JES3 control statements are used with JCL statements to control the input and output processing of jobs. The general rules for coding JCL statements apply to JES3 control statements, with a few exceptions:
Two exceptions are the /*SIGNON and /*SIGNOFF control statements, which contain the characters /* in the first two columns.


*Format JES3 Control Statements
The basic format of JES3 statements is
//*name  parameter<,parameter>...
Most JES3 control statements should be coded after the JOB statement. JES3 ignores most control statements that appear before the JOB statement.
Some JES3 control statements have additional requirements. You should refer to your JCL manuals for information on specific JES3 control statements.

Topic 1.2: Name

*Identify a Job
Now let's look at the pieces of information that identify a job. Specifically, you need to identify the jobname, stepname, account, and submitter (or programmer).
This chart lists the JCL statements and parameters for job identification that will be covered in this unit.
Examine the following table
To identify JOB EXEC
job jobname field   
step    stepname field
account accounting information parameter ACCT parameter
submitter name parameter   


*Use JES2 Format to Code JOB Statements
In addition, you'll see how to handle job identification by using JES2 format to code the JOB statement and by using JES2 and JES3 statements.
Examine the following table
To identify JCL
JOB Statement 		JES2
Statements 		JES3
Statements
job         
step         
account pano sub-parameter in JES2 format /*NETACCT //*NETACCT
submitter room in JES2 format ROOM on /*JOBPARM   


Jobname
This unit focuses on the jobname and stepname fields. Let's start with the jobname. Your job is identified to the system via its jobname: //jobname JOB.
Your job ends at ...
Examine the following table
The next JOB statement //JOB1   JOB
:
//JOB2   JOB
(starts another job)
                                                         
A null statement //JOB1   JOB
:
//           
(ends JOB1)
  
The end of the input stream //JOB1   JOB
:
(end of input stream marks the of JOB1)


*Review the Rules
Now, let's answer a few questions as a way of reviewing the rules for coding the jobname.
Recall that the rules are the same for any statement name whether in a
JOB (jobname), EXEC (stepname) or DD (ddname) statement.







 
    //jobname  JOB
    //<stepname> EXEC parameters <comments>  
    //<stepname> EXEC parameters <comments>  
    //<stepname> EXEC parameters <comments>  
    :
Stepname
The stepname is used to identify each step in a job. It is the name coded on the EXEC statement. As mentioned earlier, the coding rules for a stepname are the same as those for a jobname.
Although stepnames are not required, they are important because the system uses the stepname in messages.



*Multi-Step Jobs
Although stepnames are not required, they are important because the system uses the stepname in messages.
Let's look at a multi-step job.



 
  //EDITUNLD JOB (B638,L155),EDIT,CLASS=Z,TIME=2  
  :
  //         EXEC PGM=IEBGENER
  //SYSPRINT  DD  SYSOUT=*
  :
  //         EXEC PGM=EDITUNLD,PARM='P'
  //STEPLIB   DD  DSN=EDIT.LOAD,DISP=SHR
  :
*Condition Code
IEF142I EDITUNLD - STEP WAS EXECUTED - COND CODE 0000
Here is an example of a message that displays the condition code at the end of a job step. Its generic format is
IEF142I jobname stepname - STEP WAS EXECUTED - COND CODE nnnn
No stepnames are coded, so no stepname appears in the message.



*Output the Job
IEF142I EDITUNLD - STEP WAS EXECUTED - COND CODE 0000
IEF142I EDITUNLD - STEP WAS EXECUTED - COND CODE 0000
Here is the output from our multi-step job. As you can see, the stepname displays in the message. You can immediately tell where a problem occurred if you code the stepname.

Topic 1.3: Unit 1 Summary

In this unit, you learned that the jobname and stepname are two pieces of information that identify the job to the system. You learned that your job is identified to the system via its jobname, as in //jobname JOB, and that your job ends at (1) the next JOB statement, (2) a null statement, and (3) the end of the input stream.
You learned that the jobname must start in position 3 and that the jobname is followed by one or more blanks. You also learned that the jobname can be made up of 1 - 8 alphanumeric (A-Z, 0-9) or national (@ # $) characters, and the first character of the jobname must be alphabetic (A-Z) or national (@ # $).
And finally, you learned that the stepname is used to identify each step in a job. It is the name coded on the EXEC statement. The coding rules for a stepname are the same as those for a jobname, and although stepnames are not required, they are important, because the system uses the stepname in messages.

Unit 2. More JOB Parameters



In this unit, you will learn the pieces of information that identify a job. You'll learn how to use different parameters on JOB and EXEC statements to specify both account information and the name of the submitter or programmer.
You'll also learn how to handle job identification by using JES2 format to code the JOB statement and by using JES2 and JES3 statements.

After completing this unit, you should be able to:


Topic 2.1: Account

*Identify the Account
First let's look at identifying the account.
When you specify accounting information on the JOB statement, it applies to the entire job.
//jobname JOB accounting-information,name,keyword parameters
When you code the information on the EXEC statement, it only applies to that step within the job.
//stepname EXEC parameters comments
where ACCT=(accounting-information) is a parameter
You use the accounting information to tie the resources used to the appropriate account.

For jobs submitted to a remote node for execution, the account number may be supplied on the JES2 /*NETACCT statement or on the JES3 //*NETACCT statement.
This use of the account number is covered later during the discussion of job submission.
Direct your attention now to using the accounting information parameter on the JOB statement.

*Position the Parameter
//jobname JOB accounting-information,name,keyword parameters
As you know, the accounting information parameter on the JOB statement applies to the entire jobstream, that is, it applies to all steps.
The parameter is positional and may be required at an installation.
When you are given access to your computer system, you will receive the proper account number and information necessary to run your jobs.

*The Account Number Subparameter
//jobname JOB accounting-information,name,keyword parameters (<account number><,accounting-information>...)
The accounting information parameter has two subparameters that are defined at an installation to reflect its standards.
The first subparameter, account number, is the submitter's account number. For example, the account number can be
Examine the following table
a department name AUDIT
a social security number 234-90-9907
an installation code 347EE3


*The Accounting Information Subparameter
//jobname JOB accounting-information,name,keyword parameters (<account number><,accounting-information>...)
The second subparameter, accounting information, is other information required by the installation that further identifies the submitter. For example, in addition to the account number, you may need to specify
Examine the following table
a group within a department (AUDIT,GP7)
a social security number and class (234-90-9907,CIS2550)
an installation code, date and location (347EE3,0425,OH)


Topic 2.2: Accounting Information Parameter

*Use JES2 Format
You can also code the accounting information subparameter in the JES2 format so that JES2 can interpret it.
Here's the syntax:
(pano,room,time,lines,cards,forms,copies,log,linect)
This syntax and the alternate method of supplying this information on the JES2 /*JOBPARM statement is discussed in a subsequent section on JES2 accounting information.

*Follow Common Syntax Rules
The accounting information parameter follows the common syntax rules for coding positional parameters and subparameters.
Look now at some additional syntax considerations that pertain to the following characteristics:


Topic 2.2.1: Location

*The First Position
//jobname JOB accounting-information,name,keyword parameters
The accounting information parameter is the first positional parameter of the JOB statement. Submitter's name, the second (and last) positional parameter, will be covered later.
If you omit the accounting information parameter...


Topic 2.2.2: Length

*Use 143 Characters or Less
//jobname JOB accounting-information,name,keyword parameters
The complete accounting information parameter can be no more than 143 characters.
Include commas when you count characters; exclude enclosing parentheses.

Topic 2.2.3: Multiple Subparameters

*Separate Multiple Subparameters
//jobname JOB accounting-information,name,keyword parameters (<account number><,accounting-information>...)
When you have multiple subparameters, separate them with commas and enclose the entire parameter in parentheses or apostrophes.
In the following examples, the first subparameter is the account number (27-566), and the second is the accounting information (SYSTEMS).
//JOBX   JOB  '27-566,SYSTEMS'
//JOBY   JOB  (27-566,SYSTEMS)









*Additional Syntax
Regarding coding the accounting information parameter you've seen additional syntax considerations that pertain to the following characteristics:
Let's continue with
First, let's take a moment to review JCL's special character set.

*Special JCL Characters
The following are special characters in JCL:
comma ,
ampersand &
period .
plus sign +
slash /
hyphen -
apostrophe '
equal sign =
parentheses ()
blank asterisk *
When coding the accounting information parameter, however, hyphens are not considered special characters. For example, here's a JOB statement with an account number of DPT-78:
//UPDATE  JOB   DPT-78,CLIFF

*Code Subparameters Using Special Characters
Here are the two ways to code subparameters with special characters. These examples use a slash (/):
1. Enclose the subparameter in apostrophes and the entire parameter in parentheses, as in
//UPDATE  JOB   (AUDIT,'12/30',YEAR-END)
or
2. Enclose the entire parameter in apostrophes, as in
//UPDATE  JOB   'AUDIT,12/30,YEAR-END'

*Follow the Rules for Coding Special Characters
What if you are using special characters such as an
ampersand (&) or apostrophe (')
in the accounting information parameter? Follow the rules for coding special characters. In addition, code two consecutive ampersands (&&) or apostrophes ('').
For example, if you code a subparameter as 'P4&&SAM', the system interprets it as P4&SAM:
//UPDATE  JOB   ('P4&&SAM',GP17)

*Use Parentheses and Commas
To continue the accounting information parameter on another line, enclose the entire parameter in parentheses and break the line at a comma separating subparameters.
For example, this JOB statement
//JOBXX  JOB  (45678,HRD,
//       BLD76,45332)
is equivalent to
//JOBXX  JOB  (45678,HRD,BLD76,45332)









*Code It on the JOB or EXEC Statement
As you've learned, the accounting information parameter can specify accounting information for the entire job or for a step within a job. That is, you can code it on the JOB or EXEC statement.
You've become familiar with coding accounting information on the JOB statement, as in
//jobname JOB accounting-information,name,keyword parameters (<account number><,accounting-information>...)
Now, let's move on to coding it on an EXEC statement, as in
//stepname EXEC parameters comments
where ACCT=(accounting-information) is a parameter.

*Using ACCT
//stepname EXEC parameters comments
where ACCT=(accounting-information) is a parameter
You use the ACCT parameter to code accounting information on the EXEC statement. The accounting information applies to the step only and overrides equivalent settings on the JOB statement.

ACCT Rules
The ACCT parameter is like the accounting information parameter on the JOB statement except ...
1. It is a keyword parameter rather than positional.
2. It is optional. The accounting information parameter on the JOB statement may be required at some installations.
3. It contains only accounting information, not the account number. The account number for all job steps is taken from the JOB statement.
4. The accounting information coded pertains only to the job step.
The ACCT parameter does follow all the same coding conventions as the accounting information parameter.







Topic 2.3: Submitter

*Identify the Submitter
You've seen how to identify the job, step, and account via JCL statements and parameters. Now, let's see how to identify the submitter. You identify the submitter via the programmer's name parameter on the JOB statement. Throughout this course we refer to this parameter simply as the name parameter. It is the second (and last) positional parameter on the JOB statement. It is optional and is usually defined by your installation.
The name parameter can identify the
that submitted the job.

*Name Parameter Syntax Rules
The name parameter follows the common syntax rules for coding positional parameters.
However, you should be aware of some additional syntax considerations that pertain to the following characteristics:


*Omit the Placeholder Comma
If you code the name parameter, it must follow the accounting information parameter and precede all keyword parameters.
In the following example, the name parameter is SMITH.
//PRINTIT  JOB  01013467,SMITH,TIME=1
If you omit the name parameter, you don't have to code a placeholder comma.
In this JOB statement, the name parameter is omitted.
//UPDATE  JOB  (D100,HR),TIME=1









*Use 20 Characters or Less
The length of the name parameter must be 20 characters or less. Enclose the name in apostrophes if it contains special characters, as in
//JOB1  JOB  45678,'DON HILL'
//JOB2  JOB  34567,'R&D'
//JOB3  JOB  23456,'D.O.'
Names with following characters do not need apostrophes:
hyphens: //JOBX  JOB  ,SMITH-II
embedded periods: //JOBY  JOB  ,DR.KNOW
leading periods: //JOBZ  JOB  ,.X.Y.Z

*Use Two Consecutive Apostrophes
As with the accounting information parameter, names containing apostrophes require you to code two consecutive apostrophes.
For example,
//COMP    JOB  ,'O''RILEY'
becomes
O'RILEY







Topic 2.4: Unit 2 Summary

In this unit, you learned to code accounting information on a JOB statement and on an EXEC statement. You learned that on a JOB statement the accounting information parameter is the first positional parameter, and when you specify accounting information on the JOB statement, it applies to the entire job. You also learned the parameter is positional and may be required at an installation.
You learned the accounting information parameter has two subparameters that are defined at an installation to reflect its standards. You learned that if you omit the accounting information parameter and code the name parameter, then you code a placeholder comma for the first parameter, and conversely, if you omit the accounting information parameter and omit the name parameter, then you omit the placeholder comma.
You learned that the complete accounting information parameter can be no more than 143 characters, and that there are two ways to code subparameters with special characters. You learned that if you are using special characters such as an ampersand (&) or apostrophe (') in the accounting information parameter, then code two consecutive ampersands (&&) or apostrophes (''), and if you are continuing the accounting information parameter on another line, then enclose the entire parameter in parentheses and break the line at a comma separating subparameters.
You learned that when you code the accounting information on the EXEC statement, it only applies to that step within the job, and you learned to identify the submitter via the programmer's name parameter on the JOB statement. You also learned that if you code the name parameter, it must follow the accounting information parameter and precede all keyword parameters, and if you omit the name parameter, you don't have to code a placeholder comma.
And finally, you learned the name parameter must be 20 characters or less and to enclose the name in apostrophes if it contains special characters.

Unit 3. JOB Identification Options



In this unit, you will learn how to handle both remote and local job identification by using JES2 format to code the JOB statement and by using JES2 and JES3 statements.

After completing this unit, you should be able to:


Topic 3.1: Local Jobs

*Remember the Commas
Some JOB identification information can be interpreted and used by JES2 for jobs run locally. This can occur if you use JES2 format to code the JOB statement accounting information parameter. Supply the information as positional subparameters.
Remember, since these are positional subparameters, you must code placeholder commas for omitted subparameters if other subparameters follow.
//jobname JOB (<account number><,accounting-information>...)
                                            |
            (pano,room,time,lines,cards,forms,copies,log,linect)

*Run Jobs Locally
The information can also be interpreted and used by JES2 for jobs run locally in the following situations:


*What's Next?
Let's look at an explanation of each accounting information subparameter; for example, room time lines and its corresponding /*JOBPARM keyword parameter:
ROOM=xxxx TIME=nnnn LINES=nnnn

*Subparameters and Descriptions
Select a subparameter/parameter.
Examine the following table
Subparameter/Parameter Description
pano submitter's (programmer's) account number
room/ROOM submitter's (programmer's) room number
time/TIME estimated execution time
lines/LINES estimated line count from job's sysout data sets
cards/CARDS estimated number of cards to punch from job's sysout data sets
forms/FORMS forms to use for printing job's sysout data sets
copies/COPIES number of copies of job's sysout data sets
log/NOLOG printing of JOB log, no printing
linect/LINECT number of lines per page for job's sysout data sets

 

pano identifies the submitter's (programmer's) account number. It is from 1 to 4 alphanumeric characters. This is the only positional subparameter that doesn't have a keyword parameter equivalent on the /*JOBPARM statement.

 

room/ROOM=xxxx or R=xxxx identifies the submitter's (programmer's) room number. It is from 1 to 4 alphanumeric characters. The room number appears on the separator page to facilitate the delivery of the sysout data sets.

 

time/TIME=nnnn or T=nnnn indicates the approximate execution time in minutes. It is from 1 to 4 decimal numbers. If omitted, the installation default is used. If exceeded, a message is sent to the operator.

 

lines/LINES=nnnnnn or L=nnnnnn designates the approximate number of lines, in 1000s, from the job's sysout data sets. It is from 1 to 6 decimal numbers. If omitted, the installation default is used. If the limit is reached, control passes to an installation exit routine and the JOB may terminate.

 

cards/CARDS=nnnnnnnn or C=nnnnnnnn tells the number of cards to punch from the job's sysout data sets. It is from 1 to 8 decimal numbers. If omitted, the installation default is used. If the limit is reached, control passes to an installation exit routine and the JOB may terminate.

 

forms/FORMS=xxxxxxxx or FORMS=STD also F=xxxxxxxx or F=STD identifies which print/punch forms to use for sysout data sets. This setting is used when FORMS is not coded on the DD or JES2 /*OUTPUT statement. xxxxxxxx is 1 to 8 alphanumeric or national characters. STD is the installation default.

 

copies/COPIES=nnn or N=nnn designates how many times to print or punch the sysout data sets. It is 1 to 3 decimal numbers. The installation sets the limit, but the maximum is 255. If omitted, the default is one copy.

 

log/NOLOG or N determines whether a hard-copy of the JOB log prints. The subparameter N and the parameter NOLOG specify no JOB log.

 

linect/LINECT=nnn or K=nnn specifies the number of lines to print per page for the job's sysout data sets. It is 1 to 3 decimal numbers. If omitted, the installation default is used. If you set it to 0, JES2 does not eject to a new page when the line limit (set by the installation) is exceeded.


Now that you've had the opportunity to see an explanation of each accounting information subparameter and its corresponding /*JOBPARM keyword parameter, let's look at a few questions.











Topic 3.2: Remote Jobs

*JES2 Transmits the Network Account Number
The JES2 /*NETACCT statement supplies an account number for jobs sent to remote nodes for execution. JES2 transmits the network account number, with the job, to the remote node.
If you do not code a /*NETACCT statement, JES2 looks through a table for a network account number that is associated with your local account number.

*Use the /*NETACCT Parameter
For example, let's say that you are at your company's home office in Columbus, Ohio. You submit a JOB to run at a branch office that has the appropriate computing facilities.
This might require the use of a /*NETACCT parameter.

*Format the /*NETACCT Parameter
The format of the /*NETACCT statement is as follows:
/*NETACCT network-account-number
where network-account-number is 1 to 8 alphanumeric characters.







*The Default Value Is Used
The JES3 //*NETACCT statement supplies accounting information for jobs sent to remote nodes for execution. JES3 transmits the information, with the job, to the remote node.
If you do not code a //*NETACCT statement, JES3 uses your installation's default values.

*Run It Remotely
For example, suppose you are at the central computer center at a large university. Your JOB is a real number cruncher, so you want it to run on the super computer at another center.
This might require the use of a //*NETACCT statement.

*Format the //*NETACCT Statement
The format of the //*NETACCT statement is as follows:
//*NETACCT parameter<,parameter>...
The parameters are keyword parameters. Enclose a parameter in apostrophes if it contains special characters or embedded blanks.
The keyword parameters for the //*NETACCT statement are described on subsequent screens.

*Name, Number, and Address
//*NETACCT parameter<,parameter>...
where parameter can be as follows:
PNAME=name — the submitter's (programmer's) name 1-20 characters
ACCT=number — the network account number 1-8 characters
BLDG=address — the submitter's building address 1-8 characters

*Department, Room, and ID
//*NETACCT parameter<,parameter>...
where parameter can be as follows:
DEPT=dep — the submitter's department number 1-8 characters
ROOM=room — the submitter's room number 1-8 characters
USERID=userid — the submitter's network userid 1-8 characters
For example:  //*NETACCT PNAME=KIM,ROOM='L2/556'







Topic 3.3: Unit 3 Summary

In this unit, you learned how some JOB identification information could be interpreted and used by JES2 for jobs run locally. You learned that this could occur if you use JES2 format to code the JOB statement accounting information parameter and to supply the information as positional subparameters.
You also learned that the JES2 /*NETACCT statement supplies an account number for jobs sent to remote nodes for execution, and JES2 transmits the network account number, with the job, to the remote node. You learned that if you do not code a /*NETACCT statement, JES2 looks through a table for a network account number that is associated with your local account number.
You learned the JES3 //*NETACCT statement supplies accounting information for jobs sent to remote nodes for execution, and that JES3 transmits the information, with the job, to the remote node.
And finally, you learned that if you do not code a //*NETACCT statement, JES3 uses your installation's default values.

Unit 4. Job Resources and Performance



In this unit, you will learn the pieces of information that control a job's resources and performance. You'll learn how to code the parameters and JCL statements that control:
You'll also learn how to handle job resource and performance control by using JES2 and JES3 statements.

After completing this unit, you should be able to:


Topic 4.1: Selecting a Program Library

*Resources and Their Relation to Performance
This unit looks at the pieces of information that control a job's resources and performance. Specifically, you need to control
Examine the following table
Resources Performance Issues
Program library Job class assignment
Address space Selection priority
Processor Performance group assignment
   I/O-to-processing ratio


*JCL and Resources
This chart lists the JCL statements and parameters for resource and performance control that are covered in this unit.
Examine the following table
To select or control... JOB EXEC Other JCL
program library       JOBLIB DD
STEPLIB DD
address space REGION
ADDRSPC
parameters		 REGION
ADDRSPC
parameters		   
job class CLASS parameter      
selection priority PRTY parameter      
performance group PERFORM parameter      


*JES2/JES3 and Resources
These are the JES2 and JES3 statements used to control resource and performance.
Examine the following table
To control... JES2
Statements 		JES3
Statements
address space    LREGION on //*MAIN
processor SYSAFF on /*JOBPARM SYSTEM on //*MAIN
job class    CLASS on //*MAIN
selection priority /*PRIORITY   
I/O-to-processing ratio    IORATE on //*MAIN


*Identify the Program Library
These are the JOBLIB and STEPLIB DD statements used to identify the program library.
Examine the following table
To select... JOB   EXEC Other JCL
program library       JOBLIB DD
STEPLIB DD


*Let's Review
Before you look at how to identify program libraries, take a few moments to review the following:


*What Is a Program?
A program is a collection of instructions in a programming language — such as COBOL — that directs the computer to perform tasks.
Examples of tasks are


*Compile the Program
Before a computer can execute a program, the program has to be translated to machine language — the only language a computer understands. To accomplish this, you must go through several steps.
First — compile the program. This step translates the English-like program into an object module. This is a machine language module, but it's not yet executable.

*Link-Edit the Object Module
Next — link-edit the object module. This step translates the object module into an executable form and adds any routines it needs.
Subroutines to perform common tasks, input/output routines, and so on are added to create a load module.
The load module is now the executable program that you refer to in an EXEC statement.
But to execute, it must reside in a library.





*More About Load Libraries
Now let's find out more about load libraries by


*What Is a Library?
To execute, the program must be placed in a library. A library is a Partitioned Data Set (PDS). This is just one large data set that contains many members. In this case the members are executable programs.
The directory of the PDS contains a list of all the members. This is what the system uses to find the member requested. If the system cannot find the program, the job abnormally terminates.
Three types of libraries exist:
First, let's examine the two most common libraries: system and private.

*System Libraries
System libraries usually contain common utilities and system programs. They are system-owned and available to all users.
Therefore, the system can automatically locate and search them.
The most commonly used system library is
SYS1.LINKLIB

  //PRINTIT  JOB  0078963,TEST,TIME=(,45)
    
  :
*Use an EXEC Statement
If the program you are accessing is in a system library, then all you need is an EXEC statement to find it.
The job above accesses IEBGENER, a utility that comes with MVS. It is stored in a common system library and can be found automatically by the system.

*Private Libraries
The user-written programs at an installation are usually stored in private libraries. Private libraries are user-owned and separate from the system libraries. Thus, the system must be told what library to use before it can search for the program.
Two special DD statements,
JOBLIB and STEPLIB,
provide this function.



Topic 4.2: Defining a Library

  //PRINT  JOB
  
*The JOBLIB DD Statement
The JOBLIB DD statement defines a private library, which the system makes available to each step of a job. It must immediately follow the JOB statement.
The system looks in this library for the programs executed throughout the job. If the program cannot be found, the system then searches the system libraries. If the program is still not located, the job abnormally terminates.
The example above shows the proper way to code a JOBLIB DD statement.

  //PRINT   JOB
    
  //STEP1   EXEC PGM=PRINTIT
  
*The STEPLIB DD Statement
The STEPLIB DD statement defines a private library, which the system makes available to one job step in a job.
When a STEPLIB DD statement is used for a step and a JOBLIB DD statement for the entire job, the step library is searched first and then the system libraries.
The job library is not used for that step.
The example above shows both a JOBLIB and a STEPLIB DD statement.











*Consider Concatenation
You know what libraries are and how to retrieve information from one library via the JOBLIB and STEPLIB DD statements.
Consider concatenating several libraries so that you can retrieve from a list of libraries.
You probably noticed that the word libraries — rather than library — was used so far. The reason is that you can concatenate a list of libraries on either the JOBLIB or STEPLIB DD statements.
The system then searches the list of libraries in the order coded for the program(s) accessed in the job or step.

  //JOBLIB  DD DSN=ACCT.TEST.B43,DISP=SHR
  //        DD DSN=ACCT.TEST.GPR43,DISP=SHR
  //        DD DSN=ACCT.PROD,DISP=SHR
*Concatenate the Library List
To concatenate a list of libraries
In the example above, the system searches ACCT.TEST.B43 first, followed by ACCT.TEST.GRP43, and lastly ACCT.PROD.
All the other rules for searching libraries remain the same after the list is processed.



*Temporary Libraries
The last topic on libraries is the third type — temporary libraries.
A temporary library is created and deleted within a job. One job step creates a temporary library and passes it to a following job step or steps.
You often use temporary libraries while testing a program.
For example, you might be working with a team on a large project. You certainly don't want to store a version of a program that you aren't sure works in a library that others share.

  //COMPLT   JOB
    
  :
    
  :
  //SYSLMOD  DD DSN=&&TEMPLIB(PROG),DISP=(,PASS) ...
  :
    
  :
*An Example
Here is a jobstream that uses a temporary library. It shows a technique to compile, link-edit, test, and then discard your test program.
The job has three steps — COMP, LINK, and TEST. The system automatically deletes the temporary library at the end of the job. Let's see how you use a temporary library.

  //COMPLT   JOB
  //COMP   EXEC COMP
  :
  //LINK   EXEC PGM=IEWL
  :
   
  :
  //TEST   EXEC PGM=.LINK.SYSLMOD
  :
*The LINK Step
In the LINK step, the SYSLMOD DD statement creates a temporary library to hold the link-edited module.
The system assigns a name for your program and stores it in the temporary library. You will not be able to refer to it by name in later steps.

  //COMPLT   JOB
  //COMP   EXEC COMP
  :
  //LINK   EXEC PGM=IEWL
  :
  //SYSLMOD  DD DSN=&&TEMPLIB(PROG),DISP=(,PASS) ...
  :
    
  :
*The TEST Step
In the TEST step, the EXEC statement accesses the test module. The format looks very different from what you are used to. It is coded as a backwards reference to a DD statement.
Here is the format:
//stepname  EXEC  PGM=*.stepname.ddname
Use ...






Topic 4.3: Unit 4 Summary

In this unit, you learned how to use the JOBLIB and STEPLIB DD statements to identify the program library. You learned that you must compile and link-edit the program library to create a load module before your program can execute. You also learned the load module is now the executable program that you refer to in an EXEC statement, and to execute, the load module must reside in a library.
You also learned system libraries usually contain common utilities and system programs and are system-owned and available to all users. You learned the user-written programs at an installation are usually stored in private libraries, and that private libraries are user-owned and separate from the system libraries.
You learned the JOBLIB DD statement defines a private library, which the system makes available to each step of a job, and that the JOBLIB DD statement must immediately follow the JOB statement. You also learned the STEPLIB DD statement defines a private library, which the system makes available to one job step in a job.
You learned to concatenate a list of libraries and to code the ddname on the first statement, but to omit the ddname from all following DD statements in the list. You also learned that a temporary library is created and deleted within a job and one job step creates a temporary library and passes it to a subsequent job step or steps.
And finally, you learned to access a temporary library by coding a backwards reference to a DD statement with the format //stepname  EXEC  PGM=*.stepname.ddname.

Unit 5. Controlling the Address Space



In a previous unit, you learned how to select a program library via the JOBLIB and STEPLIB DD statements.
In this unit, you will learn how to control another resource a job needs — its address space.
You will learn that when a job is initiated, it is assigned a type of storage (virtual or real) called an address space. You will also learn the parameters that control the storage.

After completing this unit, you should be able to:


*Manage the Resources
Examine the following table
To control... JOB EXEC Other JCL
address space REGION
ADDRSPC
parameters		 REGION
ADDRSPC
parameters		   

Resource control of the address space is managed by the ADDRSPC and REGION parameters of the JOB and EXEC statements.
ADDRSPC controls the type of storage the job uses.
REGION controls the amount of storage available to the job.
Look first at the available types of storage.

Topic 5.1: Job Storage

*Two Types of Storage
MVS makes two types of storage available to a job.
Central or real storage is the integral part of the CPU that the system can access directly to retrieve or store instructions and data.
Virtual storage is addressable storage that appears to your program as real storage. In MVS, you may address up to 2 billion bytes of instructions and/or data.
The virtual addresses are mapped to central storage locations when accessed.

*Virtual Storage
Most programs run in virtual storage to make use of the larger addressing layout. In fact, it is the type of storage automatically given to a job.
In virtual storage, the program is broken up into 4K pages and transferred in and out of central storage as required. The system handles this paging behind the scenes so that it is transparent to you.
Only very special programs must reside in central storage. These are programs that cannot be paged because of complex program operations.
You must specifically request this type of storage.



*The ADDRSPC Parameter
The ADDRSPC parameter requests the type of storage the job will use. The format of the ADDRSPC parameter is as follows:
ADDRSPC=<VIRT/REAL>
VIRT requests virtual storage and allows the job to be paged. It is the default.
REAL requests central (real) storage and does not permit the system to page the job.

*Use the JOB or EXEC Statement
You can code the ADDRSPC parameter on the JOB and/or EXEC statement.
The JOB statement ADDRSPC setting is assigned to all steps in the job and overrides any ADDRSPC parameters coded on the job's EXEC statements.
Here is one example:
//J1  JOB  6372812,ONLINE,ADDRSPC=REAL
The system uses the ADDRSPC parameter coded on an EXEC statement only when the parameter was not coded on the JOB statement.
If your job has different storage requirements across steps, code the ADDRSPC parameter only on the EXEC statements.







*The REGION Parameter
Now let's consider the REGION parameter.
This parameter is directly related to the ADDRSPC parameter.
The ADDRSPC parameter specifies the type of storage used while the REGION parameter specifies the amount.

*Format the REGION Parameter
The REGION parameter specifies the amount of virtual or central storage needed in either K (kilobytes) or M (megabytes). If you do not code it, the JES installation default is used. The format for the REGION parameter is as follows:
REGION=<valueK/valueM>
valueK designates the storage amount in kilobytes.
A kilobyte is 1024 bytes. You may request from 1 to 2,096,128 kilobytes of storage. Code your request as a multiple of 4 or the system will round it up to the next 4K increment.
For example: //JHF  JOB  ,FRAN,REGION=128K

*Storage in Megabytes
valueM designates the storage amount in megabytes.
A megabyte is 1024 kilobytes. You may request from 1 to 2047 megabytes.
For example: //JHF  JOB  ,FRAN,REGION=2M

*Process Overrides
You can code the REGION parameter on the JOB and/or EXEC statement. The processing for overrides works in the same manner as the ADDRSPC parameter.
The JOB statement REGION setting is assigned to all steps in the job and overrides any REGION parameters coded on the job's EXEC statements.
The system uses the REGION parameter coded on an EXEC statement only when the parameter was not coded on the JOB statement.

*Specify REGION on EXEC Statements
If your job has different storage requirements across steps, it's preferable to code the REGION parameter only on the EXEC statements.
Coding REGION on the JOB statement can be wasteful. If the steps use widely varying amounts, the largest REGION size must be coded on the JOB statement. This allocates it for the entire job.
Leaving REGION off the JOB statement permits you to specify what's needed per step.







Topic 5.2: Controlling Performance

*Parameters That Affect Job Performance
You saw ways to select a program library and to control your job's address space. Now turn your attention to controlling the performance of your job. This section covers four JCL parameters that affect a job's performance.
Examine the following table
To control... JOB EXEC Other JCL
job class CLASS parameter      
selection priority PRTY parameter      
performance group PERFORM parameter PERFORM parameter   


CLASS and PRTY
These parameters control how your job performs.
On the JOB statement, CLASS designates the class in which the job will execute, and
PRTY designates a job's selection priority within its class.
On both the JOB and EXEC statements, PERFORM assigns a performance group to a class.
Because your job affects the mix of jobs in the system and the overall system performance, the definition and use of these parameters is often tightly managed by the installation. Please check with your systems staff to see how each is implemented at your installation.

*Let's Review CLASS
Spend a moment reviewing what you know about the CLASS parameter from the prior course in this series.
The CLASS parameter assigns a job class to your job.
The format for coding the CLASS parameter is
CLASS=jobclass
Jobclass is a one-character value containing a letter from A-Z or a number from 0-9.

*Input Queues
Each job class has its own input queue. When you submit your job, it is placed in an input queue where it waits to be selected by an initiator to be processed.
Each initiator is set to a list of job classes that it can select from.
If the input queue is held, no jobs can be selected until the queue is released.

CLASS Parameters
Examine the following table
Valid //UPDT  JOB  3457,FALLOWES,CLASS=A
//TEST  JOB  CLASS=0
Invalid //UPDT  JOB  3457,FALLOWES,CLASS=#1
//TEST  JOB  CLASS=(0)
Above you see several examples of CLASS parameters. Most installations assign a default job class if the CLASS parameter is omitted. For example, suppose the default class is A.
This JOB statement
//TEST  JOB  (1234,EDP),SMITH
results in the same job class assignment as
//TEST   JOB  (1234,EDP),SMITH,CLASS=A



*Job Characteristics
Each installation groups jobs that have like characteristics into classes. In this table , the job classes are separated by The example shows some of the characteristics an installation may look at, but certainly not all. Also, resources used by a job may be critical at one installation, but not at another.
Examine the following table
CLASS CODE RUN TIME TAPE DISK PRODUCTION TEST
1 5 min X X X   
2 > 5 min X X X   
A 5 min    X    X
B > 5 min    X    X
C > 5 min X X    X


*Maintain a Good Job Mix
By segregating jobs with similar characteristics, an installation can maintain a good mix of the jobs running at a given moment. This maintains system throughput and efficient use of resources.
What is important is that you find out your installation's standards and follow them.







*The PRTY Parameter
The PRTY parameter defines the job's input class selection priority.
The PRTY parameter can have the values
0 - 15 in JES2 and 0 - 14 in JES3.
Here is one example:
//UPDT  JOB  3457,FALLOWES,CLASS=A,PRTY=8

*Higher Priorities Prevail
Jobs with higher priorities will be selected before jobs with lower priorities.
If other jobs with the same priority as yours are already in the queue, your job has to get in line behind them!
So even using the highest priority doesn't mean that your job will be first in its queue.
Once the job is selected, the priority's function is finished. A job's priority does not affect its performance.
Your installation will set a default for this parameter and often limit its use in order to control system resources. It may even be ignored if used.









*The PERFORM Parameter
So far you've seen how to use the JOB statement parameters CLASS and PRTY to control a job's performance.
Now look at the PERFORM parameter which is available on the JOB and the EXEC statements.
Note that PERFORM is usually very restricted by an installation. Many installations go so far as to code exit routines that ignore the parameter or fail the job if specified.

*Format PERFORM
The PERFORM parameter assigns a job to a performance group. The format of this parameter is PERFORM=n.
The performance group can be set to a number from 1 to 999. The number must identify a performance group that is established at your installation.
Here is one example:
//J1  JOB  6372812,ONLINE,PERFORM=89

Performance groups control the job's access to system resources during execution. It therefore controls how quickly your job executes. Again, this parameter is regulated by the installation.
Your job is assigned a default performance group if you do not specify a performance group or if the one you specify is invalid.

*Coded on the JOB and EXEC Statements
You can code the PERFORM parameter on the JOB and/or EXEC statement.
The JOB statement performance group is assigned to all steps in the job and overrides any PERFORM parameters coded on the job's EXEC statements.
The system uses the PERFORM parameter coded on an EXEC statement only when the parameter was not coded on the JOB statement.
If your job has different performance group requirements, code the PERFORM parameter only on the EXEC statements.









Topic 5.3: Unit 5 Summary

In this unit, you learned that when a job is initiated it is assigned a type of storage (virtual or real) called an address space, and that resource control of the address space is managed by the ADDRSPC and REGION parameters of the JOB and EXEC statements.
You also learned that central or real storage is the integral part of the CPU the system can access directly to retrieve or store instructions and data, and virtual storage is addressable storage that appears to your program as real storage. You learned the ADDRSPC parameter requests the type of storage the job will use.
You learned that REGION parameter specifies the amount of virtual or central storage needed in either K (kilobytes) or M (megabytes) and if you do not code it, the JES installation default is used.
And finally, you learned the parameters on the JOB and EXEC statements that control a job's performance, including the CLASS, PRTY, and PERFORM parameters.

Unit 6. Resource And Performance Control Options



In this unit, you will learn how to use JES2 and JES3 options for job resource and performance control.
The job resource and performance control determine how jobs are processed, ordered, sized, and executed.

After completing this unit, you should be able to:


Topic 6.1: Processing, Ordering, and Sizing Jobs

*The SYSAFF Parameter
The SYSAFF parameter on the /*JOBPARM statement specifies the system or systems that can process the job.
From 1 to 7 system affinities can be specified. Affinity is a way of identifying a specific CPU on which the job is to execute. It is normally used in environments where there are some processors with special features.
For example, there might be a processor with a lot of available storage. Another example is when there might be certain types of devices that are available only on a particular CPU.
In these cases, you could use affinity to run the job on a particular CPU.

*Format SYSAFF
The basic format of the SYSAFF parameter is
SYSAFF=affinity
affinity can be


*Code IND
To specify more than one system, you code each system id separated with commas. You enclose the entire list in parentheses. Here is the format.
SYSAFF=(cccc,cccc,...)
You can code IND after any of the other SYSAFF specifications. For example,
SYSAFF=(ANY,IND)
IND indicates that JES2 is to use system scheduling in independent mode. Note that you enclose the subparameters in parentheses when you code IND.





*Use JES2 /*PRIORITY
You may use the JES2 /*PRIORITY statement to set a job's selection priority rather than the PRTY parameter. Both perform the same function.
The format for this statement is
/*PRIORITY p
p  indicates the priority
Valid values are 0 to 15.

/*PRIORITY Precedes the JOB Statement
The /*PRIORITY statement must immediately precede the JOB statement. It overrides the PRTY parameter specified on the JOB statement.
If you incorrectly code the statement, that is you code a value other than 0 to 15 or you do not code the statement immediately before the JOB statement, all following statements up to the next JOB statement are flushed.









*The LREGION Parameter
You use the //*MAIN statement to control the address space or processor of a job.
Look first at the LREGION parameter. The LREGION parameter allows you to specify an approximate size for the largest step's central storage requirements. The format for this parameter is
LREGION=nnnnK
nnnn  indicates the size in kilobytes (1024 bytes).

*Use LREGION on the //*MAIN Statement
Why would you use the LREGION parameter?
Assume you have a jobstream containing several steps for statistical analysis. Several steps have very large storage requirements.
In this case, you can use LREGION on the //*MAIN statement to specify the largest amount of storage used by any step.
You must use the LREGION parameter carefully. JES3 uses it to improve job scheduling. If it is too small, your job may take longer to run.



Topic 6.2: Executing, Naming, and Processing Jobs

*The SYSTEM Parameter
You saw how the LREGION parameter controls the address space.
Now look at the //*MAIN statement parameter which controls the processor for a job. The SYSTEM parameter specifies the system or systems that will execute the job.
If omitted, the job runs on the processor used for the job's class.
The SYSTEM parameter is only required if a UNIT parameter specifies a device number.

*Format SYSTEM=processor
The format of the SYSTEM parameter is SYSTEM=processor.
In the processor value you specify the desired system as follows:






*The CLASS Parameter
The CLASS and IORATE parameters of the //*MAIN statement control job performance characteristics. Look first at the CLASS parameter.
The CLASS parameter specifies a 1-8 character class name for a job. If it is only one character, you may specify the class name on the JOB statement.
The //*MAIN CLASS parameter, however, takes precedence over the CLASS parameter coded on the JOB statement.
The format of the CLASS parameter is CLASS=class-name...





*More Parameters
You've seen how the CLASS parameter on the //*MAIN statement controls job performance characteristics.
Let's see now how the IORATE parameter works.

*The IORATE Parameter
The IORATE parameter indicates the I/O-to-processor rate of the job. JES3 uses this information to schedule jobs and maintain a balanced mix in the processor.
A proper mix of I/O-bound and processor-bound jobs improves system throughput.
The format for the IORATE parameter is
IORATE=rate
rate can be MED, HIGH or LOW.
If omitted, your installation's default is used. You should generally use your installation's default for this parameter.



Topic 6.3: Unit 6 Summary

In this unit, you learned to use JES2 and JES3 options for resource and performance control. These options include:
JES3 uses this information to schedule jobs and maintain a balanced mix in the processor.