Those positional parameters can be used in the JCL JOB statement

CLASS

During JES initialisation job classes can be defined with each class having its own characteristics.

When creating a job you should assign the job to a class, so that a correct initiator can pick it up

This should be done as CLASS=K parameter (setting the job to be of the "K" class)\

Class names can be a number 0-9, a letter or a one to eight character name.

MSGCLASS

This parameter is easy to confuse with CLASS, however it does something different.
Instead of classifying the job itself, this parameter is used to assign the job's log to an output class. This is what you look at in SDSF to determine if the job ran well.
The exact class you should be using is likely dictated by your organisation.

If you do not use the parameter, a default will be used, however it is a good idea to assign this parameter so you can easily find the output.

An output class can dictate if the output should be held, simply dumped into SDSF log, or even use the DUMMY option, which would discard it.

MSGLEVEL

This parameter can be used to dictate how much (or little) output you want to be logged.
The default is usually MSGLEVEL=(1,1) which will show all JCL statements and messages.
Setting the first subparameter to 0 (0,1) would only produce the JOB statement and any comments that appear before the first step
Setting it to 2 will produce JCL and JES statements but not procedure statements.

Setting the second subparameter to 0 will produce only JCL messages, unless the job files, then the situation SMS messages will also be shown,

LINES

LINES=(10,WARNING) would produce a warning if over 10 (thousand) lines of output were created.
The job would continue in this option and operator messages would be sent in regular intervals
LINES=(20,CANCEL) would cancel the job when the limit of 20 thousand output lines is exceeded
LINES=(20,DUMP) would do the same, creating a dump in the process.

PAGES

This parameter can be used the same as LINES, but for pages of output instead

REGION

Every program will need different amounts of memory to run.
In some organisations the REGION parameter can be used to cap it.
REGION=0M or REGION=0K provides every program specified wit has much memory as required. Depending on the requirements you can specify the exact values to limit it.
If not provided then a JES initialisation default will take effect

REGIONX

This parameter can be used for fine tuning the amount of memory that would be provided to the job. You can use it when you know how much memory above and below the 16MB line you need e.g.
REGIONX=(4M,256M)

ADDRSPC

By default your program will use virtual, pageable memory.
With ADDRSPC=REAL you can set it so the real memory is used (making it not pageable)

MEMLIMIT

This can be used to place a limit on the total size of usable virtual storage above the bar in a single address space
MEMLIMIT=10000M

NOTIFY

When you submit the job most people would want to be notified when it's completed. This one is straightforward
You specify the TSO user ID as the value of the parameter
NOTIFY=IBMUSER
There's a good chance you will see &SYSUID used as the value. This symbol will get resolved at the time of submitting the job and notify the user who submitted it each time

This parameter is simple but has some drawbacks

• If the user is not logged on the message will not be sent until they log in
• The parameter can only be used to notify a single user
• There is no default, if you forget it, you need to check if the job completed in another way

In z/OS 2.3 the statement was expanded and introduced as a statement, JCL overview#NOTIFY statement

TYPRUN

This parameter can be used in order to prevent the job from running immediately after being submitted (and resources being available).

TYPRUN=HOLD will instruct the system to hold the job you submitted until a manual release. For example if you have the authority to submit a job, but will be busy at a certain time when the job should be run, you can submit the job with this parameter and instruct an operator, who can release the job (but not submit it themselves) to release it at the appropriate time (The job will immediately fail if the syntax is incorrect and would not be held)

TYPRUN=SCAN will check the JCL you are submitting for syntax errors, just like when submitting the job in a normal way, however the job will not be run afterwards. (although an output copy of the JCL will be produced in SDSF output)

TYPRUN=COPY this parameter will copy the JCL directly to sysout, which can be then displayed through SDSF. It will not check for syntax errors

TYPRUN=JCLHOLD is similar to the HOLD value, however the job will be held prior to being converted by JES2. This means that any syntax errors would only become apparent after the job has been released.

if this parameter is not submitted, the job will run immediately and fail if the syntax has errors.

TIME

