JCL JECL Statements: JES2 and JES3 Quick Reference

/*JOBPARM LINES=100 does not run a program, allocate a data set, or define a job step. It gives JES2 an input-processing instruction. That distinction is the key to reading JCL JECL statements correctly: JCL describes the job to z/OS, while JECL controls how the Job Entry Subsystem accepts, routes, schedules, and handles that job or its output.

JECL directs the job-entry subsystem around the JCL job stream.

What is Job Entry Control Language?

Job Entry Control Language (JECL) is the set of subsystem-specific control statements recognized by JES2 or JES3. These statements can affect input processing, execution routing, output destination, operator communication, network accounting, and remote sessions. They are placed in or around a job stream, but they are not ordinary JOB, EXEC, or DD statements.

The active subsystem matters. A JES2 statement beginning with /* should not be assumed to work under JES3, and a JES3 statement beginning with //* is not a portable substitute. IBM notes that most installations use JES2, but a job must follow the subsystem and local standards that actually process it.

Start with the environment: confirm JES2 or JES3, the permitted statements, destination names, output classes, and security rules before copying any JECL example into production.

JCL versus JECL

Question	JCL	JECL
What does it describe?	The job, program steps, data sets, procedures, and output definitions.	How JES receives, schedules, routes, transmits, or manages the input and output.
Common forms	//name JOB, //name EXEC, //ddname DD, //name XMIT.	JES2 /*keyword and JES3 //*keyword forms.
Portability	Core syntax is defined for z/OS JCL, subject to product and site resources.	Closely tied to JES2, JES3, NJE configuration, and installation policy.
Who diagnoses it?	The JCL converter, initiator, program, or allocation services may report the problem.	JES messages and the job log usually show how the subsystem interpreted the control.

Use the JCL tutorial for JOB, EXEC, and DD statements when the question is about the job itself. Use this page when the question is which JES control statement applies.

JES2 JECL statements quick reference

JES2 control statements normally begin with /* in columns 1 and 2. Since z/OS 2.1, the converter assigns statement numbers to supported JES2 JECL statements and can include those numbers in related messages. That change improves diagnosis, but the statements remain JES2 controls.

JES2 statement	Primary purpose
/*$command	Enter a JES2 operator command from the input stream.
/*JOBPARM	Supply JES2 job-related values such as output limits, forms, copies, or system affinity.
/*MESSAGE	Send a message to the operator.
/*NETACCT	Provide a network account number for NJE processing.
/*NOTIFY	Request notification for a remote user.
/*OUTPUT	Set JES2 output-processing characteristics.
/*PRIORITY	Assign the job-selection priority permitted by the installation.
/*ROUTE	Route print or punch output, or route a job for execution.
/*SETUP	Request setup activity such as volume mounting before execution.
/*SIGNOFF	End a remote job-entry session.
/*SIGNON	Begin a remote job-entry session.
/*XEQ	Route the following job to another network node for execution.
/*XMIT	Transmit an input stream or records to another network node.

JES2 JOBPARM example

//RPTJOB  JOB  (ACCT),'MONTHLY REPORT',
//              CLASS=A,MSGCLASS=X,PAGES=200
/*JOBPARM       LINES=100,BYTES=10000
//STEP1   EXEC  PGM=RPT100
//SYSPRINT DD   SYSOUT=*

In this IBM-style pattern, /*JOBPARM supplies JES2 output limits that are absent from the JOB statement. Where the same supported limit appears in both places, the JOB parameter takes precedence over /*JOBPARM; the JECL value can in turn override the JES2 initialization default. Values and enforcement can be changed by installation policy, so treat limits as controls to verify, not universal constants.

JES2 routing examples

/*ROUTE PRINT PRTBIG
/*ROUTE XEQ NODE2
/*XEQ NODE2

The first pattern routes printed output to a destination identifier defined by the installation. The next two request execution at another NJE node. A destination such as PRTBIG or NODE2 must exist at the site; copying the name from another system does not create it.

For transmission details, see the focused JCL XMIT statement guide. IBM recommends the subsystem-independent //name XMIT JCL form for new work when its functions meet the requirement.

JES3 JECL statements quick reference

JES3 control statements generally use the recommended //* prefix. Sign-on and sign-off retain the /* form, while JES3 commands use //**. Some installations can accept alternate forms for selected statements, but local standards can disallow them. Code the documented form rather than relying on permissive initialization settings.

JES3 statement	Primary purpose
//**command	Enter a JES3 command from the input stream.
//*DATASET	Mark the start of an input data set handled by JES3.
//*ENDDATASET	Mark the end of that JES3 input data set.
//*ENDPROCESS	End a group of JES3 PROCESS statements.
//*FORMAT	Describe formatting and routing for output.
//*MAIN	Supply JES3 job scheduling and resource information.
//*NET	Define dependencies within a JES3 dependent-job network.
//*NETACCT	Provide network-account information.
//*OPERATOR	Send information associated with the job to the operator.
//*PAUSE	Pause input reading so an operator action can occur.
//*PROCESS	Request JES3 batch-support processing.
//*ROUTE	Route a job for execution or direct its output.
/*SIGNOFF	End a remote session.
/*SIGNON	Begin a remote session.

JES3 scheduling and output example

//RUN2     JOB  (ACCT),'WRITER JOB',MSGCLASS=A
//*MAIN    CLASS=B
//*FORMAT  PR,DDNAME=STEPA.DD2,DEST=ANYLOCAL,COPIES=5
//STEPA    EXEC PGM=WRITER
//DD1      DD   DSN=APP.INPUT,DISP=SHR
//DD2      DD   SYSOUT=A

//*MAIN provides JES3 scheduling information, while //*FORMAT associates formatting and destination instructions with selected output. The statement operands are not interchangeable with JES2 /*JOBPARM or /*OUTPUT. Validate the expanded input and JES messages on the target system.

Placement and processing rules

• Begin in column 1: leading blanks can turn a control statement into ordinary input rather than JECL.
• Place it where JES expects it: JES3 control statements other than command and pause controls generally follow the JOB statement and any continuation records. A misplaced statement can be ignored or rejected.
• Keep the routed job together: execution-routing controls such as /*XEQ or //*ROUTE XEQ apply to the following job stream according to subsystem rules.
• Do not assume execution timing: placing an operator command in submitted input does not make it a synchronized job step. Use job logic or automation designed for sequencing when order is required.
• Check job-group restrictions: JES2 job groups cannot contain JECL statements; their supported job-group JCL is a separate facility.

If your task is specifically to enter an MVS or JES command, compare the JCL command quick reference. IBM prefers the JCL COMMAND statement for supported commands within JCL.

Choose the right statement

Task	Likely control	Check before use
Set JES2-wide job output attributes or limits	/*JOBPARM or supported JOB/OUTPUT parameters	Override precedence and site limits
Route JES2 print or punch output	/*ROUTE PRINT or /*ROUTE PUNCH	Valid destination identifier
Send work to another NJE node	JCL XMIT, JES2 /*XEQ, or JES3 //*ROUTE XEQ	Receiving subsystem, node, delimiter, and network policy
Supply JES3 scheduling requirements	//*MAIN	Class, resource, and installation definitions
Describe JES3 output formatting	//*FORMAT	DD name, destination, forms, and copies
Define ordinary program execution	EXEC, not JECL	Program or procedure name and parameters

The JCL EXEC statement guide covers program and procedure invocation, while the JCL JOB statement guide covers job-level JCL parameters.

Common JECL errors

• Wrong subsystem: the job contains a JES2 control statement but enters through JES3, or the reverse.
• Wrong prefix: /*, //*, and //** are not cosmetic variations.
• Bad placement: a valid statement appears before the JOB card, after the data it should govern, or between the wrong records.
• Unknown destination: a route code, node, remote, printer, or user ID is not defined for that network.
• Site policy rejection: initialization settings or exits override, restrict, or ignore user-supplied values.
• JCL and JECL confused: a routing statement is expected to control program flow, or an EXEC statement is expected to select a JES resource.
• Old example copied literally: a node name, output class, form, account, or device from documentation is not valid locally.

Production check: read the JES messages and job log after submission. A syntactically accepted control can still be changed or refused by the installation.

JECL review checklist

1. Identify whether JES2 or JES3 processes the input.
2. Confirm the documented prefix, operands, continuation rules, and position.
3. Verify every node, destination, class, form, remote, and account value locally.
4. Check whether equivalent JOB, OUTPUT, COMMAND, or XMIT JCL is preferred.
5. Review parameter precedence when both JCL and JECL specify the same function.
6. Use the converter and JES messages to confirm what the subsystem accepted.

For nearby topics, the JCL parameter-field guide explains positional and keyword syntax, and the specific-system scheduling guide expands on system affinity.

Official IBM references

• IBM: JECL statements for JES2 and JES3
• IBM: JES2 compared with JES3
• IBM: Defining JES2 output limits
• IBM: Executing at a remote node
• IBM: JES3 control-statement examples

JCL JECL statements FAQ

What are JECL statements in JCL?

Job Entry Control Language statements give the active Job Entry Subsystem instructions about input, routing, scheduling, messages, or output. They supplement the JCL that defines the job and its steps.

What prefix identifies a JES2 JECL statement?

Most JES2 control statements start with slash-asterisk in columns 1 and 2, followed by a keyword such as JOBPARM, ROUTE, XEQ, or XMIT.

Are JES2 and JES3 JECL statements interchangeable?

No. Many names, prefixes, operands, and placement rules differ. Confirm which JES subsystem processes the input and which options the installation permits.

Should new network-routing JCL use XMIT or JECL?

IBM recommends the JCL XMIT statement for new work when its functions are sufficient because that form is not tied to one JES subsystem. Existing JECL routing remains site and subsystem dependent.

JECL is useful when its scope is explicit: name the subsystem, choose the matching control, and verify the result in JES rather than treating every slash-asterisk statement as portable JCL.