This parameter can be used to ensure that the job you submitted will not run for longer than expected (for example when testing a program which may end up looping infinitely). It will specify the maximum amount of CPU time (not real time) that the job is allowed to execute for.

TIME=(1,30) will set this value to be 1 minute and 30 seconds.
The 'minutes' part of the value must be between 0 and 357913, while the seconds between 0 and 59.
The 'minutes' value of the subparameter can be omitted with a comma.
If we only want to specify an amount in minutes, the 'seconds' part can be omitted completely, for example TIME=2 signifying 2 minutes flat.

If the job exceeds the time set using this parameter it will abend with the code of 322.

In order to determine what limit would be appropriate for the script that you're testing / creating, you can find the value of CPU time in the log after the job has run

Setting the parameter to TIME=NOLIMIT will indicate that the job should not be constrained in how long it is allowed to run.

Setting the parameter to TIME=MAXIMUM will is a shorthand for TIME=357912, the maximum amount of minutes the job would be allowed to run for.

COND

JCL allows you to be pretty specific about the completion codes for each program in the script and what should happen in all ocassions (for example when there's no point in continuing the processing if a previous stage fails). the COND parameter can be used to achieve this.

COND=(4,LT) will use the LT (Less Than) operation on the condition code returned by a statement and the first subparameter to determine what to do.
If the returned code is 0 (which is less than 4), the condition is satisfied, therefore the execution continues

PRTY

This parameter can be used to "skip the queue" of waiting for an initiator of the correct class to become available. It defines the priority of the job submitted. In general users would not be able to set the priority of their jobs (everyone would try to be the highest priority after all), but with the permissions to do so you can define the priority of your job

For a JES2 site you can enter a value from 0 to 15 (with 15 being the highest priority)

In JES3 systems the range is 0 to 14

(Depending on the standards of the organisation the system might ignore this parameter)

RESTART

When you submit a job, it runs top to bottom, executing the programs coded in a sequence. However in some cases, the program might fail a few steps (and quite some time) in, making it a massive waste of time to try and run it all again.

If your program has steps that would not need to be repeated (for example if the first step is to make a backup copy of the data before working on it) after completing successfully, you can use the RESTART parameter.

You can use it to specify which step name (the first thing on the line after //) should the restart of the job run

SYSAFF

When submitting a job, the system assumes that it is to run on the system it was submitted to.
With this parameter you can specify which other systems of the organisation this job can run (for example if there are no initiators or resources available on the one it was submitted to).
SYSAFF=(S0W1,S0W2) would indicate that the job is allowed to run on the S0W1 and S0W2 systems

A reverse of this syntax,SYSAFF=(-S0W1) would indicate that the job can be processed by any member expect S0W1.

Maximum of 33 names can be specified.

SYSTEM

Similarly to SYSAFF it defined the systems where the job can be processed.
Up to 32 eight character system names can be used and a minus sign in front of it indicates that the job can't run on that system.
SYSTEM=(NEWYTEST,SEATTEST,-NEWYPROD) would allow the job to run on the first 2 and disallow it from running on the last one.

value of ANY indicates that any eligible system.

There are 2 more values that are used in JES3 environments.
JGLOBAL - global procesor only
JLOCAL - local processor only

SCHENV

This parameter can set the scheduling environment.
Those environments can be defined in the Workload Management policy that is set of the system.

USER

While the system will default to the user that is submitting the job, you can submit jobs as another user with this parameter. You will need to supply the password parameter as well
USER=GREG

PASSWORD

This parameter will store the password for the user specified with the user parameter
PASSWORD=TESTPASS
The password will be entered and stored there, visible to anyone who can read the job file. It will not be outputted into the log.

GROUP

If RACF defined groups are being used this parameter can assign the TSO user to an alternate group that the default
GROUP=TESTER

EMAIL

This parameter can be used instead of the USER parameter to specify the user
EMAIL=gman@natwest.com

SECLABEL

There might be some additional security requirements in order to run the job. This parameter can be used to specify the security level at which the job should run,
The level should be a predefined RACF security leve.
SECLABEL=MGMT