z/OS IBM

MVS JCL Reference

SA22-7597-02
z/OS IBM

MVS JCL Reference

SA22-7597-02
 Note
Before using this information and the product it supports, be sure to read the general information under “Notices” on
page B-1.

Third Edition, March 2002

This is a major revision of SA22-7597-01.
This edition applies to Version 1 Release 3 of z/OS (5694-A01) and to all subsequent releases and modifications
until otherwise indicated in new editions.
Order publications through your IBM representative or the IBM branch office serving your locality. Publications are
not stocked at the address below.
IBM welcomes your comments. A form for readers’ comments may be provided at the back of this publication, or you
may address your comments to the following address:
International Business Machines Corporation
Department 55JA, Mail Station P384
2455 South Road
Poughkeepsie, NY 12601-5400
United States of America

FAX (United States & Canada): 1+845+432-9405

FAX (Other Countries):
Your International Access Code +1+845+432-9405

IBMLink (United States customers only): IBMUSM10(MHVRCFS)

Internet e-mail: [email protected]
World Wide Web: http://www.ibm.com/servers/eserver/zseries/zos/webqs.html
If you would like a reply, be sure to include your name, address, telephone number, or FAX number.
Make sure to include the following in your comment or note:
v Title and order number of this book
v Page number or topic related to your comment
When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 1988, 2002. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii

About This Book . . . . . . . . . . . . . . . . . . . . . . . xxxv

Who Should Use This Book . . . . . . . . . . . . . . . . . . . xxxv
Related Information . . . . . . . . . . . . . . . . . . . . . . xxxv
Programs . . . . . . . . . . . . . . . . . . . . . . . . . xxxv
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . xxxv
Accessing licensed books on the Web . . . . . . . . . . . . . . . xxxvi
Using LookAt to look up message explanations . . . . . . . . . . . . xxxvi

Summary of changes . . . . . . . . . . . . . . . . . . . . . xxxix

Chapter 1. Job Control Statements . . . . . . . . . . . . . . . . 1-1

JCL Statements . . . . . . . . . . . . . . . . . . . . . . . . 1-1
JECL Statements . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Chapter 2. Job Control Tasks . . . . . . . . . . . . . . . . . . 2-1

Entering Jobs . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Processing Jobs . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Requesting Resources . . . . . . . . . . . . . . . . . . . . . . 2-2
Task Charts . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Chapter 3. Format of Statements . . . . . . . . . . . . . . . . . 3-1

JCL Statement Fields . . . . . . . . . . . . . . . . . . . . . . 3-1
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 3-3
JES2 Control Statement Fields. . . . . . . . . . . . . . . . . . . 3-4
JES3 Control Statement Fields. . . . . . . . . . . . . . . . . . . 3-4
Continuing Statements . . . . . . . . . . . . . . . . . . . . . . 3-4
Continuing JCL Statements . . . . . . . . . . . . . . . . . . . 3-4
Examples of Continued Statements . . . . . . . . . . . . . . . . 3-5
Continuing JES2 Control Statements . . . . . . . . . . . . . . . 3-6
Continuing JES3 Control Statements . . . . . . . . . . . . . . . 3-6

Chapter 4. Syntax of Parameters . . . . . . . . . . . . . . . . . 4-1

Notation Used to Show Syntax . . . . . . . . . . . . . . . . . . . 4-1
Character Sets. . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Syntax Notes . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Backward References . . . . . . . . . . . . . . . . . . . . . . 4-5
Examples of Backward References . . . . . . . . . . . . . . . . 4-6

Chapter 5. Procedures and Symbols . . . . . . .. 5-1 . . . . . . . .

Cataloged and In-Stream Procedures . . . . . . .. 5-1 . . . . . . . .
In-stream Procedures . . . . . . . . . . . .. 5-1 . . . . . . . .
Cataloged Procedures . . . . . . . . . . . .. 5-1 . . . . . . . .
Using a Procedure . . . . . . . . . . . . .. 5-2 . . . . . . . .
Testing a Procedure . . . . . . . . . . . . .. 5-2 . . . . . . . .
Modifying Procedures . . . . . . . . . . . . .. 5-3 . . . . . . . .
Explanation . . . . . . . . . . . . . . . .. 5-3 . . . . . . . .
Examples of Procedures . . . . . . . . . . .. 5-7 . . . . . . . .
Nested Procedures . . . . . . . . . . . . . .. 5-9 . . . . . . . .
Nesting Procedures . . . . . . . . . . . . .. 5-9 . . . . . . . .
Modifying Nested Procedures . . . . . . . . . . . . . . . . . . 5-10
Examples of Modifying Nested Procedures . . . . . . . . . . . . . 5-10

© Copyright IBM Corp. 1988, 2002 iii

 Using System Symbols and JCL Symbols . . . . . . . . . . . . . . 5-12
What are System Symbols? . . . . . . . . . . . . . . . . . . 5-12
What are JCL Symbols?. . . . . . . . . . . . . . . . . . . . 5-13
Coding Symbols in JCL . . . . . . . . . . . . . . . . . . . . 5-17
Determining Equivalent JCL . . . . . . . . . . . . . . . . . . 5-19
Examples of Defining and Coding Symbols in JCL . . . . . . . . . . 5-24
Using Symbols in Nested Procedures . . . . . . . . . . . . . . . 5-26
Examples of Coding Symbols in Nested Procedures . . . . . . . . . 5-27

Chapter 6. Job Control Statements on the Output Listing . . . . . . . 6-1

Chapter 7. Started Tasks . . . . . . . . . . . . . . . . . 7-1. . .

Determining Whether to Use a Started Task . . . . . . . . . . . 7-1. . .
Determining the Source JCL for the Started Task . . . . . . . . . 7-1. . .
START Command Processing when the Member is a Procedure . . 7-2. . .
START Command Processing when the Member is a Job . . . . . 7-3. . .
Review Current Started Tasks . . . . . . . . . . . . . . . 7-3. . .
Convert Procedures to Jobs (Optional) . . . . . . . . . . . . 7-3. . .
Determining System Services for a Started Task . . . . . . . . . 7-5. . .
Deciding Under Which Subsystem a Started Task Should Run . . . 7-5. . .
Running a Started Task Under a Job Entry Subsystem . . . . . . 7-6. . .
Running a Started Task Under the Master Subsystem . . . . . . 7-6. . .
Running a Started Task That Uses ICF Catalogs . . . . . . . . 7-7. . .
Set Up the Master JCL . . . . . . . . . . . . . . . . . 7-7. . .
Coding the JCL . . . . . . . . . . . . . . . . . . . . . 7-7. . .
Coding the JOB Statement for the Started Task . . . . . . . . 7-7. . .
Using Symbols in Started Task JCL . . . . . . . . . . . . . 7-8. . .
Naming a Started Task (Source JCL is a Job) . . . . . . . . . . . . . 7-11
Setting Up Operator Education for Your Started Task . . . . . . . . . . 7-12

Chapter 8. JCL Command Statement. . . . . . . . . . . . . . . . 8-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 8-1
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 8-2
Comments Field . . . . . . . . . . . . . . . . . . . . . . . 8-2
Location in the JCL . . . . . . . . . . . . . . . . . . . . . . 8-2
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Examples of the Command Statement . . . . . . . . . . . . . . . 8-2

Chapter 9. COMMAND Statement . . . . . . . . . . . . . . . . . 9-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Name Field . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 9-2
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 9-2
Comments Field . . . . . . . . . . . . . . . . . . . . . . . 9-2
Location in the JCL . . . . . . . . . . . . . . . . . . . . . . 9-2
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Examples of the COMMAND Statement . . . . . . . . . . . . . . 9-3

Chapter 10. Comment Statement . . . . . . . . . . . . . . . . . 10-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 10-1
Listing of Comments Statements . . . . . . . . . . . . . . . . 10-1

iv z/OS V1R3.0 MVS JCL Reference

 Examples of the Comment Statement . . . . . . . . . . . . . . . 10-1

Chapter 11. CNTL Statement . . . . . . . . . . . . . . . . . . 11-1

Description. . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Label Field. . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 11-1
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 11-1
Comments Field . . . . . . . . . . . . . . . . . . . . . . . 11-1
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 11-2
Program Control Statements . . . . . . . . . . . . . . . . . . 11-2
Program Control Statements in Procedures . . . . . . . . . . . . . 11-2
Example of the CNTL Statement. . . . . . . . . . . . . . . . . 11-2

Chapter 12. DD Statement . . . . . . . . . . . . . . . . . . . 12-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
Name Field . . . . . . . . . . . . . . . . . . . . . . . . 12-1
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 12-3
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 12-3
Comments Field . . . . . . . . . . . . . . . . . . . . . . 12-15
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 12-15
Examples of DD Statements and ddnames . . . . . . . . . . . . 12-18
* Parameter . . . . . . . . . . . . . . . . . . . . . . . . . 12-18
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-19
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-19
Relationship to Other Control Statements . . . . . . . . . . . . . 12-20
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 12-20
Unread Records . . . . . . . . . . . . . . . . . . . . . . 12-21
Examples of the * Parameter . . . . . . . . . . . . . . . . . 12-21
ACCODE Parameter . . . . . . . . . . . . . . . . . . . . . 12-22
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-22
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-22
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-22
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 12-23
Example of the ACCODE Parameter. . . . . . . . . . . . . . . 12-23
AMP Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-23
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-25
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-30
Buffer Requirements. . . . . . . . . . . . . . . . . . . . . 12-30
Examples of the AMP Parameter . . . . . . . . . . . . . . . . 12-30
AVGREC Parameter. . . . . . . . . . . . . . . . . . . . . . 12-31
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-31
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-31
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 12-32
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-32
Examples of the AVGREC Parameter . . . . . . . . . . . . . . 12-32
BLKSIZE Parameter. . . . . . . . . . . . . . . . . . . . . . 12-32
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-33
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-33
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-33
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 12-33
Relationship to Other Control Statements . . . . . . . . . . . . . 12-33
Coexistence Considerations . . . . . . . . . . . . . . . . . . 12-34

Contents v
 Examples of the BLKSIZE Parameter . . . . . . . . . . . . . . 12-34
BLKSZLIM Parameter . . . . . . . . . . . . . . . . . . . . . 12-34
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-34
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-34
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-35
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-35
Example of the BLKSZLIM Parameter . . . . . . . . . . . . . . 12-35
BURST Parameter . . . . . . . . . . . . . . . . . . . . . . 12-35
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-36
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-36
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-36
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 12-36
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-36
Relationship to Other Control Statements . . . . . . . . . . . . . 12-36
Example of the BURST Parameter . . . . . . . . . . . . . . . 12-36
CCSID Parameter . . . . . . . . . . . . . . . . . . . . . . 12-37
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-37
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-37
Default. . . . . . . . . . . . . . . . . . . . . . . . . . 12-37
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-37
Examples of the CCSID Parameter . . . . . . . . . . . . . . . 12-38
CHARS Parameter . . . . . . . . . . . . . . . . . . . . . . 12-39
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-40
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-40
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-40
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 12-40
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-41
Relationship to Other Control Statements . . . . . . . . . . . . . 12-41
Printing Device Reassignment . . . . . . . . . . . . . . . . . 12-41
Requesting a High-Density Dump . . . . . . . . . . . . . . . . 12-41
Examples of the CHARS Parameter . . . . . . . . . . . . . . . 12-41
CHKPT Parameter . . . . . . . . . . . . . . . . . . . . . . 12-41
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-42
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-42
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 12-42
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-42
Relationship to the SYSCKEOV DD Statement . . . . . . . . . . . 12-42
Checkpointing Concatenated Data Sets . . . . . . . . . . . . . 12-42
Examples of the CHKPT Parameter . . . . . . . . . . . . . . . 12-42
CNTL Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-43
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-43
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-43
Examples of the CNTL Parameter. . . . . . . . . . . . . . . . 12-43
COPIES Parameter . . . . . . . . . . . . . . . . . . . . . . 12-44
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-44
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-44
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-45
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 12-45
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-45
Relationship to Other Control Statements . . . . . . . . . . . . . 12-46
Examples of the COPIES Parameter. . . . . . . . . . . . . . . 12-46
DATA Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-47
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-47
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-48
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-48
Relationship to Other Control Statements . . . . . . . . . . . . . 12-49

vi z/OS V1R3.0 MVS JCL Reference

 Location in the JCL . . . . . . . . . . . . . . . . . . . . . 12-49
Unread Records . . . . . . . . . . . . . . . . . . . . . . 12-49
Examples of the DATA Parameter . . . . . . . . . . . . . . . . 12-49
DATACLAS Parameter . . . . . . . . . . . . . . . . . . . . . 12-50
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-51
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-51
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-51
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 12-52
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-52
Examples of the DATACLAS Parameter . . . . . . . . . . . . . 12-52
DCB Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-53
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-53
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-54
Completing the Data Control Block . . . . . . . . . . . . . . . 12-55
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-56
Examples of the DCB Parameter . . . . . . . . . . . . . . . . 12-56
DCB Subparameters . . . . . . . . . . . . . . . . . . . . 12-57
DDNAME Parameter . . . . . . . . . . . . . . . . . . . . . 12-75
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-75
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-75
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 12-75
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-75
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 12-75
Referenced DD Statement . . . . . . . . . . . . . . . . . . 12-76
Backward References . . . . . . . . . . . . . . . . . . . . 12-78
Examples of the DDNAME Parameter . . . . . . . . . . . . . . 12-78
DEST Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-80
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-81
Subparameter Definition for JES2 Systems . . . . . . . . . . . . 12-81
Subparameter Definition for JES3 Systems . . . . . . . . . . . . 12-82
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-83
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 12-83
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-83
Relationship to Other Control Statements . . . . . . . . . . . . . 12-84
Example of the DEST Parameter . . . . . . . . . . . . . . . . 12-84
DISP Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-84
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-85
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-85
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-89
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-90
Disposition of QSAM Data Sets . . . . . . . . . . . . . . . . 12-90
Disposition of Generation Data Sets . . . . . . . . . . . . . . . 12-90
Disposition of Temporary Data Sets . . . . . . . . . . . . . . . 12-90
Disposition of Partitioned Data Sets (PDSs and PDSEs) . . . . . . . 12-90
Adding a Volume to a Cataloged Data Set . . . . . . . . . . . . 12-91
DISP=MOD for a Multivolume Data Set. . . . . . . . . . . . . . 12-91
Summary of Disposition Processing . . . . . . . . . . . . . . . 12-93
Examples of the DISP Parameter . . . . . . . . . . . . . . . . 12-95
DLM Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-96
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-96
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-97
Default. . . . . . . . . . . . . . . . . . . . . . . . . . 12-97
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-97
Invalid Delimiters . . . . . . . . . . . . . . . . . . . . . . 12-97
Example of the DLM Parameter . . . . . . . . . . . . . . . . 12-97
DSID Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-97

Contents vii
 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12-98
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-98
Relationship to Other Parameters . . . . . . . . . . . . . . . . 12-98
Example of the DSID Parameter . . . . . . . . . . . . . . . . 12-99
DSNAME Parameter . . . . . . . . . . . . . . . . . . . . . 12-99
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-100
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-101
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-106
Examples of the DSNAME Parameter . . . . . . . . . . . . . . 12-106
DSNTYPE Parameter . . . . . . . . . . . . . . . . . . . . . 12-108
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-109
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-109
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-109
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-109
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-109
Examples of the DSNTYPE Parameter . . . . . . . . . . . . . 12-109
DUMMY Parameter . . . . . . . . . . . . . . . . . . . . . 12-110
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-111
Parameters on DD DUMMY Statements . . . . . . . . . . . . . 12-111
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-111
Relationship to Other Control Statements . . . . . . . . . . . . 12-112
Relationship to Access Methods . . . . . . . . . . . . . . . . 12-112
Examples of the DUMMY Parameter . . . . . . . . . . . . . . 12-112
DYNAM Parameter . . . . . . . . . . . . . . . . . . . . . . 12-113
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-113
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-113
Relationship to Other Control Statements . . . . . . . . . . . . 12-114
Example of the DYNAM Parameter . . . . . . . . . . . . . . . 12-114
EXPDT Parameter . . . . . . . . . . . . . . . . . . . . . . 12-114
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-114
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-115
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-115
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-115
Deleting a Data Set Before its Expiration Date. . . . . . . . . . . 12-115
Examples of the EXPDT Parameter. . . . . . . . . . . . . . . 12-116
FCB Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-116
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-117
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-117
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-117
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-117
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-118
Relationship to Other Control Statements . . . . . . . . . . . . 12-118
Defining an FCB Image for a Work Station . . . . . . . . . . . . 12-118
Requesting a High-Density Dump . . . . . . . . . . . . . . . 12-118
Examples of the FCB Parameter . . . . . . . . . . . . . . . . 12-118
FILEDATA Parameter . . . . . . . . . . . . . . . . . . . . . 12-119
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-120
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-120
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-120
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-120
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-120
Example of the FILEDATA Parameter . . . . . . . . . . . . . . 12-120
FLASH Parameter . . . . . . . . . . . . . . . . . . . . . . 12-120
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-121
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-121
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-121

viii z/OS V1R3.0 MVS JCL Reference

 Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-121
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-121
Relationship to Other Control Statements . . . . . . . . . . . . 12-122
Verification of Forms Overlay Frame . . . . . . . . . . . . . . 12-122
Printing without Flashing. . . . . . . . . . . . . . . . . . . 12-122
Example of the FLASH Parameter . . . . . . . . . . . . . . . 12-122
FREE Parameter . . . . . . . . . . . . . . . . . . . . . . 12-122
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-123
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-123
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-123
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-123
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-123
Relationship to Other Control Statements . . . . . . . . . . . . 12-124
Relationship to the CLOSE Macro Instruction . . . . . . . . . . . 12-124
Examples of the FREE Parameter . . . . . . . . . . . . . . . 12-124
HOLD Parameter . . . . . . . . . . . . . . . . . . . . . . 12-125
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-125
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-126
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-126
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-126
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-127
Relationship to Other Control Statements . . . . . . . . . . . . 12-127
Examples of the HOLD Parameter . . . . . . . . . . . . . . . 12-127
KEYLEN Parameter . . . . . . . . . . . . . . . . . . . . . 12-127
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-128
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-128
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-128
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-128
Examples of the KEYLEN Parameter . . . . . . . . . . . . . . 12-128
KEYOFF Parameter . . . . . . . . . . . . . . . . . . . . . 12-129
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-129
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-129
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-129
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-130
Example of the KEYOFF Parameter . . . . . . . . . . . . . . 12-130
LABEL Parameter . . . . . . . . . . . . . . . . . . . . . . 12-130
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-131
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-131
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-134
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-134
Relationship to Other Control Statements . . . . . . . . . . . . 12-135
Data Conversion . . . . . . . . . . . . . . . . . . . . . 12-135
Examples of the LABEL Parameter . . . . . . . . . . . . . . . 12-135
LGSTREAM Parameter . . . . . . . . . . . . . . . . . . . . 12-136
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-136
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-137
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-137
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-137
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-137
Example of the LGSTREAM Parameter . . . . . . . . . . . . . 12-137
LIKE Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-138
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-139
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-139
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-139
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-139
Examples of the LIKE Parameter . . . . . . . . . . . . . . . 12-139

Contents ix
 LRECL Parameter . . . . . . . . . . . . . . . . . . . . . . 12-140
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-140
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-140
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-141
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-141
Examples of the LRECL Parameter. . . . . . . . . . . . . . . 12-141
MGMTCLAS Parameter . . . . . . . . . . . . . . . . . . . . 12-141
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-142
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-142
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-142
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-142
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-143
Example of the MGMTCLAS Parameter . . . . . . . . . . . . . 12-143
MODIFY Parameter . . . . . . . . . . . . . . . . . . . . . 12-143
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-143
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-144
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-144
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-144
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-144
Relationship to Other Control Statements . . . . . . . . . . . . 12-144
Example of the MODIFY Parameter . . . . . . . . . . . . . . 12-145
OUTLIM Parameter . . . . . . . . . . . . . . . . . . . . . 12-145
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-145
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-145
Default . . . . . . . . . . . . . . . . . . . . . . . . . 12-145
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-145
Relationship to Other Control Statements . . . . . . . . . . . . 12-146
Example of the OUTLIM Parameter . . . . . . . . . . . . . . 12-146
OUTPUT Parameter . . . . . . . . . . . . . . . . . . . . . 12-146
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-146
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-147
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-147
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-147
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-148
Location in the JCL . . . . . . . . . . . . . . . . . . . . 12-148
No Match for OUTPUT Name . . . . . . . . . . . . . . . . . 12-148
Processing Options in Multiple References . . . . . . . . . . . . 12-148
Examples of the OUTPUT Parameter . . . . . . . . . . . . . . 12-149
PATH Parameter . . . . . . . . . . . . . . . . . . . . . . 12-150
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-150
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-150
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-151
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-151
Relationship to Other Statements . . . . . . . . . . . . . . . 12-152
Dummy HFS Files . . . . . . . . . . . . . . . . . . . . . 12-152
Example of the PATH Parameter. . . . . . . . . . . . . . . . 12-153
PATHDISP Parameter. . . . . . . . . . . . . . . . . . . . . 12-153
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-153
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-154
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-154
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-154
Example of the PATHDISP Parameter . . . . . . . . . . . . . . 12-154
PATHMODE Parameter . . . . . . . . . . . . . . . . . . . . 12-155
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-155
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-155
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-157

x z/OS V1R3.0 MVS JCL Reference

 Relationship to Other Parameters . . . . . . . . . . . . . . . 12-157
Example of the PATHMODE Parameter . . . . . . . . . . . . . 12-158
PATHOPTS Parameter . . . . . . . . . . . . . . . . . . . . 12-158
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-159
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-159
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-160
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-161
File Status . . . . . . . . . . . . . . . . . . . . . . . . 12-161
Example of the PATHOPTS Parameter . . . . . . . . . . . . . 12-162
PROTECT Parameter. . . . . . . . . . . . . . . . . . . . . 12-162
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-162
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-163
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-163
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-163
Requirements for Protecting a Tape Data Set . . . . . . . . . . . 12-163
Requirements for Protecting a Tape Volume . . . . . . . . . . . 12-163
Requirements for Protecting a Direct Access Data Set. . . . . . . . 12-164
Examples of the PROTECT Parameter . . . . . . . . . . . . . 12-164
QNAME Parameter . . . . . . . . . . . . . . . . . . . . . 12-164
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-165
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-165
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-165
Examples of the QNAME Parameter . . . . . . . . . . . . . . 12-165
RECFM Parameter . . . . . . . . . . . . . . . . . . . . . . 12-165
Coding RECFM for BDAM Access Method . . . . . . . . . . . . 12-166
Coding RECFM for BPAM Access Method . . . . . . . . . . . . 12-166
Coding RECFM for BSAM, EXCP, and QSAM Access Methods . . . . 12-167
Coding RECFM for QISAM Access Method . . . . . . . . . . . . 12-168
Syntax: QISAM Access Method . . . . . . . . . . . . . . . . 12-168
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-169
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-169
Examples of the RECFM Parameter . . . . . . . . . . . . . . 12-169
RECORG Parameter . . . . . . . . . . . . . . . . . . . . . 12-169
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-170
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-170
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-170
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-170
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-170
Example of the RECORG parameter . . . . . . . . . . . . . . 12-170
REFDD Parameter . . . . . . . . . . . . . . . . . . . . . . 12-170
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-171
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-171
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-172
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-172
Examples of the REFDD Parameter . . . . . . . . . . . . . . 12-172
RETPD Parameter . . . . . . . . . . . . . . . . . . . . . . 12-172
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-173
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-173
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-173
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-173
Deleting a Data Set Before its Retention Period Passes . . . . . . . 12-174
Examples of the RETPD Parameter . . . . . . . . . . . . . . 12-174
RLS Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-174
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-175
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-175
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-175

Contents xi
 Relationship to Other Parameters . . . . . . . . . . . . . . . 12-175
Examples of the RLS Parameter . . . . . . . . . . . . . . . . 12-175
SECMODEL Parameter . . . . . . . . . . . . . . . . . . . . 12-176
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-177
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-177
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-177
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-177
Examples of the SECMODEL Parameter. . . . . . . . . . . . . 12-177
SEGMENT Parameter . . . . . . . . . . . . . . . . . . . . 12-177
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-178
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-178
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-178
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-178
Example of the Segment Parameter . . . . . . . . . . . . . . 12-178
SPACE Parameter . . . . . . . . . . . . . . . . . . . . . . 12-178
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-180
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-180
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-185
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-185
SPACE for New Data Sets with SMS . . . . . . . . . . . . . . 12-186
Examples of the SPACE Parameter . . . . . . . . . . . . . . 12-186
SPIN Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-187
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-187
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-187
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-187
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-188
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-188
Examples of the SPIN Parameter . . . . . . . . . . . . . . . 12-188
STORCLAS Parameter . . . . . . . . . . . . . . . . . . . . 12-189
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-189
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-189
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-189
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-190
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-190
Examples of the STORCLAS Parameter . . . . . . . . . . . . . 12-190
SUBSYS Parameter . . . . . . . . . . . . . . . . . . . . . 12-190
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-191
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-191
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-192
Examples of the SUBSYS Parameter . . . . . . . . . . . . . . 12-193
SYSOUT Parameter . . . . . . . . . . . . . . . . . . . . . 12-193
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-194
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-194
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-195
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-196
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-196
Relationship to Other Control Statements . . . . . . . . . . . . 12-197
Starting an External Writer when Requested . . . . . . . . . . . 12-197
Held Classes in a JES2 System . . . . . . . . . . . . . . . . 12-197
Held Classes in a JES3 System . . . . . . . . . . . . . . . . 12-197
Significance of Output Classes . . . . . . . . . . . . . . . . 12-197
Examples of the SYSOUT Parameter . . . . . . . . . . . . . . 12-198
TERM Parameter . . . . . . . . . . . . . . . . . . . . . . 12-199
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-199
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-199
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-199

xii z/OS V1R3.0 MVS JCL Reference

 Location in the JCL . . . . . . . . . . . . . . . . . . . . 12-199
Examples of the TERM Parameter . . . . . . . . . . . . . . . 12-200
UCS Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-200
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-201
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-201
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 12-202
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-202
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-202
Using Special Character Sets . . . . . . . . . . . . . . . . . 12-203
Examples of the UCS Parameter . . . . . . . . . . . . . . . 12-203
UNIT Parameter . . . . . . . . . . . . . . . . . . . . . . . 12-203
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-204
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-204
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-207
Relationship of the UNIT Parameter to Other Parameters . . . . . . 12-207
Location in the JCL . . . . . . . . . . . . . . . . . . . . 12-208
Examples of the UNIT Parameter . . . . . . . . . . . . . . . 12-208
VOLUME Parameter . . . . . . . . . . . . . . . . . . . . . 12-210
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12-211
Subparameter Definition . . . . . . . . . . . . . . . . . . . 12-212
Overrides . . . . . . . . . . . . . . . . . . . . . . . . 12-218
Relationship to Other Parameters . . . . . . . . . . . . . . . 12-218
VOLUME Parameter in a JES3 System . . . . . . . . . . . . . 12-218
VOLUME Parameter for Optical Readers . . . . . . . . . . . . 12-218
VOLUME Parameter for Nonspecific Volume Requests . . . . . . . 12-218
VOLUME parameter for Specific Multi-Volume Tape Requests . . . . . 12-219
Examples of the VOLUME Parameter . . . . . . . . . . . . . . 12-219

Chapter 13. Special DD Statements . . . . . . . . . . . . . . . . 13-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
Special ddnames . . . . . . . . . . . . . . . . . . . . . . 13-1
JOBCAT DD Statement . . . . . . . . . . . . . . . . . . . . . 13-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Parameters on JOBCAT DD Statements . . . . . . . . . . . . . . 13-2
Relationship to STEPCAT DD Statement . . . . . . . . . . . . . 13-2
Relationship to Other Control Statements . . . . . . . . . . . . . 13-2
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 13-2
Example of the JOBCAT DD Statement . . . . . . . . . . . . . . 13-2
JOBLIB DD Statement . . . . . . . . . . . . . . . . . . . . . 13-2
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3
Parameters on JOBLIB DD Statements . . . . . . . . . . . . . . 13-3
Relationship to Other Control Statements . . . . . . . . . . . . . 13-4
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 13-4
Relationship of a JOBLIB to a STEPLIB . . . . . . . . . . . . . . 13-4
| Relationship between JOBLIB and Passed Data Sets . . . . . . . . . 13-5
Examples of the JOBLIB DD Statement . . . . . . . . . . . . . . 13-6
STEPCAT DD Statement . . . . . . . . . . . . . . . . . . . . 13-7
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13-8
Parameters on STEPCAT DD Statements . . . . . . . . . . . . . 13-8
Relationship to Other Control Statements . . . . . . . . . . . . . 13-8
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 13-8
Example of the STEPCAT DD Statement . . . . . . . . . . . . . 13-8
STEPLIB DD Statement . . . . . . . . . . . . . . . . . . . . . 13-9
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
Parameters on STEPLIB DD Statements . . . . . . . . . . . . . 13-9

Contents xiii
 Relationship to Other Control Statements . . . . . . . . . . . . . 13-10
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 13-11
Relationship of a STEPLIB to a JOBLIB . . . . . . . . . . . . . 13-11
Examples of the STEPLIB DD Statement . . . . . . . . . . . . . 13-11
SYSABEND, SYSMDUMP, and SYSUDUMP DD Statements. . . . . . . 13-12
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13-13
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 13-13
Storing a Dump . . . . . . . . . . . . . . . . . . . . . . 13-13
Printing a Dump . . . . . . . . . . . . . . . . . . . . . . 13-13
Overriding Dump DD Statements . . . . . . . . . . . . . . . . 13-14
Duplicate Dump Requests . . . . . . . . . . . . . . . . . . 13-14
Examples of the SYSABEND, SYSMDUMP, and SYSUDUMP DD
Statements . . . . . . . . . . . . . . . . . . . . . . . 13-14
SYSCHK DD Statement . . . . . . . . . . . . . . . . . . . . 13-15
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13-15
Parameters on SYSCHK DD Statements . . . . . . . . . . . . . 13-16
Relationship to Other Control Statements . . . . . . . . . . . . . 13-17
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 13-17
Examples of the SYSCHK DD Statement . . . . . . . . . . . . . 13-17
SYSCKEOV DD Statement . . . . . . . . . . . . . . . . . . . 13-17
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13-18
Parameters on SYSCKEOV DD Statements . . . . . . . . . . . . 13-18
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 13-18
Example of the SYSCKEOV DD Statement . . . . . . . . . . . . 13-18
SYSIN DD Statement . . . . . . . . . . . . . . . . . . . . . 13-18
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13-19
Parameters on SYSIN DD Statements . . . . . . . . . . . . . . 13-19
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 13-19
Examples of SYSIN DD Statements . . . . . . . . . . . . . . . 13-19

Chapter 14. Delimiter Statement . . . . . . . . . . . . . . . . . 14-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Comments Field. . . . . . . . . . . . . . . . . . . . . . . 14-1
Relationship to the DLM Parameter . . . . . . . . . . . . . . . 14-1
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 14-2
Examples of the Delimiter Statement . . . . . . . . . . . . . . . 14-2

Chapter 15. ENDCNTL Statement. . . . . . . . . . . . . . . . . 15-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
Label Field. . . . . . . . . . . . . . . . . . . . . . . . . 15-1
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 15-1
Comments Field. . . . . . . . . . . . . . . . . . . . . . . 15-1
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 15-1
Example of the ENDCNTL Statement . . . . . . . . . . . . . . . 15-1

Chapter 16. EXEC Statement . . . . . . . . . . . . . . . . . . 16-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 16-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1
Name Field . . . . . . . . . . . . . . . . . . . . . . . . 16-1
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 16-2
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 16-2
Comments Field. . . . . . . . . . . . . . . . . . . . . . . 16-5
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 16-5
Examples of EXEC Statements . . . . . . . . . . . . . . . . . 16-5

xiv z/OS V1R3.0 MVS JCL Reference

ACCT Parameter . . . . . . . . . . . . . . . . . . . . . . . 16-6
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
Subparameter Definition . . . . . . . . . . . . . . . . . . . . 16-7
On an EXEC Statement that Calls a Procedure . . . . . . . . . . . 16-7
Examples of the ACCT Parameter . . . . . . . . . . . . . . . . 16-7
ADDRSPC Parameter . . . . . . . . . . . . . . . . . . . . . 16-8
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
Subparameter Definition . . . . . . . . . . . . . . . . . . . . 16-8
Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
Overrides . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
Relationship to the EXEC REGION Parameter . . . . . . . . . . . 16-8
On an EXEC Statement that Calls a Procedure . . . . . . . . . . . 16-9
Examples of the ADDRSPC Parameter . . . . . . . . . . . . . . 16-9
CCSID Parameter . . . . . . . . . . . . . . . . . . . . . . . 16-9
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-10
Default. . . . . . . . . . . . . . . . . . . . . . . . . . 16-10
Relationship to Other Parameters . . . . . . . . . . . . . . . . 16-10
Examples of the CCSID Parameter . . . . . . . . . . . . . . . 16-10
COND Parameter. . . . . . . . . . . . . . . . . . . . . . . 16-10
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-11
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-12
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 16-13
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 16-13
On an EXEC Statement that Calls a Procedure . . . . . . . . . . . 16-13
Considerations when Using the COND Parameter . . . . . . . . . . 16-13
Summary of COND Parameters . . . . . . . . . . . . . . . . 16-15
Examples of the COND Parameter . . . . . . . . . . . . . . . 16-16
DYNAMNBR Parameter . . . . . . . . . . . . . . . . . . . . 16-18
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-18
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 16-18
On an EXEC Statement that Calls a Procedure . . . . . . . . . . . 16-18
Example of the DYNAMNBR Parameter . . . . . . . . . . . . . 16-19
MEMLIMIT Parameter . . . . . . . . . . . . . . . . . . . . . 16-19
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-19
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 16-19
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 16-19
Example of the MEMLIMIT Parameter . . . . . . . . . . . . . . 16-20
PARM Parameter . . . . . . . . . . . . . . . . . . . . . . . 16-20
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-21
On an EXEC Statement that Calls a Procedure . . . . . . . . . . . 16-21
Examples of the PARM Parameter . . . . . . . . . . . . . . . 16-21
PERFORM Parameter . . . . . . . . . . . . . . . . . . . . . 16-21
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-22
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-22
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 16-22
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 16-22
On an EXEC Statement that Calls a Procedure . . . . . . . . . . . 16-22
Example of the PERFORM Parameter . . . . . . . . . . . . . . 16-23
PGM Parameter . . . . . . . . . . . . . . . . . . . . . . . 16-23
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-23
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-23
Examples of the PGM Parameter . . . . . . . . . . . . . . . . 16-24

Contents xv
 PROC and Procedure Name Parameters . . . . . . . . . . . . . . 16-25
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-25
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-25
Effect of PROC Parameter on Other Parameters and Following
Statements . . . . . . . . . . . . . . . . . . . . . . . 16-25
Examples of the PROC Parameter . . . . . . . . . . . . . . . 16-25
RD Parameter . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-27
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-27
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 16-28
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 16-28
Relationship to Other Control Statements . . . . . . . . . . . . . 16-28
On an EXEC Statement that Calls a Procedure . . . . . . . . . . . 16-28
Examples of the RD Parameter . . . . . . . . . . . . . . . . 16-28
REGION Parameter . . . . . . . . . . . . . . . . . . . . . . 16-29
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-29
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-29
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 16-30
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 16-30
Relationship to the EXEC ADDRSPC Parameter . . . . . . . . . . 16-30
On an EXEC Statement that Calls a Procedure . . . . . . . . . . . 16-31
Examples of the REGION Parameter . . . . . . . . . . . . . . 16-31
TIME Parameter . . . . . . . . . . . . . . . . . . . . . . . 16-31
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16-32
Subparameter Definition . . . . . . . . . . . . . . . . . . . 16-32
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 16-32
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 16-32
On an EXEC Statement that Calls a Procedure . . . . . . . . . . . 16-32
Examples of the TIME Parameter . . . . . . . . . . . . . . . . 16-33

Chapter 17. IF/THEN/ELSE/ENDIF Statement Construct . . . . . .

. 17-1 .
Description . . . . . . . . . . . . . . . . . . . . . . .
. 17-1 .
Syntax . . . . . . . . . . . . . . . . . . . . . . . .
. 17-1 .
Name Field . . . . . . . . . . . . . . . . . . . . . .
. 17-1 .
Operation Field . . . . . . . . . . . . . . . . . . . . .
. 17-2 .
Relational-Expression Field . . . . . . . . . . . . . . . .
. 17-2 .
Comments Field. . . . . . . . . . . . . . . . . . . . .
. 17-7 .
Location in the JCL . . . . . . . . . . . . . . . . . . .
. 17-7 .
Relationship to Other Parameters . . . . . . . . . . . . . .
. 17-7 .
THEN and ELSE Clauses . . . . . . . . . . . . . . . . .
. 17-7 .
Considerations when Using the IF/THEN/ELSE/ENDIF Construct. . .
. 17-8 .
Examples of IF/THEN/ELSE/ENDIF Statement Constructs . . . . . . . 17-10

Chapter 18. INCLUDE Statement . . . . . . . . . . . . . . . . . 18-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 18-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1
Name Field . . . . . . . . . . . . . . . . . . . . . . . . 18-1
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 18-1
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 18-1
Comments Field. . . . . . . . . . . . . . . . . . . . . . . 18-2
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 18-2
Considerations for Using INCLUDE Groups . . . . . . . . . . . . 18-2
Examples of the INCLUDE Statement: . . . . . . . . . . . . . . 18-2

Chapter 19. JCLLIB Statement . . . . . . . . . . . . . . . . . . 19-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 19-1

xvi z/OS V1R3.0 MVS JCL Reference

 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 19-1
Name Field . . . . . . . . . . . . . . . . . . . . . . . . 19-2
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 19-2
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 19-2
Comments Field. . . . . . . . . . . . . . . . . . . . . . . 19-3
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 19-3
Considerations for Using the JCLLIB Statement . . . . . . . . . . . 19-3
Examples of the JCLLIB Statement . . . . . . . . . . . . . . . 19-3

Chapter 20. JOB Statement . . . . . . . . . . . . . . . . . . . 20-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 20-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-1
Name Field . . . . . . . . . . . . . . . . . . . . . . . . 20-1
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 20-2
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 20-2
Comments Field. . . . . . . . . . . . . . . . . . . . . . . 20-6
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 20-6
Examples of JOB Statements . . . . . . . . . . . . . . . . . . 20-6
Accounting Information Parameter . . . . . . . . . . . . . . . . . 20-6
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-7
Subparameter Definition . . . . . . . . . . . . . . . . . . . . 20-7
Relationship to Other Control Statements . . . . . . . . . . . . . 20-7
JES2 Accounting Information Format . . . . . . . . . . . . . . . 20-8
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-8
Examples of the Accounting Information Parameter . . . . . . . . . . 20-9
ADDRSPC Parameter . . . . . . . . . . . . . . . . . . . . . 20-10
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-10
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-10
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-10
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-10
Relationship to the JOB REGION Parameter. . . . . . . . . . . . 20-10
Examples of the ADDRSPC Parameter . . . . . . . . . . . . . . 20-11
BYTES Parameter . . . . . . . . . . . . . . . . . . . . . . 20-11
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-11
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-11
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-12
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-12
Relationship to Other Parameters . . . . . . . . . . . . . . . . 20-12
Relationship to Other Control Statements . . . . . . . . . . . . . 20-12
Examples of the BYTES Parameter . . . . . . . . . . . . . . . 20-12
CARDS Parameter . . . . . . . . . . . . . . . . . . . . . . 20-13
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-13
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-13
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-14
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-14
Relationship to Other Parameters . . . . . . . . . . . . . . . . 20-14
Relationship to Other Control Statements . . . . . . . . . . . . . 20-14
Examples of the CARDS Parameter . . . . . . . . . . . . . . . 20-14
CCSID Parameter . . . . . . . . . . . . . . . . . . . . . . 20-15
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-15
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-15
Default. . . . . . . . . . . . . . . . . . . . . . . . . . 20-15
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-15
Relationship to Other Parameters . . . . . . . . . . . . . . . . 20-15
Examples of the CCSID Parameter . . . . . . . . . . . . . . . 20-16
CLASS Parameter . . . . . . . . . . . . . . . . . . . . . . 20-16

Contents xvii
 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-17
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-17
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-17
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-17
Relationship to Other Control Statements . . . . . . . . . . . . . 20-17
Example of the CLASS Parameter . . . . . . . . . . . . . . . 20-17
COND Parameter. . . . . . . . . . . . . . . . . . . . . . . 20-17
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-18
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-18
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-19
Summary of COND Parameters . . . . . . . . . . . . . . . . 20-19
Examples of the COND Parameter . . . . . . . . . . . . . . . 20-19
GROUP Parameter . . . . . . . . . . . . . . . . . . . . . . 20-19
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-20
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-20
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-20
Example of the GROUP Parameter . . . . . . . . . . . . . . . 20-20
| JESLOG Parameter . . . . . . . . . . . . . . . . . . . . . . 20-21
| Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-21
| Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-21
| Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-21
| Examples of the JESLOG Parameter . . . . . . . . . . . . . . 20-21
LINES Parameter . . . . . . . . . . . . . . . . . . . . . . . 20-22
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-22
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-22
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-23
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-23
Relationship to Other Parameters . . . . . . . . . . . . . . . . 20-23
Relationship to Other Control Statements . . . . . . . . . . . . . 20-23
Examples of the LINES Parameter . . . . . . . . . . . . . . . 20-23
MEMLIMIT Parameter . . . . . . . . . . . . . . . . . . . . . 20-24
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-24
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-24
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-24
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-24
Examples of the MEMLIMIT Parameter . . . . . . . . . . . . . . 20-24
MSGCLASS Parameter . . . . . . . . . . . . . . . . . . . . 20-25
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-25
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-25
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-25
Significance of Output Classes . . . . . . . . . . . . . . . . . 20-25
Examples of the MSGCLASS Parameter . . . . . . . . . . . . . 20-26
MSGLEVEL Parameter. . . . . . . . . . . . . . . . . . . . . 20-26
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-27
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-27
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-27
Examples of the MSGLEVEL Parameter . . . . . . . . . . . . . 20-28
NOTIFY Parameter . . . . . . . . . . . . . . . . . . . . . . 20-28
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-28
Subparameter Definition for JES2 Systems . . . . . . . . . . . . 20-28
Subparameter Definition for JES3 Systems . . . . . . . . . . . . 20-29
Receiving Notification of Job Completion . . . . . . . . . . . . . 20-29
Examples of the NOTIFY Parameter . . . . . . . . . . . . . . . 20-29
PAGES Parameter . . . . . . . . . . . . . . . . . . . . . . 20-30
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-30
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-30

xviii z/OS V1R3.0 MVS JCL Reference

 Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-31
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-31
Relationship to Other Parameters . . . . . . . . . . . . . . . . 20-31
Relationship to Other Control Statements . . . . . . . . . . . . . 20-31
Examples of the PAGES Parameter . . . . . . . . . . . . . . . 20-31
PASSWORD Parameter . . . . . . . . . . . . . . . . . . . . 20-31
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-32
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-32
Relationship to Other Parameters . . . . . . . . . . . . . . . . 20-33
Examples of the PASSWORD Parameter . . . . . . . . . . . . . 20-33
PERFORM Parameter . . . . . . . . . . . . . . . . . . . . . 20-33
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-34
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-34
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-34
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-34
Examples of the PERFORM Parameter. . . . . . . . . . . . . . 20-34
Programmer’s Name Parameter . . . . . . . . . . . . . . . . . 20-35
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-35
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 20-35
Examples of the Programmer’s Name Parameter . . . . . . . . . . 20-36
PRTY Parameter . . . . . . . . . . . . . . . . . . . . . . . 20-36
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-37
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-37
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-37
Example of the PRTY Parameter . . . . . . . . . . . . . . . . 20-37
RD Parameter . . . . . . . . . . . . . . . . . . . . . . . . 20-37
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-38
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-38
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-39
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-39
Relationship to Other Control Statements . . . . . . . . . . . . . 20-40
Examples of the RD Parameter . . . . . . . . . . . . . . . . 20-40
REGION Parameter . . . . . . . . . . . . . . . . . . . . . . 20-40
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-41
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-41
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-41
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-42
Relationship to the JOB ADDRSPC Parameter . . . . . . . . . . . 20-42
Examples of the REGION Parameter . . . . . . . . . . . . . . 20-42
RESTART Parameter . . . . . . . . . . . . . . . . . . . . . 20-42
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-43
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-43
Relationship to Other Control Statements . . . . . . . . . . . . . 20-43
Cautions when Coding the RESTART Parameter . . . . . . . . . . 20-44
Generation Data Sets in Restarted Jobs . . . . . . . . . . . . . 20-44
Examples of the RESTART Parameter . . . . . . . . . . . . . . 20-44
SECLABEL Parameter . . . . . . . . . . . . . . . . . . . . . 20-45
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-45
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-45
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-46
Relationship to Other Parameters . . . . . . . . . . . . . . . . 20-46
Example of the SECLABEL Parameter . . . . . . . . . . . . . . 20-46
SCHENV Parameter. . . . . . . . . . . . . . . . . . . . . . 20-46
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-46
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-47
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-47

Contents xix
 Relationship to Other Control Statements . . . . . . . . . . . . . 20-47
Example of the SCHENV Parameter . . . . . . . . . . . . . . . 20-47
TIME Parameter . . . . . . . . . . . . . . . . . . . . . . . 20-47
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-48
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-48
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-48
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 20-48
Examples of the TIME Parameter . . . . . . . . . . . . . . . . 20-49
Examples of the TIME Parameter on JOB and EXEC Statements . . . . 20-49
TYPRUN Parameter . . . . . . . . . . . . . . . . . . . . . . 20-50
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-50
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-50
Relationship to Other Control Statements . . . . . . . . . . . . . 20-51
Example of the TYPRUN Parameter . . . . . . . . . . . . . . . 20-52
USER Parameter . . . . . . . . . . . . . . . . . . . . . . . 20-52
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 20-53
Subparameter Definition . . . . . . . . . . . . . . . . . . . 20-53
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 20-53
Relationship to Other Parameters . . . . . . . . . . . . . . . . 20-53
Example of the USER Parameter . . . . . . . . . . . . . . . . 20-53

Chapter 21. Null Statement . . . . . . . . . . . . . . . . . . . 21-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 21-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 21-1
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 21-1
Example of the Null Statement . . . . . . . . . . . . . . . . . 21-1

Chapter 22. OUTPUT JCL Statement . . . . . . . . . . . . . . .22-1

Description . . . . . . . . . . . . . . . . . . . . . . . . .22-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .22-1
Name Field . . . . . . . . . . . . . . . . . . . . . . . .22-1
Operation Field . . . . . . . . . . . . . . . . . . . . . . .22-1
Parameter Field . . . . . . . . . . . . . . . . . . . . . . .22-2
Comments Field. . . . . . . . . . . . . . . . . . . . . . .22-9
Location in the JCL . . . . . . . . . . . . . . . . . . . . .22-9
Overrides . . . . . . . . . . . . . . . . . . . . . . . . . 22-11
Relationship to Sysout DD Statement . . . . . . . . . . . . . . 22-11
Relationship to the JES2 /*OUTPUT Statement . . . . . . . . . . . 22-11
Relationship to the JES3 //*FORMAT Statement . . . . . . . . . . 22-11
ADDRESS Parameter . . . . . . . . . . . . . . . . . . . . . 22-12
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-12
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-12
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-13
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-13
Examples of the ADDRESS Parameter . . . . . . . . . . . . . . 22-13
BUILDING Parameter . . . . . . . . . . . . . . . . . . . . . 22-14
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-14
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-14
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-14
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-15
Example of the BUILDING Parameter . . . . . . . . . . . . . . 22-15
BURST Parameter . . . . . . . . . . . . . . . . . . . . . . 22-15
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-15
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-15
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-16
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-16

xx z/OS V1R3.0 MVS JCL Reference

 Example of the BURST Parameter . . . . . . . . . . . . . . . 22-16
CHARS Parameter . . . . . . . . . . . . . . . . . . . . . . 22-16
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-16
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-16
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-17
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-17
Requesting a High-Density Dump . . . . . . . . . . . . . . . . 22-17
Example of the CHARS Parameter . . . . . . . . . . . . . . . 22-17
CKPTLINE Parameter . . . . . . . . . . . . . . . . . . . . . 22-18
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-18
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-18
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-18
Example of the CKPTLINE Parameter . . . . . . . . . . . . . . 22-18
CKPTPAGE Parameter. . . . . . . . . . . . . . . . . . . . . 22-18
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-19
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-19
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-19
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-19
Example of the CKPTPAGE Parameter . . . . . . . . . . . . . . 22-19
CKPTSEC Parameter . . . . . . . . . . . . . . . . . . . . . 22-19
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-19
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-20
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-20
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-20
Example of the CKPTSEC Parameter . . . . . . . . . . . . . . 22-20
CLASS Parameter . . . . . . . . . . . . . . . . . . . . . . 22-20
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-20
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-20
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-21
Held Classes in a JES2 System . . . . . . . . . . . . . . . . 22-21
Held Classes in a JES3 System . . . . . . . . . . . . . . . . 22-21
Significance of Output Classes . . . . . . . . . . . . . . . . . 22-21
Examples of the CLASS Parameter . . . . . . . . . . . . . . . 22-22
COLORMAP Parameter . . . . . . . . . . . . . . . . . . . . 22-22
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-22
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-22
Example of the COLORMAP Parameter . . . . . . . . . . . . . 22-23
COMPACT Parameter . . . . . . . . . . . . . . . . . . . . . 22-23
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-23
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-23
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-23
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-23
Example of the COMPACT Parameter . . . . . . . . . . . . . . 22-23
COMSETUP Parameter . . . . . . . . . . . . . . . . . . . . 22-23
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-24
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-24
Example of the COMSETUP Parameter . . . . . . . . . . . . . 22-24
CONTROL Parameter . . . . . . . . . . . . . . . . . . . . . 22-24
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-24
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-24
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-25
Example of the CONTROL Parameter . . . . . . . . . . . . . . 22-25
COPIES Parameter . . . . . . . . . . . . . . . . . . . . . . 22-25
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-25
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-25
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-26

Contents xxi
 Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-26
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-26
Relationship to Other Control Statements . . . . . . . . . . . . . 22-26
Examples of the COPIES Parameter. . . . . . . . . . . . . . . 22-26
DATACK Parameter . . . . . . . . . . . . . . . . . . . . . . 22-27
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-28
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-28
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-28
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-28
Example of the DATACK Parameter . . . . . . . . . . . . . . . 22-28
DEFAULT Parameter . . . . . . . . . . . . . . . . . . . . . 22-28
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-29
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-29
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-29
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 22-29
References to Default OUTPUT JCL Statements . . . . . . . . . . 22-29
Example of the DEFAULT Parameter . . . . . . . . . . . . . . 22-30
DEPT Parameter . . . . . . . . . . . . . . . . . . . . . . . 22-31
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-31
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-31
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-32
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-32
Example of the DEPT Parameter . . . . . . . . . . . . . . . . 22-32
DEST Parameter . . . . . . . . . . . . . . . . . . . . . . . 22-32
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-33
Subparameter Definition for JES2 Systems . . . . . . . . . . . . 22-33
Subparameter Definition for JES3 Systems . . . . . . . . . . . . 22-34
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-35
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-35
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-35
Examples of the DEST Parameter . . . . . . . . . . . . . . . 22-35
DPAGELBL Parameter . . . . . . . . . . . . . . . . . . . . . 22-36
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-36
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-36
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-37
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-37
Example of the DPAGELBL Parameter . . . . . . . . . . . . . . 22-37
DUPLEX Parameter . . . . . . . . . . . . . . . . . . . . . . 22-37
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-37
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-37
Relationship to Other Keywords on This Statement . . . . . . . . . 22-38
Example of the DUPLEX Parameter . . . . . . . . . . . . . . . 22-38
FCB Parameter . . . . . . . . . . . . . . . . . . . . . . . 22-38
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-38
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-39
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-39
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-39
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-39
Requesting a High-Density Dump . . . . . . . . . . . . . . . . 22-39
Example of the FCB Parameter . . . . . . . . . . . . . . . . 22-40
FLASH Parameter . . . . . . . . . . . . . . . . . . . . . . 22-40
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-40
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-40
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-41
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-41
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-41

xxii z/OS V1R3.0 MVS JCL Reference

 Verification of Forms Overlay Frame . . . . . . . . . . . . . . . 22-41
Printing without Flashing . . . . . . . . . . . . . . . . . . . 22-41
Example of the FLASH Parameter . . . . . . . . . . . . . . . 22-41
FORMDEF Parameter . . . . . . . . . . . . . . . . . . . . . 22-42
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-42
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-42
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-42
Example of the FORMDEF Parameter . . . . . . . . . . . . . . 22-42
FORMLEN Parameter . . . . . . . . . . . . . . . . . . . . . 22-43
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-43
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-43
Relationship to Other Control Statements . . . . . . . . . . . . . 22-43
Examples of the FORMLEN Parameter . . . . . . . . . . . . . . 22-43
FORMS Parameter . . . . . . . . . . . . . . . . . . . . . . 22-44
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-44
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-44
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-44
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-44
Example of the FORMS Parameter . . . . . . . . . . . . . . . 22-44
FSSDATA Parameter . . . . . . . . . . . . . . . . . . . . . 22-44
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-45
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-45
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-46
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-46
Relationship to Other Keywords on this Statement . . . . . . . . . 22-46
Relationship to Other System Functions . . . . . . . . . . . . . 22-46
Examples of the FSSDATA Parameter . . . . . . . . . . . . . . 22-46
GROUPID Parameter . . . . . . . . . . . . . . . . . . . . . 22-47
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-47
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-47
Relationship to Other Control Statements . . . . . . . . . . . . . 22-47
Examples of the GROUPID Parameter . . . . . . . . . . . . . . 22-47
INDEX Parameter . . . . . . . . . . . . . . . . . . . . . . 22-48
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-48
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-49
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-49
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-49
Example of the INDEX Parameter. . . . . . . . . . . . . . . . 22-49
INTRAY Parameter . . . . . . . . . . . . . . . . . . . . . . 22-49
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-49
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-49
Relationship to Other Keywords on This Statement . . . . . . . . . 22-49
Example of the INTRAY Parameter . . . . . . . . . . . . . . . 22-49
JESDS Parameter . . . . . . . . . . . . . . . . . . . . . . 22-50
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-50
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-50
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-51
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 22-51
Destination for the System Data Sets . . . . . . . . . . . . . . 22-51
JES2 Processing with JESDS . . . . . . . . . . . . . . . . . 22-51
JES3 Processing with JESDS . . . . . . . . . . . . . . . . . 22-51
Example of the JESDS Parameter . . . . . . . . . . . . . . . 22-51
LINDEX Parameter . . . . . . . . . . . . . . . . . . . . . . 22-52
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-52
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-52
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-52

Contents xxiii
 Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-52
Example of the LINDEX Parameter . . . . . . . . . . . . . . . 22-52
LINECT Parameter . . . . . . . . . . . . . . . . . . . . . . 22-52
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-53
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-53
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-53
Example of the LINECT Parameter . . . . . . . . . . . . . . . 22-53
MODIFY Parameter . . . . . . . . . . . . . . . . . . . . . . 22-53
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-54
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-54
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-54
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-54
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-54
Example of the MODIFY Parameter . . . . . . . . . . . . . . . 22-54
NAME Parameter . . . . . . . . . . . . . . . . . . . . . . . 22-55
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-55
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-55
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-55
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-56
Example of the NAME Parameter . . . . . . . . . . . . . . . . 22-56
NOTIFY Parameter . . . . . . . . . . . . . . . . . . . . . . 22-56
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-56
Subparameter Definitions . . . . . . . . . . . . . . . . . . . 22-57
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-57
Examples of the NOTIFY Parameter . . . . . . . . . . . . . . . 22-57
OFFSETXB Parameter . . . . . . . . . . . . . . . . . . . . . 22-57
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-57
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-57
Relationship to Other Keywords on This Statement . . . . . . . . . 22-58
Example of the OFFSETXB Parameter . . . . . . . . . . . . . . 22-58
OFFSETXF Parameter . . . . . . . . . . . . . . . . . . . . . 22-58
OFFSETYB Parameter . . . . . . . . . . . . . . . . . . . . . 22-58
OFFSETYF Parameter . . . . . . . . . . . . . . . . . . . . . 22-58
OUTBIN Parameter . . . . . . . . . . . . . . . . . . . . . . 22-59
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-59
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-59
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-59
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-59
Relationship to Other System Functions . . . . . . . . . . . . . 22-59
Example of the OUTBIN Parameter . . . . . . . . . . . . . . . 22-59
OUTDISP Parameter . . . . . . . . . . . . . . . . . . . . . 22-59
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-60
Subparameter Definitions . . . . . . . . . . . . . . . . . . . 22-60
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-61
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-61
Relationship to Other Control Statements . . . . . . . . . . . . . 22-61
Examples of the OUTDISP parameter . . . . . . . . . . . . . . 22-61
OVERLAYB Parameter. . . . . . . . . . . . . . . . . . . . . 22-62
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-62
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-62
Relationship to Other Keywords on This Statement . . . . . . . . . 22-62
Example of the OVERLAYB Parameter . . . . . . . . . . . . . . 22-62
OVERLAYF Parameter . . . . . . . . . . . . . . . . . . . . . 22-62
OVFL Parameter . . . . . . . . . . . . . . . . . . . . . . . 22-63
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-63
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-63

xxiv z/OS V1R3.0 MVS JCL Reference

 Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-63
Example of the OVFL Parameter . . . . . . . . . . . . . . . . 22-63
PAGEDEF Parameter . . . . . . . . . . . . . . . . . . . . . 22-63
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-64
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-64
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-64
Example of the PAGEDEF Parameter . . . . . . . . . . . . . . 22-64
PIMSG Parameter . . . . . . . . . . . . . . . . . . . . . . 22-65
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-65
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-65
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-66
Examples of the PIMSG Parameter . . . . . . . . . . . . . . . 22-66
PORTNO Parameter . . . . . . . . . . . . . . . . . . . . . 22-66
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-66
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-67
Relationship to Other System Functions . . . . . . . . . . . . . 22-67
Example of the PORTNO Parameter. . . . . . . . . . . . . . . 22-67
PRMODE Parameter . . . . . . . . . . . . . . . . . . . . . 22-67
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-67
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-67
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-67
Printing a Line-Mode Data Set Using PSF. . . . . . . . . . . . . 22-68
Example of the PRMODE Parameter . . . . . . . . . . . . . . 22-68
PRTERROR Parameter . . . . . . . . . . . . . . . . . . . . 22-68
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-68
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-68
Relationship to Other Control Statements . . . . . . . . . . . . . 22-69
Examples of the PRTERROR Parameter . . . . . . . . . . . . . 22-69
PRTOPTNS Parameter. . . . . . . . . . . . . . . . . . . . . 22-69
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-69
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-70
Relationship to Other System Functions . . . . . . . . . . . . . 22-70
Example of the PRTOPTNS Parameter. . . . . . . . . . . . . . 22-70
PRTQUEUE Parameter . . . . . . . . . . . . . . . . . . . . 22-70
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-70
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-70
Relationship to Other System Functions . . . . . . . . . . . . . 22-70
Example of the PRTQUEUE Parameter . . . . . . . . . . . . . 22-71
PRTY Parameter . . . . . . . . . . . . . . . . . . . . . . . 22-71
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-71
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-71
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-71
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-71
Example of the PRTY Parameter . . . . . . . . . . . . . . . . 22-71
RESFMT Parameter . . . . . . . . . . . . . . . . . . . . . . 22-71
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-72
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-72
Relationship to Other Control Statements . . . . . . . . . . . . . 22-72
Example of the RESFMT Parameter . . . . . . . . . . . . . . . 22-72
RETAINS and RETAINF Parameters . . . . . . . . . . . . . . . . 22-72
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-73
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-73
Relationship to Other Control Statements . . . . . . . . . . . . . 22-73
Relationship to Other System Functions . . . . . . . . . . . . . 22-73
Examples of the RETAIN Keywords . . . . . . . . . . . . . . . 22-73
RETRYL and RETRYT Parameters . . . . . . . . . . . . . . . . 22-74

Contents xxv
 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-74
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-74
Relationship to Other Control Statements . . . . . . . . . . . . . 22-74
Relationship to Other System Functions . . . . . . . . . . . . . 22-74
Examples of the RETRY Keywords . . . . . . . . . . . . . . . 22-75
ROOM Parameter . . . . . . . . . . . . . . . . . . . . . . 22-75
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-75
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-75
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-76
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-76
Example of the ROOM Parameter . . . . . . . . . . . . . . . 22-76
SYSAREA Parameter . . . . . . . . . . . . . . . . . . . . . 22-76
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-77
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-77
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-77
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-77
Example of the SYSAREA Parameter . . . . . . . . . . . . . . 22-77
THRESHLD Parameter. . . . . . . . . . . . . . . . . . . . . 22-77
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-78
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-78
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-78
Example of the THRESHLD Parameter . . . . . . . . . . . . . . 22-78
TITLE Parameter . . . . . . . . . . . . . . . . . . . . . . . 22-79
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-79
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-79
Example of the TITLE Parameter . . . . . . . . . . . . . . . . 22-79
TRC Parameter . . . . . . . . . . . . . . . . . . . . . . . 22-80
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-80
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-80
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-80
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-80
Example of the TRC Parameter . . . . . . . . . . . . . . . . 22-80
UCS Parameter . . . . . . . . . . . . . . . . . . . . . . . 22-81
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-81
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-81
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-81
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-82
Using Special Characters Sets . . . . . . . . . . . . . . . . . 22-83
Example of the UCS Parameter . . . . . . . . . . . . . . . . 22-83
USERDATA Parameter . . . . . . . . . . . . . . . . . . . . . 22-83
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-83
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-84
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-84
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-84
Relationship to Other Keywords on this Statement . . . . . . . . . 22-84
Relationship to Other Control Statements . . . . . . . . . . . . . 22-84
Relationship to Other System Functions . . . . . . . . . . . . . 22-85
Examples of the USERDATA Parameter . . . . . . . . . . . . . 22-85
USERLIB Parameter . . . . . . . . . . . . . . . . . . . . . 22-87
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-87
Subparameter Definitions . . . . . . . . . . . . . . . . . . . 22-87
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-88
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-88
Requirements for USERLIB Libraries . . . . . . . . . . . . . . 22-88
Examples of the USERLIB Parameter . . . . . . . . . . . . . . 22-88
WRITER Parameter . . . . . . . . . . . . . . . . . . . . . . 22-88

xxvi z/OS V1R3.0 MVS JCL Reference

 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 22-89
Subparameter Definition . . . . . . . . . . . . . . . . . . . 22-89
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 22-89
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 22-89
Relationship to Other Parameters . . . . . . . . . . . . . . . . 22-89
Starting an External Writer . . . . . . . . . . . . . . . . . . 22-89
Examples of the WRITER Parameter . . . . . . . . . . . . . . 22-89

Chapter 23. PEND Statement . . . . . . . . . . . . . . . . . . 23-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 23-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 23-1
Name Field . . . . . . . . . . . . . . . . . . . . . . . . 23-1
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 23-1
Comments Field. . . . . . . . . . . . . . . . . . . . . . . 23-1
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 23-1
Examples of the PEND Statement . . . . . . . . . . . . . . . . 23-1

Chapter 24. PROC Statement . . . . . . . . . . . . . . . . . . 24-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 24-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 24-1
Name Field . . . . . . . . . . . . . . . . . . . . . . . . 24-1
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 24-2
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 24-2
Comments Field. . . . . . . . . . . . . . . . . . . . . . . 24-2
Overrides . . . . . . . . . . . . . . . . . . . . . . . . . 24-2
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 24-2
Examples of the PROC Statement . . . . . . . . . . . . . . . . 24-2

Chapter 25. SET Statement . . . . . . . . . . . . . . . . . . . 25-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 25-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 25-1
Name Field . . . . . . . . . . . . . . . . . . . . . . . . 25-2
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 25-2
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 25-2
Comments Field. . . . . . . . . . . . . . . . . . . . . . . 25-2
Overrides . . . . . . . . . . . . . . . . . . . . . . . . . 25-3
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 25-3
Relationship to Other Control Statements . . . . . . . . . . . . . 25-3
Considerations for Using the SET Statement . . . . . . . . . . . . 25-3
Examples of the SET Statement . . . . . . . . . . . . . . . . . 25-3

Chapter 26. XMIT JCL Statement . . . . . . . . . . . . . . . . . 26-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 26-2
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 26-2
Name Field . . . . . . . . . . . . . . . . . . . . . . . . 26-2
Operation Field . . . . . . . . . . . . . . . . . . . . . . . 26-2
Parameter Field . . . . . . . . . . . . . . . . . . . . . . . 26-2
Comments Field. . . . . . . . . . . . . . . . . . . . . . . 26-2
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 26-2
Error on XMIT JCL Statement. . . . . . . . . . . . . . . . . . 26-3
Examples of the XMIT JCL Statement. . . . . . . . . . . . . . . 26-3
DEST Parameter . . . . . . . . . . . . . . . . . . . . . . . 26-4
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 26-4
Subparameter Definition . . . . . . . . . . . . . . . . . . . . 26-4
Examples of the DEST Parameter . . . . . . . . . . . . . . . . 26-4
DLM Parameter . . . . . . . . . . . . . . . . . . . . . . . . 26-5

Contents xxvii
 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 26-5
Subparameter Definition . . . . . . . . . . . . . . . . . . . . 26-5
Default . . . . . . . . . . . . . . . . . . . . . . . . . . 26-5
Invalid Delimiters . . . . . . . . . . . . . . . . . . . . . . 26-5
Examples of the DLM Parameter . . . . . . . . . . . . . . . . 26-6
SUBCHARS Parameter . . . . . . . . . . . . . . . . . . . . . 26-6
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 26-6
Subparameter Definition . . . . . . . . . . . . . . . . . . . . 26-7
Default . . . . . . . . . . . . . . . . . . . . . . . . . . 26-7
Invalid Substitute . . . . . . . . . . . . . . . . . . . . . . 26-7
Examples of the SUBCHARS Parameter. . . . . . . . . . . . . . 26-7

Chapter 27. JES2 Control Statements . . . . . . . . . . . . . . . 27-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 27-1
Considerations for Started Tasks . . . . . . . . . . . . . . . . 27-1
Considerations for an APPC Scheduling Environment . . . . . . . . . 27-1
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-1
Internal Reader . . . . . . . . . . . . . . . . . . . . . . . 27-1
JES2 Command Statement . . . . . . . . . . . . . . . . . . . 27-1
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-2
Parameter Definition . . . . . . . . . . . . . . . . . . . . . 27-2
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-2
Examples of the Command Statement . . . . . . . . . . . . . . 27-3
/*JOBPARM Statement . . . . . . . . . . . . . . . . . . . . . 27-3
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-4
Parameter Definition . . . . . . . . . . . . . . . . . . . . . 27-5
Overrides . . . . . . . . . . . . . . . . . . . . . . . . . 27-8
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-8
Execution Node . . . . . . . . . . . . . . . . . . . . . . . 27-8
Examples of the /*JOBPARM Statement . . . . . . . . . . . . . . 27-8
/*MESSAGE Statement . . . . . . . . . . . . . . . . . . . . . 27-9
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-9
Relationship to the /*ROUTE XEQ Statement . . . . . . . . . . . . 27-9
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-9
Example of the /*MESSAGE Statement . . . . . . . . . . . . . . 27-9
/*NETACCT Statement . . . . . . . . . . . . . . . . . . . . . 27-9
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-10
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 27-10
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 27-10
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 27-10
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-10
Example of the /*NETACCT Statement . . . . . . . . . . . . . . 27-10
/*NOTIFY Statement. . . . . . . . . . . . . . . . . . . . . . 27-10
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-11
Parameter Definition . . . . . . . . . . . . . . . . . . . . . 27-11
Overrides . . . . . . . . . . . . . . . . . . . . . . . . . 27-11
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-11
Examples of the NOTIFY Statement . . . . . . . . . . . . . . . 27-12
/*OUTPUT Statement . . . . . . . . . . . . . . . . . . . . . 27-12
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-13
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 27-14
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 27-20
Relationship to Other Control Statements . . . . . . . . . . . . . 27-20
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-20
Example of the /*OUTPUT Statement . . . . . . . . . . . . . . 27-20
/*PRIORITY Statement . . . . . . . . . . . . . . . . . . . . . 27-21

xxviii z/OS V1R3.0 MVS JCL Reference

 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-21
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 27-21
Overrides. . . . . . . . . . . . . . . . . . . . . . . . . 27-21
Relationship to Other Control Statements . . . . . . . . . . . . . 27-21
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-21
Example of the PRIORITY Statement . . . . . . . . . . . . . . 27-22
/*ROUTE Statement . . . . . . . . . . . . . . . . . . . . . . 27-22
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-22
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 27-22
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-24
Processing of /*ROUTE Statements . . . . . . . . . . . . . . . 27-24
Multiple /*ROUTE Statements . . . . . . . . . . . . . . . . . 27-24
Examples of the ROUTE Statement . . . . . . . . . . . . . . . 27-24
/*SETUP Statement . . . . . . . . . . . . . . . . . . . . . . 27-25
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-25
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 27-25
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-25
Example of the /*SETUP Statement . . . . . . . . . . . . . . . 27-26
/*SIGNOFF Statement . . . . . . . . . . . . . . . . . . . . . 27-26
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-26
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-26
Example of the /*SIGNOFF Statement . . . . . . . . . . . . . . 27-26
/*SIGNON Statement . . . . . . . . . . . . . . . . . . . . . 27-27
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-27
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 27-27
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-28
Examples of the /*SIGNON Statement . . . . . . . . . . . . . . 27-28
/*XEQ Statement . . . . . . . . . . . . . . . . . . . . . . . 27-29
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-29
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 27-29
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-30
Multiple /*XEQ Statements . . . . . . . . . . . . . . . . . . 27-30
Example of the XEQ Statement . . . . . . . . . . . . . . . . 27-30
/*XMIT Statement. . . . . . . . . . . . . . . . . . . . . . . 27-30
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 27-31
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 27-31
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 27-32
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 27-32
Examples of the XMIT Statement . . . . . . . . . . . . . . . . 27-32

Chapter 28. JES3 Control Statements . . . . . . . . . . . . . . . 28-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . 28-1
Considerations for an APPC Scheduling Environment . . . . . . . . . 28-1
Considerations for Started Tasks . . . . . . . . . . . . . . . . 28-1
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-1
Internal Reader . . . . . . . . . . . . . . . . . . . . . . . 28-1
Examples of JES3 Control Statements . . . . . . . . . . . . . . 28-1
JES3 Command Statement . . . . . . . . . . . . . . . . . . . 28-2
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-2
Parameter Definition . . . . . . . . . . . . . . . . . . . . . 28-3
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-3
Examples of the Command Statement . . . . . . . . . . . . . . 28-3
//*DATASET Statement . . . . . . . . . . . . . . . . . . . . . 28-4
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-4
Parameter Definition . . . . . . . . . . . . . . . . . . . . . 28-4
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-5

Contents xxix
 Example of the //*DATASET Statement . . . . . . . . . . . . . . 28-5
//*ENDDATASET Statement . . . . . . . . . . . . . . . . . . . 28-6
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-6
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-6
Example of the //*ENDDATASET Statement . . . . . . . . . . . . 28-6
//*ENDPROCESS Statement . . . . . . . . . . . . . . . . . . . 28-6
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-6
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-6
Example of the //*ENDPROCESS Statement . . . . . . . . . . . . 28-7
//*FORMAT PR Statement . . . . . . . . . . . . . . . . . . . . 28-7
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-8
Parameter Definition . . . . . . . . . . . . . . . . . . . . . 28-9
Relationship to Sysout DD and OUTPUT JCL Statements . . . . . . . 28-16
Relationship to //*PROCESS Statement . . . . . . . . . . . . . 28-16
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-16
Examples of the //*FORMAT PR Statement . . . . . . . . . . . . 28-16
//*FORMAT PU Statement . . . . . . . . . . . . . . . . . . . 28-17
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-18
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 28-18
Relationship to Sysout DD and OUTPUT JCL Statements . . . . . . . 28-21
Relationship to //*PROCESS Statement . . . . . . . . . . . . . 28-21
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-21
Examples of the //*FORMAT PU Statement . . . . . . . . . . . . 28-22
//*MAIN Statement . . . . . . . . . . . . . . . . . . . . . . 28-22
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-23
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 28-24
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-36
Examples of the //*MAIN Statement . . . . . . . . . . . . . . . 28-36
//*NET Statement . . . . . . . . . . . . . . . . . . . . . . . 28-37
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-38
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 28-38
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-41
Examples of the //*NET Statement . . . . . . . . . . . . . . . 28-42
//*NETACCT Statement . . . . . . . . . . . . . . . . . . . . 28-42
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-42
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 28-42
Defaults . . . . . . . . . . . . . . . . . . . . . . . . . 28-43
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-43
Example of the //*NETACCT Statement. . . . . . . . . . . . . . 28-43
//*OPERATOR Statement . . . . . . . . . . . . . . . . . . . . 28-43
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-43
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-43
Example of the //*OPERATOR Statement . . . . . . . . . . . . . 28-43
//**PAUSE Statement . . . . . . . . . . . . . . . . . . . . . 28-43
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-44
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-44
Example of the //**PAUSE Statement . . . . . . . . . . . . . . 28-44
//*PROCESS Statement . . . . . . . . . . . . . . . . . . . . 28-44
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-45
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 28-45
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-46
Examples of the //*PROCESS Statement . . . . . . . . . . . . . 28-46
//*ROUTE XEQ Statement . . . . . . . . . . . . . . . . . . . 28-47
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-47
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 28-48
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-48

xxx z/OS V1R3.0 MVS JCL Reference

 JOB Statement after //*ROUTE XEQ. . . . . . . . . . . . . . . 28-48
Example of the //*ROUTE XEQ Statement . . . . . . . . . . . . 28-48
/*SIGNOFF Statement . . . . . . . . . . . . . . . . . . . . . 28-49
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-49
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-49
Example of the /*SIGNOFF Statement . . . . . . . . . . . . . . 28-49
/*SIGNON Statement . . . . . . . . . . . . . . . . . . . . . 28-50
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 28-50
Parameter Definition. . . . . . . . . . . . . . . . . . . . . 28-50
Location in the JCL . . . . . . . . . . . . . . . . . . . . . 28-51
Example of the /*SIGNON Statement . . . . . . . . . . . . . . 28-51

Appendix. Accessibility . . . . . . . . . . . . . . . . . . . . . A-1

Using assistive technologies . . . . . . . . . . . . . . . . . . . A-1
Keyboard navigation of the user interface . . . . . . . . . . . . . . . A-1

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . B-2

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1

Contents xxxi
xxxii z/OS V1R3.0 MVS JCL Reference
Figures
17-1. Operators on IF/THEN/ELSE/ENDIF Statement Construct . . . . . . . . . . . . . . 17-3

© Copyright IBM Corp. 1988, 2002 xxxiii

xxxiv z/OS V1R3.0 MVS JCL Reference
About This Book
This book describes the job control tasks needed to enter jobs into the OS/390
operating system, control the system’s processing of jobs, and request the
resources needed to run jobs. The book also contains a chapter that describes
″started tasks″ and how to set them up. To perform job control or started tasks,
programmers code ″job control statements.″ This book describes how to code these
statements, which include:
v Job control language (JCL) statements
v Job entry control language (JECL) statements, which encompass:
Job entry subsystem 2 (JES2) control statements
Job entry subsystem 3 (JES3) control statements

This book is designed as a reference book, to be used while coding the statements.
It contains some introductory material. Full explanations of the job control tasks are
presented in a companion book, z/OS MVS JCL User’s Guide, SA22-7598.

Who Should Use This Book

This book is needed by system and application programmers who enter programs
into the operating system. Those using this book should understand the concepts of
job management and data management.

Related Information
To have complete JCL information, you need the following book:
z/OS MVS JCL User’s Guide, SA22-7598

Where necessary, this book references information in other books, using shortened
versions of the book title. For complete titles and order numbers of the books for all
products that are part of z/OS, see z/OS Information Roadmap. The following tables
list the short titles, titles, and order numbers for books related to non-OS/390
products that this book references.

Programs
Short Title Used in This Book Title Order Number
ACF/TCAM Installation Reference Advanced Communications Function for TCAM, SC30-3133
Version 2 Installation Reference
PSF/MVS System Programming Guide PSF/MVS System Programming Guide SH35-0091
PSF/MVS Application Programming Guide PSF/MVS Application Programming Guide S544-3084

Hardware
Short Title Used in This Book Title Order Number
2821 Component Description IBM 2821 Control Unit Component Description GA24-3312
3540 Programmer’s Reference OS/VS2 IBM 3540 Programmer’s Reference GC24-5111
3800 Programmer’s Guide IBM 3800 Printing Subsystem Programmer’s GC26-3846
Guide

© Copyright IBM Corp. 1988, 2002 xxxv

Short Title Used in This Book Title Order Number
Forms Design Reference Guide for the 3800 Forms Design Reference Guide for the IBM GA26-1633
3800 Printing Subsystem

Accessing licensed books on the Web

z/OS licensed documentation in PDF format is available on the Internet at the IBM
Resource Link Web site at:
http://www.ibm.com/servers/resourcelink

Licensed books are available only to customers with a z/OS license. Access to
these books requires an IBM Resource Link Web userid and password, and a key
code. With your z/OS order you received a memo that includes this key code.

To obtain your IBM Resource Link Web userid and password log on to:
http://www.ibm.com/servers/resourcelink

To register for access to the z/OS licensed books:

1. Log on to Resource Link using your Resource Link userid and password.
2. Click on User Profiles located on the left-hand navigation bar.
3. Click on Access Profile.
4. Click on Request Access to Licensed books.
5. Supply your key code where requested and click on the Submit button.

If you supplied the correct key code you will receive confirmation that your request
is being processed. After your request is processed you will receive an e-mail
confirmation.

Note: You cannot access the z/OS licensed books unless you have registered for
access to them and received an e-mail confirmation informing you that your
request has been processed.

To access the licensed books:

1. Log on to Resource Link using your Resource Link userid and password.
2. Click on Library.
3. Click on zSeries.
4. Click on Software.
5. Click on z/OS.
6. Access the licensed book by selecting the appropriate element.

Using LookAt to look up message explanations

LookAt is an online facility that allows you to look up explanations for z/OS
messages, system abends, and some codes. Using LookAt to find information is
faster than a conventional search because in most cases LookAt goes directly to
the message explanation.

You can access LookAt from the Internet at:

http://www.ibm.com/servers/eserver/zseries/zos/bkserv/lookat/lookat.html

xxxvi z/OS V1R3.0 MVS JCL Reference

or from anywhere in z/OS where you can access a TSO command line (for
example, TSO prompt, ISPF, z/OS UNIX System Services running OMVS).

To find a message explanation on the Internet, go to the LookAt Web site and
simply enter the message identifier (for example, IAT1836 or IAT*). You can select a
specific release to narrow your search. You can also download code from the z/OS
Collection, SK3T-4269 and the LookAt Web site so you can access LookAt from a
PalmPilot (Palm VIIx suggested).

To use LookAt as a TSO command, you must have LookAt installed on your host
system. You can obtain the LookAt code for TSO from a disk on your z/OS
Collection, SK3T-4269 or from the LookAt Web site. To obtain the code from the
LookAt Web site, do the following:
1. Go to http://www.ibm.com/servers/eserver/zseries/zos/bkserv/lookat/lookat.html.
2. Click the News button.
3. Scroll to Download LookAt Code for TSO and VM.
4. Click the ftp link, which will take you to a list of operating systems. Select the
appropriate operating system. Then select the appropriate release.
5. Find the lookat.me file and follow its detailed instructions.

To find a message explanation from a TSO command line, simply enter: lookat
message-id. LookAt will display the message explanation for the message
requested.

Note: Some messages have information in more than one book. For example,
IEC192I has routing and descriptor codes listed in z/OS MVS Routing and
Descriptor Codes. For such messages, LookAt prompts you to choose which
book to open.

About This Book xxxvii

xxxviii z/OS V1R3.0 MVS JCL Reference
Summary of changes
Summary of changes
for SA22-7597-02
z/OS Version 1 Release 3

The book contains information previously presented in z/OS MVS JCL Reference,
SA22-7597-01, which supports z/OS Version 1 Release 2.

New information
v An appendix with z/OS product accessibility information has been added.

This book contains terminology, maintenance, and editorial changes. Technical

changes or additions to the text and illustrations are indicated by a vertical line to
the left of the change.

Starting with z/OS V1R2, you may notice changes in the style and structure of
some content in this book—for example, headings that use uppercase for the first
letter of initial words only, and procedures that have a different look and format. The
changes are ongoing improvements to the consistency and retrievability of
information in our books.

Summary of changes
for SA22-7597-01
z/OS Version 1 Release 2

The book contains information previously presented in z/OS MVS JCL Reference,
SA22-7597-00, which supports z/OS Version 1 Release 1.

New information
v MEMLIMIT is a new keyword on JOB and EXEC statements. MEMLIMIT
specifies the limit on the total number of usable virtual pages above the bar for a
single address space.

This book contains terminology, maintenance, and editorial changes, including

changes to improve consistency and retrievability.

Summary of changes
for SA22-7597-00
z/OS Version 1 Release 1

The book contains information also presented in OS/390 MVS JCL Reference.

© Copyright IBM Corp. 1988, 2002 xxxix

xl z/OS V1R3.0 MVS JCL Reference
Chapter 1. Job Control Statements
This chapter lists, in Table 1-1, all but one of the statements in the MVS Job Control
Language (JCL), and in Table 1-2 on page 1-2, all of the Job Entry Control
Language (JECL) statements for the JES2 and JES3 subsystems, together with the
purpose of each statement. Later chapters describe each statement in detail. (The
PRINTDEV JCL statement, for use by the person starting the Print Services Facility,
is documented in the manual PSF for OS/390 & z/OS: Customization.)

JCL Statements
Table 1-1. MVS Job Control Language (JCL) Statements
Statement Name Purpose
// command JCL command Enters an MVS system operator
command through the input stream. The
command statement is used primarily by
the operator. Use the COMMAND
statement instead of the JCL command
statement.
// COMMAND command Specifies an MVS or JES command that
the system issues when the JCL is
converted. Use the COMMAND statement
instead of the JCL command statement.
//* comment comment Contains comments. The comment
statement is used primarily to document a
program and its resource requirements.
// CNTL control Marks the beginning of one or more
program control statements.
// DD data definition Identifies and describes a data set.
/* delimiter Indicates the end of data placed in the
input stream.

Note: A user can designate any two

characters to be the delimiter.
// ENDCNTL end control Marks the end of one or more program
control statements.
// EXEC execute Marks the beginning of a job step;
assigns a name to the step; identifies the
program or the cataloged or in-stream
procedure to be executed in this step.
// IF/THEN/ELSE/ENDIF IF/THEN/ELSE/ENDIF Specifies conditional execution of job
statement construct steps within a job.
// INCLUDE include Identifies a member of a partitioned data
set (PDS) or partitioned data set
extended (PDSE) that contains JCL
statements to include in the job stream.
// JCLLIB JCL library Identifies the libraries that the system will
search for:
v INCLUDE groups
v Procedures named in EXEC
statements.

© Copyright IBM Corp. 1988, 2002 1-1

Statements
Table 1-1. MVS Job Control Language (JCL) Statements (continued)
Statement Name Purpose
// JOB job Marks the beginning of a job; assigns a
name to the job.
// null Marks the end of a job.
// OUTPUT output JCL Specifies the processing options that the
job entry subsystem is to use for printing
a sysout data set.
// PEND procedure end Marks the end of an in-stream or
cataloged procedure.
// PROC procedure Marks the beginning of an in-stream
procedure and may mark the beginning of
a cataloged procedure; assigns default
values to parameters defined in the
procedure.
// SET set Defines and assigns initial values to
symbolic parameters used when
processing JCL statements. Changes or
nullifies the values assigned to symbolic
parameters.
// XMIT transmit Transmits input stream records from one
node to another.

Note: The XMIT JCL statement is

supported only on JES3 systems.

JECL Statements
Table 1-2. Job Entry Control Language (JECL) Statements
Statement Purpose
Job Entry Subsystem 2 (JES2) Control Statements
/*$command Enters JES2 operator commands through the input stream.
/*JOBPARM Specifies certain job-related parameters at input time.
/*MESSAGE Sends messages to the operator via the operator console.
/*NETACCT Specifies an account number for a network job.
/*NOTIFY Specifies the destination of notification messages.
/*OUTPUT Specifies processing options for sysout data set(s).
/*PRIORITY Assigns a job queue selection priority.
/*ROUTE Specifies the output destination or the execution node for the job.
/*SETUP Requests mounting of volumes needed for the job.
/*SIGNOFF Ends a remote job stream processing session.
/*SIGNON Begins a remote job stream processing session.
/*XEQ Specifies the execution node for a job.
/*XMIT Indicates a job or data stream to be transmitted to another JES2
node or eligible non-JES2 node.
Job Entry Subsystem 3 (JES3) Control Statements
//**command Enters JES3 operator commands, except *DUMP and *RETURN,
through the input stream.

1-2 z/OS V1R3.0 MVS JCL Reference

 Statements
Table 1-2. Job Entry Control Language (JECL) Statements (continued)
Statement Purpose
//*DATASET Begins an input data set in the input stream.
//*ENDDATASET Ends the input data set that began with a //*dataset statement.
//*ENDPROCESS Ends a series of //*PROCESS statements.
//*FORMAT Specifies the processing options for a sysout or JES3-managed
print or punch data set.
//*MAIN Defines selected processing parameters for a job.
//*NET Identifies relationships between predecessor and successor jobs
in a dependent job control net.
//*NETACCT Specifies an account number for a network job.
//*OPERATOR Sends messages to the operator.
//*PAUSE Halts the input reader.
//*PROCESS Identifies a nonstandard job.
//*ROUTE Specifies the execution node for the job.
/*SIGNOFF Ends a remote job stream processing session.
/*SIGNON Begins a remote job stream processing session.

Chapter 1. Job Control Statements 1-3

Statements

1-4 z/OS V1R3.0 MVS JCL Reference

Chapter 2. Job Control Tasks
For your program to execute on the computer and perform the work you designed it
to do, your program must be processed by your operating system.

Your operating system consists of an MVS/SP base control program (BCP) with a
job entry subsystem (JES2 or JES3) and DFSMS/MVS DFSMSdfp installed with it.

For the operating system to process a program, programmers must perform certain
job control tasks. These tasks are performed through the job control statements,
which consist of:
JCL statements
JES2 control statements
JES3 control statements

Entering Jobs
Job Steps

You enter a program into the operating system as a job step. A job step consists of
the job control statements that request and control execution of a program and
request the resources needed to run the program. A job step is identified by an
EXEC statement. The job step can also contain data needed by the program. The
operating system distinguishes job control statements from data by the contents of
the records.

Jobs

A job is a collection of related job steps. A job is identified by a JOB statement.

Input Streams

Jobs placed in a series and entered through one input device form an input
stream. The operating system reads an input stream into the computer from an
input/output (I/O) device or an internal reader. The input device can be a card
reader, a magnetic tape device, a terminal, or a direct access device. An internal
reader is a buffer that is read from a program into the system as though it were an
input stream.

Cataloged and In-Stream Procedures

You often use the same set of job control statements repeatedly with little or no
change, for example, to compile, assemble, link-edit, and execute a program. To
save time and prevent errors, you can prepare sets of job control statements and
place, or catalog, them in a partitioned data set (PDS) or partitioned data set
extended (PDSE) known as a procedure library. The data set attributes of a
procedure library should match SYS1.PROCLIB (record length of 80 and record
format of FB). Such a set of job control statements in the system procedure library,
SYS1.PROCLIB (or an installation-defined procedure library), is called a cataloged
procedure.

To test a procedure before placing it in the catalog, place it in an input stream and
execute it; a procedure in an input stream is called an in-stream procedure. The
maximum number of in-stream procedures you can code in any job is 15.

© Copyright IBM Corp. 1988, 2002 2-1

Tasks
Steps in a Job

A job can be simple or complex; it can consist of one step or of many steps that call
many in-stream and cataloged procedures. A job can consist of up to 255 job steps,
including all steps in any procedures that the job calls. Specification of a greater
number of steps produces a JCL error.

Processing Jobs
The operating system performs many job control tasks automatically. You can
influence the way your job is processed by the JCL and JES2 or JES3 parameters
you code. For example, the job entry subsystem selects jobs for execution, but you
can speed up or delay selection of your job by the parameters you code.

Requesting Resources
Data Set Resources

To execute a program, you must request the data sets needed to supply data to the
program and to receive output records from the program.

Sysout Data Set Resources

A sysout data set is a system-handled output data set. This data set is placed
temporarily on direct access storage. Later, at the convenience of the system, the
system prints it, punches it, or sends it to a specified location. Because sysout data
sets are processed by the system, the programmer can specify many parameters to
control that processing.

Task Charts
The following charts list the job control tasks, which are described in the z/OS MVS
JCL User’s Guide, in four groups:
v Entering jobs in Table 2-1 on page 2-3
v Processing jobs in Table 2-2 on page 2-5
v Requesting data set resources in Table 2-3 on page 2-6
v Requesting sysout data set resources in Table 2-4 on page 2-8

For each task, the charts list the parameters and statements that can be used to
perform it. In many cases, the same task can be performed using different
parameters on different statements. Where a parameter can appear on both a JOB
and EXEC statement, it applies to the entire job when coded on the JOB statement
but only to a step when coded on an EXEC statement.

The system is designed to enable users to perform many types of job control in
many ways. To allow this flexibility, only two job entry tasks are required:
v Identification: The job must be identified in the jobname field of a JOB
statement.
v Execution: The program or procedure to be executed must be named in a PGM
or PROC parameter on an EXEC statement.

Therefore, the following statements are the minimum needed to perform a job
control task:

2-2 z/OS V1R3.0 MVS JCL Reference

 Tasks
//jobname JOB
// EXEC {PGM=program-name }
{PROC=procedure-name}
{procedure-name}

Table 2-1. Tasks for Entering Jobs

TASKS FOR STATEMENTS AND PARAMETERS
ENTERING
JCL Statements JES2 JES3
JOBS
Statements Statements
JOB EXEC Other JCL
Identification
of job jobname field null statement (JES3
only)
of step stepname field
of procedure PROC PEND
of INCLUDE INCLUDE
group
of account accounting ACCT /*NETACCT //*NETACCT
information or
pano in JOB
JES2 accounting
information
of programmer programmer’s ROOM on PNAME, BLDG,
name and room /*JOBPARM DEPT, ROOM,
in JOB JES2 and USERID on
accounting //*NETACCT
information
USER
Execution
of program PGM
of procedure PROC
when restarting RESTART RD RD SYSCHK DD RESTART on FAILURE and
and with /*JOBPARM JOURNAL on
checkpointing //*MAIN
deadline or DEADLINE on
periodic //*MAIN
when dependent //*NET
on other jobs
at remote node XMIT JCL (JES3 /*ROUTE XEQ //*ROUTE XEQ
only) /*XEQ /*XMIT
Job Input Control
by holding job TYPRUN CLASS HOLD, UPDATE,
entrance or CLASS on
//*MAIN //*NET
by holding local //*PAUSE
input reader
by copying input TYPRUN CLASS
stream (JES2
only)
from remote work /*SIGNON /*SIGNON
station /*SIGNOFF /*SIGNOFF
Communication

Chapter 2. Job Control Tasks 2-3

Tasks
Table 2-1. Tasks for Entering Jobs (continued)
TASKS FOR STATEMENTS AND PARAMETERS
ENTERING
JCL Statements JES2 JES3
JOBS
Statements Statements
JOB EXEC Other JCL
from JCL to COMMAND /*$command //**command
system Command
from JCL to /*MESSAGE //*OPERATOR
operator
from JCL to Comment field Comment field //*comment, also Comment field
programmer unless no comment field on all on
parameter field statements but null //*ENDPROCESS
and //*PAUSE
from JCL to PARM
program
from system to WARNING on FETCH on
operator BYTES, CARDS, //*MAIN
LINES, and WARNING on
PAGES BYTES, CARDS,
LINES, and
PAGES on
//*MAIN
from system to NOTIFY /*NOTIFY ACMAIN on
userid -of job NOTIFY on //*MAIN with JOB
completion -of OUTPUT JCL NOTIFY
print completion statement
from TSO/E USER on
userid to system //*MAIN
from functional PIMSG on OUTPUT
subsystem to JCL
programmer
through job log MSGCLASS JESDS on OUTPUT NOLOG on
MSGLEVEL log JCL /*JOBPARM
in JOB JES2
accounting
information
Protection
through RACF GROUP
PASSWORD
SECLABEL
USER
Resource Control
of program JOBLIB DD,
library STEPLIB DD, DD
defining PDS or
PDSE member
of procedure JCLLIB PROCLIB on PROC and
library /*JOBPARM UPDATE on
//*MAIN
of INCLUDE JCLLIB PROCLIB on PROC and
group /*JOBPARM UPDATE on
//*MAIN

2-4 z/OS V1R3.0 MVS JCL Reference

 Tasks
Table 2-1. Tasks for Entering Jobs (continued)
TASKS FOR STATEMENTS AND PARAMETERS
ENTERING
JCL Statements JES2 JES3
JOBS
Statements Statements
JOB EXEC Other JCL
of address space REGION REGION LREGION on
ADDRSPC ADDRSPC //*MAIN
of processor SYSAFF on SYSTEM on
/*JOBPARM //*MAIN
of spool partition SPART and
TRKGRPS on
//*MAIN

Table 2-2. Tasks for Processing Jobs

TASKS FOR STATEMENTS AND PARAMETERS FOR TASK
PROCESSING
JCL Statements JES2 JES3
JOBS
Statements Statements
JOB EXEC Other JCL
Processing Control
by conditional COND COND IF/THEN/ELSE/ CANCEL on CANCEL on
execution ENDIF statement BYTES, CARDS, BYTES, CARDS,
CANCEL on construct LINES, and LINES, and
BYTES, CARDS, PAGES on PAGES on
LINES, and /*JOBPARM //*MAIN
PAGES
by timing TIME or time in TIME TIME on
execution JOB JES2 /*JOBPARM
accounting
information
for testing: TYPRUN CLASS PGM=IEFBR14 SYSMDUMP DD //*PROCESS
1. by altering DUMP on SYSUDUMP DD //*ENDPROCESS
usual BYTES, CARDS, PGM=JCLTEST SYSABEND DD DUMP in
processing LINES, and PGM=JSTTEST BYTES, CARDS,
2. by dumping PAGES (JES3 only) To format dump on LINES, and
after error 3800 Printing PAGES on
Subsystem, //*MAIN
FCB=STD3 and
CHARS=DUMP
on dump DD
Performance Control
by job class CLASS CLASS on
assignment //*MAIN
by selection PRTY /*PRIORITY
priority
by performance PERFORM PERFORM
group
assignment
by IORATE on
I/O-to-processing //*MAIN
ratio

Chapter 2. Job Control Tasks 2-5

Tasks
Table 2-3. Tasks for Requesting Data Set Resources
TASKS FOR STATEMENTS AND PARAMETERS FOR TASK
REQUESTING
JCL Statements JES2 JES3
DATA SET
Statements Statements
RESOURCES DD OUTPUT JCL Other JCL
Identification
of data set DSNAME UPDATE on
//*MAIN
of in-stream data * or DATA SYSIN /* or xx delimiter //*DATASET
set DD DLM //*ENDDATASET
of data set on DSID
3540 Diskette
Input/Output Unit
through catalog JOBCAT DD
STEPCAT DD
through label label-type on
LABEL
by location on data-set-
tape sequence-
number on
LABEL
as TCAM QNAME
message data
set
from or to TERM
terminal
Description
of status DISP
of data attributes DCB
- by modeling AMP
DATACLAS
KEYLEN
DSNTYPE
KEYOFF
LRECL
RECFM
RECORG

LIKE
REFDD
of data for CCSID
ISO/ANSI
Version 4 tapes
of migration and MGMTCLAS
backup
Protection
through RACF PROTECT
SECMODEL

2-6 z/OS V1R3.0 MVS JCL Reference

 Tasks
Table 2-3. Tasks for Requesting Data Set Resources (continued)
TASKS FOR STATEMENTS AND PARAMETERS FOR TASK
REQUESTING
JCL Statements JES2 JES3
DATA SET
Statements Statements
RESOURCES DD OUTPUT JCL Other JCL
for ACCODE
ISO/ANSI/FIPS
Version 3 tapes
and ISO/ANSI
Version 4 tapes
by passwords PASSWORD and
NOPWREAD on
LABEL
of access to IN and OUT on
BSAM and LABEL
BDAM data sets
Allocation
of device UNIT CLASS on JOB SETUP and
STORCLAS (JES3 only) CLASS on
//*MAIN
of tape or direct VOLUME EXPDTCHK and
access volume STORCLAS RINGCHK on
//*MAIN
of direct access SPACE AVGREC
space DATACLAS
of virtual I/O UNIT
DSNAME=
temporary
data set
with deferred DEFER on UNIT
volume mounting
with volume /*SETUP
pre-mounting
dynamic DYNAMNBR on
EXEC
Processing Control
by suppressing DUMMY
processing NULLFILE on
DSNAME
by postponing DDNAME
specification
with CHKPT RESTART on JOB
checkpointing SYSCKEOV DD RD on EXEC
SYSCHK DD
by subsystem SUBSYS CNTL CNTL ENDCNTL
by TCAM job or QNAME
task
End Processing
unallocation FREE

Chapter 2. Job Control Tasks 2-7

Tasks
Table 2-3. Tasks for Requesting Data Set Resources (continued)
TASKS FOR STATEMENTS AND PARAMETERS FOR TASK
REQUESTING
JCL Statements JES2 JES3
DATA SET
Statements Statements
RESOURCES DD OUTPUT JCL Other JCL
disposition of DISP OUTDISP on
data set /*OUTPUT
RETPD
EXPDT
release of RLSE on SPACE
unused direct
access space
disposition of RETAIN and
volume PRIVATE on
VOLUME

Table 2-4. Tasks for Requesting Sysout Data Set Resources

TASKS FOR STATEMENTS AND PARAMETERS FOR TASK
REQUESTING
JCL Statements JES2 JES3
DATA SET
Statements Statements
RESOURCES DD OUTPUT JCL Other JCL
Identification
as a sysout data SYSOUT
set
name (last DSNAME
qualifier)
of output class class on CLASS MSGCLASS on JOB
SYSOUT with SYSOUT=* or
CLASS=* and
SYSOUT=(,)
of data set on DSID
3540 Diskette
Input/Output Unit
Description
of data attributes DCB
Protection
of printed output DPAGELBL
SYSAREA
Performance Control
by queue PRTY
selection
Processing Control
with additional OUTPUT DEFAULT
parameters code-name on
SYSOUT
by segmenting SEGMENT
with other data class on THRESHLD
sets SYSOUT (JES3 only)
GROUPID (JES2
only)

2-8 z/OS V1R3.0 MVS JCL Reference

 Tasks
Table 2-4. Tasks for Requesting Sysout Data Set Resources (continued)
TASKS FOR STATEMENTS AND PARAMETERS FOR TASK
REQUESTING
JCL Statements JES2 JES3
DATA SET
Statements Statements
RESOURCES DD OUTPUT JCL Other JCL
by external writer writer-name on WRITER
SYSOUT
by mode PRMODE
by holding HOLD class on CLASS OUTDISP
SYSOUT
by suppressing DUMMY class on OUTDISP=PURGE
output SYSOUT on OUTPUT
with CKPTLINE CKPLNS and
checkpointing CKPTPAGE CKPPGS on
CKPTSEC /*OUTPUT
by Print Services COLORMAP
Facility (PSF) COMSETUP
DUPLEX
FORMDEF
FORMLEN
INTRAY
OFFSETXB
OFFSETXF
OFFSETYB
OFFSETYF
OVERLAYB
OVERLAYF
PAGEDEF
PRTERROR
RESFMT
USERLIB
by IP Printway PORTNO
End Processing
unallocation FREE
SPIN
Destination Control
to local or remote DEST class on DEST /*ROUTE PRINT ORG on //*MAIN
device or to SYSOUT COMPACT /*ROUTE
another node PUNCH
to another ACMAIN on
processor //*MAIN
to internal reader INTRDR as /*EOF
writer-name on /*DEL
SYSOUT /*PURGE
/*SCAN
to terminal TERM
to assist in ADDRESS ROOM on
sysout BUILDING /*OUTPUT
distribution DEPT
NAME
ROOM
TITLE
Output Formatting

Chapter 2. Job Control Tasks 2-9

Tasks
Table 2-4. Tasks for Requesting Sysout Data Set Resources (continued)
TASKS FOR STATEMENTS AND PARAMETERS FOR TASK
REQUESTING
JCL Statements JES2 JES3
DATA SET
Statements Statements
RESOURCES DD OUTPUT JCL Other JCL
to any printer COPIES FCB COPIES forms, copies, and COPIES, COPIES and
form-name on FCB linect on JOB JES2 FORMS, and FORMS on
SYSOUT UCS FORMS accounting LINECT on //*FORMAT PR
LINECT information /*JOBPARM
(JES2 only) COPIES, FCB,
UCS and FORMS on
CONTROL /*OUTPUT
to 3800 Printing BURST BURST CHARS BURST on CHARS and
Subsystem in CHARS FLASH MODIFY /*JOBPARM FLASH on
addition to most FLASH TRC //*FORMAT PR
of printer MODIFY CHARS, FLASH,
parameters DCB= and BURST on
OPTCD=J /*OUTPUT
to 3211 Printer INDEX (JES2
with indexing LINDEX only)
feature
to punch COPIES FCB COPIES
form-name on FCB
SYSOUT FORMS
DCB=FUNC=I
of dumps on CHARS=DUMP CHARS=DUMP
3800 Printing FCB=STD3 FCB=STD3
Subsystem
Output Limiting
OUTLIM lines and cards BYTES, CARDS, BYTES, CARDS,
on JOB JES2 LINES, and LINES, and
accounting PAGES on PAGES on
information /*JOBPARM //*MAIN

BYTES, CARDS,
LINES, and PAGES
on JOB
USERDATA Specifications
Installation USERDATA
specifications

2-10 z/OS V1R3.0 MVS JCL Reference

Chapter 3. Format of Statements
This chapter describes the fields in JCL, JES2, and JES3 statements. It ends with
the conventions for continuing statements.

JCL Statement Fields

A JCL statement consists of one or more 80-byte records. Each record is in the
form of an 80-column punched-card image. Each JCL statement is logically divided
into the following five fields. All five fields do not appear on every statement; see
Table 3-1 on page 3-2 for the fields that can appear on each statement.
Identifier field
The identifier field indicates to the system that a statement is a JCL statement
rather than data. The identifier field consists of the following:
v Columns 1 and 2 of all JCL statements, except the delimiter statement,
contain //
v Columns 1 and 2 of the delimiter statement contain either /* or two other
characters designated in a DLM parameter to be the delimiter
v Columns 1, 2, and 3 of a JCL comment statement contain //*
Name field
The name field identifies a particular statement so that other statements and the
system can refer to it. For JCL statements, code the name as follows:
v The name must begin in column 3.
v The name is 1 through 8 alphanumeric or national ($, #, @) characters. See
Table 4-2 on page 4-3 for the character sets.
v The first character must be an alphabetic or national ($, #, @).
v The name must be followed by at least one blank.
Operation field
The operation field specifies the type of statement, or, for the command
statement, the command. Code the operation field as follows:
v The operation field consists of the characters in the syntax box for the
statement.
v The operation follows the name field.
v The operation must be preceded and followed by at least one blank.
Parameter, or operand field
The parameter field, also sometimes referred to as the operand field, contains
parameters separated by commas. Code the parameter field as follows:
v The parameter field follows the operation field.
v The parameter field must be preceded by at least one blank.

See “Parameter Field” on page 3-3 for details on coding the parameter field.
Comments field
The comments field contains any information you deem helpful when you code
the control statement. Code the comments field as follows:
v The comments field follows the parameter field.
v The comments field must be preceded by at least one blank.

You can code comments after the parameter field even though you continue the
parameter field on a subsequent statement; see “Continuing JCL Statements”
on page 3-4.

© Copyright IBM Corp. 1988, 2002 3-1

Format: Fields
For most statements, if you do not code any parameters, do not code any
comments.
Table 3-1. JCL Statement Fields
Statement Fields
JCL Command // command [parameter] [comments]
COMMAND //[name] COMMAND ‘command command-operand’ [comments]
Comment //* comments
CNTL //label CNTL [* comments]
DD //[ddname] DD [parameter [comments]]
//[ddname] DD
Delimiter /* [comments]
xx [comments]
ENDCNTL //[label] ENDCNTL [comments]
EXEC //[stepname] EXEC parameter [comments]
IF/THEN/ELSE/ENDIF //name IF [relational expression] THEN [comments]
//name ELSE [comments]
//name ENDIF [comments]
INCLUDE //[name] INCLUDE parameter [comments]
JCLLIB //[name] JCLLIB parameter [comments]
JOB //jobname JOB [parameter [comments]]
//jobname JOB
Null //
OUTPUT JCL //name OUTPUT parameter [comments]
PEND //[name] PEND [comments]
PROC (cataloged) //[name] PROC [parameter [comments]]
//[name] PROC
PROC (in-stream) //name PROC [parameter [comments]]
//name PROC
SET //[name] SET parameter [comments]
XMIT //[name] XMIT parameter[,parameter] [comments]

Location of Fields on Statements

Code the identifier field beginning in column 1 and the name field immediately after
the identifier, with no intervening blanks. Code the operation, parameter, and
comments fields in free form. Free form means that the fields need not begin in a
particular column. Between fields leave at least one blank; the blank serves as the
delimiter between fields.

Do not code fields, except on the comment statement, past column 71. If the total
length of the fields would exceed 71 columns, continue the fields onto one or more
following statements. Continuing fields is described under “Continuing JCL
Statements” on page 3-4. The comment statement can be coded through column
80.

Use Keywords Only for Parameters or Subparameters

3-2 z/OS V1R3.0 MVS JCL Reference

 Format: Fields
Do not use parameter or subparameter keywords from any JCL, JES2, or JES3
statements as symbolic parameters, names, or labels.

Parameter Field
The parameter field consists of two types of parameters: positional parameters
and keyword parameters. All positional parameters must precede all keyword
parameters. Keyword parameters follow the positional parameters.

Commas

Use commas to separate positional parameters, keyword parameters, and

subparameters in the parameter field.

Positional Parameters

A positional parameter consists of:

v Characters that appear in uppercase in the syntax and must be coded as shown
v Variable information, or
v A combination.
For example, DATA on a DD statement, programmer’s-name on a JOB statement,
and PGM=program-name on an EXEC statement.

Code positional parameters first in the parameter field in the order shown in the
syntax. If you omit a positional parameter and code a following positional
parameter, code a comma to indicate the omitted parameter. Do not code the
replacing comma if:
v The omitted positional parameter is the last positional parameter.
v All following positional parameters are also omitted.
v Only keyword parameters follow.
v All positional parameters are omitted.

Keyword Parameters

A keyword consists of characters that appear in uppercase in the syntax and must
be coded as shown followed by an equals sign followed by either characters that
must be coded as shown or variable information. For example, RD=R and
MSGCLASS=class-name on the JOB statement.

Code any of the keyword parameters for a statement in any order in the parameter
field after the positional parameters. Because of this positional independence, never
code a comma to indicate the absence of a keyword parameter.

Multiple Subparameters

A positional parameter or the variable information in a keyword parameter

sometimes consists of more than one item, called a subparameter list. A
subparameter list can consist of both positional and keyword subparameters. These
subparameters follow the same rules as positional and keyword parameters.

When a parameter contains more than one subparameter, separate the

subparameters by commas and enclose the subparameter list in parentheses or, if
indicated in the syntax, by apostrophes. If the list is a single keyword subparameter
or a single positional subparameter with no omitted preceding subparameters, omit
the parentheses or apostrophes.

Chapter 3. Format of Statements 3-3

Format: Fields
Null Positional Subparameters

You are allowed to specify null (that is, omitted) positional subparameters except
where the Syntax section of a particular parameter states otherwise. (For example,
null positional subparameters are not allowed on a COND parameter of an EXEC
statement or on an AMP parameter of a DD statement.) You specify a null positional
subparameter by following the coding rules listed above for an omitted positional
parameter.

JES2 Control Statement Fields

The rules for coding JES2 control statements are the same as the rules for JCL
statements, with the following additions:
v Columns 1 and 2 always contain the characters /*
v Do not code comments on any JES2 statements. Where comments are needed,
code a JCL comment statement.
v If you code the same parameter on the same statement more than once, JES2
uses the value in the last parameter.

When coding a JES2 control statement more than once, be aware of the following
JES2 actions:
v If the same parameter appears on more than one statement, JES2 uses the
value coded on the last statement.
v If the statements contain different parameters, JES2 uses all parameters
combined.

JES3 Control Statement Fields

The rules for coding JES3 control statements are the same as the rules for JCL
statements, with the following additions:
v Columns 1, 2, and 3 generally contain the characters //* (slash-slash-asterisk).
Some JES3 control statements may contain, and certain other JES3 control
statements must contain only a single slash-asterisk (/*) in columns 1 and 2.
v Columns 3 and 4 must not be blank.
v To code a comment on a JES3 control statement, code a blank after the control
statement, and end the comment before column 72.

Continuing Statements

Continuing JCL Statements

When the total length of the fields on a control statement exceeds 71 columns,
continue the fields onto one or more card images.

The following are JCL statements that you cannot continue. While you cannot
continue these statements, you can code as many separate statements as you
need.
JCL Command statement
Comment statement
Delimiter statement
Null statement

For all other JCL statements, you can continue the parameter field or the comments
field on the JCL statement. If you continue both the parameter field and the

3-4 z/OS V1R3.0 MVS JCL Reference

 Format: Continuing Statements
comments field on the same card image, the system ignores the indication to
continue the comment. How you continue a parameter field depends on whether or
not the parameter is enclosed in apostrophes.

Continuing the Parameter Field

1. Interrupt the field after a complete parameter or subparameter, including the
comma that follows it, at or before column 71.
2. Code // in columns 1 and 2 of the following statement.
3. Code a blank character in column 3 of the following statement. If column 3
contains anything but a blank or an asterisk, the system assumes the following
statement is a new statement. The system issues an error message indicating
that no continuation is found and fails the job.
4. Continue the interrupted parameter or field beginning in any column from 4
through 16.

Continuing Parameter Fields Enclosed in Apostrophes

To continue a parameter that is enclosed in apostrophes:
1. Extend the parameter to column 71.
Do not code an apostrophe in column 71 of a JCL statement that is continued.
The system interprets the apostrophe in column 71 as the final character in the
statement and ignores the continuation. See the following example:
column
71
|
// COMMAND ’R0 MVSA,S GTF.RLW,,,MBR=UNITTEST,SPC=(CYL,(100,100)),VLSR=’
// ’VOL=SER=VOL001,’,ODSN-W123456’

To correct this problem, split the statement in a different way. For example, start
COMMAND in a later column or interchange non-positional parameters in the
statement.
2. Code // in columns 1 and 2 of the following statement.
3. Continue the parameter in column 16 of the following statement even if this
splits the parameter. Trailing blanks or commas within the apostrophes do not
indicate a continued statement; the system treats them as part of the parameter.

Continuing the Comments Field

Include comments by following an interrupted parameter field with at least one
blank. To continue a comment:
1. Interrupt the comment at a convenient place before column 72, up to and
including column 71.
2. Code a nonblank character in column 72.
3. Code // in columns 1 and 2 of the following statement.
4. Code a blank character in column 3 of the following statement.
5. Continue the comments field beginning in any column after column 3.

You can use JCL comment statements as an alternative way to imbed comments in
the JCL stream.

Examples of Continued Statements

Example 1
//DD1 DD DSNAME=SWITCH.LEVEL18.GROUP12,UNIT=3350,
// VOLUME=335023,SPACE=(TRK,(80,15)),DISP=(,PASS)

Chapter 3. Format of Statements 3-5

Format: Continuing Statements
This example shows continuation of the parameter field. The parameter field is
continued from the first card image to the second card image.

Example 2
//DS1 DD DSNAME=INDS,DISP=OLD,CHKPT=EOV, MY INPUT DATA SET
// UNIT=SYSSQ,VOLUME=SER=(TAPE01,TAPE02,TAPE03)

This example shows continuation of the parameter field. The parameter field is
continued from the first card image to the second card image. The comment on the
first card image is not continued to the next card image.

Example 3
//STP4 EXEC PROC=BILLING,COND.PAID=((20,LT),EVEN),
// COND.LATE=(60,GT,FIND),
// COND.BILL=((20,GE),(30,LT,CHGE)) THIS STATEMENT CALLS X
// THE BILLING PROCEDURE AND SPECIFIES RETURN CODE TESTS X
// FOR THREE PROCEDURE STEPS.

This example shows continuation of the parameter field and the comments field.
The parameter field is continued from the first card image to the second and third
card images. The comments field is continued from the third card image to the
fourth and fifth card images.

Example 4
//S1 EXEC PGM=IEFBR14,PARM=’THIS IS A LONG PARAMETER WITHIN APOST
// ROPHES, CONTINUED IN COLUMN 16 OF THE NEXT RECORD’

This example shows continuation of a parameter field when a parameter is

enclosed in apostrophes. The parameter field is continued from column 71 of the
first card image to column 16 of the second.

Continuing JES2 Control Statements

The only JES2 control statement that you can continue is the /*OUTPUT statement.
For all other JES2 control statements, code the statement as many times as
needed.

Continuing JES3 Control Statements

Continue JES3 statements, except the command statement or //*NETACCT
statement, by:
1. Coding a comma as the last character of the first statement.
2. Coding //* in columns 1 through 3 of the continuation statement.
3. Resuming the code in column 4 of the continuation statement.

On the JES3 //*NET statement, each parameter must appear entirely on one
statement; a subparameter cannot be continued after a comma, except for the
RELEASE parameter. To continue the RELEASE parameter, end the statement with
the comma following a jobname and continue the next statement with the next
jobname. The left parenthesis appears at the beginning of the jobname list and the
right parenthesis appears at the end of the list. For example:
//*NET NETID=EXP1,RELEASE=(JOB35,JOB27Z,MYJOB,
//*WRITJB,JOBABC)

If the parameters on a //*NETACCT statement cannot fit on one statement, code

more than one //*NETACCT statement.

3-6 z/OS V1R3.0 MVS JCL Reference

Chapter 4. Syntax of Parameters
Syntax rules define how to code the fields and parameters on job control
statements. The syntax indicates:
v What the system requires.
v What is optional for the specific purpose or process you are requesting.
v How the parameters are to appear.

The syntax rules apply to all job control statements: JCL statements, JES2 control
statements, and JES3 control statements.

You must follow the syntax rules in coding job control statements to achieve
specific results. If you do not follow the rules, you may get error messages or
unpredictable results. IBM does not support the use of statements or
parameters to achieve results other than those stated in this publication.

Notation Used to Show Syntax

The syntax of the job control statements and of their parameters appear in the
chapters that describe the statements. The notation used in this publication for the
syntax is shown in Table 4-1.
Table 4-1. Notation Used to Show Syntax
Notation Meaning Examples
Uppercase letters, words, Code uppercase letters, words, and the
and characters following characters exactly as they
appear in the syntax.
& ampersand
* asterisk
, comma
= equal sign
() parentheses
. period
/ slash
Lowercase letters, words, Lowercase letters, words, and symbols in Syntax: on JOB statement
and symbols the syntax represent variables. Substitute CLASS=jobname
specific information for them.
Coded:
CLASS=A

| (vertical bar) A vertical bar indicates an exclusive OR. Syntax: on DD DCB parameter
Never code | on a control statement. It is BFALN={F|D}
used between choices within braces or Coded:
brackets; it indicates that you code only BFALN=F
one of the items within the braces or or
brackets. BFALN=D

© Copyright IBM Corp. 1988, 2002 4-1

Syntax: Notation
Table 4-1. Notation Used to Show Syntax (continued)
Notation Meaning Examples
{ } (braces) Braces surround required, related items Syntax: on DD SPACE parameter
and indicate that you must code one of the {TRK }
enclosed items. Never code { or } on a {CYL }
control statement. {blklgth}
{reclgth}
Coded:
TRK or
CYL or
960

[ ] (brackets) Brackets surround an optional item or Syntax: on DD UNIT parameter

items and indicate that you can code one [,DEFER]
or none of the enclosed items. Never code
[ or ] on a control statement. Coded:
,DEFER
or
omitted

Syntax: on DD LABEL parameter

[,RETPD=nnnn ]
[,EXPDT= {yyddd }]
[ {yyyy/ddd}]
Coded:
,RETPD=nnnn
or
,EXPDT=yyddd
or
,EXPDT=yyyy/ddd
or
omitted
{ , } or [ , ] One of the items in braces or brackets can Syntax: on DD UCS parameter
be a comma. Code the comma when you UCS=(character-set-code[,FOLD|,]
do not code any of the other items in the [,VERIFY])
braces or brackets but you are coding a
following part of the parameter. Coded:
UCS=(character-set-code)
UCS=(character-set-code,FOLD)
UCS=(character-set-code,FOLD,
VERIFY)
UCS=(character-set-code,,VERIFY)

Note that the comma is not coded if both

FOLD and VERIFY are omitted, but must
appear if FOLD is omitted and VERIFY
follows.
__ (underline) An underline indicates the default that the Syntax: on JOB or EXEC statement
system uses when you do not code a ADDRSPC={VIRT|REAL}
subparameter. Coded:
ADDRSPC omitted means
ADDRSPC=VIRT
... (ellipsis) An ellipsis follows an item that you can Syntax: on DD statement
code more than once. Never code ... on a COND=((code,operator)[,(code,operator)]....)
control statement. Coded:
Can repeat ,(code,operator)
Thus:
COND=((12,GE),(8,EQ),(4,EQ))

4-2 z/OS V1R3.0 MVS JCL Reference

 Syntax: Notation
Table 4-1. Notation Used to Show Syntax (continued)
Notation Meaning Examples
.. (two consecutive periods) Two consecutive periods indicate that a Coded: &DEPT..NYC
parameter consists of a symbolic Meaning:
parameter followed by a period and then If &DEPT is D27:
by other code, so that only part of the D27.NYC is the value
parameter is variable.

Character Sets
To code job control statements, use characters from the character sets in Table 4-2.
Table 4-3 lists the special characters that have syntactical functions in job control
statements.
Table 4-2. Character Sets
Character Set Contents
Alphanumeric Alphabetic Capital A through Z
Numeric 0 through 9
National “At” sign @ (Characters that can be
(See note) Dollar sign $ represented by hexadecimal
Pound sign # values X'7C', X'5B', and X'7B')
Comma ,
Period .
Slash /
Apostrophe '
Left parenthesis (
Right parenthesis )
Special
Asterisk *
Ampersand &
Plus sign +
Hyphen -
Equal sign =
Blank
EBCDIC text EBCDIC printable character set Characters that can be represented
by hexadecimal X'40' through X'FE'
Note: The system recognizes the following hexadecimal representations of the U.S.
National characters; @ as X'7C'; $ as X'5B'; and # as X'7B'. In countries other than the
U.S., the U.S. National characters represented on terminal keyboards might generate a
different hexadecimal representation and cause an error. For example, in some countries
the $ character may generate a X'4A'.

Table 4-3. Special Characters Used in Syntax

Character Syntactical Function
, To separate parameters and subparameters
= To separate a keyword from its value, for example, BURST=YES
(œ) To enclose subparameter list or the member name of a PDS or PDSE
& To identify a symbolic parameter, for example, &LIB
&& To identify a temporary data set name, for example, &&TEMPDS, and, to
identify an in-stream or sysout data set name, for example, &&PAYOUT
. To separate parts of a qualified data set name, for example, A.B.C., or
parts of certain parameters or subparameters, for example,
nodename.userid

Chapter 4. Syntax of Parameters 4-3

Syntax: Character Sets
Table 4-3. Special Characters Used in Syntax (continued)
Character Syntactical Function
* To refer to an earlier statement, for example, OUTPUT=*.name, or, in
certain statements, to indicate special functions: //label CNTL * //ddname
DD * RESTART=* on the JOB statement
’ To enclose specified parameter values which contain special characters
(blank) To delimit fields

Special Characters in Parameters

The syntax or parameter description indicates if the variable that you code can
contain special characters or not. Parameters and subparameters that can contain
special characters not used for syntactical functions usually must be enclosed in
apostrophes, for example, ACCT='123+456'. Code each apostrophe that is part of
the parameter or subparameter as two consecutive apostrophes, for example, code
O’NEIL as 'O''NEIL'.

Table 4-4 lists the parameters that can contain certain special characters without
requiring enclosing apostrophes.

Ampersands are used in JCL to indicate the beginning of a symbolic parameter

(see “Using System Symbols and JCL Symbols” on page 5-12). If a parameter
contains an ampersand and you do not want the system to interpret the ampersand
as a symbolic parameter, code the ampersand as two consecutive ampersands. For
example, code
//S1 EXEC PGM=IEFBR14,ACCT=’&&ABC’
//DD1 DD DSN=&&TEST,UNIT=SYSDA,SPACE=(TRK,(1,1))

The system treats double ampersands as a single character. IBM recommends that
you use apostrophes to enclose parameters that contain ampersands (other than a
DSNAME parameter representing a temporary data set) to further reduce the
possibility of error.
Table 4-4. Special Characters that Do Not Require Enclosing Apostrophes
Statement and Parameter Special Characters Not Needing Examples
or Subparameter Enclosing Apostrophes
JOB accounting information Hyphens (-) //JOBA JOB D58-D04
JOB programmer’s-name Hyphens (-), leading periods, or embedded //JOBB JOB ,S-M-TU
periods. Note that a trailing period requires //JOBC JOB ,.ABC
enclosing apostrophes. //JOBD JOB ,P.F.M
//JOBE JOB ,’A.B.C.’
EXEC ACCT Hyphens (-) or plus zero (+0, an //S1 EXEC PGM=A,ACCT=D58-LOC
overpunch) //S2 EXEC PGM=B,ACCT=D04+0
DD DSNAME Hyphens (-) DSNAME=A-B-C
Periods to indicate a qualified data set DSNAME=A.B.C
name
Double ampersands to identify a DSNAME=&&TEMPDS
temporary data set name, and to identify
an in-stream or sysout data set name DSNAME=&&PAYOUT

4-4 z/OS V1R3.0 MVS JCL Reference

 Syntax: Character Sets
Table 4-4. Special Characters that Do Not Require Enclosing Apostrophes (continued)
Statement and Parameter Special Characters Not Needing Examples
or Subparameter Enclosing Apostrophes
Parentheses to enclose the member name DSNAME=PDS1(MEMA)
of a partitioned data set (PDS) or DSNAME=ISDS(PRIME)
partitioned data set extended (PDSE), the DSNAME=GDS(+1)
area name of an indexed sequential data
set, or the generation number of a
generation data set name of a partitioned
data set (PDS) or partitioned data set
extended (PDSE), the area name of an
indexed sequential data set, or the
generation number of a generation data
set
Plus (+) or minus (-) sign to identify a DSNAME=GDS(-2)
generation of a generation data group
DD VOLUME=SER Hyphens (-) VOLUME=SER=PUB-RD
DD UNIT device-type Hyphens (-) UNIT=3330-1

Syntax Notes
JCL positional parameters and keywords can have at most two levels of
subparameters. Therefore, when parentheses are used to delimit a list of
subparameters, a maximum of two levels of parenthesis nesting is permitted. This
restriction applies even if the parentheses are empty.

Backward References
Many parameters in job control statements can use a backward reference to fill in
information. A backward reference is a reference to an earlier statement in the job
or in a cataloged or in-stream procedure called by a job step. A backward reference
is in the form:
v *.name or *.ddname where name or ddname is the name field of the referenced
statement.
v *.stepname.name or *.stepname.ddname where the referenced statement,
name or ddname, is in an earlier step, stepname, in the same job.
v *.stepname.procstepname.name or *.stepname.procstepname.ddname where
this job step or an earlier job step, stepname, calls a procedure; the procedure
contains procedure step, procstepname, which contains the referenced
statement, name or ddname.

If stepname is specified without a procstepname, it identifies an EXEC statement

that contains a PGM parameter, not one that invokes a procedure. Similarly, if
stepname.procstepname is coded, procstepname identifies an EXEC statement
containing the PGM parameter in the procedure invoked by stepname.

The backward reference lets you copy previously coded information or refer to an
earlier statement. The following parameters can make backward references:
v DD CNTL refers to earlier CNTL statement
v DD DCB refers to earlier DD statement to copy its DCB parameter
v DD DSNAME refers to earlier DD statement to copy its DSNAME parameter,
whether or not the data set is a partitioned data set, and whether or not the data
set is a temporary data set

Chapter 4. Syntax of Parameters 4-5

Syntax: Backward References
v DD OUTPUT refers to earlier OUTPUT JCL statement
v DD REFDD refers to earlier DD statement to copy its data set attributes
v DD VOLUME=REF refers to earlier DD statement to use the same volume(s).
The LABEL label type subparameter is also copied from the referenced DD
statement.
v EXEC PGM refers to an earlier DD statement that defines the program to be
executed as a member of a partitioned data set

The following statements cannot be referenced:

v DD * statement in DCB, DSNAME, or VOLUME parameter
v DD DATA statement in DCB, DSNAME, or VOLUME parameter
v DD DUMMY statement in VOLUME or UNIT parameter. The referring DD
statement acquires a dummy status.
v DD DYNAM statement
v DD statement containing FREE=CLOSE in VOLUME or UNIT parameters
v Nested procedure statements
v Sysout DD statement
v DD statement that is the target of a DDNAME= reference.
v A DD statement containing a PATH parameter

Examples of Backward References

Example 1
//JOB1 JOB ...
//STEPA EXEC ...
//DD1 DD DSNAME=REPORT
.
.
//DD4 DD DSNAME=*.DD1

The referring and referenced DD statements are in the same step.

Example 2
//JOB2 JOB ...
//STEP1 EXEC ...
//DDA DD DSNAME=D58.POK.PUBS01
.
.
//STEP2 EXEC ...
//DDB DD DSNAME=*.STEP1.DDA

The referring and referenced DD statements are in different steps in the same job.

Example 3

Cataloged procedure PROC1 contains:

//PS1 EXEC ...
.
.
//PSTEP1 EXEC ...
//DS1 DD DSNAME=DATA1
//PSTEP2 EXEC ...
//DS2 DD DSNAME=DATA2
.

The job contains:

4-6 z/OS V1R3.0 MVS JCL Reference

 Syntax: Backward References
//JOB5 JOB ...
//CALLER EXEC PROC=PROC1
.
//REF1 DD DSNAME=*.CALLER.PSTEP2.DS2
//NEXT EXEC ...
//REF2 DD DSNAME=*.CALLER.PSTEP1.DS1
.

DD statement REF1 in the calling step refers to DD statement DS2 in procedure

step PSTEP2. DD statement REF2 in a step after the calling step refers to DD
statement DS1 in procedure step PSTEP1. Note that the entire procedure is
processed when the calling EXEC statement is processed; therefore, all DD
statements in the procedure are earlier than all DD statements in the calling step.

Chapter 4. Syntax of Parameters 4-7

4-8 z/OS V1R3.0 MVS JCL Reference
Chapter 5. Procedures and Symbols
This chapter describes how to use procedures, including nested procedures. It also
explains how to use JCL symbols and system symbols.

Cataloged and In-Stream Procedures

For jobs that you run frequently or types of jobs that use the same job control,
prepare sets of job control statements, called procedures.

In-stream Procedures
When you place a procedure in the job input stream, it is called an in-stream
procedure.

An in-stream procedure must begin with a PROC statement, end with a PEND
statement, and include only the following other JCL statements: CNTL, comment,
DD, ENDCNTL, EXEC, IF/THEN/ELSE/ENDIF, INCLUDE, OUTPUT JCL, and SET.
You must observe the following restrictions regarding in-stream procedures:
v Do not place any JCL statements (other than the ones listed above) or any JES2
or JES3 control statements in the procedure.
v Do not place an in-stream data set (one that begins with DD * or DD DATA) in
the procedure.
v Do not define one in-stream procedure within another, that is, nested. For
information about nesting procedures, see “Nested Procedures” on page 5-9.
v Do not use an in-stream procedure if the procedure will be run as a started job
under the MASTER subsystem, that is, includes a JOB statement and is started
via a START command such as S procname,SUB=MSTR.

Cataloged Procedures
A procedure that you catalog in a library is called a cataloged procedure.

A cataloged procedure may consist of these JCL statements: CNTL, command, DD,
ENDCNTL, EXEC, IF/THEN/ELSE/ENDIF, INCLUDE, OUTPUT JCL, and SET.
Optionally, a cataloged procedure can begin with a PROC statement and end with a
PEND statement. If coded, PROC must be the first statement in the procedure.

Cataloging a Procedure
The library containing cataloged procedures is a partitioned data set (PDS) or a
partitioned data set extended (PDSE). The system procedure library is
SYS1.PROCLIB. The installation can have many more procedure libraries with
different names. You can also have procedures in a private library. The name of a
cataloged procedure is its member name or alias in the library.

When a cataloged procedure is called, the calling step receives a copy of the
procedure; therefore, a cataloged procedure can be used simultaneously by more
than one job.

If you are modifying a cataloged procedure, do not run any jobs that use the
procedure during modification.

In a JES3 system, you can specify UPDATE on the JES3 //*MAIN statement to
update a procedure library.

© Copyright IBM Corp. 1988, 2002 5-1

Procedures
Using a Procedure
To execute a procedure, call it on an EXEC statement in an in-stream job. Specify
the name of the procedure in the PROC parameter of the EXEC statement. The
step uses the JCL statements in the procedure as if the JCL statements appeared
in the input stream immediately following the EXEC statement. If necessary, you
can modify the procedure for the current execution of the job step.

When you call a procedure, the system retrieves it using the following search order:
1. From the input stream
If the called procedure is an in-stream procedure, the system retrieves it from
the job input stream. You must place the in-stream procedure before the EXEC
statement that calls it.
2. From a private library
If the called procedure is cataloged in a private library, the system retrieves it
from the private library that you specify on the JCLLIB statement that appears
earlier in the job stream.
3. From the system library (in a non-APPC scheduling environment)
If the called procedure is cataloged in a system library, the subsystem retrieves
it as follows:
v In JES2, from the library name on the PROCLIB= parameter on a JES2
/*JOBPARM statement. See “/*JOBPARM Statement” on page 27-3 for more
information.
v In JES3, from the library name on the PROC= parameter of the JES3
//*MAIN statement. See “//*MAIN Statement” on page 28-22 for more
information.
v In MSTR, the data set specified by the IEFPDSI DD statement in the
currently active master JCL is searched for procedures. The default master
JCL specifies SYS1.PROCLIB.

Testing a Procedure
Before putting a procedure into a system procedure library, you should test it. There
are two ways to test a procedure:
v Place a PROC statement before the procedure and a PEND statement after it
and place it in a job input stream. For the test, call this in-stream procedure with
an EXEC statement that appears later in the same job.
v Put a procedure to be tested in a private library, identify the library on a JCLLIB
statement, and call the procedure with an EXEC statement.

After testing a procedure, the type of environment in which you are running the job
determines where you can catalog it.
v In an APPC scheduling environment: Catalog the procedure in a private
library, and define the library with a JCLLIB statement.
v In a non-APPC scheduling environment: Catalog the procedure in the system
procedure library SYS1.PROCLIB, an installation-defined procedure library, or a
private library. Cataloging the procedure in the system procedure library allows
anyone to use the procedure by calling it with an EXEC statement.

Cataloged and in-stream procedures are not checked for correct syntax until an
EXEC statement that calls the procedure is checked for syntax. Therefore, a
procedure can be tested only if an EXEC statement calls it.

5-2 z/OS V1R3.0 MVS JCL Reference

 Modifying Procedures

Modifying Procedures
There are two ways you can modify a procedure:
v Using system symbols and JCL symbols
v Using overrides.

Using system symbols and JCL symbols, you can design your procedures to be
easily modified. If the procedure does not contain required system symbols and JCL
symbols, you can override the statement.

For its current execution, you can override an in-stream or cataloged procedure by:
v Overriding, nullifying, or adding EXEC statement parameters
v Overriding, nullifying, or adding parameters to DD or OUTPUT JCL statements
v Adding DD or OUTPUT JCL statements

Overriding a parameter modifies only that parameter; the system uses all other
parameters on the original statement. For example, if you override the data set
name on a DD statement that includes a UNIT and VOL=SER parameter, the
system will still use the UNIT and VOL=SER parameters.

Invalid parameters in a procedure cannot be corrected through overrides. Before

processing overrides, the system scans the original procedure statements for errors
and issues error messages.

Explanation
Modifying EXEC Statement Parameters
All keyword parameters on the calling EXEC statement affect the execution of the
procedure, as follows:

All procedure statements

If a keyword parameter is to override the parameter or be added to every EXEC

statement in the procedure, code the parameter in the usual way. For example, the
ACCT parameter applies to all steps:
//STEP1 EXEC PROC=RPT,ACCT=5670

Note: A PARM parameter without a procstepname qualifier applies only to the first
procedure step. A TIME parameter without a procstepname qualifier applies
to the entire procedure and nullifies any TIME parameters on procedure step
EXEC statements.

If the keyword parameter is to nullify the parameter on every EXEC statement in the
procedure, code it without a value following the equal sign. For example, the ACCT
parameter is nullified in all steps:
//STEP2 EXEC PROC=RPT,ACCT=

Only one procedure statement

If the keyword parameter is to override the parameter or be added to only one

EXEC statement in the procedure, code .procstepname immediately following the
keyword. The procstepname is the name field of the procedure EXEC statement
containing the keyword parameter to be overridden. For example, the ACCT
parameter applies to only step PSTEPWED:
//STEP1 EXEC PROC=RPT,ACCT.PSTEPWED=5670

Chapter 5. Procedures and Symbols 5-3

Modifying Procedures
If the keyword parameter is to nullify the parameter on only one EXEC statement in
the procedure, code it with the procstepname. For example:
//STEP2 EXEC PROC=RPT,ACCT.PSTEPTUE=

The override, nullification, or addition applies only to the current execution of the job
step; the procedure itself is not changed.

Rules for Modifying EXEC Parameters

v You cannot modify a PGM parameter.
v The calling EXEC statement can contain changes for more than one parameter
and for the same parameter in more than one step in a called procedure. (If you
code multiple overrides for any parameter in the same step, only the last
specification will be effective.)
v Modifying parameters should appear in the following order:
– Parameters without a procstepname qualifier.
– All parameters modifying the first step, then the second step, then the third
step, and so forth.
v You do not need to code the parameters for each step in the same order as they
appear on the procedure EXEC statement.
v You must code an entire overriding parameter even if you are changing only part
of it.

Modifying OUTPUT JCL and DD Statements

OUTPUT JCL and DD statements that follow the calling EXEC statement
v Override, nullify, or add parameters to OUTPUT JCL and DD statements in the
procedure, or
v Are added to the procedure.
These changes affect only the current execution of the job step; the procedure itself
is not changed. When an OUTPUT JCL statement is modified, the sysout data set
is processed according to the parameters as modified by the overriding statement.

In a procedure, to ensure that OUTPUT JCL and DD statements are overridden

correctly by modifying statements, place the OUTPUT JCL statements before the
DD statements in each step of the procedure.

Location in the JCL

Place modifying OUTPUT JCL and DD statements in the following order, after the
EXEC statement that calls the procedure:
v For each procedure step in the invoked procedure:
1. Overriding statements can appear in any order when they explicitly specify
the step that is being overridden. Added statements can appear in any order
when they specify the step explicitly.
2. Overriding and added statements that do not explicitly specify the step are
applied to the step named in the previous overriding or added OUTPUT JCL
or DD statement. If no previous override statement named a step, then they
are applied to the first step in the procedure.
v For all procedure steps in the invoked procedure, place the modifying statements
for each procedure step in the same order in which the procedure steps are
specified.

Coding an Overriding Input Stream DD Statement

5-4 z/OS V1R3.0 MVS JCL Reference

 Modifying Procedures
Code overriding input stream DD statements in the order of the steps that they are
overriding. Within a step, code the overriding statements in the order of the DD
statements that they are overriding. If you do not code the overriding input stream
DD statements in the proper order, the system considers the overriding statements
to be additions to the step.

Coding an Overriding OUTPUT JCL or DD Statement

To override, nullify, or add parameters to a procedure OUTPUT JCL or DD

statement, code in the name field of the overriding OUTPUT JCL or DD statement
the name of the procedure step containing the overridden statement, followed by a
period, followed by the name of the procedure OUTPUT JCL statement or the
ddname of the procedure DD statement.
//pstepname.name OUTPUT parameters
//pstepname.ddname DD parameters

Rules for Modifying OUTPUT JCL or DD Parameters

The override operation merges the parameters from an overriding statement with
those in the overridden statement. Follow these rules in coding overriding
statements:
v You can code more than one change on an overriding statement.
v You can code modifying parameters in any order on an overriding statement.
v Code an entire overriding parameter even when changing only part of that
parameter.
v If you code a parameter on an overriding statement that is not on the procedure
statement, the override operation adds it to the procedure statement.
v Nullify a parameter by not coding a value after the equal sign. Omitting the value
causes the system to treat the keyword as if it had been removed from the
procedure statement. This is the only way to nullify keywords that do not permit a
null parameter value.
v If you add a parameter that is mutually exclusive with a parameter on a
procedure statement, the override operation automatically nullifies the procedure
parameter. This is the only exception to the rule that the only way to override a
parameter is to specify it explicitly.
Example: If a DD statement within a procedure reads:

//ddname DD DSN=FRED,DISP=SHARE,UNIT=TAPE,VOL=SER=111111

and you wish to modify that DD statement to read in

data set GEORGE, which is cataloged to a DASD volume,
it is NOT sufficient to specify:

//stepname.ddname DD DSN=GEORGE

Instead you must specify:

//stepname.ddname DD DSN=GEORGE,UNIT=,VOL=

This nullifies the UNIT and VOLUME information, allowing

the system to retrieve that information from the catalog.
(An overriding DD statement without those parameters would
cause the system to find data set GEORGE on tape volume
serial 111111.)

Additional Rules for Modifying DD Parameters

Chapter 5. Procedures and Symbols 5-5

Modifying Procedures
v To nullify all parameters but the DCB parameter, code DUMMY on the overriding
DD statement.
v Special rules apply when overriding a DCB parameter:
– Code only the keyword subparameters to be changed; the other DCB
subparameters remain unchanged.
– If a positional subparameter is needed, code it, regardless of whether it
appears in the overridden DCB parameter. If a positional subparameter is not
needed or is to be nullified, omit it from the overriding DCB parameter.
– To nullify the entire DCB parameter, nullify each subparameter appearing in
the overridden DCB parameter.
v To nullify a DUMMY parameter on the procedure statement, code one of the
following on the overriding statement:
– A DSNAME parameter with a name other than NULLFILE
– A SYSOUT parameter
– A * or DATA parameter
– A SUBSYS parameter.

Adding an OUTPUT JCL or DD Statement

To add OUTPUT JCL or DD statements to a procedure step, code in the name field
of the added OUTPUT JCL or DD statement the name of the procedure step,
followed by a period, followed by a name or ddname. The name must not appear
on any procedure statement.
//pstepname.name OUTPUT parameters
//pstepname.ddname DD parameters

If you omit the procedure step name, the statement is added to the step named in
the previous OUTPUT JCL or DD statement that named a step. If no previous
statements named steps, the statement is added to the first step in the procedure.

Added OUTPUT JCL and DD statements can contain symbols. If the statement is
being added to the last procedure step, any symbols it contains must appear
elsewhere in the procedure.

Supplying In-stream Data for a Procedure

To supply a procedure step with data from the input stream, code a DD * or DD
DATA statement in the calling step after the last overriding and added DD
statement. The name field of this statement must contain the name of the
procedure step, followed by a period, followed by a ddname. The ddname can be of
your choosing or predefined in the procedure. If it is predefined, it appears in a
DDNAME parameter on a procedure DD statement. For example:
//PROCSTP1.ANYNAME DD *
//PROCSTP2.PREDEFN DD DATA

Rules for Modifying DD Statements in Concatenated Data Sets

v To override the first DD statement in a concatenation, code only one overriding
DD statement.
v To override any following DD statements in the concatenation, code an overriding
DD statement for each concatenated DD statement.
v The overriding DD statements must be in the same order as the concatenated
DD statements.

5-6 z/OS V1R3.0 MVS JCL Reference

 Modifying Procedures
v Code a ddname on only the first overriding DD statement. Leave the ddname
field blank on the following statements.
v To leave a concatenated statement unchanged, code its corresponding overriding
DD statement with a blank operand (or parameter) field.

Examples of Procedures
Example 1
In the input stream:

//JOBA JOB ACCT23,’G. HILL’

//STEPA EXEC PROC=REP
//PSTEP1.INDS DD *
.
(data)
.
/*

In SYS1.PROCLIB member REP:

// PROC
//PSTEP1 EXEC PGM=WRIT22
//OUTDS DD SYSOUT=A

In this example, the EXEC statement STEPA calls the cataloged procedure named
REP and supplies in-stream data. The procedure executes a program named
WRIT22. The output from the program will appear in the sysout class A data set.

Example 2
In the input stream:

//JOB1 JOB ,’H.H. MORRILL’

//ADD1 OUTPUT COPIES=2
//STEPA EXEC PROC=P
//PS1.OUTA OUTPUT CONTROL=DOUBLE,COPIES=5
//PS1.DSB DD OUTPUT=*.ADD1
//PS1.DSE DD *
.
(data)
.
/*
//PS2.OUTB OUTPUT DEFAULT=YES,DEST=STL

In SYS1.PROCLIB member P:

//PS1 EXEC PGM=R15

//OUTA OUTPUT CONTROL=PROGRAM
//DSA DD SYSOUT=C,OUTPUT=*.OUTA
//DSB DD SYSOUT=D,OUTPUT=*.OUTA
//PS2 EXEC PGM=T48
//DSC DD SYSOUT=A

In this example, added statements are:

v ADD1, which is an OUTPUT JCL statement added at the job level.
v PS1.DSE, which is an in-stream data set added to procedure step PS1.
v PS2.OUTB, which is a default OUTPUT JCL statement added to procedure step
PS2.

Overriding statements are:

v PS1.OUTA, which changes the CONTROL parameter and adds a COPIES
parameter to OUTPUT statement OUTA in procedure step PS1.

Chapter 5. Procedures and Symbols 5-7

Modifying Procedures
v PS1.DSB, which changes the OUTPUT parameter on DD statement DSB in
procedure step PS1.

Example 3
//JOBB JOB ACCT23,’G. HILL’
//STEPB EXEC PROC=WRIT35,COND.PSTEP3=(4,GT,PSTEP1),RD=R
//PSTEP1.DD1 DD VOLUME=SER=,UNIT=SYSDA,DISP=(NEW,CATLG)
//PSTEP1.INDS DD *
.
.
(data)
.
/*
//PSTEP2.DD3 DD DISP=(OLD,KEEP)
//PSTEP3.DD5 DD DUMMY
//PSTEP3.DD6 DD DSNAME=A.B.C
//PSTEP3.DD8 DD EXPDT=

In SYS1.PROCLIB member WRIT35:

// PROC
//PSTEP1 EXEC PGM=WT1,TIME=(,50)
//DD1 DD DSNAME=DATA1,DISP=(NEW,DELETE),SPACE=(TRK,(10,2)),
// UNIT=3330,VOL=SER=1095
//DD2 DD DSNAME=&&WORK,UNIT=SYSDA,SPACE=(CYL,(10,1)),
// DISP=(,PASS)
//PSTEP2 EXEC PGM=WT2,TIME=(,30)
//DD3 DD DSNAME=*.PSTEP1.DD2,DISP=(OLD,DELETE)
//PSTEP3 EXEC PGM=UPDT,TIME=(,45),RD=RNC
//DD4 DD SYSOUT=*
//DD5 DD DSNAME=DATA3,UNIT=3340,DISP=OLD,
// VOLUME=SER=335006
//DD6 DD DSNAME=QOUT,UNIT=3400-5
//DD7 DD SYSOUT=H
//DD8 DD DSNAME=A.B,DISP=(NEW,CATLG,DELETE),
// SPACE=(TRK,(1)),EXPDT=92365,UNIT=SYSDA

In this example, EXEC statement STEPB calls the cataloged procedure WRIT35.
The COND parameter is added to the EXEC statement for PSTEP3. The RD
parameter is added to the EXEC statements for PSTEP1 and PSTEP2, and
overrides the RD parameter on the EXEC statement for PSTEP3.

In-stream DD statement PSTEP1.DD1 modifies DD statement DD1 in PSTEP1; it

nullifies the VOLUME=SER parameter and overrides the UNIT and DISP
parameters. Note that the parameters are not in the same order in the overriding
and overridden statements.

In-stream DD statement PSTEP1.INDS is added to PSTEP1, supplying in-stream

data to be read by program WT1.

In-stream DD statement PSTEP2.DD3 modifies DD statement DD3 in PSTEP2; it

overrides the DISP parameter. Note that the entire parameter is coded, even though
only the second subparameter is being changed.

In-stream DD statement PSTEP3.DD5 nullifies DD statement DD5 in PSTEP3.

However, DD statement DD5 will be checked for correct syntax.

In-stream DD statement PSTEP3.DD6 modifies DD statement DD6 in PSTEP3; it

overrides the DSNAME parameter.

5-8 z/OS V1R3.0 MVS JCL Reference

 Modifying Procedures
In-stream DD statement PSTEP3.DD8 modifies DD statement DD8 in PSTEP3; it
nullifies the EXPDT parameter. Note that the EXPDT keyword cannot have a null
value. Therefore, you cannot nullify EXPDT by setting it to a substitution text in the
procedure DD and then nullifying the symbol on the invoking EXEC statement.
EXPDT can only be nullified by not coding a value for it on the overriding DD
statement.

Note that procedure DD statements DD2, DD4, and DD7 were not modified.

Nested Procedures
Cataloged and in-stream procedures can invoke other procedures (up to 15 levels
of nesting). In a procedure, an EXEC statement can invoke another procedure,
which can contain an EXEC statement to invoke another procedure, and so on.

Note that an in-stream procedure cannot be defined within another procedure. The
sequence PROC, PROC, PEND, PEND is not valid.

Nesting Procedures
The following shows how procedures can be nested:
Procedure C:
//C PROC
//CS1 EXEC PGM=GHI
.
// PEND

Procedure B:
//B PROC
//BS1 EXEC PROC=C
.
//BS2 EXEC PGM=DEF
.
// PEND

Procedure A:
//A PROC
//AS1 EXEC PROC=B
.
//AS2 EXEC PGM=ABC
.
// PEND

Job Stream:
//JOB1 JOB
//STEP1 EXEC PROC=A
.
//STEP2 EXEC PGM=JKL
.
.

The following statements are equivalent to the nested procedures shown above and
show the levels of nesting (scoping) for the procedures.
//JOB1 JOB Level 0
//CS1 EXEC PGM=GHI Level 3
.
//BS2 EXEC PGM=DEF Level 2
.
//AS2 EXEC PGM=ABC Level 1

Chapter 5. Procedures and Symbols 5-9

Nested Procedures
.
//STEP2 EXEC PGM=JKL Level 0
.
.

Modifying Nested Procedures

The rules for modifying OUTPUT JCL and DD statements described in “Modifying
OUTPUT JCL and DD Statements” on page 5-4 apply to nested procedures.

In addition, the following rules apply to modifying statements in nested procedures.

1. Procedure and step names referenced by other statements in the job should be
unique within the job.
2. Modifying or additional JCL statements must appear in the job stream following
the EXEC statement for the procedure they are to modify and prior to the next
EXEC statement.
3. Modifying or additional JCL statements apply to one level of nesting only. You
can use statements to modify statements in a procedure only for the level of
nesting at which the EXEC statement for that procedure appears.
4. Modifying or additional JCL statements cannot themselves be modified. Do not
modify statements that are overrides or additions to a procedure.
5. Modifying or additional JCL statements can only have procstepname.name or
procstepname.ddname in their name field. Do not specify backward references
to nested procedures, such as procstepname.procstepname.ddname DD
parameters.

These rules are illustrated in the examples in this topic.

Examples of Modifying Nested Procedures

Examples are shown on the following pages.

Example 1

The following example shows overrides and additions to DD statements.

Procedure C:
//C PROC
//CS1 EXEC PGM=CCC
//CS1DD1 DD DSNAME=A.B.C,DISP=SHR
//CS1DD2 DD SYSOUT=A
// PEND

Procedure B:
//B PROC
//BS1 EXEC PROC=C
//CS1.CS1DD1 DD DSNAME=X.Y.Z This statement is a valid
//* override of procedure C, stepCS1
//* for DD CS1DD1
//*
//CS1.CS1DD3 DD SYSOUT=A This statement is a valid
//* addition to procedure C, step CS1
//BS2 EXEC PGM=BBB
//BS2DD1 DD DSNAME=E,DISP=SHR
// PEND

Procedure A:
//A PROC
//AS1 EXEC PROC=B
//BS2.BS2DD2 DD DSNAME=G,DISP=SHR This statement is a valid
//* addition to procedure B, step BS2

5-10 z/OS V1R3.0 MVS JCL Reference

 Nested Procedures
//AS2 EXEC PGM=AAA
//AS2DD1 DD DSNAME=E,DISP=SHR
// PEND

Job Stream:
//JOB1 JOB
//STEP1 EXEC PROC=A
//AS2.AS2DD2 DD DSNAME=G,DISP=SHR This statement is a valid
//* addition to procedure A, step AS2
//STEP2 EXEC PGM=IEFBR14
.

The following statements are equivalent to the nested procedures shown above.
//JOB1 JOB
//CS1 EXEC PGM=CCC
//CS1DD1 DD DSNAME=X.Y.Z,DISP=SHR
//*
//CS1DD2 DD SYSOUT=A
//CS1DD3 DD SYSOUT=A
//*
//BS2 EXEC PGM=BBB
//BS2DD1 DD DSNAME=E,DISP=SHR
//BS2DD2 DD DSNAME=G,DISP=SHR
//*
//AS2 EXEC PGM=AAA
//AS2DD1 DD DSNAME=E,DISP=SHR
//AS2DD2 DD DSNAME=G,DISP=SHR
//STEP2 EXEC PGM=IEFBR14

Example 2

The following example shows nested procedures and invalid overrides of DD

statement parameters that result in JCL errors. The example refers to the rules that
appear in “Modifying Nested Procedures” on page 5-10.
Procedure C:
//C PROC
//CS1 EXEC PGM=CCC
//CS1DD1 DD DSN=A.B.C,DISP=SHR
//CS1DD2 DD SYSOUT=A
// PEND

Procedure B:
//B PROC
//BS1 EXEC PROC=C
//CS1.CS1DD1 DD DSNAME=X.Y.Z
//CS1.CS1DD3 DD SYSOUT=A
//BS2 EXEC PGM=BBB
//BS2DD1 DD DSN=E,DISP=SHR
// PEND

Procedure A:
//A PROC
//AS1 EXEC PROC=B
//BS1.CS1.CS1DD1 DD DSN=X.Y.Z This statement is an invalid
//* override of procedure B, step BS1,
//* DD CS1.CS1DD1 (rules 4 and 5)
//*
//BS1.CS1.CS1DD3 DD SYSOUT=A This statement is an invalid
//* override of procedure B, step BS1,
//* DD CS1.CS1DD3 (rules 4 and 5)
//*
//BS1.BS1DD1 DD DSN=G,DISP=SHR This statement is an invalid
//* addition to procedure B, step BS1
//* (rule 3)
//AS2 EXEC PGM=AAA

Chapter 5. Procedures and Symbols 5-11

Nested Procedures
//AS2DD1 DD DSN=E,DISP=SHR
// PEND

Job Stream:
//JOB1 JOB
//STEP1 EXEC PROC=A
//AS1.BS1.CS1.CS1DD1 DD DSN=X This statement is an invalid
//* override of procedure A, step AS1,
//* DD BS1.CS1.CS1DD1 (rules 3 and 5)
//STEP2 EXEC PGM=IEFBR14

Using System Symbols and JCL Symbols

System symbols and JCL symbols are character strings that represent variable
information in JCL. They allow you to modify JCL statements in a job easily. A
symbol-defining string is limited to eight characters, not including an identifying
ampersand.

This section:
v Describes system symbols and JCL symbols and the differences between them
v Explains how to define JCL symbols
v Shows how to code system symbols and JCL symbols.

What are System Symbols?

System symbols represent values that are unique to each system. A system
replaces those symbols with its own values when it processes started task JCL
(jobs and procedures read from a procedure library) and TSO logons. (A started
task is a task resulting from JCL that is processed immediately as a result of a
START command. For additional information about started tasks, see Chapter 7,
“Started Tasks” on page 7-1.)

Rules for governing system symbol use are:

v You can use system symbols in started task JCL (for both jobs and procedures)
and in TSO logon procedures.
v Within started task JCL you can use system symbols wherever you use JCL
symbols (described under “What are JCL Symbols?” on page 5-13).
v You cannot use system symbols, except for &SYSUID, in batch JCL.

The difference between system symbols and JCL symbols is:

v Substitution texts for system symbols are either fixed for the life of an IPL (static
system symbols) or determined by the system (dynamic system symbols).
v Substitution texts for JCL symbols can be controlled through input job stream
modifications to their definitions.

Before you use system symbols in JCL, see z/OS MVS Initialization and Tuning
Reference for a complete list of system symbols and for details about how they
work. Then read the rest of this section for specific information about using system
symbols in started task JCL.

Displaying Static System Symbols

If you are authorized to do so, you can enter the DISPLAY SYMBOLS command to
display the static system symbols and associated substitution texts that are in effect
for a member. The output from DISPLAY SYMBOLS shows you the system symbols
that you can specify. See the description of DISPLAY SYMBOLS in z/OS MVS
System Commands for the command syntax.

5-12 z/OS V1R3.0 MVS JCL Reference

 System Symbols and JCL Symbols
Using System Symbols in Started Task JCL
The general rules and recommendations for using system symbols (which are
described in z/OS MVS Initialization and Tuning Reference) apply to started task
JCL. The following are exceptions to those general rules and recommendations:
v Normally, you can specify an optional period at the end of system symbols. In
started task JCL, you must follow the rules for JCL symbols when placing a
period at the end of system symbols. See “Using Symbols Before Fixed Code” on
page 5-23 for details.
v Although dynamic system symbols are supported in started task JCL, IBM does
not recommend that you code them in started task JCL. The system substitutes
text for dynamic system symbols at conversion time, which means that the
system could assign different substitution texts to the same dynamic system
symbol within the same job.
For example, the resolved substitution text for the &JOBNAME dynamic system
symbol is the name of the job assigned to the address space in which the JCL is
converted, not the name of the JCL job being processed.

For further information about specifying system symbols in started task JCL,
including examples, see “Using Symbols in Started Task JCL” on page 7-8.

What are JCL Symbols?

JCL symbols differ from system symbols in that you must define them in started
task JCL before you can use them in that JCL. The JCL symbols that you define
are valid only for the current job. Conversely, there is no need to define system
symbols; they are either defined to MVS or defined by your installation, and you can
use them in any set of started task JCL.

The rules for coding JCL symbols are the same as for coding system symbols. You
can code system symbols anywhere in started task JCL that you code JCL
symbols.

This section explains how to define, nullify, and use JCL symbols in JCL.

Defining and Nullifying JCL Symbols

When you code JCL symbols, you must define or nullify them in your JCL each time
a job runs; otherwise, the system does not substitute text for JCL symbols.

The maximum length of any substitution text that you can assign to a JCL symbol is
255 characters.

To define or nullify a JCL symbol, code the substitution text on one or more of the
following:
1. The EXEC statement that calls procedures.
Use the EXEC statement to define substitution texts on statements in the called
procedures. The substitution texts you assign override the default substitution
texts assigned on the PROC statement. For example:
//STEP1 EXEC PROC=SEARCH,PARM1=’MYDS1.PGM’

The system uses a JCL symbol defined on the EXEC statement for any
procedures that it invokes. A JCL symbol defined on an EXEC statement is not
in effect for subsequent job steps in the same level of procedure nesting. See
“Using Symbols in Nested Procedures” on page 5-26 for more information.

Chapter 5. Procedures and Symbols 5-13

System Symbols and JCL Symbols
If you specify duplicate JCL symbols on an EXEC statement, the system uses
the first substitution text as the default.
2. The PROC statement that begins a procedure.
The PROC statement must begin in-stream procedures and can begin
cataloged procedures. Use the PROC statement to define default substitution
texts for JCL symbols in the procedure (you can override the defaults on the
EXEC statement). If you do not define or nullify the substitution text for a JCL
symbol on the EXEC statement, the system uses the default substitution text.
For example:
//PROC1 PROC PARM2=OLD,PARM3=111222

If you specify duplicate JCL symbols on a PROC statement, the system uses
the first substitution text as the default.

Assign only one substitution text to each JCL symbol used in a procedure.
3. The SET statement that defines and nullifies JCL symbols.
Code the SET statement in the JCL before the first use of the JCL symbol. Use
the SET statement to define JCL symbols that are used on:
v JCL statements in the JCL stream
v Statements in a procedure (when the EXEC statement that calls the
procedure and the PROC statement for the procedure do not also define JCL
symbols).

For example:
//LEVEL1 SET PARM2=NEW,PARM3=DELETE

If you define duplicate JCL symbols on a SET statement, the system assigns
the last substitution text to the JCL symbol.

Note: The substitution text specified on the SET statement is assigned to the
JCL symbol regardless of the logic of the construct. This is because the
SET statement is not executed conditionally (such as in the THEN and
ELSE clauses of an IF/THEN/ELSE/ENDIF statement construct).

If the SET statement defines a value for a JCL symbol but that symbol is not coded
in the JCL, there is no JCL error. Otherwise:
v All JCL symbols for which values are defined must be coded in the JCL.
v All JCL symbols coded in the JCL must have defined values.

Syntax of JCL Symbol Definitions

To define a substitution text to a JCL symbol, code:

JCL_symbol_name=substitution_text

Rules for Defining JCL Symbols

v Define a substitution text that is 1-255 characters long.
v Enclose within apostrophes substitution texts that do not fit on a single line.
Continue values that do not fit on a single line as described in “Continuing JCL
Statements that Contain Symbols” on page 5-20.
v Do not specify the ampersand that identifies the JCL symbol in the procedure.
v Define JCL symbols on EXEC, PROC, or SET statements, as described in
“Defining and Nullifying JCL Symbols” on page 5-13. For example, if the JCL

5-14 z/OS V1R3.0 MVS JCL Reference

 System Symbols and JCL Symbols
symbol &NUMBER appears on one or more DD statements in a procedure, and
you want to substitute the text 3380 for &NUMBER, code one or more of the
following:
//SET1 SET NUMBER=3380

//STEP1 EXEC PROC=PROC1,NUMBER=3380

//PROC1 PROC NUMBER=3380

v Do not specify JCL symbols within other JCL symbols. The results can be
unpredictable, especially if the imbedded JCL symbol is not previously defined.

Defining Names for JCL Symbols

IBM recommends that your installation define standard names for frequently used
JCL symbols and enforce the use of those names. For example, if your installation
frequently assigns department numbers in procedures, define the &DEPT JCL
symbol and use it consistently. If your installation plans to provide a standard set of
JCL symbols, ensure that all system and application programmers know about
those JCL symbols.

You can define names for JCL symbols that are the same as system symbol
names. When a JCL symbol has the same name as a system symbol, the
substitution text for the JCL symbol overrides the substitution text for the
system symbol. For example, if JCL defines a symbol with the name &SYSNAME,
which is also the name of a system symbol, the system uses the substitution text
that is defined in the JCL.

Defining Default Substitution Texts to JCL Symbols

The substitution texts that you define to JCL symbols on the PROC statement serve
as defaults. You should assign default values to all JCL symbols in a procedure.
The system uses the default values on the PROC statement when no calling EXEC
statement or SET statement overrides them.

Using Special Characters in Substitution Texts

If a substitution text contains certain special characters, enclose the substitution text
in apostrophes (for example, LOC='O''HARE'). The enclosing apostrophes are not
considered to be part of the substitution text. See Table 4-3 on page 4-3 for a list of
special characters.

If the substitution text contains multiple ampersands and is not enclosed in

apostrophes, the system treats each pair of ampersands as a single character.

If the special characters include apostrophes, code each apostrophe as two

consecutive apostrophes. You must code four consecutive apostrophes in
substitution texts that are to be substituted into a parameter that is enclosed in
apostrophes. For example:
// SET LOC=’O’’’’HARE’
//S1 EXEC PGM=IEFBR14,PARM=’&LOC’

produces the following equivalent JCL, which is processed correctly:

//S1 EXEC PGM=IEFBR14,PARM=’O’’HARE’

However, if you code the following:

Chapter 5. Procedures and Symbols 5-15

 System Symbols and JCL Symbols
// SET LOC=’O’’HARE’
//S1 EXEC PGM=IEFBR14,PARM=’&LOC’

The equivalent JCL is:

//S1 EXEC PGM=IEFBR14,PARM=’O’HARE’

The system fails this statement because the apostrophes resulting from the
substitution are unbalanced.

| When you want to code a JCL symbolic that consists of two parameters separated
| by a comma, you may have to enclose the JCL symbolic in triple apostrophes. For
| example:
| //JOB1 EXEC PROC1
| //PROC1 PROC WORK=’’’1000,500’’’
| //STEP1 EXEC PROC2,WORK=&WORK

| The substitution JCL would be:

| //STEP1 EXEC PROC2,WORK=’1000,500’

If the substitution text begins and ends with matched parentheses, do not enclose
the value in apostrophes. The parentheses are considered part of the substitution
text. For example:
//TPROC PROC DISP=(NEW,PASS)

If the substitution text within the parentheses contains apostrophes, the apostrophes
are considered part of the substitution text. The system does not remove them.

Syntax for Nullifying JCL Symbols

To nullify a JCL symbol, code:

JCL_symbol_name=
v Do not code the ampersand that identifies the JCL symbol in the procedure.
v Do not code a substitution text after the equal sign.
v Do not code literal blanks (for example, VALUE=' ').

For example, if the JCL symbol &NUMBER appears in one or more DD statements
in a procedure, code one or more of the following to nullify UNIT=&NUMBER:
//SET2 SET NUMBER=

//CALLER EXEC PROC=ABC,NUMBER=,ACCT=DID58

//ABC PROC NUMBER=,LOC=POK

When nullifying JCL symbols, keep the following in mind:

v When you nullify a JCL symbol, delimiters, such as leading or trailing commas,
are not nullified. In some cases, the remaining comma is required; in others it
causes a syntax error.
v Do not nullify JCL symbols that appear on JCL keywords that do not accept
NULL values. The syntax descriptions of the individual keywords specify whether
the keywords allow NULL values.
v If you use an EXEC statement to nullify a JCL symbol, and a PROC statement
specifies a default substitution text for the JCL symbol, the JCL symbol is
nullified.

5-16 z/OS V1R3.0 MVS JCL Reference

 System Symbols and JCL Symbols
The following sections explain special considerations to make when JCL symbols
are positional and not positional.

When a JCL Symbol is Positional

When a JCL symbol is a positional parameter, and another parameter follows it,
code a comma to omit the positional parameter. Code commas both before and
after the JCL symbol; the required commas remain after the JCL symbol is nullified.
For example, &NUMBER for the unit count:
UNIT=(3350,&NUMBER,DEFER)

When &NUMBER is nullified, the parameter correctly becomes:

UNIT=(3350,,DEFER)

When a JCL Symbol is Not Positional

When a JCL symbol is not a positional parameter, do not code a comma to omit the
parameter. Do not code a comma before the JCL symbol; no commas remain after
the JCL symbol is nullified. For example, serial numbers in the VOLUME=SER
parameter:
VOLUME=SER=(&FIRST&SECOND)

If either of the JCL symbols is nullified, a leading or trailing comma does not
remain. If you nullify &FIRST and assign 222222 for &SECOND, the parameter
correctly becomes:
VOLUME=SER=(222222)

If you nullify &SECOND and define 111111 to &FIRST, the parameter correctly
becomes:
VOLUME=SER=(111111)

Code a comma when it is required in a substitution text. Enclose the comma in

apostrophes (because it is a special character). For example:
//CALLER EXEC PROC=ABC,FIRST=111111,SECOND=’,222222’

Coding Symbols in JCL

JCL symbols and system symbols can represent parameters, subparameters, or
values in procedures or in the parameter field of statements; those that vary each
time a job runs are good candidates to be coded as symbols.

You can code JCL symbols in:

v JCL statements in the input job stream, submitted either in batch mode or from a
TSO session (but not in the job stream read in in response to a START
command)
v Statements in cataloged or in-stream procedures (which do not include started
task JCL)
v DD statements that are added to a procedure (something that is possible, but not
practical for a started task procedure).

You may code system symbols only in started task JCL (jobs and procedures),
which can be read only from a procedure library. Therefore, you can code system
symbols only in statements in cataloged procedures.

Chapter 5. Procedures and Symbols 5-17

System Symbols and JCL Symbols
For example, if the data set name on a DD statement in an INCLUDE group can
vary each time the INCLUDE group is imbedded in the JCL, you can code the
DSNAME parameter as a system symbol on the DD statement:
DSNAME=&DAY

If a job step is charged to different account numbers each time the procedure is
executed, code the ACCT parameter on the EXEC statement as one or more
system symbols or JCL symbols:
ACCT=&ALLNOS
ACCT=&FIRST&SECOND&THIRD

References
v For information about using symbols in nested procedures, see “Using
Symbols in Nested Procedures” on page 5-26.
v For information about using symbols in started task JCL, see “Using
Symbols in Started Task JCL” on page 7-8.

Rules for Coding Symbols in JCL

Follow these rules when coding symbols in JCL:

1. Do not code EXEC statement parameter and subparameter keywords as names
for JCL symbols.
Example: Do not code &REGION=200K or REGION=&REGION; correctly code
REGION=&SIZE.
2. Do not code DD or JOB statement keywords as JCL symbols in procedures or
jobs that are started by a START command from the operator console. This rule
includes the following obsolete keywords:
v AFF
v SEP
v SPLIT
v SUBALLOC

This rule also includes DCB subparameters. For example, do not use the
following DCB subparameters as symbol values:
v BFALN
v LRECL

For a complete list of DCB subparameters, see “DCB Subparameters” on

page 12-57.
3. When coding a JCL symbol that has the same name as a system symbol, keep
in mind that the substitution text for the JCL symbol overrides the substitution
text for the system symbol with the same name.
4. Do not use symbols to change the identifier field, name field, or operation field
of a JCL statement.
5. Do not specify symbols in records in an in-stream data set defined by the DD *
or DATA parameter. The system does not substitute text for symbols in SYSIN
data.

In addition to the preceding rules for coding symbols in JCL, you also need the
general rules for coding system symbols. See the section on coding system
symbols in z/OS MVS Initialization and Tuning Reference.

5-18 z/OS V1R3.0 MVS JCL Reference

 System Symbols and JCL Symbols
| Note: JCL does not support substringing of system symbols or JCL symbols.
| (Substringing allows you to specify a subset of characters in a substitution
| text.) Therefore, the section on substringing symbols in the general rules for
| coding symbols in z/OS MVS Initialization and Tuning Reference is not
| entirely applicable.

| However, one topic of that section in z/OS MVS Initialization and Tuning
| Reference discusses ″double ampersand notation,″ a technique that could
| be useful in coding your JCL.

| For instance, suppose you want to enter a substringed symbol as a

| parameter of an EXEC statement of a started task. By using a double
| ampersand you can force MVS to defer processing the statement until after
| the JCL is executed and the program is running. For example, given a value
| of ’05’ for SYSCLONE, the statement could read:
| //Step1 EXEC PGM=MVSCMD,PARM=’F RMF,S III,MEMBER(3&&SYSCLONE(2:1))’

| The MVS converter will change that to:

| //Step1 EXEC PGM=MVSCMD,PARM=’F RMF,S III,MEMBER(3&SYSCLONE(2:1))’

| which is the JCL that gets executed. Your MVSCMD program would then
| take what is in the PARM on its EXEC statement and issue it as an MVS
| command:
| F RMF,S III,MEMBER(3&SYSCLONE(2:1))

| which the command symbolic substitution routine then processes and

| changes to:
| F RMF,S III,MEMBER(35)

| Determining Equivalent JCL

When you submit JCL that specifies symbols, the system responds as if you had
coded the equivalent JCL (without symbols) produced by the following sequence of
operations:
1. Determine the substitution texts. The system:
v Does not consider apostrophes that enclose symbols as part of their
substitution texts.
v Considers parentheses that enclose symbols as part of their substitution
texts.
v Compresses two-to-one the double apostrophes within symbols.
v Compresses two-to-one the double ampersands in symbols that are not
enclosed in apostrophes.
v Does not compress double ampersands within symbols that are enclosed in
apostrophes.
2. Substitute all symbols.
v Resolution of all symbols might determine the processing of subsequent
statements. For example, a JCLLIB or INCLUDE statement might contain
symbols that determine which statements are used in the job.
v Symbols on JCL records are treated as if they were resolved simultaneously.

The following example shows a procedure that defines JCL symbols:

//EXAMPLE PROC SYM1=’What’’’’s up, Doc?’,SYM2=(DEF),SYM3=&&&&TEMP1,
// SYM4=’&&TEMP2’,SYM5=&&TEMP3,TEMP3=TEMPNAME,
// SYM6=&TEMP3

Chapter 5. Procedures and Symbols 5-19

System Symbols and JCL Symbols
//S1 EXEC PGM=WTO,PARM=’&SYM1’,ACCT=&SYM2
//DD1 DD DSN=&SYM3,UNIT=SYSDA,SPACE=(TRK,(1,1))
//DD2 DD DSN=&SYM4,UNIT=SYSDA,SPACE=(TRK,(1,1))
//DD3 DD DSN=&SYM5,UNIT=SYSDA,SPACE=(TRK,(1,1))
//DD4 DD DSN=&SYM6,UNIT=SYSDA,SPACE=(TRK,(1,1))
// PEND

The PROC statement assigns the following substitution texts to the JCL symbols:
SYM1 What’’s up, Doc?
SYM2 (DEF)
SYM3 &&TEMP1
SYM4 &&TEMP2
SYM5 &TEMP3
TEMP3 TEMPNAME
SYM6 &TEMP3

The equivalent JCL produced by the substitution, when the procedure is expanded,
is:
//S1 EXEC PGM=WTO,PARM=’What’s up, Doc?’,ACCT=(DEF)
//DD1 DD DSN=&&TEMP1,UNIT=SYSDA,SPACE=(TRK,(1,1))
//DD2 DD DSN=&&TEMP2,UNIT=SYSDA,SPACE=(TRK,(1,1))
//DD3 DD DSN=&TEMP3,UNIT=SYSDA,SPACE=(TRK,(1,1))
//DD4 DD DSN=&TEMP3,UNIT=SYSDA,SPACE=(TRK,(1,1))

Note the following in the example:

v SYM1 requires four apostrophes in its original definition because it is substituted
into a parameter enclosed in apostrophes. The system compresses the
apostrophes in the symbol definition when the value of the symbol is determined,
and again when the EXEC PARM parameter is processed. The parameter passed to
the WTO program is:
What’s up, Doc?
v The single ampersand produced by SYM5 in the DSN parameter of DD3 cannot be
interpreted as the start of a new JCL symbol, since substitution is performed only
once for a given statement. All symbols are treated as if they were resolved
simultaneously. If the symbol TEMP3 defined on the PROC statement is not used
elsewhere in the procedure, a JCL error results.
v The symbol TEMP3 cannot be used to assign a value for the symbol SYM6 on
the same statement. Because all symbolic parameters are resolved
simultaneously, the value assigned to SYM6 cannot depend on another symbol
defined at the same time. The system assigns the value &TEMP3, not
&&TEMP2, to SYM6. Again, if the symbol TEMP3 is not used elsewhere in the
procedure, a JCL error will result.

Continuing JCL Statements that Contain Symbols

The system evaluates continuations of JCL statements that contain symbols as
follows:
1. The system substitutes all symbols on an 80-character record.
2. The system determines if the record continues to another record. If symbolic
substitution produces a null record (a card image that is blank except for
slashes in columns 1 and 2) as the continuation record, the substitution is not
valid.

For example, consider the following JCL:

//SET1 SET VAL1=’ABC,’,VAL2=DEF,NULLSYM=’
//S1 EXEC PGM=IEFBR14,PARM=&VAL1
// TIME=30

5-20 z/OS V1R3.0 MVS JCL Reference

 System Symbols and JCL Symbols
//S2 EXEC PGM=IEFBR14,PARM=&VAL2
// TIME=30
//S3 EXEC PGM=IEFBR14,PARM=&VAL1
// &NULLSYM

The JCL records that define step S1 form a valid continuation; the JCL symbol
VAL1 introduces a comma, and the continuation is correctly coded.

Steps S2 and S3 are not valid. In step S2, the first record does not end in a comma
after substitution of VAL2. In step S3, the record containing NULLSYM evaluates to a
null record after symbolic substitution.

| It may be that the number and length of symbols form a parameter that does not fit
| within the limits imposed by an 80-character record. (In reality the limit is 68
| characters, because columns 1, 2, and 3 must contain respectively a slash, slash,
| and blank, and column 72 must be blank.) Two techniques for handling this
| situation are: (1) defining shorter symbols to substitute for the longer ones, or (2)
| dividing the series of symbols so as to form two parameters, which would allow you
| to place a comma after the first and move the second to a continuation record.

Coding Symbols in Comments

The system does not process symbols in comment statements or in comment fields
of JCL statements. Comments on JCL statements that contain symbols are
evaluated as follows:
v In the original submitted JCL, the system recognizes the beginning of the
comment field when it encounters the blank character at the end of the
parameter field. For purposes of symbolic substitution, the system disregards text
occurring after this blank.
v After performing symbolic substitution, the system re-evaluates the resulting
equivalent JCL to determine where the parameter field ends. The system
recognizes the beginning of the comment field in the substituted JCL when it
encounters the blank character at the end of the (potentially modified) parameter
field. The system disregards text occurring after this blank in subsequent
processing.

Example:
// SET QUOTE=’’’’
//S1 EXEC PGM=IEFBR14,PARM=&QUOTE.ABC DEF&QUOTE
//DD1 DD DUMMY

The equivalent JCL produced by substitution is

//S1 EXEC PGM=IEFBR14,PARM=’ABC DEF&QUOTE
//DD1 DD DUMMY

DEF&QUOTE is considered a comment because it follows the blank that ends the
parameter field, so the second instance of &QUOTE will not be replaced during
symbolic substitution. Because the first &QUOTE symbol resolves to a single
quotation mark, the system expects to either find another single quotation at the
end of a subparameter list, or find a continuation to the next line. The EXEC
statement receives an error message indicating that the system did not receive an
expected continuation.

Example:
// SET CONT=’ ’,T=’(30,0)’
//S1 EXEC PGM=IEFBR14&CONTPARM=’ABC DEF’,TIME=&T

Chapter 5. Procedures and Symbols 5-21

System Symbols and JCL Symbols
The equivalent JCL is:
//S1 EXEC PGM=IEFBR14 PARM=’ABC DEF’,TIME=(30,0)

The text (30,0) is substituted for the symbol &T. However, because substitution
introduced a blank character after the program name parameter, all text following
the blank is considered to be a comment. Thus the system does not process the
PARM and TIME parameters.

Coding Symbols in Apostrophes

You can code symbols in apostrophes on the following keywords:
v The DD statement AMP parameter
v The DD statement PATH parameter
v The DD statement SUBSYS parameter
v The EXEC statement ACCT parameter
v The EXEC statement PARM parameter.

When you specify these parameters, the system regards a string beginning with an
ampersand (&) inside the apostrophes as a symbol when the following conditions
are true:
v The character following the ampersand is not another ampersand.
v The characters following the ampersand are ended by a character that is not
alphabetic, numeric, or national. The ending character must be not more than 9
characters after the ampersand. The symbol cannot be more than 8 characters
long.
v The string of characters delimited by the ampersand and the ending character is:
– Defined as a symbol on a PROC, EXEC, or SET statement
– A system symbol.

The system treats a string beginning with an ampersand but not meeting these
criteria as a literal sequence of characters. Thus the system does not substitute text
for symbols and does not issue error messages.

In the following example, &XXX is a JCL symbol that is defined in the STEP2 EXEC
statement. &INPUT is not a symbol because it is not defined.
//TPROC PROC
//STEP1 EXEC PGM=IEFBR14,PARM=’&INPUT&XXX’
// PEND
//STEP2 EXEC TPROC,XXX=VALUE

The ending character for &XXX is the apostrophe.

The result of the example is:

//EXEC PGM=IEFBR14,PARM=’&INPUTVALUE’

On parameters that are not in the list, the system correctly resolves a symbol that is
enclosed in apostrophes when the symbol is immediately preceded by a symbol
that is not enclosed in apostrophes. For example, both A and B are substituted
correctly in:
//DD1 DD &A’&B’,DISP=OLD

A symbol within apostrophes cannot be broken at column 71 and continued to the

next line. For example, the following JCL statement is incorrect:
// SET SYMBOL=VALUE
//S1 EXEC PGM=IEFBR14,TIME=(30,0),REGION=4K,PARM=’Print &SYMB
// OL’

5-22 z/OS V1R3.0 MVS JCL Reference

 System Symbols and JCL Symbols
The JCL symbol SYMBOL is not substituted because it must be coded on a single
JCL record. A JCL error may result.

Using Symbols Before Fixed Code

A period is required after a symbol when the code that follows the symbol is fixed
and begins with:
v An alphanumeric or national character ($, #, @)
v A period.

The system recognizes the period as a delimiter. The period does not appear after
you assign a substitution text to a symbol or nullify a symbol.

For example, if the first part of a data set name varies and the last does not, as in
MONDATA, TUESDATA, and so forth, code:
DSNAME=&DAY.DATA

Code two consecutive periods (..) if a period follows a symbol. For example, code
&DEPT..POK when the desired value is D58.POK and DEPT=D58 is the value
assignment.

Using Symbols as Positional Parameters

When a symbol is a positional parameter followed by other parameters in the
statement, follow the symbol with a period instead of a comma. For example:
//DS1 DD &POSPARMDSNAME=ATLAS,DISP=OLD

If &POSPARM is nullified, the statement appears as:

//DS1 DD DSNAME=ATLAS,DISP=OLD

When assigning a substitution text to &POSPARM, include the comma:

POSPARM=’DUMMY,’

If &POSPARM is not nullified, the statement appears as:

//DS1 DD DUMMY.DSNAME=ATLAS,DISP=OLD

Using Two or More Symbols in Succession

Code two or more symbols in succession without including a comma. For example:
PARM=&DECK&CODE

If the substitution text is to contain a comma, include the comma in the substitution
text.

Using Multiple Symbols

The same symbol can appear more than once in a job. You can assign different
substitution texts to the same symbol on different statements.

The same symbol can appear more than once in a procedure, as long as its
substitution text is the same throughout the procedure. For example, &DEPT can
appear several times in a procedure, if the department number is always to be the
same.

Using the SYSUID System Symbol

As long as you observe the rules listed in the earlier topic ″Rules for Coding
Symbols in JCL,″ you may code the SYSUID system symbol anywhere in your JCL
where you would code a user ID except on the keywords and statements listed in

Chapter 5. Procedures and Symbols 5-23

System Symbols and JCL Symbols
the topic “Restrictions on Coding SYSUID”. The system replaces &SYSUID with the
user ID under whose authority the job will run, which is normally one of the
following:
v The USER parameter from the JOB statement, if specified, or
v The user ID from which the job was submitted.

Note: If userid propagation does not occur, (for example a security product is not
active or the submitting userid is not allowed to propagate), SYSUID will be
null. A security product is considered ″not active″ in OS/390 if it has been
disabled. If RACF is running in a fail soft mode, the security product is
considered ″active.″

Note: If RACF is active and the job is running with a user ID not defined to RACF,
the system provides substitute characters for &SYSUID and may fail the job
because of this JCL error. The same results may occur if &SYSUID is not
resolved to a valid user when RACF is not active.

You can, for example, use &SYSUID as a generic qualifier in a data set name
specified in a transaction program profile that will be invoked by a transaction
program. Code SYSUID on the DSNAME parameter as the high-level qualifier of
the data set name:
//DD1 DD DSNAME=&SYSUID..PROFILE,DISP=(NEW,KEEP)

The system replaces the symbol with the userid of the transaction program invoker.
If userid ROGERS invokes the transaction program, the system will create the data
set name ROGERS.PROFILE.

Restrictions on Coding SYSUID

Do not code &SYSUID on the following keywords and statements:
v Job statement USER, GROUP, PASSWORD, and SECLABEL parameters when
a security product like RACF is active.
v The XMIT JCL statement; coding &SYSUID on XMIT causes a JCL error and the
job is flushed.
v JES2 or JES3 control statements.
v Job statement accounting information and programmer name fields.

In an APPC scheduling environment:

v Avoid coding &SYSUID on the DD statement SUBSYS parameter; symbol
substitution is unpredictable on SUBSYS.
v Avoid coding &SYSUID on the JOB statement NOTIFY parameter; if the user ID
specified through the Allocate service is longer than 7 characters, the Allocate
request will fail.

Avoid using &SYSUID as an unqualified data set name. Depending on the other
statements in the transaction program profile, the system might interpret the data
set name as a temporary data set name.

Examples of Defining and Coding Symbols in JCL

Example 1
//JOBA JOB ...
//INSTREAM PROC LOC=POK
//PSTEP EXEC PGM=WRITER

5-24 z/OS V1R3.0 MVS JCL Reference

 System Symbols and JCL Symbols
//DSA DD SYSOUT=A,DEST=&LOC
// PEND
//CALLER EXEC PROC=INSTREAM,LOC=NYC
//

In this example of an in-stream procedure, the &LOC symbol has a default value of
POK on the PROC statement; then it is assigned an execution value of NYC on the
calling EXEC statement.

Example 2
//JOBB JOB ...
//INSTREAM PROC LOC=POK,NUMBER=3350
//PSTEP EXEC ...
//PIN DD DSNAME=REPORT,DISP=(OLD,KEEP),UNIT=&NUMBER
//POUT DD SYSOUT=A,DEST=&LOC
// PEND
//CALLER EXEC PROC=INSTREAM,NUMBER=,LOC=STL
//PSTEP.INDATA DD *
.
(data)
.
/*

This code nullifies the &NUMBER JCL symbol. The calling EXEC statement
assignment of STL for the &LOC symbol overrides the PROC statement assignment
of POK.

Example 3

This example illustrates execution of an in-stream procedure to test symbols before

placing the procedure in a procedure library. The in-stream procedure named
TESTPROC is:
//TESTPROC PROC A=IMB406,B=ABLE,C=3330,D=WXYZ1,
// E=OLD,F=TRK,G=’10,10,1’
//STEP EXEC PGM=&A
//DD1 DD DSNAME=&B,UNIT=&C,VOLUME=SER=&D,DISP=&E,
// SPACE=(&F,(&G))
// PEND

To execute this in-stream procedure and override &A with IEFBR14, &B with
BAKER, and &E with (NEW, KEEP) but leave the other parameters the same, call
the in-stream procedure with:
//CALLER1 EXEC PROC=TESTPROC,A=IEFBR14,B=BAKER,E=(NEW,KEEP)

Note that the value (NEW,KEEP) does not require apostrophes because it contains
a matched pair of parentheses. See Table 4-4 on page 4-4 for more information.

After symbolic substitution, the statements are:

//STEP EXEC PGM=IEFBR14
//DD1 DD DSNAME=BAKER,UNIT=3330,VOLUME=SER=WXYZ1,
// DISP=(NEW,KEEP),SPACE=(TRK,(10,10,1))

Example 4

To execute the in-stream procedure in the previous example and change DD1 to
resemble a temporary scratch space, code the following statement:
//CALLER2 EXEC PROC=TESTPROC,A=IEFBR14,B=,C=3350,D=,E=

After symbolic substitution, the statements are:

Chapter 5. Procedures and Symbols 5-25

System Symbols and JCL Symbols
//STEP EXEC PGM=IEFBR14
//DD1 DD DSNAME=,UNIT=3350,VOLUME=SER=,DISP=,SPACE=(TRK,(10,10,1))

Using Symbols in Nested Procedures

The general rules described in “Using System Symbols and JCL Symbols” on
page 5-12 also apply to symbols in nested procedures, along with the following
rules:
1. Within a nested procedure, assign only one substitution text per symbol. You
can use the same symbol in other nested procedures and assign it different
values.
2. If you assign or nullify the value for a symbol on an EXEC statement that calls a
nested procedure, the substitution text that you specify on the EXEC statement
is used in the procedure. The EXEC statement overrides any default value you
specify on the PROC statement of the nested procedure.
3. When the EXEC statement that calls the nested procedure does not assign a
substitution text to the symbol, the system uses the default substitution text
specified on a PROC statement.
One way to provide an override value for a symbolic in a nested procedure is to
design the procedure so that it requires no assignment of default symbolic
parameter values. If the PROC statement of the inner procedure contains no
default value, the system uses the value specified on the EXEC statement of
the outer procedure. For example:
//TESTJCL PROC
//STEP1 EXEC TESTJCL1
// PEND
//TESTJCL1 PROC
//STEP2 EXEC PGM=IEFBR14,PARM=&PVAL
//SYSUDUMP DD SYSOUT=A
// PEND
//RUNIT EXEC TESTJCL,PVAL=EXEC0
4. If you assign or nullify a substitution text for a symbol on a SET statement, the
substitution text that you specify on the SET statement is used in all subsequent
statements, procedures, and nested procedures. However, if the calling EXEC
statement or the PROC statement of the procedure assigns or nullifies the
symbol, it only applies to subsequent statements within that PROC and
subsequent nested procedures within that procedure.
5. If you do not assign or nullify a value for a JCL symbol in a nested procedure,
the value used for the JCL symbol in this procedure is obtained from the
procedure in which this procedure is nested.
6. If a JCL symbol is not assigned a substitution text or is not nullified, it is an
undefined JCL symbol which might cause errors in the JCL.

Table 5-1 shows rules 2 through 6 in a summary table, which is the order in which
the value for a symbol is resolved.
Table 5-1. Summary of Rules 2 through 6 for Symbols in Nested Procedures
Where the Symbol is Defined
EXEC PROC SET Nested Value None
Not EXEC Not PROC Not SET
Not EXEC Not PROC
Not EXEC
Value Used (Rule 2) (Rule 3) (Rule 4) (Rule 5) (Rule 6)
EXEC Value X
PROC Value X

5-26 z/OS V1R3.0 MVS JCL Reference

 System Symbols and JCL Symbols
Table 5-1. Summary of Rules 2 through 6 for Symbols in Nested Procedures (continued)
Where the Symbol is Defined
EXEC PROC SET Nested Value None
Not EXEC Not PROC Not SET
Not EXEC Not PROC
Not EXEC
Value Used (Rule 2) (Rule 3) (Rule 4) (Rule 5) (Rule 6)
SET Value X
Nested Value X
Undefined X

Examples of Coding Symbols in Nested Procedures

Example 2

The following example defines symbols A, B, and C with multiple assignments in

nested procedures:
Current value of symbol:
//MYJOB JOB ... Level 0:
//SET1 SET A=123,B=456 A=123,B=456,C=undefined
.
//PROC1 PROC A=234,C=GHI
//PSTEP1 EXEC PROC=PROC2,A=ABC,B=DEF
//PSTEP2 EXEC PGM=IEFBR14
// PEND
.
//PROC2 PROC
//P2STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=A
//SYSUT1 DD DSN=&A..&B,DISP=SHR
//SYSUT2 DD SYSOUT=A,DCB=LRECL=&C
// PEND
.
//STEP1 EXEC PROC=PROC1,A=,C=789 Level 1:
. A=,B=456,C=789
++PROC1 PROC A=234,C=GHI
++PSTEP1 EXEC PROC=PROC2,A=ABC,B=DEF Level 2:
. A=ABC,B=DEF,C=789
++PROC2 PROC
++P2STEP1 EXEC PGM=IEBGENER
++SYSPRINT DD SYSOUT=A
++SYSUT1 DD DSN=ABC.DEF,DISP=SHR
++SYSUT2 DD SYSOUT=A,DCB=LRECL=789
++ PEND
.
++PSTEP2 EXEC PGM=IEFBR14 Level 1:
. A=,B=456,C=789
++ PEND
//BARNEY EXEC PGM=IEFBR14 Level 0:
//... . A=123,B=456,C=undefined

The processing of symbols in MYJOB is:

v When the SET statement SET1 is processed, symbols A and B are defined and
initialized to the values 123 and 456, respectively. (The C symbol C is not yet
defined.) The level of nesting (scoping) is 0.
v EXEC statement STEP1 references in-stream procedure PROC1. The symbols
are changed as follows: A is nullified, B remains 456 from SET statement SET1,
and C is defined and assigned the substitution text 789. The level of nesting
(scoping) is now 1.

Chapter 5. Procedures and Symbols 5-27

 System Symbols and JCL Symbols
PROC statement PROC1 defines the default values for the symbols A and C as
A=234 and C=GHI. However, these values are overridden by the values on the
EXEC statement STEP1 as: A=, and C=789.B remains 456 from SET statement
SET1. The level of nesting is still 1.
v EXEC statement PSTEP1 is processed. The substitution texts for the symbols
are updated again as: A=ABC and B=DEF. (C remains 789 from EXEC statement
STEP1.) The substitution texts are passed to procedure PROC2 referenced by
EXEC statement PSTEP1. The level of nesting is now 2.
v The statements in procedure PROC2 are processed. The values used to resolve
the symbols on DD statements SYSUT1 and SYSUT2 are those from level 2,
namely A=ABC, B=DEF, C=789. The level of nesting returns to level 1.
v EXEC statement PSTEP2 in PROC1 is processed. This statement does not
change the values of the symbols. However, because the expansion of PROC2 is
complete, the values of the symbols return to the level 1 values held prior to
procedure PROC2, which are A=, B=456, and C=789. The level of nesting
returns to level 0.
v EXEC statement BARNEY is at level 0 and the substitution texts for symbols are
restored to their original values: A=123,B=456, and C=undefined. The substitution
texts, defined by SET statement SET1, are retained throughout this level of
nesting (level 0).

| Example 2

| To illustrate the scope of symbolics in the case of nested procedures, consider the
| following example, where PROC1 calls PROC2:
| //JOB2 JOB ...
| //J1 EXEC PROC1,WORK=’’’500,250’’’,LABEL=UNUSED
| //J2 EXEC PROC1
| //PROC1 PROC WORK=’’’1000,500’’’
| //S1 EXEC PROC2,WORK=&WORK
| //S2 EXEC PROC2,WORK=&WORK
| //PROC2 PROC WORK=’’’500,250’’’,LABEL=DUMMY
| //P1 EXEC PGM=IEFBR14
| //DD1 DD UNIT=SYSDA,SPACE=(TRK,(&WORK)),DSN=&LABEL

| In the above example, the symbolic LABEL is defined as UNUSED in EXEC

| statement J1, which calls PROC1. The symbolic LABEL is not used in PROC1 but
| is used in PROC2, which is called by PROC1 and therefore is in the scope of the
| original definition of the symbolic.

5-28 z/OS V1R3.0 MVS JCL Reference

Chapter 6. Job Control Statements on the Output Listing
Use the JOB statement MSGLEVEL parameter to request that job control
statements be printed in the job log output listing. Code MSGLEVEL=(1,1) to
receive the maximum amount of information, in the following order:
v JES messages and job statistics.
v All job control statements in the input stream and procedures.
v Messages about job control statements.
v JES and operator messages about the job’s processing: allocation of devices and
volumes, execution and termination of job steps and the job, and disposition of
data sets.

Statements in Listing

To identify the source and type of each statement, the system prints certain
characters in columns 1 and 2 or 1, 2, and 3 of the listing. These identifying
characters are explained in Table 6-1. The listing shows all procedure statements as
they appear in the cataloged procedure; the listing does not show parameter
substitutions and overrides on the statement itself.

Symbolic Parameters

The job log listing shows the symbolic parameters in procedure statements. The
values assigned to the parameters are given in IEF653I messages. These
messages appear immediately after each statement that contains symbolic
parameters.

EXEC Overriding Parameters

A procedure EXEC statement appears in the job log listing exactly as it appears in
the procedure. Overridden parameters must be shown by the program being
executed:
v For the EXEC statement that executes the assembler program, the Diagnostic
Cross Reference and Assembler Summary produced by the assembler
program shows the overriding parameters.
v For the EXEC statement that executes the linkage editor, the linkage editor listing
shows the overriding parameters.
Table 6-1. Identification of Statements in Job Log
Columns 1, 2, Source and Type of Statement
and 3
Job Control Statements in the Input Stream
// JCL statement
//* Job control statement that is not a JCL comment statement but one that
the system considers to contain only comments
//* JES2 statement
//* JES3 statement
/* Certain JES3 control statements
//* JCL comment statement
Cataloged Procedure Statements

© Copyright IBM Corp. 1988, 2002 6-1

Job Log
Table 6-1. Identification of Statements in Job Log (continued)
Columns 1, 2, Source and Type of Statement
and 3
XX DD statement that was not overridden and all other JCL statements, except
the JCL comment statement. Each statement appears in the listing exactly
as it appears in the procedure.
X/ DD statement that was overridden (preceded by the overriding DD
statement)
XX* Job control statement that is not a JCL comment statement but one that
the system considers to contain only comments
XX* JCL comment statement
In-Stream Procedure Statements
++ DD statement that was not overridden and all other JCL statements, except
the JCL comment statement. Each statement appears in the listing exactly
as it appears in the procedure.
+/ DD statement that was overridden (preceded by the overriding DD
statement)
++* Job control statement that is not a JCL comment statement but one that
the system considers to contain only comments
++* JCL comment statement

6-2 z/OS V1R3.0 MVS JCL Reference

Chapter 7. Started Tasks
This chapter describes the decisions your system programmer needs to make in
order for your installation to use started tasks, and the steps a person with operator
authority (the ″you″ in this chapter) will need to perform if the decision is to use
started tasks.

Determining Whether to Use a Started Task

When you determine where and when you want a set of JCL to run, you will
consider using batch jobs or started tasks. Batch jobs are scheduled by a job entry
subsystem (JES) and are scheduled to run based on the resources they require
and their availability, or based on controls you put on the batch system. Controlling
where and when a batch job runs is more complex than using a started task.

A started task is a set of JCL that is run immediately as the result of a START
command. Started tasks are generally used for critical applications. The advantages
to using started tasks are:
v You can control where and when your set of JCL is run. For example, you can
have the set of JCL started at each IPL of the system.
v You can specify both static system symbols and JCL symbols in the JCL. Static
system symbols and JCL symbols provide additional control over JCL that is
used on different systems. For example:
– When access to production data sets is controlled to protect critical business
data, you can specify symbols that represent test data sets. After testing the
data sets, you can change the values of the symbols to represent production
data sets without changing the source JCL.
– When you need to swap in an older level of a subsystem while diagnosing
problems with a newer level, you can change the values of symbols to
represent the older subsystem without changing the source JCL.

For more information about system symbols and JCL symbols, see “Using Symbols
in Started Task JCL” on page 7-8.

Note: In the past, some users set up batch jobs that controlled their programs.
Users allocated a PDS, added JOB JCL to a member of the PDS, and then
read the PDS member into an internal reader; these actions initiated a batch
job for the started task. While this method afforded some advantages, it did
not allow for symbolic support.

Determining the Source JCL for the Started Task

If you decide to use a started task, you must then determine what the source JCL
will be and where the JCL will be located. The source JCL can be a JOB (located in
a member of a data set defined in the IEFJOBS or IEFPDSI concatenation of
master JCL) or a procedure (located in a subsystem procedure library, for example,
SYS1.PROCLIB). In the latter case, the system will process only the JCL
associated with the first JOB statement in the procedure; it will bypass the second
and subsequent jobs.

Note: In the past, the source JCL for started tasks was always a procedure.

© Copyright IBM Corp. 1988, 2002 7-1

Started Tasks
For information about master JCL considerations to support started tasks, see z/OS
MVS Initialization and Tuning Reference.

Before determining whether you will use a job or a procedure as source JCL for a
given started task, you need to understand the advantages of each. After you have
identified whether the source JCL will be a job or a procedure, then determine the
system services that the started task will require. (See “Determining System
Services for a Started Task” on page 7-5.)

In most cases, you will use a procedure unless you need greater control of your
started task. For example, EREP formats the logrec data set information; you may
not need to change the way this currently works. The best candidates for
procedures are started tasks that require minimal maintenance.

The major advantage of using a job as the source JCL for a started task is the
control provided over certain aspects of the started task, such as:
v Ability to specify accounting data
For example, to determine which resources are being used by individual users.
v Ability to pass parameters to the started task
For example, using SYSIN data, you can pass data to programs in the started
task.
v Control of output
For example, many installations purge all output from started tasks because of
the volume of output. With the output control allowed within a job, you can
specify to receive output only if something abnormal occurs with the started task.

Started tasks are initiated by the START command which identifies the member that
contains the source JCL for the task. (See z/OS MVS System Commands for
information on the START command.) The following two sections describe how the
system processes the START command (depending on whether the source JCL is a
job or a procedure) and the JCL that results.

Note the following restriction: If you are running a started task you cannot override
the PARM= parameter on the START command. However, you can circumvent this
restriction as follows:
v Make the PARM= a symbolic in the EXEC statement where it is pertinent.
Example:
//JOB1 JOB parameters
//STEP1 EXEC PGM=programname,PARM=&PARM1
v Then, on the START command, change the value of the symbolic. Example:
START JOB1,,PARM1=parameters

START Command Processing when the Member is a Procedure

During START command processing, if the member specified does not start with a
JOB statement, the system creates a JOB statement and EXEC statement that will
invoke the procedure of the same name as the member.

For example, the member INIT exists in SYS1.PROCLIB as follows:

//IEFPROC EXEC PGM=IEFIIC

JES2 automatically issues the command S INIT.INIT,,,JES2,SUB=JES2 and the

following JCL is created:

7-2 z/OS V1R3.0 MVS JCL Reference

 Started Tasks
//INIT JOB MSGLEVEL=1
//INIT EXEC INIT

START Command Processing when the Member is a Job

If a JOB statement is the first statement in the member, the system uses the JCL
provided in the member. For example, given the following JOB statement and JCL
in the INIT member:
//INIT JOB ’accounting_info’,MSGLEVEL=1
//JESDS OUTPUT JESDS=ALL,OUTDISP=(PURGE,WRITE)
//INIT EXEC INIT
//DD1 DD DSN=SYSTEM.ACCOUNT.DATA,DISP=SHR
//*

JES2 automatically issues the command S INIT.INIT,,,JES2,SUB=JES2 and the

preceding JCL is invoked, starting the MVS initiator by calling the INIT procedure.
The S INIT.INIT,,,JES2,SUB=JES2 command now uses the source JCL and invokes
the same procedure.

Review Current Started Tasks

Some of your existing started tasks may offer you greater benefits if the source JCL
were a job. Review existing started tasks and identify the ones that should be a job
by comparing their needs with the support provided (for example, output or
accounting).

When you have identified that the source JCL will be a job, determine which
method you will use to convert existing procedures, and determine whether the
system services that the started task will require have changed. (See “Determining
System Services for a Started Task” on page 7-5.)

Convert Procedures to Jobs (Optional)

You may decide to convert some of your existing started task procedures to jobs.
Before doing so, you should understand how the started task JCL and processing
will change.

If the following command is issued for a started task procedure:

S DUMPCHK,SG=ALL,JDATE=93119,DAY=THURSDAY

and the procedure being started is:

//DUMPCHK PROC SG=ALL,JDATE=,DAY=
//DUMPCHK EXEC PGM=DMPCHKO,REGION=5M,PARM=’/&SG,&JDATE,&DAY’
//STEPLIB DD DSN=JCR.PGM.LOAD,DISP=SHR
//CDS DD DSN=DATAMGT.CDS,DISP=SHR
// DD DSN=DATAMGT.CDS.CLEAR,DISP=SHR
// DD DSN=DATAMGT.CDS.Y43DUMPS,DISP=SHR
//LOG DD DSN=SYS1.TSODUMP.LOG,DISP=SHR
//SYSPRINT DD SYSOUT=*

MVS creates the following JCL to invoke this procedure:

//DUMPCHK JOB MSGLEVEL=1
//STARTING EXEC DUMPCHK,SG=ALL,JDATE=93119,DAY=THURSDAY

To convert an existing procedure to a job, remove the PROC and PEND statements
and add a JOB statement and any other JCL you plan to use.

To invoke as existing procedure, you can choose one of the following alternatives.

Chapter 7. Started Tasks 7-3

Started Tasks
v “Alternative 1 - Add the Member and JCL to the IEFJOBS-Defined Data Set”
v “Alternative 2 - Add the Job JCL to the Existing Procedure”
v “Alternative 3 - Add the Member and Invoke a Procedure in Another DD
Concatenation” on page 7-5

Note: It is important to note that if system symbols are used on the PROC
statement, they cannot be overridden by the START command system
symbols.

Alternative 1 - Add the Member and JCL to the IEFJOBS-Defined

Data Set
If you plan to define an IEFJOBS concatenation in MSTJCLxx with a data set of
SYS1.STCJOBS, create a DUMPCHK member in SYS1.STCJOBS. Place the job in
this member and add an EXEC statement that will run the existing procedure. For
example:
//DUMPCHK JOB ’accounting_info’,MSGLEVEL=(1,1)
// EXEC DUMPCHK

When the START command is issued, MVS inserts a JCL SET statement after the
JOB statement, resulting in the following JCL:
//DUMPCHK JOB ’accounting_info’,MSGLEVEL=(1,1)
// SET SG=ALL,JDATE=93119,DAY=THURSDAY
// EXEC DUMPCHK

Alternative 2 - Add the Job JCL to the Existing Procedure

If you do not plan to define an IEFJOBS concatenation in MSTJCLxx and the
procedure DUMPCHK is already defined in SYS1.PROCLIB or one of the other
data sets in the IEFPDSI concatenation of MSTJCLxx, use a JOB statement in the
DUMPCHK member that formerly contained only the procedure, along with an
EXEC statement that will run the existing procedure, and convert the existing
procedure to an in-stream procedure by adding PROC and PEND statements, if
they are not already present. For example:
//DUMPCHK JOB ’accounting_info’,MSGLEVEL=(1,1)
//DUMPCHK PROC
//DUMPCHK EXEC PGM=DMPCHKO,REGION=5M,PARM=’/&SG,&JDATE,&DAY’
//STEPLIB DD DSN=JCR.PGM.LOAD,DISP=SHR
//CDS DD DSN=DATAMGT.CDS,DISP=SHR
// DD DSN=DATAMGT.CDS.CLEAR,DISP=SHR
// DD DSN=DATAMGT.CDS.Y43DUMPS,DISP=SHR
//LOG DD DSN=SYS1.TSODUMP.LOG,DISP=SHR
//SYSPRINT DD SYSOUT=*
// PEND
// EXEC DUMPCHK

When the START command is issued, MVS inserts a JCL SET statement after the
JOB statement, resulting in the following JCL:
//DUMPCHK JOB ’accounting_info’,MSGLEVEL=(1,1)
// SET SG=ALL,JDATE=93119,DAY=THURSDAY
//DUMPCHK PROC
//DUMPCHK EXEC PGM=DMPCHKO,REGION=5M,PARM=’/&SG,&JDATE,&DAY’
//STEPLIB DD DSN=JCR.PGM.LOAD,DISP=SHR
//CDS DD DSN=DATAMGT.CDS,DISP=SHR
// DD DSN=DATAMGT.CDS.CLEAR,DISP=SHR
// DD DSN=DATAMGT.CDS.Y43DUMPS,DISP=SHR
//LOG DD DSN=SYS1.TSODUMP.LOG,DISP=SHR
//SYSPRINT DD SYSOUT=*
// PEND
// EXEC DUMPCHK

7-4 z/OS V1R3.0 MVS JCL Reference

 Started Tasks
Alternative 3 - Add the Member and Invoke a Procedure in
Another DD Concatenation
If you do not plan to define an IEFJOBS concatenation in MSTJCLxx and the
procedure DUMPCHK is not in any of the data sets in the IEFPDSI concatenation
of MSTJCLxx, create a member to contain the job and add that member to one of
the data sets in the IEFPDSI concatenation and place the EXEC statement that will
run the existing procedure (contained in the JES PROCLIB) in the JCL. The existing
procedure will be invoked just as it was in the past. For example:
//DUMPCHK JOB ’accounting_info’,MSGLEVEL=(1,1)
// EXEC DUMPCHK

When the START command is issued, MVS inserts a JCL SET statement after the
JOB statement, resulting in the following JCL:
//DUMPCHK JOB ’accounting_info’,MSGLEVEL=(1,1)
// SET SG=ALL,JDATE=93119,DAY=THURSDAY
// EXEC DUMPCHK

Determining System Services for a Started Task

Before you begin to code the JCL for a started task, you should determine under
which subsystem the JCL will run, and the changes the master JCL will require.

Deciding Under Which Subsystem a Started Task Should Run

To decide under which subsystem your started task should run, determine what
services the task requires and what support the primary (job entry) subsystem, the
master subsystem, and other subsystems provide.

Inform the system programmer responsible for the master JCL of your decision.
Then code the name of the subsystem on the START command’s SUB= keyword.

Without a SUB= keyword on the START command, the operating system will create
the started task under the primary job entry subsystem (JES2 or JES3) unless the
task itself is a subsystem, that is, it is either defined
v in the member IEFSSNxx of SYS1.PARMLIB, or
v dynamically by the SETSSI command or IEFSSI macro.

(A subsystem, unless requested to start under the primary JES subsystem by

setting flag SSCTUPSS in the SSCVT, starts under the master subsystem, MSTR.)

A started task, regardless of the subsystem under which it runs, is demand-selected

and runs in its own address space. Several considerations apply:
v The task can be a multi-step procedure or a job.
v It may not use operating system restart facilities. (The system does not support
step restarts or checkpoint restarts for started tasks.)
v The JCL for the started task may contain the following statements:
– COMMAND
– ELSE
– ENDIF
– IF/THEN
– INCLUDE
– SET
v The system defines the system symbolic parameter &SYSUID. If the member
name that is the target of the START command matches an entry in the started
procedures table, &SYSUID contains the corresponding userid from that table.

Chapter 7. Started Tasks 7-5

Started Tasks
Otherwise, &SYSUID contains a null string. For information on the started
procedures table, see z/OS Security Server RACF System Programmer’s Guide.

Running a Started Task Under a Job Entry Subsystem

These additional considerations apply to a started task running under a job entry
subsystem (JES):
v The JCL for the started task may contain commands and JES2 JECL statements.
It may not use JES3 JECL.
v The JCL may contain a JCLLIB statement, and the started task may have a
SYSIN data set, but these are permitted only if the JCL being started is a
complete job. For example, the following will work:
//STC JOB
// JCLLIB ORDER=...
//STEP1 EXEC PGM=...
//MYDATA DD *
These are the times that try men’s souls.
/*
//
v The started task may have SYSOUT data sets.
v JES exits get control (to validate and modify the task).

Running a Started Task Under the Master Subsystem

These additional considerations apply to a started task that runs under the master
subsystem:
v Any started task that can operate under the master subsystem can also run
under the primary JES subsystem.
v A started task running under the master subsystem (SUB=MSTR) may choose to
use JES services. To do so, the task must issue a Request Job ID call to the
JES. (See z/OS MVS Using the Subsystem Interface for additional information
about the Request Job ID call.)
v The started task may include JES statements and commands with the //
COMMAND statement. Note, however, that if JES is not running, the system may
queue or purge these statements.
v The JCL may not include a JCLLIB statement.
v The JCL may include PROC and PEND statements if the JCL is a procedure, but
not if it is a job.
v The started task may not have SYSIN data sets.
v The system will initially allocate only data sets that are cataloged in the master
catalog, an integrated catalog facility (ICF) catalog, or in a private catalog.
v You may dynamically allocate data sets that are not cataloged in the master
catalog to a task running under the master subsystem during execution.
v You may dynamically allocate SYSOUT data sets after successfully completing a
Request Job ID SSI call.
v JES exits do not get control during startup processing of a started task. If,
however, the started task issues a Request Job ID SSI call, JES exits will get
control for the minimal JCL used to construct the JES job structure.
v SMF exits, such as IEFUJV, get control with the subsystem shown as SYS.
v SRM determines performance characteristics based on the master subsystem.
v You may not specify JES3-managed devices in the procedure; JES3 cannot
manage devices for tasks that run under the master subsystem.

7-6 z/OS V1R3.0 MVS JCL Reference

 Started Tasks
v You must code a TIME= value on the EXEC statement of the procedure (such as
TIME=NOLIMIT), or else specify the program as a system task in the program
properties table (PPT). Otherwise, the task will end abnormally with a time-out
condition.

Running a Started Task That Uses ICF Catalogs

An integrated catalog facility (ICF) catalog describes data set attributes and
indicates the volumes on which a data set is located. ICF catalogs are allocated by
the catalog address space (CAS), a system address space for the DFSMS/MVS
DFSMSdfp catalog function.

For a started task to use data sets cataloged in an ICF user catalog, either of the
following must occur:
v You start the started task after the CAS is fully active, or
v The started task is one of the following:
– Not a subsystem
– A subsystem that is used to start another task
– A subsystem that is started under the primary JES subsystem

If neither of those conditions is met and the task attempts to obtain catalog
information, the system ends the started task abnormally. To avoid this potential
abend, either specify unit and volume information in your JCL for each data set
cataloged in an ICF user catalog, or catalog the data sets in the master catalog.

Set Up the Master JCL

Before adding or changing a started task, contact the system programmer who
controls the master JCL. With that person, identify and define the data sets to which
you will need access, and what you intend to change. For information on setting up
the master JCL, the system programmer can see z/OS MVS Initialization and
Tuning Reference.

Coding the JCL

When you have determined what the started task source JCL will be, where it will
run, and have set up the necessary support for it, you are ready to code the JCL for
the started task.

This section explains how to:

v Code a JOB statement for a started task
v Use symbols in started task JCL.

Coding the JOB Statement for the Started Task

If you choose to code a started task with a JOB statement, the rules are slightly
different than the rules for other jobs:
v The statement must start with //
v The jobname is 1 through 8 non-blank characters
v The jobname does not have to follow conventional JCL jobname rules (in terms
of valid characters); however, if the jobname is not valid, it must be overridden by
the JOBNAME parameter of the START command. If a name is not valid and is
not overridden, a JCL error results.
v The jobname must be followed by at least 1 blank.
v JOB must follow the blank(s) after the jobname.

Chapter 7. Started Tasks 7-7

Started Tasks
v JOB must be followed by at least 1 blank.

Using Symbols in Started Task JCL

You can code both system symbols and JCL symbols in started task JCL for both
jobs and procedures. This section provides examples of how to code system
symbols and JCL symbols in started task JCL. For details on how to code system
symbols in JCL, and how to define and code JCL symbols in JCL, see “Using
System Symbols and JCL Symbols” on page 5-12.

Example: Using System Symbols

Suppose you want to start a task whose source JCL is in the DUMPCHK member
of a partitioned data set. You can specify system symbols for the task in one of the
following two ways:
On the START command:
Suppose you enter the following command to start the DUMPCHK task:
START DUMPCHK,SG=ALL,JDATE=93119,DAY=THURSDAY,SUB=CICS&SYSNAME

If the substitution text for the &SYSNAME system symbol is SYS1 on the
system that processes the START command, the system substitutes the text
SYS1 for the &SYSNAME system symbol. The equivalent source JCL is:
//DUMPCHK JOB MSGLEVEL=1
//STARTING EXEC DUMPCHK,SG=ALL,JDATE=93119,DAY=THURSDAY,SUB=CICSSYS1
In the source JCL:
You can also specify system symbols in the source JCL for started tasks. Keep
in mind that system symbols in the source JCL are resolved during JCL
processing, rather than command processing.
For example, suppose you code the following JCL in the DUMPCHK procedure:
//DUMPCHK PROC
//S1 EXEC PGM=DUMPPROG,PARM=CICS&SYSNAME

As in the previous example for the START command, if the substitution text for
the &SYSNAME system symbol is SYS1 on the system that processes the JCL,
the system substitutes the text SYS1 for the &SYSNAME system symbol. The
equivalent JCL is:
//DUMPCHK PROC
//S1 EXEC PGM=DUMPPROG,PARM=CICSSYS1

The DUMPCHK procedure can also include system symbols on other

statements. For example, you might specify system symbols in DD statements
that must specify data sets with unique names on different systems.

Suppose that two systems, named SYS1 and SYS2, are to process a
DUMPCHK procedure that contains the following statement:
//LOG DD DSN=&SYSNAME..LOG,DISP=......

When each system processes the statement, the following data set names
result:
SYS1.LOG on system SYS1
SYS2.LOG on system SYS2

Example: Using JCL Symbols

Suppose that processing for some JCL is charged to multiple departments, all with
different accounting numbers, and the JCL is to reflect the number of the
department to be charged for the processing.

7-8 z/OS V1R3.0 MVS JCL Reference

 Started Tasks
Code a symbol in the source JCL to represent the different account numbers:
ACCT=&ACCTNO

Assume that the source JCL is a started task named TEST. There are three
departments (A, B, and C) with three accounting codes (ACODE, BCODE, and
CCODE) respectively. You can have each department indicate its accounting code
on the START command. For example, when department A enters the following
command:
START TEST,ACCTNO=ACODE

The system places the ACODE value in the ACCTNO field.

You can also use symbols to set default values that can later be overridden (as
needed).

For example, if the procedure TEST has the following JCL coded:
ACCT=&ACCTNO

you can set the value of ACCT to ACODE by including the following JCL on the
PROC statement of procedure TEST:
ACCTNO=ACODE

ACODE is provided as the default value.

If another value is provided on the START command (for example, START TEST,
ACCT=BCODE), the new value (BCODE) overrides the default (ACODE) provided
in the JCL, but only for this instance of the started task. If the START command is
entered again without a value, the default will again be provided.

Note: This example modifies the step-level accounting data defined by the EXEC
statement ACCT parameter. The START command JOBACCT parameter can
be used to specify job-level accounting data.

Using Symbols on Certain JCL Statements

You might need to specify symbols within JCL for each invocation of a started task.
Consider the following statements for possible use of symbols:
v DD statements
v EXEC statements.

If DD statement keywords (or the positional parameters for UNIT and VOL=SER)
are specified on a START command, the following DD statement is added to the
JCL processed by the system:
//IEFPROC.IEFRDER DD keyword=value...

The added JCL either adds a DD statement (if an IEFRDER statement is not
specified in the source JCL) or modifies an existing IEFRDER DD statement in the
source JCL. The DD statement override allows you to determine the characteristics
for one DD statement when you issue the START command.

The DD statement keyword parameters can be any keyword that is valid on the
MVS JCL DD statement. The IEFRDER DD statement contains all of the DD
keywords specified on the START command. For example:
START ABLE.LOAD,DSNAME=MY.LOADLIB,DISP=SHR

creates the following DD statement:

Chapter 7. Started Tasks 7-9

Started Tasks
//IEFPROC.IEFRDER DD DSNAME=MY.LOADLIB,DISP=SHR

Also, DD statement keywords can be specified on the START command for

positional parameters on the DD statement in the procedure. For example:
START CICS.CICS,333,U30PAK

is the same as:

START CICS.CICS,UNIT=333,VOL=SER=U30PAK

Using JCL Statement Keywords and Symbols to Override JCL

You can use JCL statement keywords and symbols to override existing JCL.

JOB statement keyword parameters are those keywords defined for the MVS JCL
JOB statement. These keywords will add to or override the specification of the JOB
statement keywords. The EXEC statement keyword parameters are those keywords
defined for the MVS JCL EXEC statement. The treatment of these keywords
depends on whether the target of the START command is a job or a procedure.
See the following table. EXEC keywords that are also JOB keywords, such as TIME
and REGION, are treated as JOB keywords.

In this next example, assume ABC is a procedure, not a job. The following START
command creates a REGION=200K parameter on the JOB statement and a
DYNAMNBR=2 parameter on the EXEC statement:
START ABC.DEF,REGION=200K,DYNAMNBR=2

The result of the command is the following JCL:

//ABC JOB REGION=200K,MSGLEVEL=1
//DEF EXEC ABC,DYNAMNBR=2

You can use symbols to override other symbols that are specified in the procedure
to be started. For example, the following command starts customer information
control system (CICS) with a 20K region:
START CICS,A=20K

A=20K overrides A=10K on the following PROC statement:

//CICS PROC A=10K
// EXEC PGM=XYZ,REGION=&A

The command results in the following JCL:

//CICS JOB MSGLEVEL=1
//STARTING EXEC CICS,A=20K

Note: Select names for symbols carefully; see “Coding Symbols in JCL” on
page 5-17 for rules to use when coding and naming symbols.

The following table describes the actions that result from specifying various
keywords and symbols on the START command:

Source JCL Keyword Result

JOB JOB Overrides or added to source JOB statement
JOB EXEC Placed on SET statement as a symbol
JOB DD Overrides, or added to, source IEFRDER DD
statement

7-10 z/OS V1R3.0 MVS JCL Reference

 Started Tasks
Source JCL Keyword Result
Procedure Other (see note Placed on SET statement as a symbol
1)
Procedure JOB Overrides, or added to, source JOB statement
Procedure EXEC Placed on EXEC memname statement overriding
keyword
Procedure DD Overrides, or added to, source IEFRDER DD
statement
JOB Other (see note Placed on EXEC memname statement as symbol
1)

Note 1: Other does not include the START command reserved words SUB,
JOBNAME, and JOBACCT.

Naming a Started Task (Source JCL is a Job)

If you plan to run the started task more than once on the same system or on
different systems within a sysplex, consider using unique job names for each
instance of the started task. For example, you may want to name started tasks
according to the system tasks they support; you can name one set of jobs for CICS
terminal-owning regions (CICSTOR1, CICSTOR2) and another set for CICS
application-owning regions (CICSAOR1, CICSAOR2).

Note: You are not required to change the name of your started task; you probably
will not want to change the name of a started task that typically has only one
instance (OAM or LLA, for example).

There are four ways that you can name or identify a started task:
v JOBNAME parameter
Use the JOBNAME parameter on the START command to rename the started
task dynamically (see the description of START in z/OS MVS System Commands
for details).
v Membername
If you do not use the JOBNAME parameter on the START command and the
source JCL is a procedure, the system automatically assigns the membername
as the jobname.
v Source JCL
If you do not use the JOBNAME parameter on the START command and the
source JCL for the started task is a job, the jobname provided on the JOB
statement is assigned as the jobname.
v Identifier
If specified on the START command, and the started task runs in a system
address space that is created using common system address space procedure
IEESYSAS, the identifier is assigned to the started task.

Note: Given the capability to assign the jobname dynamically, it is recommended

that you use the JOBNAME parameter instead of the identifier. Only
operators can view the identifier for a started task, limiting automation and
identification by other users.

Chapter 7. Started Tasks 7-11

Started Tasks
If you decide to change the names of started tasks, be sure to update other
applications to recognize the new names.

Setting Up Operator Education for Your Started Task

When you have set up the system support necessary and have coded the JCL,
educate the system operators about any overrides you want them to use on the
START command for your started task, and inform them of when they should use
the overrides. Also, educate them on how to display information about your started
task (using the DISPLAY command) as well as how to manage your started task
(using the MODIFY, STOP, CANCEL, RESET, and FORCE commands).

7-12 z/OS V1R3.0 MVS JCL Reference

Chapter 8. JCL Command Statement
Purpose

Use the JCL command statement to enter an MVS operator command through the
input stream on a JES2 system.

However, the COMMAND statement, described on page 9-1, is the preferred way
within the job control language to specify MVS and JES commands.

Note: To enter a JES2 command, use the JES2 command statement described on
page 27-1. To enter a JES3 command, use the JES3 command statement
described on page 28-2.

The system usually executes an in-stream command as soon as it is read.

Therefore, the command will not be synchronized with the execution of any job or
step in the input stream. To synchronize a command with the job processing, tell
the operator the commands you want entered and when they should be issued, and
let the operator enter them from the console.

The system processes each command according to installation options for both the
input device from which the job was read, and the job class.

Considerations for an APPC Scheduling Environment

The command statement has no function in an APPC scheduling environment. If

you code the command statement, the system will check it for syntax and ignore it.

References

For more information on MVS commands and for descriptions of their parameters,
see z/OS MVS System Commands.

Description

Syntax

// command [parameter] [comments]

The command statement consists of the characters // in columns 1 and 2 and three fields:
operation (command), parameter, and comments.

Do not continue a command statement.

Operation Field
The operation field contains the MVS operator command and is coded as follows:
v Precede and follow the command with one or more blanks. It can begin in any
column.
v Code the command or a valid abbreviation for the command.

© Copyright IBM Corp. 1988, 2002 8-1

JCL Command Statement
Parameter Field
Code any required parameters. When more than one parameter is coded, separate
them with commas.

Comments Field
The comments field follows the parameter field after at least one intervening blank.
The system removes the comments field from the command before processing the
command.

Location in the JCL

A command statement can appear anywhere after a JOB statement and before the
end of the job. If a command statement appears between jobs, it is ignored. A
command statement should not be placed before the first JOB statement in an input
stream.

If a command statement contains errors, it is not executed. If the erroneous

statement is between two jobs in the input stream, the system does not issue a
message to indicate that the command is not executed.

Defaults
Two ways to control command authority are through JES initialization parameters
and RACF. For information about controlling command authority through
initialization parameters see, Initialization and Tuning for the appropriate subsystem
at your installation. For information about controlling command authority using
RACF see, z/OS MVS Planning: Operations.

Examples of the Command Statement

Example 1
// DISPLAY TS,LIST

In response to this command statement, the system displays the number and userid
of all active time-sharing users of the system.

Example 2
// F NETVIEW,CLOSE IMMED

In response to this command statement, the system shuts down NETVIEW. The
system considers IMMED to be a comment due to the delimiting blank.

8-2 z/OS V1R3.0 MVS JCL Reference

Chapter 9. COMMAND Statement
Purpose

Use the COMMAND statement to specify an MVS or JES command that the system
issues when the submitted JCL is converted.

The COMMAND statement is the preferred way within the job control language to
specify commands, rather than using the JCL command statement, which is
described in Chapter 8, “JCL Command Statement” on page 8-1. That is because
the COMMAND statement is in standard JCL statement format, is parsed and
processed using code common to the other JCL statements, and if necessary may
be continued across multiple card images, that is, is not limited to 80 characters.
Note that some MVS subsystems, including TSO, JES2, and JES3, offer additional
ways to enter system commands outside JCL, which may be preferable under
certain circumstances.

When the system encounters an in-stream command it issues message IEFC165I

to inform the operator. If the operator is requested to authorize running of
commands entered through the input stream, the system then issues message
IEFC166D asking for the operator to respond. The operator should respond REPLY
id,’Y’ if the command displayed in message IEFC165I is to be run, and REPLY
id,’N’ otherwise.

Because the system usually executes an in-stream command as soon as it is

converted, execution of the command will not be synchronized with the execution of
any job or job step in the input stream. To synchronize a command with job
processing, tell the operator the commands you want entered and when they should
be issued, and let the operator enter them from the console.

The system processes each command according to installation options for both the
input device from which the job was read, and the job class.

On a JES3 system, the system does not record in a job’s JESMSGLG data set any
commands you enter with the COMMAND statement.

References

For more information on MVS and JES commands and for descriptions of their
parameters, see z/OS MVS System Commands, z/OS JES2 Commands, and z/OS
JES3 Commands.

Considerations for an APPC Scheduling Environment

The COMMAND statement has no function in an APPC scheduling environment. If

you code a COMMAND statement, the system will check it for syntax and then
ignore it.

Description

Syntax
//[name] COMMAND ’command command-operand’ [comments]

© Copyright IBM Corp. 1988, 2002 9-1

 COMMAND
The COMMAND statement consists of the characters // in columns 1 and 2 and four fields:
name, operation (COMMAND), ‘command command-operand’, and comments.

Continuation onto Another Statement: To continue a COMMAND statement, end the

statement in column 71 and continue the statement in column 16 of the next statement. For
example:
(column 71)
|
// COMMAND ’START XYZ,PARM=’ABC,DEF,GHI,JK’,TIME=1440,REGION=4
// 096K’
|
(column 16)

Do not code an apostrophe in column 71; see “Continuing Parameter Fields Enclosed in
Apostrophes” on page 3-5 if you need more information.

Name Field
A name is optional on a COMMAND statement. If used, code it as follows:
v The name should be unique within the job.
v The name must begin in column 3.
v The name is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The name must be followed by at least one blank.
| v The name may be preceded by up to 8 alphanumeric or national characters, and
| then separated by a period. Coding the name in this way should not be confused
| with specifying an override, as can be done when coding DD statements.

If a name is not coded, column 3 must be blank.

Operation Field
The operation field consists of the characters COMMAND and must be preceded
and followed by at least one blank. It can begin in any column.

Parameter Field
The parameter field specifies the name of the command, at least one blank, and
then operands for the command. The command and its operands must be preceded
by at least one blank, enclosed in apostrophes, and followed by at least one blank.
The maximum length of the command is 123 characters. If the command operand
contains an apostrophe, code it as two apostrophes. You can specify any MVS
command that can be issued from the operator’s console.

Comments Field
The comments field follows the parameter field after at least one intervening blank.

Location in the JCL

A COMMAND statement can appear anywhere in the job after the JOB statement.

Defaults
Two ways to control command authority are through RACF and through JES
initialization parameters. For information about controlling command authority using
RACF, see z/OS MVS Planning: Operations. For information about controlling
command authority through initialization parameters, see either z/OS JES2

9-2 z/OS V1R3.0 MVS JCL Reference

 COMMAND
Initialization and Tuning Reference or z/OS JES3 Initialization and Tuning
Reference, as appropriate for the subsystem at your installation.

Examples of the COMMAND Statement

Example 1

The following shows an example COMMAND statement with the START command.
// COMMAND ’S VTAM’ start VTAM

Example 2

The following is an example of a command that is continued with the command

operand in apostrophes.
// COMMAND ’SEND ’’This message will be sent to user SCOTTC
// when this job is converted’’,USER=(SCOTTC)’

The command statement must end in column 71 and be continued in column 16.

Chapter 9. COMMAND Statement 9-3

9-4 z/OS V1R3.0 MVS JCL Reference
Chapter 10. Comment Statement
Purpose

Use the comment statement to enter a comment on the output listing. The comment
statement is used primarily to document a job and its resource requirements.

Description

Syntax

//*comments

The comment statement consists of the characters //* in columns 1, 2, and 3 and one field:
comments.

Code the comments in columns 4 through 80. The comments field does not need to be
preceded or followed by blanks. (In a JES3 system, do not use a JES3 keyword as the first
word in column 4 of the comment field, or the comment might be taken for a JES3
statement.)

Do not continue a comment statement using continuation conventions. Instead, code

additional comment statements.

Location in the JCL

Place a comment statement anywhere after the JOB statement. You can place a
comment statement between continuations of JCL statements.

Listing of Comments Statements

Use the MSGLEVEL parameter on the JOB statement to request that the job log
output listing contain all the JCL statements for your job.

See Table 6-1 on page 6-1 for the comment statement characters used in columns
1, 2, and 3.

Examples of the Comment Statement

//* THE COMMENT STATEMENT CANNOT BE CONTINUED,
//* BUT IF YOU HAVE A LOT TO SAY, YOU CAN FOLLOW A
//* COMMENT STATEMENT WITH MORE COMMENT
//* STATEMENTS.

© Copyright IBM Corp. 1988, 2002 10-1

Comment Statement

10-2 z/OS V1R3.0 MVS JCL Reference

 Chapter 11. CNTL Statement
Purpose

Use the CNTL statement to mark the beginning of program control statements in
the input stream. Program control statements specify control information for a
subsystem. The program control statements are ended by an ENDCNTL statement
and are called a CNTL/ENDCNTL group.

The DD statement that defines a data set to be processed by a subsystem must

refer to the CNTL statement in order for the subsystem to use the program control
statements in processing the data set.

References

The program control statements are documented in the publications for the
subsystems. For example, for information on program control statements for the
Print Services Facility (PSF) see PSF/MVS Application Programming Guide.

Description

Syntax

//label CNTL [ * comments]

The CNTL statement consists of the characters // in columns 1 and 2 and four fields: label,
operation (CNTL), parameter (*), and comments. The * parameter is required only when
comments follow.

Label Field
Code a label on every CNTL statement, as follows:
v The label must begin in column 3.
v The label is 1 through 8 alphanumeric or national ($, #, @)characters.
v The first character must be alphabetic or national ($, #, @)
v The label must be followed by at least one blank.
| v The label may be preceded by up to 8 alphanumeric or national characters, and
| then separated by a period. Coding the label in this way should not be confused
| with specifying an override, as can be done when coding DD statements.

Operation Field
The operation field consists of the characters CNTL and must be preceded and
followed by at least one blank. It can begin in any column.

Parameter Field
The parameter field contains only an asterisk. When present, the asterisk must be
preceded and followed by at least one blank. The asterisk is required only when the
statement contains comments.

Comments Field
The comments field follows the asterisk after at least one intervening blank.

© Copyright IBM Corp. 1988, 2002 11-1

CNTL
Location in the JCL
A CNTL statement must appear before the DD statement that refers to it. The CNTL
and its referencing DD statement must be in the same job step or in the same
cataloged or in-stream procedure step. A CNTL statement can be in a procedure
and the referencing DD statement can be in the calling job step, but not vice versa.

You can define CNTL/ENDCNTL groups at the job level and the step level. A
job-level CNTL/ENDCNTL group appears before the first EXEC statement of the
job. A step-level CNTL/ENDCNTL group appears within the same job step or
procedure step. If you code multiple step-level CNTL/ENDCNTL groups, the label
on each CNTL statement must be unique within that step. Likewise, multiple
job-level CNTL statements must also have unique labels. You can, however, use the
same name on a step-level CNTL label and a job-level CNTL label. In this case, the
step-level CNTL group overrides the job-level CNTL group.

Program Control Statements

Program control statements supply control information for a subsystem. A
subsystem can require one or more program control statements. The one or more
statements must be immediately preceded by a CNTL statement and immediately
followed by an ENDCNTL statement.

Do not code JCL statements within a program control group.

Program Control Statements in Procedures

You can code symbolic parameters on program control statements in a cataloged or
in-stream procedure.

You can override parameters on program control statements in a procedure. Follow

the rules used for overriding DD statement parameters in a procedure. For more
information, see “Modifying OUTPUT JCL and DD Statements” on page 5-4.

Example of the CNTL Statement

//STEP1 EXEC PGM=PRINT
//ALPHA CNTL * PROGRAM CONTROL STATEMENT FOLLOWS
//PRGCNTL PRINTDEV BUFNO=20,PIMSG=YES,DATACK=BLOCK
//OMEGA ENDCNTL
//AGAR DD UNIT=3800-3,CNTL=*.ALPHA

The PSF subsystem uses the BUFNO, PIMSG, and DATACK options of the
PRINTDEV control statement to print the data set for DD statement AGAR on a
3800 model 3. For information about the PRINTDEV statement, see PSF for
OS/390 & z/OS: Customization.

11-2 z/OS V1R3.0 MVS JCL Reference

Chapter 12. DD Statement
Purpose

Use the DD (data definition) statement to describe a data set and to specify the
input and output resources needed for the data set.

The parameters you can specify for data set definition are arranged alphabetically
in the following pages.

References

For information about the JES initialization parameters that provide installation
defaults, see z/OS JES2 Initialization and Tuning Reference and z/OS JES3
Initialization and Tuning Reference.

Description

Syntax
// [ddname ] DD [positional-parameter][,keyword-parameter]...[comments]
[procstepname.ddname]

// [ddname ] DD
[procstepname.ddname]

v The DD statement consists of the characters // in columns 1 and 2 and four fields: name,
operation (DD), parameter, and comments. Do not code comments if the parameter field
is blank.
v A DD statement is required for each data set.
v The maximum number of DD statements per job step is 3273, based on the number of
single DD statements allowed for a TIOT (task input output table) control block size of
64K. This limit can be different depending on the installation-defined TIOT size. The
IBM-supplied default TIOT size is 32K. For information about changing the size of the
TIOT, see z/OS MVS Programming: Authorized Assembler Services Guide.
In a JES3 system, the installation might further reduce the maximum number of DD
statements per job.

Name Field
When specified, code a ddname as follows:
v Each ddname should be unique within the job step. If duplicate ddnames appear
in a job step, processing is as follows:
– In a JES2 system: The system performs device and space allocation and
disposition processing for both DD statements; however, it directs all
references to the first DD statement in the step.
– In a JES3 system: If both DD statements request JES3 or jointly-managed
devices, the system cancels the job during JES3 interpretation. If only one or
neither DD statement requests a JES3 or jointly-managed device, the system
performs device and space allocation processing for both DD statements;
however, it directs all references to the first DD statement in the step.
v The ddname must begin in column 3.

© Copyright IBM Corp. 1988, 2002 12-1

DD
v The ddname is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The ddname must be followed by at least one blank.

Omitting the ddname

Do not code a ddname in two cases:

v The DD statement defines a data set that is concatenated to the data set of the
preceding DD statement.

Note: Allocation processing does not fail an attempt to concatenate an HFS file
to another HFS file, or an MVS data set, even though it is impossible to
read from or write to concatenated HFS files. Do not request
concatenation of HFS files.
v The DD statement is the second or third consecutive DD statement for an
indexed sequential data set.

Name Field when Overriding a Procedure DD Statement

Code the following in the name field of a DD statement that is to override a

procedure DD statement:
1. The name of the procedure step that contains the DD statement to be
overridden
2. Followed by a period
3. Followed by the ddname of the procedure DD statement that is to be
overridden.

Name Field when Adding a DD Statement to a Procedure

Code the following in the name field of a DD statement that is to be added to a

procedure:
1. The name of the procedure step to which the DD statement is to be added
2. Followed by a period
3. Followed by a ddname of your choosing.

For example:
//PROCSTP1.DDA DD parameters

Name Field when Adding a DD Statement to a Program

When you code a DD statement with a ddname of procstepname.ddname within a

program step, the system:
1. Checks the syntax of both the procstepname qualifier and the ddname qualifier
2. Uses only the ddname qualifier as the statement ddname
3. Adds the DD statement to the program step that contains the statement
4. Issues an informational message because procstepname is coded outside of a
procedure.

Special ddnames

Use the following special ddnames only when you want to use the facilities these
names represent to the system. These facilities are explained in Chapter 13,

12-2 z/OS V1R3.0 MVS JCL Reference

 DD
“Special DD Statements”.

JOBCAT SYSCHK
JOBLIB SYSCKEOV
STEPCAT SYSIN
STEPLIB SYSMDUMP
SYSABEND SYSUDUMP

Do not use the following ddnames on a DD statement in a JES2 system. They have
special meaning to JES2.

JESJCLIN JESMSGLG
JESJCL JESYSMSG

The following ddnames have special meaning to JES3; do not use them on a DD
statement in a JES3 system.

JCBIN JESJCL JS3CATLG

JCBLOCK JESMSGLG J3JBINFO
JCBTAB JOURNAL J3SCINFO
JESJCLIN JST J3STINFO
JESInnnn JESYSMSG STCINRDR
TSOINRDR

Operation Field
The operation field consists of the characters DD and must be preceded and
followed by at least one blank. It can begin in any column.

Parameter Field
A DD statement has two kinds of parameters: positional and keyword. All
parameters are optional.

Leave the parameter field blank only in the following case:

v When SMS will provide the necessary DD description.

Positional Parameters

A DD statement can contain one positional parameter. If coded, this positional

parameter must precede all keyword parameters.

POSITIONAL PARAMETERS VALUES PURPOSE

[ * ] *: for data sets containing no In a non-APPC scheduling

[DATA] JCL DATA: for data sets environment, begins an
containing JCL in-stream data set.
See page 12-18 or 12-47

DUMMY Specifies no space allocation,

no disposition processing,
See page 12-110 and, for BSAM and QSAM,
no I/O.

Chapter 12. DD Statement 12-3

 DD
POSITIONAL PARAMETERS VALUES PURPOSE

DYNAM (Parameter is supported to

provide compatibility with
See page 12-113 previous systems.)

Keyword Parameters

A DD statement can contain the following keyword parameters. You can code any
of the keyword parameters in any order in the parameter field after a positional
parameter, if coded.

Do not use DD statement keywords as symbolic parameters in procedures to be

started by a START command from the operator console.

KEYWORD PARAMETERS VALUES PURPOSE

ACCODE=access-code For ISO/ANSI/FIPS Version 3 tapes, Specifies or changes an

access-code: 1 - 8 characters, first accessibility code for an
See page 12-22 must be upper case A - Z. ISO/ANSI/FIPS Version 3
or ISO/ANSI Version 4
For ISO/ANSI Version 4 tapes, tape output data set.
access-code: 1 - 8 characters, first
must be upper case A - Z, number 0 -
9, or one of these special characters:
!*″%&’()+,-./:;<=>?_

AMP=(subparameter) see z/OS DFSMS: Using Data Sets Completes information in

AMP=('subparameter[,subparameter]...') an access method
control block (ACB) for a
subparameters: VSAM data set.

AMORG
BUFND=number
BUFNI=number
BUFSP=bytes
CROPS= {RCK}
{NCK}
{NRE}
{NRC}

| FRLOG= {NONE}
| {REDO}

OPTCD= {I }
{L }
{IL}

RECFM= {F }
{FB}
{V }
{VB}

STRNO=number
SYNAD=modulename
TRACE

See page 12-23

12-4 z/OS V1R3.0 MVS JCL Reference

 DD
KEYWORD PARAMETERS VALUES PURPOSE
With SMS only: U: space specified in records Specifies a record
AVGREC= {U} K: space specified in thousands request and the quantity
{K} of records of primary and
{M} M: space specified in millions secondary space
of records specified on the SPACE
See page 12-31 parameter.

BURST= {YES} YES or Y: burster-trimmer-stacker Directs output to a

{Y } NO or N: continuous forms stacker stacker on a 3800
{NO } Printing Subsystem.
{N }

See page 12-35

CCSID=nnnnn nnnnn: 1 - 65535 Specifies the coded
character set identifier
See page 12-37 indicating the character
code conversion
performed on reads from
and writes to tapes
accessed in ISO/ANSI
Version 4 format.

CHARS= {table-name } 1 - 4 table-name subparameters: Names

{(table-name[,table-name]...)} 1 - 4 alphanumeric or $, #, @ character-arrangement
{DUMP } characters tables for printing on a
{(DUMP[,table-name]...) } 3800 Printing
DUMP: 204-character print lines Subsystem. Requests a
See page 12-39 on 3800 high-density dump on a
SYSABEND or
SYSUDUMP DD
statement.

CHKPT=EOV Requests a checkpoint at

each end-of-volume
See page 12-41 except the last.

CNTL= {*.label } label: names CNTL statement Causes the system to

{*.stepname.label } stepname: CNTL in named step execute statements
{*.stepname.procstepname.label} procstepname: step in named following an earlier CNTL
procedure statement.
See page 12-43

COPIES= {nnn } nnn (JES2): 1 - 255 Specifies number of

{(nnn,(group-value[,group-value]...))} nnn (JES3): 1 - 254 copies printed. For a
{(,(group-value[,group-value]...)) } 1 - 8 group-values (JES2): 1 - 255 3800 Printing
1 - 8 group values (JES3): 1 - 254 Subsystem, can instead
See page 12-44 specify number of copies
of each page printed
before the next page is
printed.
With SMS only: data-class-name: installation-defined Specifies the data class
DATACLAS=data-class-name name of a data class for a new data set.

See page 12-50

Chapter 12. DD Statement 12-5

DD
KEYWORD PARAMETERS VALUES PURPOSE

DCB=(subparameter[,subparameter]...) subparameter: see tables in DCB Completes information in

parameter description data control block (DCB).

DCB= ( {dsname } ) *.ddname: copy DCB parameter from

( {*.ddname } ) named cataloged data set
( {*.stepname.ddname } )
( {*.stepname.procstepname.ddname} ) dsname: copy DCB information from
( [,subparameter]... ) named earlier DD statement

See page 12-53 stepname: DD in named step

procstepname: step in named

procedure

DDNAME=ddname ddname: names later DD statement Postpones defining the

data set until later in
See page 12-75 same step: on a DD
statement in the calling
step or in a procedure
called by the step.

DEST=destination LOCAL or ANYLOCAL: local device Sends a sysout data set

to the specified
destination (JES2): name: named local or remote device destination.
LOCAL
name Nnnnn: node (1 - 1000)
Nnnnn
NnnRmmmm to NnnnnRmm NnRm: node (1 - 1000) and remote
Rnnnn or RMnnnn or RMTnnnn work station (1 - 9999); 6 digits
Unnnn maximum for n and m combined
(node,userid)
Rnnnn or RMnnnn or RMTnnnn:
destination (JES3): remote terminal (1 - 9999)
ANYLOCAL
device-name Unnnn: local terminal (1 - 9999)
device-number
group-name (node,userid): node (1 - 8
nodename alphanumeric or $, #, @ characters)
(node,userid) and TSO/E userid (1 - 7 alphanumeric
or $, #, @ characters) or VM userid
See page 12-80 (1 - 8 alphanumeric or $, #, @
characters)

device-number: 3-digit or 4-digit

hexadecimal number (/ required
before 4-digit number)

device-name: local device (1 - 8

alphanumeric or $, #, @ characters)

group-name: 1 or more local devices

or remote stations (1 - 8
alphanumeric or $, #, @ characters)

nodename: node (1 - 8 alpha-

numeric or $, #, @ characters)

12-6 z/OS V1R3.0 MVS JCL Reference

 DD
KEYWORD PARAMETERS VALUES PURPOSE

DISP=status status: NEW, OLD, SHR (for shared), Describes the status of
DISP=([status][,normal-termination-disp] MOD (for data set to be modified) the data set and tells the
[,abnormal-termination-disp]) system to do the
normal-termination-disp: DELETE, following with the data
See page 12-84 KEEP, PASS, CATLG, or UNCATLG set after normal or
abnormal termination of
abnormal-termination-disp: DELETE, the step or job: delete or
KEEP, CATLG, or UNCATLG keep it on its volume(s),
pass it to a later step, or
add it to or remove it
from the catalog.

DLM=delimiter delimiter: 2 characters In a non-APPC

scheduling environment,
See page 12-96 terminates an in-stream
data set.

DSID= {id } id: 1 - 8 characters Identifies a data set on a

{(id,[V])} V: label was verified (only on a diskette of a 3540
SYSIN DD statement) Diskette Input/Output
See page 12-97 Unit.

{DSNAME} = {dsname } unqualified dsname: 1 - 8 Names the data set.

{DSN } {dsname(member-name) } alphanumeric or $, #, @ characters, -,
{dsname(generation-number) } +0
{dsname(area-name) }
{&&dsname } qualified dsname: multiple names
{&&dsname(member-name) } joined by periods
{&&dsname(area-name) }
{*.ddname } member-name: member in PDS or
{*.stepname.ddname } PDSE
{*.stepname.procstepname.ddname}
{NULLFILE } generation-number: 0 or signed
integer
See page 12-99
area-name: INDEX, PRIME, or
OVFLOW area in indexed sequential
data set

&&dsname: temporary data set name

*.ddname: copy dsname from earlier
DD

stepname: DD in named step

procstepname: step in named

procedure

NULLFILE: dummy data set

DSNTYPE= {LIBRARY} LIBRARY: partitioned data Specifies the type of

{HFS } set extended (PDSE) data set.
{PDS } HFS: hierarchical file system
{PIPE } (HFS) data set
PDS: partitioned data set
See page 12-108 PIPE: FIFO special file

EXPDT= {yyddd } yyddd: expiration date (yy: 2-digit Specifies an expiration

{yyyy/ddd} year, ddd: day 001-366) date for the data set.

See page 12-114 yyyy/ddd: expiration date (yyyy:

4-digit year, ddd: day 001-366)

Chapter 12. DD Statement 12-7

DD
KEYWORD PARAMETERS VALUES PURPOSE

FCB= {fcb-name } fcb-name: 1 - 4 alphanumeric or Specifies FCB image,

{(fcb-name [,ALIGN ] ) } $, #, @ characters carriage control tape for
[,VERIFY ] ALIGN: operator check forms 1403 Printer, or
alignment data-protection image for
See page 12-116 VERIFY: operator verify FCB image 3525 Card Punch.

FILEDATA= {BINARY} BINARY: byte-stream file Specifies the

{TEXT } TEXT: delimited by the organization of a
EBCDIC newline character hierarchical file.
See page 12-119

FLASH= {overlay-name } overlay-name: forms overlay frame For printing on a 3800

{(overlay-name[,count])} (1 - 4 alphanumeric or $, #, Printing Subsystem,
{NONE } @ characters) indicates that the data
count: copies with overlay (0 - 255) set is to be printed with
See page 12-120 NONE: suppresses flashing the named forms overlay
and can specify how
many copies are to be
flashed.

FREE= {END } END: unallocate at end of last step Specifies when to

{CLOSE} CLOSE: unallocate when data set is unallocate the resources
closed for this data set.
See page 12-122

HOLD= {YES} YES or Y: holds this sysout data set Tells the system to hold
{Y } this sysout data set until
{NO } NO or N: allows normal processing released by the operator.
{N } for this sysout data set’s output class

See page 12-125

KEYLEN=bytes bytes: number of bytes (1-255 for Specifies the length of

key-sequenced (KS), 0-255 for the keys in the data set.
See page 12-127 sequential (PS) or partitioned (PO))
With SMS only: offset-to-key: position of key (0 to Specifies the offset of the
KEYOFF=offset-to-key difference of LRECL and KEYLEN first byte of the record
minus 1) key.
See page 12-129

LABEL= ([data-set-seq-no][,label-type] [,PASSWORD]) [,IN ] [,RETPD=nnnn ])

[,NOPWREAD]) [,OUT] [,EXPDT= {yyddd }]
[, ]) [, ] [ {yyyy/ddd}]

See page 12-130

12-8 z/OS V1R3.0 MVS JCL Reference

 DD
KEYWORD PARAMETERS VALUES PURPOSE
data-set-seq-no: data set position on Specifies information
tape volume (1 - 4 decimal digits) about a data set’s label,
password, opening,
label-type: SL: IBM standard labels expiration date, and, for
SUL: IBM standard and user labels a tape data set, relative
AL: ISO/ANSI Version 1 and position on the volume.
ISO/ANSI/FIPS Version 3 labels AUL:
user labels and ISO/ANSI Version 1
and ISO/ANSI/FIPS Version 3 labels
NSL: nonstandard labels NL: no
labels BLP: bypass label processing
LTM: leading tapemark

PASSWORD: password required to

access data set

NOPWREAD: password required to

change or delete data set

IN: only read BSAM data set opened

for INOUT or BDAM data set opened
for UPDAT

OUT: only write to BSAM data set

opened for OUTIN or OUTINX

RETPD=nnnn: retention period (nnnn:

1 - 4 decimal digits)

EXPDT=yyddd: expiration date (yy:

2-digit year, ddd: day 001 - 366)

EXPDT=yyyy/ddd: expiration date

(yyyy: 4-digit year, ddd: day 001 -
366)
With SMS only: data-set-name: dsname of model data Specifies the attributes of
LIKE=data-set-name set a new data set.

See page 12-138

LRECL=bytes bytes: length in bytes (1-32,760 for Specifies the length of

PS or PO, 1-32,761 for KS, ES, or the records in the data
See page 12-140 RR) set.
With SMS only: data-class-name: installation- defined Specifies the
MGMTCLAS=data-class-name name of a data class management class for a
new data set.
See page 12-141

MODIFY= {module-name } module-name: 1 - 4 alphanumeric or Specifies a

{(module-name[,trc])} $, #, @ characters copy-modification module
in SYS1.IMAGELIB to be
See page 12-143 trc: table-name in CHARS parameter used by JES to print the
(0 for first, 1 for second, 2 for third, data set on a 3800
and 3 for fourth table-name) Printing Subsystem.

OUTLIM=number number: 1 - 16777215 logical records Limits the logical records

maximum in this sysout data set.
See page 12-145

Chapter 12. DD Statement 12-9

DD
KEYWORD PARAMETERS VALUES PURPOSE

OUTPUT= {reference } name: names earlier OUTPUT JCL Associates this sysout
{(reference[,reference]...)} statement data set with one or
stepname: OUTPUT JCL in named more OUTPUT JCL
reference: step statements.
*.name procstepname: step in named
*.stepname.name procedure
*.stepname.procstepname.name

See page 12-146

PATH=pathname pathname: pathname for a file Specifies the name of an

HFS file.
See page 12-150

PATHDISP=(normal-termination-disposition, normal-termination-disposition: Tells the system to keep

abnormal-termination-disposition) KEEP, DELETE or delete the file after the
abnormal-termination-disposition: job step ends.
See page 12-153 KEEP, DELETE

PATHMODE=file-access-attribute file-access-attribute for file owner Specifies file access

PATHMODE=(file-access-attribute class: SIRUSR, SIWUSR, SIXUSR, attributes when creating
[,file-access-attribute]...) SIRWXU an HFS file.

See page 12-155 file-access-attribute for file group

class: SIRGRP, SIWGRP, SIXGRP,
SIRWXG

file-access-attribute for file other

class: SIROTH, SIWOTH, SIXOTH,
SIRWXO

file-access-attribute to set process

IDs: SISUID, SISGID

PATHOPTS=file-option file-option for access group: Specifies access and

PATHOPTS=(file-option[,file-option]...) ORDONLY, OWRONLY, ORDWR status for a file.

See page 12-158 file-option for status group:

OAPPEND, OCREAT, OEXCL,
ONOCTTY, ONONBLOCK, OTRUNC

PROTECT=YES Requests that RACF

create a discrete profile
See page 12-162 to protect a data set on
direct access or a tape
volume.

QNAME=procname[.tcamname] procname: names a TPROCESS Indicates that this data

macro that defines a destination set contains TCAM
See page 12-164 queue for the messages messages.

tcamname: names a TCAM job or

started task to process the messages

12-10 z/OS V1R3.0 MVS JCL Reference

 DD
KEYWORD PARAMETERS VALUES PURPOSE

RECFM= {F } Record format is: Specifies the format and

{FB } F: fixed length characteristics of the
{FBS} B: blocked records in a data set.
{FS } [A] S: spanned
{V } [M] V: variable length
{VB } U: undefined length
{VBS} Control characters are:
{VS } A: ISO/ANSI code
{U }
M: machine code
See page 12-165
With SMS only: Organization of records: Specifies the
RECORG= {KS} KS: key-sequenced organization of the
{ES} ES: entry-sequenced records in a VSAM data
{RR} RR: relative record set.
{LS} LS: linear space

See page 12-169

With SMS only: Referenced DD statement: Specifies the attributes of
REFDD= {*.ddname } a new data set by
{*.stepname.ddname } ddname: unqualified name referring to a previous
{*.stepname.procstepname.ddname} DD statement.
stepname: qualified by step name
See page 12-170
procstepname: step in procedure

RETPD=nnnn nnnn: number of days (0-9999) Specifies the retention

period for a new data
See page 12-172 set.

RLS= {NRI} NRI: can read uncommitted changes Specifies the record-level
{CR } CR: can read only committed sharing protocol to be
changes used with a VSAM data
See page 12-174 set.
With SMS only: profile-name: name of model profile Specifies a RACF profile
SECMODEL=(profile-name[,GENERIC]) GENERIC: model is generic profile to be used for a new
data set.
See page 12-176

SEGMENT=page-count page-count: number of pages of a Specifies the number of

sysout data set pages produced for the
See page 12-177 current segment of the
sysout data set before
the data set is spun-off
for output processing.
(JES2 only)

Chapter 12. DD Statement 12-11

DD
KEYWORD PARAMETERS VALUES PURPOSE
For system assignment of space:
SPACE=({TRK, } (primary-qty [,second-qty] [,directory]) [,RLSE] [,CONTIG] [,ROUND] )
{CYL, } [, ] [,index ] [, ] [,MXIG ]
{blklgth,} [,ALX ]
{reclgth,} [, ]

To request specific tracks:

SPACE=
(ABSTR, (primary-qty,address [,directory]))
[,index ]

To request directory blocks (with SMS only):

SPACE=(,(,,directory))

See page 12-178

TRK: allocation in tracks Requests space for a
new data set on direct
CYL: allocation in cylinders access storage.

blklgth: allocation in average blocks, 1

- 65535

reclgth: allocation in average records

(SMS)

primary-qty: number of tracks,

cylinders or blocks to be allocated

second-qty: additional tracks or

cylinders to be allocated, if more are
needed

directory: number of 256-byte records

for PDS directory

index: tracks or cylinders for index of

indexed sequential data set

RLSE: release unused space when

data set is closed

CONTIG: contiguous primary

allocation

MXIG: allocation in largest available

space (not supported for indexed
sequential data sets)

ALX: allocation of up to 5 separate

contiguous primary quantities

ROUND: allocation by block length

rounded to integral cylinders

ABSTR: allocation at the specified

address

address: track number of first track to

be allocated

12-12 z/OS V1R3.0 MVS JCL Reference

 DD
KEYWORD PARAMETERS VALUES PURPOSE

SPIN= {UNALLOC} UNALLOC: the data set is available Specifies that the output
{NO } for printing immediately upon for a sysout data set is
unallocation NO: the data set is available for printing
See page 12-187 available for printing at the end of the immediately upon
job unallocation or at the
end of the job.
With SMS only: storage-class-name: installation- Specifies the storage
STORCLAS=storage-class-name defined name of a storage class class for a new data set.

See page 12-189

SUBSYS= (subsystem-name ) subsystem-name: identifies the Requests a subsystem to

([,subsystem-parameter]...) subsystem process this data set.
subsystem-parameter: specifies
See page 12-190 information for the subsystem

SYSOUT=class class: A - Z, 0 - 9 Defines this data set as

SYSOUT=([class] [,writer-name] [,form-name]) a sysout data set and (1)
[,INTRDR ] [,code-name] writer-name: 1 - 8 alphanumeric or $, assigns it to an output
[, ] #, @ characters class, (2) requests
SYSOUT=* external writer to process
SYSOUT=(,) form-name: 1 - 4 alphanumeric or $, it, (3) identifies print or
#, @ characters punch forms, and (4)
See page 12-193 refers to the code-name
code-name: 1 - 4 alphanumeric or $,
of a JES2 /*OUTPUT
#, @ characters (JES2 only)
statement.
*: same output class as MSGCLASS
parameter on JOB statement

TERM=TS The TERM parameter

has no function in an
See page 12-199 APPC scheduling
environment. In a
foreground job,indicates
that this data set is
coming from or going to
a TSO/E userid. In a
batch job, indicates that
this DD statement begins
an in-stream data set.

UCS= {character-set-code } character-set-code: 1 - 4 alpha- Specifies universal

{(character-set-code [,FOLD] [,VERIFY])} numeric or $, #, @ characters character set, print train,
{ [, ] } or character-
FOLD: operator load chain or train in arrangement table for a
See page 12-200 fold mode 3800 Printing
Subsystem.
VERIFY: operator verify UCS image

Chapter 12. DD Statement 12-13

DD
KEYWORD PARAMETERS VALUES PURPOSE

UNIT= ([ddd ] [,unit-count][,DEFER]) device-number: 3-digit or 4-digit Requests allocation to a

[/ddd ] [,P ] hexadecimal number (/ required specific device, a type or
[/dddd ] [, ] before 4-digit number and optional group of devices, or the
[device-type ] before 3-digit number) same device(s) as
[group-name ] another data set. Also
device-type: machine type and model can specify how many
UNIT=AFF=ddname devices and deferred
group-name: 1 - 8 alphanumeric or $, mounting.
See page 12-203 #, @ characters

unit-count: 1 - 59

P: allocate same number of devices

as volumes for parallel mount

DEFER: defers mounting until open

AFF=ddname: requests allocation of

same devices as for DD statement
ddname

{VOLUME}=([PRIVATE] [,RETAIN] [,volume-seq-no][,volume-count][,][SER=(serial-number[,serial-number]...)])

{VOL } [, ] [, ] [REF=dsname ]
[REF=*.ddname ]
[REF=*.stepname.ddname ]
[REF=*.stepname.procstepname.ddname ]
[REF=*.procstepname.ddname ]

See page 12-210

12-14 z/OS V1R3.0 MVS JCL Reference

 DD
KEYWORD PARAMETERS VALUES PURPOSE
PRIVATE: requests a private volume Identifies the volume(s)
on which a data set
RETAIN: requests private tape resides or will reside.
volume remain mounted and
unwound or requests public tape
volume be retained at device

volume-seq-no: begins processing

with volume 1 - 255 of existing
multivolume data set

volume-count: maximum volumes for

output data set (1 - 255)

serial-number subparameters (1 -
255): volume serial numbers (1 - 6
alphanumeric, $, #, @, or special
characters)

REF: copy volume serial numbers

from another data set or earlier DD
statement, or copy storage class for
SMS-managed data sets

dsname: from cataloged or passed

data set

ddname: from named earlier DD

statement

stepname: DD in named step

procstepname: step in named

procedure

Comments Field
The comments field follows the parameter field after at least one intervening blank.
If you do not code any parameters on a DD statement, do not code any comments.

Location in the JCL

Most DD statements define data sets to be used in a job step, in a cataloged
procedure step, or in an in-stream procedure step; these appear after the EXEC
statement for the step. Some DD statements define data sets for the job, for
example, the JOBLIB DD statement; these appear after the JOB statement and
before the first EXEC statement.

When Overriding or Adding to Procedures

Place DD statements that override, nullify, or add parameters immediately following

the EXEC statement that calls the procedure. Place overriding and nullifying DD
statements first, followed by all added DD statements. Last in the calling step are
any DD * or DD DATA statements with their in-stream data.

To override more than one DD statement in a procedure, place the overriding DD

statements in the same order as the overridden DD statements in the procedure.

Chapter 12. DD Statement 12-15

DD
Concatenating Data Sets
You can logically connect or concatenate sequential or partitioned (PDSs or
PDSEs) input data sets for the duration of a job step. Each of the concatenated
data sets can reside on a different volume. For details on concatenating data sets,
see z/OS DFSMS: Using Data Sets. Note that you cannot concatenate output data
sets.

When data sets are concatenated, they are treated as having like attributes, and
the system obtains these attributes, except for block size, from the first data set in
the concatenation.

Coding a Concatenation
To concatenate data sets, omit the ddnames from all the DD statements except the
first in the sequence. The data sets are processed in the same sequence as the DD
statements defining them.

Devices for Concatenated Data Sets

Concatenated data sets can reside on different devices and different types of
devices. (This may require internal DCB modifications, see z/OS DFSMS: Using
Data Sets.)

Block Sizes for Concatenated Data Sets

Concatenated data sets can have different block sizes. In a few cases, the data set
with the largest block size must appear first in the concatenation. (Note that you
can state a value equal to the largest block size for BLKSIZE on the first DD
statement, regardless of what the actual block size of this data set is.) Certain data
sets can be concatenated in any order of block size; these are:
v Partitioned data sets (PDSs), and partitioned data sets extended (PDSEs)
without member names coded on the DD statements.
v Sequential data sets that are DASD-resident, tape-resident, or in-stream, and are
accessed by QSAM and use system-created buffers.
v Sequential data sets that are DASD-resident or in-stream, and are accessed by
BSAM.

For these data sets, the BLKSIZE obtained is the largest in the concatenation. Note
that this block size can cause invalid attribute combinations when combined with
the attributes obtained from the first data set in the concatenation.

If you do not specify a block size, the system can, under certain conditions,
determine an optimum block size. For detailed information about system-determined
block size, see z/OS DFSMS: Using Data Sets.

Logical Record Lengths for Concatenated Data Sets

Concatenated data sets with format-V records can have different logical record
lengths as long as the data set with the largest logical record length appears first in
the concatenation. (Note that you can state a value equal to the largest logical
record length for LRECL on the first DD statement, regardless of what the actual
logical record length of this data set is.)

References to Concatenated Data Sets

If you make a backward reference to a concatenation (using *.), the system
obtains information only from the first data set defined in the sequence of DD
statements.

If you make a forward reference to a concatenation (using the DDNAME

parameter), the forward reference resolves to the first data set in the concatenation.

12-16 z/OS V1R3.0 MVS JCL Reference

 DD
If there are no DD statements between the forward reference and the
concatenation, the rest of the data sets in the concatenation are appended to the
first data set in the concatenation. The following example illustrates this.
//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DDNAME=INPUT
//INPUT DD DSN=TSTDATA1,DISP=SHR
// DD DSN=TSTDATA2,DISP=SHR
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY

In this example, SYSUT1 will resolve to the first data set, TSTDATA1, defined by
the DDNAME forward reference INPUT. TSTDATA2, the second data set in the
DDNAME forward reference INPUT, will be appended to SYSUT1 as well.
IEBGENER will recognize TSTDATA1 and TSTDATA2 as input.

If there are any DD statements between the forward reference and the
concatenation, the rest of the data sets in the concatenation are appended to the
last DD statement preceding the concatenation. For example:
//STEP1 EXEC PGM=IEBGENER
//SYSUT1 DD DDNAME=INPUT
//SYSPRINT DD SYSOUT=*
//SYSUT2 DD SYSOUT=*
//INPUT DD DSN=TSTDATA1,DISP=SHR
// DD DSN=TSTDATA2,DISP=SHR
//SYSIN DD DUMMY

In the preceding example, SYSUT1 will resolve to the first data set, TSTDATA1,
defined in the DDNAME forward reference INPUT. TSTDATA2 will be appended to
SYSUT2, the last DD statement preceding the concatenation. In this example,
IEBGENER will recognize only TSTDATA1 as input.

If a concatenated DD is added to a procedure, the remaining concatenated data

sets will be concatenated to the last DD in the step named in an override or
addition (or to the first step if no step was named in an override or addition). Note
that this may result in these concatenated DDs being added to an unexpected DD.
The following example illustrates this.
//TPROC PROC
//S1 EXEC PGM=IEFBR14
//DD1 DD DDNAME=INPUT
//DD2 DD DSN=MYDSN2,DISP=SHR
//DD3 DD DSN=MYDSN3,DISP=SHR
//S2 EXEC PGM=IEFBR14
//DDA DD DDNAME=INPUT
//DDB DD DSN=MINE2,DISP=SHR
//DDC DD DSN=MINE3,DISP=SHR
// PEND
//STEP1 EXEC TPROC
//INPUT DD DSN=MYDSN1,DISP=SHR
// DD DSN=MYDSN4,DISP=SHR
//S2.INPUT DD DSN=MINE1,DISP=SHR
// DD DSN=MINE4,DISP=SHR

In this example, the result of the DDNAME forward reference INPUT is:
v In step S1, DD1 resolves to data set MYDSN1 and data set MYDSN4 is
concatenated to data set MYDSN3.
v In step S2, DDA resolves to data set MINE1 and data set MINE4 is concatenated
to data set MINE3.

Chapter 12. DD Statement 12-17

DD
Do Not Concatenate Data Sets after a DUMMY Data Set
If you define a data set using the DUMMY parameter, do not concatenate other
data sets after it. When the processing program asks to read a dummy data set, the
system takes an end-of-data set exit immediately and ignores any data set that
might be concatenated after the dummy.

Do Not Code Other Statements Between Concatenated DD

Statements
Do not code other types of statements between two or more concatenated data
definition (DD) statements. (Comments are the only exception; you can code them
between DD statements.) For example, do not code a SET statement as follows:
//DD1 DD DSN=A
// DD DSN=B
// SET ...
//* Wrong!!! SET statement not allowed (this comment IS allowed)
// DD DSN=C

Examples of DD Statements and ddnames

Example 1
//MYDS DD DSNAME=REPORT
//A DD DSNAME=FILE

Example 2
//INPUT DD DSNAME=FGLIB,DISP=(OLD,PASS)
// DD DSNAME=GROUP2,DISP=SHR

In this example, because the ddname is missing from the second DD statement, the
system concatenates the data sets defined in these statements.

Example 3
//PAYROLL.DAY DD DSNAME=DESK,DISP=SHR

In this example, if procedure step PAYROLL contains a DD statement named DAY,

this statement overrides parameters on DD statement DAY. If the step does not
contain DD statement DAY, the system adds this statement to procedure step
PAYROLL for the duration of the job step.

Example 4
//STEPSIX.DD4 DD DSNAME=TEXT,DISP=(NEW,PASS)
// DD DSNAME=ART,DISP=SHR

In this example, the second data set is concatenated to the first, and both are
added to procedure step STEPSIX. The ddname is omitted from the second DD
statement in order to concatenate data set ART to data set TEXT.

Because the system does not allow you to write to a concatenation of data, you
need another data set with DISP=OLD in order to read from TEXT. Write to the new
DD name before reading from DD4.

* Parameter
Parameter Type

Positional, optional

Purpose

12-18 z/OS V1R3.0 MVS JCL Reference

 DD: *
Use the * (asterisk) parameter to begin an in-stream data set. The data records
immediately follow the DD * statement; the records may be in any code such as
EBCDIC. The data records end when one of the following is found:
/* in the input stream
// to indicate another JCL statement
The two-character delimiter specified by a DLM parameter on this DD statement
The input stream runs out of card images

Use a DATA parameter instead of the * parameter if any of the data records start
with //.

Considerations for an APPC Scheduling Environment

The * parameter has no function in an APPC scheduling environment. If you code *,

the system will check it for syntax and otherwise ignore it.

Syntax
//ddname DD *[,parameter]... [comments]

Defaults
When you do not code BLKSIZE and LRECL, JES uses installation defaults
specified at initialization.

Note: If the input stream is from NJE (network job entry), JES uses the size
specified at the sending node.

Relationship to Other Parameters

You may specify the following DD parameters with the DD * and DD DATA
parameters. All other parameters are either ignored or result in a JCL error.

DCB=BLKSIZE DSNAME
DCB=BUFNO LIKE
DCB=LRECL LRECL
DCB=DIAGNS REFDD
DCB=MODE=C VOLUME=SER
DLM DSID

Restrictions When Coding LRECL

If you code LRECL with the * parameter, you cannot submit a data set to JES3 with
a record length greater than 80 bytes.

You cannot use the TSO/E SUBMIT command to submit a data set to JES2 or
JES3 with a record length greater than 80 bytes.

You can submit a data set to JES2 or JES3 with a record length greater than 80
bytes by submitting the following JCL:
//SUBMIT JOB ...
//S1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*

Chapter 12. DD Statement 12-19

DD: *
//SYSIN DD DUMMY
//SYSUT2 DD SYSOUT=(,INTRDR)
//SYSUT1 DD DSN=IBMUSER.LONGDATA.JCL,DISP=SHR

In this example, IBMUSER.LONGDATA.JCL contains the data with a record length

greater than 80 bytes.

In a JES3 system, the record length limit is the size of the installation-defined spool
buffer, minus 44. (For example, if the buffer size is 4084, the record length limit is
4040.) JES3 fails any job that exceeds this limit.

If the records longer than 80 bytes include JCL to be transmitted to a remote

system using JES3 // XMIT or //*ROUTE XEQ, or JES2 /*ROUTE XEQ or /*XMIT with
JES3 in the network, the records are truncated to 80 bytes.

For JES3 SNA RJP Input

v The only parameters you can specify for JES3 systems network architecture
(SNA) remote job processing (RJP) input devices are BLKSIZE and LRECL.
v Code DCB=LRECL=nnn, where nnn is 1 to 255 when SYSIN data records are
greater than 80 bytes. (The default LRECL is 80 bytes.)

For 3540 Diskette Input/Output Units

VOLUME=SER, BUFNO, and DSID on a DD * statement are ignored except when

they are detected by a diskette reader as a request for an associated data set. See
3540 Programmer’s Reference. On a DD * or DD DATA statement processed by a
diskette reader, you can specify DSID and VOLUME=SER parameters to indicate
that a diskette data set is to be merged into the input stream following the DD
statement.

Relationship to Other Control Statements

Do not refer to an earlier DD * statement in DCB, DSNAME, or VOLUME
parameters on following DD statements.

Location in the JCL

A DD * statement begins an in-stream data set.

In-stream Data for Cataloged or In-stream Procedures

A cataloged or in-stream procedure cannot contain a DD * statement. When you

call a procedure, you can add input stream data to a procedure step by placing in
the calling step one or more DD * or DD DATA statements, each followed by data.

Multiple In-Stream Data Sets for a Step

You can code more than one DD * or DD DATA statement in a job step in order to
include several distinct groups of data for the application program. Precede each
group with a DD * or DD DATA statement and follow each group with a delimiter
statement.

Omitted Data Delimiters

12-20 z/OS V1R3.0 MVS JCL Reference

 DD: *
If you omit a DD statement before the input data, the system provides a DD *
statement with the ddname of SYSIN. If you omit a delimiter statement after input
data, the system ends the data when it reads a JCL statement or runs out of card
images.

Unread Records
If the processing program does not read all the data in an in-stream data set, the
system skips the remaining data without abnormally terminating the step.

Examples of the * Parameter

Example 1
//INPUT1 DD *
.
.
data
.
//INPUT2 DD *
.
.
data
.
/*

This example defines two groups of data in the input stream.

Example 2
//INPUT3 DD *,DSNAME=&&INP3
.
data
.
/*

This example defines an in-stream data set with INP3 as the last qualifier of the
system-generated data set name. A name such as
userid.jobname.jobid.Ddsnumber.INP3 is generated.

Example 3
//STEP2 EXEC PROC=FRESH
//SETUP.WORK DD UNIT=3400-6,LABEL=(,NSL)
//SETUP.INPUT1 DD *
.
.
data
.
/*
//PRINT.FRM DD UNIT=180
//PRINT.INP DD *
.
.
data
.
/*

This example defines two groups of data in the input stream. The input data defined
by DD statement SETUP.INPUT1 is to be used by the cataloged procedure step
named SETUP. The input data defined by DD statement PRINT.INP is to be used
by the cataloged procedure step named PRINT.

Chapter 12. DD Statement 12-21

DD: ACCODE

ACCODE Parameter
Parameter Type

Keyword, optional

Purpose

Use the ACCODE parameter to specify or change an accessibility code for an

ISO/ANSI/FIPS Version 3 or ISO/ANSI Version 4 tape output data set. An
installation-written file-access exit routine verifies the code after the code is written
to tape. If the code is authorized, the job step’s program can use the data set; if
not, the system issues messages and may abnormally terminate the job step.

A data set protected by an accessibility code should reside only on a volume

protected by RACF or a volume accessibility code. The volume should not contain
any unprotected data sets.

Note: ACCODE is supported only for ISO/ANSI/FIPS Version 3 and ISO/ANSI

Version 4 tape data sets. ACCODE is ignored for all label types except AL
and AUL label tapes.

References

For more information on ISO/ANSI/FIPS Version 3 and ISO/ANSI Version 4 tape

data sets, see z/OS DFSMS: Using Magnetic Tapes. Also z/OS DFSMS Access
Method Services for Catalogs.

Syntax
ACCODE=access-code

Subparameter Definition
access-code
Specifies an accessibility code. The access code is 1 through 8 characters. In
ISO/ANSI/FIPS Version 3 the first character must be an upper case letter from
A through Z. In ISO/ANSI Version 4 the first character must be an upper case
letter from A to Z, number from 0 to 9, or one of the special characters ! * ″ % ’
( ) + , - . / : ; < = > ? and _ .
Enclose the ACCODE in apostrophes if you specify special characters. For
example, ACCODE=’AB/CD’. Specify two apostrophes if you include an
apostrophe as a special character. For example, to specify DAY’SEND, use
ACCODE=’DAY’’SEND’.

Note: ISO/ANSI/FIPS Version 3 and ISO/ANSI Version 4 use only the first
character as the accessibility code; the installation can use the other
seven characters. If the first character is other than those allowed, the
installation does not give control to the file-access exit routine.

Defaults
If you do not specify an accessibility code on a DD statement that defines an
ISO/ANSI/FIPS Version 3 or ISO/ANSI Version 4 tape data set, the system writes

12-22 z/OS V1R3.0 MVS JCL Reference

 DD: ACCODE
an ASCII blank character (X'20') in the tape label. A blank authorizes unlimited
access to the tape’s data sets unless access is limited by RACF data set protection.

If the installation does not supply a file-access exit routine, the system prevents
access to any ISO/ANSI/FIPS Version 3 or ISO/ANSI Version 4 tape volume.

Overrides
If PASSWORD or NOPWREAD is coded on the DD statement LABEL parameter,
password access overrides the ACCODE parameter.

Example of the ACCODE Parameter

//TAPE DD UNIT=2400,VOLUME=SER=T49850,DSNAME=TAPEDS,
// LABEL=(,AL),ACCODE=Z

In this example, the DD statement ACCODE parameter specifies an accessibility

code of Z for tape volume T49850. The volume has ISO/ANSI/FIPS Version 3 or
ISO/ANSI Version 4 labels. The data set TAPEDS is first on the tape.

AMP Parameter
Parameter Type

Keyword, optional

Purpose

Use the AMP parameter to complete information in an access method control block
(ACB) for a VSAM data set. The ACB is a control block for entry-sequenced,
key-sequenced, and relative record data sets.

AMP is supported only for VSAM data sets.

Note: With SMS, you can create new VSAM data sets with JCL DD statements.
See the DATACLAS parameter (described on page 12-50) and the RECORG
parameter (described on page 12-169).

References

For more information about VSAM data sets, see z/OS DFSMS: Using Data Sets,
z/OS DFSMS Macro Instructions for Data Sets, and z/OS MVS JCL User’s Guide.

Chapter 12. DD Statement 12-23

 DD: AMP
Syntax

AMP=(subparameter)

AMP=(’subparameter[,subparameter]...’)

AMP=’subparameter[,subparameter]...’

The subparameters are:

AMORG

BUFND=number

BUFNI=number

BUFSP=number

CROPS= [NCK]
[NRC]
[NRE]
[RCK]

| FRLOG= {NONE}
| {REDO}

OPTCD= {I }
{L }
{IL}

RECFM= [F ]
[FB]
[V ]
[VB]

STRNO=number

SYNAD=module

TRACE=(subparameter[,subparameter]...)

ACCBIAS=[USER ]
[SYSTEM]
[DO ]
[DW ]
[SO ]
[SW ]

SMBDFR= {Y | N}

SMBHWT= nn

SMBVSP= {nnK | nnM}

RMODE31=[ALL ]
[BUFF]
[CB ]
[None]

12-24 z/OS V1R3.0 MVS JCL Reference

 DD: AMP
Parentheses: Parentheses are required only when you are continuing the statement.

Multiple Subparameters: When a parameter contains more than one subparameter,

separate the subparameters by commas and enclose the subparameter list in apostrophes
inside the parentheses. For example, AMP=('AMORG,STRNO=4').

Null Positional Subparameters: Null positions in the AMP parameter are invalid.

Special Characters: When a parameter contains only one subparameter and that
subparameter contains special characters, enclose the subparameter in apostrophes inside
the parentheses. For example, AMP=('STRNO=4').
Note: Do not enclose a subparameter in a subparameter list in apostrophes.

If you code a symbolic parameter on the AMP parameter, you can code the symbolic
parameter in apostrophes.

Continuation onto Another Statement: Enclose the subparameter list in only one
set of parentheses. Enclose all the subparameters on each statement in
apostrophes. End each statement with a comma after a complete subparameter.
For example:
//DS1 DD DSNAME=VSAMDATA,AMP=(’BUFSP=200,OPTCD=IL,RECFM=FB’,
// ’STRNO=6’)

Subparameter Definition
AMORG
Indicates that the DD statement describes a VSAM data set. Code AMORG
when data set access is through an ISAM interface program and the DD
statement contains VOLUME and UNIT parameters.
It is unnecessary to code AMP=AMORG for a data set that is SMS-managed.
An SMS data set is cataloged at allocation; all information pertaining to the data
set creation (such as RECORG) must be fully defined at allocation to ensure
the success of the job.
BUFND=number
Specifies the number of I/O buffers that VSAM is to use for data records. The
minimum is 1 plus the STRNO subparameter number. This value overrides the
BUFND value specified in the ACB or GENCB macro, or provides a value if one
is not specified. If you omit STRNO, BUFND must be at least 2.
If you omit BUFND from AMP and from the ACB macro instruction, the system
uses the STRNO number plus 1.
BUFNI=number
Specifies the number of I/O buffers that VSAM is to use for index records. This
value overrides the BUFNI value specified in the ACB or GENCB macro, or
provides a value if one is not specified. If you omit BUFNI from AMP and from
the ACB macro instruction, VSAM uses as many index buffers as the STRNO
subparameter number; if you omit both BUFNI and STRNO, VSAM uses 1
index buffer.
If data access is through the ISAM interface program, specify for the BUFNI
number 1 more than the STRNO number, or specify 2 if you omit STRNO, to
simulate having the highest level of an ISAM index resident. Specify a BUFNI
number 2 or more greater than the STRNO number to simulate having
intermediate levels of the index resident.
BUFSP=number
Specifies the maximum number of bytes for the data and index buffers in the

Chapter 12. DD Statement 12-25

 DD: AMP
user area. This value overrides the BUFSP value specified in the ACB or
GENCB macro, or provides a value if one is not specified.
If BUFSP specifies fewer bytes than the BUFFERSPACE parameter of the
access method services DEFINE command, the BUFFERSPACE number
overrides the BUFSP number.
CROPS=NCK
CROPS=NRC
CROPS=NRE
CROPS=RCK
Requests a checkpoint/restart option. For more information, see z/OS DFSMS
Checkpoint/Restart.
NCK
Requests no data set post-checkpoint modification tests.
NRC
Requests neither a data-erase test nor data set post-checkpoint
modification tests.
NRE
Requests no data-erase test.
RCK
Requests a data-erase test and data set post-checkpoint modification tests.
If the CROPS subparameter is omitted, RCK is the default.

If you request an inappropriate option, such as the data-erase test for an input
data set, the system ignores the option.
| FRLOG=NONE
| FRLOG=REDO
| Specifies if VSAM batch logging will be performed for your VSAM data set.
| NONE
| Disables the VSAM batch logging function for your VSAM data set.
| Changes made by applications will not be written to the MVS log stream
| indicated on the LOGSTREAMID parameter.
| REDO
| Enables the VSAM batch logging function for you VSAM data set. Changes
| made by applications will be written to the MVS log stream indicated on the
| LOGSTREAMID parameter.
| Notes:
| 1. If FRLOG=REDO is specified, the LOGSTREAMID parameter must be
| specified for the VSAM data set(s). If LOGSTREAMID is not specified,
| IEC161I is issued.
| 2. There is no default JCL value for FRLOG. If FRLOG is omitted, the catalog
| value will be used.
OPTCD=I
OPTCD=L
OPTCD=IL
Indicates how the ISAM interface program is to process records that the step’s
processing program flags for deletion.
I Requests, when the data control block (DCB) contains OPTCD=L, that the
ISAM interface program is not to write into the data set records marked for
deletion by the processing program.

12-26 z/OS V1R3.0 MVS JCL Reference

 DD: AMP
If AMP=('OPTCD=I') is specified without OPTCD=L in the DCB, the system
ignores deletion flags on records.
L Requests that the ISAM interface program is to keep in the data set records
marked for deletion by the processing program.
If records marked for deletion are to be kept but OPTCD=L is not in the
DCB, AMP=('OPTCD=L') is required.

Note: This parameter has the same meaning and restrictions for the ISAM
interface as it has for ISAM. While it was not required in the ISAM
job control language, you should code it in the AMP parameter.
IL Requests that the ISAM interface program is not to write into the data set
records marked for deletion by the processing program. If the processing
program had read the record for update, the ISAM interface program
deletes the record from the data set.
AMP=('OPTCD=IL') has the same effect as AMP=('OPTCD=I') coded with
OPTCD=L in the DCB.
RECFM=F
RECFM=FB
RECFM=V
RECFM=VB
(For data sets with SMS, see the DD RECFM parameter described on page
12-165.)
Identifies the ISAM record format used by the processing program. You must
code this RECFM subparameter when the record format is not specified in the
DCB.

Note: This parameter has the same meaning and restrictions for the ISAM
interface as it has for ISAM. While it was not required in the ISAM job
control language, you should code it in the AMP parameter.

All VSAM requests are for unblocked records. If the processing program
requests blocked records, the ISAM interface program sets the overflow-record
indicator for each record to indicate that each is being passed to the program
unblocked.
F Indicates fixed-length records.
FB
Indicates blocked fixed-length records.
V Indicates variable-length records. If no RECFM is specified in the AMP
parameter or in the DCB, V is the default.
VB
Indicates blocked variable-length records.
STRNO=number
Indicates the number of request parameter lists the processing program uses
concurrently. The number must at least equal the number of BISAM and QISAM
requests that the program can issue concurrently. If the program creates
subtasks, add together the number of requests for each subtask plus 1 for each
subtask that sequentially processes the data set. This value overrides the
STRNO value specified in the ACB or GENCB macro, or provides a value if one
is not specified.

Chapter 12. DD Statement 12-27

DD: AMP
SYNAD=module
Names a SYNAD exit routine. The ISAM interface program is to load and exit to
this routine if a physical or logical error occurs when the processing program is
gaining access to the data set.
The SYNAD parameter overrides a SYNAD exit routine specified in the EXLST
or GENCB macro instruction that generates the exit list. The address of the
intended exit list is specified in the access method control block that links this
DD statement to the processing program. If no SYNAD exit is specified, the
system ignores the AMP SYNAD parameter.
TRACE=(subparameter[,subparameter]...)
Indicates that the generalized trace facility (GTF) executes with your job to
gather information about the opening, closing, and end-of-volume processing for
the data set defined on this DD statement. You can use the interactive problem
control system to print the trace output; see z/OS MVS IPCS User’s Guide.
The TRACE subparameters are: HOOK, ECODE, KEY, PARM1, and PARM2.
See z/OS DFSMS: Using Data Sets for full information on the TRACE
subparameter and the VSAM trace facility, which you use to obtain diagnostic
information during VSAM processing.
ACCBIAS=USER
ACCBIAS=SYSTEM
ACCBIAS=DO
ACCBIAS=DW
ACCBIAS=SO
ACCBIAS=SW
Specify one of these six values to override record access bias in the data class
in order to use System-Managed Buffering (SMB) without changing the data
class. See OFSMS/MVS Using Data Sets for details on System-Managed
Buffering.
USER
Obtain buffers the same way the system would without SMB. This is the
default if you code no specification for the ACCBIAS subparameter.
SYSTEM
Force SMB and let the system determine the buffering technique based on
the ACB MACRF and storage class specification.

Note: USER and SYSTEM are the only values you may use to specify
record access bias in the data class.
DO
SMB with direct optimization.
DW
SMB weighted for direct processing.
This option provides the capability to use hiperspace.
SO
SMB with sequential optimization.
SW
SMB weighted for sequential processing.
SMBDFR=Y or SMBDFR=N
With direct optimization, use this subparameter to instruct VSAM whether to
defer writing of changed buffers to the medium until either the data set is closed

12-28 z/OS V1R3.0 MVS JCL Reference

 DD: AMP
or the buffers are required for some other request. See OFSMS/MVS Using
Data Sets for further details on using SMBDFR.
SMBHWT=nn
Specify a requirement for hiperspace where nn is an integer from 0 to 99. Use
this parameter with direct optimization. The default value is 0, which means that
the system does not obtain any hiperspace.
SMBVSP=nnK or SMBVSP=nnM
Specify the amount of virtual buffer space to acquire for direct optimized
processing when opening the data set, where nn is 1 to 2048000 kilobytes or 1
to 2048 megabytes.
RMODE31=ALL
RMODE31=BUFF
RMODE31=CB
RMODE31=NONE
Designate the residency for buffers and control blocks.
This subparameter allows you to specify whether or not to allocate the buffers
and control blocks in 31-bit addressable storage. You can use this field
independently of SMB. With SMB the default location is in 31-bit addressable
storage (″above the 16-megabyte line″). Without SMB, the default is in 24-bit
addressable storage (″below the line″).
The values you may specify for RMODE31 are:
ALL —Control blocks and buffers above the line.
BUFF —Buffers (only) above the line.
CB —Control blocks (only) above the line.
NONE —Control blocks and buffers below the line.

When you do not specify ACCBIAS, or when you specify ACCBIAS=USER, if

you specify nothing for RMODE31 in either the JCL or the ACB, the system
obtains the buffers and control blocks in virtual storage with a 24-bit address.

When ACCBIAS=SYSTEM, if you specify nothing for RMODE31 in either the

JCL or the ACB, the system obtains the buffers in storage with an address
greater than 16 million bytes.

When you specify CB or NONE for RMODE31, the system obtains the buffers
in 24-bit addressable storage.

When you specify BUFF or NONE for RMODE31, the system obtains the
control blocks in 24-bit addressable storage.

If your program runs in 24-bit mode and you use locate mode processing for
the VSAM data set, you must obtain the buffers in 24-bit addressable storage.

Note: If your program runs with local or global shared resources (LSR/GSR)
and uses journaling (JRNAD) or user processing (UPAD) exit routines,
the exits must run in 31-bit mode if you obtained the control blocks
above the line.

This capability to allocate above the line is necessary when either or both of the
following conditions exists:
v The number of data sets open to a job is quite large.

Chapter 12. DD Statement 12-29

DD: AMP
v The number of buffers is such as to cause a storage shortage if kept in 24-bit
addressable storage.

You may specify RMODE31 only with the JCL DD AMP parameter or in the
ACB. The RMODE31 subparameter of AMP overrides any RMODE31 values
specified in the ACB.

The RMODE31 subparameter is available for all data set types.

Relationship to Other Parameters

Do not code the following parameters with the AMP parameter.

* DDNAME RECFM
BURST DYNAM SUBSYS
CHARS FCB SYSOUT
COPIES FLASH TERM
DATA MODIFY UCS
DCB QNAME

Invalid ddnames

The following ddnames are invalid for VSAM data sets:

JOBLIB
STEPLIB
SYSABEND
SYSCHK
SYSCKEOV
SYSMDUMP
SYSUDUMP

Invalid DSNAMEs

When you code the AMP parameter, the DSNAME must not contain parentheses, a
minus (hyphen), or a plus (+) sign. The forms of DSNAME valid for ISAM,
partitioned access method (PAM), and generation data groups (GDG) are invalid
with VSAM data sets.

Buffer Requirements
For a key-sequenced data set, the total minimum buffer requirement is three: two
data buffers and one index buffer. For an entry-sequenced data set, two data
buffers are required.

If the number of buffers specified in the BUFND and BUFNI subparameters causes
the virtual storage requirements to exceed the BUFSP space, the number of buffers
is reduced to fit in the BUFSP space.

If BUFSP specifies more space than required by BUFND and BUFNI, the number of
buffers is increased to fill the BUFSP space.

Examples of the AMP Parameter

Example 1

12-30 z/OS V1R3.0 MVS JCL Reference

 DD: AMP
//VSAMDS1 DD DSNAME=DSM.CLASS,DISP=SHR,AMP=(’BUFSP=200,BUFND=2’,
// ’BUFNI=3,STRNO=4,SYNAD=ERROR’)

In this example, the DD statement defines the size of the user area for data and
index buffers, specifies the number of data and index buffers, specifies the number
of requests that require concurrent data set positioning, and specifies an error exit
routine named ERROR.

Example 2
//VSAMDS2 DD DSNAME=DSM.CLASS,DISP=SHR,AMP=(’BUFSP=23456,BUFND=5’,
// ’BUFNI=10,STRNO=6,SYNAD=ERROR2,CROPS=NCK’,
// ’TRACE=(PARM1=F00203000010,KEY=ABCDEF)’)

In this example, the DD statement defines the values for BUFSP, BUFNI, STRNO,
and SYNAD, as in the previous example. It also specifies that a data set
post-checkpoint modification test is not to be performed when restarting at a
checkpoint and that GTF is to provide a trace of specified data areas.

AVGREC Parameter
Parameter Type

Keyword, optional — use this parameter only with SMS

Purpose

Use the AVGREC parameter when you define a new data set to specify that:
v The units of allocation requested for storage space are records.
v The primary and secondary space quantity specified on the SPACE parameter
represents units, thousands, or millions of records.

When you use AVGREC with the SPACE parameter, the first subparameter (reclgth)
on the SPACE parameter must specify the average record length of the records.

Code the AVGREC parameter when you want to (1) specify records as the units of
allocation or (2) override the space allocation defined in the data class for the data
set.

If SMS is not installed or is not active, the system checks the syntax and then
otherwise ignores the AVGREC parameter.

Syntax
AVGREC= {U}
{K}
{M}

Subparameter Definition
U Specifies a record request and that the primary and secondary space quantity
specified on the SPACE parameter represents the number of records in units
(multiplier of 1).

Chapter 12. DD Statement 12-31

DD: AVGREC
K Specifies a record request and that the primary and secondary space quantity
specified on the SPACE parameter represents the number of records in
thousands (multiplier of 1024).
M Specifies a record request and that the primary and secondary space quantity
specified on the SPACE parameter represents the number of records in millions
(multiplier of 1048576).

Overrides
AVGREC overrides the space allocation defined in the DATACLAS parameter for
the data set. See “Overrides” on page 12-52.

Relationship to Other Parameters

Do not code AVGREC with the TRK, CYL, or ABSTR subparameters of the SPACE
parameter.

Do not code the following DD parameters with the AVGREC parameter.

* DYNAM
DATA QNAME
DDNAME

Examples of the AVGREC Parameter

Example 1
//SMSDS3 DD DSNAME=MYDS3.PGM,DATACLAS=DCLAS03,DISP=(NEW,KEEP),
// SPACE=(128,(5,2)),AVGREC=K

In the example, the space allocation defined in the DCLAS03 data class is
overridden by the SPACE and AVGREC parameters, which indicate an average
record length of 128 bytes, a primary quantity of 5K (5,120) records, and a
secondary quantity of 2K (2,048) records.

Example 2
//SMSDS3A DD DSNAME=MYDS3.PGM,DATACLAS=DCLAS03A,DISP=(NEW,KEEP),
// AVGREC=K

In the example, the space allocation defined in the DCLAS03A data class is
overridden by the AVGREC parameter, which indicates that the primary and
secondary quantity represents thousands of records.

BLKSIZE Parameter
Parameter Type

Keyword, optional

Purpose

Code the BLKSIZE parameter to specify the maximum length of a block.

12-32 z/OS V1R3.0 MVS JCL Reference

 DD: BLKSIZE
Syntax
BLKSIZE= {value}
{valueK}
{valueM}
{valueG}

Subparameter Definition
value
Specifies the maximum length, in bytes, of a block.
The number of bytes that you specify for BLKSIZE depends on the device type
and the record format for the data set. The maximum is 32,760 for DASD data
sets and 2,147,483,648 for tape, except for data sets on magnetic tape with
ISO/ANSI Version 3 labels, where the minimum value for BLKSIZE is 18 bytes
and the maximum is 2048 bytes. To allow a block size greater than 2048, use
installation exit routine IFG0193G, described in z/OS DFSMS Installation Exits.
valueK
Specifies the maximum length, in kilobytes, of a block. (1 kilobyte = 1024
bytes.) The maximum is 2097152. If you code 2097152K, the block size is the
maximum: 2,147,483,648 bytes.
valueM
Specifies the maximum length, in megabytes, of a block. (1 megabyte = 1024
kilobytes.) The maximum is 2048. If you code 2048M, the block size is the
maximum: 2,147,483,648 bytes.
valueG
Specifies the maximum length, in gigabytes, of a block. (1 gigabyte = 1024
megabytes.) The maximum is 2G. If you code 2G, the block size assigned is
the maximum: 2,147,483,648 bytes.

Defaults
If you do not code BLKSIZE, the system can, under certain conditions, determine
an optimum block size. For detailed information about system-determined block
size, see z/OS DFSMS: Using Data Sets.

Overrides
If you code a non-zero value for the BLKSIZE subparameter on a DCB or DCBE
macro instruction or on a DD statement that defines an existing data set with
standard labels, the DCB or DCBE BLKSIZE overrides the block size specified in
the label.

Relationship to Other Control Statements

Do not code the BLKSIZE parameter with the DCB subparameter BUFSIZE.

If you code BLKSIZE it will have no effect on EXCP processing unless the
application takes special steps to use it. (For information about EXCP processing
see z/OS DFSMSdfp Advanced Services.)

Chapter 12. DD Statement 12-33

 DD: BLKSIZE
Coexistence Considerations
Not all programs and operating systems prior to z/OS can read blocks longer than
32,760 bytes. For example, Version 2 Release 10 is the first release of OS/390 that
can read such long blocks using standard access methods.

Examples of the BLKSIZE Parameter

//DD1B DD DSNAME=EVER,DISP=(NEW,KEEP),UNIT=3380,
// RECFM=FB,LRECL=326,BLKSIZE=23472,
// SPACE=(23472,(200,40))

DD statement DD1B defines a new data set named EVER on a 3380. The DD
keywords RECFM, LRECL, and BLKSIZE contain the information necessary to
complete the data control block.
| //DD2B DD DSNAME=NEVER,DISP=(NEW,KEEP),UNIT=3590,
| // RECFM=FB,LRECL=256,BLKSIZE=204K

| DD statement DD2B defines a new data set named NEVER on a 3590. The DD
| keywords RECFM, LRECL, and BLKSIZE contain the information necessary to
| complete the data control block. The block size, which in this example is 204 x
| 1024 = 208,896 bytes, must be divisible by the logical record length, and each
| program that reads or writes this data set must be capable of handling block sizes
| this large.

BLKSZLIM Parameter
Keyword, optional

Purpose

Use the BLKSZLIM parameter to specify an upper limit on a data set’s block size if
BLKSIZE is omitted from all sources and the system determines the block size for
the data set. If a BLKSIZE value is available from any source (such as the DD
statement, data set label, or the program), then the block size limit has no effect.
The BLKSZLIM parameter is useful mainly when writing new magnetic tape data
sets with programs that can handle blocks longer than 32,760 bytes. Currently the
maximum block size supported on any tape is 256 KB. You can safely code a larger
value for BLKSZLIM. The BLKSZLIM value does not have to be a multiple of the
LRECL value. For more information, see z/OS DFSMS: Using Data Sets.

Syntax
BLKSZLIM= {value}
{valueK}
{valueM}
{valueG}

Subparameter Definition
value
Specifies in bytes an upper limit on a data sets’s block size if BLKSIZE is
omitted from all sources and the system determines the block size for the data
set. The maximum value is 2,147,483,648 bytes (two gigabytes). The minimum
value is 32K (32,768 bytes).

12-34 z/OS V1R3.0 MVS JCL Reference

 DD: BLKSZLIM
valueK
Specifies the block size limit in kilobytes (units of 1024). The maximum value is
2,097,152K (two gigabytes). The minimum value is 32K.
valueM
Specifies the block size limit in megabytes (units of 1024K). The maximum
value is 2048M (two gigabytes). The minimum value is 1M.
valueG
Specifies the block size limit in gigabytes (units of 1024M). The maximum
allowable value is 2G (two gigabytes). The minimum value is 1G.

Defaults
If you omit BLKSZLIM, the system determines the block size from one of the
following sources, starting with the first:
1. Data class
2. DEVSUPxx value
3. 32,768

Relationship to Other Parameters

The system ignores BLKSZLIM when you specify BLKSIZE.

Example of the BLKSZLIM Parameter

//DD1BB DD DSNAME=EVER,DISP=(NEW,KEEP),UNIT=3390,
// RECFM=FB,LRECL=326,BLKSZLIM=32760,
// SPACE=(23472,(200,40))

DD statement DD1B defines a new data set named EVER on a 3390 DASD. The
DD keywords RECFM and LRECL contain the information necessary to complete
the data control block. BLKSZLIM places an upper limit on the block size to be
determined by the system.
//DD2B DD DSNAME=NEVER,DISP=(NEW,KEEP),UNIT=3590,
// RECFM=FB,LRECL=80,BLKSZLIM=40K

DD statement DD2B defines a new data set named NEVER on a 3590 TAPE
device. The DD keywords RECFM and LRECL contain the information necessary to
complete the data control block. BLKSZLIM places an upper limit on the block size
to be determined by the system.

BURST Parameter
Keyword, optional

Purpose

Use the BURST parameter to specify that the output for this sysout data set printed
on a 3800 Printing Subsystem is to go to:
v The burster-trimmer-stacker, to be burst into separate sheets.
v The continuous forms stacker, to be left in continuous fanfold.

If the specified stacker is different from the last stacker used, or if a stacker was not
previously requested, JES issues a message to the operator to thread the paper
into the required stacker.

Chapter 12. DD Statement 12-35

DD: BURST
Note: BURST applies only for an output data set printed on a 3800 equipped with
a burster-trimmer-stacker.

Syntax
BURST= {YES}
{Y }
{NO }
{N }

Subparameter Definition
YES
Requests that the printed output is to be burst into separate sheets. This
subparameter can also be coded as Y.
NO
Requests that the printed output is to be in a continuous fanfold. This
subparameter can also be coded as N.

Defaults
If you do not code a BURST parameter, but you code a DD SYSOUT parameter
and the sysout data set is printed on a 3800 that has a burster-trimmer-stacker,
JES uses an installation default specified at initialization.

If you do not code a BURST parameter or a DD SYSOUT parameter, the default is

NO.

Overrides
A BURST parameter on a sysout DD statement overrides an OUTPUT JCL BURST
parameter.

Relationship to Other Parameters

Do not code the following parameters with the BURST parameter.

* DISP PROTECT
AMP DSID QNAME
DATA DYNAM SUBSYS
DDNAME LABEL VOLUME

Relationship to Other Control Statements

The burster-trimmer-stacker can also be requested using the following:
v The BURST parameter on the OUTPUT JCL statement.
v The STACKER parameter on the JES3 //*FORMAT PR statement.
v The BURST parameter on the JES2 /*OUTPUT statement.

Example of the BURST Parameter

//RECORD DD SYSOUT=A,BURST=Y

In this example, the DD statement requests that JES send the output to the
burster-trimmer-stacker of the 3800. The stacker separates the printed output into
separate sheets instead of stacking it in a continuous fanfold.

12-36 z/OS V1R3.0 MVS JCL Reference

 DD: CCSID

CCSID Parameter
Parameter Type

Keyword, optional

Purpose

On systems with DFSMS/MVS Version 1 Release 5 or higher, and OS/390 Version

2 Release 5 or higher, you can request DFSMSdfp to convert data from/to the
coded character set identifier (CCSID) specified on the JOB or EXEC statement
to/from the CCSID specified on the DD statement. Data conversion is supported on
access to ISO/ANSI Version 4 tapes using access methods BSAM or QSAM, but
not using EXCP.

ISO/ANSI Version 4 tapes are identified by the LABEL=(,AL) or LABEL=(,AUL)

keyword. The CCSID parameter does not apply to ISO/ANSI Version 1 or
ISO/ANSI/FIPS Version 3 tapes or to tapes with labels other than AL or AUL. See
z/OS DFSMSdfp Storage Administration Reference and z/OS DFSMS: Using Data
Sets for selecting ISO/ANSI Version 4 tapes. See the latter manual for a list of
supported CCSIDs.

The CCSID value of 65535 has a special meaning: it suppresses conversion.

When CCSID is not specified at the JOB, EXEC, or DD levels, data passed to
BSAM and QSAM is converted to 7-bit ASCII when writing to ISO/ANSI Version 4
tapes. This may result in data loss on conversion. On READ operations the CCSID
(if recorded) on the tape header label is used for conversion.

The CCSID is recorded in the tape header label if conversion is not defaulted.

Syntax
CCSID= nnnnn

Subparameter Definition
nnnnn
The CCSID as a decimal number from 1 through 65535.

Default
367.

Relationship to Other Parameters

Do not code the following parameters with the CCSID parameter:

* DDNAME QNAME
BURST DYNAM SYSOUT
CHARS FCB TERM
COPIES FLASH UCS
DATA MODIFY

Chapter 12. DD Statement 12-37

DD: CCSID
Examples of the CCSID Parameter
Example 1
//JOB1 JOB (123456)
//S1 EXEC PGM=MYPGM
//DD1 DD DSN=A,DISP=NEW,UNIT=3590,
// VOL=SER=T00001,LABEL=AL

In this example, the data on the new ISO/ANSI tape is converted from EBCDIC to
7-bit ASCII because CCSID was not specified at the JOB, EXEC, or DD levels. If
the data passed to the access methods contain graphic or special characters there
could be data loss on conversion to 7-bit ASCII. This is the default operation for
ISO/ANSI/FIPS Version 3 and ISO/ANSI Version 4 tapes.

Example 2
//JOB2 JOB (123456)
//S1 EXEC PGM=MYPGM
//DD1 DD DSN=A,DISP=OLD,UNIT=3590,
// VOL=SER=T00001,LABEL=AL

In this example the data on the ISO/ANSI tape is converted from 7-bit ASCII
(default) to EBCDIC. This is the default operation for ISO/ANSI/FIPS Version 3 and
ISO/ANSI Version 4 tapes.

Example 3
//JOB3 JOB (123456)
//S1 EXEC PGM=MYPGM
//DD1 DD DSN=A,DISP=NEW,UNIT=3590,
// CCSID=65535,VOL=SER=T00003,LABEL=AL

In this example the data written to the ISO/ANSI Version 4 tape is not converted
(CCSID=65535).

Example 4
//JOB4 JOB (123456)
//S1 EXEC PGM=MYPGM
//DD1 DD DSN=A,DISP=OLD,UNIT=3590,
// CCSID=65535,VOL=SER=T00004,LABEL=AL

In this example the user did not want any conversion (CCSID=65535) on data read
by the access methods.

Example 5
//JOB5 JOB (123456),CCSID=37
//S1 EXEC PGM=MYPGM1
//DD1 DD DSN=A,DISP=NEW,LABEL=(,AL),
// VOL=SER=T00005,UNIT=3590,CCSID=437

In this example the user wants conversion from a CCSID of 37 (CECP: USA,
Canada, Netherlands, Portugal, Brazil, Australia, New Zealand) to 437 (Base
PC-data) for data written using BSAM or QSAM for ISO/ANSI Version 4 tape. The
CCSID of 437 is recorded on the tape header label.

Example 6
//JOB6 JOB (123456),CCSID=37
//S1 EXEC PGM=MYPGM2
//DD1 DD DSN=A,DISP=OLD,UNIT=3590,
// VOL=SER=T00006,CCSID=437

12-38 z/OS V1R3.0 MVS JCL Reference

 DD: CCSID
In this example the user wants data conversion from a CCSID of 437 to a CCSID of
37 for data read by the access method. Note that the CCSID does not have to be
specified if it is recorded in the label.

Example 7
//JOB7 JOB (123456),CCSID=37
//S1 EXEC PGM=MYPGM
//DD1 DD DSN=A,DISP=OLD,UNIT=3590,
// VOL=SER=T00007

In this example the ISO/ANSI labeled tape had a recorded CCSID of 437 and a
CCSID was not specified on the DD statement. Data read from this tape by the
access method is converted from a CCSID of 437 to a CCSID of 37.

Example 8
//JOB8 JOB (123456),CCSID=37
//S1 EXEC PGM=MYPGM1
//DD1 DD DSN=A,DISP=NEW,LABEL=(,AL),UNIT=3590,
// VOL=SER=T00008,CCSID=437
//S2 EXEC PGM=MYPGM2,CCSID=65535
//DD1 DD DSN=B,DISP=NEW,LABEL=(,AL),UNIT=3590,
// VOL=SER=T00009

This example illustrates overriding the CCSID specified on the JOB statement by
the specification on the EXEC statement.

In this example, in step S1 the user wants conversion from a CCSID of 37 to 437
for data written using BSAM or QSAM for the ISO/ANSI Version 4 tape.

In step S2 the JOB level CCSID of 37 is overridden by the EXEC level CCSID of
65535. Since a CCSID of 65535 prevents conversion, the data written to tape is not
converted. A CCSID of 65535 is recorded in the tape header label because no
CCSID was specified on the DD statement.

CHARS Parameter
Parameter Type

Keyword, optional

Purpose

Use the CHARS parameter to specify the name of one or more

character-arrangement tables for printing this sysout data set on a 3800 Printing
Subsystem.

Note: CHARS applies only for an output data set that is printed on a 3800.

References

For more information on character-arrangement tables, see the 3800 Programmer’s

Guide. Refer to SMP/E User’s Guide for information on choosing particular groups,
other than the Basic group (which is always available), during system initialization.

Chapter 12. DD Statement 12-39

DD: CHARS
Syntax
CHARS= {table-name }
{(table-name[,table-name]...)}
{DUMP }
{(DUMP[,table-name]...) }

v You can omit the parentheses if you code only one table-name or only DUMP.
v Null positions in the CHARS parameter are invalid. For example, you cannot code
CHARS=(,table-name) or CHARS=(table-name,,table-name).

Subparameter Definition
table-name
Names a character-arrangement table. Each table-name is 1 through 4
alphanumeric or national ($, #, @) characters. Code from one to four names.
DUMP
Requests a high-density dump of 204-character print lines from a 3800. If more
than one table-name is coded, DUMP must be first.

Note: Use DUMP on a SYSABEND or SYSUDUMP DD statement.

Defaults
If you do not code the DD CHARS parameter, JES uses the following, in order:
1. The CHARS parameter on an OUTPUT JCL statement, if referenced by the DD
statement.
2. The DD UCS parameter value, if coded.
3. The UCS parameter on an OUTPUT JCL statement, if referenced.

If no character-arrangement table is specified on the DD or OUTPUT JCL

statements, JES uses an installation default specified at initialization.

Overrides
A CHARS parameters on a sysout DD statement overrides the OUTPUT JCL
CHARS parameter.

For a data set scheduled to the Print Services Facility (PSF), the PSF uses the
following parameters, in override order, to select the font list:
1. Font list in the library member specified by an OUTPUT JCL PAGEDEF
parameter.
2. DD CHARS parameter.
3. OUTPUT JCL CHARS parameter.
4. DD UCS parameter.
5. OUTPUT JCL UCS parameter.
6. JES installation default for the device.
7. Font list on the PAGEDEF parameter in the PSF cataloged procedure.

See “PAGEDEF Parameter” on page 22-63 for more information.

12-40 z/OS V1R3.0 MVS JCL Reference

 DD: CHARS
Relationship to Other Parameters
Do not code the following parameters with the CHARS parameter.

* DISP PROTECT
AMP DSID QNAME
DATA DYNAM SUBSYS
DDNAME LABEL VOLUME

Relationship to Other Control Statements

CHARS can also be coded on the following:
v The OUTPUT JCL statement.
v The JES3 //*FORMAT PR statement.
v The JES2 /*OUTPUT statement.

Printing Device Reassignment

The output device might not be a 3800, for example, if printing were reassigned to
a 3211. See the 3800 Programmer’s Guide for restrictions that apply.

Requesting a High-Density Dump

You can request a high-density dump on the 3800 through two parameters on the
DD statement for the dump data set or on an OUTPUT JCL statement referenced
by the dump DD statement:
v FCB=STD3. This parameter produces dump output at 8 lines per inch.
v CHARS=DUMP. This parameter produces 204-character print lines.

You can code one or both of these parameters. You can place both on the same
statement or one on each statement.

Examples of the CHARS Parameter

Example 1
//DD1 DD SYSOUT=A,CHARS=(GS10,GU12)

In this example, the CHARS parameter specifies two character-arrangement tables

to be used when printing the data set: GS10 and GU12.

Example 2
//SYSABEND DD UNIT=3800,CHARS=DUMP,FCB=STD3

The CHARS parameter on this SYSABEND DD statement specifies a high-density

dump with 204 characters per line. The FCB parameter requests the dump output
at 8 lines per inch.

CHKPT Parameter
Parameter Type

Keyword, optional

Purpose

Use the CHKPT parameter to request that a checkpoint be written when each
end-of-volume is reached on the multivolume data set defined by this DD

Chapter 12. DD Statement 12-41

DD: CHKPT
statement. Checkpoints are written for all volumes except the last. Checkpoints can
be requested for input or output data sets.

Note: CHKPT is supported only for multivolume QSAM or BSAM data sets. CHKPT
is ignored for single-volume QSAM or BSAM data sets or for ISAM, BDAM,
BPAM, or VSAM data sets. CHKPT is not supported for partitioned data sets
extended (PDSEs).

References

For more information, see z/OS DFSMS Checkpoint/Restart.

Syntax
CHKPT=EOV

Subparameter Definition
EOV
Requests a checkpoint at each end-of-volume.

Overrides
v The RD parameter values of NC and RNC on the JOB or EXEC statements
override the CHKPT parameter.
v The CHKPT parameter overrides cataloged procedure values or START
command values for checkpoints at end-of-volume.

Relationship to Other Parameters

Do not code the following parameters with the CHKPT parameter.

* DYNAM
DATA QNAME
DDNAME SYSOUT

Relationship to the SYSCKEOV DD Statement

If you specify CHKPT, you must also provide a SYSCKEOV DD statement in the job
or step.

Checkpointing Concatenated Data Sets

For concatenated BSAM or QSAM data sets, CHKPT must be coded on each DD
statement in the concatenation, if checkpointing is desired for each data set in the
concatenation.

Examples of the CHKPT Parameter

Example 1
//DS1 DD DSNAME=INDS,DISP=OLD,CHKPT=EOV,
// UNIT=SYSSQ,VOLUME=SER=(TAPE01,TAPE02,TAPE03)

12-42 z/OS V1R3.0 MVS JCL Reference

 DD: CHKPT
In this example, the DD statement defines data set INDS, a multivolume QSAM or
BSAM data set for which a checkpoint is to be written twice: once when
end-of-volume is reached on TAPE01 and once when end-of-volume is reached on
TAPE02.

Example 2
//DS2 DD DSNAME=OUTDS,DISP=(NEW,KEEP),
// CHKPT=EOV,UNIT=SYSDA,VOLUME=(,,,8)

In this example, OUTDS is a multivolume data set that is being created. The data
set requires eight volumes. Seven checkpoints will be written: when the
end-of-volume is reached on volumes one through seven.

CNTL Parameter
Parameter Type

Keyword, optional

Purpose

Use the CNTL parameter to reference a CNTL statement that appears earlier in the
job. The reference causes the subsystem to execute the program control
statements within the referenced CNTL/ENDCNTL group.

The system searches for an earlier CNTL statement with a label that matches the
label in the CNTL parameter. If the system finds no match, the system issues an
error message.

Syntax
CNTL= {*.label }
{*.stepname.label }
{*.stepname.procstepname.label}

Subparameter Definition
*.label
Identifies an earlier CNTL statement, named label. The system searches for the
CNTL statement first earlier in this step, then before the first EXEC statement of
the job.
*.stepname.label
Identifies an earlier CNTL statement, named label, that appears in an earlier
step, stepname, in the same job.
*.stepname.procstepname.label
Identifies a CNTL statement, named label, in a cataloged or in-stream
procedure. Stepname is the name of the job step that calls the procedure;
procstepname is the name of the procedure step that contains the CNTL
statement named label.

Examples of the CNTL Parameter

Example 1
//MONDAY DD CNTL=*.WKLYPGM

Chapter 12. DD Statement 12-43

DD: CNTL
In this example, the DD statement requests that the system use the program control
statements following the CNTL statement named WKLYPGM and located earlier in
this step or preceding the first step.

Example 2
//TUESDAY DD CNTL=*.SECOND.BLOCKS

In this example, the DD statement requests that the system use the program control
statements following the CNTL statement named BLOCKS and located in a
preceding step named SECOND.

Example 3
//WEDNES DD CNTL=*.THIRD.PROCTWO.CANETTI

In this example, the DD statement requests that the system use the program control
statements following the CNTL statement named CANETTI and located in the
procedure step PROCTWO of the procedure called in the preceding job step
THIRD.

COPIES Parameter
Parameter Type

Keyword, optional

Purpose

Use the COPIES parameter to specify how many copies of this sysout data set are
to be printed. The printed output is in page sequence for each copy.

For printing on a 3800 Printing Subsystem, this parameter can instead specify how
many copies of each page are to be printed before the next page is printed.

Note: For more information about the subparameters supported for the 3800
printer, see PSF/MVS Application Programming Guide.

Syntax
COPIES= {nnn }
{(nnn,(group-value[,group-value]...))}
{(,(group-value[,group-value]...)) }

v You can omit the parentheses if you code only COPIES=nnn.

v The following are not valid:
– A null group-value, for example, COPIES=(5,(,)) or COPIES=(5,)
– A zero group-value, for example, COPIES=(5,(1,0,4))
– A null within a list of group-values, for example, COPIES=(5,(1,,4))

Subparameter Definition
nnn
A number (from 1 through 255 in a JES2 system, from 1 through 254 in a JES3
system) that specifies how many copies of the data set are to be printed.

12-44 z/OS V1R3.0 MVS JCL Reference

 DD: COPIES
For a data set printed on a 3800, JES ignores nnn if any group-values are
specified.
group-value
Specifies how many copies of each page are to be printed before the next page
is printed. Each group-value is a number from 1 through 255 in a JES2 system
and from 1 through 254 in a JES3 system. You can code a maximum of eight
group-values. Their sum must not exceed 255 or 254. The total copies of each
page equals the sum of the group-values.

Defaults
On any of the following statements, if you do not code a COPIES parameter, code it
incorrectly, or code COPIES=0, the system uses the DD COPIES parameter default
of 1.
DD statement
OUTPUT JCL statement
For JES2, the /*OUTPUT statement

Overrides
A COPIES parameter on a sysout DD statement overrides an OUTPUT JCL
COPIES parameter.

If this DD statement references an OUTPUT JCL statement and that OUTPUT JCL
statement contains a FORMDEF parameter, which specifies a library member, the
COPYGROUP parameter on a FORMDEF statement in that member overrides any
group-value subparameters on the OUTPUT JCL COPIES parameter or the sysout
DD COPIES parameter. For more information, see “FORMDEF Parameter” on
page 22-42.

Relationship to Other Parameters

Do not code the following parameters with the COPIES parameter.

* DISP QNAME
AMP DYNAM SUBSYS
DATA LABEL VOLUME
DDNAME

Relationship to FLASH Parameter

If this DD statement or a referenced OUTPUT JCL statement also contains a

FLASH parameter, JES prints with the forms overlay the number of copies specified
in one of the following:
v COPIES=nnn, if the FLASH count is larger than nnn. For example, if COPIES=10
and FLASH=(LTHD,12) JES prints 10 copies, all with the forms overlay.
v The sum of the group-values specified in the COPIES parameter, if the FLASH
count is larger than the sum. For example, if COPIES=(,(2,3,4)) and
FLASH=(LTHD,12) JES prints nine copies in groups, all with the forms overlay.
v The count subparameter in the FLASH parameter, if the FLASH count is smaller
than nnn or the sum from the COPIES parameter. For example, if COPIES=10
and FLASH=(LTHD,7) JES prints seven copies with the forms overlay and three
copies without.

Restriction When Coding UNIT Parameter

Chapter 12. DD Statement 12-45

DD: COPIES
The COPIES parameter is normally coded with the SYSOUT parameter. If,
however, both COPIES and UNIT appear on a DD statement, JES handles the
COPIES parameter as follows:
v nnn defaults to 1.
v Only the first group-value is used, if group-values are specified and printing is on
a 3800.

Relationship to Other Control Statements

The number of copies can also be specified on the COPIES parameter of the
following:
v The OUTPUT JCL statement.
v The JES2 /*OUTPUT statement.
v The JES3 //*FORMAT PR statement.
v The JES3 //*FORMAT PU statement.

For JES2, if you request copies of the entire job on the JES2 /*JOBPARM COPIES
parameter and also copies of the data set on the DD COPIES or OUTPUT JCL
COPIES parameter, and if this is a sysout data set, JES2 prints the number of
copies equal to the product of the two requests.

Using OUTPUT JCL COPIES by Nullifying DD Copies

If both a DD statement and a referenced OUTPUT JCL statement contain COPIES
parameters, the DD COPIES parameter normally overrides the OUTPUT JCL
COPIES parameter. For example, four copies are printed of sysout data set DDA:
//OTA OUTPUT COPIES=3
//DDA DD SYSOUT=A,OUTPUT=*.OTA,COPIES=4

However, if the DD COPIES is a null parameter, the OUTPUT JCL COPIES

parameter is used. For example, three copies are printed of sysout data set DDB:
//OTB OUTPUT COPIES=3
//DDB DD SYSOUT=A,OUTPUT=*.OTB,COPIES=

The following example shows a null COPIES parameter on an in-stream DD

statement that overrides a procedure DD statement. The null COPIES parameter on
DD statement PS.DDA nullifies the COPIES parameter on the procedure DD
statement DDA, thereby allowing the COPIES parameter on OUTPUT JCL
statement OT to be used. The system prints three copies of the DDA sysout data
set.
//JEX JOB ACCT34,’PAUL BENNETT’
//INSTR PROC
//PS EXEC PGM=ABC
//OT OUTPUT COPIES=3
//DDA DD SYSOUT=A,OUTPUT=*.OT,COPIES=2
// PEND
//STEP1 EXEC PROC=INSTR
//PS.DDA DD COPIES=
/*

Note: If a null COPIES parameter appears on a DD statement that either does not
reference an OUTPUT JCL statement or references an OUTPUT JCL
statement that does not contain a COPIES parameter, the system uses a
default of 1.

Examples of the COPIES Parameter

Example 1
//RECORD1 DD SYSOUT=A,COPIES=32

12-46 z/OS V1R3.0 MVS JCL Reference

 DD: COPIES
This example requests 32 copies of the data set defined by DD statement
RECORD1 when printing on an impact printer or a 3800.

Example 2
//RECORD2 DD SYSOUT=A,COPIES=(0,(1,2))

In this example, when printing on a 3800, three copies of the data set are printed in
two groups. The first group contains one copy of each page. The second group
contains two copies of each page. When printing on an impact printer, one copy
(the default for nnn) is printed.

Example 3
//RECORD3 DD SYSOUT=A,COPIES=(8,(1,3,2))

In this example, when printing on a 3800, six copies of the data set are printed in
three groups. The first group contains one copy of each page, the second group
contains three copies of each page, and the last group contains two copies of each
page. When the output device is not a 3800, the system prints eight collated copies.

Example 4
//RECORD4 DD UNIT=3800,COPIES=(1,(2,3))

Because the UNIT parameter is coded and the device is a 3800, the system prints
only the first group-value: two copies of each page.

DATA Parameter
Parameter Type

Positional, optional

Purpose

Use the DATA parameter to begin an in-stream data set that may contain
statements with // in columns 1 and 2. The data records immediately follow the DD
DATA statement; the records may be in any code, such as EBCDIC. The data
records end when:
v An EBCDIC /* or the two-character delimiter specified by a DLM parameter on
this DD statement is found in the input stream, or
v The input stream runs out of card images.

Note that, unlike a DD * statement, the data is not ended by the // that indicates
another JCL statement.

Considerations for an APPC Scheduling Environment

The DATA parameter has no function in an APPC scheduling environment. If you

code DATA, the system will check it for syntax and ignore it.

Syntax
//ddname DD DATA[,parameter]... [comments]

Chapter 12. DD Statement 12-47

DD: DATA
Defaults
When you do not code BLKSIZE and LRECL, JES uses installation defaults
specified at initialization.

Relationship to Other Parameters

The following DD parameters may be specified with the DD * and DD DATA
parameters. All other parameters are either ignored or result in a JCL error.

DCB=BLKSIZE DSNAME
DCB=BUFNO LIKE
DCB=LRECL LRECL
DCB=DIAGNS REFDD
DCB=MODE=C VOLUME=SER
DLM DSID

For JES3, when using the DCB=MODE=C subparameter with the DATA parameter,
DCB=MODE=C must be the only parameter specified with the DATA parameter.

You cannot use the TSO/E SUBMIT command to submit a data set to JES2 or
JES3 with a record length of greater than 80 bytes. The records are truncated to 80
bytes.

You can submit a data set to JES2 or JES3 with a record length of greater than 80
bytes by submitting JCL like the following. In this example JCL,
IBMUSER.LONGDATA.JCL contains the data with a record length of greater than
80 bytes. In a JES3 system, the record length is limited to the installation-defined
spool buffer size minus 44. (For example, if the buffer size is defined as 4084, the
record length limit is 4040.) JES3 input service fails any job that exceeds this limit.

If the records longer than 80 bytes include JCL to be transmitted to a remote

system using JES3 // XMIT or //*ROUTE XEQ, or JES2 /*ROUTE XEQ or /*XMIT
with JES3 in the network, the records are truncated to 80 bytes.
//SUBMIT JOB ...
//S1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD SYSOUT=(,INTRDR)
//SYSUT1 DD DSN=IBMUSER.LONGDATA.JCL,DISP=SHR

For JES3 SNA RJP Input

v The only parameters you can specify for JES3 systems network architecture
(SNA) remote job processing (RJP) input devices are BLKSIZE and LRECL.
v Code DCB=LRECL=nnn, where nnn is 1 to 255 when SYSIN data records are
greater than 80 bytes. (The default LRECL is 80 bytes.)

For 3540 Diskette Input/Output Units

VOLUME=SER, BUFNO, and DSID on a DD DATA statement are ignored except

when they are detected by a diskette reader as a request for an associated data
set. See 3540 Programmer’s Reference. On a DD * or DD DATA statement
processed by a diskette reader, you can specify DSID and VOLUME=SER
parameters to indicate that a diskette data set is to be merged into the input stream
following the DD statement.

12-48 z/OS V1R3.0 MVS JCL Reference

 DD: DATA
Relationship to Other Control Statements
Do not refer to an earlier DD DATA statement in DCB, DSNAME, or VOLUME
parameters on following DD statements.

Location in the JCL

A DD DATA statement begins an in-stream data set.

In-stream Data for Cataloged or In-stream Procedures

A cataloged or in-stream procedure cannot contain a DD DATA statement. When

you call a procedure, you can add input stream data to a procedure step by placing
in the calling step one or more DD * or DD DATA statements, each followed by
data.

Multiple In-Stream Data Sets for a Step

You can code more than one DD * or DD DATA statement in a job step in order to
include several distinct groups of data for the processing program. Precede each
group with a DD * or DD DATA statement and follow each group with a delimiter
statement.

Omitted Data Delimiters

If you omit a DD statement before input data, the system provides a DD * statement
with the ddname of SYSIN and ends the data when it reads a JCL statement or
runs out of card images. If you omit a delimiter after input data, the system ends
the data when it reads a JCL statement or runs out of card images.

Unread Records
If the processing program does not read all the data in an in-stream data set, the
system skips the remaining data without abnormally terminating the step.

Examples of the DATA Parameter

Example 1
//GROUP1 DD DATA
.
.
data
.
/*
//GROUP2 DD DATA
.
.
data
.
/*

This example defines two groups of data in the input stream.

Example 2
//GROUP3 DD DATA,DSNAME=&&GRP3
.
.
data
.
/*

Chapter 12. DD Statement 12-49

DD: DATA
This example defines an in-stream data set with GRP3 as the last qualifier of the
system-generated data set name. A name such as
userid.jobname.jobid.Ddsnumber.GRP3 is generated.

Example 3
//STEP2 EXEC PROC=UPDATE
//PREP.DD4 DD DSNAME=A.B.C,UNIT=3350,VOLUME=SER=D88230,
// SPACE=(TRK,(10,5)),DISP=(,CATLG,DELETE)
//PREP.IN1 DD DATA
.
.
data
.
/*
//ADD.IN2 DD *
.
.
data
.
/*

This example defines two groups of data in the input stream. The input defined by
DD statement PREP.IN1 is to be used by the cataloged procedure step named
PREP. This data contains job control statements. The input data defined by DD
statement ADD.IN2 is to be used by the cataloged procedure step named ADD.
Because this data is defined by a DD * statement, it must not contain job control
statements.

DATACLAS Parameter
Parameter Type

Keyword, optional

This parameter is useful only if SMS is running. Without SMS, use the DCB
parameter (described on page 12-53) or the AMP parameter (described on page
12-23).

Purpose

Use the DATACLAS parameter to specify a data class for a new data set. The
storage administrator at your installation defines the names of the data classes you
can code on the DATACLAS parameter.

If SMS is not installed or is not active, the system syntax checks and then ignores
the DATACLAS parameter.

SMS ignores the DATACLAS parameter if you specify it for (1) an existing data set
or (2) a data set that SMS does not support.

You can use the DATACLAS parameter for both VSAM data sets and physical
sequential (PS) or partitioned (PO) data sets.

A data class defines the following data set allocation attributes:

v Data set organization
– Record organization (RECORG) or
– Record format (RECFM)
v Record length (LRECL)

12-50 z/OS V1R3.0 MVS JCL Reference

 DD: DATACLAS
v Key length (KEYLEN)
v Key offset (KEYOFF)
v Type, PDS or PDSE (DSNTYPE)
v Space allocation (AVGREC and SPACE)
v Retention period (RETPD) or expiration date (EXPDT)
v Volume-count (VOLUME)
v Compaction
v Media interchange type
v Space constraint relief
v Block size limit
v For VSAM data sets (IMBED or REPLICATE, CISIZE, FREESPACE,
SHAREOPTIONS, REUSE, INITIAL LOAD, SPANNED/NONSPANNED, BWO
(backup while open), and LOGGING OPTIONS)

Note

The volume-count on the VOLUME parameter in the data class specifies the
maximum number of SMS-managed volumes that a data set can span. The
volume-count is ignored for data sets to which no storage class is assigned.

For tape data sets, only the following attributes apply:

v EXPDT
v LRECL
v RECFM
v RETPD

References

See z/OS DFSMS: Using the Interactive Storage Management Facility for
information on how to use ISMF to view your installation-defined data classes.

Syntax
DATACLAS=data-class-name

Subparameter Definition
data-class-name
Specifies the name of a data class to be used for allocating the data set.
The name, one to eight characters, is defined by the storage administrator at
your installation.

Defaults
If you do not specify DATACLAS for a new data set and the storage administrator
has provided an installation-written automatic class selection (ACS) routine, the
ACS routine may select a data class for the data set. Check with your storage
administrator to determine if an ACS routine will select a data class for the new
data set, in which case you do not need to specify DATACLAS.

When RECORG is not specified, data sets associated with a data class, either by
JCL or assigned by an ACS routine, will have DSORG defaulted to either physical
sequential or a partitioned organization.

Chapter 12. DD Statement 12-51

DD: DATACLAS
Overrides
Any attributes you specify on the same DD statement using parameters such as the
following (not a complete list), override the corresponding attributes in the named
data class for the data set:
RECORG (record organization) or RECFM (record format)
LRECL (record length)
KEYLEN (key length)
KEYOFF (key offset)
DSNTYPE (type, PDS or PDSE)
AVGREC (record request and space quantity)
SPACE (average record length, primary, secondary, and directory quantity)
RETPD (retention period) or EXPDT (expiration date)
VOLUME (volume-count)
BLKSIZE (block size) and BLKSZLIM (block size limit). A block size from any
source overrides BLKSZLIM from any source.
CICS (forward recovery log stream identifier)
DASD (space constraint)
VSAM (reuse, extended addressability, spanned records, logging control, record
access bias, initial load formatting)

Explicit specification of SPACE on the DD statement overrides both the SPACE and
the AVGREC values specified in the data class.

An ACS routine can override the data class that you specify on the DATACLAS
parameter.

Attributes obtained with the LIKE and REFDD parameters override the
corresponding attributes in the DATACLAS parameter.

Relationship to Other Parameters

Do not code the following DD parameters with the DATACLAS parameter.

* DYNAM
DATA QNAME
DDNAME

Examples of the DATACLAS Parameter

Example 1
//SMSDS1 DD DSNAME=MYDS1.PGM,DATACLAS=DCLAS01,DISP=(NEW,KEEP)

In the example, the attributes in the data class named DCLAS01 are used by SMS
to handle the data set. Note that installation-written ACS routines may select a
management class and storage class and can override the specified data class.

Example 2
//SMSDS2 DD DSNAME=MYDS2.PGM,DATACLAS=DCLAS02,DISP=(NEW,KEEP),
// LRECL=256,EXPDT=1996/033

In the example, the logical record length of 256 and the expiration date of February
2, 1996, override the corresponding attributes defined in the data class for the data
set. Note that installation-written ACS routines may select a management class and
storage class and can override the specified data class.

12-52 z/OS V1R3.0 MVS JCL Reference

 DD: DCB

DCB Parameter
Parameter Type

Keyword, optional

Purpose

Use the DCB parameter to complete during execution the data set information in
the data control block (DCB).

The data control block is constructed by the DCB macro instruction in assembler
language programs or by file definition statements or language-defined defaults in
programs in other languages.
Notes:
1. With SMS, you do not need to use the DCB parameter to specify data set
attributes. See the DATACLAS parameter (described on page 12-50), the LIKE
parameter (described on page 12-138), and the REFDD parameter (described
on page 12-170).
2. For JES3 SNA RJP, code DCB=LRECL=nnn; where nnn is 1 to 255 when
SYSIN data records are greater than 80 bytes. (The default LRECL is 80 bytes.)

References

For more information on constructing the data control block, see z/OS DFSMS:
Using Data Sets.

Syntax
[ DCB=(subparameter[,subparameter]...) ]

[ DCB= ( {dsname }[,subparameter]...) ]

[ ( {*.ddname } ) ]
[ ( {*.stepname.ddname } ) ]
[ ( {*.stepname.procstepname.ddname} ) ]

Parentheses: You can omit the parentheses if you code:

v Only one keyword subparameter.
v Only a data set name, dsname, without any subparameters.
v Only a backward reference without any subparameters. A backward reference is a
reference to an earlier DD statement in the job or in a cataloged or in-stream procedure
called by a job step. A backward reference is in the form *.ddname or
*.stepname.ddname or *.stepname.procstepname.ddname.

For example, DCB=RECFM=FB or DCB=WKDATA or DCB=*.STEP3.DD2

Multiple Subparameters: When the parameter contains more than one subparameter,
separate the subparameters by commas and enclose the subparameter list in parentheses.
For example, DCB=(RECFM=FB,LRECL=133,BLKSIZE=399) or DCB=(*.DD1,BUFNO=4)

Continuation onto Another Statement: Enclose the subparameter list in only one set of
parentheses. End each statement with a comma after a complete subparameter. For
example:
//INPUT DD DSNAME=WKDATA,DCB=(RECFM=FB,LRECL=80,BLKSIZE=800,
// BUFL=800,BUFNO=4)

Chapter 12. DD Statement 12-53

DD: DCB
Alternate Syntax for DCB Keyword Subparameters

All of the DCB keyword subparameters can be specified without the need to code
DCB=. For example, the following DD statement:
//DDEX DD DSNAME=WKDATA,DCB=(RECFM=FB,LRECL=80,BLKSIZE=800),DISP=MOD

can also be specified as:

//DDEX DD DSNAME=WKDATA,RECFM=FB,LRECL=80,BLKSIZE=800,DISP=MOD

Note that KEYLEN, LRECL, and RECFM are described as DD parameters.

Note:
v If the BUFMAX subparameter is coded with or without the DCB parameter, it can
have a null value only when coded on a DD which either:
– Overrides a DD in a procedure
– Is added to a procedure.

Subparameter Definition
subparameter
(With SMS, see the DD DATACLAS parameter.)
Specifies a DCB keyword subparameter needed to complete the data control
block.
An alphabetic summary of the DCB keyword subparameters follows this
parameter description.
You must supply DCB information through the DCB subparameters if your
processing program, the data set label, or your language’s defined values do
not complete the data control block.
dsname
(With SMS, see the DD LIKE parameter.)
Names a cataloged data set. The system is to copy DCB information from the
data set’s label. The data set must reside on a direct access volume, and the
volume must be mounted before the job step is executed.
If dsname represents a VSAM data set, and you are allocating a new data set,
you must also supply the RECORG parameter. You can specify RECORG
explicitly (through the RECORG parameter), or implicitly, through the
DATACLAS or LIKE parameters.
A hyphen is a valid character in a catalogued data set name. A data set name
that contains a hyphen must be enclosed in apostrophes if it is used as a DCB
subparameter.
The dsname cannot contain special characters, except for periods used in
qualifying the name. Do not specify a generation data group (GDG) base name,
a GDG relative generation member name, or a member name of a non-GDG
data set.
The system copies the following DCB information from the data set label:

DSORG (used in a backward reference)

RECFM
OPTCD
BLKSIZE

12-54 z/OS V1R3.0 MVS JCL Reference

 DD: DCB
LRECL
KEYLEN
RKP

If you do not specify the expiration date of the cataloged data set, the system
copies it from the data set label. The system also copies the system code.

If you code any DCB subparameters after the dsname, these subparameters
override the corresponding subparameters in the data set label. The system
copies from the referenced label only those subparameters not specified on the
referencing DD statement.
*.ddname
*.stepname.ddname
*.stepname.procstepname.ddname
| (With SMS, see the DD REFDD parameter or the DD LIKE parameter to select
| a comparable refer back function.)
Specify a backward reference to an earlier DD statement. The system is to
copy DCB information from the DCB parameter specified on that DD statement.
The DCB parameter of the referenced DD statement must contain
subparameters, and it cannot name a cataloged data set or refer to another DD
statement.
*.ddname specifies the ddname of an earlier DD statement in the same step.
*.stepname.ddname specifies the ddname of a DD statement in an earlier step,
stepname, in the same job. *.stepname.procstepname.ddname specifies the
ddname of a DD statement in a cataloged or in-stream procedure called by an
earlier job step. Stepname is the name of the job step that calls the procedure,
and procstepname is the name of the procedure step that contains the DD
statement.
If you code any DCB subparameters after the reference, these subparameters
override the corresponding subparameters on the referenced DD statement.
The system copies from the referenced DD statement only those
subparameters not specified on the referencing DD statement.
Do not reference a DD * or a DD DATA statement.

Note: The system also copies the UCS and FCB parameters from the
referenced DD statement, unless you override them in the referencing
DD statement.

Completing the Data Control Block

The system obtains data control block information from the following sources, in
override order:
v The processing program, that is, the DCB macro instruction in assembler
language programs or file definition statements or language-defined defaults in
programs in other languages.
v The DCB subparameter of the DD statement.
v The data set label.

Therefore, if you supply information for the same DCB field in your processing
program and on a DD statement, the system ignores the DD DCB subparameter. If
a DD statement and the data set label supply information for the same DCB field,
the system ignores the data set label information.

Chapter 12. DD Statement 12-55

DD: DCB
Note: When concatenated data sets are involved, the DCB is completed based on
the type of data set and how the processing program uses the data set. See
z/OS DFSMS: Using Data Sets for more information.

Relationship to Other Parameters

See the descriptions of the individual DCB subparameters for the DD parameters
and DCB subparameters that should not be coded with a specific DCB
subparameter.

Do not code the following parameters with the DCB parameter.

AMP
DYNAM

With the DDNAME parameter, code only the BLKSIZE, BUFNO, and DIAGNS DCB
subparameters.

With the QNAME parameter, code only the BLKSIZE, LRECL, OPTCD, and
RECFM DCB subparameters.

The DD parameter KEYLEN and DCB subparameters KEYLEN, MODE, PRTSP,

STACK, and TRTCH apply to specific device types. If you specify one of these
subparameters on a DD statement for a device different from the type to which it
applies, the system interprets the value incorrectly.

With the SPACE parameter, the value specified for BLKSIZE directly affects the
amount of space obtained for data sets allocated in records, and for data sets
allocated in blocks where the block length (blklgth) is zero.

For 3540 Diskette Input/Output Units

The VOLUME=SER, DCB=BUFNO, and DSID parameters on a DD * or DD DATA

statement are ignored except when they are detected by a diskette reader as a
request for an associated data set. See 3540 Programmer’s Reference.

Examples of the DCB Parameter

Example 1
//DD1 DD DSNAME=ALP,DISP=(,KEEP),VOLUME=SER=44321,
// UNIT=3400-6,DCB=(RECFM=FB,LRECL=240,BLKSIZE=960,
// DEN=1,TRTCH=C)

DD statement DD1 defines a new data set named ALP. The DCB parameter
contains the information necessary to complete the data control block.

Example 2
//DD1A DD DSNAME=EVER,DISP=(NEW,KEEP),UNIT=3380,
// DCB=(RECFM=FB,LRECL=326,BLKSIZE=23472),
// SPACE=(23472,(200,40))

DD statement DD1A defines a new data set named EVER on a 3380. The DCB
parameter contains the information necessary to complete the data control block.
//DD1B DD DSNAME=EVER,DISP=(NEW,KEEP),UNIT=3380,
// RECFM=FB,LRECL=326,
// SPACE=(23472,(200,40))

12-56 z/OS V1R3.0 MVS JCL Reference

 DD: DCB
DD statement DD1B is the same as the DD1A statement except that it shows the
alternate syntax for the DCB keyword subparameters. Also, because BLKSIZE is
omitted, the system will select an optimum block size for the data.

Example 3
//DD2 DD DSNAME=BAL,DISP=OLD,DCB=(RECFM=F,LRECL=80,
// BLKSIZE=80)
//DD3 DD DSNAME=CNANN,DISP=(,CATLG,DELETE),UNIT=3400-6,
// LABEL=(,NL),VOLUME=SER=663488,DCB=*.DD2

DD statement DD3 defines a new data set named CNANN and requests that the
system copy the DCB subparameters from DD statement DD2, which is in the same
job step.

Example 4
//DD4 DD DSNAME=JST,DISP=(NEW,KEEP),UNIT=SYSDA,
// SPACE=(CYL,(12,2)),DCB=(A.B.C,KEYLEN=8)

DD statement DD4 defines a new data set named JST and requests that the
system copy the DCB information from the data set label of the cataloged data set
named A.B.C. If the data set label contains a key length specification, it is
overridden by the KEYLEN coded on this DD statement.

Example 5
//DD5 DD DSNAME=SMAE,DISP=OLD,
// DCB=(*.STEP1.PROCSTP5.DD8,BUFNO=5)

DD statement DD5 defines an existing, cataloged data set named SMAE and
requests that the system copy DCB subparameters from DD statement DD8, which
is contained in the procedure step named PROCSTP5. The cataloged procedure is
called by EXEC statement STEP1. Any of the DCB subparameters coded on DD
statement DD8 are ignored if they are specified in the program. If the DCB BUFNO
subparameter is not specified in the program, five buffers are assigned.

DCB Subparameters
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
BFALN X X X X X X X BFALN={F|D}

Specifies that each buffer starts either on a word boundary

that is not also a doubleword boundary or on a doubleword
boundary. If both BFALN and BFTEK are specified, they
must be specified from the same source.

Default: D (doubleword)

Note: Do not code the BFALN subparameter with DCB

subparameter GNCP, or with DD parameters DDNAME or
QNAME.

Chapter 12. DD Statement 12-57

DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
BFTEK X X X X BDAM and BSAM: BFTEK=R
R Specifies that the data set is being created for or
contains variable-length spanned records. Do not
specify R for a PDSE.

BTAM: BFTEK=D
D Specifies that dynamic buffering is to be used in
the processing program; if dynamic buffering is
specified, a buffer pool also must be defined.

QSAM: BFTEK={S|A}
S Specifies simple buffering (default). Simple
buffering may be coded at any time for QSAM files.
A Specifies locate mode logical record interface for
spanned records. QSAM obtains a logical record
area and assembles the physical record segments
of a spanned record into that logical record area.
This forms a complete logical record before
pointing the user to it.
v This parameter value may be specified only for
RECFM=VS or RECFM=VBS files; if specified
without RECFM=VS|VBS, the specification is
ignored.
v Locate mode must be used together with this
parameter value.
Note: If you use locate mode on a
RECFM=VS|VBS file and BFTEK=A is not
specified, the results may include processing the
segments of a spanned record as separate
records, issuance of system completion (abend)
code X'002' with reason code X'04', or other
unpredictable results.
v If you specify BFTEK=A with move mode, a
system completion (abend) code X'013' with
reason code X'5C' is issued.

For information about the locate and move modes in the

DCB subparameters BFTEK and VBS, see z/OS DFSMS
Macro Instructions for Data Sets.

If you specify both BFALN and BFTEK, you must specify

them from the same source.

Note: Do not code the BFTEK subparameter with DCB

subparameter GNCP, or with DD parameters DDNAME or
QNAME.

Note: For compatibility purposes with previous operating

systems, the system accepts BFTEK=E.

12-58 z/OS V1R3.0 MVS JCL Reference

 DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
BLKSIZE X X X X X X X BLKSIZE={value|valueK|valueM|valueG}

Specifies the maximum length, in bytes, of a block.

value Specifies the maximum length of a block.
The number you specify for BLKSIZE
depends on the device type and the
record format for the data set. The
maximum is 32,760 for DASD data sets
and 2,147,483,648 for tape, except for
data sets on magnetic tape with
ISO/ANSI/FIPS labels, where the minimum
value for BLKSIZE is 18 bytes and the
maximum is 2048 bytes. (To allow a value
greater than 2048, use installation exit
routine IFG0193G, described in z/OS
DFSMS Installation Exits.)
valueK Specifies the maximum length, in
kilobytes, of a block. (1 kilobyte = 1024
bytes.) The maximum is 2097152. If
2097152K is coded, the block size
assigned will be the maximum:
2,147,483,648.
valueM Specifies the maximum length, in
megabytes, of a block. (1 megabyte =
1024 kilobytes.) The maximum is 2048. If
2048M is coded, the block size assigned
will be the maximum: 2,147,483,648.
valueG Specifies the maximum length, in
gigabytes, of a block. (1 gigabyte = 1024
megabytes.) The maximum is 2G. If 2G is
coded, the block size assigned will be the
maximum: 2,147,483,648.

If you code the BLKSIZE subparameter in the DCB macro

instruction or on a DD statement that defines an existing
data set with standard labels, the DCB BLKSIZE overrides
the block size specified in the label. BLKSIZE can be coded
but will have no effect on EXCP processing.

The number you specify for BLKSIZE directly affects the

amount of space obtained for data sets allocated in records,
and for data sets allocated in blocks where the block length
(blklgth) is zero.

Default: If you do not code BLKSIZE, the system can, under

certain conditions, determine an optimum block size for the
data. For detailed information about system-determined
block size, see z/OS DFSMS: Using Data Sets.

Note: Do not code the BLKSIZE subparameter with the

BUFSIZE subparameter.

Chapter 12. DD Statement 12-59

DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
BUFIN X BUFIN=buffers

Specifies the number of buffers to be assigned initially for

receiving operations for each line in the line group. The
combined BUFIN and BUFOUT values must not be greater
than the number of buffers in the buffer pool for this line
group (not including those for disk activity only).

Default: 1

Note: Do not code the BUFIN subparameter with DCB

subparameter BUFNO, or DD parameters DDNAME,
QNAME.
BUFL X X X X X X X X BUFL=bytes

Specifies the length, in bytes, of each buffer in the buffer

pool. The maximum is 32,760.

Note: Do not code the BUFL subparameter with DD

parameter DDNAME.
BUFMAX X BUFMAX=buffers

Specifies the maximum number of buffers to be allocated to

a line at one time. Number must be 2 through 15 and must
be equal to or greater than the larger of the numbers
specified by the BUFIN and BUFOUT subparameters.

Default: 2

Note: Do not code the BUFMAX subparameter with DCB

subparameter NCP, or DD parameters DDNAME, QNAME.
BUFNO X X X X X X X X BUFNO=buffers

Specifies the number of buffers to be assigned to the DCB.

The maximum normally is 255, but can be less because of
the size of the region.

Note: Do not code the BUFNO subparameter with DCB

subparameters BUFIN, BUFOUT, or DD parameter QNAME.
BUFOFF X X BUFOFF={n|L}
n Specifies the length, in bytes, of the block prefix
used with an ASCII tape data set. For input, n can
be 0 through 99. For output, n must be 0 for writing
an output data set with fixed-length or
undefined-length records.
L Specifies that the block prefix is 4 bytes and
contains the block length. BUFOFF=L is valid only
with RECFM=D. For output, only BUFOFF=L is
valid.

Note: Do not code the BUFOFF subparameter with DD

parameters DDNAME, QNAME.

12-60 z/OS V1R3.0 MVS JCL Reference

 DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
BUFOUT X BUFOUT=buffers

Specifies the number of buffers to be assigned initially for

sending operations for each line in the line group. The
combined number of BUFIN and BUFOUT values must not
be greater than the number of buffers in the buffer pool for
this line group (not including those for disk activity only) and
cannot exceed 15.

Default: 2

Note: Do not code the BUFOUT subparameter with DCB

subparameter BUFNO, or DD parameter DDNAME.
BUFSIZE X BUFSIZE=bytes

Specifies the length, in bytes, of each of the buffers to be

used for all lines in a particular line group. Length must be
31 through 65535 bytes.

Note: Do not code the BUFSIZE subparameter with DCB

subparameter BLKSIZE, or DD parameters DDNAME,
QNAME.
CPRI X CPRI={R|E|S}

Specifies the relative transmission priority assigned to the

lines in this line group.
R Specifies that processor receiving has priority over
processor sending.
E Specifies that receiving and sending have equal
priority.
S Specifies that processor sending has priority over
processor receiving.

Note: Do not code the CPRI subparameter with DCB

subparameter THRESH, or DD parameters DDNAME,
OUTLIM, QNAME.
CYLOFL X CYLOFL=tracks

Specifies the number of tracks on each cylinder to hold the

records that overflow from other tracks on that cylinder. The
maximum is 99. Specify CYLOFL only when OPTCD=Y.

Note: Do not code the CYLOFL subparameter with DCB

subparameter RESERVE, or DD parameters DDNAME,
FCB, QNAME, UCS.

Chapter 12. DD Statement 12-61

DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
DEN X X X DEN={1|2|3|4}

Specifies the magnetic density, in number of bits-per-inch,

used to write a magnetic tape data set.
DEN 7-track tape 9-track tape
1 556 -
2 800 800 (NRZI)
3 - 1600 (PE)
4 - 6250 (GCR)
NRZI Non-return-to-zero inverted recording mode.
PE Phase encoded recording mode.
GCR Group coded recording mode.
Default:
800 bpi assumed for 7-track tape and 9-track
without dual density.
1600 bpi assumed for 9-track with dual density or
phase-encoded drives.
6250 bpi assumed for 9-track with 6250/1600 bpi
dual density or group coded recording tape.

Note: Do not code the DEN subparameter with DD

parameters DDNAME, QNAME.
DIAGNS X X X X X X X X X DIAGNS=TRACE

Specifies the OPEN/CLOSE/EOV trace option, which gives

a module-by-module trace of OPEN/CLOSE/EOV’s work
area and the DCB. If the generalized trace facility (GTF) is
not running and tracing user events, DIAGNS is ignored.
See z/OS DFSMSdfp Diagnosis Reference for more
information.

12-62 z/OS V1R3.0 MVS JCL Reference

 DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
DSORG X X X X X X X X X X DSORG=organization

Specifies the organization of the data set and indicates

whether the data set contains any location-dependent
information that would make the data set unmovable.

Note: Do not code the DSORG subparameter with DD

parameters DDNAME, QNAME, RECORG.
Organization | Access Method
___________________________________ _ _____________________
PS Physical sequential data set | BSAM,EXCP,QSAM,
| TCAM
PSU Physical sequential data set | BSAM,QSAM,EXCP
that contains |
location-dependent information |
DA Direct access data set | BDAM,EXCP
DAU Direct access data set that | BDAM,EXCP
contains location-dependent |
information |
IS Indexed sequential data set | BISAM,QISAM,EXCP
ISU Indexed sequential data set | QISAM,EXCP
that contains |
location-dependent information |
PO Partitioned data set |BPAM,EXCP
(PDS or PDSE) |
POU Partitioned data set (PDS) that| BPAM,EXCP
contains location-dependent |
information |
CX Communications line group | BTAM
GS Graphic data control block | GAM

EROPT X X EROPT=x
BTAM: Requests the BTAM on-line terminal test option.
x=T
QSAM: Specifies the option to be executed if an error
occurs in reading or writing a record.
x=ACC System is to accept the block causing the
error.
x=SKP System is to skip the block causing the
error.
x=ABE System is to cause abnormal end of task.
Default ABE

Note: Do not code the EROPT subparameter with DD

parameters DDNAME, QNAME.

Chapter 12. DD Statement 12-63

DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
FUNC X X FUNC={I|R|P|W|D|X|T}

Specifies the type of data set to be opened for a 3505 Card

Reader or 3525 Card Punch. Unpredictable results will
occur if coded for other than a 3505 or 3525.
I Data set is for punching and printing cards.
R Data set is for reading cards.
P Data set is for punching cards.
W Data set is for printing.
D Protected data set is for punching.
X Data set is for both punching and printing.
T Two-line print option.

The only valid combinations of these values are:

I WT RWT RPWXT PWX
R RP PW RPWD RPWX
P RPD PWXT RWX RWX
W RW RPW RWXT

Default: P, for output data set. R, for input data set.

Note: Do not code the FUNC subparameter with the

data-set-sequence number of the DD LABEL parameter, or
DD parameters DDNAME, QNAME.
GNCP X GNCP=n

Specifies the maximum number of I/O macro instructions

that the program will issue before a WAIT macro instruction.

Note: Do not code the GNCP subparameter with DCB

subparameters BFALN, BFTEK, or DD parameters
DDNAME, QNAME.
INTVL X INTVL={n|0}

Specifies the interval, in seconds, between passes through

an invitation list.

Default: 0

Note: Do not code the INTVL subparameter with DD

parameters DDNAME, FCB, QNAME, UCS.
IPLTXID X IPLTXID=member

Specifies the name of the partitioned data set (PDS)

member that you want loaded into a 3704/3705
Communications Controller. The DCB IPLTXID
subparameter overrides IPLTXID in the TERMINAL macro
representing the NCP.

Note: Do not code the IPLTXID subparameter with DD

parameters DDNAME, DSNAME, QNAME.

12-64 z/OS V1R3.0 MVS JCL Reference

 DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
KEYLEN X X X X X X KEYLEN=bytes

The KEYLEN keyword subparameter is described on the DD

KEYLEN parameter, page 12-127.
LIMCT X LIMCT={blocks|tracks}

Specifies how many blocks (if relative block addressing is

used) or how many tracks (if relative track addressing is
used) are to be searched for a free block or available space.
This kind of search occurs only when DCB OPTCD=E is
also specified; otherwise, LIMCT is ignored. If the LIMCT
number equals or exceeds the number of blocks or tracks in
the data set, the entire data set is searched.

Note: Do not code the LIMCT subparameter with DD

parameters DDNAME, QNAME.
LRECL X X X X X X LRECL=bytes

The LRECL keyword subparameter is described on the DD

LRECL parameter, page 12-140.
MODE X X X MODE= {C [O]}
{E [R]}

Specifies the mode of operation to be used with a card

reader, a card punch, or a card read-punch.
C Card image (column binary) mode
E EBCDIC mode
O Optional mark read mode
R Read column eliminate mode

If you specify R, you must also specify either C or E. Do not

code the MODE subparameter for data entered through the
input stream except in a JES3 system.

Do not code MODE=C for JES2 or JES3 output.

Default: E

Note: Do not code the MODE subparameter with DCB

subparameters KEYLEN, PRTSP, TRTCH, or DD
parameters DDNAME, KEYLEN, QNAME.

Chapter 12. DD Statement 12-65

DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
NCP X X X NCP=n

Specifies the maximum number of READ or WRITE macro

instructions that may be issued before a CHECK macro
instruction is issued to test for completion of the I/O
operation. The maximum number is 255 for BSAM and
BPAM, but may actually be smaller depending on the size of
the address space. If chained scheduling is used, the
number should be greater than 1. The maximum number for
BISAM is 99.

Default: 1

Note: Do not code the NCP subparameter with DCB

subparameter BUFMAX, or DD parameters DDNAME,
QNAME.
NTM X NTM=tracks

Specifies the number of tracks to be used for a cylinder

index. When the specified number of tracks has been filled,
a master index is created. The DCB NTM is needed only
when the DCB OPTCB=M. If you specify OPTCD=M but
omit NTM, the master index option is ignored.

Note: Do not code the NTM subparameter with DCB

subparameter PCI, or DD parameters DDNAME, QNAME.

12-66 z/OS V1R3.0 MVS JCL Reference

 DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
OPTCD X X X X X X X X Specifies the optional services to be performed by the
control program. All optional services must be requested in
one source, that is, in the data set label of an existing data
set, in the DCB macro, or in the DD DCB parameter.
However, the processing program can modify the DCB
OPTCD field. Code the characters in any order; when
coding more than one, do not code commas between the
characters.

Note: Do not code the OPTCD subparameter with DD

parameter DDNAME.
BDAM: OPTCD= {A}[E][F][W]
{R}
A indicates that the actual device addresses are to be
specified in READ and WRITE macro instructions.
R indicates that relative block addresses are to be
specified in READ and WRITE macro instructions.
E indicates that an extended search (more than one
track) is to be performed for a block of available
space. LIMCT must also be coded. Do not code
LIMCT=0 because it will cause an abnormal
termination when a READ or WRITE macro
instruction is executed.
F indicates that feedback can be requested in READ
and WRITE macro instructions and the device is to
be identified in the same form as it was presented
to the control program.
W requests a validity check for write operations on
direct access devices.

BISAM: OPTCD={[L][R][W]}
L requests that the control program delete records
that have a first byte of all ones. These records will
be deleted when space is required for new records.
To use the delete option, the DCB RKP must be
greater than zero for fixed-length records and
greater than four for variable-length records.
R requests that the control program place
reorganization criteria information in certain fields of
the DCB. The problem program can analyze these
statistics to determine when to reorganize the data
set.
W requests a validity check for write operations on
direct access devices.

Default: R, whenever the OPTCD subparameter is omitted

from all sources.

Chapter 12. DD Statement 12-67

DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
OPTCD BPAM: OPTCD= {C|W|CW}
(continued)
C has no effect.
W requests a validity check for write operations.
BSAM and QSAM: OPTCD= {B }
{T }
{U[C] }
{C[T][B][U] }
{H[Z][B] }
{J[C][U] }
{W[C][T][B][U]}
{Z[C][T][B][U]}
{Q[C][T][B] }
{Z }
B requests that the end-of-volume (EOV) routine
disregard the end-of-file (EOF) recognition for
magnetic tape. For an input data set on a
standard-labeled (SL or AL) tape, the EOV routine
treats EOF labels as EOV labels until the volume
serial list is exhausted. This option allows SL or AL
tapes to be read out of volume sequence or to be
concatenated to another tape with the same data
set name using one DD statement. See ″Data Sets
that Span Libraries″ in z/OS MVS JCL User’s
Guide for a description of allocation processing for
multi-volume data sets created in different tape
libraries.
C requests chained scheduling.
H requests hopper empty exit for optical readers or
bypass of DOS checkpoint records.
J for a data set to be printed on a 3800 Printing
Subsystem, instructs the system that the logical
record for each output data line contains a table
reference character (TRC). The TRC identifies
which character arrangement table in the CHARS
parameter is to be used to print the line. Before
specifying OPTCD=J, see the 3800 Programmer’s
Guide.

12-68 z/OS V1R3.0 MVS JCL Reference

 DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
OPTCD BSAM and QSAM (continued):
(continued)
Q indicates that all the user data in the data set is in
ASCII. BSAM or QSAM converts the records from
ASCII to EBCDIC when reading and converts the
records from EBCDIC to ASCII when writing. The
data set must reside on magnetic tape and must
not contain IBM standard labels. The record format
(RECFM) must not be V but can be D. If the label
type is ISO/ANSI/FIPS, specified as LABEL=(,AL),
the system forces OPTCD=Q.
T requests user totaling facility. T cannot be specified
for a SYSIN or sysout data set.
U for 1403 or 3211 Printers with the Universal
Character Set (UCS) feature and for the 3800,
permits data checks and allows analysis by an
appropriate error analysis routine. If U is omitted,
data checks are not recognized as errors.
W requests a validity check for write operations on
direct access devices. Requests ″tape write
immediate″ mode on a cartridge tape device such
as the IBM 3490 Magnetic Tape Subsystem.
Z for magnetic tape reel input, requests that the
control program shorten its normal error recovery
procedure. When specified, a data check is
considered permanent after five unsuccessful
attempts to read a record.

OPTCD=Z is ignored if chained scheduling or a tape

cartridge is used. For a PDSE, all options except OPTCD=J
are ignored.

EXCP: OPTCD=Z
Z for magnetic tape reel input, requests that the
control program shorten its normal error recovery
procedure. When specified, a data check is
considered permanent after five unsuccessful
attempts to read a record. OPTCD=Z has no effect
on a tape cartridge.

Chapter 12. DD Statement 12-69

DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
OPTCD QISAM: OPTCD={[I][L][M][R][U][W][Y]}
(continued)
I requests that ISAM use the independent overflow
areas for overflow records.
L requests that ISAM delete records that have a first
byte of all ones. These records can be deleted
when space is required for new records. To use the
delete option, the DCB RKP must be greater than
zero for fixed-length records and greater than four
for variable-length records.
M requests that the system create and maintain one
or more master indexes, according to the number
of tracks specified in the DCB NTM subparameter.
R requests that the control program place
reorganization criteria information in the DCB. The
problem program can analyze these statistics to
determine when to reorganize the data set.
U requests that the system accumulate track index
entries in storage and write them as a group for
each track of the track index. U can be specified
only for fixed-length records.
W requests a validity check for write operations on
direct access devices.
Y requests that the system use the cylinder overflow
areas for overflow records.

Default: R, whenever the OPTCD subparameter is omitted

from all sources.

TCAM: OPTCD={C|U|W}
C specifies that one byte of the work area indicates if
a segment of a message is the first, middle, or last
segment.
U specifies that the work unit is a message. If U is
omitted, the work unit is assumed to be a record.
W specifies that the name of each message source is
to be placed in an 8-byte field in the work area.

12-70 z/OS V1R3.0 MVS JCL Reference

 DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
PCI X {([N][,N])}
PCI= {([R][,R])}
{([A][,A])}
{([X][,X])}

Specifies (1) whether or not a program-controlled

interruption (PCI) is to be used to control the allocation and
freeing of buffers and (2) how these operations are to be
performed. The first operand applies to receiving operations
and the second to sending operations.
N specifies that no PCIs are taken while filling buffers
during receiving operations or emptying buffers
during sending operations.
R specifies that after the first buffer is filled or
emptied, a PCI occurs during the filling or emptying
of each succeeding buffer. The completed buffer is
freed, but no new buffer is allocated to take its
place.
A specifies that after the first buffer is filled or
emptied, a PCI occurs during the filling or emptying
of the next buffer. The first buffer is freed, and a
buffer is allocated to take its place.
X specifies that after a buffer is filled or emptied, a
PCI occurs during the filling or emptying of the next
buffer. The first buffer is not freed, but a new buffer
is allocated.

You can omit the parentheses if you code only the first
operand.

Default: (A,A)

Note: Do not code the PCI subparameter with DCB

subparameter NTM, or DD parameters DDNAME, QNAME.
PRTSP X X X PRTSP={0|1|2|3}

Specifies the line spacing for an online printer. PRTSP is

valid only for an online printer and only if the RECFM is not
A or M. PRTSP=2 is ignored if specified with the DD
SYSOUT parameter. 0 - spacing is suppressed, 1 - single, 2
- double, 3 - triple spacing

JES2 ignores PRTSP for sysout data sets.

Default: 1

Note: Do not code the PRTSP subparameter with DCB

subparameters KEYLEN, MODE, STACK, TRTCH, or DD
parameters DDNAME, KEYLEN, QNAME.

Chapter 12. DD Statement 12-71

DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
RECFM X X X X X X X RECFM=format

The RECFM keyword subparameter is described on the DD

RECFM parameter, page 12-165.
RESERVE X RESERVE=(bytes1,bytes2)

Specifies the number of bytes (0 through 255) to be

reserved in a buffer for insertion of data by the DATETIME
and SEQUENCE macros.
bytes1 indicates the number of bytes to be reserved in the
first buffer that receives an incoming message.
bytes2 indicates the number of bytes to be reserved in all
the buffers following the first buffer in a
multiple-buffer header situation.

Default: (0,0)

Note: Do not code the RESERVE subparameter with DCB

subparameters CYLOFL, RKP, or DD parameters DDNAME,
KEYOFF, QNAME, UCS.
RKP X X RKP=number

With SMS, use the DD KEYOFF or DATACLAS parameter.

Specifies the position of the first byte of the record key in
each logical record. The first byte of a logical record is
position 0.

If RKP=0 is specified for blocked fixed-length records, the

key begins in the first byte of each record. OPTCD=L must
not be specified.

If RKP=0 is specified for unblocked fixed-length records, the

key is not written in the data field. OPTCD=L can be
specified.

For variable-length records, the relative key position must be

4 or greater, if OPTCD=L is not specified; the relative key
position must be 5 or greater, if OPTCD=L is specified.

For EXCP processing, RKP can be coded but is ignored.

Default: 0

Note: Do not code the RKP subparameter with DCB

subparameter RESERVE, or DD parameters DDNAME,
FCB, KEYOFF, UCS.

12-72 z/OS V1R3.0 MVS JCL Reference

 DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
STACK X X X STACK={1|2}

Specifies which stacker bin is to receive a card.

Default: 1

Note: Do not code the STACK subparameter with DCB

subparameters KEYLEN, PRTSP, TRTCH, or DD
parameters DDNAME, KEYLEN, QNAME.
THRESH X THRESH=nn

Specifies the percentage of the nonreusable disk message

queue records that are to be used before a flush closedown
occurs.

Default: Closedown occurs when 95 percent of the records

have been used.

Note: Do not code the THRESH subparameter with DCB

subparameter CPRI, or DD parameters DDNAME, OUTLIM,
QNAME.

Chapter 12. DD Statement 12-73

DD: DCB
Access Method
B Q
B I B B B E I Q T
D S P S T X G S S C
DCB A A A A A C A A A A
Subparameters M M M M M P M M M M Description of Subparameters
TRTCH X X X TRTCH={C|E|T|ET} {COMP|NOCOMP}

With C, E, T, or ET: specifies the recording technique for

7-track tape.
C specifies data conversion, odd parity, and no
translation.
E specifies no data conversion, even parity, and no
translation.
T specifies no data conversion, odd parity, and that
BCD to EBCDIC translation is required when
reading and EBCDIC to BCD translation when
writing.
ET specifies no data conversion, even parity, and that
BCD to EBCDIC translation is required when
reading and EBCDIC to BCD translation when
writing.

Default: no conversion, odd parity, and no translation.

With COMP or NOCOMP: specifies data compaction or no

data compaction on a tape device enabled for compaction.
Data compaction is not supported with ISO/ANSI labels.
COMP specifies data compaction.
NOCOMP
specifies no data compaction

Defaults: On an IBM standard label tape, data sets after the

first data set have the same compaction value (COMP or
NOCOMP) as the first data set. The system ignores any
compaction specified on data sets after the first. The system
takes the compaction value from the first source that
specifies it. The following sources can specify compaction:
1. TRTCH subparameter.
2. Data class, as set by the storage administrator. The
tape, however, does not have to be system-managed.
3. DEVSUPxx member of SYS1.PARMLIB.
4. The hardware model. For the IBM 3480, the default is
NOCOMP. For the IBM 3490, the default is COMP.

See z/OS MVS JCL User’s Guide for information about

using IEFBR14 and the TRTCH subparameter.

Note: Do not code the TRTCH subparameter with DCB

subparameters KEYLEN, MODE, PRTSP, STACK, or DD
parameters DDNAME, KEYLEN, QNAME.

Note: TRTCH is not applicable for DASD data sets. If

specified, it will be ignored.

12-74 z/OS V1R3.0 MVS JCL Reference

 DD: DDNAME

DDNAME Parameter
Parameter Type

Keyword, optional

Purpose

Use the DDNAME parameter to postpone defining a data set until later in the same
job step. A DDNAME parameter on a DD statement in a cataloged or in-stream
procedure allows you to postpone defining the data set until a job step calls the
procedure; the data set must be defined in the calling job step.

Syntax
DDNAME=ddname

v The DDNAME parameter can have a null value only when coded on a DD which either:
– Overrides a DD in a procedure
– Is added to a procedure.

Subparameter Definition
ddname
Refers to a later DD statement that defines the data set. ddname must match
the ddname of the referenced DD statement.
A job step or procedure step can contain up to five DD statements with
DDNAME parameters. Each DDNAME parameter must refer to a different DD
statement.

Overrides
If any DCB subparameter appears on both DD statements, the DCB subparameter
on the referenced DD statement overrides the DCB subparameter on the DD
statement that contains DDNAME.

Relationship to Other Parameters

The only DD parameters you can code with the DDNAME parameter are:

DCB=BLKSIZE LIKE
DCB=BUFNO REFDD
DCB=DIAGNS

Do not code the DDNAME parameter on a DD statement with a ddname of JOBLIB,

JOBCAT, or STEPCAT.

Location in the JCL

Place a DD statement containing a DDNAME parameter in a job step or in a
cataloged or in-stream procedure. The referenced DD statement must be later in
the same job step, must be in the calling job step, or must be in a cataloged or
in-stream procedure called by the job step.

Chapter 12. DD Statement 12-75

DD: DDNAME
Do not use the name of a DDNAME statement more than once within the same
step.

Location of DD Statements for Concatenated Data Sets

To concatenate data sets to a data set defined with a DDNAME parameter, the
unnamed DD statements must follow the DD statement that contains the DDNAME
parameter, not the referenced DD statement that defines the data set.

Errors in Location of Referenced DD Statement

The system treats a DDNAME parameter as though it were a DUMMY parameter

and issues a warning message in the following cases:
v If the job step or called procedure does not contain the referenced DD statement.
v If the referenced DD statement appears earlier in the job step.

Location of DD Statement Requesting Unit Affinity

To use the same device, a DD statement can request unit affinity to an earlier DD
statement by specifying UNIT=AFF=ddname. If a DD statement requests unit affinity
to a DD statement containing a DDNAME parameter, the DD statement requesting
unit affinity must be placed after the referenced DD statement. If the DD statement
requesting unit affinity appears before, the system treats the DD statement
requesting unit affinity as a DUMMY DD statement.
//STEP EXEC PGM=TKM
//DD1 DD DDNAME=DD4
//DD2 DD DSNAME=A,DISP=OLD
.
.
//DD4 DD DSNAME=B,DISP=OLD
//DD5 DD UNIT=AFF=DD1

DD1 postpones defining the data set until DD4. DD5 requests unit affinity to DD1.
Because DD1 has been defined when DD5 is processed, the system assigns DD5
to the same device as DD1.

Instead of specifying UNIT=AFF=ddname, both DD statements can specify the

same devices in their UNIT parameters or the same volume serials in their
VOLUME parameters.

Referenced DD Statement
If the DDNAME parameter appears in a procedure with multiple steps, the ddname
on the referenced DD statement takes the form stepname.ddname. For example, if
procedure step STEPCP1 contains:
//INDATA DD DDNAME=DD1

The referenced DD statement in the calling job step is:

//STEPCP1.DD1 DD *

Parameters not Permitted on the Referenced DD Statement

The referenced DD statement must not contain a DYNAM or PATH parameter.

12-76 z/OS V1R3.0 MVS JCL Reference

 DD: DDNAME
A DD statement that contains a DDNAME parameter must not override a procedure
sysout DD statement that contains an OUTPUT parameter if the referenced DD
statement also contains an OUTPUT parameter.

References to Concatenated Data Sets

If you make a forward reference to a concatenation, the forward reference

resolves to the first data set in the concatenation. If there are no DD statements
between the forward reference and the concatenation, the rest of the data sets in
the concatenation are appended to the first data set in the concatenation. The
following example illustrates this.
//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DDNAME=INPUT
//INPUT DD DSN=TSTDATA1,DISP=SHR
// DD DSN=TSTDATA2,DISP=SHR
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY

In this example, SYSUT1 will resolve to the first data set TSTDATA1, defined by the
DDNAME forward reference INPUT. TSTDATA2, the second data set in the
DDNAME forward reference INPUT, will be appended to SYSUT1 as well.
IEBGENER will recognize TSTDATA1 and TSTDATA2 as input.

If there are any DD statements between the forward reference and the
concatenation, the rest of the data sets in the concatenation are appended to the
last DD statement preceding the concatenation. For example:
//STEP1 EXEC PGM=IEBGENER
//SYSUT1 DD DDNAME=INPUT
//SYSPRINT DD SYSOUT=*
//SYSUT2 DD SYSOUT=*
//INPUT DD DSN=TSTDATA1,DISP=SHR
// DD DSN=TSTDATA2,DISP=SHR
//SYSIN DD DUMMY

In the preceding example, SYSUT1 will resolve to the first data set, TSTDATA1,
defined in the DDNAME forward reference INPUT. TSTDATA2 will be appended to
SYSUT2, the last DD statement preceding the concatenation. In that example
IEBGENER will only recognize TSTDATA1 as input.

If a concatenated DD is added to a procedure, the remaining concatenated data

sets will be concatenated to the last DD in the step named in an override or
addition (or to the first step if no step was named in an override or addition). Note
that this may result in these concatenated DDs being added to an unexpected DD.
The following example illustrates this.
//TPROC PROC
//S1 EXEC PGM=IEFBR14
//DD1 DD DDNAME=INPUT
//DD2 DD DSN=MYDSN2,DISP=SHR
//DD3 DD DSN=MYDSN3,DISP=SHR
//S2 EXEC PGM=IEFBR14
//DDA DD DDNAME=INPUT
//DDB DD DSN=MINE2,DISP=SHR
//DDC DD DSN=MINE3,DISP=SHR
// PEND
//STEP1 EXEC TPROC
//INPUT DD DSN=MYDSN1,DISP=SHR

Chapter 12. DD Statement 12-77

DD: DDNAME
// DD DSN=MYDSN4,DISP=SHR
//S2.INPUT DD DSN=MINE1,DISP=SHR
// DD DSN=MINE4,DISP=SHR

In the preceding example, the result of the DDNAME forward reference INPUT is:
v In step S1, DD1 resolves to data set MYDSN1 and data set MYDSN4 is
concatenated to data set MYDSN3.
v In step S2, DDA resolves to data set MINE1 and data set MINE4 is concatenated
to data set MINE3.

Backward References
A backward reference is a reference to an earlier DD statement in the job or in a
cataloged or in-stream procedure called by a job step. A backward reference is in
the form *.ddname or *.stepname.ddname or *.stepname.procstepname.ddname.
The ddname in the reference is the ddname of the earlier DD statement. If the
earlier DD statement contains a DDNAME parameter, the reference is to the
ddname in the name field of the earlier statement, not to the ddname in the
DDNAME parameter.

The DD statement referenced in a DDNAME parameter cannot refer to a DD

statement between the statement containing the DDNAME parameter and itself. For
example:
//SHOW EXEC PGM=ABLE
//DD1 DD DDNAME=INPUT
//DD2 DD DSNAME=TEMPSPAC,SPACE=(TRK,1),UNIT=SYSDA
//DD3 DD DSNAME=INCOPY,VOLUME=REF=*.DD1,
// DISP=(,KEEP),SPACE=(TRK,(5,2))
//DD4 DD DSNAME=OUTLIST,DISP=OLD
//DD5 DD DSNAME=MESSAGE,DISP=OLD,UNIT=3330,VOLUME=SER=333333
//INPUT DD DSNAME=NEWLIST,DISP=(OLD,KEEP),VOLUME=SER=333333,
// UNIT=3330

The DDNAME parameter on DD1 refers to DD statement INPUT. The VOLUME

parameter of DD3 specifies a backward reference to DD1, which is the name field
ddname.

DD statement INPUT identifies the volume 333333 in its VOLUME=SER=333333

parameter. DD statement INPUT cannot use a backward reference to the VOLUME
parameter on DD5 because DD5 is between the referring DD1 and the referenced
INPUT.

Examples of the DDNAME Parameter

Example 1

The following procedure step is the only step in a cataloged procedure named
CROWE:
//PROCSTEP EXEC PGM=RECPGM
//DD1 DD DDNAME=WKREC
//POD DD DSNAME=OLDREC,DISP=OLD

DD statement DD1 is intended for weekly records in the input stream; these records
are processed by this step. Because the * and DATA parameters cannot be used in
cataloged procedures, the DDNAME parameter is coded to postpone defining the
data set until the procedure is called by a job step. The step that calls the
procedure is:

12-78 z/OS V1R3.0 MVS JCL Reference

 DD: DDNAME
//STEPA EXEC PROC=CROWE
//WKREC DD *
.
.
data
.
/*

Example 2

When the procedure contains multiple steps, use the form stepname.ddname for
the ddname of the referenced DD statement. For example, the following procedure
steps appear in a cataloged procedure named PRICE:
//STEP1 EXEC PGM=SUGAR
//DD1 DD DDNAME=QUOTES
.
.
.
//STEP2 EXEC PGM=MOLASS
//DD2 DD DSNAME=WEEKB,DISP=OLD
.
.
.

The step that calls the procedure is:

//STEPA EXEC PROC=PRICE
//STEP1.QUOTES DD *
.
.
data
.
/*

Example 3

When the referenced DD statement is to be a concatenation, the procedure must

already contain the concatenation. (Such as when the referencing DD statement is
to contain in-stream data.) For example, the following procedure step appears in
cataloged procedure NEWONE.
//NEWONE PROC
//STEP1 EXEC PGM=TRYIT
//DD1 DD DDNAME=INSTUFF
// DD DSN=OLDSTUFF,DISP=OLD
.
.

The step that calls the procedure is:

//STEPA EXEC PROC=NEWONE
//STEP1.INSTUFF DD *
.
data
.
/*

The instream data (DDNAME=INSTUFF) is inserted before OLDSTUFF in the

concatenation.

Example 4

In the following example we create a DD concatenation in a procedure using

multiple DDNAME forward references, INPUT1—INPUT5. In the example, INPUT1

Chapter 12. DD Statement 12-79

DD: DDNAME
resolves to data set FIRST, INPUT2 resolves to data set SECOND, and INPUT3
resolves to data set THIRD. INPUT4 and INPUT5 resolve to DUMMY.

//ABC PROC
//SI EXEC PGM=IEFBR14
//DD1 DD DDNAME=INPUT1
// DD DDNAME=INPUT2
// DD DDNAME=INPUT3
// DD DDNAME=INPUT4
// DD DDNAME=INPUT5
//STEP1 EXEC ABC
//INPUT1 DD DSN=FIRST,DISP=SHR
//INPUT2 DD DSN=SECOND,DISP=SHR
//INPUT3 DD DSN=THIRD,DISP=SHR

DEST Parameter
Parameter Type

Keyword, optional

Purpose

Use the DEST parameter to specify a destination for a sysout data set. The DEST
parameter can send a sysout data set to a remote or local terminal, a node, a node
and remote workstation, a local device or group of devices, or a node and userid.

Note: Code the DEST parameter only on a DD statement with a SYSOUT

parameter. Otherwise, the system checks the DEST parameter for syntax,
then ignores it.

For more information about USERID and WRITER ID, see z/OS MVS JCL User’s
Guide.

12-80 z/OS V1R3.0 MVS JCL Reference

 DD: DEST
Syntax
DEST=destination

The destination subparameter for JES2 is one of the following:

LOCAL|ANYLOCAL
name
Nnnnn
NnnRmmmm
NnnnRmmm
NnnnnRmm
Rmmmm
RMmmmm
RMTmmmm
Unnnn
(node,userid)
userid

The destination subparameter for JES3 is one of the following:

ANYLOCAL
device-name
device-number
group-name
nodename
(node,userid)
(nodename.devicename)

Subparameter Definition for JES2 Systems

LOCAL|ANYLOCAL
Indicates the local node on a local device.
name
Identifies a destination by a symbolic name which is defined by the installation
during JES2 initialization. The name can be, for example, a local device, remote
device, or a userid. The name is 1 through 8 alphanumeric or national ($, #, @)
characters.
Nnnnn
Identifies a node. nnnn is 1 through 4 decimal numbers from 1 through 1000.
NnnRmmmm
NnnnRmmm
NnnnnRmm
(node,remote)
Identifies a node and a remote work station connected to the node. The node
number, indicated in the format by n, is 1 through 4 decimal numbers from 1
through 1000. The remote work station number, indicated in the format by m, is
1 through 4 decimal numbers from 1 through 9999. Do not code leading zeros
in n or m. The maximum number of digits for n and m combined cannot exceed
six.

Note: NnnR0 is equivalent to LOCAL specified at node Nn.

Rmmmm
RMmmmm

Chapter 12. DD Statement 12-81

DD: DEST
RMTmmmm
Identifies a remote workstation. mmmm is 1 through 4 decimal numbers from 1
through 9999. Note that with remote pooling, the installation may translate this
route code to another route code.
If you send a job to execute at a remote node and the job has a ROUTE PRINT
RMTmmmm statement, JES2 returns the output to RMTmmmm at the node of
origin. For JES2 to print the output at RMTmmmm at the executing node, code
DEST=NnnnRmmm on an OUTPUT JCL statement or sysout DD statement.

Note: R0 indicates any local device.

Unnnn
Identifies a local terminal with special routing. nnnn is 1 through 4 decimal
numbers from 1 through 9999.
If you send a job to execute and the job has a ROUTE PRINT Unnnn
statement, JES2 returns the output to Unnnn at the node of origin.
(node,userid)
Identifies a node and a TSO/E or VM userid at that node. The node is a
symbolic name defined by the installation during initialization; node is 1 through
8 alphanumeric or national ($, #, @) characters. The userid must be defined at
the node; userid for TSO/E is 1 through 7 alphanumeric or national ($, #, @)
characters and for VM is 1 through 8 alphanumeric or national ($, #, @)
characters.
DEST=(node) is valid with a writer-name subparameter in the SYSOUT
parameter; however, DEST=(node,userid) is not valid. Therefore, you can code
SYSOUT=(A,writer-name),DEST=(node), but not SYSOUT=(A,writer-
name),DEST=(node,userid).

Note: You can code DEST=(nodename,Unnnn) here; this syntax is a valid

subset of DEST=(node,userid).
userid
Identifies a userid at the local node.

Note: JES2 initialization statements determine whether or not the node name is
required when coding a userid. See your system programmer for
information regarding how routings will be interpreted by JES2.

Subparameter Definition for JES3 Systems

ANYLOCAL
Indicates any local device that is attached to the global processor.
device-name
Identifies a local device by a symbolic name defined by the installation during
JES3 initialization. device-name is 1 through 8 alphanumeric or national ($, #,
@) characters.
device-number
Identifies a specific device by a 3-digit or 4-digit hexadecimal number. Precede
a 4-digit number with a slash (/). A 3-digit number can be specified with or
without a slash.
group-name
Identifies a group of local devices, an individual remote station, or a group of

12-82 z/OS V1R3.0 MVS JCL Reference

 DD: DEST
remote stations by a symbolic name defined by the installation during JES3
initialization. group-name is 1 through 8 alphanumeric or national ($, #, @)
characters.
nodename
Identifies a node by a symbolic name defined by the installation during JES3
initialization. nodename is 1 through 8 alphanumeric or national ($, #, @)
characters. If the nodename you specify is the same as the node you are
working on, JES3 treats the output as though you specified ANYLOCAL.
(node,userid)
Identifies a node and a TSO/E or VM userid at that node. The node is a
symbolic name defined by the installation during initialization; node is 1 through
8 alphanumeric or national ($, #, @) characters. The userid must be defined at
the node; userid for TSO/E is 1 through 7 alphanumeric or national ($, #, @)
characters and for VM is 1 through 8 alphanumeric or national ($, #, @)
characters.
A userid requires a node; therefore, code DEST=(node,userid). You cannot
code a userid without a node.
DEST=(node) is valid with a writer-name subparameter in the SYSOUT
parameter: however, DEST=(node,userid) is invalid. Therefore, you can code
SYSOUT=(A,writer-name),DEST=(node).
(nodename.devicename)
Identifies by symbolic names defined by the installation during JES3
initialization, a node and a device defined to that node. nodename and
devicename are each 1 through 8 alphanumeric or national ($, #, @)
characters.
Use this form of the DEST parameter to override the ORG parameter.

Defaults
If you do not code a DEST parameter, JES directs the sysout data set to the default
destination for the input device from which the job was submitted.

In a JES3 system, if you do not code a DEST parameter, the default destination is
the submitting location. For jobs submitted through TSO/E and routed to NJE for
execution, the default is the node from which the job was submitted, and the
destination ANYLOCAL.

If a specified destination is invalid, the job fails.

If you’ve coded the ORG parameter but did not explicitly code a primary destination,
the default primary destination is the node specified in the ORG parameter, not the
submitting node.

Overrides
The DEST parameter on the sysout DD statement overrides an OUTPUT JCL
DEST parameter.

Relationship to Other Parameters

Code the DEST parameter only on a DD statement with the SYSOUT parameter.

Chapter 12. DD Statement 12-83

DD: DEST
Relationship to Other Control Statements
You can also code an output destination using:
v The OUTPUT JCL statement.
v The JES2 /*OUTPUT and /*ROUTE control statements.
v The JES3 //*MAIN, //*FORMAT PR, and //*FORMAT PU control statements.

Because DEST=(node,userid) cannot be coded on JES2 or JES3 control

statements, you must code it, if needed, on a DD or OUTPUT JCL statement.

Example of the DEST Parameter

//JOB01 JOB ,’MAE BIRD’,MSGCLASS=B
//STEP1 EXEC PGM=INTEREST
//DEBIT DD SYSOUT=A
//CALIF DD SYSOUT=A,DEST=R555
//FLOR DD SYSOUT=A,DEST=(BOCA,’9212U28’)

In this example, the system sends the sysout data set defined by DD statement
DEBIT to the work station that submitted the job, the data set defined by DD
statement CALIF to the remote terminal 555, and the data set defined by DD
statement FLOR to VM userid 9212U28 at node BOCA.

DISP Parameter
Parameter Type

Keyword, optional

Purpose

Use the DISP parameter to describe the status of a data set to the system and tell
the system what to do with the data set after termination of the step or job. You can
specify one disposition for normal termination and another for abnormal termination.

Note: Disposition of the data set is controlled solely by the DISP parameter;
disposition of the volume(s) on which the data set resides is a function of
the volume status when the volume is demounted. If the UNIT parameter
specifies a device, such as a printer or telecommunications device, that does
not involve a data set, do not code the DISP parameter.

If the system obtains unit and volume information for an OLD, MOD, or SHR status,
the data set is treated as if it exists, whether or not it is physically on the device.

When any step of a job requests exclusive control of a data set, the system
converts all requests for shared control of that data set within that job (DISP=SHR)
to requests for exclusive control. One of two methods can be used to request
exclusive control:
v DISP=NEW, DISP=MOD, or DISP=OLD on a JCL request.
v DISP=NEW, DISP=MOD, or DISP=OLD on a dynamic allocation request,
including dynamic allocation requests that result from the use of certain utility
control statements. For example, utility control statements that delete/scratch a
data set will result in exclusive use of that data set.

12-84 z/OS V1R3.0 MVS JCL Reference

 DD: DISP
When any step of a job requests exclusive control of a data set (through
DISP=NEW, DISP=MOD, or DISP=OLD), the system converts all requests for
shared control of that data set within that job (DISP=SHR) to requests for exclusive
control.

References

For information about tape data set processing, see z/OS DFSMS: Using Magnetic
Tapes.

Syntax
{DISP=status }
{DISP=([status][,normal-termination-disp][,abnormal-termination-disp])}

DISP= ( [NEW] [,DELETE ] [,DELETE ] )

[OLD] [,KEEP ] [,KEEP ]
[SHR] [,PASS ] [,CATLG ]
[MOD] [,CATLG ] [,UNCATLG]
[, ] [,UNCATLG]
[, ]

v You can omit the parentheses if you code only the status subparameter.
v If you omit the status subparameter but code subparameters for normal or abnormal
termination disposition, you must code a comma to indicate the absence of NEW. For
example, DISP=(,KEEP) or DISP=(,CATLG,DELETE).
v If you omit the second subparameter but code the third, you must code a comma to
indicate the absence of the second subparameter. For example, DISP=(OLD,,DELETE)
or DISP=(,,KEEP).

Subparameter Definition
Status Subparameter
NEW
Indicates that a new data set is to be created in this step.

Note: Initialize a new data set to ensure that it is empty.

OLD
Indicates that the data set exists before this step and that this step requires
exclusive (unshared) use of the data set.
If you specify DISP=OLD for an output tape data set and (1) the data set is not
protected by RACF or a password or (2) the data set has no expiration date,
the system does not verify the data set name in the header label.
SHR
Indicates that the data set exists before this step and that other jobs can share
it, that is, use it at the same time. This subparameter can also be coded as
SHARE.
If you specify DISP=SHR for an output tape data set and (1) the data set is not
protected by RACF or a password or (2) the data set has no expiration date,
the system does not verify the data set name in the header label.
MOD
Indicates one of the following:

Chapter 12. DD Statement 12-85

DD: DISP
v The data set exists and records are to be added to the end of it. The data
set must be sequential.
v A new data set is to be created.

In either case, MOD specifies exclusive (unshared) use of the data set.

When the data set is opened, the read/write mechanism is positioned after the
last sequential record for an existing data set or at the beginning for a new data
set. For subsequent OPENs within the same step, the read/write mechanism is
positioned after the last sequential record.

Note: You cannot specify DISP=MOD to extend an ISO/ANSI/FIPS Version 3

tape data set unless the ISO/ANSI/FIPS Version 3 label validation
installation exit allows the extension. For information on using
ISO/ANSI/FIPS Version 3 installation exits, see z/OS DFSMS: Using
Magnetic Tapes.

If the system cannot find volume information for the data set on the DD
statement, in the catalog, or passed with the data set from a previous step, the
system assumes that the data set is being created in this job step. For a new
data set, MOD causes the read/write mechanism to be positioned at the
beginning of the data set.

To use DISP=MOD to create a new data set, code one of the following:
v No VOLUME=SER or VOLUME=REF parameter on the DD statement. The
data set must not be cataloged or passed from another job step.
v A VOLUME=REF parameter that refers to a DD statement that makes a
nonspecific volume request. (A nonspecific volume request is a DD statement
for a new data set that can be assigned to any volume or volumes.) One of
the following must also be true:
– The DSNAME parameters in the two DD statements must be different.
– The two DD statements must request different areas of the same ISAM
data set.
v In the case of tape, if you do not specify an explicit volume serial number on
the DD statement, the system requests the operator to mount a ″scratch″
tape.
For a new generation of a generation data group (GDG) data set (where (+n)
is greater than 0), you may code VOLUME=REF or VOLUME=SER.
For an SMS-managed data set the system ignores the volume.

After the system chooses a volume for a new data set, if the system finds
another data set with the same name on that volume, the system will try to
allocate a different volume. However, SMS-managed data sets require unique
data set names. If a new data set is chosen to be SMS-managed and an
existing SMS-managed data set has the same name, the request fails.

In a JES3 system, if you code DISP=MOD for a multivolume data set and any
of the volumes are JES3-managed, JES3 will not execute the job until all
volumes, including scratch volumes being added, are allocated. Such a job will
wait on the queue until all volumes are allocated.

If you are using DISP=MOD for an existing data set, see Determining the Last
Volume on page 12-91.

12-86 z/OS V1R3.0 MVS JCL Reference

 DD: DISP
Normal Termination Disposition Subparameter
DELETE
Indicates that the data set is no longer needed if this step terminates normally.
For a DASD data set, DELETE means that the space occupied by that data set
is available for use by other data sets. The system will physically erase the data
set itself only if the erase option of a security product, such as RACF, is in
effect for this data set. If the erase option is not in effect, the data will remain
on the DASD until overwritten by another data set. For information on how to
set the erase option, see the documentation for the security product.
For a tape data set, DELETE does not physically erase the data from the tape
volume. The data will remain on the tape until overwritten by another data set. If
the tape volume is a public volume, specifying DELETE allows the system to
reuse the tape volume for other data sets that require a public volume; the
system may overwrite the data set.
Existing data sets:
v If you set a retention period on the DD RETPD parameter, an existing data
set is deleted only if its retention period is passed; otherwise the data set is
kept.
v If you set an expiration date on the DD EXPDT parameter, an existing data
set is deleted if the expiration date has passed.
If the storage administrator specified OVRD_EXPDT(YES) in the IGDSMSxx
member of SYS1.PARMLIB, you can override the expiration date or retention
period for SMS-managed data sets by specifying DELETE on the DD DISP
parameter. In that case, the data set will be deleted whether or not the
expiration date or the retention period has passed. See z/OS MVS
Initialization and Tuning Reference for information on the IGDSMSxx parmlib
member.

New data sets:

A new data set is deleted at the end of the step even though a retention period
or expiration date is also specified. See the DD EXPDT or RETPD parameters.

If the system retrieves volume information from the catalog because the DD
statement does not specify VOLUME=SER or VOLUME=REF, then DELETE
implies UNCATLG: the system deletes the data set and removes its catalog
entry.
KEEP
Indicates that the data set is to be kept on the volume if this step terminates
normally.
Without SMS, only KEEP is valid for VSAM data sets. VSAM data sets should
not be passed, cataloged, uncataloged, or deleted.
With SMS, all dispositions are valid for VSAM data sets; however, UNCATLG is
ignored.
For new SMS-managed data sets, KEEP implies CATLG.
PASS
Indicates that the data set is to be passed for use by a subsequent step in the
same job.

Chapter 12. DD Statement 12-87

DD: DISP
With SMS, the system replaces PASS with KEEP for permanent VSAM and
non-VSAM data sets. When you refer to the data set later in the job, the system
obtains data set information from the catalog.
Notes:
1. A data set can be passed only within a job.
2. If you specify DISP=(NEW,PASS) but, at the end of the job, one or more
data sets were not received by any job step, then the maximum number of
DD statements you can specify decreases by one. (The size of the TIOT
controls how many DD statements are allowed per job step.) For example, if
the current limit is 1635 DD statements, you can specify
DISP=(NEW,PASS), and up to 1634 DD statements.
3. Coding PASS does not ensure that the operator will not unload the volume
or that the system will not demount it to accommodate another job step
allocation. Either can occur when the device on which the volume is
mounted is not allocated to the job step that specified PASS or, for
unlabaled tapes, when the volume requires verification. If the system does
demount a volume for which RETAIN was requested, it will do so by issuing
message IEF234E R (retain) for that volume. When the system reaches the
next step requiring that volume, it will request the operator to remount the
volume on an available device of the appropriate type.
CATLG
Indicates that, if the step terminates normally, the system is to place an entry
pointing to the data set in the system or user catalog. For CVOL catalogs, the
system creates any missing index levels. Note that the data set is kept.
An unopened tape data set is cataloged, unless the volume request is
nonspecific or unless the data set is allocated to a dual-density tape drive but
no density is specified. A nonspecific volume request is a DD statement for a
new data set that can be assigned to any volume or volumes.
For information about the rules for cataloged data set names, see z/OS DFSMS
Access Method Services for Catalogs.
UNCATLG
Indicates that, if the step terminates normally, the system is to delete (1) the
entry pointing to the data set in the system or user catalog and (2) unneeded
indexes, except for the highest level entry. Note that the data set is kept.
With SMS, UNCATLG is ignored for SMS-managed data sets and VSAM data
sets (KEEP is implied).

Abnormal Termination (Conditional) Disposition Subparameter

DELETE
Indicates that the data set’s space on the volume is to be released if this step
terminates abnormally. The space can be used for other data sets; the data set
is not erased from the space.
Existing data sets:
v If you set a retention period on the DD RETPD parameter, an existing data
set is deleted only if its retention period is passed; otherwise the data set is
kept.
v If you set an expiration date on the DD EXPDT parameter, an existing data
set is deleted if the expiration date has passed.
You can override the expiration date or retention period for SMS-managed
DASD data sets using the OVRD_EXPDT(YES) parameter in the IGDSMSxx
SYS1.PARMLIB member. In that case, the data set will be deleted whether or

12-88 z/OS V1R3.0 MVS JCL Reference

 DD: DISP
not the data set has expired or the retention period has passed. See z/OS
MVS Initialization and Tuning Reference for information on the IGDSMSxx
parmlib member.

New data sets:

A new data set is deleted at the end of the step even though a retention period
or expiration date is also specified. See the DD EXPDT or RETPD parameters.

If the system retrieves volume information from the catalog because the DD
statement does not specify VOLUME=SER or VOLUME=REF, then DELETE
implies UNCATLG: the system deletes the data set and removes its catalog
entry.

For a cataloged, passed data set, the user catalog is not updated.
KEEP
Indicates that the data set is to be kept on the volume if this step terminates
abnormally.
Without SMS, only KEEP is valid for VSAM data sets. VSAM data sets should
not be passed, cataloged, uncataloged, or deleted.
With SMS, all dispositions are valid for VSAM data sets; however, UNCATLG is
ignored.
For new SMS-managed data sets, KEEP implies CATLG.
CATLG
Indicates that, if the step terminates abnormally, the system is to place an entry
pointing to the data set in the system or user catalog. For CVOL catalogs, the
system creates any missing index levels. Note that the data set is kept.
An unopened tape data set is cataloged, unless the volume request is
nonspecific or unless the data set is allocated to a dual-density tape drive but
no density is specified.
For a cataloged, passed data set, the user catalog is not updated. A passed,
not received data set is not cataloged if the data set name has a first-level
qualifier of a catalog name or alias.
UNCATLG
Indicates that, if this step terminates abnormally, the system is to delete (1) the
entry pointing to the data set in the system or user catalog and (2) unneeded
indexes, except for the highest level entry. Note that the data set is kept.
For a cataloged, passed data set, the user catalog is not updated.
With SMS, UNCATLG is ignored for SMS-managed data sets and VSAM data
sets (KEEP is implied).

Defaults
v If you omit the status subparameter, the default is NEW.
v If you omit the normal termination disposition subparameter, the default is
DELETE for a NEW data set or KEEP for an existing data set.
v If you omit the abnormal termination disposition subparameter, the default is the
disposition specified or implied by the second subparameter. However, if the
second subparameter specified PASS, the default abnormal termination
disposition is DELETE for a NEW data set or KEEP for an existing data set.

Chapter 12. DD Statement 12-89

 DD: DISP
v If you omit the DISP parameter, the default is a NEW data set with a disposition
of DELETE for both normal and abnormal termination disposition. Thus, you can
omit the DISP parameter for a data set that is created and deleted during a step.

Relationship to Other Parameters

Do not code the following parameters with the DISP parameter.

* DDNAME SYSOUT
BURST DYNAM
CHARS FLASH
COPIES MODIFY
DATA QNAME

Disposition of QSAM Data Sets

Do not code DISP=MOD if the data control block (DCB) specifies RECFM=FBS and
the data set is processed by QSAM. If you do and a block is shorter than the
specified block size, QSAM assumes that the short block is the last block and starts
end-of-file processing. By this action, QSAM can embed short blocks in your data
set and so affect the number of records per track.

Disposition of Generation Data Sets

See Appendix B in z/OS MVS JCL User’s Guide for additional information about
disposition processing for generation data sets.

Disposition of Temporary Data Sets

Specify a normal termination disposition of PASS or DELETE for a temporary data
set or for a data set with a system-generated name, that is, when a DSNAME
parameter is omitted from the DD statement.

| For a temporary data set name, the system ignores any abnormal termination
| disposition specified in the third subparameter and always PASSes the data set to
| subsequent steps.

Disposition of Partitioned Data Sets (PDSs and PDSEs)

When you specify DISP=MOD or DISP=NEW for a partitioned data set (PDS) or
partitioned data set extended (PDSE), and you also specify a member name in the
DSNAME parameter, the member name must not already exist. If the member
name already exists, the system terminates the job.

When you specify DISP=OLD for a PDS or a PDSE, and you also specify a
member name in the DSNAME parameter, the data set must already exist. If the
member name already exists and the data set is opened for output, the system
replaces the existing member with the new member. If the member name does not
already exist and the data set is opened for output, the system adds the member to
the data set.

When you specify DISP=MOD for a PDS or a PDSE, and you do not specify a
member name, the system positions the read/write mechanism at the end of the
data set. The system does not make an automatic entry into the directory.

12-90 z/OS V1R3.0 MVS JCL Reference

 DD: DISP
When you specify DISP=MOD for a PDS or a PDSE, and you do specify a member
name, the system positions the read/write mechanism at the end of the data set. If
the member name already exists, the system terminates the job.

When you specify DISP=SHR for a partitioned data set extended (PDSE) and also
specify a member name, then:
v If the member name exists, the member can have one writer or be shared by
multiple readers, or
v If the member name does not exist, the member can be added to the data set.
Thus, multiple jobs can access different members of the data set and add new
members to the data set concurrently — but concurrent update access to a
specific member (or update and read by other jobs) is not valid.

Adding a Volume to a Cataloged Data Set

If you want to add a volume to a cataloged data set and have it properly cataloged
after it is kept or passed, code the volume count subparameter of the VOLUME
parameter to make the system use the values in the system catalog to process the
data set. The following DD statement shows how to keep and extend a cataloged
data set using the system catalog. Assume that this data set was created with a
volume count of 2.
//DDEX2 DD DSNAME=OPER.DATA,DISP=(MOD,KEEP),
// VOLUME=(,,,3),UNIT=(,P)

The VOLUME parameter references the system catalog for volume information
about the data set and increases the maximum number of volumes for
OPER.DATA. Because the UNIT parameter requests parallel mounting, the system
must allocate the same number of units as the number of volumes in the VOLUME
parameter; in this case, 3.

The following is an example of the messages in the job log after the job completes.
IEF285I OPER.DATA KEPT
IEF285I VOL SER NOS= 333001,333002,333003.
IEF285I OPER.DATA RECATALOGED
IEF285I VOL SER NOS= 333001,333002,333003.

Non-SMS-managed Data Sets

If you do not reference the catalog when adding a volume to a cataloged data set,
the system does not update the catalog with the newly referenced volumes.

DISP=MOD for a Multivolume Data Set

Minimizing Tape Mounts
When you code DISP=MOD and the volume information is for a multivolume data
set, normally the first volume(s) will be mounted on the devices(s) allocated. Then,
if the data set is opened for output, OPEN starts with the last volume. If the number
of tape volumes is more than the number of allocated devices, the system asks the
operator to demount the first volume(s) and mount the last. To have the last tape
volume mounted without first mounting and then demounting the earlier volume(s),
code VOLUME=REF or DEFER in the UNIT parameter, or a volume sequence
number in the VOLUME parameter.

Determining the Last Volume

If a data set that is not a striped data set resides on multiple volumes, you can
code a volume sequence number to specify the volume on which reading or writing

Chapter 12. DD Statement 12-91

DD: DISP
is to begin. If you do not code a volume sequence number and the data set is not
striped, the system must identify the volume that contains the logical end of the
data. Data might not have been written on all the volumes. After the system
identifies the last volume, it positions the read/write mechanism on that volume.

In DASD and tape data set labels there is an indicator on the last volume
containing user data. When you do not specify a volume sequence number, the
system looks in the data set label for the indicator that identifies the last volume,
and then selects the volume on which to begin writing as follows:

SMS-managed DASD

The system tests the data set label on the first volume in the list. If the label
indicates it contains the end of the data set, the system selects that volume.
Otherwise, it checks each subsequent volume until it finds one that has a
last-volume indicator. (To begin writing, the system will not select later volumes that
might also have the last-volume indicator by virtue of having previously contained
parts of the data set.)

Non-SMS-managed DASD

The system tests the last volume in the list. If it contains a label for the data set,
and the label indicates it is the last volume of the data set, the system selects that
volume to begin writing. If that volume does not have a label for the data set or that
label does not have the last-volume indicator, the system checks the first and
subsequent volumes until it finds a last-volume indicator or until it tests the
second-to-last volume. If the last volume in the list once had the end of the data set
but now the data set requires fewer volumes, the system selects the wrong volume,
and any data you add will not be retrievable by normal access.

Tape

For tapes with IBM standard or ANSI/ISO/FIPS labels, the system reads trailer
labels on each volume starting with the first volume, and selects the first volume
that ends with an end-of-file label instead of an end-of-volume label. For unlabeled
tapes and those with the BLP option, the system selects the first volume.

Extending on a Volume Other Than the Last

When you code DISP=MOD for a multivolume data set, use the volume count and
volume sequence number subparameters of the VOLUME parameter if you want to
keep the system from positioning the read/write mechanism after the last record on
the last volume. For example:
//DDEX1 DD DSNAME=OPER.DATA,DISP=(MOD,KEEP),VOLUME=(,,1,2)

The volume sequence number of 1 specifies that you want to use the first volume,
and the volume count of 2 specifies that the data set requires two volumes.

Effect of DCB=dsname Parameter

If the DCB parameter refers to a cataloged data set, the system obtains the volume
sequence number from the label of the data set, unless the volume sequence
number is coded on the DD statement.

Thus, for the following DD statement, even though DISP=MOD is specified, the
system positions the read/write mechanism after the last record on the volume
specified in the volume sequence number in the label; this volume may or may not
be the last volume.

12-92 z/OS V1R3.0 MVS JCL Reference

 DD: DISP
//DD1 DD DSNAME=MULTI1,DISP=MOD,DCB=CATDD

To control which volume is processed, code a volume sequence number.

//DD2 DD DSNAME=MULTI2,DISP=MOD,DCB=CATDD,VOLUME=(,,2)

Summary of Disposition Processing

Table 12-1. Summary of Disposition Processing
DISP Subparameters: Disposition (If Data Set was Allocated):
Status Normal Abnormal At Normal At Abnormal End of Step At End of Job
Termination Termination End of Step
Step If Later
Disposition Disposition
Abnormally Allocation
Terminated Failed in Step
NEW none deleted deleted
permanent
KEEP kept kept
data set deleted
or MOD DELETE none deleted deleted
treated CATLG cataloged cataloged
as new
PASS passed passed passed deleted
DELETE If all steps
KEEP terminated
CATLG normally:
UNCATLG deleted
If a step
PASS passed passed passed
terminated
abnormally:
third
subparameter
disposition
DELETE KEEP second kept
KEEP subparameter
DELETE deleted deleted
CATLG disposition
UNCATLG CATLG cataloged
NEW none DELETE deleted
temporary KEEP
DELETE deleted deleted
data set CATLG
PASS UNCATLG passed deleted
NEW DELETE DELETE
data set in KEEP KEEP
step to be PASS CATLG deleted
automatically CATLG UNCATLG
restarted UNCATLG
NEW DELETE DELETE kept, if being
data set in KEEP KEEP used when
step to be PASS CATLG checkpoint
restarted at CATLG UNCATLG was taken
checkpoint UNCATLG

Chapter 12. DD Statement 12-93

DD: DISP
Table 12-1. Summary of Disposition Processing (continued)
DISP Subparameters: Disposition (If Data Set was Allocated):
Status Normal Abnormal At Normal At Abnormal End of Step At End of Job
Termination Termination End of Step
Step If Later
Disposition Disposition
Abnormally Allocation
Terminated Failed in Step
OLD or SHR none kept
or MOD kept kept
KEEP
treated
as old DELETE deleted deleted
CATLG cataloged or, if cataloged or, if
none new volumes new volumes
were added, were added,
recataloged recataloged
UNCATLG uncataloged uncataloged
PASS passed passed passed kept
OLD or SHR PASS DELETE passed passed passed If all steps
or MOD KEEP terminated
treated CATLG normally: kept,
as old UNCATLG if originally old;
(continued) deleted, if
originally new
If a step
terminated
abnormally:
third
subparameter
disposition
DELETE KEEP second kept kept, if step
KEEP parameter was receiving
CATLG DELETE disposition deleted originally
UNCATLG CATLG cataloged or, if old data set;
new volumes deleted, if
were added, step was
recataloged receiving
originally
UNCATLG uncataloged new data set
OLD none none deleted, if deleted, if
permanent data set was data set was
data set originally originally
passed to new; kept, if new; kept, if
this job step originally old originally old
OLD DELETE DELETE kept
data set in KEEP KEEP
step to be PASS CATLG
automatically CATLG UNCATLG
restarted UNCATLG
OLD DELETE DELETE kept, if being
data set in KEEP KEEP used when
step to be PASS CATLG checkpoint
restarted at CATLG UNCATLG was taken
checkpoint UNCATLG

12-94 z/OS V1R3.0 MVS JCL Reference

 DD: DISP
Examples of the DISP Parameter
Example 1
//DD2 DD DSNAME=FIX,UNIT=3420-1,VOLUME=SER=44889,
// DISP=(OLD,,DELETE)

DD statement DD2 defines an existing data set and implies by the omitted second
subparameter that the data set is to be kept if the step terminates normally. The
statement requests that the system delete the data set if the step terminates
abnormally.

Example 2
//STEPA EXEC PGM=FILL
//DD1 DD DSNAME=SWITCH.LEVEL18.GROUP12,UNIT=3350,
// VOLUME=SER=LOCAT3,SPACE=(TRK,(80,15)),DISP=(,PASS)
//STEPB EXEC PGM=CHAR
//DD2 DD DSNAME=XTRA,DISP=OLD
//DD3 DD DSNAME=*.STEPA.DD1,DISP=(OLD,PASS,DELETE)
//STEPC EXEC PGM=TERM
//DD4 DD DSNAME=*.STEPB.DD3,DISP=(OLD,CATLG,DELETE)

DD statement DD1 defines a new data set and requests that the data set be
passed. If STEPA abnormally terminates, the data set is deleted because it is a new
data set, the second subparameter is PASS, and an abnormal termination
disposition is not coded.

DD statement DD3 in STEPB receives this passed data set and requests that the
data set be passed. If STEPB abnormally terminates, the data set is deleted
because of the third subparameter of DELETE.

DD statement DD4 in STEPC receives the passed data set and requests that the
data set be cataloged at the end of the step. If STEPC abnormally terminates, the
data set is deleted because of the abnormal termination disposition of DELETE.

DD statement DD2 defines an old data set named XTRA. When STEPB terminates,
normally or abnormally, this data set is kept.

Example 3
//SMSDD5 DD DSNAME=MYDS5.PGM,DATACLAS=DCLAS05,STORCLAS=SCLAS05,
// DISP=(NEW,KEEP)

DD statement SMSDD5 defines a new SMS-managed data set and requests that
the data set be kept (which implies that it be cataloged).

Example 4
//SMSDD7 DD DSNAME=MYDS7.PGM,DISP=(OLD,UNCATLG)

DD statement SMSDD7 defines an existing SMS-managed data set (the data set
had been assigned a storage class when it was created) and requests that the data
set be uncataloged. However, the data set is kept because UNCATLG is ignored for
SMS-managed data sets.

Chapter 12. DD Statement 12-95

DD: DLM

DLM Parameter
Parameter Type

Keyword, optional

Purpose

Use the DLM parameter to specify a delimiter to terminate this in-stream data set.
When the DLM parameter assigns a different delimiter, the in-stream data records
can include standard delimiters, such as /* and //, in the data.

In a JES2 system, when the DLM delimiter appears on a DD * statement, either

the assigned delimiter or // ends the input data set. When the DLM delimiter
appears on a DD DATA statement, only the assigned delimiter ends the input data
set.

In a JES3 system, when the DLM delimiter appears on either a DD * or DD DATA

statement, only the assigned delimiter ends the input data set.

Note: When the DLM delimiter overrides any implied delimiter, you must terminate
the data with the DLM characters. Otherwise, the system keeps reading until
the reader is empty.

Except for the JES2 /*SIGNON and /*SIGNOFF statements, the system does not
recognize JES2 and JES3 statements in an input stream between the DLM
parameter and the delimiter it assigns. The JES2 /*SIGNON and /*SIGNOFF
statements are processed by the remote work station regardless of any DLM
delimiter.

Considerations for an APPC Scheduling Environment

The DLM parameter has no function in an APPC scheduling environment. If you

code DLM, the system will check it for syntax and ignore it.

Syntax
DLM=delimiter

v If the specified delimiter contains any special characters, enclose it in apostrophes. In this
case, a special character is any character that is neither alphanumeric nor national ($, #,
@).
Failing to code enclosing apostrophes produces unpredictable results.
v If the delimiter contains an ampersand or an apostrophe, code each ampersand or
apostrophe as two consecutive ampersands or apostrophes. Each pair of consecutive
ampersands or apostrophes counts as one character.
v The DLM parameter can have a null value only when coded on a DD which either:
– Overrides a DD in a procedure
– Is added to a procedure.

12-96 z/OS V1R3.0 MVS JCL Reference

 DD: DLM
Subparameter Definition
delimiter
Specifies two characters that indicate the end of this data set in the input
stream.

Default
If you do not specify a DLM parameter, the default is the /* delimiter statement.

If the system finds an error on the DD statement before the DLM parameter, it does
not recognize the value assigned as a delimiter. The system reads records until it
reads a record beginning with /* or //.

Relationship to Other Parameters

Code the DLM parameter only on a DD statement with the * or DATA parameter.

The DLM parameter has meaning only on statements defining data in the input
stream, that is, DD * and DD DATA statements. If DLM is specified on any other
statement, a JCL error message is issued.

Invalid Delimiters
If the delimiter is not two characters:
v For JES2, the delimiter is not recognized. The in-stream data set is terminated
when a record starting with // or /* is read. The system fails the job due to the
invalid delimiter.
v For JES3, if an incorrect number of characters is coded, JES3 terminates the
job.

Example of the DLM Parameter

//DD1 DD *,DLM=AA
.
.
data
.
AA

The DLM parameter assigns the characters AA as the delimiter for the data defined
in the input stream by DD statement DD1. For JES2, the characters // would also
serve as valid delimiters since a DD * statement was used. JES3 accepts only the
characters specified for the DLM parameter as a terminator for DD * or DD DATA.

DSID Parameter
Parameter Type

Keyword, optional

Purpose

Use the DSID parameter to specify the data set identifier of an input or output data
set on a diskette of the 3540 Diskette Input/Output Unit.

Chapter 12. DD Statement 12-97

DD: DSID
An input data set is read from a 3540 diskette by a diskette reader program, and an
output data set is written on a 3540 diskette by a diskette writer, which is an
external writer.

To read a data set from a 3540 diskette, the DD statement must contain:
v A DSID parameter.
v An * or DATA parameter, to begin the input stream data set.

To write a data set on a 3540 diskette, the DD statement must contain:

v A DSID parameter.
v A SYSOUT parameter that specifies the output class that the diskette writer
processes and the name of the diskette writer.

Also, a system command, from the operator or in the input stream, must start the
diskette writer before this DD statement is processed.

Note: The system ignores the DSID parameter on a DD *, DD DATA, or a DD

statement with the SYSOUT parameter, except when a diskette reader or
writer processes the JCL.

References

For more information about associated data sets, see 3540 Programmer’s
Reference. For information about external writers, see z/OS JES2 Initialization and
Tuning Guide or z/OS JES3 Initialization and Tuning Guide.

Syntax
DSID= {id }
{(id,[V])}

v You can omit the parentheses if you code only an id.

v Null positions in the DSID parameter are invalid.

Subparameter Definition
id Specifies the data set identifier. The id is 1 through 8 characters. The
characters must be alphanumeric, national ($, #, @), a hyphen, or a left
bracket. The first character must be alphabetic or national ($, #, @).
V Indicates that the data set label must have been previously verified on a 3741
Data Station/Workstation. This subparameter is required only on a SYSIN DD
statement.

Relationship to Other Parameters

Do not code the following parameters with the DSID parameter.

BURST FLASH
CHARS MODIFY
DDNAME MVSGP
DYNAM QNAME

For 3540 Diskette Input/Output Units

12-98 z/OS V1R3.0 MVS JCL Reference

 DD: DSID
A DSID parameter on a DD *, DD DATA, or sysout DD statement is ignored except
when detected by a diskette reader as a request for an associated data set. See
3540 Programmer’s Reference.

On a DD * or DD DATA statement processed by a diskette reader, you can specify

DSID, VOLUME=SER, BUFNO, and LRECL to indicate that a diskette data set is to
be merged into the input stream following the DD statement.

Example of the DSID Parameter

//JOB1 JOB ,,MSGLEVEL=(1,1)
//STEP EXEC PGM=AION
//SYSIN DD *,DSID=(ABLE,V),VOLUME=SER=123456,
// DCB=LRECL=80
//SYSPRINT DD SYSOUT=E,DCB=LRECL=128,DSID=BAKER

In this example, the SYSIN DD statement indicates that the input is on diskette
123456 in data set ABLE and must have been verified. The output will be written on
a diskette in data set BAKER.

DSNAME Parameter
Parameter Type

Keyword, optional

Purpose

Use the DSNAME parameter to specify the name of a data set. For a new data set,
the specified name is assigned to the data set; for an existing data set, the system
uses the name to locate the data set.

References

Data sets are described in z/OS DFSMS: Using Data Sets.

In a DFSMS-active environment, the names of all data sets that are to be cataloged
or SMS-managed must conform to the rules for cataloged data set names. For
information about the rules for cataloged data set names, refer to either z/OS
DFSMS Access Method Services for Catalogs.

Chapter 12. DD Statement 12-99

DD: DSNAME
Syntax
{DSNAME} =name
{DSN }

name for permanent data set:

dsname
dsname(member)
dsname(generation)
dsname(area)

name for temporary data set:

&&dsname
&&dsname(member)
&&dsname(area)

name for in-stream or sysout data set:

&&dsname

name copied from earlier DD statement:

*.ddname
*.stepname.ddname
*.stepname.procstepname.ddname

name for dummy data set:

NULLFILE

v You can abbreviate DSNAME as DSN.

v Avoid starting a data set name with JES or SYS1. The system uses these characters for
system data sets.
v If the data set name begins with a blank character, the system assigns the data set with
a unique temporary data set name, and ignores the name specified on the DSNAME
parameter
v The system ignores blank characters at the end of a data set name.
v Blanks can be included in a data set name if the name is enclosed in apostrophes, such
as DSNAME='AB CD'. However, do not code blanks in the name for an in-stream or
sysout data set; for example, SYSOUT=P,DSNAME='&&AB CD' is not valid.
v If the data set is to be managed through SMS, you cannot enclose the data set name in
apostrophes. However, the following exception applies: You can enclose the data set
name on the DSNAME parameter in apostrophes if the data set is to be assigned to, or
already resides on, an SMS-managed mountable tape volume. This exception applies
only if DFSMS/MVS 1.1 or later is installed.
v Any data set name enclosed in apostrophes on the DSNAME parameter will be treated
as an unqualified name. Data sets with an unqualified name cannot be cataloged.
v The system does not check data set names enclosed in apostrophes for valid characters
or valid length. When SMS is not installed or active incorrect characters or length result
in data set allocation, but the data set is not cataloged. When SMS is active, it will fail the
job for incorrect characters or length.

12-100 z/OS V1R3.0 MVS JCL Reference

 DD: DSNAME
Non-Significant Special Characters: When a data set name contains special characters
that are not significant to the system, other than hyphens, enclose it in apostrophes. For
example, DSNAME='DS/29'.

Code each apostrophe that is part of the data set name as two consecutive apostrophes.
For example, code DAYS'END as DSNAME='DAYS''END'.

The system ignores blank characters at the end of a data set name, even if the data set
name is enclosed in apostrophes.

Significant Special Characters: The following special characters are significant to the
system. Do not enclose them in apostrophes.
v Periods to indicate a qualified data set name. However, you must enclose in apostrophes
a period immediately before a right parenthesis, immediately after a left parenthesis, or
immediately before a comma; for example, DSNAME='(.ABC)' and DSNAME='(ABC.)'
and DSNAME='A.B.C.'.
v Double ampersands to identify a temporary data set name. Note that if you use
apostrophes, DSNAME='&&AB' and DSNAME='&AB' refer to the same data set.
v Double ampersands to identify an in-stream or sysout data set name.
v Parentheses to enclose the member name of a partitioned data set (PDS) or partitioned
data set extended (PDSE), the area name of an indexed sequential data set, or the
generation number of a generation data set.
v Plus (+) or minus (-) sign to identify a generation of a generation data group.
v The asterisk to indicate a backward reference.

On a DD statement in a cataloged or in-stream procedure, if the data set name is a

symbolic parameter, do not enclose it in apostrophes. If it is enclosed in apostrophes, the
system performs correct substitution only if the symbolic parameter enclosed in apostrophes
is preceded by a symbolic parameter not enclosed in apostrophes.

The data set name should not contain the 44 special characters (X'04') created by the
12-4-9 multiple punch or any operation that converts the value of characters to X'04'.

Subparameter Definition
The data set names you specify on DSNAME are described in the following topics:
v Data Set Name for Permanent Data Set
v Data Set Name for Temporary Data Set
v Data Set Name for In-Stream or Sysout Data Set
v Data Set Name Copied from Earlier DD Statement
v Data Set Name for Dummy Data Set

Data Set Name for Permanent Data Set

Assign a permanent data set either an unqualified or a qualified name:

Unqualified Name
1 through 8 alphanumeric or national ($, #, @) characters, a hyphen, or a character
X'C0'. The first character must be alphabetic or national ($, #, @). For example,
DSNAME=ALPHA is an unqualified data set name.

For the characters allowed in ISO/ANSI/FIPS tape data set names, see information
about label definition and organization in z/OS DFSMS: Using Magnetic Tapes.

Qualified Name
Multiple unqualified names joined by periods. Each qualifier is coded like an
unqualified name; therefore, the name must contain a period after every 8
characters or fewer. For example, DSNAME=ALPHA.PGM is a qualified data set
name. The maximum length of a qualified data set name is:

Chapter 12. DD Statement 12-101

DD: DSNAME
v 44 characters, including periods.
v For a generation data group, 35 characters, including periods.
v For an output tape data set, 17 characters, including periods. If longer than 17
characters, only the rightmost 17 characters, excluding trailing blanks, are written
to the tape header label. For more information, see z/OS DFSMS: Using
Magnetic Tapes .

Name for RACF-Protected Data Set

The OS/390 Security Server, which includes RACF, expects the data set name to
have a high-level qualifier that is defined to RACF. See the z/OS Security Server
RACF Security Administrator’s Guide for details. RACF uses the entire data set
name, from 1 through 44 characters, when protecting a tape data set.

Cataloged Data Set Name

For information about the rules for cataloged data set names, see z/OS DFSMS
Access Method Services for Catalogs.
dsname
Specifies a data set name.
dsname(member)
Specifies the name of permanent partitioned data set (PDS) or partitioned data
set extended (PDSE), and the name of a member within that data set.
member
1 to 8 alphanumeric or national characters, or a character X'C0'. The first
character must be alphabetic, national, +, or −. If the first character is + or
−, the member is a part of a generation data group.
dsname(generation)
Specifies the name of a generation data group (GDG) and the generation
number (zero or a signed integer) of a generation data set within the GDG.

Note: A VSAM data set cannot be a generation data set.

generation
v The first character of a relative generation number is +, −, or 0.
v All characters of a relative generation number that follow the +, −, or 0
must be numeric (0 through 9).
v The numeric portion (not + or −) of a relative generation number must be
expressed in 1 to 3 numeric characters. For example, +100, −002, +4,
−09, 000.
v A relative generation number cannot exceed 255.

To retrieve all generations of a generation data group, omit the generation

number.
dsname(area)
Specifies the name of a permanent indexed sequential data set and an area of
the data set. The area-name is INDEX, PRIME, or OVFLOW.
If you define an indexed sequential data set on only one DD statement, omit the
area name or code it as PRIME. For example, DSNAME=dsname or
DSNAME=dsname(PRIME).
To retrieve an indexed sequential data set, omit the area name.

12-102 z/OS V1R3.0 MVS JCL Reference

 DD: DSNAME
Data Set Name for Temporary Data Set
A temporary data set is a data set that you create and delete within a job. (For
information about coding data set names with the DD *, DATA, and SYSOUT
parameters, see ″Data Set Name for In-Stream or Sysout Data Set.″)

Note: SMS manages a temporary data set if you specify a storage class (with the
DD STORCLAS parameter) or if an installation-written automatic class
selection (ACS) routine selects a storage class for the temporary data set.

When you define a temporary data set, you can code the DSNAME parameter or
omit it; in either case, the system generates a qualified name for the temporary data
set.

When you use DSNAME for a temporary data set, code the name as two
ampersands (&&) followed by a character string 1 to 8 characters in length:
v The first character following the ampersands must be alphabetic or national.
v The remaining characters must be alphanumeric or national.

The format of the qualified name the system generates depends on whether or not
you specified a data set name on the DSNAME parameter:
v All temporary data set names begin as follows:
SYSyyddd.Thhmmss.RA000.jjobname

where:
yy indicates the year
ddd indicates the Julian day
hh indicates the hour
mm indicates the minute
ss indicates the second
jjobname
indicates the name of the job

Date fields in the system-generated name reflect when the job containing the
request (or the dynamic allocation request) was allocated. Time fields in the
system-generated name reflect when the job started (or the time of a dynamic
allocation request).
| v If you do not specify a data set name, the full format of the temporary data set
| name is:
| SYSyyddd.Thhmmss.RA000.jjobname.Rggnnnnn

| where:
| gg 01 or, in a sysplex, the system identifier
| nnnnn
| a number that is unique within a system
v If you do specify a data set name, the full format of the temporary data set name
is:
SYSyyddd.Thhmmss.RA000.jjobname.name.Hgg

where:
name the name you specified as &&name on the DSNAME parameter
gg 01 or, in a sysplex, the system identifier.

If you use DSNAME, note that the system-generated qualified name for the
temporary data set will not be unique under the following conditions:

Chapter 12. DD Statement 12-103

DD: DSNAME
v Multiple tasks or APPC transactions having identical jobnames execute at exactly
the same time, and
v The tasks or transactions contain DD statements with identical temporary data
set names.

To ensure that a temporary data set name is unique, do not code a temporary data
set name. Allow the system to assign one.

Only the job that creates a temporary data set has access to it to read and write
data and to scratch the data set.

Note: In general, the system treats a single ampersand (&) followed by a character
string of 1 to 8 characters as a symbolic parameter. (See “Using System
Symbols and JCL Symbols” on page 5-12.) However, if you code a data set
name as a symbolic parameter (by coding DSNAME=&xxxxxxxx), and do not
assign a value to or nullify the symbolic parameter, the system will process it
as a temporary data set name.
&&dsname
Specifies the name of a temporary data set.
&&dsname(member)
Specifies the name of a temporary partitioned data set (PDS) or partitioned data
set extended (PDSE) and a member within that data set.
member
1 - 8 alphanumeric or national characters, or a character X'C0'. The first
character must be alphabetic or national.
&&dsname(area)
Specifies the name of a temporary indexed sequential data set and an area of
the data set. The area name is INDEX, PRIME, or OVFLOW.
If you define an indexed sequential data set on only one DD statement, omit the
area name or code it as PRIME. For example, DSNAME=&&dsname or
DSNAME=&&dsname(PRIME).

Data Set Name for In-Stream or Sysout Data Set

Use the DSNAME parameter to assign a data set name to an in-stream data set
(defined with the DD * or DD DATA parameter) and to a sysout data set (defined
with the DD SYSOUT parameter). When defining an in-stream or sysout data set,
you can code the DSNAME parameter or omit it; if omitted, the system generates a
name for the data set.

The data set name for in-stream and sysout data sets consists of two ampersands
(&&) followed by one through eight 8 alphanumeric or national ($, #, @,) characters,
a hyphen, or a character X'C0'. The first character following the ampersands must
be alphabetic or national ($, #, @).

The system generates a qualified name for the in-stream or sysout data set. The
qualified name contains:
v The userid of the job
v The jobname
v The jobid
v A system-assigned identifier
v The data set name from the DSNAME parameter (if DSNAME is coded), or a
question mark (?) if DSNAME is not coded.

12-104 z/OS V1R3.0 MVS JCL Reference

 DD: DSNAME
The format of the name is:
userid.jobname.jobid.Ddsnumber.name

where name is the dsname or a question mark (?).

When the system checks a user’s authority to access a SYSOUT data set, the
check is made against the JESSPOOL class using the fully qualified name,
preceded by the node name and a period:
nodename.userid.jobname.jobid.Ddsnumber.name

Profiles of this format may be defined in your security system to allow other users
access to your SYSOUT data sets. A profile is not necessary for you to access your
own data sets.

Note: A single ampersand before a data set name in a cataloged or in-stream

procedure signifies a symbolic parameter. However, if no value is assigned
to the name on either the EXEC statement that calls the procedure, a PROC
statement in the procedure, or a previous SET statement, the system treats
the name as the last qualifier of the data set name for an in-stream or sysout
data set.
&&dsname
Specifies the last qualifier of the system-generated data set name for an
in-stream or sysout data set.

Data Set Name Copied from Earlier DD Statement

A backward reference is a reference to an earlier statement in the job or in a
cataloged or in-stream procedure called by this or an earlier job step. A backward
reference can be coded in the DSNAME parameter to copy a data set name from
an earlier DD statement.

When copying the data set name, the system also copies the following from the DD
statement:
v Whether or not the data set is a PDS or a PDSE.
v Whether or not the data set is a temporary data set.
*.ddname
Asks the system to copy the data set name from earlier DD statement ddname.
*.stepname.ddname
Asks the system to copy the data set name from DD statement, ddname, in an
earlier step, stepname, in the same job.
*.stepname.procstepname.ddname
Asks the system to copy the data set name from a DD statement in a cataloged
or in-stream procedure. Stepname is the name of this job step or an earlier job
step that calls the procedure, procstepname is the name of the procedure step
that contains the DD statement, and ddname is the name of the DD statement.

Data Set Name for Dummy Data Set

NULLFILE
Specifies a dummy data set. NULLFILE has the same effect as coding the DD
DUMMY parameter. NULLFILE must be coded as a single-word parameter. For
instance, IBM does not support the use of NULLFILE to obtain a dummy data
set for these (or other) formats:
v When followed by a member name
v As a qualifier in a qualified data set name

Chapter 12. DD Statement 12-105

DD: DSNAME
v As a temporary data set name.

Relationship to Other Parameters

Do not code the following parameters with the DSNAME parameter.

DDNAME
DYNAM
QNAME

Do not code the DCB IPLTXID subparameter with the DSNAME parameter.

Reserved Data Set Names

Do not code the following data set names on the DSNAME parameter with the *,
DATA, or SYSOUT parameter (an in-stream or sysout data set); the names are
reserved for system use.

JESJCL JESMSGLG
JESJCLIN JESYSMSG

With DD AMP Parameter

When you code an AMP parameter for a VSAM data set, do not code a DSNAME:
v That contains parentheses, a minus (hyphen), or a plus (+) sign.
v That is in the form for ISAM.
v That is in the form for PAM (partitioned access method).
v That names a generation data group.

With DD DISP Parameter

You can create a permanent data set by specifying a qualified or unqualified data
set name, the disposition must be other than DELETE.

The following example illustrates how to create a permanent data set:

//REPORT DD DSN=DEHART.APAR.REPORT,SPACE=(CYL,(5,5)),
// DISP=(NEW,CATLG),UNIT=SYSALLDA,
// DCB=(LRECL=121,RECFM=FBA,BLKSIZE=1210)

You can create a temporary data set by specifying a:

v &&dsname or by omitting the DSNAME parameter
v Qualified or unqualified data set name and specifying, either explicitly or
implicitly, DISP=(NEW,DELETE).

The following two examples illustrate how to create a temporary data set:
//MYDD1 DD DSN=TEMP1,UNIT=3480,DISP=(,DELETE),SPACE=(TRK,(1,1))
//DD2 DD UNIT=SYSALLDA,SPACE=(TRK,1),DISP=(NEW,PASS)

Note: When you code a disposition of CATLG for a data set, do not code a
DSNAME name in apostrophes.

Examples of the DSNAME Parameter

Example 1

12-106 z/OS V1R3.0 MVS JCL Reference

 DD: DSNAME
//DD1 DD DSNAME=ALPHA,DISP=(,KEEP),
// UNIT=3420,VOLUME=SER=389984

DD statement DD1 defines a new data set and names it ALPHA. DD statements in
later job steps or jobs may retrieve this data set by specifying ALPHA in the
DSNAME parameter, unit information in the UNIT parameter, and volume
information in the VOLUME parameter.

Example 2
//DDSMS1 DD DSNAME=ALPHA.PGM,DISP=(NEW,KEEP),DATACLAS=DCLAS1,
// MGMTCLAS=MCLAS1,STORCLAS=SCLAS1

DD statement DDSMS1 defines a new SMS-managed data set and names it

ALPHA.PGM. DD statements in later job steps or jobs may retrieve this data set by
specifying ALPHA.PGM in the DSNAME parameter.

Example 3
//DD2 DD DSNAME=LIB1(PROG12),DISP=(OLD,KEEP),UNIT=3350
// VOLUME=SER=882234

DD statement DD2 retrieves member PROG12 from the partitioned data set named
LIB1.

Example 4
//DDIN DD DATA,DSNAME=&&PAYIN1
.
data
.
/*

DD statement DDIN defines PAYIN1 as the last qualifier of the system-generated

data set name for the in-stream data set. This generates a data set name such as
userid.jobname.jobid.Ddsnumber.PAYIN1.

Example 5
//DDOUT DD DSNAME=&&PAYOUT1,SYSOUT=P

DD statement DDOUT defines PAYOUT1 as the last qualifier of the

system-generated data set name for the sysout data set. This generates a data set
name such as userid.jobname.jobid.Ddsnumber.PAYOUT1.

Example 6
//DD3 DD DSNAME=&&WORK,UNIT=3420

DD statement DD3 defines a temporary data set. Because the data set is deleted at
the end of the job step, the DSNAME parameter can be omitted. The following
example shows why a temporary data set should be named.

Example 7
//STEP1 EXEC PGM=CREATE
//DD4 DD DSNAME=&&ISDATA(PRIME),DISP=(,PASS),UNIT=(3350,2),
// VOLUME=SER=334859,SPACE=(CYL,(10,,2),,CONTIG),DCB=DSORG=IS
//STEP2 EXEC PGM=OPER
//DD5 DD DSNAME=*.STEP1.DD4,DISP=(OLD,DELETE)

DD statement DD4 in STEP1 defines a temporary indexed sequential data set

named ISDATA. This DD statement defines all of the areas of an indexed sequential

Chapter 12. DD Statement 12-107

DD: DSNAME
data set. DD statement DD5 in STEP2 retrieves the data set by referring to the
earlier DD statement that defines the data set. Because the temporary data set is
passed when it is defined in STEP1, it is not deleted at the end of STEP1 and
STEP2 can retrieve it.

DSNTYPE Parameter
Parameter Type

Keyword, optional — use this parameter only with DFSMS/MVS

Purpose

Use the DSNTYPE parameter to specify:

v A new partitioned data set (PDS)
v A new partitioned data set extended (PDSE), which is also called a library
v A new hierarchical file system (HFS) data set
v A first-in first-out (FIFO) special file, which is also called a named pipe

Also use the DSNTYPE parameter to override the DSNTYPE attribute defined in
the data class of the partitioned data set or PDSE.

Serialization of the data set can exist at both the data set (library) level and the
member level. If you specify DISP=SHR on the DD statement for a PDSE, sharing
of the data set applies to the data set and the individual member specified. Multiple
jobs can access different members of the data set and create new members of the
data set concurrently. However, concurrent update access to a specific member (or
update and read by other jobs) is not allowed. Dispositions of DISP=OLD, NEW, or
MOD result in exclusive use of the entire data set. A PDSE can be created through
the BPAM, BSAM, and QSAM access methods.

If DFSMS is not installed or is not active, the system checks the syntax and then
ignores the DSNTYPE parameter.

Before you define a PDSE, check with your storage administrator to ensure that
SMS is able to manage the data set and assign the PDSE to a storage class.
Information that you need to define a PDSE appears in z/OS DFSMS: Using Data
Sets .

An HFS data set is a data set used by z/OS UNIX System Services (z/OS UNIX)
programs. It contains a mountable file system. It is a partitioned format data set,
similar to a PDSE.

A FIFO special file is a type of file with the property that data written to such a file is
read on a first-in-first-out basis. A FIFO special file defined in a DD statement
provides a connection filled with data among programs. One or more programs can
write data into the file; one or more programs can read the data.

References

For information on partitioned data sets and PDSEs, see z/OS DFSMS: Using Data
Sets. For information on HFS data sets and FIFO special files, see z/OS UNIX
System Services Planning and the z/OS UNIX System Services User’s Guide.

12-108 z/OS V1R3.0 MVS JCL Reference

 DD: DSNTYPE
Syntax
DSNTYPE= {LIBRARY}
{HFS }
{PDS }
{PIPE }

Subparameter Definition
LIBRARY
Specifies a DFSMS-managed partitioned data set extended (PDSE). A PDSE
can contain data and problem object members.
HFS
Specifies an HFS data set. Specify HFS only when the DD statement also
specifies a DSNAME parameter.
PDS
Specifies a partitioned data set (PDS). A PDS can contain data and load
module members.
PIPE
Specifies a FIFO special file. Specify PIPE only when the DD statement also
specifies a PATH parameter.

Defaults
If you do not specify DSNTYPE, the type of data set is determined by other data
set attributes, the data class for the data set, or an installation default.

DSNTYPE cannot default to HFS or PIPE. You must explicitly specify these
attributes.

Overrides
DSNTYPE overrides the DSNTYPE attribute in the DATACLAS parameter for the
data set. See “Overrides” on page 12-52.

Relationship to Other Parameters

Do not code the following DD parameters with the DSNTYPE parameter.

* DDNAME
AMP DYNAM
DATA QNAME
RECORG

Examples of the DSNTYPE Parameter

Example 1
//NEWPDSE DD DSNAME=FILEA.ABC(REC1),DISP=(NEW,KEEP)

In the example, the NEWPDSE DD statement defines member REC1 in the new
PDSE named FILEA.ABC. Note that installation-written ACS routines select the data
class (which specifies LIBRARY for DSNTYPE), management class, and storage
class for the data set.

Chapter 12. DD Statement 12-109

DD: DSNTYPE
Example 2
//NEWA DD DSNAME=REPORT.ONE(WEEK1),DISP=(NEW,KEEP),
// DATACLAS=DCLAS09,DSNTYPE=LIBRARY

In the example, the NEWA DD statement defines member WEEK1 in the new
PDSE named REPORT.ONE. DSNTYPE=LIBRARY overrides the DSNTYPE
attribute in data class DCLAS09 but uses other data set attributes in DCLAS09.
Note that installation-written ACS routines select the management class and storage
class for the data set.

Example 3
//NEWB DD DSNAME=REPORT.TWO(WEEK2),DISP=SHR,
// DATACLAS=DCLAS09,DSNTYPE=LIBRARY

In the example, the NEWB DD statement adds a new member named WEEK2 to
the existing PDSE named REPORT.ONE. DSNTYPE=LIBRARY overrides the
DSNTYPE attribute in data class DCLAS09 but uses other data set attributes in
DCLAS09. Other jobs can be concurrently processing existing members of PDSE
named REPORT. Note that installation-written ACS routines select the management
class and storage class for the data set.

Example 4
//FILESYS DD DSNAME=OPENDS.USRJOE,DATACLAS=DCLAS05,DISP=(NEW,KEEP),
// DSNTYPE=HFS,SPACE=(CYL,(100,100,1))

The FILESYS DD statement creates an HFS data set to contain an HFS file
system. The DCLAS05 in DATACLAS specifies allocation characteristics. The
number of directory blocks must be specified to indicate that this is an HFS data set
but the value has no effect on allocation.

Example 5
//PIPE DD PATH=’/u/payroll/buffer’,DSNTYPE=PIPE,
// PATHOPTS=(OWRONLY,OEXCL,OCREAT),PATHMODE=(SIWUSR,SIRGRP),
// PATHDISP=(KEEP,DELETE)

The PIPE DD statement creates a file named /u/payroll/buffer for use as a FIFO
special file. The PATHOPTS parameter specifies that the user intends that the
program open the FIFO special file for writing. The PATHMODE parameter specifies
that the file owner can write in the FIFO special file and that users in the file group
class can read from the FIFO special file. The PATHDISP parameter requests that
the file be kept when the program ends normally and deleted when it ends
abnormally.

Pathnames are case-sensitive. If you are specifying a pathname containing a

special character, including a lowercase character, enclose it in apostrophes. For
more information, refer to “PATH Parameter” on page 12-150.

DUMMY Parameter
Parameter Type

Positional, optional

Purpose

Use the DUMMY parameter to specify that:

12-110 z/OS V1R3.0 MVS JCL Reference

 DD: DUMMY
v No device or external storage space is to be allocated to the data set.
v No disposition processing is to be performed on the data set.
v For BSAM and QSAM, no input or output operations are to be performed on the
data set.

One use of the DUMMY parameter is in testing a program. When testing is finished
and you want input or output operations performed on the data set, replace the DD
DUMMY statement with a DD statement that fully defines the data set.

Another use of the DUMMY parameter is in a cataloged or in-stream procedure.

Code on the DD DUMMY statement all the required parameters. When the
procedure is called, nullify the effects of the DUMMY parameter by coding on the
DD statement that overrides the DD DUMMY statement a DSNAME parameter that
matches the DSNAME parameter on the DD DUMMY statement. For example,
procedure step PS contains the following:
//DS1 DD DUMMY,DSNAME=A,DISP=OLD

Nullify the DUMMY parameter by coding:

//JS EXEC PROC=PROC1
//PS.DS1 DD DSNAME=A

Syntax
//ddname DD DUMMY[,parameter]...

All parameters coded on a DD DUMMY statement must be syntactically correct. The system
checks their syntax.

Parameters on DD DUMMY Statements

v Code the DUMMY parameter by itself or follow it with all the parameters you
would normally code when defining a data set, except the DDNAME parameter.
v Code the DCB parameter, if needed. If the program does not supply all the data
control block information, make sure that the DCB parameter supplies the
missing information.
v Code AMP=AMORG if you are using VSAM’s ISAM interface.
v If you code either VOLUME=REF=dsname or DCB=dsname with DUMMY, the
referenced dsname must be cataloged or passed; otherwise, the job is
terminated.
v Because no I/O is performed to the dummy data set, the system checks the
SPACE and DISP parameters, if coded, for syntax, then ignores them. If you
code UNIT with DUMMY, the system will ignore it if the specified unit name is
syntactically correct and defined to the system. Otherwise the system terminates
the job.

Relationship to Other Parameters

Do not code the following parameters with the DUMMY parameter.

* DYNAM
DATA QNAME
DDNAME

Chapter 12. DD Statement 12-111

DD: DUMMY
Relationship to Other Control Statements
Backward References

If a later DD statement in a job refers to a DD DUMMY statement when requesting

unit affinity (UNIT=AFF=ddname) or volume affinity
(VOLUME=REF=*.stepname.ddname), the system assigns a dummy status to the
later DD statement.

Overriding a Procedure DD Statement

Coding DUMMY on a DD statement that overrides a DD statement in a procedure

does not nullify symbolic parameters on the overridden DD statement. You must
assign values to, or nullify, symbolic parameters on the overridden DD statement as
described in “Using System Symbols and JCL Symbols” on page 5-12.

If the overriding DD statement contains a DSNAME parameter other than

NULLFILE, a PATH parameter other than /dev/null, or a SUBSYS, SYSOUT, *, or
DATA parameter, the system nullifies a DUMMY parameter on the overridden DD
statement.

Note: If you code SYSOUT= on an overriding statement, without specifying a

subparameter value, the system does not nullify the DUMMY parameter. You
must code a subparameter value for SYSOUT to nullify the DUMMY
parameter.

Data Sets Concatenated to Dummy Data Sets

The system treats data sets concatenated to a DUMMY data set as dummy data
sets in that I/O operations are bypassed. However, the system performs disposition
processing and allocates devices and storage for any concatenated data sets.

Relationship to Access Methods

Use one of the following access methods with the DUMMY parameter:
v Basic sequential access method (BSAM)
v Virtual storage access method (VSAM)
v Queued sequential access method (QSAM)
v BDAM load mode (BSAM with MACRF=WL in the data control block)

If you use any other access method, the job is terminated.

Note: The ISAM/VSAM interface does not support the DUMMY parameter. For
more information on the ISAM/VSAM interface, see z/OS DFSMS: Using
Data Sets.

Examples of the DUMMY Parameter

Example 1
//OUTDD1 DD DUMMY,DSNAME=X.X.Z,UNIT=3380,
// SPACE=(TRK,(10,2)),DISP=(,CATLG)

DD statement OUTDD1 defines a dummy data set. The other parameters coded on
the statement are checked for syntax but not used.

Example 2
//IN1 DD DUMMY,DCB=(BLKSIZE=800,LRECL=400,RECFM=FB)

12-112 z/OS V1R3.0 MVS JCL Reference

 DD: DUMMY
DD statement IN1 defines a dummy data set. The DCB parameter supplies data
control block information not supplied in the program. Without it, the step might be
abnormally terminated.

Example 3
//IN2 DD DUMMY,DSNAME=ELLN,DISP=OLD,VOLUME=SER=11257,UNIT=3350

When calling a cataloged procedure that contains DD statement IN2 in procedure

step STEP4, you can nullify the effects of the DUMMY parameter by coding:
//STEP4.IN2 DD DSNAME=ELLN

Example 4
//TAB DD DSNAME=APP.LEV12,DISP=OLD

If you call a cataloged procedure that contains DD statement TAB in procedure step
STEP1, you can make this DD statement define a dummy data set by coding:
//STEP1.TAB DD DUMMY

Example 5
//MSGS DD SYSOUT=A

If you call a cataloged procedure that contains the DD statement MSGS in

procedure step LOCK, you can make this DD statement define a dummy data set
by coding:
//LOCK.MSGS DD DUMMY

DYNAM Parameter
Parameter Type

Positional, optional

Purpose

Use the DYNAM parameter to increase by one the control value for dynamically
allocated resources held for reuse. Even when DYNAM is not coded, the system
normally holds resources in anticipation of reuse. The DYNAM parameter is
supported to provide compatibility with older systems.

A DD DYNAM statement is a dummy request.

Syntax
//ddname DD DYNAM [comments]

Relationship to Other Parameters

Do not code any parameters with the DYNAM parameter.

Do not code on a DD DYNAM statement a ddname that is meaningful to the

system; for example, JOBLIB, SYSCHK.

Chapter 12. DD Statement 12-113

DD: DYNAM
Relationship to Other Control Statements
v Do not refer to a DD DYNAM statement in a DDNAME parameter.
v To nullify the DYNAM parameter on a DD statement in a cataloged or in-stream
procedure, code a SYSOUT or DSNAME parameter in the overriding DD
statement. DSNAME=NULLFILE does not nullify a DYNAM parameter.
v Do not code a backward reference to a DD DYNAM statement.
v Do not code the DYNAM parameter on the first DD statement for a
concatenation.

Example of the DYNAM Parameter

//INPUT DD DYNAM

This DD statement increases by one the control value for dynamically allocated
resources held for reuse.

EXPDT Parameter
Parameter Type

Keyword, optional

Purpose

Use the EXPDT parameter to specify the expiration date for a new data set. On and
after the expiration date, the data set can be deleted or written over by another data
set.

Note: You cannot use the EXPDT parameter to change the expiration date of an
existing SMS data set.

Note: You may specify a past date; this would not be an error condition.

If the DD statement contains DISP=(NEW,DELETE) or the DISP parameter is

omitted and defaults to NEW and DELETE, the system deletes the data set when
the step terminates, either normally or abnormally, even if you have specified an
expiration date.

Do not specify EXPDT for a temporary data set.

The EXPDT parameter achieves the same result as the RETPD parameter.

Code the EXPDT parameter when you want to specify an expiration date for the
data set, or, with SMS, override the expiration date defined in the data class for the
data set.

Syntax
EXPDT= {yyddd }
{yyyy/ddd}
The EXPDT parameter can have a null value only when coded on a DD statement that is
either added to a procedure or overrides a DD statement in a procedure.

12-114 z/OS V1R3.0 MVS JCL Reference

 DD: EXPDT
Subparameter Definition
EXPDT=yyddd
EXPDT=yyyy/ddd
Specifies an expiration date for the data set.
yyddd
This form of the expiration date specifies a two-digit year number yy (from
00 through 99) and a three-digit day number ddd (from 001 through 365 for
a non-leap year date, from 001 through 366 for a leap year date). For
example, code February 2, 1999 as EXPDT=99033, and code December
31, 1996 as EXPDT=96366.

Note: For expiration dates of January 1, 2000 and later, you MUST use the
form EXPDT=yyyy/ddd.

Note: Expiration dates of 99365 and 99366 are considered “never-scratch”

dates. Data sets with these expiration dates are not deleted or
written over.
yyyy/ddd
This form of the expiration date specifies a four-digit year number yyyy
(from 1900 through 2155) and a three-digit day number ddd (from 001
through 365 for a non-leap year date, from 001 through 366 for a leap year
date). For example, code February 2, 1999 as EXPDT=1999/033, and code
December 31, 2000 as EXPDT=2000/366.

Note: Expiration dates of 1999/365 and 1999/366 are considered

“never-scratch” dates. Data sets with these expiration dates are not
deleted or written over.

You may specify the years from 1900. However, if you specify the current date
or an earlier date, the data set is immediately eligible for replacement.

Overrides
With SMS, EXPDT overrides the expiration date defined in the DATACLAS
parameter for the data set. See “Overrides” on page 12-52.

With SMS, both the expiration date specified on EXPDT and defined in the data
class for an SMS-managed data set can be limited by a maximum expiration date
defined in the management class for the data set.

Relationship to Other Parameters

Do not code the following DD parameters with the EXPDT parameter.

* DYNAM
DATA RETPD
DDNAME SYSOUT

Deleting a Data Set Before its Expiration Date

To delete a data set (and make the space occupied by the data set available for
reallocation) before the expiration date has passed, use one of the following
methods:

Chapter 12. DD Statement 12-115

DD: EXPDT
v For data sets cataloged in an integrated catalog facility catalog, use the DELETE
command, as described in z/OS DFSMS Access Method Services for Catalogs.
v For data sets not cataloged in an integrated catalog facility catalog, use the
IEHPROGM utility, as described in z/OS DFSMSdfp Utilities.
v Use the SCRATCH macro with the OVRD parameter, as described in z/OS
DFSMSdfp Advanced Services. If the data set is SMS-managed, this also
uncatalogs the data set.
v If the storage administrator specified OVRD_EXPDT(YES) in the IGDSMSxx
member of SYS1.PARMLIB, you can override the expiration date for
SMS-managed DASD data sets by specifying DELETE on the DD DISP
parameter. The system will delete the data set whether or not it has expired. See
z/OS MVS Initialization and Tuning Reference for information about the
IGDSMSxx parmlib member.

Examples of the EXPDT Parameter

Example 1
//DD7 DD DSNAME=TOM1,DISP=(NEW,KEEP),EXPDT=2006/033,
// UNIT=SYSDA,SPACE=(TRK,(1,1)),VOLUME=SER=663344

In this example, the data set is not eligible for being deleted or written over until
February 2, 2006.

Example 2
//SMSDS2 DD DSNAME=MYDS2.PGM,DATACLAS=DCLAS02,DISP=(NEW,KEEP),
// EXPDT=2001/033

In this example, the expiration date of February 2, 2001 overrides the expiration
date defined in the data class for the data set.

FCB Parameter
Parameter Type

Keyword, optional

Purpose

Use the FCB parameter to specify:

v The forms control buffer (FCB) image JES is to use to guide printing of this
sysout data set by a 1403 Printer, 3211 Printer, 3203 Printer Model 5, 3800
Printing Subsystem, 4245 Printer, 4248 Printer, or by a printer supported by
systems network architecture (SNA) remote job entry (RJE).
v The carriage control tape JES is to use to control printing of this sysout data set
by a 1403 Printer or by a printer supported by SNA RJE.
v The data-protection image JES is to use to control output of this sysout data set
by a 3525 Card Punch.

The FCB image specifies how many lines are to be printed per inch and the length
of the form. JES loads the image into the printer’s forms control buffer. The FCB
image is stored in SYS1.IMAGELIB. IBM provides three standard FCB images:
v STD1, which specifies 6 lines per inch on an 8.5-inch-long form. (3211 and
3203-2 only)
v STD2, which specifies 6 lines per inch on an 11-inch-long form. (3211 and
3203-2 only)

12-116 z/OS V1R3.0 MVS JCL Reference

 DD: FCB
v STD3, which specifies 8 lines per inch for a dump on an 11-inch form. (3800
only)

References

For more information on the forms control buffer, see z/OS DFSMSdfp Advanced
Services or 3800 Programmer’s Guide.

Syntax
FCB= {fcb-name }
{(fcb-name[,ALIGN|,VERIFY])}

v You can omit the parentheses if you code only the fcb-name.
v Code the fcb-name as STD1 or STD2 only to request the IBM-supplied images.
v Code the fcb-name as STD3 for a high-density dump.
v Null positions in the FCB parameter are invalid.

Subparameter Definition
fcb-name
Identifies the FCB image. The name is 1 through 4 alphanumeric or national ($,
#, @) characters and is the last characters of a SYS1.IMAGELIB member
name:
v FCB2xxxx member for a 3211, a 3203 model 5, or a printer supported by
SNA.
v FCB3xxxx member for a 3800.
v FCB4xxxx member for a 4248.
ALIGN
Requests that the system ask the operator to check the alignment of the printer
forms before the data set is printed.

Note:
v ALIGN is ignored for a sysout data set.
v ALIGN is ignored for a data set printed on a 3800. The 3800 does not
use the ALIGN subparameter.
VERIFY
Requests that the system ask the operator to verify that the image displayed on
the printer is for the desired FCB image. The operator can also take this
opportunity to align the printer forms.

Note: VERIFY is ignored for a sysout data set.

Defaults
If you do not code the FCB parameter, the system checks the FCB image in the
printer’s forms control buffer; if it is a default image, as indicated by its first byte,
JES uses it. If it is not a default image, JES loads the FCB image that is the
installation default specified at JES initialization.

Overrides
An FCB parameter on a sysout DD statement overrides an OUTPUT JCL FCB
parameter.

Chapter 12. DD Statement 12-117

DD: FCB
Relationship to Other Parameters
Do not code the following parameters with the FCB parameter.

* DYNAM
AMP KEYOFF
DATA PROTECT
DDNAME QNAME

Do not code the following DCB subparameters with the FCB parameter.

CYLOFL INTVL
RKP

For output to the 3525, do not code the SYSOUT parameter and the FCB
parameter; the system ignores the FCB parameter.

Relationship to Other Control Statements

You can also code the FCB parameter on the following:
v The OUTPUT JCL statement.
v The JES2 /*OUTPUT statement.
v The JES3 //*FORMAT PR statement.

Defining an FCB Image for a Work Station

When a work station uses a peripheral data set information record (PDIR), the FCB
image is defined in the work station. The DD statement FCB fcb-name
subparameter must match the FCB name defined in the PDIR work station.

When a work station does not use a PDIR, add an FCB member to
SYS1.IMAGELIB. At setup time, JES3 translates the FCB into a set vertical format
(SVF).

Requesting a High-Density Dump

You can request a high-density dump on the 3800 through two parameters on the
DD statement for the dump data set or on an OUTPUT JCL statement referenced
by the dump DD statement:
v FCB=STD3. This parameter produces dump output at 8 lines per inch.
v CHARS=DUMP. This parameter produces 204-character print lines.

You can code one or both of these parameters. You can place both on the same
statement or one on each statement.

Examples of the FCB Parameter

Example 1
//DD1 DD UNIT=3211,FCB=(IMG1,VERIFY)

In this example, the DD statement defines an output data set to be printed by a

3211. The FCB parameter requests that the data set be printed under control of the
FCB2IMG1 member in SYS1.IMAGELIB. Because VERIFY is coded, the system
displays the FCB image on the printer before printing the data set.

Example 2

12-118 z/OS V1R3.0 MVS JCL Reference

 DD: FCB
//DD2 DD SYSOUT=A,FCB=IMG2

This sysout DD statement specifies output class A. If output class A routes output to
a printer having the forms control buffer feature, JES loads the FCB image IMG2
into the forms control buffer. If the printer does not have the forms control buffer
feature, the operator receives a message to mount the carriage control tape IMG2
on the printer.

Example 3
//OUTDDS DD UNIT=3211,FCB=(6,ALIGN)

In this example, the DD statement defines an output data set to be printed by a

3211. The FCB parameter requests that the data set be printed under control of the
FCB image named 6. Because ALIGN is coded, the system issues a message to
the operator requesting that the alignment of the printer forms be checked before
the data set is printed.

Example 4
//PUNCH DD UNIT=3525,FCB=DP2

In this example, the DD statement requests output on a 3525. Therefore, the FCB
parameter defines the data protection image to be used for the 3525.

Example 5
//SYSUDUMP DD SYSOUT=A,FCB=STD3

In this example, the DD statement requests that the 3800 print a dump at 8 lines
per inch.

FILEDATA Parameter
Parameter Type

Keyword, optional

Purpose

Use the FILEDATA keyword to describe the organization of a hierarchical file so that
the system can determine how to process the file.

Use the FILEDATA keyword only on a system that includes DFSMS/MVS

Version 1.3 or later.

If a job containing the FILEDATA parameter runs on a system without the required
DFSMS/MVS support, the system checks the FILEDATA syntax and then ignores
the parameter.

References

For more information on network file protocols, see z/OS Network File System
Customization and Operation and z/OS Network File System User’s Guide.

Chapter 12. DD Statement 12-119

DD: FILEDATA
Syntax
FILEDATA= {BINARY}
{TEXT }

Subparameter Definition
BINARY
The file described by the DD statement is a byte-stream file and does not
contain record delimiters. The access method does not insert or delete record
delimiters.
TEXT
The file described by the DD statement contains records delimited by the
EBCDIC newline character (x’15’).

Defaults
If you do not code the FILEDATA parameter, the system assigns a default value of
BINARY.

Overrides
The FILEDATA parameter does not override the specification of any other JCL
keyword or system parameter.

Relationship to Other Parameters

You can code the FILEDATA parameter only on a DD statement that contains a
PATH parameter.

You can code the following parameters with the FILEDATA parameter.

BLKSIZE LRECL PATHMODE

BUFNO NCP PATHOPTS
DSNTYPE PATH RECFM
DUMMY PATHDISP TERM

Example of the FILEDATA Parameter

//DD1 DD PATH=’/u/d89pek1/new’,FILEDATA=TEXT,
// PATHMODE=(SIRWXU,SISUID),PATHOPTS=(ORDONLY,OCREAT)

In this example, the DD statement identifies a hierarchical file and informs the
system that this file contains records delimited by the newline character.

FLASH Parameter
Parameter Type

Keyword, optional

Purpose

Use the FLASH parameter to identify the forms overlay to be used in printing this
sysout data set on a 3800 Printing Subsystem and, optionally, to specify the
number of copies on which the forms overlay is to be printed.

12-120 z/OS V1R3.0 MVS JCL Reference

 DD: FLASH
Note: FLASH applies only for a data set printed on a 3800.

References

For information on forms overlays, see the Forms Design Reference Guide for the
3800.

Syntax
{overlay-name }
FLASH= {(overlay-name[,count])}
{NONE }

The count subparameter is optional. If you omit it, you can omit the parentheses. However,
if you omit it, you must not code it as a null; for example, FLASH=(ABCD,) is invalid.

Subparameter Definition
overlay-name
Identifies the forms overlay frame that the operator is to insert into the printer
before printing begins. The name is 1 through 4 alphanumeric or national ($, #,
@) characters.
count
Specifies the number, 0 through 255, of copies that JES is to flash with the
overlay, beginning with the first copy printed. Code a count of 0 to flash all
copies.
NONE
Suppresses flashing for this sysout data set.
If FLASH=NONE is on a DD statement in a job to be executed at a remote
node, JES3 sets the overlay-name to zero before sending the job to the node.

Defaults
If you do not code a FLASH parameter and an installation default was not specified
at JES2 or JES3 initialization, forms are not flashed.

If you specify an overlay-name without specifying a count or with a count of 0, all

copies are flashed. That is, the default for count is 255.

Overrides
A FLASH parameter on a sysout DD statement overrides an OUTPUT JCL FLASH
parameter.

Note: A null first subparameter is invalid in a FLASH parameter on a DD

statement, but is permitted on an OUTPUT JCL statement.

Relationship to Other Parameters

Do not code the following parameters with the FLASH parameter.

* DISP PROTECT
AMP DSID QNAME
DATA DYNAM SUBSYS
DDNAME LABEL VOLUME

Chapter 12. DD Statement 12-121

DD: FLASH

Relationship to COPIES Parameter

If this DD statement or a referenced OUTPUT JCL statement also contains a

COPIES parameter, JES prints with the forms overlay the number of copies
specified in one of the following:
v COPIES=nnn, if the FLASH count is larger than nnn. For example, if COPIES=10
and FLASH=(LTHD,12) JES prints 10 copies, all with the forms overlay.
v The sum of the group-values specified in the COPIES parameter, if the FLASH
count is larger than the sum. For example, if COPIES=(,(2,3,4)) and
FLASH=(LTHD,12) JES prints nine copies in groups, all with the forms overlay.
v The count subparameter in the FLASH parameter, if the FLASH count is smaller
than nnn or the sum from the COPIES parameter. For example, if COPIES=10
and FLASH=(LTHD,7) JES prints seven copies with the forms overlay and three
copies without.

Relationship to Other Control Statements

FLASH can also be coded on the following:
v The OUTPUT JCL statement.
v The JES3 //*FORMAT PR statement.
v The JES2 /*OUTPUT statement.

Verification of Forms Overlay Frame

Before printing starts, the system requests the operator to load the specified forms
overlay frame in the printer. A frame must be loaded, but the system cannot verify
that it is the correct frame.

Printing without Flashing

To print without flashing, specify one of the following:
v FLASH=NONE on the DD or OUTPUT JCL statement.
v Omit the FLASH parameter on all of the statements for the data set and on all
JES initialization statements.
v For a sysout data set, omit the FLASH parameter on the DD statement and
specify FLASH=(,0) on a referenced OUTPUT JCL statement.

Example of the FLASH Parameter

//DD1 DD SYSOUT=A,COPIES=10,FLASH=(ABCD,5)

In this example, JES issues a message to the operator requesting that the
forms-overlay frame named ABCD be inserted into the printer. Then JES prints the
first five copies of the data set with the forms-overlay and the last five copies
without.

FREE Parameter
Parameter Type

Keyword, optional

Purpose

12-122 z/OS V1R3.0 MVS JCL Reference

 DD: FREE
Use the FREE parameter to specify when the system is to unallocate the resources
used for this DD statement’s data set. The resources can be devices, volumes, or
exclusive use of a data set.

Note: Specifying FREE will not release the enqueue on the data set until the last
step that requires the data set completes processing.

Syntax
FREE= {END }
{CLOSE}

Subparameter Definition
END
Requests that the system unallocate the data set at the end of the last step that
references the data set.
CLOSE
Requests that the system unallocate the data set when it is closed.

Defaults
If no FREE parameter is specified, the default is END. Also, if the FREE parameter
is incorrectly coded, the system substitutes END and issues a warning message.

Overrides
FREE=CLOSE is ignored when:
v The data set is a member of a concatenated group.
v The task using the data set abnormally terminates.
v The data set is referenced by another DD statement in the same or subsequent
step.

Relationship to Other Parameters

Do not code the following parameters with the FREE parameter.

* DYNAM
DATA QNAME
DDNAME

If the DD statement specifies FREE=END and a DISP subparameter of PASS, the

data set is not unallocated until the end of the job or until used for a later DD
statement with a disposition of other than PASS.

Do not specify FREE=CLOSE on a DD statement with a ddname of JOBCAT,

JOBLIB, STEPCAT, or STEPLIB; CLOSE is ignored.

When you specify FREE=CLOSE:

v If the job step abnormally terminates before the data set is closed, the system
uses the abnormal termination disposition from the DISP parameter to process
the data set. If a recovery routine, such as an ESTAE routine, gets control and
closes the data set, however, it uses the normal termination disposition.

Chapter 12. DD Statement 12-123

DD: FREE
v If the job step abnormally terminates after the data set is closed, then the system
has already processed the data set using the normal termination disposition.

If you specify SPIN=NO with FREE=CLOSE, the sysout data set will be
unallocated, but not printed until the end of the job.

When you specify SPIN=UNALLOC with FREE=CLOSE, the sysout data set is
available for printing immediately when you explicitly close or dynamically
unallocate the data set. If you do not explicitly close or dynamically unallocate the
data set, it will be available for printing at the end of the step.

If you specify SPIN=UNALLOC with FREE=END, the sysout data set is unallocated
at the end of the step, and is made available for printing then. If you dynamically
unallocate the sysout data set, the system makes it available for printing
immediately.

If you specify SPIN=NO with FREE=END, the system makes the sysout data set
available for printing at the end of the job, regardless of when the data set is
unallocated or closed.

Relationship to Other Control Statements

If a DD statement requests unit affinity in a UNIT=AFF parameter or volume affinity
in a VOLUME=REF parameter with an earlier DD statement, do not code
FREE=CLOSE on the earlier statement.

If you code FREE=CLOSE on a sysout DD statement that references an OUTPUT

JCL statement containing a GROUPID parameter, JES2 will not group the data sets
into one output group. Instead, JES2 produces one copy of the sysout data set for
each OUTPUT JCL statement that the DD statement references.

Relationship to the CLOSE Macro Instruction

When FREE=CLOSE is specified for a data set that is opened and closed more
than once during a job step:
v The data set is unallocated after it is closed if the assembler CLOSE macro
instruction specifies DISP, REWIND, or FREE. If the data set is reopened after
the system has unallocated it, the job step abnormally terminates, unless the
data set is dynamically allocated in the interval.

The data set is not unallocated until the end of the job if the assembler CLOSE
macro instruction specifies LEAVE or REREAD. Then the data set can be
reopened.

Examples of the FREE Parameter

Example 1
//EA33 DD SYSOUT=D,FREE=CLOSE

In this example, the FREE=CLOSE parameter makes JES unallocate this output
class D data set when it is closed, rather than at the end of the job step. JES
schedules the data set for printing.

Example 2
//EA33 DD DSNAME=SYBIL,DISP=OLD,FREE=CLOSE

12-124 z/OS V1R3.0 MVS JCL Reference

 DD: FREE
In this example, the FREE=CLOSE parameter makes JES unallocate the data set,
dequeue it, and make it available to other jobs as soon as it is closed.

Example 3
//STEP1 EXEC PGM=ABLE1
//DD1 DD DSNAME=A,DISP=(,PASS),FREE=END
//STEP2 EXEC PGM=ABLE2
//DD2 DD DSNAME=A,DISP=(OLD,CATLG),FREE=END

In this example, data set A is passed by STEP1 to STEP2. FREE=END on DD

statement DD1 is ignored because the disposition is PASS. FREE=END on DD
statement DD2 causes data set A to be unallocated at the end of STEP2, when it is
also cataloged.

Example 4
//STEP1 EXEC PGM=BAKER1
//DD DD DSNAME=A,DISP=(NEW,PASS),FREE=END
//STEP2 EXEC PGM=BAKER2

In this example, data set A is a new data set. Because PASS is specified,
FREE=END is ignored and the data set remains allocated.

HOLD Parameter
Parameter Type

Keyword, optional

Purpose

Use the HOLD parameter to tell the system to hold a sysout data set until it is
released by the system operator. When the data set is ready for processing, notify
the system operator to release it via a TSO/E NOTIFY parameter, a JES2
/*MESSAGE statement, or a JES3 //*OPERATOR statement.

A TSO/E user can specify HOLD=YES to retrieve a sysout data set and display it
on a terminal. For JES3, the TSO/E user can process only work on the hold queue.
Notes:
1. HOLD is supported only for sysout data sets. If HOLD appears on a DD
statement that does not contain a SYSOUT parameter, it is ignored.
2. HOLD allows the sysout data set to be the internal reader. If the sysout data set
is the internal reader, the job being submitted will be held.

Syntax
HOLD= {YES}
{Y }
{NO }
{N }

Chapter 12. DD Statement 12-125

DD: HOLD
Subparameter Definition
YES
Requests that the system hold the sysout data set until the data set is released
by the system operator. You can also code this subparameter as Y.
NJE Notes:
v In a JES2 NJE environment, the system does not hold the data set until it
reaches its ultimate destination node.
v If the destination node is a JES3 node, the system may still not hold the data
set if the class of output being transmitted is not defined as a hold class.
If the sending node is JES3, the system holds the output data set at that
node on the BDT queue (when transmitting to an SNA-attached node) or the
WTR queue (when transmitting to a BSC-attached node) if all of the following
are true:
– The ″// DD SYSOUT=″ JCL statement does not contain a
DEST=(node,userid) parameter.
– The SYSOUT= parameter does not contain the WRITER-NAME
subparameter and the output class is not defined as a hold class.
– No WRITER= parameter is coded on the OUTPUT JCL statement.

Example 1.

The following job executes on NODE1 and results in the SYSUT2 output
data set being held on the BDT queue on NODE1. (NODE5 is attached to
NODE1 via SNA and output class A is not defined as a hold class.)
//S1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=A
//SYSIN DD DUMMY
//SYSUT1 DD DSN=SYS1.PROCLIB(JES3),DISP=SHR
//SYSUT2 DD SYSOUT=A,HOLD=YES,DEST=NODES

Example 2.

The following job executes on NODE1 and results in the SYSUT2 output
data set being held on the WTR queue on NODE1. (NODE5 is attached to
NODE1 via BSC and output class A is not defined as a hold class.)
//S1 EXEC PGM=IEBGENER
//O1 OUTPUT CLASS=A,DEST=NODE2.MYWRITR
//SYSPRINT DD SYSOUT=A
//SYSIN DD DUMMY
//SYSUT1 DD DSN=SYS1.PROCLIB(JES3),DISP=SHR
//SYSUT2 DD SYSOUT=(,),HOLD=YES,OUTPUT=(*.O1)
NO
Requests that the system perform installation-defined processing for the sysout
data set’s output class. You can also code this subparameter as N.

Defaults
If no HOLD parameter is specified, the default is NO. If the HOLD parameter is
incorrectly coded, the system assumes the default of NO and issues a warning
message; the job continues.

Overrides
HOLD=NO is overridden by the unallocation verb of dynamic allocation or the
TSO/E FREE command.

12-126 z/OS V1R3.0 MVS JCL Reference

 DD: HOLD
Either HOLD=YES or HOLD=NO on the DD statement overrides the sysout data set
disposition specified on the OUTDISP parameter of the OUTPUT JCL statement.

Relationship to Other Parameters

Code the HOLD parameter only on a DD statement with the SYSOUT parameter.

JES3 ignores HOLD=YES when

v DEST=(node,userid) is coded on the SYSOUT= DD statement. Example 1 shows
this case. (JES3 does not ignore the HOLD=YES when DEST= is coded on the
OUTPUT DD statement. Example 2 shows this case.) or
v the sysout data set is placed on the hold queue, for example, if
SYSOUT=(,writer-name) is coded.

Relationship to Other Control Statements

Code a NOTIFY parameter on the JOB statement to ask the system to send a
message to your TSO/E userid when job processing is complete.

JES2 users can use the /*NOTIFY control statement to direct job notification
messages and to override a JOB NOTIFY parameter.

Examples of the HOLD Parameter

Example 1
//JOB01 JOB ,’HAROLD DUQUETTE’,MSGLEVEL=1
//STEP1 EXEC PGM=MJCOSCO
//DD1 DD SYSOUT=B,DEST=RMT6,HOLD=YES

In this example, sysout data set DD1 from JOB01 is held on a queue until the
TSO/E user at RMT6 asks the system operator to release the data set.

Example 2
//$JOBxx JOB ,’OSWALD CHALMERS’,MSGLEVEL=1
//OUT1 OUTPUT DEST=NODE2.printer,CLASS=A,...
//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=A.DATA.SET
//SYSUT2 DD SYSOUT=(,),OUTPUT=(*.OUT1),HOLD=YES

In this example, if the job is submitted on NODE1, JES3 does not ignore the
HOLD=YES. The SYSOUT data set is held at NODE1 and is not transmitted to
NODE2 to be held there.

KEYLEN Parameter
Parameter Type

Keyword, optional

Purpose

Use the KEYLEN parameter to specify the length of the keys used in a new data
set.

Code the KEYLEN parameter when you want to:

v Specify a key length for the data set or

Chapter 12. DD Statement 12-127

DD: KEYLEN
v With SMS, override the key length defined in the data class of the data set.

The key length can be supplied from the data set label (or data class with SMS). If
a key length is not specified or supplied, input or output requests must not require
keys.

KEYLEN applies to data sets with the BDAM, BPAM, BSAM, EXCP, QISAM, and
TCAM access methods, and, with SMS, to VSAM data sets.

Syntax
KEYLEN=bytes

Subparameter Definition
bytes
Specifies the length, in bytes, of the keys used in the data set.
The number of bytes is:
v 0 to 255 for non-VSAM data sets. The key length must be less than or equal
to the record length.

Note: Use only 0 for a member of a partitioned data set extended (PDSE).
Use 0 or 8 to perform input operations on the directory of a PDSE.
v 1 to 255 for VSAM key-sequenced (RECORG=KS) data sets. A key length
must be specified, either explicitly with the KEYLEN or LIKE parameter, or in
the data class for the data set. The key length must be less than the record
length.

Overrides
KEYLEN overrides the key length specified in the data set label, and with SMS,
KEYLEN overrides the key length defined in the DATACLAS parameter for the data
set. See “Overrides” on page 12-52.

Relationship to Other Parameters

Do not code the following DD parameters with the KEYLEN parameter.

* DCB=STACK
DATA DCB=TRTCH
DCB=KEYLEN DDNAME
DCB=MODE DYNAM
DCB=PRTSP

Examples of the KEYLEN Parameter

Example 1
//DD4 DD DSNAME=JST,DISP=(NEW,KEEP),UNIT=3350,
// SPACE=(CYL,(12,2)),DCB=(A.B.C),KEYLEN=8

DD statement DD4 defines a new data set named JST and requests that the
system copy the DCB information from the data set label of the cataloged data set

12-128 z/OS V1R3.0 MVS JCL Reference

 DD: KEYLEN
named A.B.C. If the data set label contains a key length specification, it is
overridden by the KEYLEN coded on this DD statement.

Example 2
//SMSDS3 DD DSNAME=MYDS3.PGM,DATACLAS=VSAM1,DISP=(NEW,KEEP),
// KEYLEN=6

In the example, where the data class VSAM1 defines a key-sequenced VSAM data
set, the key length of 6 overrides the key length defined in the data class.

KEYOFF Parameter
Parameter Type

Keyword, optional — use this parameter only with SMS

Without SMS, use the RKP subparameter of the DCB parameter described on page
12-72.

Purpose

Use the KEYOFF parameter to specify the key offset, the position of the first byte of
the record key in each logical record of a new VSAM data set. The first byte of a
logical record is position 0.

If SMS is not installed or is not active, the system syntax checks and then ignores
the KEYOFF parameter.

Code the KEYOFF parameter only for a VSAM key-sequenced data set
(RECORG=KS).

Code the KEYOFF parameter when you want to (1) specify a key offset for the data
set or (2) override the key offset defined in the data class of the data set.

References

See z/OS DFSMS: Using Data Sets for information on VSAM key-sequenced data
sets.

Syntax
KEYOFF=offset-to-key

Subparameter Definition
offset-to-key
Specifies the position (offset), in bytes, of the first byte of the key in each
record. The offset is 0 to the difference between the record length (LRECL) and
key length (KEYLEN), in the range 0 to 32,760.

Overrides
KEYOFF overrides the key offset defined in the DATACLAS parameter for the data
set. See “Overrides” on page 12-52.

Chapter 12. DD Statement 12-129

DD: KEYOFF
Relationship to Other Parameters
Do not code the following DD parameters with the KEYOFF parameter.

* DYNAM
DATA FCB
DCB=RESERVE UCS
DCB=RKP
DDNAME

Example of the KEYOFF Parameter

//SMSDS3 DD DSNAME=MYDS3.PGM,DATACLAS=VSAM1,DISP=(NEW,KEEP),
// KEYOFF=2

In the example, the data class VSAM1 defines a key-sequenced VSAM data set.
The key offset of 2 overrides the key offset defined in the data class and specifies
that the first byte of the key is in the third position of each record.

LABEL Parameter
Parameter Type

Keyword, optional

Purpose

Use the LABEL parameter to specify for a tape or direct access data set:
v The type and contents of the label or labels for the data set.
v If a password is required to access the data set.
v If the system is to open the data set only for input or output.
v The expiration date or retention period for the data set.

Although subparameters RETPD and EXPDT are shown in the syntax of the LABEL
parameter, you should use the RETPD or EXPDT DD parameter to specify a
retention period or expiration date for the data set.

For a tape data set, this parameter can also specify the relative position of the data
set on the volume.

References

For details on tape labels, see z/OS DFSMS: Using Magnetic Tapes. For details on
direct access labels, see z/OS DFSMS: Using Data Sets. For information on
protecting a data set with a password, see z/OS DFSMSdfp Advanced Services.

12-130 z/OS V1R3.0 MVS JCL Reference

 DD: LABEL
Syntax
LABEL=([data-set-sequence-number][,label] [,PASSWORD][,IN ][,RETPD=nnnn ])
[, ] [,NOPWREAD][,OUT][,EXPDT={yyddd }]
[, ] [ {yyyy/ddd}]

label is one of the following:

AL
AUL
BLP
LTM
NL
NSL
SL
SUL

The first four subparameters are positional; the last subparameter is keyword. If you omit
any positional subparameters but code a following positional subparameter, indicate each
omitted subparameter by a comma. If the following subparameter is one of the keyword
subparameters (EXPDT or RETPD), you do not need commas to indicate omitted
subparameters. For example:
LABEL=(0001,SUL,PASSWORD,IN)
LABEL=(,SUL,PASSWORD)
LABEL=(,SUL,,IN,EXPDT=97033)
LABEL=(,,PASSWORD,EXPDT=1997/033)
LABEL=(,SUL,EXPDT=1997/033)
LABEL=(0001,,,IN)
LABEL=(0001,EXPDT=1997/033)
If you specify only the data-set-sequence-number or only the retention period or only the
expiration date, you can omit the parentheses. For example, code LABEL=data-set-
sequence-number, LABEL=RETPD=nnnn, LABEL=EXPDT=yyddd, or
LABEL=EXPDT=yyyy/ddd.

Alternate Syntax for RETPD and EXPDT

RETPD and EXPDT should be specified as DD parameters rather than

subparameters of the LABEL parameter. This allows you to specify a retention
period or expiration date without the need to code LABEL.

For example, code RETPD and EXPDT on the DD statement as:

RETPD=366 or EXPDT=2006/033

See the DD RETPD parameter described on page 12-172, and the DD EXPDT
parameter described on page 12-114.

Subparameter Definition
Data-Set-Sequence-Number
data-set-sequence-number
Identifies the relative position of a data set on a tape volume. The
data-set-sequence-number is 1 through 4 decimal digits. Omit this
subparameter or code 0 or 1 to indicate the first data set on the tape volume.
Omit this subparameter for the following:
v Cataloged data sets. The system obtains the data-set-sequence-number from
the catalog.

Chapter 12. DD Statement 12-131

DD: LABEL
v A DD DSNAME parameter that requests all members of a generation data
group (GDG). The system retrieves the data-set-sequence-number from the
catalog.
v A data set passed from a preceding step. The system obtains the
data-set-sequence-number from the passing step.

Label
The system does not retain label type information for cataloged data sets; if the
label type is not coded in the LABEL parameter for a cataloged data set, the system
assumes SL.

For a data set on a direct access device, the system obtains the label type from the
DD statement; the label type is not obtained from any other source referred to in
the DD statement. Only two label types are valid for direct access devices: SL and
SUL.
SL
Indicates that a data set has IBM standard labels. If this subparameter is
omitted, SL is the default.
Code only SL or SUL for data sets on direct access devices.
If the LABEL parameter is coded on a SYSCKEOV DD statement, code
LABEL=(,SL).
SUL
Indicates that a data set has both IBM standard and user labels.
Code only SL or SUL for data sets on direct access devices.
Do not code SUL for partitioned or indexed sequential data sets.
AL
Indicates that a tape data set has ISO/ANSI Version 1 or ISO/ANSI/FIPS
Version 3 labels.
If you specify AL for a tape generation data set for output, the ending
.GnnnnVnn (where n=0 through 9) will not appear as part of the file identifier
(data set name field) of the HDR1 label. Instead, the data is placed in the
generation and version number fields of the HDR1 label.
AUL
Indicates that a tape data set has user labels and ISO/ANSI Version 1 or
ISO/ANSI/FIPS Version 3 labels.
NSL
Indicates that a tape data set has nonstandard labels.
Before you code NSL, ensure that your installation has created and installed
non-standard label processing routines, described in z/OS DFSMS Installation
Exits.
NL
Indicates that a tape data set has no labels.
When retrieving two or more data sets from several NL or BLP tape volumes,
concatenate the DD statements and repeat the LABEL parameter on each DD
statement.
If you are processing ASCII data on unlabeled tapes, the data control block
must specify OPTCD=Q.

12-132 z/OS V1R3.0 MVS JCL Reference

 DD: LABEL
BLP
Requests that the system bypass label processing for a tape data set.
If the installation did not specify the BLP feature in the reader cataloged
procedure, BLP has the same effect as NL.
If you code BLP and the tape volume has labels, a tapemark delimits the data
set. To let the system position a tape with labels to the proper data set, code
the data-set-sequence-number subparameter; the number must reflect all labels
and data sets that precede the desired data set.
Do not specify BLP when the DD DSNAME parameter requests all members of
a generation data group (GDG); the system obtains the data-set-sequence-
number from the catalog. Therefore, coding BLP might result in incorrect tape
positioning.
When retrieving two or more data sets from several NL or BLP tape volumes, or
when retrieving a data set from several BLP tape volumes and those volumes
have labels, concatenate the DD statements and repeat the LABEL parameter
on each DD statement.
LTM
Indicates that the data set has a leading tapemark.
Notes:
1. You may use the LABEL parameter when allocating a system-managed tape
volume, but you cannot use the NSL or LTM subparameters. If the ACS routine
does not exclude these subparameters, the job will fail with JCL errors.
System-managed tape volumes must be IBM standard label or ANSI standard
tapes.
2. LABEL=(,,,IN) is the system-managed tape library equivalent of either
UNIT=SYS3480R or UNIT=SYS348XR, which represent overriding esoteric unit
names.

Password Protection
For an SMS-managed data set (one with an assigned storage class), SMS sets the
password indicators in the VTOC and catalog but ignores the indicators and does
not use password protection for the data set. See the DD SECMODEL parameter
described on page 12-176.

Password protecting data sets requires the following:

v Data set names no longer than 17 characters. MVS retains in the tape label only
the rightmost 17 characters of the data set name. Consequently, longer names
could be identical in password checks.
v Volumes with IBM standard labels or ISO/ANSI/FIPS Version 3 labels.
v A password assigned in the PASSWORD data set. If a password is not assigned,
the system will abnormally terminate a job step when it attempts to open the data
set for output, if NOPWREAD is coded, or for input or output, if PASSWORD is
coded.

To create a password-protected data set following an existing password-protected

data set, code the password of the existing data set. The password must be the
same in both the existing and the new data set.

To password-protect a data set on a tape volume containing other data sets, you
must password-protect all the data sets on the volume and the passwords must be
the same for all data sets.

Chapter 12. DD Statement 12-133

DD: LABEL
To password-protect an existing data set using PASSWORD or NOPWREAD, open
the data set for output the first time it is used during the job step.
PASSWORD
Indicates that a data set cannot be read, changed, deleted, or written to unless
the system operator or TSO/E user supplies the correct password.
NOPWREAD
Indicates that a data set cannot be changed, deleted, or written to unless the
system operator or TSO/E user supplies the correct password. No password is
necessary for reading the data set.

Input or Output Processing

IN
Indicates that a BSAM data set opened for INOUT or a BDAM data set opened
for UPDAT is to be read only. The IN subparameter overrides the processing
option in the assembler OPEN macro instruction. Any attempt by the processing
program to write in the data set makes the system give control to the error
analysis (SYNAD) routine.
OUT
Indicates that a BSAM data set opened for OUTIN or OUTINX is to be written in
only. The OUT subparameter overrides the processing option in the assembler
OPEN macro instruction. Any attempt by the processing program to read the
data set makes the system give control to the error analysis (SYNAD) routine.

Retention Period or Expiration Date for Data Set

You should avoid using the RETPD and EXPDT subparameters on the LABEL
parameter to specify a retention period or expiration date for the data set.

Use the DD RETPD parameter (described on page 12-172) or the DD EXPDT

parameter (described on page 12-114), which do the same function. This allows you
to specify a retention period or expiration date without the need to code the LABEL
parameter.

Defaults
v If no data-set-sequence-number subparameter is specified or if the number is
coded as 0 or 1, the default is the first data set on the tape volume, unless the
data set is passed or cataloged.
v If no label type subparameter is specified, the default is only IBM standard labels
(SL).

Relationship to Other Parameters

Do not code the following parameters with the LABEL parameter.

* DATA MODIFY
BURST DDNAME QNAME
CHARS DYNAM SYSOUT
COPIES FLASH

Do not specify the LABEL parameter with the FUNC subparameter of the DCB
parameter. The results are unpredictable.

ISO/ANSI/FIPS Version 3 tape data sets can be protected by use of the ACCODE
parameter.

12-134 z/OS V1R3.0 MVS JCL Reference

 DD: LABEL
If you specify a LABEL parameter on a SYSCKEOV DD statement, code
LABEL=(,SL).

Relationship to Other Control Statements

When a VOLUME=REF subparameter refers to an earlier DD statement to use the
same volume(s):
v For tape, the system copies the LABEL label type subparameter from the
referenced DD statement; the copied label type overrides the label type on the
referencing DD statement.
v For direct access, the system uses a LABEL=(,SL) or LABEL=(,SUL)
subparameter from the referencing DD statement. If the referencing DD
statement specifies any other label type, the system copies the LABEL label type
subparameter from the referenced DD statement; the copied label type overrides
the label type on the referencing DD statement.
v You do not need to provide a data set sequence number when the DD DSNAME
parameter references all the members of a GDG or a single member through a
relative generation number; the system obtains the data from the catalog. For all
other data set names, however, you must provide the data set sequence number
on the LABEL parameter.

Data Conversion
AL or AUL in the LABEL parameter requests conversion between EBCDIC and
ASCII. You can also request conversion by specifying OPTCD=Q in the data control
block. If the tape is not labeled, LABEL=(,NL), you must specify OPTCD=Q for
conversion to occur.

Examples of the LABEL Parameter

Example 1
//DD1 DD DSNAME=HERBI,DISP=(NEW,KEEP),UNIT=TAPE,
// VOLUME=SER=T2,LABEL=(3,NSL,RETPD=188)

DD statement DD1 defines a new data set. The LABEL parameter tells the system:
v This data set is to be the third data set on the tape volume.
v This tape volume has nonstandard labels.
v This data set is to be kept for 188 days.

Although LABEL=(3,NSL,RETPD=188) is valid, it is better practice to use the DD

RETPD parameter as follows:
//DD1 DD DSNAME=HERBI,DISP=(NEW,KEEP),UNIT=TAPE,
// VOLUME=SER=T2,LABEL=(3,NSL),RETPD=188

Example 2
//DD2 DD DSNAME=A.B.C,DISP=(,CATLG,DELETE),UNIT=3400-5,LABEL=(,NL)

DD statement DD2 defines a new data set, requests that the system catalog it, and
indicates that the data set has no labels. Each time this data set is used by a
program, the DD statement must include LABEL=(,NL).

Example 3
//DD3 DD DSNAME=SPECS,UNIT=3400-5,VOLUME=SER=10222,
// DISP=OLD,LABEL=4

DD statement DD3 indicates an existing data set. The LABEL parameter indicates
that the data set is fourth on the tape volume.

Chapter 12. DD Statement 12-135

DD: LABEL
Example 4
//STEP1 EXEC PGM=FIV
//DDX DD DSNAME=CLEAR,DISP=(OLD,PASS),UNIT=3400-5,
// VOLUME=SER=1257,LABEL=(,NSL)
//STEP2 EXEC PGM=BOS
//DDY DD DSNAME=*.STEP1.DDX,DISP=OLD,LABEL=(,NSL)

DD statement DDX in STEP1 indicates an existing data set with nonstandard labels
and requests that the system pass the data set. DD statement DDY in STEP2
receives the data set. DDY contains the label type, because the system does not
obtain the label type through the backward reference in the DSNAME parameter.

Example 5
//DDZ DD DSNAME=CATDS,DISP=OLD,LABEL=(,SUL)

DD statement DDZ indicates an existing, cataloged data set on direct access. The
data set has IBM standard labels and user labels. The LABEL parameter is
required; otherwise, if the DD statement does not contain a LABEL parameter, the
system assumes that a direct access data set has SL labels.

Example 6
//DD7 DD DSNAME=TOM1,DISP=(NEW,KEEP),LABEL=EXPDT=2006/033,
// UNIT=3350,SPACE=(TRK,(1,1)),VOLUME=SER=663344

DD statement DD7 defines a new data set, requests the system to keep the data
set, and indicates that the data set cannot be deleted or written over until the
expiration date of February 2, 2006.

Although LABEL=EXPDT=2006/033 is valid, it is better practice to use the DD

EXPDT parameter as follows:
//DD7 DD DSNAME=TOM1,DISP=(NEW,KEEP),EXPDT=2006/033,
// UNIT=3350,SPACE=(TRK,(1,1)),VOLUME=SER=663344

LGSTREAM Parameter
Parameter Type

Keyword, optional

Purpose

Use the LGSTREAM parameter to specify the prefix of the name of the log stream
for an SMS-managed VSAM data set. Use it only:
v For allocating SMS-managed VSAM data sets that will be accessed using record
level sharing (RLS).
v On a system that includes DFSMS/MVS Version 1 Release 4 or later. (The
system ignores the LGSTREAM parameter when operating with DFSMS 1.3 and
earlier releases.)

Syntax
LGSTREAM=name

12-136 z/OS V1R3.0 MVS JCL Reference

 DD: LGSTREAM
The name, up to a maximum of twenty-six characters, consists of one or more
segments. Each segment may contain one to eight characters, which may be
alphabetic, numeric, or national ($, #, @) characters. Segments are joined by
periods, with periods being counted as characters towards the limit of twenty-six.
The first character of each segment must be non-numeric.

Subparameter Definition
name
Specifies the name of the prefix the system logger uses for the forward
recovery log stream for recording changes made to the data set when accessed
in the RLS mode. The system logger adds other qualifiers to the end of the
LGSTREAM name to generate the data set name where it keeps the forward
recovery logs.

Defaults
If you do not code a LGSTREAM parameter the system will assign the value
specified in the SMS data class assigned to the data set, if applicable.

Overrides
The system ignores LGSTREAM specifications for non-SMS-managed and
non-VSAM data sets and for VSAM linear data sets.

The LGSTREAM name on a DD statement can override the LOGSTREAMID name

specified in the SMS data class.

Relationship to Other Parameters

Code a disposition of NEW or of MOD treated as NEW. (The system ignores the
LGSTREAM parameter for existing data sets.)

Do not code the following DD parameters with the LGSTREAM parameter.

* DLM PATHDISP
BURST DSNTYPE QNAME
CHARS DYNAM SEGMENT
COPIES FLASH SPIN
DATA MODIFY SYSOUT
DCB=DSORG OUTPUT TERM
DCB=RECFM PATHOPTS UCS
DDNAME PATHMODE

Example of the LGSTREAM Parameter

//FRED DD DSN=VSAM.DATASET,LGSTREAM=SSAB1234.NEW,RECORG=KS,
// KEYLEN=8,KEYOFF=0,DISP=(,KEEP)

In this example, the system will create an SMS-managed VSAM key-sequenced

data set if the storage administrator assigns a data class that provides other
parameters such as SPACE and LOG=ALL, and assigns a POOL storage group.
The system logger will use the name SSAB1234.NEW as the prefix to generate the
data set name where it will keep the forward recovery logs.

Chapter 12. DD Statement 12-137

 DD: LIKE

LIKE Parameter
Parameter Type

Keyword, optional — use this parameter only with SMS

Without SMS, use the DCB=dsname form of the DCB parameter described on page
12-54.

Purpose

Use the LIKE parameter to specify the allocation attributes of a new data set by
copying the attributes of a model data set, which must be an existing cataloged
data set and reside on a direct access volume.

The following attributes are copied from the model data set to the new data set:
v Data set organization
– Record organization (RECORG) or
– Record format (RECFM)
v Record length (LRECL)
v Key length (KEYLEN)
v Key offset (KEYOFF)
v Type, PDS or PDSE (DSNTYPE)
v Space allocation (AVGREC and SPACE)
| Unless you explicitly code the SPACE parameter for the new data set, the
| system determines the space to be allocated for the new data set by adding up
| the space allocated in the first three extents of the model data set. Therefore, the
| space allocated for the new data set will generally not match the space that was
| specified for the model data set. Note that if the model data set was allocated in
| blocks (that is, BLKLGTH or RECLGTH was specified rather than TRK or CYL),
| then the system will allocate space for the new data set in tracks.

Note: Directory quantity is picked up as part of the space allocation attribute

except when the model data set is a PDSE. When you create a PDS, the
directory blocks must be specified directly on the JCL by using the SPACE
parameter.

There is no requirement that either the new data set or the model data set must be
SMS-managed. If the new data set is to reside on tape:
v The model data set must be a sequential DASD data set
v Only the record format (RECFM) and the record length (LRECL) attributes are
copied to the new data set.

For VSAM data set compression, the LIKE parameter copies existing data set
attributes. That is, LIKE processing on a model data set that is compressed will
pass the attribute to the new data set. This means that specifying compaction in
DATACLAS is not the only way compression can be achieved. For additional
information on VSAM data set compression, see z/OS DFSMS Migration.

When you specify the LIKE parameter on a JCL DD statement, the SMS read-only
variable values that correspond to the attributes copied from the model data set are
not available as input to the ACS routines. For more information on SMS read-only
variables, see z/OS DFSMSdfp Storage Administration Reference.

If SMS is not installed or is not active, the system syntax checks and then ignores
the LIKE parameter.

12-138 z/OS V1R3.0 MVS JCL Reference

 DD: LIKE
The retention period (RETPD) or expiration date (EXPDT) is not copied to the new
data set.

Note: Do not use the LIKE parameter to copy attributes from a temporary data set
(&&dsname), partitioned data set if a member name is included, and relative
generation number for a GDG.

Syntax
LIKE=data-set-name

Subparameter Definition
data-set-name
Specifies the data set name (dsname) of the model data set whose attributes
are to be used as the attributes of the new data set.

Overrides
Any attributes obtained using the LIKE parameter override the corresponding
attributes in the DATACLAS parameter.

Any attributes you specify on the same DD statement with the following parameters
override the corresponding attributes obtained from the model data set.
AVGREC (record request and space quantity)
DSNTYPE (type, PDS or PDSE)
KEYLEN (key length)
KEYOFF (key offset)
LRECL (record length)
RECORG (record organization) or RECFM (record format)
SPACE (average record length, primary, secondary, and directory quantity)

Relationship to Other Parameters

Do not code the following DD parameters with the LIKE parameter.

DYNAM
REFDD
SYSOUT

Examples of the LIKE Parameter

Example 1
//SMSDS6 DD DSNAME=MYDS6.PGM,LIKE=MYDSCAT.PGM,DISP=(NEW,KEEP)

In the example, the data set attributes used for MYDS6.PGM are obtained from the
cataloged model data set MYDSCAT.PGM.

Example 2
//SMSDS7 DD DSNAME=MYDS7.PGM,LIKE=MYDSCAT.PGM,DISP=(NEW,KEEP),
// LRECL=1024

Chapter 12. DD Statement 12-139

DD: LIKE
In the example, the data set attributes used for MYDS7.PGM are obtained from the
cataloged model data set MYDSCAT.PGM. Also, the logical record length of 1024
overrides the logical record length obtained from the model data set.

LRECL Parameter
Parameter Type

Keyword, optional

Purpose

Use the LRECL parameter to specify the length of the records in a new data set.

Code the LRECL parameter when you want to

v Specify the logical record length for the data set, or
v With SMS, override the record length defined in the data class of the data set.

LRECL applies to data sets with the BPAM, BSAM, EXCP, QISAM, QSAM, and
TCAM access methods, and with SMS, to VSAM data sets.

Syntax
LRECL=bytes

Subparameter Definition
bytes
Specifies (1) the length, in bytes, for fixed length records or (2) the maximum
length, in bytes, for variable-length records.
The value of bytes is:
v 1 to 32,760 for non-VSAM data sets.
v 1 to 32,761 for VSAM key-sequenced (KS), entry-sequenced (ES), or relative
record (RR) data sets. (LRECL does not apply to VSAM linear space,
RECORG=LS, data sets.)
For VSAM key-sequenced (KS) data sets, a record length must be specified,
either explicitly with the LRECL or LIKE parameter, or in the data class for
the data set. The record length must be greater than the key length.

Note: When RECFM is F or U, the length must not exceed DCB BLKSIZE. For
RECFM=D or V, the length must not exceed BLKSIZE minus 4. For
RECFM=VS, the length can exceed BLKSIZE. For unblocked records
when DCB RKP=0, the length is for only the data portion of the record.
LRECL=0 is valid only for RECFM=U.

Additional Syntax for LRECL=bytes

LRECL=nnnnnK
Specifies the length in kilobytes for variable-length spanned records in
ISO/ANSI/FIPS Version 3 tape data sets that are processed by the Data Facility
Product using the extended logical record interface (XLRI). nnnnn is from 1
through 16,383 and indicates multiples of 1024 bytes. The value in the DCB

12-140 z/OS V1R3.0 MVS JCL Reference

 DD: LRECL
macro must already be coded as LRECL=0K or LRECL=nnnnnK. If a K is
coded for any other type of data set, only the numeric value of LRECL is
recognized.
LRECL=X
For QSAM only, specifies that the logical record length exceeds 32,760 bytes
for variable-length spanned records. This option is not valid for ISO/ANSI/FIPS
Version 3 variable-length records.

Overrides
LRECL overrides the record length specified in the data set label, and with SMS,
LRECL overrides the record length defined in the DATACLAS parameter for the
data set. See “Overrides” on page 12-52.

Relationship to Other Parameters

Do not code the following DD parameters with the LRECL parameter.

DCB=LRECL
DDNAME
DYNAM

Examples of the LRECL Parameter

Example 1
//DD1B DD DSNAME=EVER,DISP=(NEW,KEEP),UNIT=3380,
// RECFM=FB,LRECL=326,SPACE=(23472,(200,40))

In the example, the logical record length of 326 is used for the new data set EVER.

Example 2
//SMSDS2 DD DSNAME=MYDS2.PGM,DATACLAS=DCLAS02,DISP=(NEW,KEEP),
// LRECL=256

In the example, the logical record length of 256 overrides the logical record length
defined in the data class for the data set.

MGMTCLAS Parameter
Parameter Type

Keyword, optional

Use this parameter only with SMS and for SMS-managed data sets.

Without SMS, there are no DD parameters that provide this function.

Purpose

Use the MGMTCLAS parameter to specify a management class for a new

SMS-managed data set. The storage administrator at your installation defines the
names of the management classes you can code on the MGMTCLAS parameter.

After the data set is allocated, the attributes in the management class control:
v Migration of the data set, including migration from primary storage to
DFSMShsm-owned storage to archival storage

Chapter 12. DD Statement 12-141

DD: MGMTCLAS
v Backup of the data set, including frequency of backup, number of versions, and
retention criteria for backup versions
v Automatic deletion of data sets
v Automatic release of unused space in data sets

The Hierarchical Storage Manager (DFSMShsm) or a functionally equivalent

program performs these functions.

If SMS is not installed or is not active, the system syntax checks and then ignores
the MGMTCLAS parameter.

SMS ignores the MGMTCLAS parameter if you specify it for an existing data set.

The use of a management class can be protected by RACF.

References

See z/OS DFSMS: Using the Interactive Storage Management Facility for
information on how to use ISMF to view your installation-defined management
classes.

Syntax
MGMTCLAS=management-class-name

Subparameter Definition
management-class-name
Specifies the name of a management class to be used for management of the
SMS-managed data set after the data set is allocated.
The name, one to eight alphanumeric or national ($ # @) characters, is defined
by the storage administrator at your installation.

Defaults
If you do not specify MGMTCLAS for a new data set and the storage administrator
has provided an installation-written automatic class selection (ACS) routine, the
ACS routine may select a management class for the data set. Check with your
storage administrator to determine if an ACS routine will select a management class
for the new data set, in which case you do not need to specify MGMTCLAS.

Overrides
You cannot override management class attributes via JCL parameters. With SMS,
MGMTCLAS overrides the attributes defined in the DATACLAS parameter for the
data set. See “Overrides” on page 12-52.

The management class for a data set defines a maximum value for the expiration
date or retention period of the data set. This maximum limits the values that are
specified on the EXPDT or RETPD parameter, or defined in the data class for the
data set.

An ACS routine can override the management class that you specify on the
MGMTCLAS parameter.

12-142 z/OS V1R3.0 MVS JCL Reference

 DD: MGMTCLAS
Relationship to Other Parameters
Do not code the following DD parameters with the MGMTCLAS parameter.

* DYNAM DATA QNAME

DDNAME

Code MGMTCLAS only when you specify a storage class for the data set (via the
STORCLAS parameter) or an ACS routine selects a storage class.

Example of the MGMTCLAS Parameter

//SMSDS1 DD DSNAME=MYDS1.PGM,DATACLAS=DCLAS1,STORCLAS=SCLAS1,
// MGMTCLAS=MCLAS01,DISP=(NEW,KEEP)

In the example, SMS uses the attributes in the management class named
MCLAS01 to handle the migration and backup of the SMS-managed data set. Note
that installation-written ACS routines may override the specified management class,
storage class, and data class.

MODIFY Parameter
Parameter Type

Keyword, optional

Purpose

Use the MODIFY parameter to specify a copy-modification module that tells JES
how to print this sysout data set on a 3800 Printing Subsystem. The module can
specify the following:
v Legends.
v Column headings.
v Where and on which copies the data is to be printed.

The module is defined and stored in SYS1.IMAGELIB using the IEBIMAGE utility
program.

Note: MODIFY applies only for the 3800 Printing Subsystem Models 1 and 2 and
the 3800 Printing Subsystem Models 3, 6, and 8 in compatibility mode.

References

For more information on the copy modification module and the IEBIMAGE utility
program, see z/OS DFSMSdfp Utilities.

Syntax
MODIFY= {module-name }
{(module-name[,trc])}

v You must code the module-name.

v The trc subparameter is optional. If you omit it, you can omit the parentheses. However, if
you omit it, you must not code it as a null; for example, MODIFY=(TAB1,) is invalid.

Chapter 12. DD Statement 12-143

DD: MODIFY
Subparameter Definition
module-name
Identifies a copy-modification module in SYS1.IMAGELIB. The module-name is
1 through 4 alphanumeric or national ($, #, @) characters.
trc
Identifies which table-name in the CHARS parameter is to be used. This table
reference character is 0 for the first table-name specified, 1 for the second, 2
for the third, or 3 for the fourth. The CHARS parameter is on the following, in
override order:
1. This DD statement.
2. A referenced OUTPUT JCL statement.
3. A statement in the library member specified on the OUTPUT JCL PAGEDEF
parameter.
4. A statement in the SYS1.IMAGELIB member obtained by default.
5. A JES3 initialization statement.

Defaults
If no MODIFY parameter is specified, JES3 uses an installation default specified at
initialization. JES2 provides no installation default at initialization.

If you do not specify trc or if the trc value is greater than the number of
table-names in the CHARS parameter, JES2 uses the first table named in the
CHARS parameter and JES3 uses the default character arrangement table.

Overrides
A MODIFY parameter on a sysout DD statement overrides an OUTPUT JCL
MODIFY parameter.

Note: A null first subparameter is invalid in a MODIFY parameter on a DD

statement, but is permitted on an OUTPUT JCL statement.

Relationship to Other Parameters

Do not code the following parameters with the MODIFY parameter.

* DISP PROTECT
AMP DSID QNAME
DATA DYNAM SUBSYS
DDNAME LABEL VOLUME

Relationship to Other Control Statements

MODIFY can also be coded on the following:
v The OUTPUT JCL statement.
v The JES3 //*FORMAT PR statement.
v The JES2 /*OUTPUT statement.

The second character of each logical record can be a TRC code, so that each
record can be printed in a different font. This way of specifying fonts is indicated by
the OUTPUT JCL TRC parameter.

12-144 z/OS V1R3.0 MVS JCL Reference

 DD: MODIFY
Example of the MODIFY Parameter
//DD1 DD UNIT=3800,MODIFY=(A,0),CHARS=(GS15,GS10)

In this example, the MODIFY parameter requests that the data in the
copy-modification module named A replace variable data in the data set to be
printed by the 3800. Module A defines which positions are to be replaced and which
copies are to be modified. The second subparameter in MODIFY specifies that the
first character arrangement table in the CHARS parameter, GS15, be used.

OUTLIM Parameter
Parameter Type

Keyword, optional

Purpose

Use the OUTLIM parameter to limit the number of logical records in the sysout data
set defined by this DD statement. When the limit is reached, the system exits to the
SYSOUT limit exit routine. If the installation supplies an installation-written routine,
the routine can determine whether to terminate the job or increase the limit. If the
installation does not supply a routine, the system terminates the job.

Note: OUTLIM is valid only on a DD statement with a SYSOUT parameter.

References

For more information on the SYSOUT limit exit routine, see z/OS MVS Installation
Exits .

Syntax
OUTLIM=number

Subparameter Definition
number
Specifies the maximum number of logical records. The number is 1 through 8
decimal digits from 1 through 16777215.

Default
(1) If no OUTLIM parameter is specified or OUTLIM=0 is coded and (2) if output is
not limited by JES control statements, JES3 uses an installation default specified at
initialization; JES2 provides no installation default at initialization.

Relationship to Other Parameters

Code the OUTLIM parameter only on a DD statement with the SYSOUT parameter.

Do not code the OUTLIM parameter with the DCB subparameters CPRI or
THRESH; these subparameters can alter the OUTLIM value.

On Dump DD Statements

Chapter 12. DD Statement 12-145

 DD: OUTLIM
On a SYSABEND or SYSUDUMP DD statement:
v JES3 ignores the OUTLIM parameter.
v JES2 limits the output as specified on the OUTLIM parameter.

| Not only can JECL statement limit output, but the OUTLIM parameter is applied
| independently of other limits.

Relationship to Other Control Statements

Output can also be limited by the following:
v The LINES, BYTES, PAGES, or CARDS parameter of the JES2 /*JOBPARM
statement.
v The LINES, BYTES, PAGES, or CARDS parameter of the JES3 //*MAIN
statement.
v The LINES, BYTES, PAGES, or CARDS parameter of the JOB statement.

Example of the OUTLIM Parameter

//OUTDD DD SYSOUT=F,OUTLIM=1000

The limit for the number of logical records is 1000.

OUTPUT Parameter
Parameter Type

Keyword, optional

Purpose

Use the OUTPUT parameter with the SYSOUT parameter to associate a sysout
data set explicitly with an OUTPUT JCL statement. JES processes the sysout data
set using the options from this DD statement combined with the options from the
referenced OUTPUT JCL statement.

When the OUTPUT parameter references more than one OUTPUT JCL statement,
the system produces separate output for each OUTPUT JCL statement.

Note: Code the OUTPUT parameter only on a DD statement with a SYSOUT

parameter. Otherwise, the system checks the OUTPUT parameter for syntax
then ignores it.

Syntax
OUTPUT= {reference }
{(reference[,reference]...)}

A reference is one of the following:

*.name
*.stepname.name
*.stepname.procstepname.name

12-146 z/OS V1R3.0 MVS JCL Reference

 DD: OUTPUT

v You can omit the parentheses if you code only one reference.
v You must not code a null in an OUTPUT parameter. For example, OUTPUT=(,*.name) is
invalid.
v You can reference a maximum of 128 OUTPUT JCL statements on one OUTPUT
parameter.
v You can code references in any combination. For example, the following are valid:
//EXA DD SYSOUT=A,OUTPUT=(*.name,*.name,*.stepname.name)
//EXB DD SYSOUT=A,OUTPUT=(*.stepname.name,
// *.stepname.procstepname.name,*.name)
v You can code the references to OUTPUT JCL statements in any order.

Subparameter Definition
*.name
Refers to an earlier OUTPUT JCL statement with name in its name field. The
system searches for the OUTPUT JCL statement first in the same step, then
before the first EXEC statement of the job.
*.stepname.name
Refers to an earlier OUTPUT JCL statement, name, in this step or an earlier
step, stepname, in the same job.
*.stepname.procstepname.name
Refers to an OUTPUT JCL statement in a cataloged or in-stream procedure.
Stepname is the name of this job step or an earlier job step that calls the
procedure, procstepname is the name of the procedure step that contains the
OUTPUT JCL statement, and name is the name field of the OUTPUT JCL
statement.

Defaults
If you do not code an OUTPUT parameter on a sysout DD statement, JES obtains
processing options for the sysout data set in the following order:
1. From each OUTPUT JCL statement containing DEFAULT=YES in the same
step.
2. From each OUTPUT JCL statement containing DEFAULT=YES before the first
EXEC statement in the job, provided that the step contains no OUTPUT JCL
statements with DEFAULT=YES.
3. Only from the sysout DD statement, provided that neither the step nor job
contains any OUTPUT JCL statements with DEFAULT=YES.

If you do not specify a SYSOUT class on the DD statement, JES3 uses the
truncation value associated with the first referenced (or defaulted) OUTPUT
statement that does specify a class. If this DD statement specifies an OUTPUT
class, JES3 accepts that class and its associated truncation value.

Overrides
When an OUTPUT JCL statement is used with the sysout DD statement to specify
processing, JES handles parameters as follows:
v If a parameter appears on the DD statement, JES uses the parameter.
v If a parameter appears only on the OUTPUT JCL statement, JES uses the
parameter.
v If the same parameter appears on both statements, JES uses the DD parameter.

Chapter 12. DD Statement 12-147

DD: OUTPUT
JES uses the whole overriding parameter, ignoring the whole overridden parameter.
If a subparameter is left off the overriding parameter, the system does not pick up
that subparameter from the overridden parameter. For example:
//EXAMP2 OUTPUT FLASH=(ABCD,3)
//FVZ2 DD SYSOUT=F,OUTPUT=*.EXAMP2,FLASH=(EFGH)

Only EFGH is used. The system ignores all of the FLASH parameter on the
OUTPUT JCL statement, including the second parameter.

Relationship to Other Parameters

Code the OUTPUT parameter only on a DD statement with the SYSOUT parameter.

With INTRDR Subparameter in SYSOUT Parameter

Do not code an OUTPUT parameter when the SYSOUT parameter specifies a

JES2 internal reader by an INTRDR parameter.

Null Subparameters

A null first subparameter is invalid in a FLASH or MODIFY parameter on a DD

statement, but is permitted on an OUTPUT JCL statement. For example,
MODIFY=(,3) is valid only on an OUTPUT JCL statement.

SYSOUT Third Subparameter

You cannot reference a JES2 /*OUTPUT statement using the third subparameter of
the SYSOUT parameter if either of the following is also coded:
v The OUTPUT parameter on the same DD statement.
v An OUTPUT JCL statement containing DEFAULT=YES in the same step or
before the EXEC statement of the job, when the DD statement does not contain
an OUTPUT parameter.

DEFAULT Parameter on OUTPUT JCL Statement

If you code DEFAULT=YES on an OUTPUT JCL statement, you can still refer to
that OUTPUT JCL statement in the OUTPUT parameter of a sysout DD statement.

Location in the JCL

All referenced OUTPUT JCL statements must precede the DD statement that refers
to them. If the referencing DD statement appears in an in-stream or cataloged
procedure, the referenced OUTPUT JCL statement must precede the DD statement
in the procedure. A sysout DD statement in a procedure cannot refer to an
OUTPUT JCL statement in the calling step.

No Match for OUTPUT Name

If the system finds no match for the name coded in the OUTPUT parameter, the
system issues a JCL error message and fails the job.

Processing Options in Multiple References

A sysout DD statement can refer to more than one OUTPUT JCL statement, either
explicitly in an OUTPUT parameter containing more than one reference or implicitly
when several default OUTPUT JCL statements apply. The processing options for a
sysout data set come from one sysout DD statement and one OUTPUT JCL

12-148 z/OS V1R3.0 MVS JCL Reference

 DD: OUTPUT
statement. In multiple references, each combination of sysout DD statement and
one of the referenced OUTPUT JCL statements produces a separate set of printed
or punched output.

Processing options are not cumulative across a group of OUTPUT JCL statements.

Note that in JES3, when TYPE=DSISO and/or TRUNC=YES|NO are specified on

the SYSOUT initialization statement, and a sysout DD statement that does not
specify a class references multiple OUTPUT statements, the data set
DSISO/TRUNC characteristics are derived from the first class specification
encountered in the OUTPUT statements. If the DD statement does specify a class,
the DSISO/TRUNC characteristics are derived from that class.

Examples of the OUTPUT Parameter

Example 1
//J1 JOB ,’MARY LUDWIG’
//JOUT OUTPUT CLASS=C,FORMS=RECP,INDEX=6
//STEP1 EXEC PGM=XYZ
//SOUT OUTPUT CLASS=H,BURST=YES,CHARS=GT12,FLASH=BLHD
//ALL DD SYSOUT=(,),OUTPUT=(*.JOUT,*.SOUT),COPIES=5
//IN DD *
.
(data)
.
/*

The OUTPUT parameter references two OUTPUT JCL statements. Therefore, the
system prints the single sysout data set twice:
v For DD ALL combined with OUTPUT JOUT, the sysout data set is printed in
class C. In the installation, output class C is printed on a 3211 Printer. Combining
the parameters from the DD and OUTPUT JCL statements, the system prints 5
copies of the data set on form RECP and indents the left margin 5 spaces.
v For DD ALL combined with OUTPUT SOUT, the sysout data set is printed in
class H. In the installation, output class H is printed on a 3800 Printing
Subsystem. Combining the parameters from the DD and OUTPUT JCL
statements, the system prints 5 copies of the data set with the forms-overlay
frame named BLHD using character-arrangement table GT12 and bursts the
output.

Example 2
//J6 JOB ,’SUE THACKER’
//OUTA OUTPUT DEST=HQ
//STEP1 EXEC PGM=RDR
//OUTB OUTPUT CONTROL=DOUBLE
//DS1 DD SYSOUT=A,OUTPUT=(*.OUTA,*.OUTB)
//STEP2 EXEC PGM=WRT
//OUTC OUTPUT DEST=ID2742
//DS2 DD SYSOUT=A,OUTPUT=(*.OUTC,*.STEP1.OUTB)

The OUTPUT parameter on DS1 references:

v The job-level OUTPUT JCL statement OUTA to send the sysout data set to HQ.
v The step-level OUTPUT JCL statement OUTB to print the sysout data set
double-spaced on the local 3800 Printing Subsystem used for output class A.

The OUTPUT parameter on DS2 references:

v OUTPUT JCL statement OUTB in the first step to print the sysout data set
double-spaced on the local 3800 Printing Subsystem used for output class A.

Chapter 12. DD Statement 12-149

DD: OUTPUT
v OUTPUT JCL statement OUTC in the same step to send the sysout data set to
userid ID2742, which is attached to the local system.

Note: The references to OUTPUT JCL statements are in no particular order.

PATH Parameter
Parameter Type

Keyword, optional — use this parameter only with an HFS file

Purpose

Use the PATH parameter to specify the name of the HFS file.

Reference

For information on HFS files, see z/OS UNIX System Services User’s Guide.

Syntax
PATH=pathname

v Enclose the pathname value in single quotes if it contains a character other than:
Uppercase letters
Numbers
National characters
Slash (/)
Asterisk (*)
Plus (+)
Hyphen (-)
Period (.)
Ampersand (&)
v Enclose the pathname value in single quotes if you continue it on another statement. For
example:
//EXA DD PATH=’/u/payroll/directory171/DEPT64directory/account
// ingDIR/personhoursfile’

See Chapter 3. “Format of Statements” for the rules on continuing parameters in

apostrophes.

Subparameter Definition
pathname
Identifies a file in a hierarchical file system (HFS). The pathname consists of
the names of the directories from the root to the file being identified, and then
the name of the file.
Each directory or filename:
v Is preceded by a slash (/). The system treats any consecutive slashes as a
single slash.
v Can contain symbolic parameters.
v Has a length of 1 through 254 characters, not including the slash.
v Consists of printable characters from X’40’ through X’FE’. These printable
characters include all the characters that can be used in a portable filename,

12-150 z/OS V1R3.0 MVS JCL Reference

 DD: PATH
plus additional characters. For a portable filename, use only the portable
filename character set, which is listed in z/OS UNIX System Services User’s
Guide. A filename can contain characters outside this range, but it cannot be
specified in JCL.
v Is subject to symbolic substitution. An ampersand (&) (X'50'), followed by a
character string that matches a valid symbolic parameter in the JCL, causes
a substitution to occur, based on the syntax rules for symbolic parameters.
v Is case-sensitive. Thus, /u/joe and /u/JOE and /u/Joe define three different
files.

The pathname:
v Has the form:
/name1/name2/name3/.../namen
v Begins with a slash.
v Has a length of 1 through 255 characters. The system checks the length
after substituting for any symbols and before compressing any consecutive
slashes.

Defaults
Defaults for a DD statement with a PATH parameter are:
v If the PATHDISP parameter is not specified, the normal and abnormal disposition
is KEEP.
v If the PATHOPTS parameter is not specified, the status is OLD.

Relationship to Other Parameters

You can code the following parameters with the PATH parameter:

BLKSIZE
BUFNO
DSNTYPE
DUMMY
FILEDATA
LRECL
NCP
PATHDISP
PATHMODE
PATHOPTS
RECFM
TERM

Do not code PATHDISP, PATHMODE, or PATHOPTS on a DD statement without a

PATH parameter.

Do not code a PATH parameter on the following DD statements:

JOBCAT
JOBLIB
STEPCAT
STEPLIB
SYSABEND
SYSMDUMP
SYSUDUMP

Chapter 12. DD Statement 12-151

DD: PATH
Coding the PATH parameter is useful only when one of the following is true:
v The job runs on a system with both MVS SP5.2.2 or later and DFSMS/MVS 1.3.
At this level, programs can use standard MVS access methods to work with
hierarchical files. See z/OS DFSMS: Using Data Sets.
v The program being run has been coded to recognize and process the PATH
specification. Programs designed to use such DD statements must either:
– Use dynamic allocation information retrieval to obtain the information specified
for PATH, PATHOPTS, and PATHMODE, and pass it to the open() callable
service. See z/OS UNIX System Services User’s Guide for details on using
open().
– Use the C/370 fopen(//dd: ) function. fopen() handles the differences
between DD statements with PATH and DSN specified. See z/OS UNIX
System Services User’s Guide for details on using fopen().

If:
v You specify either:
– OCREAT alone

or:
– Both OCREAT and OEXCL
on the PATHOPTS parameter,

And if:
v The file does not exist,

Then MVS performs an open() function. The options from PATHOPTS, the
pathname from the PATH parameter, and the options from PATHMODE (if specified)
are used in the open(). MVS uses the close() function to close the file before the
application program receives control.

For status group options other than OCREAT and OEXCL, the description in this
book assumes that the application passes the subparameters to the open() function
without modification. That is, this application uses dynamic allocation information
retrieval (the DYNALLOC macro) to retrieve the values specified for PATHOPTS
and passes the values to the open() function. The application program can ignore
or modify the information specified in the JCL.

Relationship to Other Statements

A PATH parameter other than /dev/null on a DD statement that overrides a
procedure statement nullifies the DUMMY parameter on the overridden statement.

Backward and forward references to a DD statement containing a PATH parameter

are not permitted. For backward references, the referring DD statement is treated
as an error. For forward references, the DD statement referred to is treated as an
error.

Dummy HFS Files

The following DD statements define a dummy HFS file. The statements are
equivalent; for DUMMY3, the extra slashes (/) are compressed to single slashes.

//DUMMY1 DD PATH=’/dev/null’
//DUMMY2 DD DUMMY,PATH=/ANYNAME
//DUMMY3 DD PATH=’//dev///null’

12-152 z/OS V1R3.0 MVS JCL Reference

 DD: PATH
The system checks the syntax of pathnames specified with DUMMY. In the DD
statement DUMMY2, the pathname must be a valid name.

Example of the PATH Parameter

//DD1 DD PATH=’/usr/applics/pay.time’,PATHOPTS=ORDONLY

The DD statement specifies the HFS file pay.time that is listed in the directory
applics. The directory applics is listed in the directory usr. The PATHOPTS
parameter specifies that the program can only read the file.

The effects of the missing PATH parameters are:

v The file must already exist, because the statement does not specify
PATHOPTS=OCREAT.
v The system will keep the file for both normal and abnormal step terminations,
because the statement does not contain a PATHDISP parameter.
v The access permissions were set with a PATHMODE parameter when the file
was created.

PATHDISP Parameter
Parameter Type

Keyword, optional — use this parameter only with an HFS file

Purpose

Use the PATHDISP parameter to specify the disposition of an HFS file when the job
step ends normally or abnormally.

Reference

For information on HFS files, see z/OS UNIX System Services User’s Guide.

Syntax
PATHDISP={normal-termination-disposition }
={(normal-termination-disposition,abnormal-termination-disposition)}

PATHDISP=([KEEP ][,KEEP ])
=([DELETE][,DELETE])

A normal-termination-disposition or abnormal-termination-disposition is
one of the following:

KEEP
DELETE

v If you omit the normal-termination-disposition parameter, you must code a comma to

indicate its absence. For example: PATHDISP=(,DELETE)
v If you code only the normal-termination-disposition parameter, you may omit the
enclosing parentheses.

Chapter 12. DD Statement 12-153

DD: PATHDISP
Subparameter Definition
KEEP
Specifies that the file should be kept:
v When the step ends normally, KEEP is the first subparameter.
v When the step ends abnormally, KEEP is the second subparameter.
DELETE
Specifies that the file should be deleted:
v When the step ends normally, DELETE is the first subparameter.
v When the step ends abnormally, DELETE is the second subparameter.

Deleting a file deletes the name for the file. If the file has other names created
by link() functions, DELETE does not delete the file itself. The file persists until
all of its names are deleted.

Defaults
The system uses KEEP for both the normal and abnormal dispositions:
v If you do not code a value on the PATHDISP parameter — for example,
PATHDISP=(,)
v If you do not code a PATHDISP on a DD statement with a PATH parameter

If you code only a normal-termination-disp, such as PATHDISP=DELETE, the

abnormal disposition is the same as the normal disposition.

If you code only an abnormal-termination-disp, such as PATHDISP=(,DELETE), the

system uses KEEP for the normal disposition.

Relationship to Other Parameters

Code the PATHDISP parameter only on a DD statement that contains a PATH
parameter.

You can code the following parameters with the PATHDISP parameter:

BLKSIZE
BUFNO
DSNTYPE
DUMMY
FILEDATA
LRECL
NCP
PATH
PATHMODE
PATHOPTS
RECFM
TERM

Example of the PATHDISP Parameter

//DD1 DD PATH=’/usr/applics/pay.time’,PATHDISP=(KEEP,DELETE)

The DD statement identifies a file that already exists. The DD statement requests
that the system keep the file, if the step ends normally. If the step ends abnormally,
the system deletes the filename and, if no other names were set using link(),
deletes the file itself.

12-154 z/OS V1R3.0 MVS JCL Reference

 DD: PATHMODE

PATHMODE Parameter
Parameter Type

Keyword, optional — use this parameter only with an HFS file

Purpose

Use the PATHMODE parameter to specify the file access attributes when the
system is creating the HFS file named on the PATH parameter. Creating the file is
specified by a PATHOPTS=OCREAT parameter.

Reference

For information on HFS files, see the z/OS UNIX System Services User’s Guide.

Syntax
PATHMODE={file-access-attribute }
{(file-access-attribute[,file-access-attribute]...)}

A file-access-attribute is one of the following:

For file owner class: SIRUSR

SIWUSR
SIXUSR
SIRWXU

For file group class: SIRGRP

SIWGRP
SIXGRP
SIRWXG

For file other class: SIROTH

SIWOTH
SIXOTH
SIRWXO

To set user and group IDs: SISUID

SISGID

v You can specify up to 14 file-access-attributes.

v The file-access-attributes can be in any order.
v Duplicate file-access-attributes are treated as one specification.
v Do not code null positions. For example, do not code PATHMODE=(,file-access-attribute)
or PATHMODE=(file-access-attribute,,file-access-attribute).

Subparameter Definition
For File Owner Class
The file owner class consists of the user who created the file or who currently owns
the file. The user is identified by an OMVS user ID (UID).
SIRUSR
Specifies permission for the file owner to read the file.
SIWUSR
Specifies permission for the file owner to write the file.

Chapter 12. DD Statement 12-155

DD: PATHMODE
SIXUSR
Specifies permission for the file owner either:
v To search, if the file is a directory
v To execute the program in the file, for a file other than a directory
SIRWXU
Specifies permission for the file owner either:
v To read, write, and search, if the file is a directory
v To read, write, and execute, for a file other than a directory

This value has the same effect as specifying all three parameters (SIRUSR,
SIWUSR, and SIXUSR).

For File Group Class

The file group class contains the users who are in the same group as the file. The
group is identified by an OMVS group ID (GID).
SIRGRP
Specifies permission for users in the file group class to read the file.
SIWGRP
Specifies permission for users in the file group class to write the file.
SIXGRP
Specifies permission for users in the file group class either:
v To search, if the file is a directory
v To execute the program in the file, for a file other than a directory
SIRWXG
Specifies permission for users in the file group class either:
v To read, write, and search, if the file is a directory
v To read, write, and execute, for a file other than a directory

This value has the same effect as specifying all three parameters (SIRGRP,
SIWGRP, and SIXGRP).

For File Other Class

The file other class consists of all users other than the file owner or the members
of the file’s group who can access z/OS UNIX resources on the MVS system.
SIROTH
Specifies permission for users in the file other class to read the file.
SIWOTH
Specifies permission for users in the file other class to write the file.
SIXOTH
Specifies permission for users in the file other class either:
v To search, if the file is a directory
v To execute the program in the file, for a file other than a directory
SIRWXO
Specifies permission for users in the file other class either:
v To read, write, and search, if the file is a directory
v To read, write, and execute, for a file other than a directory

This value has the same effect as specifying all three parameters (SIROTH,
SIWOTH, and SIXOTH).

12-156 z/OS V1R3.0 MVS JCL Reference

 DD: PATHMODE
To Set User and Group IDs in a Program
These controls allow users to run a program with the user ID of the file owner or
the group ID of the file owner of the program file. They control access authorization
a particular program is running. The file owner can set the controls any time, not
just in the DD statement.

Do not specify these controls in JCL, because they will be reset when the file is
written.

The system overrides the SISUID and SISGID parameters and sets the controls so
that no users can run the program when either:
v The DD statement creates the file
v A user writes in the file, thus changing the program

Then, for the program to be run, the file owner must reset the controls.
SISUID
Specifies that the system set the user ID of the process to be the same as the
user ID of the file owner when the file is run as a program.
SISGID
Specifies that the system set the group ID of the process to be the same as the
group ID of the file owner when the file is run as a program. The group ID is
taken from the directory in which the file resides.

Defaults
When creating a new HFS file, if you do not code a PATHMODE on a DD statement
with a PATH parameter, the system sets the permissions to 0, which prevents
access by all users. If the HFS file already exists, PATHMODE is checked for
syntax but ignored. The permission bits are left as they are set.

Relationship to Other Parameters

Code the PATHMODE parameter only on a DD statement that contains both a
PATH parameter and a PATHOPTS parameter with OCREAT.

If OCREAT is not on the statement, the PATHMODE parameter is checked for

syntax and then ignored.

You can code the following parameters with the PATHMODE parameter:

BLKSIZE
BUFNO
DSNTYPE
DUMMY
FILEDATA
LRECL
NCP
PATH
PATHMODE
PATHOPTS
RECFM
TERM

If:
v You specify either:
– OCREAT alone

Chapter 12. DD Statement 12-157

DD: PATHMODE
or:
– Both OCREAT and OEXCL
on the PATHOPTS parameter,

And if:
v The file does not exist,

Then MVS performs an open() function. The options from PATHOPTS, the
pathname from the PATH parameter, and the options from PATHMODE (if specified)
are used in the open(). MVS uses the close() function to close the file before the
application program receives control.

For status group options other than OCREAT and OEXCL, the description in this
book assumes that the application passes the subparameters to the open() function
without modification. That is, this application uses dynamic allocation information
retrieval (the DYNALLOC macro) to retrieve the values specified for PATHOPTS
and passes the values to the open() function. The application program can ignore
or modify the information specified in the JCL.

Example of the PATHMODE Parameter

//DD1 DD PATH=’/usr/applics/pay.time’,PATHDISP=(KEEP,DELETE),
// PATHOPTS=(OWRONLY,OCREAT,OEXCL),PATHMODE=(SIRWXU,SIRGRP)

The DD statement requests that the file named in the PATH parameter be created.
The PATHMODE parameter specifies that the file owner can read, write, and search
or execute the file and that users in the file group can read the file.

PATHOPTS Parameter
Parameter Type

Keyword, optional — use this parameter only with an HFS file

Purpose

Use the PATHOPTS parameter to specify the access and status for the HFS file
named in the PATH parameter.

Reference

For information on HFS files, see z/OS UNIX System Services User’s Guide.

12-158 z/OS V1R3.0 MVS JCL Reference

 DD: PATHOPTS
Syntax
PATHOPTS={file-option }
{(file-option[,file-option]...)}

A file-option can be in the access or status group and is one of the following:

Access group: ORDONLY

OWRONLY
ORDWR

Status group: OAPPEND

OCREAT
OEXCL
ONOCTTY
ONONBLOCK
OSYNC
OTRUNC

v You can specify up to 7 file-options.

v The file-options can be in any order.
v Code only one file-option from the access group. If you specify more than one file-option
from the access group, the system uses ORDWR as the access.
v Code any combination of file-options from the status group.
v Duplicate file-options are treated as one specification.
v Do not code null positions. For example, do not code PATHOPTS=(,file-option) or
PATHOPTS=(file-option,,file-option).

Subparameter Definition
Access Group
ORDONLY
Specifies that the program should open the file for reading.
OWRONLY
Specifies that the program should open the file for writing.
ORDWR
Specifies that the program should open the file for reading and writing. Do not
use this option for a FIFO special file.

Status Group
OAPPEND
Specifies that MVS sets the file offset to the end of the file before each write, so
that data is written at the end of the file.
OCREAT
Specifies that:
v If the file does not exist, the system is to create it. If a directory specified in
the pathname does not exist, one is not created, and the new file is not
created.
v If the file already exists and OEXCL was not specified, the system allows the
program to use the existing file.
v If the file already exists and OEXCL was specified, the system fails the
allocation and the job step.

Chapter 12. DD Statement 12-159

DD: PATHOPTS
OEXCL
Specifies that:
v If the file does not exist, the system is to create it.
v If the file already exists, the system fails the allocation and the job step.

The system ignores OEXCL if OCREAT is not also specified.

ONOCTTY
Specifies that if the PATH parameter identifies a terminal device, opening of the
file does not make the terminal device the controlling terminal for the process.
ONONBLOCK
Specifies the following, depending on the type of file:
v For a FIFO special file:
– With ONONBLOCK specified and ORDONLY access: An open() function
for reading-only returns without delay.
– With ONONBLOCK not specified and ORDONLY access: An open()
function for reading-only blocks (waits) until a process opens the file for
writing.
– With ONONBLOCK specified and OWRONLY access: An open() function
for writing-only returns an error if no process currently has the file open
for reading.
– With ONONBLOCK not specified and OWRONLY access: An open()
function for writing-only blocks (waits) until a process opens the file for
reading.
v For a character special file that supports nonblocking open:
– If ONONBLOCK is specified: An open() function returns without blocking
(waiting) until the device is ready or available. Device response depends
on the type of device.
– If ONONBLOCK is not specified: An open() function blocks (waits) until
the device is ready or available.

Specification of ONONBLOCK has no effect on other file types.

OSYNC
Specifies that the system is to move data from buffer storage to permanent
storage before returning control from a callable service that performs a write.
OTRUNC
Specifies that the system is to truncate the file length to zero if all the following
are true:
v The file specified on the PATH parameter exists.
v The file is a regular file.
v The file successfully opened with ORDWR or OWRONLY.

The system does not change the mode and owner. OTRUNC has no effect on
FIFO special files or character special files.

Defaults
If you do not code a value on the PATHOPTS parameter or if you do not code a
PATHOPTS on a DD statement with a PATH parameter, the system assumes that
the pathname exists, searches for it, and issues a message if the pathname does
not exist.

12-160 z/OS V1R3.0 MVS JCL Reference

 DD: PATHOPTS
If the file exists and you specify PATHOPTS without a file-option for the access
group, the allocation succeeds. If the file does not exist and you specify PATHOPTS
without a file-option from the access group, the system fails to open the file and
issues a message.

Relationship to Other Parameters

Code the PATHOPTS parameter only on a DD statement that contains a PATH
parameter.

You can code the following parameters with the PATHOPTS parameter:

BLKSIZE
BUFNO
DSNTYPE
DUMMY
FILEDATA
LRECL
NCP
PATH
PATHMODE
PATHOPTS
RECFM
TERM

If:
v You specify either:
– OCREAT alone

or:
– Both OCREAT and OEXCL
on the PATHOPTS parameter,

And if:
v The file does not exist,

Then MVS performs an open() function. The options from PATHOPTS, the
pathname from the PATH parameter, and the options from PATHMODE (if specified)
are used in the open(). MVS uses the close() function to close the file before the
application program receives control.

For status group options other than OCREAT and OEXCL, the description in this
book assumes that the application passes the subparameters to the open() function
without modification. That is, this application uses dynamic allocation information
retrieval (the DYNALLOC macro) to retrieve the values specified for PATHOPTS
and passes the values to the open() function. The application program can ignore
or modify the information specified in the JCL.

File Status
The MVS system uses the PATHOPTS parameter to determine the status for the
file, as follows:
v OLD status:
– PATHOPTS is not on the DD statement.
– PATHOPTS does not contain a file option.
– PATHOPTS does not contain OCREAT.

Chapter 12. DD Statement 12-161

DD: PATHOPTS
v MOD status: PATHOPTS contains OCREAT but not OEXCL.
v NEW status: PATHOPTS contains both OCREAT and OEXCL.

Note: The DISP parameter cannot appear on a DD statement containing the PATH
parameter.

Example of the PATHOPTS Parameter

//DD1 DD PATH=’/usr/applics/pay.time’,PATHDISP=(KEEP,DELETE),
// PATHOPTS=(OWRONLY,OCREAT,OEXCL),PATHMODE=(SIRWXU,SIRGRP)

OCREAT in the PATHOPTS parameter specifies that the file named in the PATH
parameter be created. OWRONLY requests that the system open the file only for
writing. OEXCL specifies that, if the file already exists, the system will not create a
file and the job step will fail.

PROTECT Parameter
Parameter Type

Keyword, optional

Use the PROTECT parameter only if RACF is installed and active.

With SMS, use the SECMODEL parameter to protect data sets; SECMODEL is
described on page 12-176.

Purpose

Use the PROTECT parameter to tell the z/OS Security Server, which includes
RACF, to protect:
v One data set on a direct access volume.
v One data set on a tape volume with one of the following types of labels:
– IBM standard labels, LABEL=(,SL) or LABEL=(,SUL)
– ISO/ANSI/FIPS Version 3 labels, LABEL=(,AL) or LABEL=(,AUL)
– Nonstandard labels, LABEL=(,NSL), if the installation provides support
v An entire tape volume with one of the following:
– IBM standard labels, LABEL=(,SL) or LABEL=(,SUL)
– ISO/ANSI/FIPS Version 3 labels, LABEL=(,AL) or LABEL=(,AUL)
– Nonstandard labels, LABEL=(,NSL), if the installation provides support
– No labels, LABEL=(,NL)
– Bypassed label processing, LABEL=(,BLP)
– Leading tapemarks, LABEL=(,LTM)

References

For more information on RACF, see www.ibm.com/servers/eserver/zseries/racf/.

Syntax
PROTECT= {YES}
{Y }

12-162 z/OS V1R3.0 MVS JCL Reference

 DD: PROTECT
Subparameter Definition
YES
Requests RACF to protect a direct access data set, tape data set, or tape
volume. This parameter can also be coded as Y.

Overrides
With SMS, the DD SECMODEL parameter overrides the PROTECT=YES
parameter.

Relationship to Other Parameters

Do not code the following parameters with the PROTECT parameter.

* DLM QNAME
BURST DYNAM SYSOUT
CHARS FCB TERM
DATA FLASH UCS
DDNAME MODIFY

DSNAME Parameter for RACF-Protected Data Sets

RACF expects the data set name specified in the DSNAME parameter to have a
high-level qualifier that is defined to RACF. See the z/OS Security Server RACF
Security Administrator’s Guide for details.

Requirements for Protecting a Tape Data Set

A DD statement that contains a PROTECT parameter to establish RACF protection
for a tape data set must:
v Specify or imply VOLUME=PRIVATE.
v Specify or imply DISP=NEW, DISP=OLD, or DISP=SHR; it must not specify or
imply DISP=MOD.
v Specify in the LABEL parameter a label type of:
– SL or SUL for IBM standard labels.
– AL or AUL for ISO/ANSI Version 1 or ISO/ANSI/FIPS Version 3 tape labels.
– NSL for nonstandard labels. In this case, the NSL installation exit routine must
issue a RACDEF or RACROUTE TYPE=DEFINE macro instruction. See z/OS
Security Server RACROUTE Macro Reference for a description of these
macro instructions.
v If the data set is not the first on the volume, specify a data-set-sequence-number
in the LABEL parameter, which requires that the RACF TAPEDSN option be
active.

Requirements for Protecting a Tape Volume

A DD statement that contains a PROTECT parameter to establish RACF protection
for a tape volume must:
v Specify or imply VOLUME=PRIVATE.
v Specify or imply DISP=NEW.
v Specify in the LABEL parameter a label type of:
– SL or SUL for IBM standard labels.
– AL or AUL for ISO/ANSI Version 1 or ISO/ANSI/FIPS Version 3 tape labels.

Chapter 12. DD Statement 12-163

DD: PROTECT
– NSL for nonstandard labels. In this case, the NSL installation exit routine must
issue a RACDEF or RACROUTE TYPE=DEFINE macro instruction.
– NL for no labels.
– BLP for bypass label processing.
– LTM for leading tapemark.

Note that RACF cannot fully protect unlabeled tapes because RACF cannot verify
the volume serial number directly; the operator must verify the volume serial
number when mounting the tape volume.

Requirements for Protecting a Direct Access Data Set

A DD statement that contains a PROTECT parameter to establish RACF protection
for a direct access data set must:
v Name a permanent data set in the DSNAME parameter.
v Specify a status of DISP=NEW or MOD treated as NEW. RACF can establish
protection only when the data set is being created.

Examples of the PROTECT Parameter

Example 1
//DASD DD DSNAME=USER37.MYDATA,DISP=(,CATLG),
// VOLUME=SER=333000,UNIT=3330,SPACE=(TRK,2),PROTECT=YES

This DD statement requests RACF protection for the new direct access data set
USER37.MYDATA.

Example 2
//TAPEVOL DD DSNAME=MHB1.TAPEDS,DISP=(NEW,KEEP),LABEL=(,NL),
// VOLUME=SER=T49850,UNIT=3400-5,PROTECT=YES

This DD statement requests RACF protection for tape volume T49850. Because a
specific tape volume is requested, it automatically has the PRIVATE attribute. The
volume has no labels.

Example 3
//TAPEDS DD DSNAME=INST7.NEWDS,DISP=(NEW,CATLG),LABEL=(2,SUL),
// VOLUME=SER=223344,UNIT=3400-5,PROTECT=YES

This DD statement requests RACF protection for INST7.NEWDS, which is the

second data set on tape volume 223344. Because a specific tape volume is
requested, it automatically has the PRIVATE attribute. The volume has IBM
standard and user labels; the RACF TAPEDSN option must be active.

QNAME Parameter
Parameter Type

Keyword, optional

Purpose

Use the QNAME parameter to indicate that this DD statement defines a data set of
telecommunications access method (TCAM) messages. The QNAME parameter

12-164 z/OS V1R3.0 MVS JCL Reference

 DD: QNAME
refers to a TPROCESS macro instruction that defines a destination queue for the
messages. Optionally, the QNAME parameter can also name a TCAM job to
process the messages.

References

For information about TCAM and the TPROCESS macro instruction, see
ACF/TCAM Installation Reference.

Syntax
QNAME=procname[.tcamname]

Subparameter Definition
procname
Identifies a TPROCESS macro instruction; procname must be identical to the
procname in the name field of the TPROCESS macro instruction.
tcamname
Names a TCAM job: tcamname must be identical to the jobname. The TCAM
job can be a task started by an operator START command.

Relationship to Other Parameters

The only DD parameters that you can code with the QNAME parameter are DCB,
LIKE, LRECL, RECFM, and REFDD. The only DCB subparameters that you can
code with the QNAME parameter are: BLKSIZE, BUFL, LRECL, OPTCD, and
RECFM.

Examples of the QNAME Parameter

Example 1
//DYD DD QNAME=FIRST,DCB=(RECFM=FB,LRECL=80,BLKSIZE=320)

This DD statement defines a data set of TCAM messages. FIRST is the name of
the TPROCESS macro instruction that specifies the destination queue to which the
messages are routed. The DCB parameter supplies information not supplied in the
program’s DCB macro instruction for the data control block.

Example 2
//DXD DD QNAME=SECOND.TCAM01

This DD statement defines a data set of TCAM messages. SECOND is the name of
the TPROCESS macro instruction that specifies the destination queue to which the
messages are routed. TCAM program TCAM01 will process the messages.

RECFM Parameter
Parameter Type

Keyword, optional

Purpose

Chapter 12. DD Statement 12-165

DD: RECFM
Use the RECFM parameter to specify the format and characteristics of the records
in a new data set. All the format and characteristics must be completely described
in one source, that is, in the data set label of an existing data set, in the DCB
macro, in the DD DCB parameter, or in the DD RECFM parameter. However, the
processing program can modify the RECFM field in the DCB.

Code the RECFM parameter when you want to (1) specify the record format for the
data set or (2) with SMS, override the record format defined in the data class of the
data set.

The syntax of the RECFM parameter is described in the following topics:

v Coding RECFM for BDAM Access Method
v Coding RECFM for BPAM Access Method
v Coding RECFM for BSAM, EXCP, and QSAM Access Methods
v Coding RECFM for QISAM Access Method
v Coding RECFM for TCAM Access Method

Coding RECFM for BDAM Access Method

Syntax: BDAM Access Method

RECFM= {U }
{V }
{VS }
{VBS}
{F }
{FT }

U indicates that the records are undefined length.

V indicates that the records are variable length.
VS indicates that the records are variable length and spanned.
VBS indicates that the records are variable length, blocked, and spanned, and that the
problem program must block and segment the records.
F indicates that the records are fixed length.
T indicates that the records may be written using the track-overflow feature.

Default: undefined-length, unblocked records.

Coding RECFM for BPAM Access Method

Syntax: BPAM Access Method

RECFM= {U } [A]
{UT } [M]
{V }
{VB }
{VS }
{VT }
{VBS }
{VBT }
{VBST}
{F }
{FB }
{FT }
{FBT }

A or M can be coded with any record format, such as: RECFM=FBA

12-166 z/OS V1R3.0 MVS JCL Reference

 DD: RECFM
A indicates that the records contain ISO/ANSI control characters.
B indicates that the records are blocked.
F indicates that the records are fixed length.
M indicates that the records contain machine code control characters.
T indicates that the records may be written using the track-overflow feature.
U indicates that the records are undefined length.
V indicates that the records are variable length.

Default: U

Coding RECFM for BSAM, EXCP, and QSAM Access Methods

Syntax: BSAM, EXCP, and QSAM Access Methods

RECFM= {U } [A]
{UT } [M]
{F }
{FB }
{FS }
{FT }
{FBS }
{FBT }
{V }
{VB }
{VS }
{VT }
{VBS }
{VBT }
{VBST}

A or M can be coded with any record format, such as: RECFM=FBA

For BSAM, EXCP, and QSAM using ISO/ANSI/FIPS data sets on tape:
RECFM= {D } [A]
{DB }
{DS }
{DBS}
{U }
{F }
{FB }

A can be coded with any record format, such as: RECFM=FBA

Chapter 12. DD Statement 12-167

DD: RECFM
A or M cannot be specified if the PRTSP subparameter is specified.

A indicates that the record contains ISO/ANSI device control characters.

B indicates that the records are blocked.
D indicates that the records are variable-length ISO/ANSI tape records.
F indicates that the records are fixed length.
M indicates that the records contain machine code control characters.
S (1) For fixed-length records, indicates that the records are written as standard
blocks, that is, no truncated blocks or unfilled tracks within the data set, with the
exception of the last block or track. (2) For variable-length records, indicates that a
record can span more than one block.
T indicates that the records can be written using the track-overflow feature, if
required.
U indicates that the records are undefined length. U is invalid for an ISO/ANSI/FIPS
Version 3 tape data set.
V indicates that the records are variable length. V cannot be specified for (1) a
variable-length ISO/ANSI tape data set (specify D for this data set), (2) a card
reader data set, or (3) a 7-track tape unless the data conversion feature
(TRTCH=C) is used.

Default: U

Coding RECFM for QISAM Access Method

Syntax: QISAM Access Method
RECFM= {V }
{VB}
{F }
{FB}

B indicates that the records are blocked.

F indicates that the records are fixed length.
V indicates that the records are variable length; variable records cannot be in ASCII.

When creating indexed sequential data sets, you can code the RECFM subparameter; when
processing existing indexed sequential data sets, you must omit RECFM.

Default: V

Coding RECFM for TCAM Access Method

Syntax: TCAM Access Method

RECFM= {U }
{V }
{VB}
{F }

B indicates that the records are blocked.

F indicates that the records are fixed length.
U indicates that the records are undefined length.
V indicates that the records are variable length.

Default: U

12-168 z/OS V1R3.0 MVS JCL Reference

 DD: RECFM
Overrides
RECFM overrides the record format specified in the data set label, and with SMS,
RECFM overrides the record format defined in the DATACLAS parameter for the
data set. See “Overrides” on page 12-52.

Relationship to Other Parameters

Do not code the following DD parameters with the RECFM parameter.

* DDNAME
AMP DYNAM
DATA RECORG
DCB=DSORG
DCB=RECFM

Examples of the RECFM Parameter

Example 1
//DD1B DD DSNAME=EVER,DISP=(NEW,KEEP),UNIT=3380,
// RECFM=FB,LRECL=326,SPACE=(23472,(200,40))

In the example, the record format of fixed block (FB) is used for the new data set
EVER.

Example 2
//SMSDS6 DD DSNAME=MYDS6.PGM,DATACLAS=DCLAS06,DISP=(NEW,KEEP),
// RECFM=FB

In the example, the record format of fixed block (FB) overrides the record format
defined in the data class for the data set.

RECORG Parameter
Parameter Type

Keyword, optional — use this parameter only with SMS

Without SMS, see the AMP parameter described on page 12-23.

Purpose

Use the RECORG parameter to specify the organization of the records in a new
VSAM data set.

Code the RECORG parameter when you want to (1) specify the record organization
for the data set or (2) override the record organization defined in the data class of
the data set.

If SMS is not installed or is not active, the system syntax checks and then ignores
the RECORG parameter.

References

See z/OS DFSMS: Using Data Sets for information on VSAM data sets.

Chapter 12. DD Statement 12-169

DD: RECORG
Syntax
{KS}
RECORG= {ES}
{RR}
{LS}

Subparameter Definition
KS
Specifies a VSAM key-sequenced data set.
ES
Specifies a VSAM entry-sequenced data set.
RR
Specifies a VSAM relative record data set.
LS
Specifies a VSAM linear space data set.

Defaults
If you do not specify RECORG, SMS assumes a physical sequential (PS) or
partitioned (PO) data set.

Overrides
The RECORG parameter overrides the record organization defined in the
DATACLAS parameter for the data set. See “Overrides” on page 12-52.

Relationship to Other Parameters

Do not code the following DD parameters with the RECORG parameter.

* DDNAME
DATA DSNTYPE
DCB=DSORG DYNAM
DCB=RECFM RECFM

Example of the RECORG parameter

//SMSDS3 DD DSNAME=MYDS3.PGM,DATACLAS=VSAM1,DISP=(NEW,KEEP),
// RECORG=KS

In the example, the record organization of key-sequenced (KS) overrides the record
organization defined in the data class.

REFDD Parameter
Parameter Type

Keyword, optional — use this parameter only with SMS

Without SMS, use the DCB=*.ddname form of the DCB parameter described on
page 12-55.

12-170 z/OS V1R3.0 MVS JCL Reference

 DD: REFDD
Purpose

Use the REFDD parameter to specify attributes for a new data set by copying
attributes of a data set defined on an earlier DD statement in the same job.

The following attributes are copied to the new data set from (1) the attributes
specified on the referenced DD statement, and (2) for attributes not specified on the
referenced DD statement, from the data class of the data set specified by the
referenced DD statement:
v Data set organization
– Record organization (RECORG) or
– Record format (RECFM)
v Record length (LRECL)
v Key length (KEYLEN)
v Key offset (KEYOFF)
v Type, PDS or PDSE (DSNTYPE)
v Space allocation (AVGREC and SPACE)

Only RECFM and LRECL apply to tape data sets.

REFDD does not copy DCB attributes from the data set label. See the DD LIKE
parameter.

If SMS is not installed or is not active, the system checks the syntax and then
ignores the REFDD parameter.

The retention period (RETPD) or expiration date (EXPDT) is not copied to the new
data set.

Note: Do not use the REFDD parameter to copy attributes from a temporary data
set (&&dsname), partitioned data set if a member name is included, and
relative generation number for a GDG.

Syntax
{*.ddname }
REFDD= {*.stepname.ddname }
{*.stepname.procstepname.ddname}

Subparameter Definition
*.ddname
*.stepname.ddname
*.stepname.procstepname.ddname
Specify a backward reference to an earlier DD statement. The referenced DD
statement cannot name a cataloged data set or refer to another DD statement.
*.ddname
Specifies the ddname of an earlier DD statement in the same step.
*.stepname.ddname
Specifies the ddname of a DD statement in an earlier step, stepname, in
the same job.
*.stepname.procstepname.ddname
Specifies the ddname of a DD statement in a cataloged or in-stream

Chapter 12. DD Statement 12-171

DD: REFDD
procedure called by an earlier job step. Stepname is the name of the job
step that calls the procedure and procstepname is the name of the
procedure step that contains the DD statement.

Do not reference a DD * or a DD DATA statement.

Overrides
Any attributes specified on the referenced DD statement override the corresponding
data class attributes of the referenced data set.

Any attributes you specify on the referencing DD statement with the following
parameters override the corresponding attributes obtained from the referenced DD
statement and the data class attributes of the referenced data set.
RECORG (record organization) or RECFM (record format)
LRECL (record length)
KEYLEN (key length)
KEYOFF (key offset)
DSNTYPE (type, PDS or PDSE)
AVGREC (record request and space quantity)
SPACE (average record length, primary, secondary, and directory quantity)

Relationship to Other Parameters

Do not code the following DD parameters with the REFDD parameter.

DYNAM
LIKE

Examples of the REFDD Parameter

Example 1
//SMSDS6 DD DSNAME=MYDS6.PGM,DATACLAS=DCLAS01,DISP=(NEW,KEEP),
// LRECL=512,RECFM=FB
//SMSDS7 DD DSNAME=MYDS7.PGM,REFDD=*.SMSDS6,DISP=(NEW,KEEP)

In the example, the data set attributes used for MYDS7.PGM are obtained from the
referenced data set MYDS6.PGM.

Example 2
//SMSDS6 DD DSNAME=MYDS6.PGM,DATACLAS=DCLAS01,DISP=(NEW,KEEP),
// LRECL=512,RECFM=FB
//SMSDS8 DD DSNAME=MYDS8.PGM,REFDD=*.SMSDS6,DISP=(NEW,KEEP),
// LRECL=1024

In the example, the data set attributes used for MYDS8.PGM are obtained from the
referenced data set MYDS6.PGM. Also, the logical record length of 1024 overrides
the logical record length obtained from the referenced data set.

RETPD Parameter
Parameter Type

Keyword, optional

Purpose

12-172 z/OS V1R3.0 MVS JCL Reference

 DD: RETPD
Use the RETPD parameter to specify the retention period for a new data set to help
reduce the chance of later accidental deletion. After the retention period, the data
set can be deleted or written over by another data set.

If the DD statement contains DISP=(NEW,DELETE) or the DISP parameter is

omitted to default to NEW and DELETE, the system deletes the data set when the
step terminates normally or abnormally, even though a retention period is also
specified.

Do not specify RETPD for a temporary data set.

The RETPD parameter achieves the same result as the EXPDT parameter.

Code the RETPD parameter when you want to (1) specify a retention period for the
data set or (2) with SMS, override the retention period defined in the data class for
the data set.

Syntax
RETPD=nnnn

v The RETPD parameter can have a null value only when coded on a DD which either:
– Overrides a DD in a procedure
– Is added to a procedure.

Subparameter Definition
nnnn
Specifies the retention period, in days, for the data set. The nnnn is one
through four decimal digits (0 - 9999).
| The system adds nnnn to the current date to produce an expiration date. For
| SMS data sets, the system adds nnnn to the data set creation date to produce
| an expiration date. The calculated expiration date uses 365-day years and
366-day leap years.

Note: If you code RETPD and the calculated expiration date is December 31,
1999, the expiration date is set to January 1, 2000.

Overrides
With SMS, RETPD overrides the retention period defined in the DATACLAS
parameter for the data set. See “Overrides” on page 12-52.

With SMS, both the retention period specified on RETPD and defined in the data
class for an SMS-managed data set can be limited by a maximum retention period
defined in the management class for the data set.

Relationship to Other Parameters

Do not code the following DD parameters with the RETPD parameter.

* DYNAM
DATA EXPDT
DDNAME SYSOUT

Chapter 12. DD Statement 12-173

DD: RETPD
Deleting a Data Set Before its Retention Period Passes
To delete a data set before the retention period has passed, use one of the
following:
v For data sets cataloged in an integrated catalog facility catalog, use the DELETE
command, as described in z/OS DFSMS Access Method Services for Catalogs.
v For data sets not cataloged in an integrated catalog facility catalog, use the
IEHPROGM utility, as described in z/OS DFSMSdfp Utilities.
v For a non-VSAM data set, use the SCRATCH macro with the OVRD parameter,
as described in z/OS DFSMSdfp Advanced Services.
v The system operator can reply ″u″ to the IEC507D message prompt to delete
unexpired data sets.
v You can override the retention period for SMS-managed DASD data sets by
specifying OVRD_EXPDT(YES) in the IGDSMSxx SYS1.PARMLIB member and
specifying DELETE on the DD DISP statement. The data set will be deleted
whether or not the retention period has passed. See z/OS MVS Initialization and
Tuning Reference for information about the IGDSMSxx parmlib member.

Examples of the RETPD Parameter

Example 1
//DD1 DD DSNAME=HERBI,DISP=(NEW,KEEP),UNIT=TAPE,
// VOLUME=SER=T2,LABEL=(3,NSL),RETPD=188

In the example, the data set is not eligible for being deleted or written over for 188
days.

Example 2
//SMSDS2 DD DSNAME=MYDS2.PGM,DATACLAS=DCLAS02,DISP=(NEW,KEEP),
// RETPD=732

In the example, the retention period of 732 days overrides the retention period
defined in the data class for the data set.

RLS Parameter
Parameter Type

Keyword, optional

Purpose

You can, on a system that includes MVS/DFSMS Version 1 Release 3 or higher,

use the RLS parameter to specify the level of record sharing, or sharing protocol,
for a VSAM data set containing records that must be shared. See z/OS DFSMS:
Using Data Sets for a description of the sharing protocols and to determine whether
your application can run in a shared data environment without modification.

Note: RLS is most useful for an existing application. For a new or heavily-modified
application, you can request record-level sharing in application code and do
not need to specify RLS on the DD statement.

12-174 z/OS V1R3.0 MVS JCL Reference

 DD: RLS
Syntax
RLS= {NRI}
{CR }

Subparameter Definition
NRI
Specifies ″no read integrity″ (NRI). The application can read all records. Use
this subparameter if the application can read uncommitted changes made to a
data set by another application. NRI provides better performance than the CR
subparameter because it avoids the overhead of obtaining a lock when reading
a record from the data set.
CR
Specifies ″consistent read″ (CR). This subparameter requests VSAM to obtain a
SHARE lock on each record the application reads. This ensures the application
will not read uncommitted changes made to a data set by another application.
VSAM obtains the lock while processing a GET NUP request, and releases the
lock before completing the GET request. An application that processes a data
set allocated with RLS=CR may require modification if it tries to read changes
to the data set.

Overrides
Specifying RLS does not override any other JCL parameter. See z/OS DFSMS:
Using Data Sets for a description of how to override the RLS value specified in the
JCL.

Relationship to Other Parameters

Do not code the following DD parameters with the RLS parameter:

*
AMP DSNTYPE PATHDISP
BURST DYNAM QNAME
CHARS FLASH SEGMENT
COPIES MODIFY SPIN
DATA OUTPUT SYSOUT
DCB (see Note) PATH TERM
DDNAME PATHOPTS UCS
DLM PATHMODE

Note: You can code RLS with DCB as long as the only DCB subparameters you
specify are KEYLEN and LRECL.

Examples of the RLS Parameter

Example 1
// EXEC PGM=BATCHPRG
//DD1 DD DSN=A,RLS=NRI,DISP=SHR

When the program BATCHPRG opens DD1, the data set is to be processed as a
shared resource. NRI specifies that an application can read uncommitted changes
made by other applications.

Chapter 12. DD Statement 12-175

DD: RLS
Example 2
// EXEC PGM=BATCHPRG
//DD2 DD DSN=B,RLS=CR,DISP=SHR

When the program BATCHPRG opens DD2, the data set is to be processed as a
shared resource. CR specifies that an application can read only committed changes
made by other applications.

SECMODEL Parameter
Parameter Type

Keyword, optional — use this parameter only with SMS

Without SMS, use the DD PROTECT parameter described on page 12-162.

Purpose

Use the SECMODEL parameter to specify the name of an existing RACF data set
profile that is copied to the discrete data set profile that RACF builds for the new
data set.

The following information from the RACF data set profile, which RACF uses to
control access to the data set, is copied to the discrete data set profile of the new
data set:
v OWNER - indicates the user or group assigned as the owner of the data set
profile.
v ID - indicates the access list of users or groups authorized to access the data
set.
v UACC - indicates the universal access authority associated with the data set.
v AUDIT/GLOBALAUDIT - indicates which access attempts are logged.
v ERASE - indicates that the data set is to be erased when it is deleted
(scratched).
v LEVEL - indicates the installation-defined level indicator.
v DATA - indicates installation-defined information.
v WARNING - indicates that an unauthorized access causes RACF to issue a
warning message but allow access to the data set.
v SECLEVEL - indicates the name of an installation-defined security level.

Use the SECMODEL parameter (1) when you want a different RACF data set
profile than the default profile selected by RACF or (2) when there is no default
profile.

If SMS is not installed or is not active, the system syntax checks and then ignores
the SECMODEL parameter.

References

For information about RACF, see z/OS Security Server RACF Command Language
Reference.

12-176 z/OS V1R3.0 MVS JCL Reference

 DD: SECMODEL
Syntax
SECMODEL=(profile-name[,GENERIC])

Subparameter Definition
profile-name
Specifies the name of a RACF model profile, discrete data set profile, or
generic data set profile. The named profile is copied to the discrete data set
profile of the new data set.
If a generic data set profile is named, GENERIC must also be coded.
GENERIC
Identifies that the profile-name refers to a generic data set profile.

Overrides
The SECMODEL parameter overrides the PROTECT=YES parameter.

Relationship to Other Parameters

Do not code the following DD parameters with the SECMODEL parameter.

* DDNAME
DATA DYNAM

Examples of the SECMODEL Parameter

Example 1
//SMSDS4 DD DSNAME=MYDS4.PGM,SECMODEL=(GROUP4.DEPT1.DATA),
// DISP=(NEW,KEEP)

In the example, RACF uses the previously defined model data set profile named
GROUP4.DEPT1.DATA to control access to the new data set.

Example 2
//SMSDS5 DD DSNAME=MYDS5.PGM,SECMODEL=(GROUP5.*,GENERIC),
// DISP=(NEW,KEEP)

In the example, RACF uses the previously defined generic data set profile named
GROUP5.* to control access to the new data set.

SEGMENT Parameter
Parameter Type

Keyword, optional

Purpose

In a JES2 system, use the SEGMENT parameter to allow part of a job’s output to
be printed while the job is still executing, or to allow multiple segments of a job’s
output to be printed simultaneously on multiple printers. With SEGMENT, portions of
a data set are spun, one segment at a time. You determine the size of the portion
with the SEGMENT parameter. SEGMENT allows you to specify the number of

Chapter 12. DD Statement 12-177

DD: SEGMENT
pages produced for a sysout data set before the system processes the segment of
the data set. To count pages, JES2 uses the carriage control characters in the data
that skip to channel 1.

SEGMENT is supported by JES2 only. The SEGMENT parameter applies only to

line mode data sets with RECFM=A or RECFM=M.

Syntax
SEGMENT=page-count

Subparameter Definition
page-count
Indicates the number of pages produced for the sysout data set for the current
segment. When the number is reached, the system spins-off the data segment
for output processing.

Overrides
The system spins the sysout regardless of SPIN, FREE, and OUTDISP
specifications.

Relationship to Other Parameters

Do not code the following parameters with the SEGMENT parameter.

* DDNAME EXPDT QNAME

AMP DISP LABEL RETPD
CHKPT DSNAME LIKE SUBSYS
DATA DYNAM PROTECT VOLUME

Page mode data is not counted for segmentation.

The system might suspend segmentation if it reaches the threshold for

segmentation allowed by JES.

Example of the Segment Parameter

//DD1 DD SYSOUT=A,SEGMENT=100

In this example, if the sysout data set produced 400 pages, then four separate
segments, 100 pages in each, are produced for output processing.

SPACE Parameter
Parameter Type

Keyword, optional

Note: With SMS, code the SPACE parameter when you want to
v Request space for a new data set, or
v Override the space allocation defined in the DATACLAS parameter for the
data set.

12-178 z/OS V1R3.0 MVS JCL Reference

 DD: SPACE
See the DATACLAS parameter (described on page 12-50) and the AVGREC
parameter (described on page 12-31).

Purpose

Use the SPACE parameter to request space for a new data set on a direct access
volume. You can request space in two ways:
v Tell the system how much space you want and let the system assign specific
tracks.
v Tell the system the specific tracks to be allocated to the data set.

Letting the system assign the specific tracks is most frequently used. You specify
only how space is to be measured — in tracks, cylinders, blocks, or records — and
how many of those tracks, cylinders, blocks, or records are required.

The SPACE parameter has no meaning for tape volumes; however, if you assign a
data set to a device class that contains both direct access devices and tape
devices, for example, UNIT=SYSSQ, you should code the SPACE parameter.

If you code the SPACE parameter on a DD statement that defines an existing data
set, the SPACE value you specify temporarily overrides the SPACE value used to
create the data set. For example, a data set created with SPACE=(CYL,(5,1))
causes 5 cylinders to be allocated to the data set, and, if it needs more space, it
can obtain 1 additional cylinder.

Suppose, though, that there is one particular job that specifies DISP=MOD and will
write many records to this data set. JCL for this job can define, for example,
SPACE=(CYL,(5,10)) to obtain an additional 10 cylinders instead of just 1 cylinder.
The override, however, is in effect only for this job. Any other job that requires a
secondary extent and does not have a SPACE parameter override gets just the 1
additional cylinder specified in the JCL that created the job.

Notes
v When creating VSAM data sets, be aware that there is no direct one-to-one
correspondence between ‘define cluster’ parameters and JCL keyword
parameters.
v The average value in the SPACE keyword is meant to be an average block
length value for space calculations and is not meant to represent an LRECL
value.
v The AVGREC keyword is only to be used as a multiplier in determining how
much space is to be allocated.
v When defining VIO data sets, be aware that a SPACE parameter in the JCL or
the SPACE value defined for a data class will override the system default space
value.
v The size of a data set is limited to 65,536 tracks per volume except for the
following types of data sets:
– Hierarchical File System (HFS)
– Extended format sequential
– Partitioned data set extended (PDSE)
– VSAM

Chapter 12. DD Statement 12-179

DD: SPACE
Syntax
For system assignment of space:
SPACE= ({TRK,}(primary-qty[,second-qty][,directory])[,RLSE][,CONTIG][,ROUND])
({CYL,} [, ][,index ] [, ][,MXIG ]
({blklgth,} [,ALX ]
({reclgth,} [, ]

To request specific tracks:

SPACE= (ABSTR,(primary-qty,address [,directory])
[,index ]

To request only directory space:

SPACE=(,(,,directory))

v You can omit the parentheses around the primary quantity if you do not code secondary,
directory, or index quantities. For example,
SPACE=(TRK,20,RLSE,CONTIG) or SPACE=(TRK,20).

Note that if you omit these inner parentheses, you also omit the commas within them.

v All the subparameters are positional. Code a comma to indicate an omitted subparameter
if any others follow. Thus:
– If you code primary and directory or index quantities and omit a secondary quantity,
code a comma inside the inner parentheses to indicate the omission. For example,
SPACE=(TRK,(20,,2)).
– If you omit RLSE but code a following subparameter, code a comma to indicate the
omission. For example, SPACE=(TRK,(20,10),,CONTIG) or
SPACE=(TRK,20,,CONTIG).
– If you omit CONTIG, MXIG, or ALX and ROUND follows, code a comma to indicate
the omission. For example, SPACE=(400,30,RLSE,,ROUND). If you also omit RLSE,
this example becomes SPACE=(400,30,,,ROUND).

Subparameter Definition
System Assignment of Space
TRK
Requests that space be allocated in tracks.
CYL
Requests that space be allocated in cylinders.
blklgth — (only if AVGREC is not coded)
Specifies the average block length of the data, in bytes. The blklgth is a decimal
number from 0 through 65535. This parameter indicates that the values
specified for primary-qty and second-qty are block quantities, and directs the
system to compute the number of tracks to allocate using a block length. The
value specified for block size uses block length in this computation, with the
exception of the value zero. See primary-qty and second-qty descriptions for
how a zero block size is handled.
reclgth — (only if AVGREC is coded and SMS is active)
With SMS, specifies the average record length of the data, in bytes. The reclgth
is a decimal number from 0 through 65535. This parameter indicates that the
values specified for primary-qty and second-qty are record quantities, whose
average record length is reclgth. If you specify zero, no space will be allocated.

12-180 z/OS V1R3.0 MVS JCL Reference

 DD: SPACE
The system allocates DASD space in whole tracks. The number of tracks
required depends on how the records are blocked. The system uses one of the
following as the block length to compute the number of tracks to allocate, in the
order indicated:
1. The block size from the DCB parameter, if specified
2. The system determined block size, if available
3. A default value of 4096.
primary-qty
Specifies one of the following:
v For TRK, the number of tracks to be allocated.
v For CYL, the number of cylinders to be allocated.
v For a block length, the number of data blocks in the data set.
v For a record length, the number of records in the new data set. Use the
AVGREC parameter to specify that the primary quantity represents units,
thousands, or millions of records.

Note: When you specify TRK or CYL for a partitioned data set (PDS or PDSE),
the primary quantity includes the space for the directory. When you
specify a block length or record length for a partitioned data set (PDS or
PDSE), the primary quantity does not include the directory space; the
system assigns the directory to space outside the primary space
assignment.

If the data set does not have the space constraint relief option, one volume
must have enough available space for the primary quantity. If you request a
particular volume and it does not have enough space available for your request,
the system terminates the job step. In order for a data set to have the space
constraint relief option, it must be SMS-managed and the data class must
specify the option.

If you specify a blklgth of zero for the first subparameter, the system uses one
of the following as the block length to compute the number of tracks to allocate,
in the order indicated:
1. The block size from the DCB parameter, if specified
2. The block size determined from RECFM and LRECL on the DD statement
or data class, if available
3. A default value of 4096.

To request an entire volume, either code the ALX parameter or specify in the
primary quantity the number of tracks or cylinders on the volume minus the
number used by the volume table of contents (VTOC), volume label track,
VTOC index, and VVDS (if any). The volume must not contain other data sets.
second-qty
Specifies the number of additional tracks, cylinders, blocks, or records to be
allocated, if more space is needed. The system does not allocate additional
space until it is needed.
With SMS, use the AVGREC parameter to specify that the secondary quantity
represents units, thousands, or millions of records. The system computes the
number of tracks to allocate using a block length as indicated in the following
order:
1. The block size from the DCB parameter, if specified
2. The system determined block size, if available
3. A default value of 4096.

Chapter 12. DD Statement 12-181

DD: SPACE
If the first subparameter specifies the average block length, the system
computes the number of tracks for the secondary quantity from the second-qty
number and one of the following, in order:
1. The blklgth subparameter of the SPACE parameter.
2. The saved average block length value specified when the data set was
created, if no SPACE parameter was specified for an existing data set.
3. The block length in the BLKSIZE field of the data control block.

When you specify a secondary quantity and the data set requires additional
space, the system allocates the specified quantity:
v In contiguous tracks or cylinders, if available.
v If not available:
– If the data set does not have the space constraint relief option, in up to
five extents.
– With the space constraint relief option, the system might have to allocate
more than five new extents. A data set has this option only if it is
SMS-managed and the data class specifies the option.

The system can allocate up to 123 extents for a data set on a volume if it is a
PDSE, an HFS data set, an extended format data set, or a VSAM data set in
an ICF catalog. For other types of data sets the system can allocate up to 16
extents for each data set on each volume. An extent is space that may or may
not be contiguous to other space allocated to the data set. The extents for a
data set include the primary quantity space and user-label space.

Note: BDAM data sets cannot be extended.

When your program has filled a sequential data set’s allocated space on a
volume, the system determines where the following data is written as follows:
v If the disposition of the data set is NEW or MOD and the limit on the number
of extents on a volume has not been reached, the system attempts to
allocate the secondary quantity on the same volume.
v If the disposition of the data set is OLD or SHR, the system examines the
next volume specified for the data set.
– If space has been allocated on the next volume for the data set, the next
volume is used for the data set.
– If space has not been allocated on the next volume for the data set,
secondary space is allocated on the next volume for the data set.

If there is not another volume specified for the data set, the system attempts
to allocate the secondary quantity on the current volume.

Note that your program should not write with a disposition of DISP=SHR
unless you take precautions to prevent other programs from writing at the
same time.

If the requested volumes have no more available space and if at least one
volume is demountable, the system asks the operator to mount scratch
(nonspecific) volumes until the secondary allocation is complete. If none of the
volumes are demountable, the system abnormally terminates the job step.
directory
Specifies the number of 256-byte records needed in the directory of a
partitioned data set (PDS).

12-182 z/OS V1R3.0 MVS JCL Reference

 DD: SPACE
Note: When creating a partitioned data set (PDS), you must request space for
a directory. When creating a partitioned data set extended (PDSE), the
size of the directory grows dynamically as needed. SMS uses the size
requested for a PDSE directory only if you later convert the PDSE to a
PDS.

The PDS directory must fit in the first extent of the data set. If the primary
quantity is too small for the directory, or if the system has allocated the primary
quantity over multiple extents and the first extent is too small for the directory,
then the allocation fails.

With SMS, you can specify the number of directory records on the SPACE
parameter without specifying any other subparameters. For example:
//DD12 DD DSNAME=PDS.EXMP,DATACLAS=DCLAS12,SPACE=(,(,,20)),
// DISP=(NEW,KEEP)

specifies 20 directory records for the data set. In this example, the number of
specified directory records (20) overrides the number of directory records
defined in the data class of the data set. (SMS uses all other space allocation
attributes defined in the data class of the data set.)
index
For the index of an indexed sequential data set, specifies one of the following:
v For TRK, the number of tracks needed. The number of tracks must equal
one or more cylinders.
v For CYL, the number of cylinders needed.
RLSE (Partial Release)
Requests that space allocated to an output data set, but not used, is to be
released when the data set is closed. This partial release parameter causes
the close function to release unused space only if the data set is open to allow
writing and the last operation was not a read or a POINT macro.
For a multi-volume sequential data set, only unused space on the current
volume is released when the data set is closed; allocated space on any
subsequent volume is not affected.
If you specify RLSE and an abnormal termination occurs, the system does not
release unused space even though the data set is open.
RLSE is supported only for sequential, partitioned, and VSAM extended format
data sets.
Coding RLSE for primary allocation does not prohibit use of secondary
allocation. The secondary request for space is still in effect.
The system ignores a request to release unused space when closing a data set
if it cannot immediately obtain exclusive control of the data set. Circumstances
that would preclude obtaining exclusive control include:
v Another job is sharing the data set.
v Another task in the same multitasking job is processing an OPEN, CLOSE,
EOV, or FEOV request for the data set.
v Another data control block is open for the data set.

The RLSE subparameter is ignored when TYPE=T is coded in the CLOSE

macro instruction.

Chapter 12. DD Statement 12-183

DD: SPACE
When coding RLSE for an existing data set, code the unit of measurement and
primary quantity as they appeared in the original request. For example, if the
original request was:
SPACE=(TRK,(100,50))

you can release unused tracks when you retrieve the data set by coding:
SPACE=(TRK,(100),RLSE)

You can release space in the following additional ways other than by deleting
the data set:
v Partial release option in the management class
v DFSMShsm space management cycle
v PARTREL macro issued by an authorized program.
CONTIG
Requests that space allocated to the data set must be contiguous. This
subparameter affects only primary space allocation.
If CONTIG is specified and contiguous space is not available, the system
terminates the job step.
MXIG
Requests that space allocated to the data set must be (1) the largest area of
available contiguous space on the volume and (2) equal to or greater than the
primary quantity. This subparameter affects only primary space allocation.
Caution: IBM recommends that you use extreme care when coding this
parameter. Large amounts of storage could be allocated, depending on how
much free space is available at the time the request is made. If you code this
parameter, IBM recommends that you also code the RLSE parameter to release
any unused space.

Note: Do not code a MXIG subparameter for an indexed sequential data set.
ALX
Requests that space allocated to the data set is to be up to 5 of the largest
areas of available contiguous space on the volume, and each area must be
equal to or greater than the primary quantity. The system allocates fewer than 5
areas only when 5 areas of sufficient size are not available. ALX affects only
primary space allocation.
For example, assume the following space extents (in tracks) are available: 910,
435, 201, 102, 14, 12, and 8.
If your job requests 14 tracks as its primary allocation, and ALX is in effect, the
job receives the following 5 extents: 910, 435, 201, 102, and 14.
However, if the job requests 15 tracks as its primary allocation, it would receive
4 extents: 910, 435, 201, and 102. The job does not receive the 14-track extent
because it is less than the primary space allocation.
Caution: IBM recommends that you use extreme care when coding this
parameter. Large amounts of storage could be allocated, depending on how
much free space is available at the time the request is made. If you code this
parameter, IBM recommends that you also code the RLSE parameter to release
any unused space.

Note: Do not code an ALX subparameter for an indexed sequential data set.

12-184 z/OS V1R3.0 MVS JCL Reference

 DD: SPACE
ROUND
When the first subparameter specifies the average block length, requests that
space allocated to the data set must be equal to an integral number of
cylinders. If the first subparameter specifies TRK, or CYL, the system ignores
ROUND.

Request for Specific Tracks

For an SMS-managed data set (one with an assigned storage class), do not code
ABSTR.
ABSTR
Requests that the data set be allocated at the specified location on the volume.
primary-qty
Specifies the number of tracks to be allocated to the data set.
The volume must have enough available space for the primary quantity. If it
does not, the system terminates the job step.
address
Specifies the track number of the first track to be allocated. Count the first track
of the first cylinder on the volume as 0. Count through the tracks on each
cylinder until you reach the track on which you want the data set to start.
address
Specifies the track number of the first track to be allocated. Count the first
track of the first cylinder on the volume as 0. Count through the tracks on
each cylinder until you reach the track on which you want the data set to
start. The absolute track address must be a decimal number equal to or
less than 65535.

Note: Do not request track 0.

directory
Specifies the number of 256-byte records needed in the directory of a
partitioned data set.

Note: When creating a partitioned data set, you must request space for a
directory.
index
Specifies the number of tracks needed for the index of an indexed sequential
data set. The number of tracks must equal one or more cylinders.

Overrides
With SMS, the SPACE parameter overrides the space allocation attributes defined
in the data class for the data set.

Explicit specification of SPACE on the DD statement overrides both the SPACE and
the AVGREC values specified in the data class.

Relationship to Other Parameters

Do not code the following parameters with the SPACE parameter.

* DYNAM
DATA QNAME
DDNAME SUBSYS

Chapter 12. DD Statement 12-185

DD: SPACE
With KEYLEN for Block Requests

If space is requested in blocks and the blocks have keys, code the DD parameter
KEYLEN (or the DCB subparameter KEYLEN) on the DD statement and specify the
key length.

SPACE for New Data Sets with SMS

With SMS, code the SPACE parameter with or without the AVGREC parameter
when you want to (1) request space for the data set or (2) override the space
allocation attributes defined in the data class for the data set.

Examples of the SPACE Parameter

Example 1
//DD1 DD DSNAME=&&TEMP,UNIT=MIXED,SPACE=(CYL,10)

The DD statement defines a temporary data set. The UNIT parameter requests any
available tape or direct access volume; MIXED is the installation’s name for a group
of tape and direct access devices. If a tape volume is assigned, the SPACE
parameter is ignored; if a direct access volume is assigned, the SPACE parameter
is used to allocate space to the data set. The SPACE parameter specifies only the
required subparameters: the type of allocation and a primary quantity. It requests
that the system allocate 10 cylinders.

Example 2
//DD2 DD DSNAME=PDS12,DISP=(,KEEP),UNIT=3350,
// VOLUME=SER=25143,SPACE=(CYL,(10,,10),,CONTIG)

The DD statement defines a new partitioned data set. The system allocates 10
cylinders to the data set, of which ten 256-byte records are for a directory. Since
the CONTIG subparameter is coded, the system allocates 10 contiguous cylinders
on the volume.

Example 3
//REQUEST1 DD DSNAME=EXM,DISP=NEW,UNIT=3330,VOLUME=SER=606674,
// SPACE=(1024,75),DCB=KEYLEN=8
//REQUESTA DD DSNAME=EXQ,DISP=NEW,UNIT=3380,
// SPACE=(1024,75),DCB=KEYLEN=8

These DD statements request space in block lengths. The average block length of
the data is 1024 bytes. 75 blocks of data are expected as output. Each block is
preceded by a key eight bytes long. The system computes how many tracks are
needed, depending on the device requested in the UNIT parameter.

Example 4
//REQUEST2 DD DSNAME=PET,DISP=NEW,UNIT=3330,VOLUME=SER=606674,
// SPACE=(ABSTR,(5,1))

In this example, the SPACE parameter asks the system to allocate 5 tracks,
beginning on the second track of the volume.

Example 5
//DD3 DD DSNAME=MULTIVOL,UNIT=3350,DISP=(,CATLG),
// VOLUME=SER=(223344,223345),SPACE=(CYL,(554,554))

12-186 z/OS V1R3.0 MVS JCL Reference

 DD: SPACE
This example shows how to create a multivolume data set on two complete
volumes. The two volumes do not contain other data sets. A volume on 3350 Direct
Access Storage contains 555 cylinders. The unrequested cylinder contains the
volume table of contents (VTOC).

Example 6
//SMSDS3 DD DSNAME=MYDS3.PGM,DATACLAS=DCLAS03,DISP=(NEW,KEEP),
// SPACE=(128,(5,2)),AVGREC=K

In this example, the space allocation defined in the DCLAS03 data class is
overridden by the SPACE and AVGREC parameters, which indicate an average
record length of 128 bytes, a primary quantity of 5K (5,120) records, and a
secondary quantity of 2K (2,048) records.

SPIN Parameter
Parameter type

Keyword, optional

Purpose

Use the SPIN parameter to specify that the output for the sysout data set is to be
made available for processing
v Immediately upon unallocation
v At the end of the job.

Syntax
SPIN= {UNALLOC}
{NO }

Subparameter Definition
UNALLOC
Indicates that the system makes the data set available for processing
immediately when the data set is unallocated. If you dynamically unallocate the
sysout data set, either explicitly or by specifying FREE=CLOSE, the system
makes the data set available for processing immediately. If you do not
dynamically unallocate it, the sysout data set is unallocated at the end of the
step, and the system will make it available for processing then.
NO
Indicates that the system makes the sysout data set available for processing as
a part of the output at the end of the job, regardless of when the data set is
unallocated.

Defaults
If you dynamically unallocate the sysout data set, the default is that the data set is
immediately available for processing. If you unallocate the sysout data set at the
end of the step, the default is that the data set is available for processing. at the
end of the job.

If you specify FREE=CLOSE, the following defaults apply:

Chapter 12. DD Statement 12-187

DD: SPIN
v A data set that is closed by the application program is available for processing
immediately.
v A data set that is closed as part of the end-of-step cleanup, such as for a
program abend, is available for processing at the end of the job.

If you specify FREE=END, the default is that the data set is available for processing
at the end of the job.

Overrides
The SEGMENT parameter overrides the SPIN parameter.

Note: Another way for a program to control when the sysout data set becomes
available for processing is to issue a SETPRT macro. For more information,
see z/OS DFSMS Macro Instructions for Data Sets.

Relationship to Other Parameters

Do not code the following parameters with the SPIN parameter.

* DDNAME LABEL RETPD

AMP DISP LIKE SUBSYS
CHKPT DYNAM PROTECT VOLUME
DATA EXPDT QNAME

Examples of the SPIN Parameter

Example 1
//DD1 DD SYSOUT=A,FREE=CLOSE,SPIN=UNALLOC

In this example, if you explicitly close or dynamically unallocate the sysout data set,
the system makes it available for printing immediately. If you do not explicitly close
or dynamically unallocate the sysout data set, the system makes it available for
printing at the end of the step.

Example 2
//DD2 DD SYSOUT=A,FREE=CLOSE,SPIN=NO

In this example, the system makes the sysout data set available for printing at the
end of the job, regardless of when it is unallocated or closed.

Example 3
//DD3 DD SYSOUT=A,FREE=END,SPIN=UNALLOC

In this example, the sysout data set is unallocated at the end of the step, and made
available for printing then. If you dynamically unallocate the sysout data set, the
system makes it available for printing immediately.

Example 4
//DD4 DD SYSOUT=A,FREE=END,SPIN=NO

In this example, the system makes the sysout data set available for printing at the
end of the job, regardless of whether the data set is unallocated or closed.

12-188 z/OS V1R3.0 MVS JCL Reference

 DD: STORCLAS

STORCLAS Parameter
Parameter Type

Keyword, optional — use this parameter only with SMS and for SMS-managed data
sets

Without SMS or for non-SMS-managed data sets, use the UNIT parameter
(described on page 12-203) and the VOLUME parameter (described on page
12-210).

Purpose

Use the STORCLAS parameter to specify a storage class for a new SMS-managed
data set. The storage administrator at your installation defines the names of the
storage classes you can code on the STORCLAS parameter.

The storage class contains the attributes that identify a storage service level to be
used by SMS for storage of the data set. It replaces the storage attributes that are
specified on the UNIT and VOLUME parameters for non-SMS-managed data sets.

An SMS-managed data set is defined as a data set that has a storage class
assigned. A storage class is assigned when either (1) you specify the STORCLAS
parameter or (2) an installation-written automatic class selection (ACS) routine
selects a storage class for a new data set.

If SMS is not installed or is not active, the system syntax checks and then ignores
the STORCLAS parameter.

SMS ignores the STORCLAS parameter if you specify it for an existing data set.

The use of a storage class can be protected by RACF.

References

See z/OS DFSMS: Using the Interactive Storage Management Facility for
information on how to use ISMF to view your installation-defined storage classes.

Syntax

STORCLAS=storage-class-name

Subparameter Definition
storage-class-name
Specifies the name of a storage class to be used for storage of the data set.
The name, one to eight characters, is defined by the storage administrator at
your installation.

Defaults
If you do not specify STORCLAS for a new data set and the storage administrator
has provided an installation-written automatic class selection (ACS) routine, the

Chapter 12. DD Statement 12-189

DD: STORCLAS
ACS routine may select a storage class for the data set. Check with your storage
administrator to determine if an ACS routine will select a storage class for the new
data set, in which case you do not need to specify STORCLAS.

Overrides
No attributes in the storage class can be overridden by JCL parameters.

An ACS routine can override the storage class that you specify on the STORCLAS
parameter.

Relationship to Other Parameters

If the storage administrator has specified GUARANTEED_SPACE=YES in the
storage class, then volume serial numbers you specify on the VOLUME=SER
parameter override the volume serial numbers used by SMS. Otherwise, volume
serial numbers are ignored.

Do not code the following DD parameters with the STORCLAS parameter.

* DYNAM UNIT=AFF
DATA QNAME VOLUME=REF
DDNAME

Examples of the STORCLAS Parameter

Example 1
//SMSDS1 DD DSNAME=MYDS1.PGM,STORCLAS=SCLAS01,DISP=(NEW,KEEP)

In the example, SMS uses the attributes in the storage class named SCLAS01 for
the storage service level of the data set. Note that installation-written ACS routines
may select a management class and data class and can override the specified
storage class.

Example 2
//SMSDS2 DD DSNAME=MYDS2.PGM,STORCLAS=SCLAS02,DISP=(NEW,KEEP),
// VOLUME=SER=(223344,224444)

In the example, SMS uses the attributes in the storage class named SCLAS02 for
the storage service level of the data set. Also, if the storage administrator has
specified GUARANTEED_SPACE=YES in the storage class, VOLUME=SER can be
coded and the data set will reside on the specified volumes. (However, if space is
not available on the volumes, the job step fails.) Note that installation-written ACS
routines may select a management class and data class and can override the
specified storage class.

SUBSYS Parameter
Parameter Type

Keyword, optional

Purpose

Use the SUBSYS parameter to request a subsystem to process this data set and,
optionally, to specify parameters defined by the subsystem.

12-190 z/OS V1R3.0 MVS JCL Reference

 DD: SUBSYS
Do not use the SUBSYS parameter for an SMS-managed data set (one with an
assigned storage class).

In a loosely-coupled multiprocessing environment, the requested subsystem must

be defined on all processors that could interpret this DD statement.

Considerations for an APPC Scheduling Environment

In an APPC scheduling environment, avoid coding the system symbolic SYSUID on

the SUBSYS parameter. Symbolic substitution is inconsistent when you code
SYSUID as a subparameter of SUBSYS parameter.

References

For more information on the SUBSYS parameter and subsystem-defined

parameters, refer to the documentation for the requested subsystem.

Syntax
SUBSYS= {subsystem-name }
{(subsystem-name[,subsystem-subparameter]...)}
Single Subparameter: You can omit the parentheses if you code only the subsystem-name.

Number of Subparameters : If needed, you can code up to 254 subsystem-subparameters

on a JES2 system, or up to 1020 bytes of data on a JES3 system.

Multiple Subparameters: When the parameter contains more than the subsystem-name,
separate the subparameters by commas and enclose the subparameter list in parentheses.
For example, SUBSYS=(XYZ,1724,DT25).

Positional Subparameters: If you omit a subparameter that the subsystem considers

positional, code a comma in its place.

Special Characters: When a subparameter contains special characters, enclose the

subparameter in apostrophes. For example, SUBSYS=(XYZ,1724,'KEY=Y').

Code each apostrophe that is part of a subparameter as two consecutive apostrophes. For
example, code O’Day as SUBSYS=(XYX,1724,'NAME=O''DAY').

If you code a symbolic parameter on the SUBSYS parameter, you can code the symbolic
parameter in apostrophes.

Continuation onto Another Statement: Enclose the subparameter list in only one set of
parentheses. End each statement with a comma after a complete subparameter. For
example:
//DS1 DD DSNAME=DATA1,SUBSYS=(XYZ,1724,’KEY=Y’,
// DT25,’NAME=O’’DAY’)

Note: The SUBSYS parameter can have a null value only when coded on a DD which
either:
v Overrides a DD in a procedure
v Is added to a procedure.

Subparameter Definition
subsystem-name
Identifies the subsystem. The subsystem name is 1 through 4 alphanumeric or

Chapter 12. DD Statement 12-191

DD: SUBSYS
national ($, #, @) characters; the first character must be alphabetic or national
($, #, @). The subsystem must be available in the installation.
subsystem-subparameter
Specifies information needed by the subsystem. A subparameter consists of
alphanumeric, national ($, #, @), or special characters.

Relationship to Other Parameters

Do not code the following DD parameters with the SUBSYS parameter:

* CHARS DDNAME MODIFY

AMP COPIES DYNAM QNAME
BURST DATA FLASH SYSOUT

The specified subsystem can define other parameters that you must not code with
the SUBSYS parameter:

Ignored but Permitted DD Parameters

If you specify any of the following DD parameters,the system checks them for
syntax and then ignores them:

FCB
UNIT

If you specify the SPACE parameter, the system checks its syntax and then ignores
it, but the subsystem designated on the SUBSYS parameter may use this
information when it allocates the DD.

DISP Parameter

The system checks the DISP status subparameter for syntax, but always indicates
a status of MOD to the subsystem. If the DISP normal or abnormal termination
subparameter is CATLG or UNCATLG, the system allocates the appropriate catalog
to the subsystem.

DUMMY Parameter

If DUMMY is specified with SUBSYS, the subsystem checks the syntax of the
subsystem subparameters. If they are acceptable, the system treats the data set as
a dummy data set.

When This Statement Overrides a Procedure Statement

If SUBSYS appears on a DD statement that overrides a DD statement in a

cataloged or in-stream procedure, the following occurs:
v The system ignores a UNIT parameter, if specified, on the overridden DD
statement.
v The system nullifies a DUMMY parameter, if specified, on the overridden DD
statement.

12-192 z/OS V1R3.0 MVS JCL Reference

 DD: SUBSYS
Examples of the SUBSYS Parameter
Example 1
//DD1 DD DSNAME=ANYDS,DISP=OLD,SUBSYS=ABC

The DD statement asks subsystem ABC to process data set ANYDS.

Example 2
//DD1 DD DSNAME=ANYDS,DISP=OLD,SUBSYS=(XYZ2,
// ’KEYWORD=DATA VALUE1’)

The DD statement asks subsystem XYZ2 to process data set ANYDS. The system
passes the subparameter KEYWORD=DATA VALUE1 to the subsystem. The
parameter is enclosed in apostrophes because it contains an equal sign and a
blank, which are special characters.

Example 3
//DD1 DD DSNAME=ANYDS,DISP=OLD,SUBSYS=(XYZ2,IKJ2,
// ’NAME=’’MODULE1’’’,’DATE=4/11/86’)

The DD statement asks subsystem XYZ2 to process the data set ANYDS. The
system passes three subparameters to the subsystem: IKJ2, NAME='MODULE1'
and DATE=4/11/86. Note that the character string MODULE1 is passed to the
subsystem enclosed in apostrophes.

SYSOUT Parameter
Parameter Type

Keyword, optional

Purpose

Use the SYSOUT parameter to identify this data set as a system output data set,
usually called a sysout data set.

Do not use the SYSOUT parameter for an SMS-managed data set (one with an
assigned storage class).

The SYSOUT parameter also:

v Assigns this sysout data set to an output class. The attributes of each output
class are defined during JES initialization.
v Optionally requests an external writer to process the sysout data set rather than
JES. An external writer is an IBM- or installation-written program.
v Optionally identifies the forms on which the data set is to be printed or punched.
v Optionally refers to a JES2 /*OUTPUT statement for processing parameters.

The sysout data set is processed according to the following processing options, in
override order:
1. The options specified on this sysout DD statement.
2. The options specified on a referenced OUTPUT JCL statement.
3. The options specified on a referenced JES2 /*OUTPUT statement or on a JES3
//*FORMAT statement.
4. The installation default options for the requested output class.

Chapter 12. DD Statement 12-193

DD: SYSOUT
Notes:
1. If a sysout data set has the same class as the JOB statement MSGCLASS
parameter, the job log appears on the same output listing as this sysout data
set.
2. An installation should maintain a list of available output classes and their
attributes. Some classes should be used for most printing and punching, but
others should be reserved for special processing. Each class is processed by
an output writer. The system operator starts the output writers for the commonly
used output classes. If you plan to specify a special output class, ask the
operator to start the output writer for that class. If the writer is not started before
the job produces the sysout data set, the data set is retained until the writer is
started.
3. If the automatic restart manager (ARM) restarts a job, JES discards all non-spin
sysout data sets created during the previous execution. (You can avoid losing
that output by adding SPIN=UNALLOC to the DD statement for the SYSOUT
data set.)

References

For information on output writers and external writers, see z/OS MVS Using the
Subsystem Interface.

Syntax
SYSOUT= { class }
{ * }
{ ([class] [,writer-name] [,form-name]) }
[,INTRDR ] [,code-name]

SYSOUT=(,)

v You can omit the parentheses if you code only a class.

v All of the subparameters are positional. Code a comma to indicate an omitted
subparameter as follows:
– If you omit the class, code a comma to indicate the omission. For example, when
other subparameters follow, code SYSOUT=(,INTRDR,FM26). When other
subparameters do not follow, code a null class as SYSOUT=(,).
– If you omit a writer-name but code a form-name or code-name, code a comma to
indicate the omission. For example, SYSOUT=(A,,FM26).
– Omission of the third subparameter does not require a comma. For example,
SYSOUT=A or SYSOUT=(A,INTRDR).

Subparameter Definition
class
Identifies the output class for the data set. The class is one character: A through
Z or 0 through 9, which you may optionally include in quotation marks. The
attributes of each output class are defined during JES initialization; specify the
class with the desired attributes.
* Requests the output class in the MSGCLASS parameter on the JOB statement.
In a JES2 system you can also use the dollar-sign ($) to request the output
class in the MSGCLASS parameter on the JOB statement.

12-194 z/OS V1R3.0 MVS JCL Reference

 DD: SYSOUT
(,) Specifies a null class. A null class must be coded to use the CLASS parameter
on a referenced OUTPUT JCL statement.
writer-name
Identifies the member name (1 to 8 alphanumeric characters) of an
installation-written program.
An external writer is a started task used to process output. Because the
external writer is a started task, it has a userid associated with it. Process
output with an external writer by naming the writer on the DD statement that
defines the output:
//MYOUTPUT DD SYSOUT=(A,XTWTR)

In order for the writer to process that output, the writer’s userid must be in a
RACF access list. The access list permits the writer’s userid to the SYSOUT
data set. The writer’s userid is the userid specified in the started procedure
table for the writer task. If your installation’s policy requires security labels, the
security label associated with the external writer must be equal to or greater
than the security label associated with the SYSOUT. For more information, see
your security administrator.

Do not code STDWTR as a writer-name. STDWTR is reserved for JES and

used as a parameter in the MVS operator’s MODIFY command.

In a JES3 system, do not code NJERDR as a writer-name. NJERDR is

reserved for JES3.
INTRDR
Tells JES that this sysout data set is to be sent to the internal reader as an
input job stream.
form-name
Identifies the print or punch forms. form-name is 1 through 4 alphanumeric or
national ($, #, @) characters.
code-name
Identifies an earlier JES2 /*OUTPUT statement from which JES2 is to obtain
processing characteristics. The code-name must be the same as the code
parameter on the JES2 /*OUTPUT statement.

Note:
v code-name is supported only on JES2 systems.
v Do not specify the code-name subparameter when the job or job step
contains a default OUTPUT JCL statement.

Defaults
In a JES2 system, if you do not specify a class on this DD statement or a
referenced OUTPUT JCL statement, JES2 assigns the sysout data set to the output
class defined by the MSGCLASS value of the JOB statement. See the override
order shown under ″Purpose″ for how this default is established.

If you do not code a writer-name subparameter on this DD statement or a

referenced OUTPUT JCL statement, the installation’s job entry subsystem
processes the sysout data set.

If you do not code a form-name subparameter on this DD statement or a referenced

OUTPUT JCL statement, JES uses an installation default specified at initialization.

Chapter 12. DD Statement 12-195

DD: SYSOUT
Overrides
The class subparameter of the DD statement SYSOUT parameter overrides an
OUTPUT JCL CLASS parameter. On the DD statement, you must code a null class
in order to use the OUTPUT JCL CLASS parameter; for example:
//OUTDS DD SYSOUT=(,),OUTPUT=*.OUT1

The writer-name subparameter of the DD statement SYSOUT parameter overrides

an OUTPUT JCL WRITER parameter.

The form-name subparameter of the DD statement SYSOUT parameter overrides

an OUTPUT JCL FORMS parameter. Note that the SYSOUT form-name
subparameter can be only four characters maximum while both the OUTPUT JCL
FORMS form-name and the JES initialization default form names can be eight
characters maximum.

Relationship to Other Parameters

Do not code the following DD parameters with the SYSOUT parameter.

* DDNAME LIKE
AMP DISP PROTECT
CHKPT DYNAM QNAME
DATA EXPDT RETPD
DATACLAS LABEL SUBSYS
VOLUME

Ignored Parameters

Because JES allocates sysout data sets, the UNIT and SPACE parameters are
ignored, if coded on a sysout DD statement.

Parameters on Procedure DD Statements that are Overridden

When an overriding DD statement contains a SYSOUT parameter, the system

ignores a UNIT parameter on the overridden DD statement in the cataloged or
in-stream procedure.

Naming a Sysout Data Set

Code the DSNAME parameter with the SYSOUT parameter if you wish to assign
the last qualifier of the system-generated name to a sysout data set.

SYSOUT and DEST Subparameters

Do not code the SYSOUT writer-name subparameter when coding a DEST userid
subparameter. These subparameters are mutually exclusive. You can code:
//VALID1 DD SYSOUT=D,DEST=(node,userid)
//VALID2 DD SYSOUT=(D,writer-name),DEST=(node)

With DCB Subparameters

JES2 ignores DCB=PRTSP=2 on a DD statement that also contains a SYSOUT

parameter.

12-196 z/OS V1R3.0 MVS JCL Reference

 DD: SYSOUT
For JES, it is not necessary to select a specific BLKSIZE on the DCB parameter for
performance reasons because the subsystem selects its own blocking.

INTRDR with OUTPUT Parameter

Do not code an OUTPUT parameter when the writer-name subparameter is

INTRDR.

Relationship to Other Control Statements

A sysout DD statement can directly or indirectly reference an OUTPUT JCL
statement. The parameters on the referenced OUTPUT JCL statement combine
with the parameters on the sysout DD statement to control the processing of the
sysout data set. See “OUTPUT Parameter” on page 12-146 and Chapter 22,
“OUTPUT JCL Statement”.

SYSOUT cannot specify a code-name subparameter in a job or job step that

contains an OUTPUT JCL statement; in this case, JES2 treats the third
subparameter as a form-name, instead of a reference to a JES2 /*OUTPUT
statement.

Backward References

Do not refer to an earlier DD statement that contains a SYSOUT parameter.

Starting an External Writer when Requested

When a statement supplying processing options for a sysout data set specifies an
external writer, the writer must be started before it can print or punch the data set.
The writer is started by a system command from the operator or in the input stream.
If the writer is not started before the job produces the sysout data set, the data set
is retained until the writer is started.

Held Classes in a JES2 System

A sysout data set is held if the sysout DD statement contains HOLD=YES or the
OUTPUT JCL statement specifies OUTDISP=HOLD.

Held Classes in a JES3 System

If CLASS specifies a class-name that is defined to JES3 as a held class for the
output service hold queue (Q=HOLD), all of the new output characteristics might not
be included in the data set on the writer queue when (1) the data set is moved from
the hold queue to the output service writer queue (Q=WTR), (2) the data set
includes an OUTPUT JCL statement, and (3) the NQ= or NCL= keyword is used.

For more information, see z/OS JES3 Initialization and Tuning Guide.

Significance of Output Classes

To print this sysout data set and the messages from your job on the same output
listing, code one of the following:
v The same output class in the DD SYSOUT parameter as in the JOB MSGCLASS
parameter.
v DD SYSOUT=* to default to the JOB MSGCLASS output class.
v DD SYSOUT=(,) to default to one of the following:

Chapter 12. DD Statement 12-197

DD: SYSOUT
1. The CLASS parameter in an explicitly or implicitly referenced OUTPUT JCL
statement. In this case, the OUTPUT JCL CLASS parameter should specify
the same output class as the JOB MSGCLASS parameter.
2. The JOB MSGCLASS output class, if no OUTPUT JCL statement is
referenced or if the referenced OUTPUT JCL statement contains either
CLASS= or CLASS=*.

Examples of the SYSOUT Parameter

Example 1
//DD1 DD SYSOUT=P

In this example, the DD statement specifies that JES is to write the sysout data set
to the device handling class P output.

Example 2
//DD2 DD DSNAME=&&PAYOUT1,SYSOUT=P

In this example, DD statement DD2 defines PAYOUT1 as the last qualifier of the
system-generated name for the sysout data set. The system generates a name
such as userid.jobname.jobid.Ddsnumber.PAYOUT1. The DD statement specifies
that JES is to write the data set to the device handling class P output.

Example 3
//JOB50 JOB ,’C. BROWN’,MSGCLASS=C
//STEP1 EXEC PGM=SET
//DDX DD SYSOUT=C

In this example, DD statement DDX specifies that JES is to write the sysout data
set to the device handling class C output. Because the SYSOUT parameter and the
MSGCLASS parameter specify the same class, the messages from this job and the
sysout data set can be written to the same device.

Example 4
//STEP1 EXEC PGM=ANS
//OT1 OUTPUT DEST=NYC
//OT2 OUTPUT DEST=LAX
//OT3 OUTPUT COPIES=5
//DSA DD SYSOUT=H,OUTPUT=(*.OT2,*.OT1,*.OT3)

In this example, the DD statement combines with the three referenced OUTPUT
JCL statements to create three separate sets of output:
1. DSA combines with OT1 to send the sysout data set to NYC.
2. DSA combines with OT2 to send the sysout data set to LAX.
3. DSA combines with OT3 to print five copies of the data set locally on the printer
used for output class H.

Note that the output references can be in any order.

Example 5
//DD5 DD SYSOUT=(F,,2PRT)

In this example, the DD statement specifies that JES is to write the sysout data set
to the device handling class F output. The data set is to be printed or punched on
forms named 2PRT.

12-198 z/OS V1R3.0 MVS JCL Reference

 DD: TERM

TERM Parameter
Parameter Type

Keyword, optional

Do not use the TERM parameter for an SMS-managed data set (one with an
assigned storage class).

Purpose

Use the TERM parameter to indicate to the system that a data set is coming from
or going to a terminal for a TSO/E user.

Considerations for an APPC Scheduling Environment

The TERM parameter has no function in an APPC scheduling environment. If you

code TERM, the system will check it for syntax and ignore it.

Syntax
TERM=TS

Subparameter Definition
TS
In a foreground job submitted by a TSO/E user, indicates that the input or
output data set is coming from or going to a TSO/E userid.
In a background or batch job, the system either:
v Ignores the TERM=TS parameter, when it appears with other parameters.
v Fails the TERM=TS parameter with an allocation error, when the parameter
appears by itself. (The system bypasses this error if SYSOUT=* is coded
with TERM=TS.)

Relationship to Other Parameters

Do not code the following DD parameters with the TERM parameter.

* DYNAM
AMP PROTECT
DATA QNAME
DDNAME

Code only the DCB and SYSOUT parameters with the TERM parameter. The
system ignores any other DD parameters.

Location in the JCL

To ensure that the system uses the desired OUTPUT JCL statement, code all
referenced OUTPUT JCL statements in the input stream before the DD statement
that refers to them. For example, if the referencing DD statement appears in an
in-stream or cataloged procedure, the referenced OUTPUT JCL statement should
precede the DD statement in the procedure.

Chapter 12. DD Statement 12-199

DD: TERM
In a foreground TSO/E job, a DD statement containing TERM=TS and a SYSOUT
parameter begins an in-stream data set.

When concatenating DD statements, the DD statement that contains TERM=TS

must be the last DD statement in a job step.

Examples of the TERM Parameter

Example 1
//DD1 DD TERM=TS

In a foreground job submitted from a TSO/E userid, this DD statement defines a

data set coming from or going to the TSO/E userid.

Example 2
//DD1 DD TERM=TS,SYSOUT=*

In a background or batch job, the system ignores TERM=TS and recognizes a

sysout data set. (An allocation error occurs if SYSOUT=* is not coded with
TERM=TS.)

Example 3
//DD3 DD UNIT=3400-5,DISP=(MOD,PASS),TERM=TS,LABEL=(,NL),
// DCB=(LRECL=80,BLKSIZE=80)

In a foreground job, the system ignores all of the parameters in this example except
TERM and DCB. In a batch job, the system ignores only the TERM parameter.

UCS Parameter
Parameter Type

Keyword, optional

Purpose

Use the UCS (universal character set) parameter to identify:

v The UCS image JES is to use in printing this sysout data set.
v A print train (print chain or print band) JES is to use in printing this sysout data
set on an impact printer.
v A character-arrangement table for this sysout data set printed on 3800 Printing
Subsystem in a JES2 system. In this use, the UCS parameter acts like a CHARS
parameter.

The UCS image specifies the special character set to be used. JES loads the
image into the printer’s buffer. The UCS image is stored in SYS1.IMAGELIB. IBM
provides the special character set codes in Table 12-2.

References

For more information on the UCS parameter, see z/OS DFSMSdfp Advanced
Services.

12-200 z/OS V1R3.0 MVS JCL Reference

 DD: UCS
Syntax
UCS= {character-set-code }
{(character-set-code [,FOLD] [,VERIFY]) }
[, ]

v You can omit the parentheses if you code only a character-set-code.

v All of the subparameters are positional. If you omit FOLD but code VERIFY, code a
comma to indicate the omission. For example, UCS=(AN,,VERIFY).
v Null positions in the UCS parameter are invalid.

Subparameter Definition
character-set-code
Identifies a universal character set. The character-set-code is 1 through 4
alphanumeric or national ($, #, @) characters. See Table 12-2 for IBM standard
special character set codes.
FOLD
Requests that the chain or train for the universal character set be loaded in fold
mode. Fold mode is described in 2821 Component Description. Fold mode is
most often used when upper- and lower-case data is to be printed only in
uppercase.

Note: JES2 and JES3 do not support the FOLD subparameter. For JES2, the
FOLD option is specified in the UCS image for JES2-controlled printers.
See z/OS DFSMSdfp Advanced Services.
VERIFY
Requests that, before the data set is printed, the operator verify visually that the
character set image is for the correct chain or train. The character set image is
displayed on the printer before the data set is printed.
Table 12-2. Special Character Sets for the 1403, 3203 Model 5, and 3211 Printers
3203
1403 Model 5 3211 Characteristics
AN AN A11 Arrangement A, standard EBCDIC character set, 48 characters
HN HN H11 Arrangement H, EBCDIC character set for FORTRAN and
COBOL, 48 characters
G11 ASCII character set
PCAN PCAN Preferred alphanumeric character set, arrangement A
PCHN PCHN Preferred alphanumeric character set, arrangement H
PN PN P11 PL/I alphanumeric character set
QN QN PL/I preferred alphanumeric character set for scientific
applications
QNC QNC PL/1 preferred alphanumeric character set for commercial
applications
RN RN Preferred character set for commercial applications of
FORTRAN and COBOL
SN SN Preferred character set for text printing
TN TN T11 Character set for text printing, 120 characters
XN High-speed alphanumeric character set for 1403, Model 2

Chapter 12. DD Statement 12-201

DD: UCS
Table 12-2. Special Character Sets for the 1403, 3203 Model 5, and 3211
Printers (continued)
3203
1403 Model 5 3211 Characteristics
YN High-speed preferred alphanumeric character set for 1403,
Model N1
Note: Where three values exist (for the 1403, 3211, and 3203 Model 5 printers), code any
one of them. JES selects the set corresponding to the device on which the data set is
printed. Not all of these character sets may be available at your installation. Also, an
installation can design character sets to meet special needs and assign a unique code to
them. Follow installation procedures for using character sets.

Defaults
If you do not code the UCS parameter, the system checks the UCS image in the
printer’s buffer; if it is a default image, as indicated by its first byte, JES uses it. If it
is not a default image, JES loads the UCS image that is the installation default
specified at JES initialization.

On an impact printer, if the chain or train does not contain a valid character set,
JES asks the operator to specify a character set and to mount the corresponding
chain or train.

Overrides
For printing on a printer with the UCS feature, the UCS parameter on a sysout DD
statement overrides an OUTPUT JCL UCS parameter. For printing on a 3800, a
CHARS parameter on the sysout DD statement or the OUTPUT JCL statement
overrides all UCS parameters.

For a data set scheduled to the Print Services Facility (PSF), the PSF uses the
following parameters, in override order, to select the font list:
1. Font list in the library member specified by an OUTPUT JCL PAGEDEF
parameter.
2. DD CHARS parameter.
3. OUTPUT JCL CHARS parameter.
4. DD UCS parameter.
5. OUTPUT JCL UCS parameter.
6. JES installation default for the device.
7. Font list on the PAGEDEF parameter in the PSF cataloged procedure.

See “PAGEDEF Parameter” on page 22-63 for more information.

Relationship to Other Parameters

Do not code the following DD parameters with the UCS parameter.

* DYNAM
AMP KEYOFF
DATA PROTECT
DDNAME QNAME

Do not code the UCS parameter with the DCB subparameters CYLOFL, INTVL,
RESERVE, and RKP.

12-202 z/OS V1R3.0 MVS JCL Reference

 DD: UCS
The FOLD and VERIFY subparameters are meaningful only when you specify a
printing device directly on a DD statement, for example, UNIT=00E, thus bypassing
JES sysout processing.

Using Special Character Sets

To use a special character set, SYS1.IMAGELIB must contain an image of the
character set, and the chain or train for the character set must be available. IBM
provides standard special character sets, and the installation may provide
user-designed special character sets.

Examples of the UCS Parameter

Example 1
//DD1 DD UNIT=1403,UCS=(YN,,VERIFY)

In this example, the DD statement requests a 1403 Printer. The UCS parameter
requests the chain or train for special character set code YN. Because VERIFY is
coded, the system will display the character set image on the printer before the
data set is printed.

Example 2
//DD2 DD SYSOUT=G,UCS=PN

In this example, the DD statement requests the device for output class G. If the
device is a printer with the UCS feature, the system loads the UCS image for code
PN. If the device is an impact printer, the system asks the operator to mount the
chain or train for PN, if it is not already mounted. If the device is a 3800, the system
uses the UCS subparameter to select the character-arrangement table. Otherwise,
the system ignores the UCS parameter.

UNIT Parameter
Parameter Type

Keyword, optional

Note: With SMS, you do not need to use the UNIT parameter to specify a device
for an SMS-managed data set. Use the STORCLAS parameter (described
on page 12-189) or let an installation-written automatic class selection (ACS)
routine select a storage class for the data set.

Also with SMS, for a non-SMS-managed data set, if your storage administrator has
set a system default unit under SMS, you do not need to specify UNIT. Check with
your storage administrator.

Purpose

Use the UNIT parameter to ask the system to place the data set on:
v A specific device.
v A certain type or group of devices.
v The same device as another data set.

The UNIT parameter can also tell the system how many devices to assign and
request that the system defer mounting the volume until the data set is opened.

Chapter 12. DD Statement 12-203

DD: UNIT
Syntax
{UNIT=([ddd ] [,unit-count] [,DEFER]) }
[/ddd ] [,P ]
[/dddd ] [, ]
[device-type
[group-name

{UNIT=AFF=ddname }

v You can omit the parentheses if you code only the first subparameter.
v All of the subparameters are positional. If you omit unit-count or P but code DEFER,
code a comma to indicate the omission; one device is assigned to the data set. For
example, UNIT=(3490,,DEFER).

Subparameter Definition
device-number
Identifies a specific device by a 3-digit or 4-digit hexadecimal number. Precede
a 4-digit number with a slash (/). A 3-digit number can be specified with or
without a slash.
Attention: Specify a device number only when necessary. When you specify a
device number, the system can assign only that specific device. If the device is
already being used, the job must be delayed or canceled.
However, for a permanently mounted direct access device, such as a 3390
Direct Access Storage, specifying a device type (UNIT=3390) and a volume
serial number in the VOLUME=SER parameter has the same result as
specifying a device number in the UNIT parameter.
In a JES3 system, if any DD UNIT parameter in a job specifies a
device-number for a device that is JES3-managed or jointly JES3/MVS
managed, the JES3 //*MAIN statement must contain a SYSTEM parameter.
SMS ignores a device number, if specified for SMS-managed DASD.
device-type
Requests a device by its generic name, which is an IBM-supplied name that
identifies a device by its machine type and model. For example, UNIT=3390.
When a device-type name contains a hyphen, do not enclose it in apostrophes,
for example, UNIT=3400-5.
Obtain the list of device types you can specify from your installation.
If you specify the device-type subparameter, SMS ignores it.
For a 3480 Magnetic Tape Subsystem in compatibility mode, code
UNIT=3400-9 or a group-name.
group-name
Requests a group of devices by a symbolic name. The installation must have
assigned the name to the device(s) during system initialization or IBM must
have assigned the name. The group-name is 1 through 8 alphanumeric
characters.
If you specify the group-name subparameter, SMS ignores it.

12-204 z/OS V1R3.0 MVS JCL Reference

 DD: UNIT
Group Names: A group-name can identify a single device or a group of
devices. A group can consist of devices of the same or different types. For
example, a group can contain both direct access and tape devices.

Note: A group name is called an esoteric name in Hardware Configuration

Definition (HCD) terminology.

Allocation from Groups: The system assigns a device from the group. If a
group consists of only one device, the system assigns that device. If the group
consists of more than one device type, the units requested are allocated from
the same device type. For example, if GPDA contains 3380 Disk Storage and
3390 Direct Access Storage devices, a request for two units would be allocated
to two 3380s or to two 3390s.

Extending Data Set: If a data set that was created using the group-name
subparameter is to be extended, the system allocates additional devices of the
same type as the original devices. However, the additional devices may not
necessarily be from the same group.

SYSALLDA: IBM assigned group-names include SYSALLDA, which contains all

direct access devices defined to the system.

SYS3480R and SYS348XR: SYS3480R and SYS348XR are IBM-assigned

group names. SYS3480R contains 3480, 3480X, and 3490 Magnetic Tape
Subsystems. SYS348XR contains 3480X and 3490 Magnetic Tape Subsystems.

Use these group names to override the device type eligibility retrieved by the
system when referencing existing 3480- or 3480 XF-formatted data sets.
Specifically, use SYS3480R when you want to read 3480-formatted data sets
and use SYS348XR when you want to read 3480 XF-formatted data sets.

Note: LABEL=(n,,,IN) is the system-managed tape library equivalent of either

UNIT=SYS3480R or UNIT=SYS348XR.
unit-count
Specifies the number of devices for the data set. ″Unit-count″ is a decimal
number from 1 through 59.
Number of Devices Allocated: The system uses the unit-count to determine
how many devices to allocate. For tapes, the system uses the unit-count
subparameter to allocate the specified number of system-managed or
non-system-managed units. If you also specify P (for parallel mount) in the
UNIT parameter, and for SMS-managed DASD, the system uses the highest of
the following numbers to determine how many devices and volumes to allocate:
v unit-count specified in the UNIT parameter
v volume-count specified in the VOLUME parameter
v number of volume serial numbers implicitly or explicitly specified

You may receive more devices than the unit-count requests if you specify
VOLUME=REF or a permanently resident or reserved volume. And, if two DD
statements in a step request the same volume and either DD statement
requests any other volume(s), the system assigns an additional device.

Unit Count for Received or VOLUME=REF Data Sets: The system assigns
one device when the DD statement receives a passed data set or refers in a

Chapter 12. DD Statement 12-205

DD: UNIT
VOLUME=REF subparameter to a cataloged data set or earlier DD statement
for volume and unit information. Code a unit-count subparameter if the data set
needs more than one device.

Unit Count when Device Number Specified: When the first subparameter
requests a specific device, the unit count must be 1 or omitted. Only when the
device is a communication device can the unit count be higher than 1.
P Asks the system to allocate the same number of devices as requested in the
VOLUME volume-count or SER subparameter, whichever is higher. Thus, all
volumes for the data set are mounted in parallel.
If you specify the P subparameter for system-managed DASD, the system
ignores it. If you specify the P subparameter for system-managed tape libraries,
the system honors it.
DEFER
Asks the system to assign the data set to device(s) but requests that the
volume(s) not be mounted until the data set is opened. To defer mounting,
DEFER must be specified or implied for all DD statements that reference the
volume.
If you specify the DEFER subparameter for system-managed DASD, the system
ignores it. If you specify the DEFER subparameter for system-managed tape
libraries, the system honors it.
DEFER when Data Set is Never Opened: If you request deferred mounting of
a volume and the data set on that volume is never opened by the processing
program, the volume is never mounted during the job step.
Restrictions on DEFER: Do not code DEFER:
v For a new data set on direct access. The system ignores DEFER.
v On a SYSCKEOV DD statement.
AFF=ddname
Requests that the system allocate different data sets residing on different,
removable volumes to the same device during execution of the step. This
request is called unit affinity, where ″ddname″ is the ddname of an earlier DD
statement in the same step. Use unit affinity to reduce the number of devices
used in a job step; request that an existing data set be assigned to the same
device(s) as another existing data set.
If you specify the UNIT=AFF subparameter for system-managed DASD, the
system ignores it. If you specify the UNIT=AFF subparameter for
system-managed tape libraries, the system attempts to honor it.
Under certain conditions the system ignores unit affinity. See z/OS MVS JCL
User’s Guide for more information.
In a JES3 environment, UNIT=AFF=ddname may not be honored. See z/OS
MVS JCL User’s Guide and z/OS HCD Planning for information about device
eligibility and unit affinity.

Restrictions on UNIT=AFF: Do not code UNIT=AFF=ddname:

v With DISP=NEW if the data set referenced in the AFF subparameter resides on a
direct access device. This restriction applies only to non-SMS-managed DASD. If
coded, the system terminates the job. If the referenced data set can be allocated
to either tape or DASD, the system allocates both requests to tape devices.

12-206 z/OS V1R3.0 MVS JCL Reference

 DD: UNIT
v On a DD * or DD DATA statement or on a DD statement containing a SUBSYS
parameter. The system ignores the UNIT=AFF and defaults the device to
SYSALLDA.
v When the DD statement referenced in the AFF subparameter contains
FREE=CLOSE.
v With the STORCLAS parameter.
v With an affinity specification to an earlier DD statement that requests SYS3480R
or SYS348XR on the group-name subparameter, unless volume affinity also
exists. Volume affinity exists when two DD statements both reference a data set
on the same volume. Do not also specify DISP=OLD or DISP=MOD; attempting
to write 3480 data to a 3490 drive, or 3490 data to a 3480 drive, will fail during
OPEN processing with ABEND 813-04 accompanied by message IEC149I.

Overrides
If you code SYSOUT and UNIT on the same statement, the SYSOUT parameter
overrides the UNIT parameter.

The system also obtains device information when the system obtains volume serial
information from:
v A VOLUME=REF=dsname reference to an earlier data set.
v A VOLUME=REF=ddname reference to an earlier DD statement.
v The volume(s) for a passed data set.
v The catalog for a cataloged data set.

However, you can override the retrieved device information if the device you specify
is a subset of the retrieved device information; otherwise the system ignores the
overriding device information. For example, if the retrieved unit grouping is 3350,
and the specified unit subparameter is 3350A (a subset of 3350), then the system
allocates from the devices contained in 3350A.

If you have 3490 Magnetic Tape Subsystem models A10 and A20 defined to your
system and you use one of the IBM-generated group names SYS3480R or
SYS348XR, the system overrides the device type retrieved from the catalog with a
device from the esoteric device group.

For more about how the system uses device information it retrieves from the
catalog, see the text about the relationship of the UNIT and VOLUME parameters
for non-SMS-managed data sets in z/OS MVS JCL User’s Guide.

Note: LABEL=(n,,,IN) is the system-managed tape library equivalent of either

UNIT=SYS3480R or UNIT=SYS348XR.

You can mount 3480-formatted or 3480X-formatted (18-track formatted) tape

volumes, that are not extended, on a 3490 tape device (36-track write, 18-track or
36-track read).

Relationship of the UNIT Parameter to Other Parameters

Do not code the following DD parameters with the UNIT parameter.

* DYNAM
DATA QNAME
DDNAME

Do not code the UNIT DEFER subparameter on a SYSCKEOV DD statement.

Chapter 12. DD Statement 12-207

DD: UNIT
To allocate a device, such as a printer or telecommunications device, that does not
involve a data set, do not code the DISP parameter.

See also ″Restrictions on UNIT=AFF.″

Location in the JCL

When a DD statement contains a UNIT=AFF=ddname parameter, the DD statement
referenced in the AFF subparameter must be defined earlier in the job step;
otherwise, the system treats the DD statement containing UNIT=AFF as a DD
DUMMY statement.

The following example illustrates a case where the system treats the DD statement
containing the UNIT=AFF as a DD DUMMY statement:
//STEP EXEC PGM=TKM
//DD1 DD DDNAME=DD5
//DD2 DD DSNAME=A,DISP=OLD
//DD3 DD DSNAME=C,DISP=SHR,UNIT=AFF=DD1
//DD5 DD DSNAME=B,DISP=SHR

DD3 requests unit affinity to DD1. Although DD1 occurs earlier in the job step than
DD3, it refers to DD5 that is located after DD3. Because DD1 is not completely
defined, the system treats DD3 as a dummy statement.

Examples of the UNIT Parameter

Example 1
//STEP2 EXEC PGM=POINT
//DDX DD DSNAME=EST,DISP=MOD,VOLUME=SER=(42569,42570),
// UNIT=(3480,2)
//DDY DD DSNAME=ERAS,DISP=OLD,UNIT=3480
//DDZ DD DSNAME=RECK,DISP=OLD,
// VOLUME=SER=(40653,13262),UNIT=AFF=DDX

DD statement DDX requests two 3480 tape devices, DD statement DDZ requests
the same two devices as DDX. Note that the operator will have to change volumes
on the two 3480 devices during execution of the job step.

DD statement DDY requests one 3480 tape device.

Example 2
//DD1 DD DSNAME=AAG3,DISP=(,KEEP),
// VOLUME=SER=13230,UNIT=3400-5

This DD statement defines a new data set and requests that the system assign any
3420 Magnetic Tape Unit that can operate in 6250 BPI NRZI nine-track format.

Example 3
//DD2 DD DSNAME=X.Y.Z,DISP=OLD,UNIT=(,2)

This DD statement defines a cataloged data set and requests that the system
assign two devices to the data set. The system obtains the device type from the
catalog.

Example 4
//DD3 DD DSNAME=COLLECT,DISP=OLD,
// VOLUME=SER=1095,UNIT=(3490,,DEFER)

12-208 z/OS V1R3.0 MVS JCL Reference

 DD: UNIT
This DD statement defines an existing data set that resides on a tape volume and
requests that the system assign a 3490 tape device. Because DEFER is coded, the
volume will not be mounted until the data set is opened.

Example 5
//STEPA DD DSNAME=FALL,DISP=OLD,UNIT=237

For this data set, the system retrieves the volume and device type from the catalog.
The UNIT parameter, by specifying device 237, overrides the catalog device type;
however, device 237 must be the same type as the device stated in the catalog.

Example 6

This example shows the use of the ALLOCxx UNITAFF default.

This example assumes the following environment:

v UNITAFF(3490) was specified in parmlib member ALLOC05, defining a 3490 as
the default unit-affinity-ignored unit name. This default is used when unit affinity is
ignored, the referenced DD is an SMS-managed request and the referencing DD
is a NEW non-SMS-managed request, and the system is unable to obtain a unit
from the primary DD in the unit affinity chain.
v The SMS ACS routines are defined so that:
– Data set L is to be redirected from tape to an SMS-managed DASD volume,
SD3.
– Data set M is not to be redirected and is, therefore, still intended to go to a
non-SMS managed tape volume.
//JOB2 JOB ......
//STEP1 EXEC ......
//DD11 DD DSN=L,DISP=(NEW),UNIT=3480,.....
//STEP2 EXEC ......
//DD21 DD DSN=L,DISP=OLD,......
//DD22 DD DSN=M,DISP=(NEW,CATLG),UNIT=AFF=DD21

In STEP1, DD11, data set L is created and cataloged on SD3, SMS-managed

DASD (redirected using SMS ACS routines).

In STEP2, DD21, data set L is an existing data set and is cataloged on SD3,
SMS-managed DASD. DD21 is both the referenced DD (referenced by the
UNIT=AFF on DD22) and the primary DD.

In STEP2, DD22 is the referencing DD, which requests unit affinity to DD21.
Because data set L is on SMS-managed DASD, the system cannot honor the unit
affinity for DD22 which is intended to go to tape. With the unit affinity ignored, the
system must determine a unit to be used for DD22.

The system is not able to rely on the unit information in the catalog for data set L,
because the catalog reflects a DASD unit (as a result of being redirected). Because
data set L was created in a prior step and there is no unit specified on DD21, the
system is not able to use the JCL for DD21 as a source of unit information. The
system will, therefore, use the unit-affinity-ignored unit name of 3490 for DD22.

Chapter 12. DD Statement 12-209

DD: VOLUME

VOLUME Parameter
Parameter Type

Keyword, optional

Terminology

Data sets on system-managed tape volumes exhibit both SMS and non-SMS
characteristics. When necessary, data sets on a system-managed tape volume
are distinguished from system-managed DASD data sets. Otherwise, the term
system-managed data sets refers to both data sets on a system-managed tape
volume and system-managed DASD data sets.

To cause multiple data sets to be stacked on the same volume, see z/OS MVS JCL
User’s Guide for recommendations and examples.

With SMS, consider the following:

v All volumes in a multi-volume data set should reside in the same
system-managed tape library and must belong to the same tape storage group. If
all of the volumes do not reside in the same tape library, the installation can
enter the volumes through the DFSMS installation exit, CBRUXVNL.
v You cannot make a specific volume reference to a scratch volume.
v You do not need to use the VOLUME parameter to specify volumes for new data
sets. See the DATACLAS parameter described on page 12-50 and the
STORCLAS parameter described on page 12-189.
v You cannot override the volume count for an existing system-managed DASD
data set (but you can specify a volume count when you create a new
system-managed DASD data set).
v If the storage administrator has specified a system default unit name and you do
not code a UNIT name for non-system-managed data sets, then the system uses
the volumes associated with the default unit name. In this case, you do not need
to code the VOLUME parameter. Check with your storage administrator to
determine whether a default unit name has been specified.

Purpose

Use the VOLUME parameter to identify the volume or volumes on which a data set
resides or will reside. You can request:
v A private volume
v Retention of the volume
v A specific volume by serial number
v The same volume that another data set uses

You can also specify which volume of a multivolume data set is to be processed
first and, for an output data set, the number of volumes required.

A nonspecific volume request is a DD statement for a new data set that can be
assigned to any volume or volumes. To make a nonspecific volume request for a
new data set, either:
v Omit the VOLUME parameter.
v Code a VOLUME parameter but omit a SER or REF subparameter.

12-210 z/OS V1R3.0 MVS JCL Reference

 DD: VOLUME
Syntax
{VOLUME} = ([PRIVATE] [,RETAIN] [,volume-sequence-number] [,volume-count]
{VOL } [, ] [, ]

[SER=serial-number ]
[SER=(serial-number[,serial-number]...)]
[,] [REF=dsname ]
[REF=*.ddname ]
[REF=*.stepname.ddname ]
[REF=*.stepname.procstepname.ddname ]
Single Subparameter: You can omit the parentheses if you code only PRIVATE or only a
keyword subparameter. For example, VOLUME=PRIVATE or VOLUME=SER=222001 or
VOLUME=REF=DS1.

Null REF Subparameter: The REF subparameter of the VOLUME parameter can have a
null value only when coded on a DD that either overrides a DD in a procedure or is added
to a procedure.

Null Positional Subparameters: Null positions in the VOLUME=SER parameter are invalid.

Chapter 12. DD Statement 12-211

DD: VOLUME
Positional Subparameters: The first four subparameters are positional. The last
subparameter, SER or REF, is a keyword subparameter and must follow all
positional subparameters. Code a comma to indicate an omitted positional
subparameter as follows:
v If you omit PRIVATE and code RETAIN, code a comma before RETAIN. For
example, VOLUME=(,RETAIN,2,3,SER=(222001,222002,222003)).
v Code a comma when RETAIN is omitted and the volume sequence number and
volume count subparameters follow. For example,
VOLUME=(PRIVATE,,2,3,SER=(222001,222002,222003)), and if PRIVATE is also
omitted, VOLUME=(,,2,3,SER=(222001,222002,222003)).
v Code a comma when the volume sequence number is omitted and the volume
count subparameter follows. For example,
VOLUME=(,RETAIN,,3,SER=(222001,222002,222003)), and
VOLUME=(PRIVATE,,,3,SER=(222001,222002,222003)), and
VOLUME=(,,,3,SER=(222001,222002,222003)).
v Code a comma when the volume count is omitted, at least one other
subparameter precedes it, and a keyword subparameter follows. For example,
VOLUME=(,RETAIN,2,,SER=(222001,222002,222003)), and
VOLUME=(,,2,,SER=(222001,222002,222003)), and
VOLUME=(,RETAIN,REF=*.stepname.ddname)

Single SER Subparameter: You can omit the parentheses in the SER
subparameter if you code only one serial number. For example,
VOLUME=SER=222001.

Special Characters: When a serial number in the SER subparameter contains

special characters, other than hyphens, enclose it in apostrophes. For example,
VOLUME=SER=(222001,222-02,'222/03').

When the dsname in the REF subparameter contains special characters, other than
the periods used in a qualified name, enclose it in apostrophes. For example,
VOLUME=REF='DS/284'.

Code each apostrophe that is part of the serial number or data set name as two
consecutive apostrophes. For example, VOLUME=SER='O''HARE' or
VOLUME=REF='DS''371'.

Subparameter Definition
PRIVATE
Requests a private volume. Private means that:
v The system is not to allocate an output data set to the volume unless the
volume is specifically requested, such as in a VOLUME=SER subparameter.
v If tape, the volume is to be demounted after the data set is closed, unless
RETAIN is also coded or the DD DISP parameter specifies PASS.
v If a demountable direct access volume, the volume is to be demounted after
the data set is closed.
RETAIN
For a private tape volume, RETAIN requests that this volume is not to be
demounted or rewound after the data set is closed or at the end of the step. For
a public tape volume, RETAIN requests that this volume is to be retained at the
device if it is demounted during the job.

12-212 z/OS V1R3.0 MVS JCL Reference

 DD: VOLUME
RETAIN Support: RETAIN is supported only for tape volumes managed by the
basic control program and by JES2. If coded on a DD statement for a tape data
set on a JES3-managed device, JES3 ignores the parameter when issuing
KEEP/RETAIN messages and when performing unallocation at the end of the
job. However, if RETAIN is coded for a tape data set on a JES3-managed
device and the tape volume is to be shared with a later step, JES3 designates
the volume as retained.
RETAIN has no effect on the handling of direct access volumes.
Demounting Despite RETAIN: Coding RETAIN does not ensure that the
operator will not unload the volume or that the system will not demount it for
another job step allocation. Either can occur when the device on which the
volume is mounted is not allocated to the job step that specified RETAIN or, for
unlabeled tapes, when the volume requires verification. If the system does
demount a volume for which RETAIN was requested, it will do so by issuing
message IEF234E R (retain) for that volume. When the system reaches the
next step requiring that volume, it will request the operator to remount the
volume on an available device of the appropriate type.
volume-sequence-number
Identifies the volume of an existing multivolume data set to be used to begin
processing the data set. The volume sequence number is a decimal number
from 1 through 255; the first volume is identified as 1. The volume sequence
number must be less than or equal to the number of volumes on which the data
set exists; otherwise, the job fails.
If the volume sequence number is not specified the system will process the first
volume.
For new data sets, the system ignores the volume sequence number.
volume-count
Specifies the maximum number of volumes that an output data set requires.
The volume count is a decimal number from 1 through 255 for a tape data set
and from 1 through 59 for a DASD data set. The total volume count for all DD
statements in one job step cannot exceed 4095.

Note: The system uses the unit count to determine how many devices to
allocate. However, if you also specify P (for parallel mount) in the UNIT
parameter, the system might use the value specified for the volume
count to determine how many devices and volumes to allocate. See the
unit-count subparameter description on page 12-205 for further
information.

Volume Count for Tape Data Sets: Code a volume count when a new data set
will reside on 6 or more volumes. If you omit the volume count or if you specify
1 through 5, the system allows up to five volumes; if you specify 6 through 20,
the system allows 20 volumes; if you specify a count greater than 20, the
system allows 5 plus a multiple of 15 volumes.

Volume Count and Serial Numbers: When the volume count is greater than:
v The number of volume serials coded in the SER subparameter
v The number of volume serials the system retrieved from the catalog
v The number of volume serials the system retrieved from VOL=REF
v The number of volume serials the system retrieved from a passed data set,

Chapter 12. DD Statement 12-213

DD: VOLUME
the system assigns other volumes to the remaining devices. If the volume count
is smaller than the number of volume serials, the system ignores the volume
count.

If a data set may need more volumes than the number of volume serials coded,
specify a volume count equal to the total number of volumes that might be
used. Requesting more volumes in the volume count will make sure that the
data set can be written on more volumes if it exceeds the requested volumes.

If you do not code a volume count and volume serial number, the system can
extend an existing cataloged data set that resides on a removable volume up to
20 volumes.

Volume Count for Nonspecific Requests: If the request is for a nonspecific,

public volume on a direct access device, the system ignores the volume count
and allocates the number of volumes in the UNIT unit count subparameter.

If the request is for a nonspecific, private volume, the system treats it like a
specific request if the volume count is more than one and allocates the number
of volumes in the volume count.

Volume Count for System-Managed DASD Data Sets: You cannot specify a
volume count for an existing system-managed DASD data set. (If you do, the
system will ignore it.) When you create a new system-managed DASD data set,
however, you can override the volume count defined in the data class by using
the volume-count subparameter.

Volume Count for System-Managed Tape Data Sets: If you specify a volume
count and DISP=PASS on a DD statement, the system will pass the volume
count to subsequent receiving steps within the job. This may cause the system
to allocate more devices than expected to the receiving DD. Coding UNIT=AFF
in the receiving step’s DD will result in the optimum number of devices being
allocated to the receiving DD. For more information about the number of
devices allocated, refer to the z/OS MVS JCL User’s Guide.
SER=serial-number
SER=(serial-number[,serial-number]...)
Identifies by serial number the volume(s) on which the data set resides or will
reside. A volume serial number is 1 through 6 alphanumeric, national ($, #, @),
or special characters; enclose a serial number that contains special characters,
other than hyphens, in apostrophes. If the number is shorter than 6 characters,
it is padded with trailing blanks.
You can code a maximum of 255 volume serial numbers on a DD statement.
Do not specify duplicate volume serial numbers in a SER subparameter. Each
volume must have a unique volume serial number, regardless of whether it is a
tape or disk volume.
Do not code a volume serial number as SCRTCH, PRIVAT, or Lnnnnn (L with
five numbers); these are used in messages to ask the operator to mount a
volume. Do not code a volume serial number as MIGRAT, which is used by the
Hierarchical Storage Manager DFSMShsm for migrated data sets. When using
some typewriter heads or printer chains, a volume serial number may be
unrecognizable if you code certain special characters.

12-214 z/OS V1R3.0 MVS JCL Reference

 DD: VOLUME
For a permanently mounted direct access device, such as a 3390 Direct Access
Storage, specifying a volume serial number and UNIT=3390 has the same
result as specifying a device number in the UNIT parameter.
For new SMS-managed data sets:
For an SMS-managed data set, code the SER subparameter only if the storage
administrator has specified GUARANTEED_SPACE=YES in the storage class
of the data set. In this case, SMS uses the volumes you explicitly specify. If it is
unable to do so, the allocation fails. The volume serial numbers must be
assigned to the same storage group. If GUARANTEED_SPACE=YES is not in
effect, SMS ignores any volume serial numbers you specify for new
SMS-managed data sets.
For existing data sets:
v If you do not specify a volume serial number and you specify an
SMS-managed or cataloged data set: the system will allocate the data set
to the volume on which it resides.
v If you specify a non-SMS managed volume serial number: the system will
allocate the data set on the volume specified, regardless of whether there is
a cataloged or SMS-managed data set of the same name elsewhere. If there
is no data set with the specified name on the volume specified, the request
will fail.
v If you specify an SMS-managed volume serial number: the system will
find and allocate the data set to the volume on which it resides, even if that
is different from the volume specified. If there is no SMS-managed data set
with the specified name, the request will fail.

When two data sets, one that is SMS-managed and one that is not, share the
same data set name:
v If you specify the non-SMS-managed volume, the system will allocate the
non-SMS-managed data set.
v If you do not specify the volume information, or you specify an SMS-
managed volume, the system will allocate the SMS-managed data set.
REF=dsname
REF=*.ddname
REF=*.stepname.ddname
REF=*.stepname.procstepname.ddname
Tells the system to obtain volume serial numbers from another data set or an
earlier DD statement.

Note: VOL=REF obtains ONLY the volume serial numbers from the referenced
data set or earlier DD statement. In particular it does not obtain the
volume sequence number, volume count, label type, or data set
sequence number.
dsname
Names a cataloged or passed data set. The system assigns this data set to
the same volumes containing the cataloged or passed data set.
When dsname names a passed data set, the reference must appear on a
DD statement before the receiving DD statement. (After a passed data set
is received, the passed data set information is no longer available.)
The dsname can be an alias name or a catalog name. The dsname cannot
be a generation data group (GDG) base name, a GDG relative generation
member, or a member name of a non-GDG data set.

Chapter 12. DD Statement 12-215

 DD: VOLUME
When the dsname contains special characters, other than the periods used
in a qualified name, enclose it in apostrophes.
*.ddname
Asks the system to obtain the volume serial numbers from earlier DD
statement ddname in the same job step.
*.stepname.ddname
Asks the system to obtain the volume serial numbers from DD statement,
ddname, in an earlier step, stepname, in the same job.
*.stepname.procstepname.ddname
Asks the system to obtain the volume serial numbers from a DD statement
in a cataloged or in-stream procedure. Stepname is the name of the job
step that calls the procedure, procstepname is the name of the procedure
step that contains the DD statement, and ddname is the name of the DD
statement.

Referenced Data Set Not Opened: When REF refers to a DD statement in a

previous step and the data set was not opened, the system allocates a device
that has the widest range of eligibility to meet both DD statement requests.
Thus, the system might allocate a device for which the referring data set is not
eligible. To prevent this problem for tape data sets, always code the DCB DEN
subparameter or the DCB TRTCH subparameter on a DD statement that you
plan to reference.

| References to Multivolume Tape Data Sets: When REF refers to a data set
| residing on more than one tape volume, the system allocates all volumes to the
| referencing DD when it represents an OLD data set, that is, a data set that
| existed prior to the current job step. For a NEW tape data set the system
| allocates only the last volume of a referenced multivolume tape data set.

| If an earlier job step extends the referenced data set to more volumes, or adds
| or extends an earlier data set so that the referenced data set resides on a later
| volume, the new volume information is available to the referencing DD
| statement.

| If the current job step extends the referenced data set to more volumes, or
| adds or extends an earlier data set so that the referenced data set resides on a
| later volume, the new volume information is available to the referencing DD
| statement ONLY when the referenced data set is a new data set with no
| volume serial numbers explicitly or implicitly specified, which means only if the
| entire collection of data sets on the volumes was created in the current step. In
| other words, if the current job step extends the referenced data set to more
| volumes, or adds or extends an earlier data set so that the referenced data set
| resides on a later volume, the new volume information is not available to the
| referencing DD statement when either of the following conditions is true:
| v The data set that is referenced (directly or through a chain of references)
| existed before the start of the step containing the reference.
| v The data set that is referenced (directly or through a chain of references) is a
| new data set requested with specific volume serial numbers.

| If the referenced data set already exists and has volume serial numbers
| explicitly specified, then the last listed volume serial is used even if the earlier
| data set actually exists on or is written to fewer volumes.

12-216 z/OS V1R3.0 MVS JCL Reference

 DD: VOLUME
| If the referenced data set is new and has specific volume serials, then the last
| listed volume serial is used even if the data set is written with fewer volumes.

| In either of these cases, the allocation of the referencing data set is likely to fail.

References to Multivolume Direct Access Data Sets: When REF refers to a

data set that resides on more than one direct access volume, the system
allocates all of the volumes.

If a DD statement that is requesting a new data set has a unit count and
volume count greater than one but specifies no volume serial numbers, one
volume is allocated. If a second DD statement within the same step requests
the same data set, the same volume is allocated to it. If this job step extends
the data set to more volumes, this new volume information is not available to
the second DD statement.

Two or more DD statements in the same step can request the same data set.
However, if the data set is extended to additional volumes in that step, the
additional volume information is not available to the second or succeeding DD
statements within the step.

References to DD Statements with UNIT Group Names: When REF refers to

a DD statement containing a UNIT group-name subparameter, the system
allocates a device of the same type actually used for the referenced data set,
but not necessarily a device in the referenced group-name.

References to VSAM Data Sets: When REF refers to a multivolume VSAM

data set, the system allocates a device of the same type as the first device type
used for the referenced VSAM data set.

References to SMS-Managed Data Sets: When REF refers to an

SMS-managed data set, SMS manages the new data set using the storage
class of the referenced data set, if it is available, and applies these rules:
v If the reference is to a data set on one or more SMS-managed tape volumes,
then the two data sets must be assigned to the same storage group. If the
automatic class selection (ACS) routine does not assign the same storage
group to the referenced and referencing data sets, the allocation fails with
message IGD304I.
v For references to data sets on SMS-managed media other than tape, the two
data sets must be assigned to compatible types of storage groups. This
ensures the consistency for locate requests. For example, if the referenced
data set is on DASD, allocating the referencing data set to be allocated on
tape could result in potential locate request errors. If the ACS routine does
not assign compatible types of storage groups to both data sets, the
allocation fails with message IGD318I.

References to Non-SMS-Managed Data Sets: When REF refers to a

non-SMS-managed data set, the ACS routine receives control and can do one
of two things:
v Allow the allocation to proceed as a non-SMS-managed data set.
v Fail the allocation by exiting with a non-zero return code.

If the ACS routine attempts to make the referencing data set SMS-managed,
SMS fails the allocation with message IGD305I.

Chapter 12. DD Statement 12-217

DD: VOLUME
Do Not Refer to In-Stream Data Sets: Do not refer to a DD *, DD DATA, or
DD SYSOUT statement. The system ignores the reference and defaults the
device name to SYSALLDA, which is the group name for all direct access
devices defined to the system.

References to DUMMY Data Sets: If ddname refers to a DD DUMMY

statement, the data set for this DD statement is also assigned a dummy status.

Label Type Picked up from Referenced Statement: When REF is coded, the
system also copies the LABEL label type subparameter from the referenced DD
statement.

Overrides
The volume sequence number overrides a DISP=MOD parameter. Thus, instead of
starting at the end of the data set on the last volume, according to the MOD
subparameter, processing of the data set begins with the volume indicated by the
volume sequence number.

Relationship to Other Parameters

Do not code the following parameters with the VOLUME parameter.

BURST DDNAME MODIFY

CHARS DYNAM QNAME
COPIES FLASH SYSOUT

Do not code VOLUME=REF with the STORCLAS parameter.

Other DD Parameter Picked up from Referenced Statement

When REF is coded, the system also copies the LABEL label type subparameter
from the referenced DD statement.

For 3540 Diskette Input/Output Units

The VOLUME=SER, DCB=BUFNO, and DSID parameters on a DD * or DD DATA

statement are ignored except when they are detected by a diskette reader as a
request for an associated data set. See the 3540 Programmer’s Reference.

VOLUME Parameter in a JES3 System

When you do not code a volume serial number, code PRIVATE if you want JES3 to
manage the allocation. Otherwise, MVS manages the allocation.

RETAIN is ignored in a JES3 system.

VOLUME Parameter for Optical Readers

For optical readers, if no volume serial number is specified, the system assumes
VOLUME=SER=OCRINP.

VOLUME Parameter for Nonspecific Volume Requests

A nonspecific volume request can appear on a DD statement for a new data set;
the data set is assigned to any volume or volumes. The nonspecific request is
made through a VOLUME parameter that does not contain a SER or REF
subparameter. The parameter can contain the following subparameters:

12-218 z/OS V1R3.0 MVS JCL Reference

 DD: VOLUME
VOLUME=(PRIVATE,RETAIN,,volume-count)

Note: The use of PRIVATE on nonspecific requests eligible to permanently resident

DASD devices is not recommended. Operator intervention is required to
allow the system to allocate such a request to a private volume.

VOLUME parameter for Specific Multi-Volume Tape Requests

When allocating a specific, multi-volume tape data set, if the data set resides on
multiple tape volumes that are:
v System-managed, then all volumes should reside in the same system-managed
tape library and the same tape storage group. (If all of the volumes do not reside
in the same tape library, the installation can enter the volumes through the
DFSMS installation exit, CBRUXVNL.) These volumes must also be part of the
same SMS storage group.
v Non-system-managed, then all volumes must be outside of any system-managed
tape library.

Examples of the VOLUME Parameter

Example 1
//DD1 DD DSNAME=DATA3,UNIT=SYSDA,DISP=OLD,
// VOLUME=(PRIVATE,SER=548863)

The DD statement requests an existing data set, which resides on the direct access
volume, serial number 548863. Since PRIVATE is coded, the system will not assign
to the volume another data set for which a nonspecific volume request is made and
will demount the volume at the end of the job.

Example 2
//DD2 DD DSNAME=QUET,DISP=(MOD,KEEP),UNIT=(3400-5,2),
// VOLUME=(,,,4,SER=(96341,96342))

The DD statement requests an existing data set, which resides on two volumes,
serial numbers 96341 and 96342. The VOLUME volume count subparameter
requests four volumes, if required. Thus, if more space is required, the system can
assign a third and fourth volume.

Example 3
//DD3 DD DSNAME=QOUT,UNIT=3400-5

The DD statement defines a data set that is created and deleted in the job step. By
omission of the VOLUME parameter, the statement makes a nonspecific volume
request, thereby asking the system to assign a suitable volume to the data set.

Example 4
//DD4 DD DSNAME=NEWDASD,DISP=(,CATLG,DELETE),UNIT=3350,
// VOLUME=SER=335006,SPACE=(CYL,(10,5))

This new data set is assigned to volume serial number 335006, which is a
permanently mounted volume on a particular 3350 Direct Access Storage. You can
obtain the same space on the same volume in another way: instead of specifying
the volume serial number and UNIT=3350, you can specify the device number of
the particular 3350 device in the UNIT parameter.

Example 5

Chapter 12. DD Statement 12-219

DD: VOLUME
//OUTDD DD DSNAME=TEST.TWO,DISP=(NEW,CATLG),
// VOLUME=(,,,3,SER=(333001,333002,333003)),
// SPACE=(TRK,(9,10)),UNIT=(3330,P)
//NEXT DD DSNAME=TEST.TWO,DISP=(OLD,DELETE)

DD statement OUTDD creates a multivolume data set and catalogs it. If the data
set does not require three volumes, it will reside on fewer volumes. DD statement
NEXT then deletes the data set.

If the data set resides on fewer volumes than the number of volumes on which it is
cataloged, the following messages appear in the job log when the system deletes
the data set:
IEF285I TEST.TWO DELETED
IEF285I VOL SER NOS=333001,333003.
IEF283I TEST.TWO NOT DELETED
IEF283I VOL SER NOS=333002 1.
IEF283I TEST.TWO UNCATALOGED
IEF283I VOL SER NOS=333001,333002,333003.

If the data set resides on all specified volumes, the following messages appear in
the job log when the system deletes the data set:
IEF285I TEST.TWO DELETED
IEF285I VOL SER NOS=333001,333002,333003.

Example 6
//SMSDS2 DD DSNAME=MYDS2.PGM,STORCLAS=SCLAS02,DISP=(NEW,KEEP),
// VOLUME=SER=(223344,224444)

For new system-managed DASD data sets or data sets on a system-managed tape
volume, the system uses the attributes in the storage class named SCLAS02 for the
storage service level of the data set. Also, if the storage administrator has specified
GUARANTEED_SPACE=YES in the storage class for DASD VOLUME=SER can be
coded and the data set will reside on the specified volumes. (However, if space is
not available on the volumes, the job step fails. Allocation also fails if the requested
volumes aren’t in any of the possible storage groups for the data set. For tape
requests, the system always gets the tape request specified with a specific volume
serial.) Installation-written automatic class selection (ACS) routines select the data
class and management class.

Example 7
//STEP1 EXEC PGM=....
//DD1 DD DSN=OLD.SMS.DATASET,DISP=SHR
//DD2 DD DSN=FIRST,DISP=(NEW,CATLG,DELETE),VOL=REF=*.DD1

//STEP2 EXEC PGM=...

//DD3 DD DSN=SECOND,DISP=(NEW,CATLG,DELETE),VOL=REF=*.STEP1.DD1

DD1 in STEP1 identifies the original SMS-managed data set OLD.SMS.DATASET.

DD2 in STEP1 and DD3 in STEP2 each create an SMS-managed data set using
the attributes in the storage class associated with the original data set
OLD.SMS.DATASET in DD1.

12-220 z/OS V1R3.0 MVS JCL Reference

Chapter 13. Special DD Statements
Use special DD statements to specify private catalogs, private libraries, and data
sets for storage dumps and checkpoints. This chapter provides descriptions of
these special statements.

Description

Syntax
//ddname DD keyword-parameter[,keyword-parameter]... [comments]

Special ddnames
The special data sets are identified by the following ddnames:

JOBCAT
JOBLIB
STEPCAT
STEPLIB
SYSABEND
SYSCHK
SYSCKEOV
SYSIN
SYSMDUMP
SYSUDUMP

Except for SYSIN, code these ddnames only when you want the special data sets.

JOBCAT DD Statement
Purpose

Use the JOBCAT DD statement to define a private VSAM or integrated catalog

facility user catalog for the duration of a job. The system searches the private
catalog for data sets before it searches the master catalog or a private catalog
associated with the first qualifier of a data set’s name.

Do not use the JOBCAT DD statement in a job that references an SMS-managed

data set. SMS only accesses SMS-managed data sets that are cataloged in a
system catalog.

The system does not support the JOBCAT DD statement (or STEPCAT DD
statement) for catalogs that have a unit control block (UCB) above the 16MB line.

You cannot specify CVOLs as JOBCAT. Access to a CVOL is possible only with a
special CVOL pointer in the master catalog.

References

For more information about VSAM data sets, see z/OS DFSMS: Using Data Sets.

© Copyright IBM Corp. 1988, 2002 13-1

 JOBCAT DD
Syntax
//JOBCAT DD DISP={OLD},DSNAME=private-catalog-name[,parameter]... [comments]
{SHR}

Parameters on JOBCAT DD Statements

Do not specify any unit or volume information. The system obtains the location of
the private catalog from the master catalog. Do not specify FREE=CLOSE; CLOSE
is ignored.

Relationship to STEPCAT DD Statement

A JOBCAT DD statement applies to any job step for which you do not specify a
STEPCAT DD statement.

Relationship to Other Control Statements

Concatenating Job Catalogs

To specify more than one private catalog for a job:

v Code a JOBCAT DD statement.
v Immediately follow this statement with DD statements that define other private
catalogs. Omit a ddname from these subsequent DD statements.

| See also “Relationship between JOBLIB and Passed Data Sets” on page 13-5 for
| information about the relationship of the JOBCAT statement to the JOBLIB
| statement.

Location in the JCL

v Place the JOBCAT DD statement after the JOB statement and before the first
EXEC statement.
v Place a JOBLIB DD statement, if coded, before a JOBCAT DD statement.

Example of the JOBCAT DD Statement

//EXAMPLE JOB WILLIAMS,MSGLEVEL=1
//JOBLIB DD DSNAME=USER.LIB,DISP=SHR
//JOBCAT DD DSNAME=LYLE,DISP=SHR
// EXEC PGM=SCAN

In this example, the JOBCAT DD statement specifies a private catalog. The

JOBCAT DD statement follows the JOBLIB DD statement.

JOBLIB DD Statement
Purpose

Use the JOBLIB DD statement to:

v Create a private library.
v Identify a private library that the system is to search for the program named in
each EXEC statement PGM parameter in the job. Only if the system does not
find the program in the private library, does it search the system libraries.

13-2 z/OS V1R3.0 MVS JCL Reference

 JOBLIB DD
A private library is a partitioned data set or partitioned data set extended on a direct
access device. Each member is an executable, user-written program.

Syntax
//JOBLIB DD parameter[,parameter]... [comments]

Parameters on JOBLIB DD Statements

When Retrieving a Cataloged Library
v Code the DSNAME parameter.
v Code the DISP parameter. The status subparameter must be OLD or SHR. The
disposition subparameters should indicate what you want done with the private
library after its use in the job.
v Do not code VOLUME or UNIT.

When Retrieving a Library that is not Cataloged

v Code the DSNAME parameter.
v Code the DISP parameter. The DISP parameter must be DISP=(OLD,PASS) or
DISP=(SHR,PASS). SHR indicates that the data set is old, but allows other jobs
to use the library.
v Code the UNIT parameter.
v Code the VOLUME parameter.

When Creating a Library

v Code the DSNAME parameter to assign the library a name.
v Code the UNIT parameter. The library must be allocated to a direct access
device.
v Code a VOLUME parameter, unless a nonspecific request is to be made for any
volume.
v Code the SPACE parameter, allowing enough space for the entire library on one
direct access volume. Specify space for the PDS directory.
v Code a DISP parameter. The status is NEW. Code CATLG as the disposition, if
you intend to keep the library you are creating. Code PASS as the disposition, if
you wish the library to be available throughout the job, but deleted at job
termination. Note that you must code a disposition; otherwise, the system
assumes DELETE and deletes the library at the end of the first step.

Note: Do not use VSAM for a JOBLIB library.

When Adding Members to the Library

v In the DSNAME parameter, follow the library name with the name of the program
being added to the library. For example, DSNAME=LIBRARY(PROGRAM).
v Code the status in the DISP parameter as MOD. If you cataloged the library
when you created it, do not code a disposition. Otherwise, code PASS or CATLG.
v If the JOBLIB library is being created in the job, the JOBLIB DD DISP specified
CATLG, and the first step adds a member to it, supply unit and volume
information in the first step by coding: VOLUME=REF=*.JOBLIB. This parameter
is needed because the library is not actually cataloged until the first step
completes execution. Otherwise, unit and volume information should not be
supplied for a cataloged library.

Chapter 13. Special DD Statements 13-3

JOBLIB DD
v Do not code a SPACE parameter. The JOBLIB DD statement requests space for
the entire library.

Other Parameters

Code the DCB parameter if complete data control block information is not contained
in the data set label. Do not specify FREE=CLOSE; CLOSE is ignored.

Relationship to Other Control Statements

Concatenating Job Libraries

To specify more than one private library for a job:

v Code a JOBLIB DD statement.
v Immediately follow this statement with DD statements that define other private
libraries. Omit a ddname from these subsequent DD statements.

The system searches the libraries for the program in the same order as the DD
statements.

Overriding a JOBLIB

If you want the system to ignore the JOBLIB for a particular job step and the step
does not require another private library, define the system library on a STEPLIB DD
statement. For example, specify:
//STEPLIB DD DSNAME=SYS1.LINKLIB,DISP=SHR

For this particular job step, the system will search SYS1.LINKLIB, as specified on
the STEPLIB DD statement, for the program requested in the EXEC statement. The
system will not search the JOBLIB.

EXEC Statement COND Parameter

If COND=ONLY is specified on the EXEC statement of a job step and a JOBLIB DD

statement is being used, the system does not pass the unit and volume information
to any succeeding steps, and the system must search the catalog for the JOBLIB
data set’s unit and volume information.

Location in the JCL

v The JOBLIB DD statement must immediately follow the JOB statement and any
JES statements. There must be no intervening EXEC or other DD statements
between the JOBLIB DD statement and the JOB statement.
v If libraries are concatenated to the JOBLIB library, the concatenated DD
statements must immediately follow the JOBLIB DD statement.
v Do not include a JOBLIB DD statement in an in-stream or cataloged procedure.

Relationship of a JOBLIB to a STEPLIB

Use a STEPLIB DD statement to define a private library for one job step in a job. If
you include a STEPLIB DD statement for a job step and a JOBLIB DD statement
for the entire job, the system first searches the step library and then the system
library for the requested program. The system ignores the job library for a step that
has a STEPLIB DD statement.

13-4 z/OS V1R3.0 MVS JCL Reference

 JOBLIB DD
| Relationship between JOBLIB and Passed Data Sets
| When you request an existing data set by its data set name and you do not supply
| a volume serial number, the system first checks in the Passed Data set Information
| table (PDI) to see if that data set was passed from a previous step. If so it will use
| the information from the PDI to locate the data set without looking in any catalogs.
| If the data set was not passed from a previous step, then the system will attempt to
| locate the data set name in a catalog.

| A non-obvious case exists, however, when you code a STEPCAT DD statement

| along with a JOBLIB DD statement.

| For this example, assume that there are three different versions of data set
| “user_dataset”:
| v one version on volserJ, cataloged in UCAT.JOBCAT
| v one version on volserX, cataloged in UCAT.STEPCATX
| v one version on volserY, cataloged in UCAT.STEPCATY

| and three different versions of data set “user_library”:

| v one version on volserJ, cataloged in UCAT.JOBCAT
| v one version on volserX, cataloged in UCAT.STEPCATX
| v one version on volserY, cataloged in UCAT.STEPCATY

| Assume also that each version of “user_library” contains a version of programs:

| v userpgm1
| v userpgm2
| v userpgm3

| Pictorially, this would look like this:

| UCAT.JOBCAT
| -----------
| user_library(J) --->volserJ
| userpgm1(J)
| userpgm2(J)
| userpgm3(J)
| user_dataset(J) --->volserJ
|
| UCAT.STEPCATX
| -------------
| user_library(X) --->volserX
| userpgm1(X)
| userpgm2(X)
| userpgm3(X)
| user_dataset(X) --->volserX
|
| UCAT.STEPCATY
| -------------
| user_library(Y) ---volserY
| userpgm1(Y)
| userpgm2(Y)
| userpgm3(Y)
| user_dataset(Y) --->volserY

| Finally, assume the following JCL is coded:

| //JOBLIB DD DSN=user_library,DISP=SHR
| //JOBCAT DD DSN=UCAT.JOBCAT,DISP=SHR
| //*
| //STEP1 EXEC PGM=userpgm1

Chapter 13. Special DD Statements 13-5

 JOBLIB DD
| //STEPCAT DD DSN=UCAT.STEPCATX,DISP=SHR
| //DD1 DD DSN=user_dataset,DISP=(SHR,PASS)
| //*
| //STEP2 EXEC PGM=userpgm2
| //STEPCAT DD DSN=UCAT.STEPCATY,DISP=SHR
| //DD2 DD DSN=user_dataset,DISP=(SHR,PASS)
| //*
| //STEP3 EXEC PGM=userpgm3
| //DD3 DD DSN=user_dataset,DISP=SHR
| //*

| Because there is an implied PASS on all JOBLIB DD statements, the system

| allocates the JOBLIB data set for the first step of the job and then PASSes that
| information to all subsequent steps of the job. Thus, even if the JOBLIB data set
| name is in the STEPCAT catalog, the system will never look there for it because it
| will first find the information in the PDI.

| Using the above JCL and cataloging and placement of data sets, here is what a
| user might expect to happen, versus what actually does happen:

| STEP1
| userpgm1
| EXPECTED: userpgm1(X) from user_library(X) on volserX
| ACTUAL: userpgm1(X) from user_library(X) on volserX
| user_dataset
| EXPECTED: user_dataset(X) on volserX
| ACTUAL: user_dataset(X) on volserX

| STEP2
| userpgm2
| EXPECTED: userpgm2(Y) from user_library(Y) on volserY
| ACTUAL: userpgm2(X) from user_library(X) on volserX
| user_dataset
| EXPECTED: user_datasetY on volserY
| ACTUAL: user_datasetX on volserX
| v If PASS had not been coded on STEP1’s DD1, the user_dataset selected
| WOULD have been user_datasetY from volserY, but userpgm2 would STILL have
| been userpgm2(X) from user_library(X) on volserX due to the implied PASS on
| JOBLIB.

| STEP3
| userpgm3
| EXPECTED: userpgm3(J) from user_library(J) on volserJ
| ACTUAL: userpgm3(X) from user_library(X) on volserX
| user_dataset
| EXPECTED: user_dataset(J) on volserJ
| ACTUAL: user_dataset(X) on volserX
| v If PASS had not been coded on STEP2’s DD2, the user_dataset selected
| WOULD have been user_dataset(J) from volserJ, but userpgm3 would STILL
| have been userpgm3(X) from user_library(X) on volserX due to the implied PASS
| on JOBLIB.

Examples of the JOBLIB DD Statement

Example 1
//PAYROLL JOB JONES,CLASS=C
//JOBLIB DD DSNAME=PRIVATE.LIB4,DISP=(OLD,PASS)
//STEP1 EXEC PGM=SCAN
//STEP2 EXEC PGM=UPDATE
//DD1 DD DSNAME=*.JOBLIB,DISP=(OLD,PASS)

13-6 z/OS V1R3.0 MVS JCL Reference

 JOBLIB DD
The private library requested on the JOBLIB DD statement is cataloged. The
system passes catalog information to subsequent job steps. The system searches
for the programs SCAN and UPDATE first in PRIVATE.LIB4, then in SYS1.LINKLIB.
DD statement DD1 refers to the private library requested in the JOBLIB DD
statement.

Example 2
//PAYROLL JOB FOWLER,CLASS=L
//JOBLIB DD DSNAME=PRIV.DEPT58,DISP=(OLD,PASS),
// UNIT=3350,VOLUME=SER=D58PVL
//STEP EXEC PGM=DAY
//STEP2 EXEC PGM=BENEFITS
//DD1 DD DSNAME=*.JOBLIB,VOLUME=REF=*.JOBLIB,DISP=(OLD,PASS)

The private library requested on the JOBLIB DD statement is not cataloged;

therefore, unit and volume information is specified. The system searches for the
programs DAY and BENEFITS first in PRIV.DEPT58, then in SYS1.LINKLIB. DD
statement DD1 refers to the private library requested in the JOBLIB DD statement.

Example 3
//TYPE JOB MSGLEVEL=(1,1)
//JOBLIB DD DSNAME=GROUP8.LEVEL5,DISP=(NEW,CATLG),
// UNIT=3350,VOLUME=SER=148562,SPACE=(CYL,(50,3,4))
//STEP1 EXEC PGM=DISC
//DDA DD DSNAME=GROUP8.LEVEL5(RATE),DISP=MOD,
// VOLUME=REF=*.JOBLIB
//STEP2 EXEC PGM=RATE

The private library requested on the JOBLIB DD statement does not exist yet;
therefore, the JOBLIB DD statement contains all the parameters required to define
the library. The library is created in STEP1, when DD statement DDA defines the
new member RATE for the library. Therefore, the system searches SYS1.LINKLIB
for the program named DISC. In STEP2, the system searches for the program
RATE first in GROUP8.LEVEL5.

Example 4
//PAYROLL JOB BIRDSALL,TIME=1440
//JOBLIB DD DSNAME=KRG.LIB12,DISP=(OLD,PASS)
// DD DSNAME=GROUP31.TEST,DISP=(OLD,PASS)
// DD DSNAME=PGMSLIB,UNIT=3350,
// DISP=(OLD,PASS),VOLUME=SER=34568

The three DD statements concatenate the three private libraries. The system
searches the libraries for each program in this order:
KRG.LIB12
GROUP31.TEST
PGMSLIB
SYS1.LINKLIB

STEPCAT DD Statement
Purpose

Use the STEPCAT DD statement to define a private VSAM or integrated catalog

facility user catalog for the duration of a job step. The system searches the private
catalog for data sets before it searches the master catalog or a private catalog
associated with the first qualifier of a data set’s name.

Chapter 13. Special DD Statements 13-7

 STEPCAT DD
Do not use the STEPCAT DD statement in a job step that references an
SMS-managed data set. SMS only accesses SMS-managed data sets that are
cataloged in a system catalog.

The system does not support the STEPCAT DD statement (or JOBCAT DD
statement) for catalogs that have a unit control block (UCB) above the 16MB line.

You cannot specify OS CVOLs as STEPCAT. Access to an OS CVOL is possible

only with a special CVOL pointer in the master catalog.

References

For more information about VSAM data sets, see z/OS DFSMS: Using Data Sets.

Syntax
//STEPCAT DD DISP={OLD},DSNAME=private-catalog-name[,parameter]... [comments]
{SHR}

Parameters on STEPCAT DD Statements

Do not specify any unit or volume information. The system obtains the location of
the private catalog from the master catalog. Do not specify FREE=CLOSE; CLOSE
is ignored.

Relationship to Other Control Statements

Concatenating Step Catalogs

To specify more than one private catalog for a step:

v Code a STEPCAT DD statement.
v Immediately follow this statement with DD statements that define other private
catalogs. Omit a ddname from these subsequent DD statements.

Overriding a JOBCAT

To override a JOBCAT private catalog with the master catalog for a particular job
step, code the following in the job step:
//STEPCAT DD DISP=OLD,DSNAME=master-catalog-name

| See also “Relationship between JOBLIB and Passed Data Sets” on page 13-5 for
| information about the relationship of the STEPCAT statement to the JOBLIB
| statement.

Location in the JCL

Place a STEPCAT DD statement in any position among the DD statements for a
step.

Example of the STEPCAT DD Statement

// EXEC PROC=SNZ12
//STEPCAT DD DSNAME=BETTGER,DISP=SHR

The STEPCAT DD statement specifies a private catalog that the system uses for
this job step only.

13-8 z/OS V1R3.0 MVS JCL Reference

 STEPLIB DD

STEPLIB DD Statement
Purpose

Use the STEPLIB DD statement to:

v Create a private library.
v Identify a private library that the system is to search for the program named in
the EXEC statement PGM parameter. If the system does not find the program in
the private library, only then does the system search the system libraries.

The private library is a partitioned data set (PDS) or partitioned data set extended
(PDSE) on a direct access device. Each member is an executable, user-written
program.

Subsequent job steps in the same job may refer to or receive a private library
defined on a STEPLIB DD statement. Also, you can place a STEPLIB DD statement
in an in-stream or cataloged procedure.

Syntax
//STEPLIB DD parameter[,parameter]... [comments]

Parameters on STEPLIB DD Statements

When Retrieving a Cataloged Library
v Code the DSNAME parameter.
v Code the DISP parameter. The status subparameter must be OLD or SHR. The
disposition subparameters should indicate what you want done with the private
library after its use in the job step.
v Do not code VOLUME or UNIT.

When Retrieving a Library Passed from a Previous Step

In the passing job step, code a DISP disposition subparameter of PASS when a
step library is to be used by subsequent steps in the job.

In a receiving step:
v Code in the DSNAME parameter either the name of the step library or a
backward reference of the form *.stepname.STEPLIB. If the step library is
defined in a procedure, the backward reference must include the procedure step
name: *.stepname.procstepname.STEPLIB.
v Code the DISP parameter. The status subparameter must be OLD. The
disposition subparameters should indicate what you want done with the private
library after its use in the receiving step.

When Retrieving a Library that is Neither Cataloged Nor Passed

v Code the DSNAME parameter.
v Code the DISP parameter. The status subparameter must be OLD or SHR. The
disposition subparameters should indicate what you want done with the private
library after its use in the job step.
v Code the UNIT parameter.
v Code the VOLUME parameter.

Chapter 13. Special DD Statements 13-9

STEPLIB DD
When Creating a Library
v Code the DSNAME parameter to assign the library a name.
v Code the UNIT parameter. The library must be allocated to a direct access
device.
v Code a VOLUME parameter, unless a nonspecific request is to be made for any
volume.
v Code the SPACE parameter, allowing enough space for the entire library on one
direct access volume. Specify space for the PDS directory.
v Code a DISP parameter. The status is NEW. Code CATLG as the disposition, if
you intend to keep the library you are creating. Code PASS as the disposition, if
you wish the library to be available to a following step. Note that you must code
a disposition; otherwise, the system assumes DELETE and deletes the library at
the end of the step.

Note: Do not use VSAM for a STEPLIB library.

When Adding Members to the Library

v In the DSNAME parameter, follow the library name with the name of the program
being added to the library. For example, DSNAME=LIBRARY(PROGRAM).
v Code the status in the DISP parameter as MOD. If the library is cataloged, do
not code a disposition. Otherwise, code PASS or CATLG.
v If the library is cataloged, do not code unit and volume information. Otherwise,
code UNIT and VOLUME.
v Do not code a SPACE parameter. The STEPLIB DD statement requests space
for the entire library.

Other Parameters

Code the DCB parameter if complete data control block information is not contained
in the data set label. Do not specify FREE=CLOSE; CLOSE is ignored.

Relationship to Other Control Statements

Concatenating Step Libraries

To specify more than one private library for a step:

v Code a STEPLIB DD statement.
v Immediately follow this statement with DD statements that define other private
libraries. Omit a ddname from these subsequent DD statements.

The system searches the libraries for the program in the same order as the DD
statements.

Overriding a JOBLIB

If you want the system to ignore the JOBLIB for a particular job step and the step
does not require another private library, define the system library on a STEPLIB DD
statement. For example, specify:
//STEPLIB DD DSNAME=SYS1.LINKLIB,DISP=SHR

For this particular job step, the system will first search SYS1.LINKLIB, as specified
on the STEPLIB DD statement, for the program requested in the EXEC statement.
The system will not search the JOBLIB.

13-10 z/OS V1R3.0 MVS JCL Reference

 STEPLIB DD
Location in the JCL
Place a STEPLIB DD statement in any position among the DD statements for a
step.

If libraries are concatenated to the STEPLIB library, the concatenated DD

statements must immediately follow the STEPLIB DD statement.

Relationship of a STEPLIB to a JOBLIB

Use a JOBLIB DD statement to define a private library that the system is to use for
an entire job. If you include a JOBLIB DD statement for the job and a STEPLIB DD
statement for an individual job step, the system first searches the step library and
then the system library for the program requested in the EXEC statement. The
system ignores the JOBLIB library for that step.

Examples of the STEPLIB DD Statement

Example 1
//PAYROLL JOB BROWN,MSGLEVEL=1
//STEP1 EXEC PROC=LAB14
//STEP2 EXEC PGM=SPKCH
//STEPLIB DD DSNAME=PRIV.LIB5,DISP=(OLD,KEEP)
//STEP3 EXEC PGM=TIL80
//STEPLIB DD DSNAME=PRIV.LIB12,DISP=(OLD,KEEP)

The system searches PRIV.LIB5 for the program SPKCH and PRIV.LIB12 for TIL80.
The system catalogs both private libraries.

Example 2
//PAYROLL JOB BAKER,MSGLEVEL=1
//JOBLIB DD DSNAME=LIB5.GROUP4,DISP=(OLD,PASS)
//STEP1 EXEC PROC=SNZ12
//STEP2 EXEC PGM=SNAP10
//STEPLIB DD DSNAME=LIBRARYP,DISP=(OLD,PASS),
// UNIT=3350,VOLUME=SER=55566
//STEP3 EXEC PGM=A1530
//STEP4 EXEC PGM=SNAP11
//STEPLIB DD DSNAME=*.STEP2.STEPLIB,
// DISP=(OLD,KEEP)

The system searches LIBRARYP for program SNAP10; LIBRARYP is passed to

subsequent steps of this job. The STEPLIB DD statement in STEP4 refers to the
LIBRARYP library defined in STEP2; the system searches LIBRARYP for SNAP11.
Since a JOBLIB DD statement is included, the system searches for programs
SNZ12 and A1530 first in LIB5.GROUP4, then in SYS1.LINKLIB.

Example 3
//PAYROLL JOB THORNTON,MSGLEVEL=1
//JOBLIB DD DSNAME=LIB5.GROUP4,DISP=(OLD,PASS)
//STEP1 EXEC PGM=SUM
//STEPLIB DD DSNAME=SYS1.LINKLIB,DISP=OLD
//STEP2 EXEC PGM=VARY
//STEP3 EXEC PGM=CALC
//STEPLIB DD DSNAME=PRIV.WORK,DISP=(OLD,PASS)
// DD DSNAME=LIBRARYA,DISP=(OLD,KEEP),
// UNIT=3350,VOLUME=SER=44455
// DD DSNAME=LIB.DEPT88,DISP=(OLD,KEEP)
//STEP4 EXEC PGM=SHORE

Chapter 13. Special DD Statements 13-11

STEPLIB DD
For STEP2 and STEP4, the system searches the private library named
LIB5.GROUP4 defined in the JOBLIB DD statement first for programs VARY and
SHORE. For STEP1, the system searches SYS1.LINKLIB first for program SUM,
because the STEPLIB DD statement names the system library.

A concatenation of private libraries is defined in STEP3. The system searches for

the program named CALC in this order: PRIV.WORK, LIBRARYA, LIB.DEPT88,
SYS1.LINKLIB. If a later job step refers to the STEPLIB DD statement in STEP3,
the system will search for the program in the private library named PRIV.WORK
and, if it is not found there, in SYS1.LINKLIB; the concatenated libraries are not
searched.

SYSABEND, SYSMDUMP, and SYSUDUMP DD Statements

Purpose

Use a SYSABEND, SYSMDUMP, or SYSUDUMP DD statement in a job step to

direct the system to produce a dump. The system produces the requested dump:
v If the step terminates abnormally.
v If the step starts to terminate abnormally, but system recovery procedures enable
the step to terminate normally.

The dump DD statements for requesting dumps are:

SYSABEND DD statement
Produces a dump of user and system areas; this dump contains all the areas
dumped in a SYSUDUMP, plus:
v The local system queue area (LSQA), including subpools 229, 230, and 249
v The input/output system (IOS) control blocks for the failing task.

The dump is formatted, so that it can be printed directly.

SYSMDUMP DD statement
Produces a dump of the system areas and the program’s address space. The
dump is unformatted and machine-readable; to be used, it must be printed by
the interactive problem control system (IPCS).
SYSUDUMP DD statement
Produces a dump of user areas. The dump is formatted, so that it can be
printed directly.

The dump contents are as described only when the installation uses the
IBM-supplied defaults for the dumps. The contents of these dumps can be set
during system initialization and/or can be changed for an individual dump in the
ABEND macro instruction, in a CHNGDUMP command, and by a SLIP command.
For details, see z/OS MVS Initialization and Tuning Guide.

Dumps are optional; use a dump DD statement only when you want to produce a
dump.

References

For information on how to interpret dumps, see z/OS MVS Diagnosis: Tools and
Service Aids.

13-12 z/OS V1R3.0 MVS JCL Reference

 SYSABEND, SYSMDUMP, SYSUDUMP DD
Syntax
//SYSABEND DD parameter[,parameter]... [comments]
//SYSMDUMP DD parameter[,parameter]... [comments]
//SYSUDUMP DD parameter[,parameter]... [comments]

Location in the JCL

Do not place in the same job step two DD statements with the same dump ddname.

Storing a Dump
If you wish to store a dump instead of having it printed, code the following
parameters on the dump DD statement:
v The DSNAME parameter.
v The UNIT parameter.
v The VOLUME parameter. This parameter is optional and not recommended. The
system will select a volume.
v The DISP parameter. The data set’s status is NEW. Because you want to store
the data set, make the data set’s abnormal termination disposition KEEP or
CATLG.
v The SPACE parameter, if the dump is written on direct access.

Note: Do not use VSAM for dump data sets.

SYSMDUMP Requirements

The SYSMDUMP DD statement must specify a magnetic tape unit or a direct

access device.

With the exception of the following facility, the system processes dump data sets
according to the disposition to which they are allocated. To keep only the first
SYSMDUMP dump written to a dump data set, specify the following on the
SYSMDUMP DD statement:
v DSNAME=SYS1.SYSMDPxx, where xx is 00 through FF and indicates the
specific dump data set to be used. SYSMDPxx is a preallocated data set that
must have end-of-file (EOF) mark as its first record.
v DISP=SHR
v FREE=CLOSE for multiple job steps

See z/OS MVS Diagnosis: Tools and Service Aids for a description of the
SYS1.SYSMDPxx naming convention and an explanation of how the system
manages the dump data sets.

Printing a Dump
To print a dump for either a SYSABEND or SYSUDUMP DD statement, code one of
the following on the DD statement for the output data set:
v A UNIT parameter that specifies a printer.
v The SYSOUT parameter that specifies a print output class.

To print a dump for a SYSMDUMP DD statement, use the following program:

Chapter 13. Special DD Statements 13-13

SYSABEND, SYSMDUMP, SYSUDUMP DD
IPCS
This program is described in z/OS MVS IPCS User’s Guide. When using IPCS,
the data set disposition affects the collection of events.

If you print the dump in a JES3 system on a 3800 Printing Subsystem, code
CHARS=DUMP for a dump with 204 characters per line and FCB=STD3 for 8 lines
per inch.

Overriding Dump DD Statements

To change the type of dump requested in a dump DD statement in a cataloged or
in-stream procedure, the ddname of the overriding DD statement in the calling step
must be different from the dump ddname of the procedure DD statement.

Duplicate Dump Requests

You can code more than one dump request in a job step using DD statements that
have different ddnames. When you do this, the system uses the last dump DD
statement it encounters.

When the system finds dump DD statements with duplicate ddnames, processing is
as follows:
v In a JES2 system, the job fails with message IEA912I.
v In a JES3 system:
– If both DD statements request JES3- or jointly-managed devices, the job is
cancelled during JES3 interpretation.
– If only one or neither statement requests JES3- or jointly-managed devices,
the job fails with message IEA912I.

Examples of the SYSABEND, SYSMDUMP, and SYSUDUMP DD

Statements
Example 1
//STEP2 EXEC PGM=A
//SYSUDUMP DD SYSOUT=A

The SYSUDUMP DD statement specifies that you want the dump routed to system
output class A.

Example 2
//SYSMDUMP DD DSNAME=DUMP,DISP=(NEW,KEEP),
// UNIT=3400-6,VOLUME=SER=147958

The SYSMDUMP DD statement specifies that the dump is to be stored on a tape.

Because the LABEL parameter is not coded, the tape must have IBM standard
labels.

Example 3
//STEP1 EXEC PGM=PROGRAM1
//SYSABEND DD DSNAME=DUMP,UNIT=3350,DISP=(,PASS,KEEP),
// VOLUME=SER=1234,SPACE=(TRK,(40,20))
//STEP2 EXEC PGM=PROGRAM2
//SYSABEND DD DSNAME=*.STEP1.SYSABEND,DISP=(OLD,DELETE,KEEP)

Both SYSABEND DD statements specify that the dump is to be stored. The space
request in STEP1 is ample and will not inhibit dumping due to insufficient space. If
STEP1 does not abnormally terminate but STEP2 does, the system writes the

13-14 z/OS V1R3.0 MVS JCL Reference

 SYSABEND, SYSMDUMP, SYSUDUMP DD
dump for STEP2 in the space allocated in STEP1. In both steps, an abnormal
termination disposition of KEEP is specified so that the dump is stored if either of
the steps abnormally terminates. If both of the steps successfully execute, the
second DISP subparameter, DELETE, in STEP2 instructs the system to delete the
data set and free the space acquired for dumping.

Example 4
//STEP EXEC PGM=EXSYSM
//SYSMDUMP DD UNIT=3330,VOLUME=SER=123456,SPACE=(CYL,(0,1)),
// DISP=(NEW,DELETE,KEEP),DSNAME=MDUMP

The SYSMDUMP DD statement allocates dump data set MDUMP to a direct access
device.

Example 5
//JOB1 JOB
//STEP EXEC PGM=EXSYSMDP
//SYSMDUMP DD DSNAME=SYS1.SYSMDP00,DISP=SHR

//JOB2 JOB
//STEP EXEC PGM=EXSYSMDP
//SYSMDUMP DD DSNAME=SYS1.SYSMDP00,DISP=SHR

Only the SYSMDUMP dump written by the first job will be in data set
SYS1.SYSMDP00. All subsequent jobs receive message IEA849I, indicating that
the data set is full.

Note: When you specify a DSNAME of SYS1.SYSMDPxx with DISP=SHR, the

system writes the first SYSMDUMP dump on the data set. You must offload
this first SYSMDUMP dump and write an EOF mark at the beginning of the
SYS1.SYSMDPxx data set before subsequent dumps can be written to that
data set.

SYSCHK DD Statement
Purpose

Use the SYSCHK DD statement to define a checkpoint data set that the system is
to write during execution of a processing program. Use this statement again when
the step is restarted from a checkpoint written in the data set.

Note: If restart is to begin at a step, as indicated by the RD parameter on the

EXEC statement, do not use a SYSCHK DD statement.

References

For detailed information about the checkpoint/restart facilities, see z/OS DFSMS
Checkpoint/Restart.

Syntax
//SYSCHK DD parameter[,parameter]... [comments]

Chapter 13. Special DD Statements 13-15

SYSCHK DD
Parameters on SYSCHK DD Statements
When Creating a Checkpoint Data Set
v Code a SPACE parameter, but do not request secondary space.
– The primary space request must be large enough to hold all checkpoints.
Although your program or the system can write checkpoints in secondary
space, the system cannot perform a restart from checkpoints in secondary
space.
– If you do not request secondary space and the primary space fills up, the
job abnormally terminates. You can successfully restart the job at the last
checkpoint; however, when the processing program or system writes the next
checkpoint the job abnormally terminates again.
– If you do request secondary space and the primary space fills up, the
processing program or the system writes one invalid checkpoint followed by
successful checkpoints. An attempt to restart from one of the checkpoints
following the invalid checkpoint results in abnormal termination.
v Code the RLSE subparameter of the SPACE parameter only if the processing
program opens the checkpoint data set and the checkpoint data set remains
open until the end of the program. If you specify RLSE, the system releases
unused space after the first CLOSE macro instruction.
Do not code the RLSE subparameter:
– If the processing program opens the checkpoint data set before writing each
checkpoint and closes the checkpoint data set after writing each checkpoint.
The system releases all unused space while closing the data set after the first
checkpoint, leaving no space for additional checkpoints.
– If the system opens the checkpoint data set. The system opens and closes
the checkpoint data set before it writes the first checkpoint. With RLSE
specified, the system would release all space before the first checkpoint could
be written.
v Code the CONTIG subparameter of the SPACE parameter to request contiguous
space. The system otherwise provides additional primary space using extents. If
the extents are not contiguous, any checkpoints in these extents cannot be used
for a successful restart.

When Retrieving a Cataloged Checkpoint Data Set

v Code the DSNAME parameter.
v Code the DISP parameter to specify a status of OLD and a disposition of KEEP.
v Code the VOLUME parameter. If the checkpoint entry is on a tape volume other
than the first volume of the checkpoint data set, code the volume serial number
or volume sequence number to identify the correct volume. The serial number of
the volume on which a checkpoint entry was written appears in the console
message issued after the checkpoint entry is written.
v Code the UNIT parameter, if you coded the VOLUME parameter, because the
system will not look in the catalog for unit information.

When Retrieving a Checkpoint Data Set that is not Cataloged

v Code the DSNAME parameter. If the checkpoint data set is a partitioned data set
(PDS), do not code a member-name in the DSNAME parameter.
v Code the DISP parameter to specify a status of OLD and a disposition of KEEP.
v Code the VOLUME parameter. The serial number of the volume on which a
checkpoint entry was written appears in the console message issued after the
checkpoint entry is written.

13-16 z/OS V1R3.0 MVS JCL Reference

 SYSCHK DD
v Code the UNIT parameter.

Other Parameters
v Code the LABEL parameter if the checkpoint data set does not have standard
labels.
v Code DCB=TRTCH=C if the checkpoint data set is on 7-track magnetic tape with
nonstandard labels or no labels.
v If the volume containing the checkpoint data set is to be mounted on a
JES3-managed device, do not code the DEFER subparameter of the UNIT
parameter on the SYSCHK DD statement.

Note: Do not use VSAM for a checkpoint data set, and do not use a partitioned
data set extended (PDSE) for a checkpoint data set.

Relationship to Other Control Statements

Code the RESTART parameter on the JOB statement; without it, the system ignores
the SYSCHK DD statement.

Location in the JCL

v When writing checkpoints, place the SYSCHK DD statement after any JOBLIB
DD statements, if coded; otherwise, after the JOB statement.
v When restarting a job from a checkpoint, place the SYSCHK DD statement
immediately before the first EXEC statement of the resubmitted job.

Examples of the SYSCHK DD Statement

Example 1
//JOB1 JOB RESTART=(STEP3,CK3)
//SYSCHK DD DSNAME=CHLIB,UNIT=3350,
// DISP=OLD,VOLUME=SER=456789
//STEP1 EXEC PGM=A

The checkpoint data set defined on the SYSCHK DD statement is not cataloged.

Example 2
//JOB2 JOB RESTART=(STEP2,NOTE2)
//JOBLIB DD DSNAME=PRIV.LIB3,DISP=(OLD,PASS)
//SYSCHK DD DSNAME=CHECKPTS,DISP=(OLD,KEEP),
// UNIT=3400-6,VOLUME=SER=438291
//STEP1 EXEC PGM=B

The checkpoint data set defined on the SYSCHK DD statement is not cataloged.
Note that the SYSCHK DD statement follows the JOBLIB DD statement.

SYSCKEOV DD Statement
Purpose

Use the SYSCKEOV DD statement to define a checkpoint data set for checkpoint
records from the checkpoint at end-of-volume (EOV) facility. The checkpoint at EOV
facility is invoked by a DD CHKPT parameter.

References

Chapter 13. Special DD Statements 13-17

SYSCKEOV DD
For information on the DD CHKPT parameter, see “CHKPT Parameter” on
page 12-41 . For information on checkpoint/restart facilities, see z/OS DFSMS
Checkpoint/Restart.

Syntax
//SYSCKEOV DD parameter[,parameter]... [comments]

Parameters on SYSCKEOV DD Statements

When Creating a Checkpoint Data Set
v Code a SPACE parameter, but do not request secondary space. The primary
space request must be large enough to hold all checkpoints; if not, the job
abnormally terminates.
v Do not code the RLSE subparameter of the SPACE parameter.
v Code the CONTIG subparameter of the SPACE parameter to request contiguous
space. The system otherwise provides additional primary space using extents.
v The SYSCKEOV DD statement must define a BSAM data set, but cannot define
a partitioned data set extended (PDSE).
v Code DISP=MOD to reduce loss of checkpoint data in case of a system failure
during checkpointing.

Other Parameters
v Do not code on the SYSCKEOV DD statement the following:
– CHKPT=EOV parameter.
– DCB parameter. All DCB information is provided by the checkpoint at EOV
facility.
– DEFER subparameter of the UNIT parameter.
v If you code the LABEL parameter, you must specify LABEL=(,SL) for IBM
standard labels.
v If the SYSCKEOV data set resides on a direct access storage device, that device
cannot be shared with another processor.

Location in the JCL

If you code a CHKPT parameter on any DD statements in a job step, place a
SYSCKEOV DD statement in the DD statements for the step.

Example of the SYSCKEOV DD Statement

//SYSCKEOV DD DSNAME=CKPTDS,UNIT=TAPE,DISP=MOD

This statement defines a checkpoint data set for checkpoint at EOV records.

SYSIN DD Statement
Purpose

By convention, people often use a SYSIN DD statement to begin an in-stream data

set. In-stream data sets begin with a DD * or DD DATA statement; these DD
statements can have any valid ddname, including SYSIN. If you omit a DD
statement before input data, the system provides a DD * statement with the
ddname of SYSIN.

13-18 z/OS V1R3.0 MVS JCL Reference

 SYSIN DD
Syntax
//SYSIN DD parameter[,parameter]... [comments]

Parameters on SYSIN DD Statements

The first parameter is an * or DATA, to signal that an in-stream data set follows
immediately.

Location in the JCL

A SYSIN DD statement appears at the beginning of an in-stream data set.

Examples of SYSIN DD Statements

//STEP1 EXEC PGM=READ
//SYSIN DD *
.
.
data
.
//OUT1 DD SYSOUT=A
//STEP2 EXEC PGM=WRITE
//SYSIN DD DATA,DLM=17
.
.
.
17

Chapter 13. Special DD Statements 13-19

SYSIN DD

13-20 z/OS V1R3.0 MVS JCL Reference

Chapter 14. Delimiter Statement
Purpose

Use the delimiter statement to indicate the end of data or transmittal records in the
input stream.

Considerations for an APPC Scheduling Environment

The delimiter statement has no function in an APPC scheduling environment. If you

code a delimiter statement, the system will ignore it.

Description

Syntax

/* [comments]
xx [comments]

A delimiter statement consists of the characters /* or the two characters specified in a DLM
parameter in columns 1 and 2 and one field: comments.

Do not continue a delimiter statement.

Comments Field
The comments field follows the delimiter characters.

For JES2, code any comments in columns 4 through 80. (A blank must follow the
delimiter characters.)

For JES3, text in columns 3 through 80 is a comment, except when the default
delimiter (/*) is used with an //XMIT statement causing the text starting in column 3
to be recognized as a JECL statement (for example, /*ROUTE, /*JOBPARM). This
includes JES2 commands (/*$command) except that any command prefix other
than $ is considered a comment instead of a command.

To avoid ambiguity in these cases, IBM recommends that you either start comments
in column 4 or use a delimiter other than the default on the //XMIT statement.

Relationship to the DLM Parameter

The system recognizes a delimiter other than /* if a DLM parameter is coded on:
v A DD * or DD DATA statement that defines an in-stream data set.
v An XMIT JCL statement that precedes input stream records to be transmitted to
another node.
v A JES2 /*XMIT statement that precedes input stream records to be transmitted to
another node.

A delimiter statement is optional:

v If the data is preceded by a DD * statement without a DLM parameter.

© Copyright IBM Corp. 1988, 2002 14-1

Delimiter Statement
v If transmitted records are preceded by an /*XMIT statement without a DLM
parameter.

Location in the JCL

A delimiter statement must appear:
v At the end of an in-stream data set that begins with a DD DATA statement.
v At the end of an in-stream data set that begins with a DD statement containing a
DLM parameter.
v At the end of records to be transmitted to another node when the records are
preceded by an /*XMIT statement containing a DLM parameter.
v At the end of records to be transmitted to another node when the records are
preceded by an XMIT JCL statement.

Examples of the Delimiter Statement

Example 1
//JOB54 JOB ,’C BROWN’,MSGLEVEL=(2,0)
//STEPA EXEC PGM=SERS
//DD1 DD *
.
.
data
.
/* END OF DATA FOR DATA SET DD1
//DD2 DD DATA,DLM=AA
.
.
data
.
AA END OF DATA FOR DATA SET DD2

Example 2
//JOB54 JOB ,’C BROWN’,MSGLEVEL=(2,0)
// XMIT DEST=NODEA,DLM=BB
//JOB55 JOB ,’C BROWN’,MSGLEVEL=(2,0)
//STEPA EXEC PGM=SERS
//DD1 DD *
.
.
data
.
/* END OF DATA FOR DATA SET DD1
//DD2 DD DATA,DLM=AA
.
.
data
.
AA END OF DATA FOR DATA SET DD2
BB END OF TRANSMITTED JOB

This example shows nested delimiter statements.

14-2 z/OS V1R3.0 MVS JCL Reference

Chapter 15. ENDCNTL Statement
Purpose

Use the ENDCNTL statement to mark the end of the program control statements
following a CNTL statement.

Description

Syntax
//[label] ENDCNTL [comments]

The ENDCNTL statement consists of the characters // in columns 1 and 2, and three fields:
label, operation (ENDCNTL), and comments.

Label Field
Code a label on the ENDCNTL statement, as follows:
v Each label must be unique within the job.
v The label must begin in column 3.
v The label is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The label must be followed by at least one blank.

Operation Field
The operation field consists of the characters ENDCNTL and must be preceded and
followed by at least one blank. It can begin in any column.

Comments Field
The comments field follows the ENDCNTL after at least one intervening blank.

Location in the JCL

The ENDCNTL statement immediately follows the one or more program control
statements following a CNTL statement. Thus, the ENDCNTL statement can appear
in a job step or in a cataloged or in-stream procedure.

Example of the ENDCNTL Statement

//STEP1 EXEC PGM=PRINT
//ABLE CNTL
//STATE1 PRINTDEV BUFNO=20,PIMSG=YES,DATACK=BLOCK
//BAKER ENDCNTL
//CALLER DD UNIT=3800-3,CNTL=*.ABLE

(For information about the PRINTDEV JCL statement see the manual PSF for
OS/390 & z/OS: Customization.)

© Copyright IBM Corp. 1988, 2002 15-1

15-2 z/OS V1R3.0 MVS JCL Reference
Chapter 16. EXEC Statement
Purpose

Use the EXEC (execute) statement to identify the program or cataloged or

in-stream procedure that this job step is to execute and to tell the system how to
process the job step. The EXEC statement marks the beginning of each step in a
job or a procedure.

A job can have a maximum of 255 job steps. This maximum includes all steps in
any procedures the EXEC statements call.

The parameters you can specify for step processing are arranged alphabetically in
the following pages.

References

For information about the JES initialization parameters that provide installation
defaults, see z/OS JES2 Initialization and Tuning Reference and z/OS JES3
Initialization and Tuning Reference.

Description

Syntax
//[stepname] EXEC positional-parm[,keyword-parm]...[,symbolic-parm=value]...
[comments]

The EXEC statement consists of the characters // in columns 1 and 2 and four fields: name,
operation (EXEC), parameter, and comments.

An EXEC statement is required for each job step.

Name Field
A stepname is optional, but is needed for the following. When a stepname is
needed, it must be unique within the job, including stepnames in any procedures
called by the job.
v Referring to the step in later job control statements.
v Overriding parameters on an EXEC statement or DD statement in a cataloged or
in-stream procedure step.
v Adding DD statements to a cataloged or in-stream procedure step. However, a
stepname is not required when adding to the first step in a procedure.
v Performing a step or checkpoint restart at or in the step.
v Identifying a step in a cataloged or in-stream procedure.

Code a stepname as follows:

v The stepname must begin in column 3.
v The stepname is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The stepname must be followed by at least one blank.

© Copyright IBM Corp. 1988, 2002 16-1

 EXEC
| v The stepname may be preceded by up to 8 alphanumeric or national characters
| and then separated by a period. If the stepname is coded in this way, the
| characters up to and including the period are ignored.

Stepnames for Started Tasks

When JCL runs as a started task, the system assigns a stepname of ssssssss
(when the START command was S procname.ssssssss) or STARTING (when the
START command was S procname). Embedded procedures that refer back to the
invoking procedure, as on a COND parameter, need to specify the stepname the
system assigns.

Operation Field
The operation field consists of the characters EXEC and must be preceded and
followed by at least one blank. It can begin in any column.

Parameter Field
An EXEC statement has two kinds of parameters: positional and keyword.

Do not use EXEC statement parameter keywords as symbolic parameters, names,

or labels.

Positional Parameters

An EXEC statement must contain one of the positional parameters: PGM, PROC,
or procedure name. This positional parameter must precede all keyword
parameters.

POSITIONAL PARAMETERS VALUES PURPOSE

PGM= {program-name } program-name: 1 - 8 alphanumeric or Names the program the

{*.stepname.ddname } $, #, @ characters member system is to execute or,
{*.stepname.procstepname.ddname} containing program for JES3 only, requests
{JCLTEST } syntax check without
{JSTTEST } stepname: DD in named step execution

See page 16-23 procstepname: step in named

procedure

JCLTEST and JSTTEST: scan for

syntax without executing the job
(JES3 only)

{PROC=procedure-name} procedure-name: 1 - 8 alphanumeric Names the cataloged or

{procedure-name } or $, #, @ characters in-stream procedure the
system is to call and
See page 16-25 execute.

Keyword Parameters

An EXEC statement can contain the following keyword parameters. You can code
any of the keyword parameters in any order in the parameter field after the
positional parameter.

16-2 z/OS V1R3.0 MVS JCL Reference

 EXEC
KEYWORD PARAMETERS VALUES PURPOSE

ACCT[.procstepname]=(accounting-information) accounting-information: up to 142 Specifies accounting

characters information for the step
See page 16-6
[.procstepname]: name of procedure
EXEC containing ACCT to be affected

ADDRSPC[.procstepname]= {VIRT} VIRT: virtual (pageable) storage Indicates the type of

{REAL} storage required for the
REAL: central (nonpageable) storage step.
See page 16-8 [.procstepname]: name of procedure
EXEC containing ADDRSPC to be
affected

CCSID=nnnnn nnnnn: 1 - 65535 Specifies the coded

character set identifier
indicating the character
code conversion
performed on reads from
and writes to tapes
accessed in ISO/ANSI
Version 4 format.

COND[.procstepname]=
((code,operator[,stepname][.procstepname]) )
([,(code,operator[,stepname][.procstepname])...])
( [,EVEN] )
( [,ONLY] )

See page 16-10

code: 0 - 4095 Specifies the return code
operator: GT Code from tests used to determine if
GE chart on this step is to be
EQ page executed or bypassed.
16-15
LT
LE
NE

EVEN: execute step even if preceding

step abnormally terminated

ONLY: execute step only if preceding

step abnormally terminated

stepname: step issuing return code

procstepname: step is in named

procedure

[.procstepname]: name of procedure

EXEC containing COND to be
affected

DYNAMNBR[.procstepname]=n n: 0 - 3273 minus number of DD Holds a number of data

statements in step set allocations for reuse.
See page 16-18
[.procstepname]: name of procedure
EXEC containing DYNAMNBR to be
affected

Chapter 16. EXEC Statement 16-3

EXEC
KEYWORD PARAMETERS VALUES PURPOSE

MEMLIMIT={nnnnnM} n: 0 - 99999 Specifies the limit on the

{nnnnnG} total number of usable
{nnnnnT} virtual pages above the
{nnnnnP} bar in a single address
{NOLIMIT} space.

See page 16-19

PARM[.procstepname]=subparameter
PARM[.procstepname]=(subparameter,subparameter)
PARM[.procstepname]=(’subparameter’,subparameter)
PARM[.procstepname]=’subparameter,subparameter’

See page 16-20

subparameter: up to 100 characters Passes variable
information to the
[.procstepname]: name of procedure processing program.
EXEC containing PARM to be
affected

PERFORM[.procstepname]=n n: 1 - 999 In WLM compatibility

mode, specifies the
See page 16-21 [.procstepname]: name of procedure step’s performance
EXEC containing PERFORM to be group. In WLM goal
affected mode, PERFORM on the
EXEC statement is
ignored except for the
TSO logon procedure,
where it can be used to
classify the TSO user to
a service class or report
class.

RD[.procstepname]= {R } R: restart, checkpoints allowed In a non-APPC

{RNC} scheduling environment,
{NR } RNC: restart, no checkpoints indicates whether the
{NC } operator should perform
NR: no restart, checkpoints allowed automatic step restart, if
See page 16-26 the step fails, and
NC: no restart, no checkpoints
controls whether
[.procstepname]: name of procedure checkpoints are written
EXEC containing RD to be affected for CHKPT macros or
DD statement CHKPT
parameters.

REGION[.procstepname]={valueK} valueK: 1 - 7 digits from 1 - 2096128 Specifies the amount of

{valueM} space in kilobytes or
valueM: 1 - 4 digits from 1 - 2047 megabytes required by
See page 16-29 the step.
[.procstepname]: name of procedure
EXEC containing REGION to be
affected

16-4 z/OS V1R3.0 MVS JCL Reference

 EXEC
KEYWORD PARAMETERS VALUES PURPOSE

TIME[.procstepname]= {([minutes][,seconds])} minutes: 1 - 357912 Specifies the maximum

{1440 } time the step is to use
{NOLIMIT } seconds: 1 - 59 the processor and
{MAXIMUM } requests messages
[.procstepname]: name of procedure giving the time used.
See page 16-31 EXEC containing TIME to be affected

NOLIMIT: specifies that the step can

use the processor for an unlimited
amount of time

MAXIMUM: specifies that the step

can use the processor for the
maximum amount of time

Keyword Parameters on an EXEC Statement that Calls a Procedure

When an EXEC statement positional parameter calls a cataloged or in-stream

procedure, all of the EXEC statement’s keyword parameters override matching
EXEC keyword parameters in the called procedure. If a keyword parameter is to
override a parameter on only one EXEC statement in the procedure, code
.procstepname immediately following the keyword:
keyword.procstepname=value

The procstepname is the name field on the procedure EXEC statement containing
the keyword parameter to be overridden. For example:
//STEP1 EXEC PROC=WKREPORT,ACCT.PSTEPWED=5670

The accounting information 5670 applies only to step PSTEPWED in the procedure
WKREPORT.

Symbolic Parameters on an EXEC Statement that Calls Procedures

An EXEC statement can assign values to, or nullify, symbolic parameters. See
“Using System Symbols and JCL Symbols” on page 5-12 for more information
about symbolic parameters.

Comments Field
The comments field follows the parameter field after at least one intervening blank.

Location in the JCL

An EXEC statement must be the first statement in each job step or cataloged or
in-stream procedure step.

Examples of EXEC Statements

Example 1
//STEP4 EXEC PGM=DREC,PARM=’3018,NO’

The EXEC statement named STEP4 invokes a program named DREC and passes
the value in the PARM parameter to DREC.

Example 2
// EXEC PGM=ENTRY,TIME=(2,30)

Chapter 16. EXEC Statement 16-5

EXEC
This EXEC statement, which does not have a stepname, invokes a program named
ENTRY and specifies the maximum processor time for execution of the step.

Example 3
//FOR EXEC PROC=PROC489,ACCT=DB1528,RD.PSTEP2=RNC,DEV=3350

The EXEC statement named FOR invokes a cataloged or in-stream procedure

named PROC489. The ACCT parameter applies to all steps in the procedure. The
RD parameter applies to only the step named PSTEP2. The DEV parameter
assigns the value 3350 to the symbolic parameter Device Support Bucket in a
procedure statement.

ACCT Parameter
Parameter Type

Keyword, optional

Purpose

Use the ACCT parameter to specify one or more subparameters of accounting

information that apply to this step. The system passes the accounting information to
the installation’s accounting routines.

References

For more information on how to add accounting routines, see z/OS MVS System
Management Facilities (SMF).

Syntax
ACCT[.procstepname]=(accounting-information)

16-6 z/OS V1R3.0 MVS JCL Reference

 EXEC: ACCT
Single Subparameter: You can omit the parentheses if the accounting information consists
of only one subparameter.

Length: The entire accounting-information must not exceed 142 characters:

v Including any commas, which are considered part of the information.
v Excluding any enclosing parentheses or apostrophes, which are not considered part of
the information.

Multiple Subparameters: When the accounting-information consists of more than one

subparameter, separate the subparameters by commas and enclose the information in
parentheses or apostrophes. For example, ACCT=(5438,GROUP6) or
ACCT='5438,GROUP6'.

Special Characters: When a subparameter contains special characters, other than

hyphens or plus zero (+0, an overpunch), enclose it in apostrophes and the information in
parentheses or enclose all of the information in apostrophes. For example,
ACCT=(387,'72/159') or ACCT='387,72/159'.

Code each apostrophe that is part of the accounting-information as two consecutive

apostrophes. For example, code DEPT'D58 as ACCT='DEPT''D58'

If you code a symbolic parameter on the ACCT parameter, you can code the symbolic
parameter in apostrophes.

Continuation onto Another Statement: Enclose the accounting-information in

parentheses. End each statement with a comma after a complete subparameter. For
example:
//STEP1 EXEC PGM=WRITER,ACCT=(1417,J318,’D58/920’,’CHG=2’,
// ’33.95’)

Subparameter Definition
accounting-information
Specifies one or more subparameters of accounting information, as defined by
the installation.

On an EXEC Statement that Calls a Procedure

If an EXEC statement calls a cataloged or in-stream procedure, the ACCT
parameter overrides the ACCT parameter on or is added to:
v The EXEC statement named in the procstepname qualifier. The information
applies only to the named procedure step. The EXEC statement can have as
many ACCT.procstepname parameters as the procedure has steps; each ACCT
parameter must specify a unique procstepname.
v All EXEC statements in the procedure if procstepname is not coded. Then the
information applies to all steps in the called procedure.

Examples of the ACCT Parameter

Example 1
//STEP1 EXEC PGM=JP5,ACCT=(LOCATION8,’CHGE+3’)

This EXEC statement executes program JP5 and specifies accounting information
for this job step.

Example 2
//STP3 EXEC PROC=LOOKUP,ACCT=(’/83468’)

Chapter 16. EXEC Statement 16-7

EXEC: ACCT
This EXEC statement calls cataloged or in-stream procedure LOOKUP. The
accounting information applies to this job step, STP3, and to all the steps in
procedure LOOKUP.

Example 3
//STP4 EXEC PROC=BILLING,ACCT.PAID=56370,ACCT.LATE=56470,
// ACCT.BILL=’121+366’

This EXEC statement calls cataloged or in-stream procedure BILLING. The

statement specifies different accounting information for each of the procedure steps:
PAID, LATE, and BILL.

ADDRSPC Parameter
Parameter Type

Keyword, optional

Purpose

Use the ADDRSPC parameter to indicate to the system that the job step requires
virtual storage (which is pageable) or central storage (also called real storage,
which is nonpageable).

Syntax
ADDRSPC[.procstepname]= {VIRT}
{REAL}

Subparameter Definition
VIRT
Requests virtual storage. The system can page the job step.
REAL
Requests central storage (also called real storage). The system cannot page
the job step and must place the job step in central storage.

Defaults
If no ADDRSPC parameter is specified, the default is VIRT.

Overrides
The JOB statement ADDRSPC parameter applies to all steps of the job and
overrides any EXEC statement ADDRSPC parameters.

Code EXEC statement ADDRSPC parameters when each job step requires different
types of storage. The system uses an EXEC statement ADDRSPC parameter only
when no ADDRSPC parameter is on the JOB statement and only during the job
step.

Relationship to the EXEC REGION Parameter

When ADDRSPC=REAL

16-8 z/OS V1R3.0 MVS JCL Reference

 EXEC: ADDRSPC
Code a REGION parameter to specify how much central storage the job needs. If
you omit the REGION parameter, the system uses the default.

When ADDRSPC=VIRT or ADDRSPC is Omitted

Code a REGION parameter to specify how much virtual storage the job needs. If
you omit the REGION parameter, the system uses the default.

On an EXEC Statement that Calls a Procedure

If this EXEC statement calls a cataloged or in-stream procedure, the ADDRSPC
parameter overrides the ADDRSPC parameter on or is added to:
v The EXEC statement named in the procstepname qualifier. The parameter
applies only to the named procedure step. The EXEC statement can have as
many ADDRSPC.procstepname parameters as the procedure has steps; each
ADDRSPC parameter must specify a unique procstepname.
v All EXEC statements in the procedure if procstepname is not coded. Then the
parameter applies to all steps in the called procedure.

Examples of the ADDRSPC Parameter

Example 1
//CAC1 EXEC PGM=A,ADDRSPC=VIRT

This EXEC statement executes program A and requests virtual (pageable) storage.
Because the REGION parameter is not specified, the storage available to this job
step is the installation default or the region size specified on the JOB statement.

Example 2
//CAC2 EXEC PROC=B,ADDRSPC=REAL,REGION=80K

This EXEC statement calls procedure B and requests central (nonpageable)

storage. The REGION parameter specifies 80K of storage.

CCSID Parameter
Parameter Type

Keyword, optional

Purpose

On systems with DFSMS/MVS Version 1 Release 5 or higher, and OS/390 Version

2 Release 5 or higher, you can request DFSMSdfp to convert data from/to the
coded character set identifier (CCSID) specified on the JOB or EXEC statement
to/from the CCSID specified on the DD statement. Data conversion is supported on
access to ISO/ANSI Version 4 tapes using access methods BSAM or QSAM, but
not using EXCP.

ISO/ANSI Version 4 tapes are identified by the LABEL=(,AL) or LABEL=(,AUL)

keyword. The CCSID parameter does not apply to ISO/ANSI Version 1 or
ISO/ANSI/FIPS Version 3 tapes or to tapes with labels other than AL or AUL. See
DFSMS/MVS Version 1 Release 5 z/OS DFSMSdfp Storage Administration
Reference and DFSMS/MVS Version 1 z/OS DFSMS: Using Data Sets for selecting
ISO/ANSI Version 4 tapes. See the latter manual for a list of supported CCSIDs.

Chapter 16. EXEC Statement 16-9

EXEC: CCSID
The CCSID value of 65535 has a special meaning: it suppresses conversion.

When CCSID is not specified at the JOB, EXEC, or DD levels, data passed to
BSAM and QSAM is converted to 7-bit ASCII when writing to ISO/ANSI Version 4
tapes. This may result in data loss on conversion. On READ operations the CCSID
(if recorded) on the tape header label is used for conversion.

The CCSID is recorded in the tape header label if conversion is not defaulted.

Syntax
CCSID= nnnnn

Subparameter Definition
nnnnn
The CCSID as a decimal number from 1 through 65535.

Default
If no CCSID parameter is specified on the JOB statement, the default is 500.

Relationship to Other Parameters

Do not code the following parameters with the CCSID parameter:

* DDNAME QNAME
BURST DYNAM SYSOUT
CHARS FCB TERM
COPIES FLASH UCS
DATA MODIFY

Examples of the CCSID Parameter

For examples of the CCSID parameter see ″CCSID Parameter″ in the chapter
″DD Statement.″

COND Parameter
Parameter Type

Keyword, optional

Purpose

Use the COND parameter to test return codes from previous job steps and
determine whether to bypass this job step. You can specify one or more tests on
the COND parameter, and you can test return codes from particular job steps or
from every job step that has completed processing. If any of the test conditions are
satisfied, the system evaluates the COND parameter as true and bypasses the job
step. If none of the test conditions specified on the COND parameter are satisfied,
the system evaluates the COND parameter as false and executes the job step.

16-10 z/OS V1R3.0 MVS JCL Reference

 EXEC: COND
The system performs the COND parameter tests against return codes from the
current execution of the job. If a test specifies a previous step that was bypassed,
the system evaluates the COND parameter as false.

Bypassing a step because of a return code test is not the same as abnormally
terminating the step. The system abnormally terminates a step following an error so
serious that it prevents successful execution. In contrast, bypassing of a step is
merely its omission.

If a step abnormally terminates, the system normally bypasses all following steps in
the job unless the step(s) are part of an IF/THEN/ELSE/ENDIF construct that
specifies the ABEND, ABENDCC, or ¬ABEND keywords, described in Chapter 17,
“IF/THEN/ELSE/ENDIF Statement Construct” on page 17-1. Another way to make
the system execute a following step, for instance, to write a dump, is to code EVEN
or ONLY on that step’s EXEC statement. The EVEN or ONLY subparameters are
interpreted first. If they indicate that the step should be executed, then the return
code tests, if specified, are performed. If no return code tests were coded or if none
of the coded tests is satisfied, the system executes the step.

Instead of coding a JOB statement COND parameter, code an EXEC statement

COND parameter when you want to:
v Specify different tests for each job step.
v Name a specific step whose return code the system is to test.
v Specify special conditions for executing a job step.
v Bypass only one step. When a step is bypassed because of a JOB COND
parameter, all following steps in the job are bypassed.

Note that a test showing that a return code from a step is zero is not sufficient to
verify that the step did not fail; the system may fail a step (or job) even if the return
code is zero. This could happen, for example, as a result of specifying CATLG_ERR
FAILJOB(YES) and incurring that type of ″post execution error.″ (The return code is
generated by the application program and is never changed by the operating
system.) You can determine that a step failed due to a ″post execution error″ if bit
SMF30SYE in the two-byte SMF30STI field in the SMF30 subtype 4 record is on.

Syntax
COND[.procstepname] = (code,operator)
COND[.procstepname] = ((code,operator[,stepname][.procstepname])
[,(code,operator[,stepname][.procstepname])]... [,EVEN])
[,ONLY]
COND=EVEN
COND=ONLY

v One return code test is: (code,operator)

v You can omit the outer parentheses if you code only one return code test or only EVEN
or ONLY.
v Specify up to eight return code tests. However, if you code EVEN or ONLY, specify up to
seven return code tests.
v You can omit all return code tests and code only EVEN or ONLY.
v Place the EVEN or ONLY subparameters before, between, or after the return code tests.
v Null positional subparameters of the COND parameter are invalid.

Chapter 16. EXEC Statement 16-11

EXEC: COND
Subparameter Definition
code
Specifies a number that the system compares to the return codes from all
previous steps in the job or from specific steps. code is a decimal number from
0 through 4095.

Note: Specifying a decimal number greater than 4095 could result in invalid
return code testing or invalid return codes in messages.
operator
Specifies the type of comparison to be made to the return code. If the specified
test is true, the step is bypassed. Use Table 16-1 on page 16-15 to select the
correct operator. Operators and their meanings are:

Operator Meaning
GT Greater than
GE Greater than or equal to
EQ Equal to
LT Less than
LE Less than or equal to
NE Not equal to

stepname
Identifies the EXEC statement of a previous job step that issues the return code
to be used in the test. If the specified step is in a procedure, this step must be
in the same procedure. Otherwise, the specified step must not be in a
procedure; the specified step must contain a PGM keyword, rather than invoke
a procedure.
If you omit stepname, the code you specify is compared to the return codes
from all previous steps. If the return code issued by any of those previous steps
causes the test condition to be satisfied, the system evaluates the COND
parameter as true and bypasses the job step.
If this step is invoked in JCL that runs as a started task, see “Stepnames for
Started Tasks” on page 16-2 for information about the stepname the system
assigns.
stepname.procstepname
Identifies a step in a cataloged or in-stream procedure called by an earlier job
step. Stepname identifies the EXEC statement of the calling job step;
procstepname identifies the EXEC statement of the procedure step that issues
the return code to be used in the test. The step identified by procstepname
must contain the PGM keyword, rather than invoke a procedure.
EVEN
Specifies that this job step is to be executed even if a preceding job step
abnormally terminated. When EVEN is coded, the system:
v Does not test the return code of any steps that terminated abnormally.
v Does test the return code of any steps that terminated normally. If none of
the return code tests for these steps is satisfied, this job step is executed.

See “Considerations when Using the COND Parameter” on page 16-13 for
cautions related to the use of EVEN.

16-12 z/OS V1R3.0 MVS JCL Reference

 EXEC: COND
ONLY
Specifies that this job step is to be executed only if a preceding step
abnormally terminated. When ONLY is coded, the system:
v Does not test the return code of any steps that terminated abnormally.
v Does test the return code of any steps that terminated normally. If none of
the return code tests for these steps is satisfied, this job step is executed.

See “Considerations when Using the COND Parameter” for cautions related to
the use of ONLY.

Overrides
If you code the COND parameter on the JOB statement and on one or more of the
job’s EXEC statements, and if a return code test on the JOB statement is satisfied,
the job terminates. In this case, the system does not process any subsequent
EXEC statement COND parameters.

If the tests on the JOB statement are not satisfied, the system then performs the
return code tests on the EXEC statement. If a return code test is satisfied, the step
is bypassed.

Location in the JCL

You can specify the COND parameter on any EXEC statement in the job. However,
the system evaluates a COND parameter on the first EXEC statement in a job as
false.

On an EXEC Statement that Calls a Procedure

The COND parameter on an EXEC statement that calls a cataloged or in-stream
procedure (a calling EXEC statement) will either override or is added to the called
EXEC statements.

The COND on the calling EXEC statement overrides the COND on the called EXEC
statement. If the called EXEC statement does not have COND coded on it, the
COND on the calling EXEC statement will be added to the called EXEC statement.

If an EXEC statement calls a cataloged or in-stream procedure, the COND

parameter overrides the COND parameter on or is added to:
v The EXEC statement named in the procstepname qualifier, which is to the left of
the equals sign. The parameter applies only to the named procedure step. The
EXEC statement can have as many COND.procstepname parameters as the
procedure has steps; each COND parameter must specify a unique
procstepname.
v All EXEC statements in the procedure if procstepname is not coded. Then the
parameter applies to this job step and to all steps in the called procedure.

Considerations when Using the COND Parameter

Be aware of the following considerations when specifying COND parameters. Some
of these considerations relate to errors that prevent step execution, no matter what
is specified on the COND parameter, while others are related to the use of the
COND parameter.

Chapter 16. EXEC Statement 16-13

EXEC: COND
Errors that Prevent Step Execution, Regardless of COND
Specifications
Certain error conditions prevent the system from executing a step, regardless of
any requests specified through the COND parameter. These conditions are as
follows:

Abnormal Termination by the System

After certain types of abnormal termination by the system, remaining job steps are
not executed, regardless of whether EVEN or ONLY were specified. The completion
codes associated with these types of abnormal termination are:
122 Operator canceled job
222 Operator or TSO/E user canceled job

You might encounter other system completion codes for which remaining job steps
are not executed, regardless of whether EVEN or ONLY was specified. See z/OS
MVS System Codes for further information about specific system completion codes.

Backward References to Data Sets

If a step is bypassed because of its COND parameter or if a step abnormally

terminates, a data set that was to have been created or cataloged in the step may
not exist, may not be cataloged, or may be incomplete. Thus, a job step should not
refer to a data set being created or cataloged in a step that could be bypassed or
abnormally terminated. If the job step does make such a reference, the system
might not be able to execute the step.

When the Program Does Not Have Control

For the system to act on the COND parameter, the step must abnormally terminate
while the program has control. If a step abnormally terminates during scheduling,
due to failures such as JCL errors or the inability to allocate space, the system
bypasses the remaining steps, no matter what the COND parameter requests.

JES3 Considerations
In both JES2 and JES3 systems, an EXEC COND parameter determines if a step is
executed or bypassed. However, JES3 processes all jobs as though each step will
execute; therefore, JES3 allocates devices for steps that are bypassed. JES3 will
fail jobs that delete a data set in one step and attempt to reference the deleted data
set in a later step, even if the step that deletes the data set is bypassed during
execution. JES3 does not support conditional JCL, although it does permit
conditional statements to be specified.

COND Parameter on the First Statement in a Job

The system evaluates a COND parameter on the first EXEC statement in a job as
false. However, you can use an IF statement before the first EXEC statement in a
job to bypass the step. See Chapter 17, “IF/THEN/ELSE/ENDIF Statement
Construct” on page 17-1 for more information.

JOBLIB with COND=ONLY

If the job contains a JOBLIB DD statement and ONLY is specified in a job step, the
JOBLIB unit and volume information are not passed to the next step; when the next
step is executed, the system searches the catalog for the JOBLIB data set.

When the JOB Statement Contains a RESTART Parameter

When restarting a job, the restart step becomes, in effect, the first step in the job.
Therefore, the system evaluates a COND parameter on the restart step as false

16-14 z/OS V1R3.0 MVS JCL Reference

 EXEC: COND
and executes the step. Subsequent steps might be executed. When a COND
parameter on a step following the restarted step refers to a step that precedes the
restarted step, the system evaluates the COND parameter as false. If all other
COND parameters on that step are also false, the system executes the step. When
the JOB statement contains a RESTART parameter with a checkpoint id, the
system evaluates the COND parameter on the designated restart step as false and
executes the step.

Restarted Step COND Parameter Processing

The restarted step does not call a procedure The system evaluates any COND parameters on the restarted step
and is not a step within a procedure. as false, and executes the step.
The restarted step calls a procedure and does The system evaluates any COND parameters on the first step to be
not contain a COND parameter. executed within the procedure at restart as false, and executes the
step. Subsequent steps containing COND parameters are processed
normally.
The restarted step is within a procedure, and The system evaluates any COND parameters on the first step to be
the step that called the procedure does not executed within the procedure at restart as false, and executes the
contain a COND parameter. step. Subsequent steps containing COND parameters are processed
normally.
The restarted step calls a procedure, and the The system evaluates any COND parameters on the restarted step
restarted step contains a COND parameter as false, and executes the step. The system evaluates any COND
without a procstepname qualifier. parameters on steps within the called procedure as false, regardless
of whether they were overridden or added from the COND parameter
on the step that called the procedure.
The restarted step is within a procedure, and The system evaluates any COND parameters on the restarted step
the step that called the procedure contains a as false, and executes the step. Any subsequent steps within the
COND parameter without a procstepname procedure that contain COND parameters are processed normally.
qualifier.
The restarted step calls a procedure, and the The system evaluates any COND parameters on the first step to be
restarted step contains one or more COND executed within the procedure at restart as false, and executes the
parameters with procstepname qualifiers. step. Subsequent steps that contain COND parameters are
processed normally. COND parameters on these subsequent steps
are added or overridden as specified in the calling step.
The restarted step is within a procedure, and The system evaluates any COND parameters on the first step to be
the step that called the procedure contains executed within the procedure at restart as false, and executes the
one of more COND parameters with step. Subsequent steps that contain COND parameters are
procstepname qualifiers. processed normally. COND parameters on these subsequent steps
are added or overridden as specified in the calling step.

Summary of COND Parameters

Table 16-1. Execution or Bypassing of Current Step Based on COND Parameter
Return Code (RC) from a Previous Step
Test in COND Parameter Execute Current Step Bypass Current Step
COND=(code,GT) RC >= code RC < code
COND=(code,GE) RC > code RC <= code
COND=(code,EQ) RC ¬= code RC = code
COND=(code,LT) RC <= code RC > code
COND=(code,LE) RC < code RC >= code
COND=(code,NE) RC = code RC ¬= code
Note: When the COND parameter does not name a previous step, the system tests all
previous steps. If any test is satisfied, the system bypasses the current step.

Chapter 16. EXEC Statement 16-15

EXEC: COND

Table 16-2. Effect of EVEN and ONLY Subparameters on Step Execution

EVEN or ONLY Any Preceding Any Tests Current Step
Specified? Abend? Satisfied? Execute?
EVEN No No Yes
EVEN No Yes No
EVEN Yes No Yes
EVEN Yes Yes No
ONLY No No No
ONLY No Yes No
ONLY Yes No Yes
ONLY Yes Yes No
Neither No No Yes
Neither No Yes No
Neither Yes No No
Neither Yes Yes No

Examples of the COND Parameter

Example 1
//STEP6 EXEC PGM=DISKUTIL,COND=(4,GT,STEP3)

In this example, if the return code from STEP3 is 0 through 3, the system bypasses
STEP6. If the return code is 4 or greater, the system executes STEP6. Because
neither EVEN nor ONLY is specified, the system does not execute this step if a
preceding step abnormally terminates.

Example 2
//TEST2 EXEC PGM=DUMPINT,COND=((16,GE),(90,LE,STEP1),ONLY)

The system executes this step ONLY if two conditions are met:
1. A preceding job step abnormally terminated.
2. No return code tests are satisfied.

Therefore, the system executes this step only when all three of the following are
true:
v A preceding job step abnormally terminated.
v The return codes from all preceding steps are 17 or greater.
v The return code from STEP1 is 89 or less.

The system bypasses this step if any one of the following is true:
v All preceding job steps terminated normally.
v The return code from any preceding step is 0 through 16.
v The return code from STEP1 is 90 or greater.

Example 3
//STEP1 EXEC PGM=CINDY
.
.
//STEP2 EXEC PGM=NEXT,COND=(4,EQ,STEP1)
.
.
//STEP3 EXEC PGM=LAST,COND=((8,LT,STEP1),(8,GT,STEP2))
.

16-16 z/OS V1R3.0 MVS JCL Reference

 EXEC: COND
In this example, if STEP1 returns a code of 4, STEP2 is bypassed. Before STEP3
is executed, the system performs the first return code test. If 8 is less than the
return code from STEP1, STEP3 is bypassed; or, restated, if the STEP1 return
code is less than or equal to 8, STEP3 is executed. Because 4 is less than 8,
STEP3 is executed.

The system does not perform the second return code test because STEP2 was
bypassed.

Example 4
//STP4 EXEC PROC=BILLING,COND.PAID=((20,LT),EVEN),
// COND.LATE=(60,GT,FIND),
// COND.BILL=((20,GE),(30,LT,CHGE))

This statement calls cataloged or in-stream procedure BILLING. The statement

specifies different return code tests for each of the procedure steps: PAID, LATE,
and BILL. The system executes step PAID even if a preceding step abnormally
terminates unless the accompanying return code is satisfied.

Example 5

The procedure TEST exists in SYS1.PROCLIB:

//TEST PROC
//PROCSTP1 EXEC PGM=IEFBR14,COND=(0,NE)
//PROCSTP2 EXEC PGM=IEFBR14,COND=(0,NE)
//PROCSTP3 EXEC PGM=IEFBR14
//PROCSTP4 EXEC PGM=IEFBR14,COND=(4,LT)
// PEND

The job:
//JOB1 JOB...RESTART=JOBSTEP
//JOBSTEP EXEC PROC=TEST

JOB1 restarts at JOBSTEP. PROCSTP1 is the first step in the job because of the
RESTART specification, and the COND parameter test is not valid because no
previous steps have run. Therefore, the system evaluates the COND parameter for
PROCSTP1 as false, and PROCSTP1 runs. PROCSTP3 has no COND parameter.
The COND parameters for PROCSTP2 and PROCSTP4 are used.

The job:
//JOB1 JOB...RESTART=JOBSTEP.PROCSTP2
//JOBSTEP EXEC PROC=TEST,COND=(8,GT)

JOB1 restarts at PROCSTP2 as called by JOBSTEP. The COND parameter on

JOBSTEP does not specify a procstepname qualifier and therefore applies to all
steps in procedure TEST. The system evaluates the COND parameter for
PROCSTP2, the restart step, as false, and the step runs. However, the COND
parameter for steps PROCSTP3 and PROCSTP4 evaluates as true (because 8 is
greater than the return code of 0 provided by all previous steps in the job), and the
steps are bypassed.

The job:
//JOB1 JOB...RESTART=JOBSTEP.PROCSTP2
//JOBSTEP EXEC PROC=TEST,COND.PROCSTP4=(8,GT)

JOB1 restarts at PROCSTP2 as called by JOBSTEP. Because of the RESTART

specification, PROCSTP2 is the first step in the job. The system evaluates the

Chapter 16. EXEC Statement 16-17

EXEC: COND
COND parameter for PROCSTP2 as false, and the step runs. PROCSTP3 has no
COND parameter. PROCSTP4 is overridden as specified on JOBSTEP.

DYNAMNBR Parameter
Parameter Type

Keyword, optional

Purpose

Use the DYNAMNBR parameter to tell the system to hold a number of resources in
anticipation of reuse. Code DYNAMNBR instead of several DD statements with
DYNAM parameters.

Syntax
DYNAMNBR[.procstepname]=n

Subparameter Definition
n Specifies a value used to calculate the maximum number of data set allocations
that the system can hold in anticipation of reuse. Specify n as a decimal
number from 0 through 3273 minus the number of DD statements in the step.
Note that the limit of 3273 is based on the number of single unit DD statements
for a 64K TIOT (task input output table). This limit can be different depending
on the installation-defined TIOT size. 32K is the default TIOT size. The limit for
a 32K TIOT is 1635. (In a JES3 system, the installation might further reduce the
limit.)

Note: If you specify DISP=(NEW,PASS) but, at the end of the job, one or more
data sets were not received by any job step, then the maximum number
of DD statements you can specify decreases by one. For example, if the
current limit is 1635 DD statements, you can specify DISP=(NEW,PASS),
and up to 1634 DD statements.

The number of resources that the system actually holds in anticipation of reuse
equals n plus the number of DD statements in the step, including any DD
statements in a cataloged or in-stream procedure called by the step.

Defaults
If no DYNAMNBR parameter is specified, the default is 0. If you code DYNAMNBR
incorrectly, the system uses the default of 0 and issues a JCL warning message.

On an EXEC Statement that Calls a Procedure

If this EXEC statement calls a cataloged or in-stream procedure, the DYNAMNBR
parameter overrides the DYNAMNBR parameter on or is added to:
v The EXEC statement named in the procstepname qualifier. The parameter
applies only to the named procedure step. The EXEC statement can have as
many DYNAMNBR.procstepname parameters as the procedure has steps; each
DYNAMNBR parameter must specify a unique procstepname.

16-18 z/OS V1R3.0 MVS JCL Reference

 EXEC: DYNAMNBR
v All EXEC statements in the procedure if procstepname is not coded. Then the
parameter applies to all steps in the called procedure.

Example of the DYNAMNBR Parameter

//STEP1 EXEC PROC=ACCT,DYNAMNBR.CALC=12

For the procedure step CALC, this statement specifies that the system should hold
the following data set allocations for reuse: 12 plus the number of DD statements
following this EXEC statement and the number of DD statements in procedure
ACCT.

MEMLIMIT Parameter
Parameter Type

Keyword, optional

Purpose

Use the MEMLIMIT parameter to specify the limit on the total number of usable
virtual pages above the bar in a single address space.

Syntax
MEMLIMIT={nnnnnM}
{nnnnnG}
{nnnnnT}
{nnnnnP}
{NOLIMIT}

Subparameter Definition
nnnnnM
nnnnnG
nnnnnT
nnnnnP
Specifies a value to be used as the limit on the total number of usable virtual
pages above the bar in a single address space. The value may be expressed in
megabytes (M), gigabytes (G), terabytes (T), or petabytes (P). nnnnn may be a
value from 0 to 99999.
NOLIMIT
Specifies that there is no limit on the virtual pages to be used above the bar.

Defaults
If no MEMLIMIT parameter is specified, the default is the value defined to SMF.

Overrides
The JOB statement MEMLIMIT parameter applies to all steps of the job and
overrides any EXEC statement MEMLIMIT parameter.

If MEMLIMIT is not specified, SMF provides a default value. The IEFUSI installation
exit can override any JCL- or SMF-supplied value.

Chapter 16. EXEC Statement 16-19

EXEC: MEMLIMIT
Example of the MEMLIMIT Parameter
//STEPA EXEC PGM=ADDER,MEMLIMIT=10000M

This job step specifies a limit of 10000 megabytes of usable virtual pages above the
bar, depending on other job and installation factors.

PARM Parameter
Parameter Type

Keyword, optional

Purpose

Use the PARM parameter to pass variable information to the processing program
executed by this job step. To use the information, the processing program must
contain instructions to retrieve the information.

References

For details on the format of the passed information and its retrieval, see z/OS MVS
Programming: Assembler Services Guide.

Syntax
PARM[.procstepname]=subparameter
PARM[.procstepname]=(subparameter,subparameter)
PARM[.procstepname]=(’subparameter’,subparameter)
PARM[.procstepname]=’subparameter,subparameter’

Length: The length of the subparameters passed must not exceed 100 characters:
v Including any commas, which are passed to the processing program.
v Excluding any enclosing parentheses or apostrophes, which are not passed.

For example, PARM='P1,123,MT5' is received by the program as P1,123,MT5.

Commas: When you code more than one subparameter, separate the subparameters by
commas and enclose the subparameters in parentheses or apostrophes. For example,
PARM=(P1,123,MT5) or PARM='P1,123,MT5'.

Special Characters and Blanks: When a subparameter contains special characters or

blanks, enclose it in apostrophes and the other subparameters in parentheses, or enclose
all the subparameters in apostrophes. For example, PARM=(P50,'12+80') or
PARM='P50,12+80'.

Code each apostrophe and ampersand that is part of the subparameter as two consecutive
apostrophes or ampersands. For example, code 3462&5 as PARM='3462&&5'.

However, if a subparameter contains a symbolic parameter, code a single ampersand. You

can code the symbolic parameter in apostrophes.

Continuation onto Another Statement: Enclose the subparameters in parentheses. End

each statement with a comma after a subparameter. For example:
//STEP1 EXEC PGM=WORK,PARM=(DECK,LIST,’LINECNT=80’,
// ’12+80’,NOMAP)

Do not code an apostrophe in column 71; see ″Continuing Parameter Fields Enclosed in
Apostrophes″ if you need more information.

16-20 z/OS V1R3.0 MVS JCL Reference

 EXEC: PARM
Subparameter Definition
subparameter
Consists of the information to be passed to the processing program.

On an EXEC Statement that Calls a Procedure

If an EXEC statement calls a cataloged or in-stream procedure, the PARM
parameter overrides the PARM parameter on or is added to:
v The EXEC statement named in the procstepname qualifier. The information
applies only to the named procedure step. The EXEC statement can have as
many PARM.procstepname parameters as the procedure has steps; each PARM
parameter must specify a unique procstepname.
v The first EXEC statement in the procedure if procstepname is not coded; the
system nullifies any PARM parameters on any following EXEC statements in
the procedure. The information applies to only the first step in the called
procedure.

Examples of the PARM Parameter

Example 1
//RUN3 EXEC PGM=APG22,PARM=’P1,123,P2=5’

The system passes P1,123,P2=5 to the processing program named APG22.

Example 2
// EXEC PROC=PROC81,PARM=MT5

The system passes MT5 to the first step of the procedure named PROC81. If
PROC81 contains more steps and their EXEC statements contain PARM
parameters, the system nullifies those PARM parameters.

Example 3
//STP6 EXEC PROC=ASMFCLG,PARM.LKED=(MAP,LET)

The system passes MAP,LET to the procedure step named LKED in procedure
ASMFCLG. If any other procedure steps in ASMFCLG contain a PARM parameter,
those PARM parameters remain in effect.

Example 4
//RUN4 EXEC PGM=IFOX00,PARM=(NOOBJECT,’LINECNT=50’, ’TRUNC(BIN)’,
// DECK)

The system passes NOOBJECT,LINECNT=50,TRUNC(BIN),DECK to processing

program IFOX00. Because the PARM parameter contains a list of more than one
subparameter, the information is enclosed in parentheses.

PERFORM Parameter
Parameter Type

Keyword, optional

Purpose

Chapter 16. EXEC Statement 16-21

EXEC: PERFORM
Use the PERFORM parameter in WLM compatibility mode to specify the
performance group for the job step. The installation-defined performance groups
determine the rate at which associated steps have access to the processor,
storage, and channels.

In WLM goal mode, any PERFORM parameter on an EXEC statement for a job or
a started procedure is ignored. However, for a TSO session, a PERFORM
parameter specified on the EXEC statement of the TSO logon procedure, or
entered on the TSO logon panel, can be used for classification of the session to a
service class or report class. For details on how to use workload management
classification rules to map a PERFORM value to a service class or report class, see
z/OS MVS Planning: Workload Management.

Syntax
PERFORM[.procstepname]=n

Subparameter Definition
n The n is a number from 1 through 999.
In WLM compatibility mode, n identifies a performance group that has been
defined by your installation. The specified performance group should be
appropriate for your step type according to your installation’s rules.

Defaults
In WLM compatibility mode, if no PERFORM parameter is specified or if the
specified PERFORM number fails validity checks, the system uses an installation
default specified at initialization. If the installation did not specify a default, the
system uses a built-in default:

Default Use
1 For non-TSO/E job steps
2 For TSO/E sessions

See z/OS MVS Initialization and Tuning Guide for details.

Overrides
A JOB statement PERFORM parameter applies to all steps of the job and overrides
any EXEC statement PERFORM parameters.

Code EXEC statement PERFORM parameters when each job step is to execute in
a different performance group. The system uses an EXEC PERFORM parameter
only when no PERFORM parameter is on the JOB statement and only during the
job step.

On an EXEC Statement that Calls a Procedure

If an EXEC statement calls a cataloged or in-stream procedure, the PERFORM
parameter overrides the PERFORM parameter on or is added to:
v The EXEC statement named in the procstepname qualifier. The parameter
applies only to the named procedure step. The EXEC statement can have as

16-22 z/OS V1R3.0 MVS JCL Reference

 EXEC: PERFORM
many PERFORM.procstepname parameters as the procedure has steps; each
PERFORM parameter must specify a unique procstepname.
v All EXEC statements in the procedure if procstepname is not coded. Then the
parameter applies to all steps in the called procedure.

Example of the PERFORM Parameter

//STEPA EXEC PGM=ADDER,PERFORM=60

This job step will be run in performance group 60 if it passes validity checks. The
installation must have defined the significance of this performance group.

PGM Parameter
Parameter Type

Positional, optional

Purpose

Use the PGM parameter to name the program that the system is to execute. The
specified program must be a member of a partitioned data set (PDS) or partitioned
data set extended (PDSE) used as a system library, a private library, or a temporary
library.

Syntax
PGM= {program-name }
{*.stepname.ddname }
{*.stepname.procstepname.ddname}
{JCLTEST }
{JSTTEST }

The EXEC statement parameter field must begin with a PGM parameter or a PROC
parameter. These two parameters must not appear on the same EXEC statement.

Subparameter Definition
program-name
Specifies the member name or alias of the program to be executed. The
program-name is 1 through 8 alphanumeric or national ($, #, @) characters; the
first character must be alphabetic or national.
Use this form of the parameter when the program resides in a system library,
such as SYS1.LINKLIB, or in a private library specified in the job by a JOBLIB
DD statement or in the step by a STEPLIB DD statement.
*.stepname.ddname
Refers to a DD statement that defines, as a member of a partitioned data set
(PDS) or a partitioned data set extended (PDSE), the program to be executed.
Stepname identifies the EXEC statement of the earlier job step that contains the
DD statement with ddname in its name field.
Use this form of the parameter when a previous job step creates a temporary
library to store a program until it is required.

Chapter 16. EXEC Statement 16-23

EXEC: PGM
When referring to a DD statement, the system does not honor requests for
special program properties as defined in the program properties table (PPT).
(See z/OS MVS Initialization and Tuning Reference.)
*.stepname.procstepname.ddname
Refers to a DD statement that defines, as a member of a partitioned data set
(PDS) or a partitioned data set extended (PDSE), the program to be executed.
The DD statement is in a cataloged or in-stream procedure that is called by an
earlier job step. Stepname identifies the EXEC statement of the calling job step;
procstepname identifies the EXEC statement of the procedure step that
contains the DD statement with ddname in its name field.
Use this form of the parameter when a previous job step calls a procedure that
creates a temporary library to store a program until it is required.
When referring to a DD statement, the system does not honor requests for
special program properties as defined in the program properties table (PPT).
(See z/OS MVS Initialization and Tuning Reference.)
JCLTEST (JES3 only)
JSTTEST (JES3 only)
Requests that the system scan the step’s job control statements for syntax
errors without executing the job or allocating devices. JCLTEST or JSTTEST
provides for a step the same function as provided by the JOB statement
TYPRUN=SCAN parameter for a job. See z/OS JES3 Commands for details.

Note: JCLTEST and JSTTEST are supported only in JES3 systems.

Examples of the PGM Parameter

Example 1
//JOB8 JOB ,BOB,MSGLEVEL=(2,0)
//JOBLIB DD DSNAME=DEPT12.LIB4,DISP=(OLD,PASS)
//STEP1 EXEC PGM=USCAN

These statements indicate that the system is to search the private library
DEPT12.LIB4 for the member named USCAN, read the member into storage, and
execute the member.

Example 2
//PROCESS JOB ,MARY,MSGCLASS=A
//CREATE EXEC PGM=IEWL
//SYSLMOD DD DSNAME=&&PARTDS(PROG),UNIT=3350,DISP=(MOD,PASS),
// SPACE=(1024,(50,20,1))
//GO EXEC PGM=*.CREATE.SYSLMOD

The EXEC statement named GO contains a backward reference to DD statement

SYSLMOD, which defines a library created in the step named CREATE. Program
PROG is a member of the partitioned data set &&PARTDS, which is a temporary
data set. Step GO executes program PROG. The data set &&PARTDS is deleted at
the end of the job.

Example 3
//JOBC JOB ,JOHN,MSGCLASS=H
//STEP2 EXEC PGM=UPDT
//DDA DD DSNAME=SYS1.LINKLIB(P40),DISP=OLD
//STEP3 EXEC PGM=*.STEP2.DDA

16-24 z/OS V1R3.0 MVS JCL Reference

 EXEC: PGM
The EXEC statement named STEP3 contains a backward reference to DD
statement DDA, which defines system library SYS1.LINKLIB. Program P40 is a
member of SYS1.LINKLIB; STEP3 executes program P40.

PROC and Procedure Name Parameters

Parameter Type

Positional, optional

Purpose

Use the PROC parameter to specify that the system is to call and execute a
cataloged or in-stream procedure.

Syntax
{PROC=procedure-name}
{procedure-name }

v The EXEC statement parameter field must begin with a PGM parameter or a PROC
parameter. These two parameters must not appear on the same EXEC statement.
v You can omit PROC= and code only the procedure-name.

Subparameter Definition
procedure-name
Identifies the procedure to be called and executed:
v The member name or alias of a cataloged procedure.
v The name on the PROC statement that begins an in-stream procedure. The
in-stream procedure must appear earlier in this job.

The procedure-name is 1 through 8 alphanumeric or national ($, #, @)

characters; the first character must be alphabetic or national.

Effect of PROC Parameter on Other Parameters and Following

Statements
Because this EXEC statement calls a cataloged or in-stream procedure, the other
parameters on the statement are added to or override corresponding parameters on
the EXEC statements in the called procedure. See the descriptions of the other
parameters for details of their effects.

Any DD statements following this EXEC statement are added to the procedure, or
override or nullify corresponding DD statements in the procedure.

Examples of the PROC Parameter

Example 1
//SP3 EXEC PROC=PAYWKRS

This statement calls the cataloged or in-stream procedure named PAYWKRS.

Example 2

Chapter 16. EXEC Statement 16-25

EXEC: PROC and Procedure Name
//BK EXEC OPERATE

This statement calls the cataloged or in-stream procedure named OPERATE.

RD Parameter
Parameter Type

Keyword, optional

Purpose

Use the RD (restart definition) parameter to:

v Specify that the system is to allow the operator the option of performing
automatic step or checkpoint restart if a job step abends with a restartable abend
code. (See the SCHEDxx parmlib member description in z/OS MVS Initialization
and Tuning Guide for information about restartable abends.)
v Allow JES to perform automatic step restart after a system failure even if the
journal option is not specified in the JES initialization parameters or JES control
statements.
v Suppress, partially or totally, the action of the assembler language CHKPT macro
instruction or the DD statement CHKPT parameter.

The system can perform automatic restart only if all of the following are true:
v The JOB or EXEC statement contains RD=R or RD=RNC.
v The step to be restarted abended with a restartable wait state code.
v The operator authorizes a restart.

The system can perform automatic step restart for a job running during a system
failure as long as the job has a job journal.

A job journal is a sequential data set that contains job-related control blocks needed
for restart. If you use the automatic restart manager (ARM) to restart a job, you do
not need to save the journal because ARM does not use the job journal when
restarting jobs.

For JES2, specify a job journal by one of the following:

v JOURNAL=YES on the CLASS statement in the JES2 initialization parameters.
v RD=R or RD=RNC on either the JOB statement or any one EXEC statement in
the job.

For JES3, specify a job journal in one of the following:

v JOURNAL=YES on the CLASS statement in the JES3 initialization parameters.
v RD=R or RD=RNC on either the JOB statement or any one EXEC statement in
the job.
v JOURNAL=YES on a JES3 //*MAIN statement in the job.

References

For detailed information on deferred checkpoint restart, see z/OS DFSMS

Checkpoint/Restart.

Considerations for an APPC Scheduling Environment

16-26 z/OS V1R3.0 MVS JCL Reference

 EXEC: RD
The RD parameter has no function in an APPC scheduling environment. If you code
RD, the system will check it for syntax and ignore it.

Syntax
RD[.procstepname]= {R }
{RNC}
{NR }
{NC }

Subparameter Definition
R (Restart, Checkpoints Allowed)
Indicates that the operator can perform automatic step restart if the job step
fails.
RD=R does not suppress checkpoint restarts:
v If the processing program executed in a job step does not include a CHKPT
macro instruction, RD=R allows the system to restart execution at the
beginning of the abnormally terminated step.
v If the program includes a CHKPT macro instruction, RD=R allows the system
to restart execution at the beginning of the step, if the step abnormally
terminates before the CHKPT macro instruction is executed.
v If the step abnormally terminates after the CHKPT macro instruction is
executed, only checkpoint restart can occur. If you cancel the affects of the
CHKPT macro instruction before the system performs a checkpoint restart,
the request for automatic step restart is again in effect.
RNC (Restart, No Checkpoints)
Indicates that the operator can perform automatic step restart if the job step
fails.
RD=RNC suppresses automatic and deferred checkpoint restarts. It
suppresses:
v Any CHKPT macro instruction in the processing program: That is, the
operator cannot perform an automatic checkpoint restart, and the system is
not to perform a deferred checkpoint restart if the job is resubmitted.
v The DD statement CHKPT parameter.
v The checkpoint at end-of-volume (EOV) facility.
NR (No Automatic Restart, Checkpoints Allowed)
Indicates that the operator cannot perform automatic step restart if the job fails.
RD=NR suppresses automatic checkpoint restart but permits deferred
checkpoint restarts. It permits:
v A CHKPT macro instruction to establish a checkpoint.
v The job to be resubmitted for restart at the checkpoint. On the JOB
statement when resubmitting the job, specify the checkpoint in the RESTART
parameter.

If you code RD=NR and the system fails, RD=NR does not prevent the job from
restarting.
NC (No Automatic Restart, No Checkpoints)
Indicates that the operator cannot perform automatic step restart if the job step
fails.

Chapter 16. EXEC Statement 16-27

EXEC: RD
RD=NC suppresses automatic and deferred checkpoint restarts. It suppresses:
v Any CHKPT macro instruction in the processing program.
v The DD statement CHKPT parameter.
v The checkpoint at EOV facility.

Defaults
If you do not code the RD parameter, the system uses the installation default from
the job’s job class specified at initialization.

Overrides
v A JOB statement RD parameter applies to all steps of the job and overrides any
EXEC statement RD parameters.
When no RD parameter is on the JOB statement, the system uses an EXEC
statement RD parameter, but only during the job step. Code EXEC statement RD
parameters when you want to specify different restart types for each job step.
v A request by a CHKPT macro instruction for an automatic checkpoint restart
overrides a request by a JOB or EXEC statement RD=R parameter for automatic
step restart.

Relationship to Other Control Statements

Code RD=NC or RD=RNC to suppress the action of the DD statement CHKPT
parameter.

On an EXEC Statement that Calls a Procedure

If an EXEC statement calls a cataloged or in-stream procedure, the RD parameter
is added to or overrides the RD parameter on:
v The EXEC statement named in the procstepname qualifier. The information
applies only to the named procedure step. The EXEC statement can have as
many RD.procstepname parameters as the procedure has steps; each RD
parameter must specify a unique procstepname.
v All EXEC statements in the procedure if procstepname is not coded. Then the
parameter applies to all steps in the called procedure.

Examples of the RD Parameter

Example 1
//STEP1 EXEC PGM=GIIM,RD=R

RD=R specifies that the operator can perform automatic step restart if the job step
fails.

Example 2
//NEST EXEC PGM=T18,RD=RNC

RD=RNC specifies that, if the step fails, the operator can perform automatic step
restart. RD=RNC suppresses automatic and deferred checkpoint restarts.

Example 3
//CARD EXEC PGM=WTE,RD=NR

RD=NR specifies that the operator cannot perform automatic step restart or
automatic checkpoint restart. However, a CHKPT macro instruction can establish
checkpoints to be used later for a deferred restart.

16-28 z/OS V1R3.0 MVS JCL Reference

 EXEC: RD
Example 4
//STP4 EXEC PROC=BILLING,RD.PAID=NC,RD.BILL=NR

This statement calls a cataloged or in-stream procedure BILLING. The statement

specifies different restart requests for each of the procedure steps: PAID and BILL.

REGION Parameter
Parameter Type

Keyword, optional

Purpose

Use the REGION parameter to specify the amount of central or virtual storage that
the step requires.

The amount of storage that you request must include the following:
v Storage for all programs in the step to execute.
v All additional storage that the programs in the step request with GETMAIN,
STORAGE, and CPOOL macro instructions.
v Enough unallocated storage for task initialization and termination. Task
initialization and termination can issue GETMAIN macro instructions for storage
in the user’s address space.

Two installation exits, IEFUSI and IEALIMIT, can also affect the size of the user
address space assigned to the job step.

References

For more information on address space size, see ″Resource Control of Address
Space″ in z/OS MVS JCL User’s Guide. For more information on region size with
checkpoint/restart jobs, see z/OS DFSMS Checkpoint/Restart.

Syntax
REGION[.procstepname]= {valueK}
{valueM}

Subparameter Definition
valueK
Specifies the required storage in kilobytes (1 kilobyte = 1024 bytes). The value
is 1 through 7 decimal numbers, from 1 through 2096128. Code a multiple of 4.
For example, code REGION=68K. If the value you code is not a multiple of 4,
the system will round it up to the next multiple of 4.

Note: Specifying a REGION size that gives the STEP all the available storage,
such as 0K or any value greater than 16,384K, can cause storage
problems if the IBM- or installation-supplied routine IEALIMIT or IEFUSI
is not used to establish a limiting value.

Chapter 16. EXEC Statement 16-29

EXEC: REGION
valueM
Specifies the required storage in megabytes (1 megabyte = 1024 kilobytes).
The value is 1 through 4 decimal numbers, from 1 through 2047. For example,
REGION=3M.

Note: Specifying a REGION size that gives the STEP all the available storage,
such as 0M or any value greater than 16M, can cause storage problems
if the IBM- or installation-supplied routine IEALIMIT or IEFUSI is not
used to establish a limiting value.

Defaults
If no REGION parameter is specified, the system uses an installation default
specified at JES initialization.

If your installation does not change the IBM-supplied default limits in the IEALIMIT
or IEFUSI exit routine modules, then specifying various values for the region size
have the following results:
v A value equal to 0K or 0M — gives the job step all the storage available below
and above 16 megabytes. The resulting size of the region below and above 16
megabytes depends on system options and what system software is installed.
v A value greater than 0K or 0M and less than or equal to 16,384K or 16M —
establishes the size of the private area below 16 megabytes. If the region size
specified is not available below 16 megabytes, the job step abnormally
terminates. The extended region size is the default value of 32 megabytes.
v A value greater than 16,384K or 16M and less than or equal to 32,768K or 32M
— gives the job step all the storage available below 16 megabytes. The resulting
size of the region below 16 megabytes depends on system options and what
system software is installed. The extended region size is the default value of 32
megabytes.
v A value greater than 32,768K or 32M and less than or equal to 2,096,128K or
2047M — gives the job step all the storage available below 16 megabytes. The
resulting size of the region below 16 megabytes depends on system options and
what system software is installed. The extended region size is the specified
value. If the region size specified is not available above 16 megabytes, the job
step abnormally terminates.

Overrides
A JOB statement REGION parameter applies to all steps of the job and overrides
any EXEC statement REGION parameters.

When no REGION parameter is on the JOB statement, the system uses an EXEC
statement REGION parameter, but only during the job step. Code EXEC statement
REGION parameters when you want to specify a different region size for each job
step.

Relationship to the EXEC ADDRSPC Parameter

When ADDRSPC=REAL

Code a REGION parameter to specify how much central storage (also called real
storage) the step needs.

When ADDRSPC=VIRT or ADDRSPC is Omitteda

16-30 z/OS V1R3.0 MVS JCL Reference

 EXEC: REGION
Code a REGION parameter to specify how much virtual storage the step needs.

On an EXEC Statement that Calls a Procedure

If an EXEC statement calls a cataloged or in-stream procedure, the REGION
parameter is added to or overrides the REGION parameter on:
v The EXEC statement named in the procstepname qualifier. The information
applies only to the named procedure step. The EXEC statement can have as
many REGION.procstepname parameters as the procedure has steps; each
REGION parameter must specify a unique procstepname.
v All EXEC statements in the procedure if procstepname is not coded. Then the
parameter applies to all steps in the called procedure.

Examples of the REGION Parameter

Example 1
//MKBOYLE EXEC PROC=A,ADDRSPC=REAL,REGION=40K

The system assigns 40K bytes of central (real) storage to this job step.

Example 2
//STP6 EXEC PGM=CONT,REGION=120K

The system assigns a region of 120K bytes. When the ADDRSPC parameter is not
specified, the system defaults to ADDRSPC=VIRT.

TIME Parameter
Parameter Type

Keyword, optional

Purpose

Use the TIME parameter to specify the maximum amount of time that a job step
may use the processor or to find out through messages how much processor time a
step used.

You can use the TIME parameter on an EXEC statement to increase or decrease
the amount of processor time available to a job step over the default value.

A step that exceeds its allotted time abnormally terminates and causes the job to
terminate, unless an installation exit routine extends the time for the job. The exit
routine IEFUTL is established through System Management Facilities (SMF).

References

See “TIME Parameter” on page 20-47 (the TIME parameter on the JOB statement)
or z/OS MVS Installation Exits.

Chapter 16. EXEC Statement 16-31

EXEC: TIME
Syntax
TIME[.procstepname]= {([minutes][,seconds])}
{1440 }
{NOLIMIT }
{MAXIMUM }
{0 }
You can omit the parentheses if you code only 1440, 0, or the processor time in minutes.

Subparameter Definition
minutes
Specifies the maximum number of minutes the step can use the processor.
Minutes must be a number from 0 through 357912 (248.55 days).
seconds
Specifies the maximum number of seconds that the step can use the processor,
in addition to any minutes that are specified. Seconds must be a number from 0
through 59.
1440 or NOLIMIT
Indicates that the step can use the processor for an unlimited amount of time.
(″1440″ literally means ″24 hours.″)
Also code TIME=1440 or TIME=NOLIMIT to specify that the system is to allow
this step to remain in a continuous wait state for more than the installation time
limit, which is established through SMF.
MAXIMUM
Indicates that the step can use the processor for the maximum amount of time.
Coding TIME=MAXIMUM allows the step to run for 357912 minutes.
0 Indicates that the step is to use the time remaining from the previous step. If
the step exceeds the remaining time available, the step abnormally terminates.

Defaults
Each job step has a time limit. If you do not specify a TIME parameter on the JOB
statement, the time limit for any job step is:
v The value you specify for the TIME parameter on its EXEC statement, or
v The default time limit (that is, the JES default job step time limit), if you do not
specify a TIME parameter on its EXEC statement.

Overrides
If you specify either MAXIMUM or a value in minutes or seconds other than 1440
for the JOB statement TIME parameter, the system can reduce the processor time
available to a job step. In those two cases, the system sets the time limit for the
step to the smaller of the two following values:
v The job time remaining after all previous job steps have completed.
v The time limit that was specified or the default time limit.

See “Defaults” for an explanation of default time limits.

On an EXEC Statement that Calls a Procedure

If an EXEC statement calls a cataloged or in-stream procedure, the TIME
parameter is added to or overrides the TIME parameter on:

16-32 z/OS V1R3.0 MVS JCL Reference

 EXEC: TIME
v The EXEC statement named in the procstepname qualifier. The information
applies only to the named procedure step. The EXEC statement can have as
many TIME.procstepname parameters as the procedure has steps; each TIME
parameter must specify a unique procstepname.
If procstepname is not coded, the TIME parameter applies to the entire procedure
and nullifies any TIME parameters on EXEC statements in the procedure. For
example, suppose you specify TIME=5 on an EXEC statement that calls a
procedure. The first step in the procedure is allowed 5 minutes, the second step is
allowed 5 minutes minus the time used by the first step, the third step is allowed 5
minutes minus the time used by the first and second steps, and so forth, regardless
of any TIME parameter values on EXEC statements in the procedure.

TIME=1440 and TIME=NOLIMIT also nullify any TIME parameters on EXEC

statements in the procedure. Specifying TIME=1440 or TIME=NOLIMIT on the
calling EXEC statement allows the procedure to have unlimited processor time.

Examples of the TIME Parameter

For examples of TIME coded on both the JOB and EXEC statements, see
“Examples of the TIME Parameter on JOB and EXEC Statements” on page 20-49.

Example 1
//STEP1 EXEC PGM=GRYS,TIME=(12,10)

This statement specifies that the maximum amount of time the step can use the
processor is 12 minutes, 10 seconds.

Example 2
//FOUR EXEC PGM=JPLUS,TIME=(,30)

This statement specifies that the maximum amount of time the step can use the
processor is 30 seconds.

Example 3
//INT EXEC PGM=CALC,TIME=5

This statement specifies that the maximum amount of time the step can use the
processor is 5 minutes.

Example 4
//LONG EXEC PGM=INVANL,TIME=NOLIMIT

This statement specifies that the step can have unlimited use of the processor.
Therefore, the step can use the processor and can remain in a wait state for an
unspecified period of time, if not restricted by the JOB statement TIME parameter.

Example 5
//STP4 EXEC PROC=BILLING,TIME.PAID=(45,30),TIME.BILL=(112,59)

This statement calls cataloged or in-stream procedure BILLING. The statement

specifies different time limits for each of the procedure steps: PAID and BILL.

Example 6
//STP6 EXEC PGM=TIMECARD,TIME=MAXIMUM

Chapter 16. EXEC Statement 16-33

EXEC: TIME
This statement specifies that the step can use the processor for 357912 minutes, if
not restricted by the JOB statement TIME parameter.

Example 7
//TEST1 JOB MSGLEVEL=(1,1)
//STEP1 EXEC PGM=USES40,TIME=(,50)
//STEP2 EXEC PGM=USESREST,TIME=0

STEP1 can use the processor for 50 seconds. If STEP1 actually uses the processor
for only 40 seconds, STEP2 can use the processor for 10 seconds, because that is
the time remaining from the previous step.

Example 8
//TEST1 JOB MSGLEVEL=(1,1),TIME=(,50)
//STEP1 EXEC PGM=USES15,TIME=(,25)
//STEP2 EXEC PGM=USES30,TIME=(,40)
//STEP3 EXEC PGM=USESREST,TIME=0

STEP1 can use the processor for 25 seconds. If STEP1 actually uses the processor
for only 15 seconds, the time limit for STEP2 is the smaller of the following values:
v The job time remaining (35 seconds)
v The time limit specified on the EXEC statement for STEP2 (40 seconds).

In this case, the job time remaining is the smaller value, so STEP2 can use the
processor for 35 seconds. If STEP2, then, actually uses the processor for only 30
seconds, STEP3 can use the processor for 5 seconds, because that is the time
remaining from the previous step.

Example 9
//TEST2 JOB MSGLEVEL=(1,1),TIME=8,CLASS=5
//STEP1 EXEC PGM=USES4
//STEP2 EXEC PGM=USESREST

Assume that the default time limit for class 5 is 5 minutes. The time limit for STEP1
is 5 minutes (the default). If STEP1 actually uses the processor for 4 minutes, the
time limit for STEP2 is the smaller of the following values:
v The job time remaining (4 minutes)
v The default time limit (5 minutes).

In this case, the job time remaining is the smaller value, so STEP2 can use the
processor for 4 minutes.

16-34 z/OS V1R3.0 MVS JCL Reference

Chapter 17. IF/THEN/ELSE/ENDIF Statement Construct
This topic describes the IF/THEN, ELSE, and ENDIF statements, collectively called
the IF/THEN/ELSE/ENDIF statement construct.

Purpose

Use the IF/THEN/ELSE/ENDIF statement construct to conditionally execute job

steps within a job.

The IF statement is always followed by a relational-expression and a THEN clause.

Optionally, an ELSE clause can follow the THEN clause. An ENDIF statement
always follows the ELSE clause, if present, or the THEN clause.
v The THEN clause specifies the job steps that the system processes when the
evaluation of the relational-expression for the IF statement is a true condition.
The system evaluates the relational-expression at execution time.
v The ELSE clause specifies the job steps that the system processes when the
evaluation of the relational-expression for the IF statement is a false condition.
v The ENDIF statement indicates the end of the IF/THEN/ELSE/ENDIF statement
construct, and must be coded for each construct.

You can nest IF/THEN/ELSE/ENDIF statement constructs up to a maximum of 15

levels. The steps that execute in a THEN clause and an ELSE clause can be
another IF/THEN/ELSE/ENDIF statement construct.

Description

Syntax
//[name] IF [(]relational-expression[)] THEN [comments]
.
. action when relational-expression is true
.
//[name] ELSE [comments]
.
. action when relational-expression is false
.
//[name] ENDIF [comments]

The IF statement consists of the characters // in columns 1 and 2 and the five fields: name,
operation (IF), the relational-expression, the characters THEN, and comments. The
relational-expression can be enclosed in parentheses.

The ELSE statement consists of the characters // in columns 1 and 2 and the three fields:
name, operation (ELSE), and comments.

The ENDIF statement consists of the characters // in columns 1 and 2 and the three fields:
name, operation (ENDIF), and comments.

Name Field
A name is optional on IF/THEN, ELSE, and ENDIF statements. If used, code it as
follows:
v The name should be unique within the job.
v The name must begin in column 3.

© Copyright IBM Corp. 1988, 2002 17-1

 IF/THEN/ELSE/ENDIF
v The name is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The name must be followed by at least one blank.
| v The name may be preceded by up to 8 alphanumeric or national characters, and
| then separated by a period. Coding the name in this way should not be confused
| with specifying an override, as can be done when coding DD statements.

If a name is not coded, column 3 must be blank.

Operation Field
The operation field consists of the characters IF, ELSE, or ENDIF and must be
preceded and followed by at least one blank. It can begin in any column.

Relational-Expression Field
The relational-expression field follows the IF operation field after at least one
intervening blank and is followed by at least one blank before the characters THEN.
For example, to test that a return code is greater than 4, code:
// IF RC > 4 THEN

You can enclose the relational-expression in parentheses. For example:

// IF (RC > 4) THEN

A relational-expression indicates the condition that the system evaluates. The result
of the evaluation of the relational-expression always depends on two factors: the
operation specified, and the values of the operands or expressions that are
compared at execution time. The result of evaluating a relational-expression is
either true or false.

If you specify a stepname as part of a relational-expression, the system first

determines whether the step executed. If the step did not execute, the evaluation of
the relational-expression is false.

Continuing a Relational Expression

You can continue relational-expressions on the next JCL statement. Break the
relational-expression where a blank is valid on the current statement, and continue
the expression beginning in column 4 through 16 of the next statement. Do not put
comments on the statement that you are continuing. You can code comments after
you have completed the statement. For example:
//TESTCON IF (RC = 8 | RC = 10 | RC = 12 |
// RC = 14) THEN COMMENTS OK HERE
.
.

A relational-expression consists of:

v Comparison operators
v Logical operators
v NOT (¬) operators
v Relational-expression keywords.

Priorities of Operators
The operators that you can use in a relational-expression and their processing
priority are shown in Figure 17-1 on page 17-3.

17-2 z/OS V1R3.0 MVS JCL Reference

 IF/THEN/ELSE/ENDIF
The system evaluates operators in the order indicated. Code operators with the
same priority in the order in which you want the system to evaluate them.

You can specify either the alphabetic characters or the special characters for an
operator. For example, GT and > have the same meaning. (RC GT 10) and (RC >
10) are the same.

Order of
Operator Operation Evaluation
-------- --------- ----------

NOT operator:

NOT or ¬ NOT first

Comparison operators:

GT or > Greater than second

LT or < Less than second
NG or ¬> Not greater than second
NL or ¬< Not less than second
EQ or = Equal to second
NE or ¬= Not equal to second
GE or >= Greater than or equal to second
LE or <= Less than or equal to second

Logical operators:

AND or & AND third

OR or | OR third

Figure 17-1. Operators on IF/THEN/ELSE/ENDIF Statement Construct

Comparison Operators
Use comparison operators in a relational-expression to compare a keyword with a
numeric value. The comparison results in a true or false condition.

For example, to test for a return code of 8, code:

//TESTA IF (RC = 8) THEN

In the example, if a return code is 8, the expression is true; otherwise, the

expression is false.

Blanks are not required to precede and follow special character comparison
operators (such as > or ¬=). However, it is good practice to use blanks so your
code is easier to read. Blanks are required to precede and follow alphabetic
comparison operators (such as GT or EQ). Precede and follow the special
character & with at least one blank so that it is not confused with symbolic
parameters.

Logical Operators
Use the & (AND) and | (OR) logical operators in a complex relational-expression to
indicate that the Boolean result of two or more relational-expressions is to be
evaluated.

You must precede and follow the & (AND) and | (OR) operators with at least one
blank.

Chapter 17. IF/THEN/ELSE/ENDIF Statement Construct 17-3

IF/THEN/ELSE/ENDIF
The & (AND) operator indicates that all of the specified expressions must be true.
For example, to test that a return code is both greater than 8 and less than 24 (in
the range 9 through 23), code:
//TESTAND IF (RC > 8 & RC < 24) THEN

The | (OR) operator specifies that only one of the expressions need be true. For
example, to test that a return code is either equal to 8, equal to 10, or greater than
24, code:
//TESTOR IF (RC = 8 | RC = 10 | RC > 24) THEN

NOT Operator
Use the ¬ (NOT) operator to reverse the testing of relational-expressions.

For example, the statements TESTNOTA and TESTNOTB make the same test. The
relational expression is true when the return code is between 0 and 8:
//TESTNOTA IF ¬(RC > 8) THEN
//TESTNOTB IF (RC <= 8) THEN

The statements TESTNOTC and TESTNOTD make the same test; the relational
expression is true when the return code is 0, 1, 2, 3, 4, 5, 6, 7, 9, or 10.
//TESTNOTC IF ¬(RC = 8 | RC > 10) THEN
//TESTNOTD IF (RC ¬= 8 & RC <= 10) THEN

Note that the use of the ¬ operator reverses both the logical and comparison
operators.

You do not need to code a blank between the ¬ operator and the expression it is
reversing.

Relational-Expression Keywords
The following keywords are the only keywords supported by IBM and recommended
for use in relational-expressions. Any other keywords, even if accepted by the
system, are not intended or supported keywords.
Keyword
Use
RC indicates a return code
ABEND
indicates an abend condition occurred
¬ABEND
indicates no abend condition occurred
ABENDCC
indicates a system or user completion code
RUN indicates that the specified step started execution
¬RUN indicates that the specified step did not start execution

Descriptions of the keywords follow:

RC
Indicates that the relational-expression tests a return code. Evaluate a return
code by coding RC, a comparison operator, and a numeric value. For example,
the expression (RC = 8) tests for a return code equal to 8, and (RC >= 10)
tests for a return code greater than or equal to 10.
The return code must be within the range of 0 - 4095.

17-4 z/OS V1R3.0 MVS JCL Reference

 IF/THEN/ELSE/ENDIF
If you omit stepname, RC refers to the highest job step return code that
occurred during job processing prior to the time of evaluation. This applies only
to steps that execute. Any step that did not start execution, is cancelled, or
abnormally ends is not evaluated.

Note: At the start of execution, RC is initially set to zero.

stepname.RC
Indicates that the relational-expression tests a return code for a specific
step (stepname) of the job.
stepname.procstepname.RC
Indicates that the relational-expression tests a return code for a specific
step (stepname) and procedure step (procstepname) of the job.
ABEND
ABEND=TRUE
Indicates that the relational-expression tests for an abend condition that
occurred during processing of the job prior to the time of evaluation. The
statement IF ABEND THEN tests true when an abend occurred on any previous
job step.
If stepname is omitted, ABEND and ABEND=TRUE refer to all previous steps.
Certain types of abnormal termination by the system prevent the execution of
the THEN or ELSE clauses of an IF/THEN/ELSE/ENDIF statement construct,
regardless of any tests for abnormal termination conditions. See “Errors that
Prevent Execution, Regardless of IF Statement Tests” on page 17-9 for further
information.
stepname.ABEND
stepname.ABEND=TRUE
Indicates that the relational-expression tests for an abend that occurred on
a specific step (stepname) of the job.
stepname.procstepname.ABEND
stepname.procstepname.ABEND=TRUE
Indicates that the relational-expression tests for an abend that occurred on
a specific step (stepname) and procedure step (procstepname) of the job.
¬ABEND
ABEND=FALSE
Indicates that the relational-expression tests that an abend condition did not
occur during the processing of the job prior to the time of evaluation. The
statement IF ¬ABEND THEN tests true when no abend occurred on any
previous job step.
If stepname is omitted, ¬ABEND and ABEND=FALSE refer to all previous steps.
Certain types of abnormal termination by the system prevent the execution of
the THEN or ELSE clauses of an IF/THEN/ELSE/ENDIF statement construct,
regardless of any tests for abnormal termination conditions. See “Errors that
Prevent Execution, Regardless of IF Statement Tests” on page 17-9 for further
information.
¬stepname.ABEND
stepname.ABEND=FALSE
Indicates that the relational-expression tests that no abend occurred on a
specific step (stepname) of the job.
¬stepname.procstepname.ABEND

Chapter 17. IF/THEN/ELSE/ENDIF Statement Construct 17-5

IF/THEN/ELSE/ENDIF
stepname.procstepname.ABEND=FALSE
Indicates that the relational-expression tests that no abend occurred on a
specific step (stepname) and procedure step (procstepname) of the job.
ABENDCC=Sxxx
ABENDCC=Uxxxx
Indicates that the relational-expression tests for a system abend completion
code (Sxxx) or user-defined abend completion code (Uxxxx). Specify S with a
hexadecimal value (3 characters) for system abend codes, and U with a
decimal value (4 digits) for user abend codes. For example, ABENDCC=S0C4
tests for system abend code 0C4, and ABENDCC=U0100 tests for user abend
code 0100.
If stepname is omitted, ABEND=Sxxx and ABENDCC=Uxxxx refer to the most
recent abend code that occurred during the execution of the job prior to the
time of evaluation.
Certain types of abnormal termination by the system prevent the execution of
the THEN or ELSE clauses of an IF/THEN/ELSE/ENDIF statement construct,
regardless of any tests for abnormal termination completion codes. See “Errors
that Prevent Execution, Regardless of IF Statement Tests” on page 17-9 for
further information.
stepname.ABENDCC=Sxxx
stepname.ABENDCC=Uxxxx
Indicates that the relational-expression tests the abend code for a specific
step (stepname) of the job.
stepname.procstepname.ABENDCC=Sxxx
stepname.procstepname.ABENDCC=Uxxxx
Indicates that the relational-expression tests the abend code for a specific
step (stepname) and procedure step (procstepname) of the job.
stepname.RUN
stepname.RUN=TRUE
Indicates that the relational expression tests that a specific job step (stepname)
started execution.
stepname.procstepname.RUN
stepname.procstepname.RUN=TRUE
Indicates that the relational expression tests that a specific job step (stepname)
and procedure step (procstepname) started execution.
¬stepname.RUN
stepname.RUN=FALSE
Indicates that the relational expression tests that a specific job step (stepname)
did not start execution.
¬stepname.procstepname.RUN
stepname.procstepname.RUN=FALSE
Indicates that the relational expression tests that a specific job step (stepname)
and procedure step (procstepname) did not start execution.

Specification of Step Names in Relational Expression Keywords

If you specify stepname.keyword, where keyword is any of the relational expression
keywords, stepname must identify a step containing the EXEC PGM keyword rather
than one that invokes a procedure. If you specify stepname.procstepname.keyword,
procstepname must identify a step containing the PGM keyword. In this case,
stepname identifies the EXEC statement that invokes the procedure in which
procstepname appears.

17-6 z/OS V1R3.0 MVS JCL Reference

 IF/THEN/ELSE/ENDIF
When you specify a step name as part of a relational expression keyword, the
system tests whether the specified step started executing. If the step started
executing, the system performs the test indicated by the relational expression. If the
step did not start executing, the system evaluates that part of the expression as
false.

You must always specify a step name when using the RUN relational-expression
keywords to determine if a step or procedure step executed. For more information
about step names in relational expression keywords, see z/OS MVS JCL User’s
Guide.

Use of Parentheses with Relational Expressions

The system evaluates relational-expressions that are enclosed within parentheses
prior to expressions found outside of parentheses. Therefore, you can control the
way in which complex relational-expressions are evaluated.

For example, code the following to test that a return code is 0, 1, 2, or 3:

//TESTPAR IF (RC LT 4 & (RC LT 12 | RC = 16)) THEN

By keeping the same expressions but changing the position of the parentheses, you
can test that a return code is 0, 1, 2, 3 or 16:
//TESTPAR1 IF ((RC LT 4 & RC LT 12) | RC = 16) THEN

Comments Field
The comments field follows THEN, ELSE, and ENDIF after at least one intervening
blank.

Location in the JCL

An IF/THEN/ELSE/ENDIF statement construct can appear anywhere in the job after
the first EXEC statement.

Relationship to Other Parameters

When you specify both an IF/THEN/ELSE/ENDIF statement construct and a COND
parameter for an EXEC statement, the system executes the job step represented by
the EXEC statement only when both the IF/THEN/ELSE/ENDIF statement construct
and the COND parameter evaluate to execute.

Defaults
By default, job steps within the IF/THEN/ELSE/ENDIF statement construct do not
execute when
v An abend occurred, and
v the IF/THEN/ELSE/ENDIF structure containing the job steps does not specify the
ABEND, ABENDCC, or ¬ABEND keyword. If any of these keywords is specified
(with or without stepname or procstepname), the job steps do execute despite
the abend.
v The step’s COND parameter, if any, does not specify an abend condition
(COND=EVEN or COND=ONLY).

THEN and ELSE Clauses

A THEN clause consists of the JCL statements between the IF/THEN statement
and, if specified, its matching ELSE statement; otherwise, its matching ENDIF
statement. If you do not specify any statements, it is a null THEN clause.

Chapter 17. IF/THEN/ELSE/ENDIF Statement Construct 17-7

IF/THEN/ELSE/ENDIF
An ELSE clause consists of the JCL statements between the ELSE statement and
its matching ENDIF statement. If you do not specify any statements, it is a null
ELSE clause.

In an IF/THEN/ELSE/ENDIF statement construct, the THEN clause or the ELSE

clause must contain at least one EXEC statement to identify a job step.

The system executes the following statements conditionally, in either the THEN
clause or the ELSE clause of an IF/THEN/ELSE/ENDIF statement construct.
Execution of the statement depends on the evaluation of the relational-expression
at execution time:
Nested IF/THEN/ELSE/ENDIF statement constructs
EXEC statements
DD (including DD * and DD DATA) statements
STEPCAT and STEPLIB DD statements
SYSABEND, SYSMDUMP, and SYSUDUMP DD statements
SYSCHK (step level) and SYSCKEOV DD statements
SYSIN DD statements
OUTPUT JCL statements
CNTL and ENDCNTL statements

Do not place the following statements in a THEN or ELSE clause:

JOB statement
JCLLIB statement
JOBCAT and JOBLIB statement
SYSCHK (job level) statement
XMIT JCL statement

The system processes the following statements regardless of the logic of the
IF/THEN/ELSE/ENDIF statement construct. They can be placed in a THEN or ELSE
clause, but they are not executed conditionally.
PROC and PEND statements
JES2 and JES3 statements and commands
JCL command statements
Comment (//*) statements
INCLUDE statements
Delimiter (/*) statements
Null statements
SET statements

Considerations when Using the IF/THEN/ELSE/ENDIF Construct

Be aware of the following considerations when using the IF/THEN/ELSE/ENDIF
statement construct:
v The IF/THEN/ELSE/ENDIF statement construct does not conditionally control the
processing of JCL; rather, it conditionally controls the execution of job steps.
v The result of processing an IF/THEN/ELSE/ENDIF statement construct, once
determined, remains unchanged regardless of the outcome from running any
remaining steps in a job. The system does not reexamine the original condition at
any later job step termination, either normal or abnormal. See Example 9.
v The system allocates all DD statements defined to a step if the execution time
evaluation of the relational-expression determines that a step is to be executed.
v All data sets defined on DD statements in the job must be available at the time
the job is selected for execution.

17-8 z/OS V1R3.0 MVS JCL Reference

 IF/THEN/ELSE/ENDIF
v You can nest IF/THEN/ELSE/ENDIF statement constructs up to a maximum of 15
levels.
v You can specify symbolic parameters on IF/THEN/ELSE/ENDIF statements
provided that they resolve to one of the supported relational-expression keywords
listed in the preceding topic (that is, RC, ABEND, ...). Any other symbolic
parameters, even if accepted by the system, are not intended or supported.
v An IF statement specified before the first EXEC statement in a job is not
evaluated before the first step executes. If the IF statement applies to later steps
in the job, the statement will be evaluated when the system decides whether to
process the later steps.
v When you specify an IF statement before the first EXEC statement in a job and
the job contains a JOBLIB DD statement, the maximum limit for the number of
steps in the job is 254 steps.

There are additional considerations related to errors that prevent execution of the
THEN or ELSE clause, no matter what is specified on the IF statement, and there
are special considerations related to restarted jobs.

Errors that Prevent Execution, Regardless of IF Statement Tests

Certain error conditions prevent the system from executing the THEN or ELSE
clauses of an IF/THEN/ELSE/ENDIF statement construct. When such an error
condition occurs, the system does not execute the THEN or ELSE clause,
regardless of any tests on the IF statement. These conditions are as follows:

Abnormal Termination by the System

After certain types of abnormal termination by the system, remaining job steps are
not executed, regardless of any tests for abnormal termination conditions. The
completion codes associated with these types of abnormal termination are:
122 Operator canceled job
222 Operator or TSO/E user canceled job

You might encounter other system completion codes for which the THEN or ELSE
clause is not executed, regardless of any tests for abnormal termination conditions.
See z/OS MVS System Codes for further information about specific system
completion codes.

When Job Time Expires

The system abnormally terminates processing if a step has exceeded the time limit
for the job. The specification of the IF/THEN/ELSE/ENDIF construct has no effect
on this type of abnormal termination.

When a Referenced Data Set Is Not Complete

When a job step that contains the IF/THEN/ELSE/ENDIF statement construct

references a data set that was to be created or cataloged in a preceding step, the
data set
v Will not exist if the step creating it was bypassed, or
v May be incomplete if the step creating it abnormally terminated.
As a result, the system may be unable to execute the step.

When the Program Does Not Have Control

Chapter 17. IF/THEN/ELSE/ENDIF Statement Construct 17-9

IF/THEN/ELSE/ENDIF
For the system to act on the IF/THEN/ELSE/ENDIF statement construct, the step
must abnormally terminate while the program has control. If a step abnormally
terminates during scheduling, (due to failures such as JCL errors or the inability to
allocate space), the system bypasses the remaining steps. The steps specified by
the IF/THEN/ELSE/ENDIF statement construct do not execute.

Considerations for Restarted Jobs

There are four types of restarts:
v Automatic step restart
v Automatic checkpoint restart
v Deferred step restart
v Deferred checkpoint restart
Only the automatic restarts retain the information (step completion codes)
necessary to perform valid evaluations of any relational expressions based on prior
steps.

If you plan to use either type of deferred restart, you should keep certain points in
mind when coding the JCL for the job. Planning ahead in this manner can help
prevent the need to update the JCL when the job is submitted for restart. The points
to consider are the following:
v Relational expressions on IF/THEN statements that refer to a step preceding the
restarted step are evaluated as false.
v Relational expressions on IF/THEN statements on steps following the restarted
step can still refer to these following steps, but should also check to see whether
the referenced steps actually ran during this invocation. The default value for
relational expressions on IF/THEN statements is false, which, unlike COND, will
cause the system to skip steps. Adding a ¬STEP.RUN condition is recommended.
See “Example 7” on page 17-13 for an example of a statement construct with a
deferred checkpoint restart.

Examples of IF/THEN/ELSE/ENDIF Statement Constructs

Example 1
The following example shows the use of the alphabetic characters rather than
special characters for comparison operators.
//IFBAD IF (ABEND | STEP1.RC > 8) THEN
or
//IFBAD IF (ABEND OR STEP1.RC GT 8) THEN
.
.
//IFTEST2 IF (RC > 4 & RC < 8) THEN
or
//IFTEST2 IF (RC GT 4 AND RC LT 8) THEN

Example 2
The following example shows a simple IF/THEN/ELSE/ENDIF statement construct
without an ELSE statement.
//JOBA JOB ...
//STEP1 EXEC PGM=RTN
.
.
//IFBAD IF (ABEND | STEP1.RC > 8) THEN
//TRUE EXEC PROC=ERROR
//IFBADEND ENDIF
//NEXTSTEP EXEC PROC=CONTINUE

17-10 z/OS V1R3.0 MVS JCL Reference

 IF/THEN/ELSE/ENDIF
The IF statement named IFBAD invokes procedure ERROR if either an abend has
occurred on a previous step of the job, or STEP1 has returned a return code that is
greater than 8. Otherwise, step TRUE is bypassed and the system processes step
NEXTSTEP.

Example 3
The following example shows a simple IF/THEN/ELSE/ENDIF statement construct
with a null ELSE clause.
//JOBB JOB ...
//STEP1 EXEC PGM=RTN
.
.
//IFBAD IF (ABEND | STEP1.RC > 8) THEN
//TRUE EXEC PROC=ERROR
// ELSE
//IFBADEND ENDIF
//NEXTSTEP EXEC PROC=CONTINUE

The IF statement named IFBAD invokes procedure ERROR if either an abend has
occurred on a previous step of the job, or STEP1 has returned a return code that is
greater than 8. Otherwise, the system bypasses step TRUE, and the null ELSE
clause passes to NEXTSTEP.

Example 4
The following example shows a simple IF/THEN/ELSE/ENDIF statement construct
with an ELSE clause.
//JOBC JOB ...
//STEP0 EXEC PGM=RTN1
.
.
//IFTEST2 IF (RC > 4 & RC < 8) THEN
//* *** WARNING CONDITION REPORTING GROUP ***
//STEP1 EXEC PGM=IEFBR14
//REPORT EXEC PROC=REPTRTN
//* *** WARNING CONDITION REPORTING GROUP END ***
// ELSE
//ERRORSTP EXEC PROC=ERRORTN
//ENDTEST2 ENDIF
//NEXTSTEP EXEC PROC=CONTINUE

Processing for this IF/THEN/ELSE/ENDIF statement construct is:

1. If the relational-expression for the IF/THEN statement construct named IFTEST2
is true (the highest step return code for the job is greater than 4 and less than 8
at the point when this statement is being processed), the system processes the
THEN clause. The system executes program IEFBR14 and procedure
REPTRTN on EXEC statements STEP1 and REPORT.
2. Otherwise, the relational-expression for IFTEST2 is false and the system
processes the ELSE clause (procedure ERRORTN on EXEC statement
ERRORSTP).
3. Processing then continues with procedure CONTINUE on step NEXTSTEP.

Example 5
The following example shows nested IF/THEN/ELSE/ENDIF statement constructs
with ELSE clauses. The nested statements are indented so that they are easier to
read.
//JOBD JOB ...
//PROC1 PROC
//PSTEPONE EXEC PGM=...
//PSTEP11 EXEC PGM=...

Chapter 17. IF/THEN/ELSE/ENDIF Statement Construct 17-11

IF/THEN/ELSE/ENDIF
//PSTEP12 EXEC PGM=...
// PEND
//PROC2 PROC
//PSTEPTWO EXEC PGM=...
// PEND
//EXP1 EXEC PROC=PROC1
//EXP2 EXEC PROC=PROC2
//IFTEST3 IF (RC > 12) THEN
//STEP1BAD IF (EXP1.PSTEP11.RC > 12 OR EXP1.PSTEP12.RC > 12) THEN
//STEP1ERR EXEC PGM=ERRTN,PARM=(EXP1)
// ELSE
//STEP2ERR EXEC PGM=ERRTN,PARM=(EXP2)
//END1BAD ENDIF
// ELSE
//NOPROB EXEC PROC=RUNOK
//ENDTEST3 ENDIF
//NEXTSTEP EXEC ...

Processing for the IF/THEN/ELSE/ENDIF construct named IFTEST3 is:

1. If the relational-expression for IFTEST3 is true (the highest step return code for
the job is greater than 12 at the point where this statement is being processed),
the system processes the THEN clause of IFTEST3. It evaluates the
relational-expression of the IF/THEN/ELSE/ENDIF construct named STEP1BAD.
2. If the STEP1BAD relational-expression is true (the return code is greater than
12 for either of the two steps in procedure PROC1, which is invoked by step
EXP1), the system processes the THEN clause of STEP1BAD. Step
STEP1ERR invokes program ERRTN, passing EXP1 as a parameter.
3. If the STEP1BAD relational-expression is not true, the system processes the
ELSE clause for STEP1BAD. Step STEP2ERR invokes program ERRTN,
passing EXP2 as a parameter.
4. However, if the relational-expression for IFTEST3 is false, the system processes
the ELSE clause. Step NOPROB invokes procedure RUNOK.
5. Processing then continues with step NEXTSTEP.

Example 6
The following example shows two IF/THEN/ELSE/ENDIF statement constructs, one
of which is nested in the ELSE clause of the other. The nested statements are
indented so that they are easier to read.
//JOBE JOB ...
//PROC1 PROC
//PSTEPONE EXEC PGM=...
// PEND
//PROC2 PROC
//PSTEPTWO EXEC PGM=...
// PEND
//EXP1 EXEC PROC=PROC1
//EXP2 EXEC PROC=PROC2
//IFTEST4 IF (EXP1.PSTEPONE.RC > 4) THEN
//STEP1ERR EXEC PGM=PROG1
// ELSE
//IFTEST5 IF (EXP2.PSTEPTWO.ABENDCC=U0012) THEN
//STEP2ERR EXEC PGM=PROG2
// ELSE
//NOERR EXEC PGM=PROG3
//ENDTEST5 ENDIF
//ENDTEST4 ENDIF
//NEXTSTEP EXEC ...

Processing for the IF/THEN/ELSE/ENDIF construct named IFTEST4 is:

17-12 z/OS V1R3.0 MVS JCL Reference

 IF/THEN/ELSE/ENDIF
1. If the relational-expression for IFTEST4 is true (the return code is greater than 4
for PSTEPONE in procedure PROC1, which is invoked by step EXP1), the
system processes the THEN clause of IFTEST4. EXEC statement STEP1ERR
invokes program PROG1. The system then passes control to ENDIF statement
ENDTEST4, and processing continues with step NEXTSTEP.
2. However, if the relational-expression for IFTEST4 is false (the return code is 4
or less for PSTEPONE in procedure PROC1, which is invoked by step EXP1),
the system processes the ELSE clause of IFTEST4. It evaluates the
IF/THEN/ELSE/ENDIF statement construct IFTEST5.
Processing for the IF/THEN/ELSE/ENDIF construct named IFTEST5 is:
a. If the relational-expression for IFTEST5 is true (the user-defined abend
completion code is 0012 from PSTEPTWO in procedure PROC2, which is
invoked by step EXP2), the system processes the THEN clause of IFTEST5.
EXEC statement STEP2ERR invokes program PROG2. The system then
passes control to ENDIF statement ENDTEST5, and then ENDTEST4.
Processing continues with EXEC statement NEXTSTEP.
b. However, if the relational-expression for IFTEST5 is false (that is, the
user-defined abend completion code is not 0012 from PSTEPTWO in
procedure PROC2, which is invoked by step EXP2), the system processes
the ELSE clause of IFTEST5. EXEC statement NOERR invokes program
PROG3. Processing then continues with step NEXTSTEP.

Example 7
The following example shows an IF/THEN/ELSE/ENDIF statement construct with a
deferred checkpoint restart.
//DEFER1 JOB RESTART=(STEP2,CHECK004)
//STEP1 EXEC PGM=IEFBR14
//IF1 IF STEP1.RC=0 | ¬STEP1.RUN THEN
//STEP2 EXEC PGM=DEBIT1
//STEP3 EXEC PGM=CREDIT1
//STEP4 EXEC PGM=SUMMARY1
// ELSE
//STEP5 EXEC PGM=DEBIT2
//STEP6 EXEC PGM=CREDIT2
//STEP7 EXEC PGM=SUMMARY2
// ENDIF

Processing for the IF/THEN/ELSE/ENDIF construct named IF1 is as follows:

1. The conditions on statement IF1 will be checked before executing STEP2.
2. STEP1.RC=0 tests false because STEP1 did not execute and cannot be
correctly evaluated.
3. ¬STEP1.RUN tests true; therefore, STEP2, STEP3, and STEP4 will execute and
STEP5, STEP6, and STEP7 will not execute.

Note: Without the ¬STEP.RUN condition, STEP2, STEP3, and STEP4 would not
execute and STEP5, STEP6, and STEP7 would execute.

Example 8
The following example shows an IF/THEN/ELSE/ENDIF statement construct with a
deferred step restart.
//DEFER2 JOB RESTART=(STEP3)
//STEP1 EXEC PGM=IEFBR14
//IF1 IF STEP1.RC=0 | ¬STEP1.RUN THEN
//STEP2 EXEC PGM=DEBIT1
//STEP3 EXEC PGM=CREDIT1
//STEP4 EXEC PGM=SUMMARY1
// ELSE

Chapter 17. IF/THEN/ELSE/ENDIF Statement Construct 17-13

IF/THEN/ELSE/ENDIF
//STEP5 EXEC PGM=DEBIT2
//STEP6 EXEC PGM=CREDIT2
//STEP7 EXEC PGM=SUMMARY2
// ENDIF

Processing for the IF/THEN/ELSE/ENDIF construct named IF1 is:

1. The conditions on statement IF1 will be checked before executing STEP3.
2. STEP1.RC=0 tests false because STEP1 did not execute and cannot be
correctly evaluated.
3. ¬STEP1.RUN tests true; therefore, STEP3 and STEP4 will execute and STEP5,
STEP6, and STEP7 will not execute.

Note: Without the ¬STEP1.RUN condition, STEP3 and STEP4 would not run, and
STEP5, STEP6, and STEP7 would run.

Example 9
The following example specifies that if STEP1 does not abend, the system is to run
STEP2 and STEP3. Otherwise it is to run STEP4.
//JOBF JOB ...
//STEP1 EXEC PGM=...
//IFTEST6 IF ¬ABEND THEN
//STEP2 EXEC PGM=...
//STEP3 EXEC PGM=...
// ELSE
//STEP4 EXEC PGM=...
// ENDIF

The determination of which steps to run is made when the IF/THEN/ELSE/ENDIF

statement construct is processed immediately after STEP1 executes. This
determination is not subject to change based on the results of running steps after
STEP1.

Thus, if STEP1 does not abend, even if STEP2 does, STEP3 (and not STEP4) still
runs. If, however, STEP1 does abend, STEP4 is the next step to run, as prescribed
by the ELSE clause.

17-14 z/OS V1R3.0 MVS JCL Reference

 Chapter 18. INCLUDE Statement
Purpose

Use the INCLUDE statement to:

v Identify the name of the member of a partitioned data set (PDS) or partitioned
data set extended (PDSE) that contains a set of JCL statements (such as DD
and OUTPUT JCL statements) called an INCLUDE group.
v Imbed the INCLUDE group in the JCL stream at the position of the INCLUDE
statement.

The INCLUDE group replaces the INCLUDE statement, and the system processes
the imbedded JCL statements as part of the JCL stream. The JCL statements,
which are subject to all JCL processing rules, must be complete statements; that is,
you cannot use an imbedded statement to continue the statement that precedes
INCLUDE.

Description

Syntax

//[name] INCLUDE MEMBER=name [comments]

The INCLUDE statement consists of the characters // in columns 1 and 2 and four fields:
name, operation (INCLUDE), keyword parameter (MEMBER), and comments.

Name Field
A name is optional on an INCLUDE statement. If used, code it as follows:
v The name should be unique within the job.
v The name must begin in column 3.
v The name is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The name must be followed by at least one blank.
| v The name may be preceded by up to 8 alphanumeric or national characters, and
| then separated by a period. Coding the name in this way should not be confused
| with specifying an override, as can be done when coding DD statements.

If you do not code a name, column 3 must be blank.

Operation Field
The operation field consists of the characters INCLUDE and must be preceded and
followed by at least one blank. It can begin in any column.

Parameter Field
The INCLUDE statement contains one keyword parameter:
MEMBER=name
Specifies the name of a member of a PDS or partitioned data set extended
(PDSE) that contains the set of JCL statements (called an INCLUDE group) to
be imbedded in the JCL stream.

© Copyright IBM Corp. 1988, 2002 18-1

INCLUDE
The PDS or PDSE must be one of the following:
v A system procedure library (such as SYS1.PROCLIB), or
v An installation-defined procedure library, or
v A private library that you must specify on a JCLLIB statement appearing
earlier in the job.

Comments Field
The comments field follows the parameter field after at least one intervening blank.

Location in the JCL

An INCLUDE statement:
v Can appear anywhere in the job after the JOB statement, with one exception: if
there is a JCLLIB statement, the INCLUDE statement must follow the JCLLIB
statement.
v Must follow a complete JCL statement.
v Can appear within an INCLUDE group. INCLUDE groups can contain INCLUDE
statements and can be nested up to a maximum of 15 levels of nesting.
v Cannot appear in a CNTL/ENDCNTL group, which contains program control
statements delimited by the CNTL and ENDCNTL statements.

Considerations for Using INCLUDE Groups

System and private libraries can contain both procedures and INCLUDE groups.
The order in which the system searches system and private libraries for INCLUDE
groups is the same as the search order used for procedures (see “Using a
Procedure” on page 5-2).

INCLUDE groups cannot contain the following JCL statements:

JOB statements
PROC and PEND statements
JCLLIB statements
JES2 and JES3 statements and commands
DD * and DD DATA statements

Do not define procedures in an INCLUDE group. However, you can put EXEC
statements that invoke procedures in an INCLUDE group.

You can use INCLUDE statements to imbed INCLUDE groups that contain DD and
OUTPUT JCL statements, which allows you to use the same data set definitions for
various jobs.

When the INCLUDE statement and the INCLUDE group contain symbolic
parameters, the system substitutes the values that are current at the time the
symbolic parameter is encountered. Values assigned to symbolic parameters in an
INCLUDE group (such as with the SET statement) are valid for use on subsequent
JCL statements.

Examples of the INCLUDE Statement:

Example 1

The following INCLUDE group is defined in member SYSOUT2 of private library

CAMPBELL.SYSOUT.JCL.

18-2 z/OS V1R3.0 MVS JCL Reference

 INCLUDE
//* THIS INCLUDE GROUP IS CATALOGED AS...
//* CAMPBELL.SYSOUT.JCL(SYSOUT2)
//SYSOUT2 DD SYSOUT=A
//OUT1 OUTPUT DEST=POK,COPIES=3
//OUT2 OUTPUT DEST=KINGSTON,COPIES=30
//OUT3 OUTPUT DEST=MCL,COPIES=10
//* END OF INCLUDE GROUP...
//* CAMPBELL.SYSOUT.JCL(SYSOUT2)

The system executes the following program:

//TESTJOB JOB ...
//LIBSRCH JCLLIB ORDER=CAMPBELL.SYSOUT.JCL
//STEP1 EXEC PGM=OUTRTN
//OUTPUT1 INCLUDE MEMBER=SYSOUT2
//STEP2 EXEC PGM=IEFBR14

The JCLLIB statement specifies that the system is to search private library
CAMPBELL.SYSOUT.JCL for the INCLUDE group SYSOUT2 before it searches any
system libraries.

After the system processes the INCLUDE statement, the JCL stream appears as:
//TESTJOB JOB ...
//LIBSRCH JCLLIB ORDER=CAMPBELL.SYSOUT.JCL
//STEP1 EXEC PGM=OUTRTN
//* THIS INCLUDE GROUP IS CATALOGED AS...
//* CAMPBELL.SYSOUT.JCL(SYSOUT2)
//SYSOUT2 DD SYSOUT=A
//OUT1 OUTPUT DEST=POK,COPIES=3
//OUT2 OUTPUT DEST=KINGSTON,COPIES=30
//OUT3 OUTPUT DEST=MCL,COPIES=10
//* END OF INCLUDE GROUP...
//* CAMPBELL.SYSOUT.JCL(SYSOUT2)
//STEP2 EXEC PGM=IEFBR14

The system imbeds the INCLUDE group in the JCL stream (replacing the INCLUDE
statement), and processes the included JCL statements with the JCL stream.

Example 2

The following example shows the use of the SET statement to assign values to
symbolic parameters in an INCLUDE group.
//* THIS INCLUDE GROUP IS CATALOGED AS...
//* LAMAN.SYSOUT.JCL(SYSOUT2)
//SYSOUT2 DD SYSOUT=A
//OUT1 OUTPUT DEST=POK,COPIES=3
//OUT2 OUTPUT DEST=&AA,COPIES=&NC
//OUT3 OUTPUT DEST=&BB,COPIES=10
//* END OF INCLUDE GROUP...
//* LAMAN.SYSOUT.JCL(SYSOUT2)

The following program is executed.

//JOBA JOB ...
//LIBS JCLLIB ORDER=LAMAN.SYSOUT.JCL
//SET1 SET AA=KINGSTON,BB=STL,NC=10
//STEP1 EXEC PGM=OUTRTN
//OUTPUT1 INCLUDE MEMBER=SYSOUT2
//STEP2 EXEC PGM=IEFBR14

The SET statement, which is easy to change for different jobs, assigns values to
the symbolic parameters in INCLUDE group SYSOUT2.

Chapter 18. INCLUDE Statement 18-3

INCLUDE
After the system processes the INCLUDE statement, it executes the JCL stream as:
//JOBA JOB ...
//LIBS JCLLIB ORDER=LAMAN.SYSOUT.JCL
//STEP1 EXEC PGM=OUTRTN
//* THIS INCLUDE GROUP IS CATALOGED AS...
//* LAMAN.SYSOUT.JCL(SYSOUT2)
//SYSOUT2 DD SYSOUT=A
//OUT1 OUTPUT DEST=POK,COPIES=3
//OUT2 OUTPUT DEST=KINGSTON,COPIES=10
//OUT3 OUTPUT DEST=STL,COPIES=10
//* END OF INCLUDE GROUP...
//* LAMAN.SYSOUT.JCL(SYSOUT2)
//STEP2 EXEC PGM=IEFBR14

The system imbeds the INCLUDE group in the JCL stream (replacing the INCLUDE
statement), and assigns the values to the symbolic parameters in the INCLUDE
group.

18-4 z/OS V1R3.0 MVS JCL Reference

Chapter 19. JCLLIB Statement
Purpose

Use the JCLLIB statement to:

v Identify the names of the private libraries that the system uses for the job. The
system searches the libraries for:
– Procedures named on any EXEC statements
– Groups of JCL statements (called INCLUDE groups) named on any INCLUDE
statements.
v Identify the names of the system procedure libraries and installation-defined
procedure libraries that the system uses for the job.
v Identify the order in which the libraries are to be searched. The system searches
the libraries in the order in which you specify them on the JCLLIB statement,
prior to searching any unspecified default system procedure libraries.

The JCLLIB statement allows you to code and use procedures and INCLUDE
groups in a private library without the need to use system procedure libraries.

You can code only one JCLLIB statement per job.

Considerations for an APPC Scheduling Environment

In an APPC environment, see the information about scheduler JCL for TP profiles in
z/OS MVS Planning: APPC/MVS Management.

Considerations for JES3

In a JES3 environment, the system on which the job is submitted and/or converted
must have access to any libraries named on the JCLLIB statement.

Description

Syntax

//[name] JCLLIB ORDER=(library[,library]...) [comments]

© Copyright IBM Corp. 1988, 2002 19-1

 JCLLIB
The JCLLIB statement consists of the characters // in columns 1 and 2 and four fields:
name, operation (JCLLIB), keyword parameter (ORDER), and comments.

If only one library is listed in the search order, the parentheses are optional. For example:
//MYLIB JCLLIB ORDER=MY.PROC1

Library names can be enclosed in apostrophes, for example:

//MYLIB JCLLIB ORDER=(’MY.PROC1’,’MY.PROC2’)

You can continue the list of libraries to the following statement by breaking the statement
after a comma in the list, and continuing the list on the next statement, beginning in any
column from 4 to 16. For example:
//MYLIB JCLLIB ORDER=(MY.PROC1,MY.PROC2,
// MY.PROC3)

You can continue a parameter enclosed in quotes by breaking the parameter in column 71
and continuing the parameter in column 16 of the next statement.
column 71
|
//MYLIB JCLLIB ORDER=(’MY.PROC1’,’MY.PROC2’,’MY.PROC3’,’MY.PROC4’,’MY
// .PROC5’)
|
column 16

Name Field
A name is optional on a JCLLIB statement. If used, code it as follows:
v The name must begin in column 3.
v The name is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The name must be followed by at least one blank.
| v The name may be preceded by up to 8 aphanumeric or national characters, and
| then separated by a period. Coding the name in this way should not be confused
| with specifying an override, as can be done when coding DD statements.

If a name is not coded, column 3 must be blank.

Operation Field
The operation field consists of the characters JCLLIB and must be preceded and
followed by at least one blank. It can begin in any column.

Parameter Field
The JCLLIB statement contains one keyword parameter:
ORDER=(library[,library...])
Specifies the names of the libraries to be searched. The maximum number of
libraries that may be specified is 15. You can specify private libraries, system
procedure libraries, and installation-defined procedure libraries. The system
searches the libraries in the order in which you specify them, before it searches
any unspecified default system procedure libraries.
Do not specify a library that is a temporary data set (&&dsname), partitioned
data set if a member name is included, or relative generation number for a
GDG.

Note: GDGs are not supported.

19-2 z/OS V1R3.0 MVS JCL Reference

 JCLLIB
Comments Field
The comments field follows the parameter field after at least one intervening blank.

Location in the JCL

A JCLLIB statement:
v Must appear after the JOB statement and before the first EXEC statement in the
job.
v Must appear before any INCLUDE statement.
v Must not appear within an INCLUDE group.

Considerations for Using the JCLLIB Statement

You can specify only one JCLLIB statement in a job.

The system and private libraries that you specify on the JCLLIB statement can
contain both procedures and INCLUDE groups.

The private libraries that you specify on the JCLLIB statement must comply with the
following rules:
v The private library must be cataloged. However, the library cannot be cataloged
in a catalog specified via a JOBCAT or STEPCAT DD statement.
v The private library must be accessible to the job. The library must be
permanently resident and online.
v The JCLLIB data set cannot be a password-protected data set.
v The job must have read access to any system or private libraries specified on
JCLLIB.
v The private library must have the same data set attributes as a system library,
which are:
– Logical record length of 80 bytes (LRECL=80)
– Fixed length records (RECFM=F or RECFM=FB). If the JCLLIB data set is a
PDSE, the record format can only be RECFM=FB.
– When multiple libraries are specified on the JCLLIB statement, these libraries
will be concatenated.

Examples of the JCLLIB Statement

Note: For each example, assume that the system default procedure library includes
SYS1.PROCLIB only. If you do not specify the JCLLIB statement, then the
system searches only SYS1.PROCLIB. (“Using a Procedure” on page 5-2
describes how the system determines the default procedure library.)

Example 1
//MYJOB1 JOB ...
//MYLIBS1 JCLLIB ORDER=CAMPBEL.PROCS.JCL
//S1 EXEC PROC=MYPROC1
.
.

The system searches the libraries for procedure MYPROC1 in the following order:
1. CAMPBEL.PROCS.JCL
2. SYS1.PROCLIB

Example 2

Chapter 19. JCLLIB Statement 19-3

JCLLIB
//MYJOB2 JOB ...
//MYLIBS2 JCLLIB ORDER=(CAMPBEL.PROCS.JCL,PUCHKOF.PROCS.JCL,
// YUILL.PROCS.JCL,GARY.PROCS.JCL)
//S2 EXEC PROC=MYPROC2
.
.
//INC2 INCLUDE MEMBER=MYINC2
.
.

The system searches the libraries for procedure MYPROC2 and INCLUDE group
MYINC2 in the following order:
1. CAMPBEL.PROCS.JCL
2. PUCHKOF.PROCS.JCL
3. YUILL.PROCS.JCL
4. GARY.PROCS.JCL
5. SYS1.PROCLIB

Example 3

You can specify a system procedure library.

//MYJOB3 JOB ...
//MYLIBS3 JCLLIB ORDER=(SYS1.PROCLIB,CAMPBEL.PROCS.JCL)
//S3 EXEC PROC=MYPROC3
.
.

The system searches the libraries for procedure MYPROC3 in the following order:
1. SYS1.PROCLIB
2. CAMPBEL.PROCS.JCL
3. SYS1.PROCLIB (the system default procedure library is searched again)

19-4 z/OS V1R3.0 MVS JCL Reference

Chapter 20. JOB Statement
Purpose

Use the JOB statement to mark the beginning of a job and to tell the system how to
process the job. Also, when jobs are stacked in the input stream, the JOB
statement marks the end of the preceding job.

Note: The JOB statement can be specified in source JCL for started tasks. For
more information, refer to Chapter 7, “Started Tasks” on page 7-1.

The parameters you can specify for job processing are arranged alphabetically in
the following pages.

References

For information about the JES initialization parameters that provide installation
defaults, see z/OS JES2 Initialization and Tuning Reference and z/OS JES3
Initialization and Tuning Reference.

Description

Syntax
//jobname JOB positional-parameters[,keyword-parameter]... [comments]

//jobname JOB

The JOB statement consists of the characters // in columns 1 and 2 and four fields: name,
operation (JOB), parameter, and comments. Do not code comments if the parameter field is
blank.

A JOB statement is required for each job.

Name Field
Code a jobname on every JOB statement, as follows:
v Each jobname must be unique.
v The jobname must begin in column 3.
v The jobname is 1 through 8 alphanumeric or national ($, #, @) characters. If your
system uses ANSI tapes, the jobname must contain only alphanumeric
characters; it must not contain national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The jobname must be followed by at least one blank.
v For the job types TSO logon and batch processing, the jobname must be unique,
otherwise:
– For TSO logon, duplicate jobnames fail. For example, if IBMUSER is logged
on, another attempt to logon as IBMUSER will fail.
– For batch processing, duplicate jobnames are delayed. For example, if job
BATCH01 is executing, then another job named BATCH01 will be delayed
until the original job has completed.

© Copyright IBM Corp. 1988, 2002 20-1

JOB
Operation Field
The operation field consists of the characters JOB and must be preceded and
followed by at least one blank. It can begin in any column.

Parameter Field
A JOB statement has two kinds of parameters: positional and keyword. All
parameters are optional; however, your installation may require the accounting
information parameter and the programmer’s name parameter.

Note: The following parameters are not supported on the JOB statement for a
started task:
v CLASS *
v GROUP
v PASSWORD
v RD *
v RESTART
v SCHENV
v SECLABEL
v TYPRUN
v USER

An asterisk indicates that the parameter will be ignored. The other parameters listed
result in a JCL error and job failure.

If JES detects an error in any parameter on the JOB statement, the error causes a
JCL error and a job failure; the system flushes all subsequent JCL statements,
including any SYSOUT-specific DD statements directing output to any other class or
destination.

Positional Parameters

A JOB statement can contain two positional parameters. They must precede all
keyword parameters. You must code the accounting parameter first, followed by the
programmer’s name parameter.

POSITIONAL PARAMETERS VALUES PURPOSE

([account-number] account-number Specifies an account number

[,accounting-information]...) and other accounting
,accounting- information, formatted as
See page 20-6 information: up to 143 required by the installation.
characters This parameter may be
required by the installation.

programmer’s-name programmer’s-name: 1 Identifies the owner of the

- 20 characters job. This parameter may be
See page 20-35 required by the installation.

Keyword Parameters

A JOB statement can contain the following keyword parameters. You can code any
of the keyword parameters in any order in the parameter field after the positional
parameters.

20-2 z/OS V1R3.0 MVS JCL Reference

 JOB
KEYWORD PARAMETERS VALUES PURPOSE

ADDRSPC= {VIRT} VIRT: virtual (pageable) storage Indicates the type of

{REAL} storage required for the
REAL: central (nonpageable) storage job.
See page 20-10

BYTES={nnnnnn } nnnnnn: 0 - 999999 Indicates the maximum

{([nnnnnn][,CANCEL]) } amount of output to be
{([nnnnnn][,DUMP]) } printed for the job’s
{([nnnnnn][,WARNING])} sysout data sets, in
thousands of bytes, and
See page 20-11 the action the system is
to take if the maximum is
exceeded.

CARDS={nnnnnnnn } nnnnnnnn: 0 - 99999999 Indicates the maximum

{([nnnnnnnn][,CANCEL]) } amount of output, in
{([nnnnnnnn][,DUMP]) } cards, to be punched for
{([nnnnnnnn][,WARNING])} the job’s sysout data
sets, and the action the
See page 20-13 system is to take if the
maximum is exceeded.

CCSID=nnnnn nnnnn: 1 - 65535 Specifies the coded

character set identifier
indicating the character
code conversion
performed on reads from
and writes to tapes
accessed in ISO/ANSI
Version 4 format.

CLASS=jobclass jobclass: A - Z, 0 - 9 In a non-APPC

scheduling environment,
See page 20-16 assigns the job to a job
class.

COND=((code,operator)[,(code,operator)]...) code: 0 - 4095 Specifies the return code

operator: GT Code from tests used to determine
See page 20-17 GE chart on whether a job will
EQ page continue processing or
20-19 be terminated.
LT
LE
NE

GROUP=group-name group-name: 1 - 8 alphanumeric or In a non-APPC

national characters ($, #, @) scheduling environment,
See page 20-19 identifies a group to
which a RACF-defined
user is to be connected.
|| JESLOG= {SPIN} SPIN: JESLOG is spin-eligible. There Has meaning when the
|| {NOSPIN} is an optional second operand that subsystem is a version
| {SUPPRESS} specifies the time or the time interval. of JES2 or JES3 that
| supports this function. It
| See page 20-21 NOSPIN: JESLOG will not be spun. specifies whether the
| JESLOG data set should
|| SUPPRESS: JESLOG will be be spin-eligible and if it
|| suppressed. should be automatically
| spun at a particular time
| or time interval.

Chapter 20. JOB Statement 20-3

JOB
KEYWORD PARAMETERS VALUES PURPOSE

LINES={nnnnnn } nnnnnn: 0 - 999999 Indicates the maximum

{([nnnnnn][,CANCEL]) } amount of output to be
{([nnnnnn][,DUMP]) } printed for the job’s
{([nnnnnn][,WARNING])} sysout data sets, in
thousands of lines, and
See page 20-22 the action the system is
to take if the maximum is
exceeded.

MEMLIMIT={nnnnnM} nnnnn: 0 - 99999 Specifies the limit on the

{nnnnnG} total number of usable
{nnnnnT} virtual pages above the
{nnnnnP} bar for a single address
{NOLIMIT} space.

See page 20-24

MSGCLASS=class class: A - Z, 0 - 9 In a non-APPC

scheduling environment,
See page 20-25 assigns the job log to an
output class.

MSGLEVEL=([statements][,messages]) statements: Indicates the job control

0 Only JOB statement information to be printed
See page 20-26 1 All JCL and procedure in the job log.
statements
2 Only JCL statements

messages:
0 Only JCL messages
1 JCL, JES, and operator
messages

NOTIFY={nodename.userid} nodename: 1 - 8 alphanumeric or In a non-APPC

{userid } national characters ($, #, @) scheduling environment,
requests that the system
See page 20-28 userid: 1 - 8 alphanumeric or national send a message to a
characters ($, #, @), 1 - 7 userid when this
alphanumeric or national characters background job
($, #, @) when userid specified completes.
without nodename

PAGES={nnnnnnnn } nnnnnnnn: 0 - 99999999 Indicates the maximum

{([nnnnnnnn][,CANCEL]) } amount of output, in
{([nnnnnnnn][,DUMP]) } pages, to print for the
{([nnnnnnnn][,WARNING])} job’s sysout data sets,
and the action the
See page 20-30 system is to take if the
maximum is exceeded.

PASSWORD=(password[,new-password]) password or new-password: 1 - 8 In a non-APPC

alphanumeric or national characters scheduling environment,
See page 20-31 ($, #, @) identifies the current
RACF password or
specifies a new RACF
password.

20-4 z/OS V1R3.0 MVS JCL Reference

 JOB
KEYWORD PARAMETERS VALUES PURPOSE

PERFORM=n n: 1 - 999 In WLM compatibility

mode, specifies the job’s
See page 20-33 performance group.

In WLM goal mode, can

be used for classification
of the job to a service
class or report class.

PRTY=priority priority (JES2): 0 - 15 priority (JES3): In a non-APPC

0 - 14 scheduling environment,
See page 20-36 JES2: Assigns the job’s
queue selection priority.
JES3: Assigns the job’s
initiation or selection
priority in its job class.

RD= {R } R: restart, checkpoints allowed In a non-APPC

{RNC} RNC: restart, no checkpoints scheduling environment,
{NR } NR: no restart, checkpoints allowed indicates whether the
{NC } NC: no restart, no checkpoints operator should perform
automatic step restart, if
See page 20-37 the job fails, and controls
whether checkpoints are
written for CHKPT
macros or DD statement
CHKPT parameters.

REGION= {valueK} valueK: 1 - 7 digits Specifies the amount of

{valueM} from 1 - 2096128 space in kilobytes or
valueM: 1 - 4 digits megabytes required by
See page 20-40 from 1 - 2047 the job.

RESTART= ({* } [,checkid] ) *: at first step In a non-APPC

{stepname } stepname: at named step scheduling environment,
{stepname.procstepname} procstepname: step is in named specifies restart of a job
procedure at the beginning of a
See page 20-42 checkid: at checkpoint in first or step or from a
named step checkpoint within a step.

SECLABEL=seclabel-name seclabel-name: 1 - 8 alphanumeric or In a non-APPC

$, #, @, characters scheduling environment,
See page 20-45 identifies the security
label of the job to RACF.

SCHENV=schenv-name schenv-name: 1 - 16 alphanumeric or In a non-APPC

$, #, @, _ characters scheduling environment,
See page 20-46 identifies the name of the
WLM scheduling
environment associated
with this job.

Chapter 20. JOB Statement 20-5

JOB
KEYWORD PARAMETERS VALUES PURPOSE

TIME= {([minutes][,seconds])} minutes: 1 - 357912 Specifies the maximum

{1440 } time the job is to use the
{NOLIMIT } seconds: 1 - 59 processor and requests
{MAXIMUM } messages giving the
1440: Specifies that the job can use time used.
See page 20-47 the processor for an unlimited amount
of time.

NOLIMIT: Specifies that the job can

use the processor for an unlimited
amount of time.

MAXIMUM: Specifies that the job can

use the processor for the maximum
amount of time, 357912 minutes.

TYPRUN= {COPY } COPY: copies job stream to sysout In a non-APPC

{HOLD } data set (JES2 only) scheduling environment,
{JCLHOLD} HOLD: holds job requests special job
{SCAN } JCLHOLD: holds job before JCL processing.
processing (JES2 only)
See page 20-50 SCAN: scans JCL for syntax errors

USER=userid userid: 1 - 7 alphanumeric or $, #, @ In a non-APPC

characters scheduling environment,
See page 20-52 identifies the job’s owner
to RACF, SRM, and
other system
components.

Comments Field
The comments field follows the parameter field after at least one intervening blank.
If you do not code any parameters on a JOB statement, do not code any
comments.

Location in the JCL

A JOB statement must be the first statement in each job. JOB statements never
appear in cataloged or in-stream procedures.

Examples of JOB Statements

//ALPHA JOB 843,LINLEE,CLASS=F,MSGCLASS=A,MSGLEVEL=(1,1)
//LOS JOB ,’J M BUSKIRK’,TIME=(4,30),MSGCLASS=H,MSGLEVEL=(2,0)
//MART JOB 1863,RESTART=STEP4 THIS IS THE THIRD JOB STATEMENT.
//TRY8 JOB
//RACF1 JOB ’D83,123’,USER=RAC01,GROUP=A27,PASSWORD=XYY
//RUN1 JOB ’D8306P,D83,B1062J12,S=C’,’JUDY PERLMAN’,MSGCLASS=R,
// MSGLEVEL=(1,1),CLASS=3,NOTIFY=D83JCS1,
// COND=(8,LT)

Accounting Information Parameter

Parameter Type

Positional, required (according to installation procedures)

Purpose

20-6 z/OS V1R3.0 MVS JCL Reference

 JOB: Accounting Information
Use the accounting information parameter to enter an account number and any
other accounting information that your installation requires.

References

For more information on how to add accounting routines, see z/OS MVS System
Management Facilities (SMF).

Syntax
([account-number][,accounting-information]...)

Location: Code the accounting information parameter first in the parameter field.

Omission: If you omit the accounting information parameter but you are coding a
programmer’s name parameter, code a comma to indicate the omitted parameter. If you
omit both positional parameters, do not code any commas before the first keyword
parameter.

Length: The entire accounting information parameter must not exceed 143 characters:
v Including any commas, which are considered part of the information.
v Excluding any enclosing parentheses, which are not considered part of the information.

Multiple Subparameters: When the accounting information parameter consists of more

than one subparameter, separate the subparameters by commas and enclose the
parameter in parentheses or apostrophes. For example, (5438,GROUP6) or
'5438,GROUP6'. If you use apostrophes, all information inside the apostrophes is
considered one field.

Special Characters: When a subparameter contains special characters, other than

hyphens, enclose it in apostrophes and the entire parameter in parentheses or enclose all
of the parameter in apostrophes. For example, (12A75,'DEPT/D58',706) or
'12A75,DEPT/D58,706'. Code each apostrophe or ampersand that is part of the accounting
information as two consecutive apostrophes or ampersands. For example, code DEPT'D58
as (12A75,'DEPT''D58',706) or '12A75,DEPT''D58,706'. Code 34&251 as '34&&251'.

Continuation onto Another Statement: Enclose the accounting information parameter in

parentheses. End each statement with a comma after a complete subparameter. For
example:
//JOB1 JOB (12A75,’DEPT/D58’,
// 706)

Subparameter Definition
account-number
Specifies an accounting number, as defined by the installation.
accounting-information
Specifies more information, as defined by the installation. For example, your
department and room numbers.

Relationship to Other Control Statements

If you are to provide accounting information for an individual step within a job, code
an ACCT parameter on the EXEC statement for that step.

Chapter 20. JOB Statement 20-7

JOB: Accounting Information
JES2 Accounting Information Format
Except for the first subparameter, the JES2 accounting information shown in the
syntax can, alternatively, appear on the JES2 /*JOBPARM statement. If you code
the accounting information parameter in the JES2 format, JES2 can interpret and
use it.

References

For a discussion of the JES2 scan of the accounting information parameter, see
z/OS JES2 Initialization and Tuning Guide.

Syntax
(pano,room,time,lines,cards,forms,copies,log,linect)

Code a comma in place of each omitted subparameter when other subparameters follow.

Subparameter Definition
pano
Specifies the programmer’s accounting number. pano is 1 through 4
alphanumeric characters.
room
Specifies the programmer’s room number. room is 1 through 4 alphanumeric
characters.
time
Specifies the estimated execution time in minutes. time is 1 through 4 decimal
numbers. For example, code 30 for 30 minutes. If you omit a time
subparameter and a TIME parameter on the JES2 /*JOBPARM statement,
JES2 uses an installation default specified at initialization. If job execution
exceeds the time, JES2 sends a message to the operator.
lines
Specifies the estimated line count, in thousands of lines, from this job’s sysout
data sets. lines is 1 through 4 decimal numbers. For example, code 5 for 5000
lines. If you omit lines, JES2 uses an installation default specified at
initialization.
cards
Specifies the estimated number of cards JES2 is to punch from this job’s sysout
data sets. cards is 1 through 4 decimal numbers. If you omit cards, JES2 uses
an installation default specified at initialization.
forms
Specifies the forms that JES2 is to use for printing this job’s sysout data sets.
forms is 1 through 4 alphanumeric characters. For example, code 5 for 5-part
forms. If you omit forms, JES2 uses an installation default specified at
initialization.
copies
Specifies the number of times JES2 is to print and/or punch this job’s sysout
data sets. copies is 1 through 3 decimal numbers not exceeding an
installation-specified limit. The maximum is 255. For example, code 2 for two
copies. If you omit copies, JES2 assumes one copy.

20-8 z/OS V1R3.0 MVS JCL Reference

 JOB: Accounting Information
The copies subparameter is ignored and only one copy is produced if the output
class for the job log, as specified in the JOB MSGCLASS parameter, or the
output class of any of the job’s system output data sets is a held class.
log
Specifies whether or not JES2 is to print the job log. Code N to request no job
log. If you code any other character or omit this subparameter, JES2 prints the
job log. If your installation specified NOLOG for this job’s class during JES2
initialization, JES2 will not print a job log.
linect
Specifies the number of lines JES2 is to print per page for this job’s sysout data
sets. linect is 1 through 3 decimal numbers. When you send a data set across a
network, linect cannot exceed 254. When you print the data set locally, linect
cannot exceed 255. If you omit linect, JES2 uses an installation default
specified at initialization. If you code a zero, JES2 does not eject to a new page
when the number of lines exceeds the installation default.

Invalid Subparameters

Your installation can initialize JES2 to do one of the following if the accounting
information contains subparameters that are invalid to JES2:
v Ignore the invalid subparameters.
v Terminate the job. In this case, JES2 requires the first two subparameters: pano
and room.

Overrides

A parameter on any of the following statements overrides an equivalent accounting

information subparameter on the JOB statement:
v JOB statement
v JES2 /*JOBPARM statement
v JES2 /*OUTPUT statement
v OUTPUT JCL statement
v DD statement

Examples of the Accounting Information Parameter

Example 1
//JOB43 JOB D548-8686

Example 2
//JOB44 JOB (D548-8686,’12/8/85’,PGMBIN)

Because this statement contains an account-number plus additional

accounting-information, parentheses are required.

Example 3
//JOB45 JOB (CFH1,2G14,15,,,,2)

This statement shows a JES2 accounting information parameter: programmer’s

accounting number, CFH1; room number, 2G14; estimated job time, 15 minutes;
and copies, 2. Parentheses are required. Standard values are assumed for the
other JES2 subparameters.

Chapter 20. JOB Statement 20-9

JOB: ADDRSPC

ADDRSPC Parameter
Parameter Type

Keyword, optional

Purpose

Use the ADDRSPC parameter to indicate to the system that the job requires virtual
storage (which is pageable) or central storage (also called real storage, which is
nonpageable).

Syntax
ADDRSPC= {VIRT}
{REAL}

Subparameter Definition
VIRT
Requests virtual storage. The system can page the job.
REAL
Requests central storage (also called real storage). The system cannot page
the job and must place each step of the job in central storage.

Defaults
If no ADDRSPC parameter is specified, the default is VIRT.

Overrides
The JOB statement ADDRSPC parameter applies to all steps of the job and
overrides any EXEC statement ADDRSPC parameters.

Code EXEC statement ADDRSPC parameters when each job step requires different
types of storage. The system uses an EXEC statement ADDRSPC parameter only
when no ADDRSPC parameter is on the JOB statement and only during the job
step.

Relationship to the JOB REGION Parameter

When ADDRSPC=REAL

Code a REGION parameter to specify how much central storage (also called real
storage) the job needs. If you omit the REGION parameter, the system uses an
installation default specified at JES initialization.

When ADDRSPC=VIRT or ADDRSPC is Omitted

Code a REGION parameter to specify how much virtual storage the job needs. If
you omit the REGION parameter, the system uses an installation default specified
at JES initialization.

20-10 z/OS V1R3.0 MVS JCL Reference

 JOB: ADDRSPC
Examples of the ADDRSPC Parameter
Example 1
//PEH JOB ,BAKER,ADDRSPC=VIRT

The ADDRSPC parameter requests virtual (pageable) storage. The space available
to the job is the installation-specified default.

Example 2
//DEB JOB ,ERIC,ADDRSPC=REAL,REGION=100K

The ADDRSPC parameter requests central (nonpageable) storage. The REGION

parameter specifies 100K of storage for the job.

BYTES Parameter
Parameter Type

Keyword, optional

Purpose

Use the BYTES parameter to:

v Indicate the maximum amount of output, in thousands of bytes, to be printed for
this job’s sysout data sets
v Specify the action that the system is to take if the maximum is exceeded. You
can indicate that the job is to be cancelled with or without a dump, or that the job
is to continue and the system is to notify the operator that the maximum was
exceeded.

Syntax
BYTES={nnnnnn }
{([nnnnnn][,CANCEL]) }
{([nnnnnn][,DUMP]) }
{([nnnnnn][,WARNING])}

Subparameter Definition
nnnnnn
Indicates the maximum amount of output to be printed for this job, in thousands
of bytes. An nnnnnn value of 500 represents 500,000 bytes. The value for
nnnnnn is 0 through 999999.
In a JES2 system, a value of 0 for nnnnnn will produce an amount of output
that is based on the record blocking factor. When the system recognizes that
the 0 value has been exceeded, one of the following will get control:
v The CANCEL, DUMP, or WARNING option (if coded)
v The installation exit.

In a JES3 system, a value of 0 for nnnnnn will cause JES3 to use the system
default defined at initialization.

Chapter 20. JOB Statement 20-11

JOB: BYTES
CANCEL
Indicates that the system is to cancel the job without dumping storage when the
output for the job exceeds the maximum.
DUMP
Indicates that the system is to cancel the job when the output for the job
exceeds the maximum, and requests a storage dump.
WARNING
Indicates that the job is to continue, and the system is to send a message to
the operator, when the output for the job exceeds the maximum. The system
issues subsequent warning messages at an interval defined by the installation.

Defaults
If you do not code the BYTES parameter, the system uses the installation-defined
default value.

If you do not code nnnnnn, the system uses an installation-defined limit.

If you do not code CANCEL, DUMP, or WARNING, the system uses the
installation-defined default option.

Overrides
Specifying BYTES on the JOB statement overrides BYTES on the JES2
/*JOBPARM statement, the JES3 //*MAIN statement, and the installation-defined
default.

Relationship to Other Parameters

In addition to BYTES, the following parameters also limit the amount of output for a
job.
CARDS
LINES
PAGES

If the job’s output exceeds the limits defined by any of the parameters above, the
system might cancel the job. When coding BYTES, determine whether the values
coded on these related parameters are sufficient to produce the output you require.

Relationship to Other Control Statements

The OUTLIM parameter of the DD statement controls the number of logical records
in the sysout data set defined by that DD statement. If the sysout limit defined on
the BYTES parameter is exceeded before the limit defined on OUTLIM, the system
will take the action defined on BYTES. If the sysout limit defined on the OUTLIM
parameter is exceeded before the limit defined on BYTES, the system exits to the
sysout limit exit routine.

Examples of the BYTES Parameter

Example 1
//JOB1 JOB (123456),’R F B’,BYTES=(500,CANCEL)

In this example, the job JOB1 will be cancelled when its output exceeds 500
thousand bytes. The system will not produce a storage dump.

Example 2

20-12 z/OS V1R3.0 MVS JCL Reference

 JOB: BYTES
//JOB2 JOB (123456),’R F B’,BYTES=40

In this example, when the output for JOB2 exceeds 40 thousand bytes, the
installation default determines whether the job is
v Cancelled, and a dump is requested
v Cancelled, and no dump is requested
v Allowed to continue, with a warning message issued to the operator.

CARDS Parameter
Parameter Type

Keyword, optional

Purpose

Use the CARDS parameter to:

v Indicate the maximum amount of output, in cards, to be punched for this job’s
sysout data sets
v Specify the action that the system is to take if the maximum is exceeded. You
can indicate that the job is to be cancelled with or without a dump, or that the job
is to continue and the system is to notify the operator that the maximum was
exceeded.

Syntax
CARDS={nnnnnnnn }
{([nnnnnnnn][,CANCEL]) }
{([nnnnnnnn][,DUMP]) }
{([nnnnnnnn][,WARNING])}

Subparameter Definition
nnnnnnnn
Indicates the maximum number of sysout output cards to be punched for this
job. For JES2 systems, nnnnnnnn is a value from 0 to 99999999. For JES3
systems, nnnnnnnn is a value from 0 through 6500000. If you specify a value
greater than 6500000 in a JES3 system, it will be treated as 6500000.
In a JES2 system, a value of 0 for nnnnnnnn will produce an amount of output
that is based on the record blocking factor. When the system recognizes that
the 0 value has been exceeded, one of the following will get control:
v The CANCEL, DUMP, or WARNING option (if coded)
v The installation exit.

In a JES3 system, a value of 0 for nnnnnnnn will produce no output.

CANCEL
Indicates that the system is to cancel the job without dumping storage when the
output for the job exceeds the maximum.
DUMP
Indicates that the system is to cancel the job when the output for the job
exceeds the maximum, and requests a storage dump.

Chapter 20. JOB Statement 20-13

JOB: CARDS
WARNING
Indicates that the job is to continue, and the system is to send a message to
the operator, when the output for the job exceeds the maximum. The system
issues subsequent warning messages at an interval defined by the installation.

Defaults
If you do not code the CARDS parameter, the system uses the installation-defined
default value.

If you do not code nnnnnnnn, the system uses an installation-defined limit.

If you do not code CANCEL, DUMP, or WARNING, the system uses the
installation-defined default option.

Overrides
Specifying CARDS on the JOB statement overrides CARDS on the JES2
/*JOBPARM statement, the JES3 //*MAIN statement, the JES2 accounting
subparameter for cards on the JOB statement, and the installation-defined default.

Relationship to Other Parameters

In addition to CARDS, the following JOB statement parameters also limit the
amount of output for a job.
BYTES
LINES
PAGES

If the job’s output exceeds the limits defined by any of the parameters above, the
system might cancel the job. When coding CARDS, determine whether the values
coded on these related parameters are sufficient to produce the output you require.

Relationship to Other Control Statements

The OUTLIM parameter of the DD statement controls the number of logical records
in the sysout data set defined by that DD statement. If the sysout limit defined on
the CARDS parameter is exceeded before the limit defined on OUTLIM, the system
will take the action defined on CARDS. If the sysout limit defined on the OUTLIM
parameter is exceeded before the limit defined on CARDS, the system exits to the
sysout limit exit routine.

Examples of the CARDS Parameter

Example 1
//JOB1 JOB (123456),’R F B’,CARDS=(500,CANCEL)

In this example, the job JOB1 will be cancelled when its output exceeds 500 cards.
The system will not produce a storage dump.

Example 2
//JOB2 JOB (123456),’R F B’,CARDS=4000

In this example, when the output for JOB2 exceeds 4000 cards of output, the
installation default determines whether the job is
v Cancelled, and a dump is requested
v Cancelled, and no dump is requested
v Allowed to continue, with a warning message issued to the operator.

20-14 z/OS V1R3.0 MVS JCL Reference

 JOB: CCSID

CCSID Parameter
Parameter Type

Keyword, optional

Purpose

On systems with DFSMS/MVS Version 1 Release 5 or higher, and OS/390 Version

2 Release 5 or higher, you can request DFSMSdfp to convert data from/to the
coded character set identifier (CCSID) specified on the JOB or EXEC statement
to/from the CCSID specified on the DD statement. Data conversion is supported on
access to ISO/ANSI Version 4 tapes using access methods BSAM or QSAM, but
not using EXCP.

ISO/ANSI Version 4 tapes are identified by the LABEL=(,AL) or LABEL=(,AUL)

keyword. The CCSID parameter does not apply to ISO/ANSI Version 1 or
ISO/ANSI/FIPS Version 3 tapes or to tapes with labels other than AL or AUL. See
DFSMS/MVS Version 1 Release 5 z/OS DFSMSdfp Storage Administration
Reference and DFSMS/MVS Version 1 z/OS DFSMS: Using Data Sets for selecting
ISO/ANSI Version 4 tapes. See the latter manual for a list of supported CCSIDs.

The CCSID value of 65535 has a special meaning: it suppresses conversion.

When CCSID is not specified at the JOB, EXEC, or DD levels, data passed to
BSAM and QSAM is converted to 7-bit ASCII when writing to ISO/ANSI Version 4
tapes. This may result in data loss on conversion. On READ operations the CCSID
(if recorded) on the tape header label is used for conversion.

The CCSID is recorded in the tape header label if conversion is not defaulted.

Syntax
CCSID= nnnnn

Subparameter Definition
nnnnn
The CCSID as a decimal number from 1 through 65535.

Default
500.

Overrides
The CCSID parameter specified on the JOB statement can be overridden by
specifying the CCSID parameter on the EXEC statement.

Relationship to Other Parameters

Do not code the following parameters with the CCSID parameter:

* DDNAME QNAME
BURST DYNAM SYSOUT
CHARS FCB TERM

Chapter 20. JOB Statement 20-15

JOB: CCSID
COPIES FLASH UCS
DATA MODIFY

Examples of the CCSID Parameter

For examples of the CCSID parameter see ″CCSID Parameter″ in the chapter ″DD
Statement.″

CLASS Parameter
Parameter Type

Keyword, optional

Purpose

Use the CLASS parameter to assign the job to a class. The class you should
request depends on the characteristics of the job and your installation’s rules for
assigning classes.

Note: The CLASS parameter is ignored for a started task in a JES2 environment.
For a started task in a JES3 environment all class related attributes and
functions are ignored except device fencing, SPOOL partitioning, and track
group allocation. Refer to the z/OS JES3 Initialization and Tuning Guide for
more information about class attributes and functions.

In a JES2 system, the assigned job class can affect whether or how a job is
executed. A job class can be defined during JES2 initialization as:
v Held. The system holds any job assigned to this class until the operator releases
it.
v To be copied only. The system copies the input stream for the job directly to a
sysout data set and schedules the sysout data set for output processing. The
system does not execute the job or allocate devices.
v To be scanned for job control statement syntax errors. The system does not
execute the job or allocate devices.

In a JES2 system, there are a number of factors that determine the order in which a
particular job is selected for execution. Therefore, you cannot be assured that job
priority (based on the PRTY you assign a job), job class, or the order of job
submission will guarantee that the jobs will execute in a particular order. If you need
to submit jobs in a specific order, contact your JES2 system programmer for advice
based on how your system honors such requests. (z/OS JES2 Initialization and
Tuning Guide provides JES2 system programmer procedures concerning job
queuing and how to control job execution sequence.)

Considerations for an APPC Scheduling Environment

The CLASS parameter has no function in an APPC scheduling environment. If you

code CLASS, the system will check it for syntax and ignore it.

20-16 z/OS V1R3.0 MVS JCL Reference

 JOB: CLASS
Syntax
CLASS=jobclass

v The CLASS parameter cannot have a null value.

Subparameter Definition
jobclass
Identifies the class for the job. The jobclass is one character, A through Z or 0
through 9, and must be a valid class specified at JES initialization.

Defaults
If you do not specify the CLASS keyword, JES uses the installation default specified
at initialization, as follows:
v In a JES2 system, the default is based on the source of the job: The system
makes the job’s class the same as the installation-specified default class for the
particular card reader, work station, or time-sharing user that submitted the job.
v In a JES3 system, the default is an installation-defined standard default class.

Overrides
A JES3 //*MAIN statement CLASS parameter overrides a JOB statement CLASS
parameter.

Relationship to Other Control Statements

In JES3 systems, you can also code a CLASS parameter on a JES3 //*MAIN
statement.

Example of the CLASS Parameter

//SETUP JOB 1249,SMITH,CLASS=M

This statement assigns the job to class M.

COND Parameter
Parameter Type

Keyword, optional

Purpose

Use the COND parameter to specify the return code tests the system uses to
determine whether a job will continue processing. Before and after each job step is
executed, the system performs the COND parameter tests against the return codes
from completed job steps. If none of these tests is satisfied, the system executes
the job step; if any test is satisfied, the system bypasses all remaining job steps
and terminates the job.

The tests are made against return codes from the current execution of the job. A
step bypassed because of an EXEC statement COND parameter does not produce
a return code.

Chapter 20. JOB Statement 20-17

JOB: COND
Bypassing a step because of a return code test is not the same as abnormally
terminating the step. The system abnormally terminates a step following an error so
serious that it prevents successful execution. In contrast, bypassing of a step is
merely its omission.

Note that a test showing that a return code from a step is zero is not sufficient to
verify that the step did not fail; the system may fail a step (or job) even if the return
code is zero. This could happen, for example, as a result of specifying CATLG_ERR
FAILJOB(YES) and incurring that type of ″post execution error.″ (The return code is
generated by the application program and is never changed by the operating
system.) You can determine that a step failed due to a ″post execution error″ if bit
SMF30SYE in the two-byte SMF30STI field in the SMF30 subtype 4 record is on.

Note: In both JES2 and JES3 systems, a JOB COND parameter determines if
steps are executed or bypassed. However, JES3 processes all jobs as
though each step will execute; therefore, JES3 allocates devices for steps
that are bypassed.

Syntax
COND=(code,operator)
COND=((code,operator)[,(code,operator)]...)

v One return code test is: (code,operator)

v You can omit the outer parentheses if you code only one return code test.
v Specify up to eight return code tests for a job.
v The COND parameter cannot have a null value.

Subparameter Definition
code
Specifies a number that the system compares to the return code from each job
step. code is a decimal number from 0 through 4095.

Note: Specifying a decimal number greater than 4095 could result in invalid
return code testing or invalid return codes in messages.
operator
Specifies the type of comparison to be made to the return code. If the specified
test is true, the system bypasses all remaining job steps. Use the chart on this
page to select the correct operator. Operators and their meanings are:

Operator Meaning
GT Greater than
GE Greater than or equal to
EQ Equal to
LT Less than
LE Less than or equal to
NE Not equal to

20-18 z/OS V1R3.0 MVS JCL Reference

 JOB: COND
Overrides
If you code the COND parameter on the JOB statement and on one or more of the
job’s EXEC statements, and if a return code test on the JOB statement is satisfied,
the job terminates. In this case, the system ignores any EXEC statement COND
parameters.

If the tests on the JOB statement are not satisfied, the system then performs the
return code tests on the EXEC statement. If an EXEC return code test is satisfied,
the step is bypassed.

Summary of COND Parameters

Table 20-1. Continuation or Termination of the Job Based on the COND Parameter
Return Code (RC) from the Just Completed Step
Test in the COND
Parameter Continue Job Terminate Job
COND=(code,GT) RC >= code RC < code
COND=(code,GE) RC > code RC <= code
COND=(code,EQ) RC ¬= code RC = code
COND=(code,LT) RC <= code RC > code
COND=(code,LE) RC < code RC >= code
COND=(code,NE) RC = code RC ¬= code

Examples of the COND Parameter

Example 1
//TYPE JOB (611,402),BOURNE,COND=(7,LT)

The COND parameter specifies that if 7 is less than the return code, the system
terminates the job. Any return code less than or equal to 7 allows the job to
continue.

Example 2
//TEST JOB 501,BAXTER,COND=((20,GE),(30,LT))

The COND parameter specifies that if 20 is greater than or equal to the return code
or if 30 is less than the return code, the system terminates the job. Any code of 21
through 30 allows the job to continue.

GROUP Parameter
Parameter Type

Keyword, optional

Note: Do not specify this parameter for a started task; if GROUP is specified, the
job will fail.

Purpose

Chapter 20. JOB Statement 20-19

JOB: GROUP
Use the GROUP parameter to specify a RACF-defined group to which a
RACF-defined user is to be connected. RACF places each RACF-defined user in a
default group; the GROUP parameter is needed only to specify a group other than
a user’s default group.

If the installation contains the feature for propagation of the user and group
identification, the USER and PASSWORD parameters are required, and the
GROUP parameter is optional on JOB statements only for the following:
v Batch jobs submitted through an input stream, such as a card reader, if:
– the job requires access to RACF-protected resources, or
– the installation requires that all jobs have RACF identification.
v Jobs submitted by one RACF-defined user for another user. In this case, the JOB
statement must specify the other user’s userid and may need a password. The
group id is optional.
v Jobs that execute at another network node that uses RACF protection.

Otherwise, the USER, PASSWORD, and GROUP parameters can be omitted from
JOB statements. RACF uses the userid, password, and default group id of the
submitting TSO/E user or job.

References

For more information on RACF-protected facilities, see the z/OS Security Server
RACF Security Administrator’s Guide.

Considerations for an APPC Scheduling Environment

The GROUP parameter has no function in an APPC scheduling environment. If you

code GROUP, the system will check it for syntax and ignore it.

Syntax
GROUP=group-name

Subparameter Definition
group-name
Identifies the group with which the system is to associate the user. group-name
is 1 through 8 alphanumeric or national ($, #, @) characters. The first character
must be alphabetic or national ($, #, @).

Defaults
If you do not code the GROUP parameter, but do code the USER and PASSWORD
parameters, the system assigns the RACF default group name associated with the
specified userid. However, the default group name is not passed to JES and thus is
not available to JES installation exits.

Example of the GROUP Parameter

//TEST JOB ’D83,123456’,GROUP=MYGROUP,USER=MYNAME,PASSWORD=ABC

This statement requests that the system connect RACF-defined user MYNAME to
the group named MYGROUP for the duration of the job.

20-20 z/OS V1R3.0 MVS JCL Reference

 JOB: JESLOG

| JESLOG Parameter
| Parameter Type

| Keyword, optional

| Purpose

| Use the JESLOG parameter to indicate whether the JESLOG data set should be
| spin-eligible and if it should be automatically spun at a particular time or time
| interval. JESLOG has meaning when the subsystem is a version of JES2 or JES3
| that supports this function.

| Syntax
|
| JESLOG= {SPIN}
| {NOSPIN}
| {SUPPRESS}
|
|
|

| Subparameter Definition
| SPIN
| JESLOG is spin-eligible. There is an optional second operand.
| JESLOG=(SPIN,hh:mm)
| JESLOG will be spun at time hh:mm each 24 hour period. “hh” is hours and
| has a range of 00 through 23. “mm” is minutes and has a range of 00
| through 59.
| JESLOG=(SPIN,+hh:mm)
| JESLOG will be spun every hh:mm time interval. “hh” is hours and has a
| range of 00 through 23. “mm” is minutes and has a range of 00 through 59.
| The minimum interval which can be specified is 10 minutes. Note that “hh”
| must be specified even if zero. For example, JESLOG=(SPIN,0:20)
| JESLOG=(SPIN,nnn)
| JESLOG=(SPIN,nnnK)
| JESLOG=(SPIN,nnnM)
| JESLOG will be spun when either data set has “n” lines. A minimum of 500
| lines must be specified. “K” is thousands and “M” is millions.
| NOSPIN
| JESLOG will not be spun.
| SUPPRESS
| JESLOG will be suppressed.

| Defaults
| If no JESLOG parameter is specified, the default is NOSPIN.

| Examples of the JESLOG Parameter

| Example 1
| //PEH JOB ,BAKER,JESLOG=(SPIN,+08:00)

| The JESLOG parameter requests that JESLOG be spun every 8 hours.

Chapter 20. JOB Statement 20-21

 JOB: JESLOG
| Example 2
| //DEB JOB ,ERIC,JESLOG=(SPIN,090K)

| The JESLOG parameter requests that JESLOG be spun every 90,000 lines.

LINES Parameter
Parameter Type

Keyword, optional

Purpose

Use the LINES parameter to:

v Indicate the maximum amount of output, in thousands of lines, to be printed for
this job’s sysout data sets
v Specify the action that the system is to take if the maximum is exceeded. You
can indicate that the job is to be cancelled with or without a dump, or that the job
is to continue and the system is to notify the operator that the maximum was
exceeded.

Syntax
LINES={nnnnnn }
{([nnnnnn][,CANCEL]) }
{([nnnnnn][,DUMP]) }
{([nnnnnn][,WARNING])}

Subparameter Definition
nnnnnn
Indicates the maximum amount of output to be printed for this job, in thousands
of lines. An nnnnnn value of 500 represents 500,000 lines. The value for
nnnnnn is 0 through 999999.
In a JES2 system, a value of 0 for nnnnnn will produce an amount of output
that is based on the record blocking factor. When the system recognizes that
the 0 value has been exceeded, one of the following will get control:
v The CANCEL, DUMP, or WARNING option (if coded)
v The installation exit.

In a JES3 system, a value of 0 for nnnnnn produces no output.

CANCEL
Indicates that the system is to cancel the job without dumping storage when the
output for the job exceeds the maximum.
DUMP
Indicates that the system is to cancel the job when the output for the job
exceeds the maximum, and requests a storage dump.
WARNING
Indicates that the job is to continue, and the system is to send a message to
the operator, when the output for the job exceeds the maximum. The system
issues subsequent warning messages at an interval defined by the installation.

20-22 z/OS V1R3.0 MVS JCL Reference

 JOB: LINES
Defaults
If you do not code the LINES parameter, the system uses the installation-defined
default value.

If you do not code nnnnnn, the system uses an installation-defined limit.

If you do not code CANCEL, DUMP, or WARNING, the system uses the
installation-defined default option.

Overrides
Specifying LINES on the JOB statement overrides LINES on the JES2 /*JOBPARM
statement, the JES3 //*MAIN statement, the JES2 accounting subparameter for
lines on the JOB statement, and the installation-defined default.

Relationship to Other Parameters

In addition to LINES, the following JOB statement parameters also limit the amount
of output for a job.
BYTES
CARDS
PAGES

If the job’s output exceeds the limits defined by any of the parameters above, the
system might cancel the job. When coding LINES, determine whether the values
coded on these related parameters are sufficient to produce the output you require.

Relationship to Other Control Statements

The OUTLIM parameter of the DD statement controls the number of logical records
in the sysout data set defined by that DD statement. If the sysout limit defined on
the LINES parameter is exceeded before the limit defined on OUTLIM, the system
will take the action defined on LINES. If the sysout limit defined on the OUTLIM
parameter is exceeded before the limit defined on LINES, the system exits to the
sysout limit exit routine.

Examples of the LINES Parameter

Example 1
//JOB1 JOB (123456),’R F B’,LINES=(500,CANCEL)

In this example, the job JOB1 will be cancelled when its output exceeds 500
thousand lines. The system will not produce a storage dump.

Example 2
//JOB2 JOB (123456),’R F B’,LINES=40

In this example, when the output for JOB2 exceeds 40 thousand lines, the
installation default determines whether the job is
v Cancelled, and a dump is requested
v Cancelled, and no dump is requested
v Allowed to continue, with a warning message issued to the operator.

Chapter 20. JOB Statement 20-23

JOB: MEMLIMIT

MEMLIMIT Parameter
Parameter Type

Keyword, optional

Purpose

Use the MEMLIMIT parameter to specify the limit on the total number of usable
virtual pages above the bar for a single address space.

Syntax
MEMLIMIT={nnnnnM}
{nnnnnG}
{nnnnnT}
{nnnnnP}
{NOLIMIT}

Subparameter Definition
nnnnnM
nnnnnG
nnnnnT
nnnnnP
Specifies a value to be used as the limit on the total number of usable virtual
pages above the bar in a single address space. The value may be expressed in
megabytes (M), gigabytes (G), terabytes (T), or petabytes (P). nnnnn may be a
value from 0 to 99999.
NOLIMIT
Specifies that there is no limit on the virtual pages to be used above the bar.

Defaults
If no MEMLIMIT parameter is specified, the default is the value defined to SMF,
except when REGION=0K/0M is specified, in which case the default is NOLIMIT.

Overrides
Specifying MEMLIMIT on the JOB statement overrides MEMLIMIT on the EXEC
statement.

If MEMLIMIT is not specified, SMF provides a default value. The IEFUSI installation
exit can override any JCL- or SMF-supplied value.

Examples of the MEMLIMIT Parameter

//TEST JOB ’D83,123456’,MEMLIMIT=10000M

This statement specifies that the job is limited to the use of 10000 megabytes of
usable virtual pages above the bar.

20-24 z/OS V1R3.0 MVS JCL Reference

 JOB: MSGCLASS

MSGCLASS Parameter
Parameter Type

Keyword, optional

Purpose

Use the MSGCLASS parameter to assign the job log to an output class. The job log
is a record of job-related information for the programmer. Depending on the JOB
statement MSGLEVEL parameter, the job log can consist of:
v Only the JOB statement.
v All job control statements.
v In-stream and cataloged procedure statements.
v Job control statement messages.
v JES and operator messages about the job.

Note: In a JES3 environment, a job can complete processing before all of its
messages have been written to the job log. When this occurs, the job’s
output is incomplete. For this reason, do not use the contents of the job log
as an automation or as a programming interface.

Considerations for an APPC Scheduling Environment

The MSGCLASS parameter has no function in an APPC scheduling environment. If

you code MSGCLASS, the system will check it for syntax and ignore it.

Syntax
MSGCLASS=class

Subparameter Definition
class
Identifies the output class for the job log. The class is one character, A through
Z or 0 through 9, and must be a valid output class specified at JES initialization.

NJE Note: If you specify an output class that is a held class in an NJE
environment, the system does not hold the data set until it reaches its ultimate
destination node.

Defaults
The default is based on the source of the job: The system places the job log in the
same output class as the installation-specified default class for the particular card
reader, work station, or time-sharing user that submitted the job. The installation
default is specified at JES initialization.

Significance of Output Classes

To print the job log and any output data sets on the same output listing, code one of
the following:
v The same output class in the DD SYSOUT parameter as in the JOB MSGCLASS
parameter.

Chapter 20. JOB Statement 20-25

JOB: MSGCLASS
v DD SYSOUT=* to default to the JOB MSGCLASS output class.
v DD SYSOUT=(,) to default to one of the following:
1. The CLASS parameter in an explicitly or implicitly referenced OUTPUT JCL
statement. In this case, the OUTPUT JCL CLASS parameter should specify
the same output class as the JOB MSGCLASS parameter.
2. The JOB MSGCLASS output class, if no OUTPUT JCL statement is
referenced or if the referenced OUTPUT JCL statement contains either
CLASS= or CLASS=*.

Examples of the MSGCLASS Parameter

Example 1
//EXMP1 JOB ,GEORGE,MSGCLASS=F

In this example, the JOB statement specifies output class F for the job log.

Example 2
//EXMP2 JOB ,MENTLE,MSGLEVEL=(2,0)

This JOB statement does not specify an output class. In this case, the output class
defaults to the installation default output class for the device from which the job was
submitted.

Example 3
//A1403 JOB ,BLACK,MSGCLASS=L
//STEP1 EXEC PGM=PRINT
//OUTDD1 DD SYSOUT=L

In this example, the JOB statement and sysout DD statement OUTDD1 both specify
the same output class. Consequently, the job log and data set OUTDD1 are written
on the same output listing.

Example 4
//B209 JOB ,WHITE,MSGCLASS=M
//STEPA EXEC PGM=PRINT
//OUTDDX DD SYSOUT=*

In this example, the JOB statement specifies that the system route the job log to
output class M. The system also routes sysout data set OUTDDX to class M
because SYSOUT=* is specified.

MSGLEVEL Parameter
Parameter Type

Keyword, optional

Purpose

Use the MSGLEVEL parameter to control the listing of the JCL output for the job.
You can request that the system print the following:
v The JOB statement and all comments and JECL statements up to the first EXEC
statement.
v All job control statements in the input stream, that is, all JCL statements and
JES2 or JES3 statements.

20-26 z/OS V1R3.0 MVS JCL Reference

 JOB: MSGLEVEL
v In-stream and cataloged procedure statements for any procedure a job step calls.
v Messages about job control statements.
v JES and operator messages about the job’s processing: allocation of devices and
volumes, execution and termination of job steps and the job, and disposition of
data sets.

Considerations for an APPC Scheduling Environment

For information about using the MSGLEVEL parameter in a TP message log

definition, see z/OS MVS Planning: APPC/MVS Management.

Syntax
MSGLEVEL=([statements][,messages])

You can omit the parentheses if you code only the first subparameter.

Subparameter Definition
The JCL output for a batch job or any piece of work handled by JES2 or JES3 is a
collection of three data sets. These three data sets (in the order they appear in the
output) are:
JES JOB LOG (JESMSG)
STATEMENT IMAGES (JESJCL)
SYSTEM MESSAGES (SYSMSG)
statements
Indicates which job control statements the system is to print in the statement
images portion of the JCL output. This subparameter is one of the following
numbers:
0 The system prints the JOB statement and all comments and JECL
statements up to the first EXEC statement.
1 The system prints all JCL statements, JES2 or JES3 control
statements, the procedure statements, and IEF653I messages, which
give the values assigned to symbolic parameters in the procedure
statements.
2 The system prints only JCL statements and JES2 or JES3 control
statements.
messages
Indicates which messages the system is to print in the system messages
portion of the JCL output. This subparameter is one of the following numbers:
0 The system prints only JCL messages. It prints JES and operator
messages only if the job abnormally terminates, and prints SMS
messages only if SMS fails the job.
1 The system prints JCL, JES, operator, and SMS messages.

Defaults
If you do not code the MSGLEVEL parameter, JES uses an installation default
specified at initialization.

Chapter 20. JOB Statement 20-27

 JOB: MSGLEVEL
Examples of the MSGLEVEL Parameter
Example 1
//EXMP3 JOB ,GEORGE,MSGLEVEL=(2,1)

In this example, the JOB statement requests that the system print JCL statements,
JCL messages, JES and operator messages, and SMS messages.

Example 2
//EXMP4 JOB ,MENTLE,MSGLEVEL=0

In this example, the JOB statement requests that the system print the JOB
statement and any comments and JECL statements up to the first EXEC statement;
and, that JES is to use the installation default for messages.

Example 3
//EXMP5 JOB ,MIKE,MSGLEVEL=(,0)

In this example, the JOB statement requests that JES use the installation default for
printing JCL statements and the system is not to print JES and operator messages
unless the job abnormally terminates. SMS messages are printed only if SMS fails
the job.

NOTIFY Parameter
Parameter Type

Keyword, optional

Purpose

Use the NOTIFY parameter to request that the system send a message to a user
when this background job completes processing.

Considerations for an APPC Scheduling Environment

The NOTIFY parameter has no function in an APPC scheduling environment. If you

code NOTIFY, avoid possible syntax and runtime errors by reading the information
about scheduler JCL for TP profiles in z/OS MVS Planning: APPC/MVS
Management.

Syntax
|
| The NOTIFY parameter for both JES2 and JES3 is the following:
|
| NOTIFY={nodename.userid}
| {userid }
|

Subparameter Definition for JES2 Systems

nodename.userid
Identifies a node and a TSO/E or VM userid at that node. The nodename is a
symbolic name defined by the installation during initialization; nodename is 1
through 8 alphanumeric or national ($, #, @) characters. The first character of

20-28 z/OS V1R3.0 MVS JCL Reference

 JOB: NOTIFY
nodename must be alphabetic or national ($, #, @). The userid must be defined
at the node. It is 1 through 8 alphanumeric or national ($, #, @) characters; the
first character must be alphabetic or national ($, #, @).
userid
Identifies the user that the system is to notify. The userid is 1 through 7
alphanumeric or national ($, #, @) characters. The first character must be an
alphabetic or national ($, #, @) character. When you specify only a userid,
JES2 assumes that the userid is at the origin node.
The userid may also be a valid remote ID in the form Rnnnn or a destid for a
remote. If the userid is specified as R1-R9999, JES2 will assume the notify
message is intended for a remote and not a userid. If the remote is defined to
the system or is less than the highest defined remote for your system, the notify
message is queued to the remote. If the remote value is greater than the
highest defined remote but less than the maximum allowed remote, the notify
message is discarded. If the Rxxxx value specified is greater than R9999, JES2
will consider that as a TSO/E userid and not a remote id.

Subparameter Definition for JES3 Systems

userid
Identifies the user that the system is to notify. The userid is 1 through 7
alphanumeric characters and must be a valid TSO/E userid. JES3 assumes that
the userid is at the node where the job runs.

Receiving Notification of Job Completion

In a JES2 System

If you are logged on to the member of the JES2 multi-access spool from which you
submitted the job, the system immediately notifies you when the job completes. If
you are not logged on, the system saves the message until you log on to the
member from which you originally submitted the job.

In a JES3 System

If you are logged on, the system immediately notifies you at the system you are
logged onto when the job completes. If you are not logged on, the system saves
the message until you log on to the system from which you originally submitted the
job.

If you want to receive notification at a system of your choice, specify the system
you want to be notified at on the ACMAIN parameter.

If a job is submitted by another job, the ACMAIN parameter specified for the first job
is propagated to the second job.

If a //*ROUTE or XMIT JCL statement follows the JOB statement, you may not be
notified when the transmitted job completes.

Examples of the NOTIFY Parameter

//SIGN JOB ,TKLOMP,NOTIFY=VMNODE.VMUSERID

When the job SIGN completes processing, the system sends a message to user
VMUSERID on node VMNODE.
//SIGN JOB ,TKLOMP,NOTIFY=MVSUSER

Chapter 20. JOB Statement 20-29

JOB: NOTIFY
When the job SIGN completes processing, the system sends a message to user
MVSUSER on the job’s origin node.

PAGES Parameter
Parameter Type

Keyword, optional

Purpose

Use the PAGES parameter to

v Indicate the maximum amount of output, in pages, to be printed for this job’s
sysout data sets
v Specify the action that the system is to take if the maximum is exceeded. You
can indicate that the job is to be cancelled with or without a dump, or that the job
is to continue and the system is to notify the operator that the maximum was
exceeded.

Syntax

PAGES={nnnnnnnn }
{([nnnnnnnn][,CANCEL]) }
{([nnnnnnnn][,DUMP]) }
{([nnnnnnnn][,WARNING])}

Subparameter Definition
nnnnnnnn
Indicates the maximum amount of output, in pages, to be printed for this job.
The value for nnnnnnnn is 0 through 99999999.
In a JES2 system, a value of 0 for nnnnnnnn will produce an amount of output
that is based on the record blocking factor. When the system recognizes that
the 0 value has been exceeded, one of the following will get control:
v The CANCEL, DUMP, or WARNING option (if coded)
v The installation exit.

In a JES3 system, a value of 0 for nnnnnnnn will produce no output.

CANCEL
Indicates that the system is to cancel the job without dumping storage when the
output for the job exceeds the maximum.
DUMP
Indicates that the system is to cancel the job when the output for the job
exceeds the maximum, and requests a storage dump.
WARNING
Indicates that the job is to continue, and the system is to send a message to
the operator, when the output for the job exceeds the maximum. The system
issues subsequent warning messages at an interval defined by the installation.

20-30 z/OS V1R3.0 MVS JCL Reference

 JOB: PAGES
Defaults
If you do not code the PAGES parameter, the system uses the installation-defined
default value.

If you do not code nnnnnnnn, the system uses an installation-defined limit.

If you do not code CANCEL, DUMP, or WARNING, the system uses the
installation-defined default option.

Overrides
Specifying PAGES on the JOB statement overrides PAGES on the JES2
/*JOBPARM statement, the JES3 //*MAIN statement, and the installation-defined
default.

Relationship to Other Parameters

In addition to PAGES, the following JOB statement parameters also limit the
amount of output for a job.
BYTES
CARDS
LINES

If the job’s output exceeds the limits defined by any of the parameters above, the
system might cancel the job. When coding PAGES, determine whether the values
coded on these related parameters are sufficient to produce the output you require.

Relationship to Other Control Statements

The OUTLIM parameter of the DD statement controls the number of logical records
in the sysout data set defined by that DD statement. If the sysout limit defined on
the PAGES parameter is exceeded before the limit defined on OUTLIM, the system
will take the action defined on PAGES. If the sysout limit defined on the OUTLIM
parameter is exceeded before the limit defined on PAGES, the system exits to the
sysout limit exit routine.

Examples of the PAGES Parameter

Example 1
//JOB1 JOB (123456),’R F B’,PAGES=(500,CANCEL)

In this example, the job JOB1 will be cancelled when its output exceeds 500 pages.

Example 2
//JOB2 JOB (123456),’R F B’,PAGES=40

In this example, when the output for JOB2 exceeds 40 pages, the installation
default determines whether the job is
v Cancelled, and a dump is requested
v Cancelled, and no dump is requested
v Allowed to continue, with a warning message issued to the operator.

PASSWORD Parameter
Parameter Type

Keyword, optional

Chapter 20. JOB Statement 20-31

JOB: PASSWORD
Note: Do not specify this parameter for a started task; if PASSWORD is specified,
the job will fail.

Purpose

Use the PASSWORD parameter to identify a current RACF password or specify a

new RACF password. You can specify a new password at any time and must
specify a new password when your current one expires.

If the installation contains the installation exit routine used to verify the password, a
new password specified in the PASSWORD parameter takes effect when the job is
read in. The new password takes effect even if the job is held for execution later
and may take effect even if the job fails because of JCL errors. When changing the
password, other jobs that use the new or old password may fail, depending on
when their passwords are verified.

If the installation contains the feature for propagation of the user and group
identification, the USER and the PASSWORD parameters are required, and the
GROUP parameter is optional on JOB statements only for the following:
v Batch jobs submitted through an input stream, such as a card reader, (1) if the
job requires access to RACF-protected resources or (2) if the installation requires
that all jobs have RACF identification.
v Jobs submitted by one RACF-defined user for another user. In this case, the JOB
statement must specify the other user’s userid and may need a password. The
group id is optional.
v Jobs that execute at another network node that uses RACF protection.

Otherwise, the USER, PASSWORD, and GROUP parameters can be omitted from
JOB statements. RACF uses the userid, password, and default group id of the
submitting TSO/E user or job.

References

For more information on using RACF-protected facilities, see the z/OS Security
Server RACF Security Administrator’s Guide.

Considerations for an APPC Scheduling Environment

The PASSWORD parameter has no function in an APPC scheduling environment. If

you code PASSWORD, the system will check it for syntax and ignore it.

Syntax
PASSWORD=(password[,new-password])

You can omit the parentheses if you code only the first subparameter.

Subparameter Definition
password
Specifies the user’s current RACF password. The password is 1 through 8
alphanumeric or national ($, #, @) characters.

20-32 z/OS V1R3.0 MVS JCL Reference

 JOB: PASSWORD
Note: The system suppresses the value you code for password from the
JESJCL and JESJCLIN data sets.
new-password
Specifies the user’s new RACF password. The new-password is 1 through 8
alphanumeric or national ($, #, @) characters. The installation’s security
administrator can impose additional restrictions on passwords; follow your
installation’s rules.

Note: The system suppresses the value you code for new-password from the
JESJCL and JESJCLIN data sets.

Relationship to Other Parameters

If the installation does not contain the user and group identification propagation
feature:
v Code a PASSWORD parameter when coding a USER or GROUP parameter on
a JOB statement.
v Code a USER parameter when coding a PASSWORD parameter.

Examples of the PASSWORD Parameter

Example 1
//TEST1 JOB ’D83,123456’,PASSWORD=ABCDE,USER=MYNAME

This JOB statement identifies ABCDE as the current password for the RACF user.

Example 2
//TEST2 JOB ’D83,123456’,PASSWORD=(BCH,A12),USER=RAC1,GROUP=GRP1

This JOB statement requests that the system change the RACF password from
BCH to A12.

PERFORM Parameter
Parameter Type

Keyword, optional

Purpose

Use the PERFORM parameter in WLM compatibility mode to specify the

performance group for the job. The installation-defined performance groups
determine the rate at which associated jobs have access to the processor, storage,
and channels.

In WLM goal mode, the PERFORM parameter on the JOB statement can be used
to classify jobs and started procedures to a service class and/or report class. This
classification method is provided to reduce the need to modify existing JCL when
migrating to goal mode. Note that PERFORM on the EXEC statement is ignored in
goal mode for jobs and started procedures.

For details on how to use the WLM application for managing a service definition
and service policies, see z/OS MVS Planning: Workload Management.

Chapter 20. JOB Statement 20-33

JOB: PERFORM
Syntax
PERFORM=n

Subparameter Definition
n In WLM compatibility mode, requests a performance group. The n is a number
from 1 through 999 and must identify a performance group that has been
defined by your installation. The specified performance group should be
appropriate for your job type according to your installation’s rules.
In WLM goal mode, n can be used to classify the job or started task to a
service class and/or report class.

Defaults
In compatibility mode, if no PERFORM parameter is specified or if the specified
PERFORM number fails validity checks, the system uses an installation default
specified at initialization. If the installation did not specify a default, the system uses
a built-in default:

Default Use
1 For non-TSO/E job steps
2 For TSO/E sessions

See z/OS MVS Initialization and Tuning Guide for details.

Overrides
A JOB statement PERFORM parameter applies to all steps of the job and overrides
any EXEC statement PERFORM parameters.

Code EXEC statement PERFORM parameters when each job step executes in a
different performance group. The system uses an EXEC statement PERFORM
parameter only when no PERFORM parameter is on the JOB statement and only
during the job step.

Examples of the PERFORM Parameter

Example 1: PERFORM in compatibility mode
//STEP1 JOB ,MARLA,CLASS=D,PERFORM=25

In this example, CLASS=D determines the class in which the system will execute
the job. Once in the system, the job will run in performance group 25. The
installation must have defined the significance of this performance group.

Example 2: PERFORM in goal mode

//STEP1 JOB ,KIRTS,PERFORM=26

In this example, the job will be associated with service class PBATCH because the
PERFORM value is specified as 26, and the PERFORM value of 26 is defined to
workload management as being associated with the service class named PBATCH.
To associate the PERFORM value with a service class, you need to define a
classification rule in the workload management service definition. The following

20-34 z/OS V1R3.0 MVS JCL Reference

 JOB: PERFORM
panel from the WLM application shows a rule for subsystem type JES that assigns
any job with a PERFORM value of 26 to service class PBATCH.
Modify Rules for the Subsystem Type Row 1 to 1 of
Command ===> ____________________________________________ SCROLL ===> PA

Subsystem Type . : JES Fold qualifier names? Y (Y or N)

Description . . . batch

Action codes:A=After C=Copy M=Move I=Insert rule

B=Before D=Delete row R=Repeat IS=Insert Sub-rule
-------Qualifier------------- -------Class--------
Action Type Name Start Service Report
DEFAULTS: TBATCH ________
____ 1 PF 26 ___ PBATCH ________

Programmer’s Name Parameter

Parameter Type

Positional, required (according to installation procedures)

Purpose

Use the programmer’s name parameter to identify the person or group responsible
for a job.

Syntax
programmer’s-name

Location: Place the programmer’s name parameter immediately after the accounting
information parameter and before all keyword parameters.

Omission: Do not code a comma to indicate the absence of the programmer’s name
parameter. For example:
//JOBA JOB ’D58/706’,MSGCLASS=A

Special Characters: Enclose the programmer’s name in apostrophes when:

v The name contains special characters, other than hyphens, leading periods, or
embedded periods. For example:
//JOBB JOB ,S-M-TU
//JOBC JOB ,.ABC
//JOBD JOB ,P.F.M
//JOBE JOB ,’BUILD/PAUL’
//JOBF JOB ,’MAE BIRDSALL’
v The last character of the name is a period. For example:
//JOBG JOB ,’A.B.C.’
v Code each apostrophe that is part of the name as two consecutive apostrophes. For
example, code O'DONNELL as 'O''DONNELL'.

Parameter Definition
programmer’s-name
Identifies the job’s owner. The name must not exceed 20 characters, including
all special characters.

Chapter 20. JOB Statement 20-35

JOB: Programmer’s Name
Examples of the Programmer’s Name Parameter
Example 1
//APP JOB ,G.M.HILL

This JOB statement specifies a programmer’s name with no accounting information.

The leading comma may be optional; check with your installation.

Example 2
//DELTA JOB ’T.O’’NEILL’

The programmer’s name contains special characters. The installation requires no

accounting information. The imbedded apostrophe is coded as two consecutive
apostrophes; the entire name must be enclosed in apostrophes.

Example 3
//#308 JOB (846349,GROUP12),MATTHEW

This JOB statement specifies an account number, additional accounting information,

and a programmer’s name.

Example 4
//JOBA JOB ’DEPT. 15E’

This installation requires the department number in the programmer’s name

parameter.

PRTY Parameter
Parameter Type

Keyword, optional

Purpose

Use the PRTY parameter to assign a selection priority to your job. Within a JES2
job class or a JES3 job class group, the system selects jobs for execution in order
by priority. A job with a higher priority is selected for execution sooner; jobs with the
same priority are selected on a first-in first-out basis.

Note: Depending on the JES2 initialization options in use at your installation, JES2
may ignore the PRTY parameter.

In a JES2 system, there are a number of factors that determine the order in which a
particular job is selected for execution. Therefore, you cannot be assured that job
priority (based on the PRTY you assign a job), job class, or the order of job
submission will guarantee that the jobs will execute in a particular order. If you need
to submit jobs in a specific order, contact your JES2 system programmer for advice
based on how your system honors such requests. (z/OS JES2 Initialization and
Tuning Guide provides JES2 system programmer procedures concerning job
queuing and how to control job execution sequence.)

References

For more information about priority, see z/OS JES2 Initialization and Tuning Guide.

20-36 z/OS V1R3.0 MVS JCL Reference

 JOB: PRTY
Considerations for an APPC Scheduling Environment

The PRTY parameter has no function in an APPC scheduling environment. If you

code PRTY, the system will check it for syntax and ignore it.

Syntax
PRTY=priority

Subparameter Definition
priority
Requests a priority for the job. The priority is a number from 0 through 15 for
JES2 and from 0 through 14 for JES3. The highest priority is 15 or 14.
Follow your installation’s rules in coding a priority.

Defaults
JES2 determines the job priority from the following, in override order:
1. A JES2 /*PRIORITY statement.
2. A PRTY parameter on the JOB statement.
3. A value calculated from the accounting information on a JES2 /*JOBPARM
statement or the JOB statement.
4. An installation default specified at JES2 initialization.

JES3 determines the job priority from the following, in override order:
1. A PRTY parameter on the JOB statement. If the specified priority is invalid,
JES3 issues an error message.
2. An installation default specified at JES3 initialization.

Example of the PRTY Parameter

//JOBA JOB 1,’JIM WEBSTER’,PRTY=12

This job has a priority of 12.

RD Parameter
Parameter Type

Keyword, optional

Note: This parameter is ignored for a started task.

Purpose

Use the RD (restart definition) parameter to:

v Specify that the system is to allow the operator the option of performing
automatic step or checkpoint restart if a job step abends with a restartable abend
code. (See the SCHEDxx parmlib member description in z/OS MVS Initialization
and Tuning Guide for information about restartable abends.)

Chapter 20. JOB Statement 20-37

JOB: RD
v Allow JES to perform automatic step restart after a system failure even if the
journal option is not specified in the JES initialization parameters or JES control
statements.
v Suppress, partially or totally, the action of the assembler language CHKPT macro
instruction or the DD statement CHKPT parameter.

The system can perform automatic restart only if all of the following are true:
v The JOB or EXEC statement contains RD=R or RD=RNC.
v The step to be restarted abended with a restartable abend code.
v The operator authorizes a restart.

The system can perform automatic step restart for a job running during a system
failure as long as the job has a job journal. A job journal is a sequential data set
that contains job-related control blocks needed for restart.

If you use checkpoint restart or restart a job step, you need to save the journal or
the system cannot automatically restart the job if it fails or if there is a system
restart. If you use the automatic restart manager (ARM) to restart a job, you do not
need to save the journal because ARM does not use the job journal when restarting
jobs.

For JES2, specify a job journal by one of the following:

v JOURNAL=YES on the CLASS statement in the JES2 initialization parameters.
v RD=R or RD=RNC on either the JOB statement or any one EXEC statement in
the job.

For JES3, specify a job journal by one of the following:

v JOURNAL=YES on the CLASS statement in the JES3 initialization parameters.
v RD=R or RD=RNC on either the JOB statement or any one EXEC statement in
the job.
v JOURNAL=YES on a JES3 //*MAIN statement in the job.

References

For detailed information on deferred checkpoint restart, see z/OS DFSMS

Checkpoint/Restart.

Considerations for an APPC Scheduling Environment

The RD parameter has no function in an APPC scheduling environment. If you code

RD, the system will check it for syntax and ignore it.

Syntax
RD= {R }
{RNC}
{NR }
{NC }

v The RD parameter cannot have a null value.

Subparameter Definition
R (Restart, Checkpoints Allowed)
Indicates that the operator can perform automatic step restart if the job fails.

20-38 z/OS V1R3.0 MVS JCL Reference

 JOB: RD
RD=R does not suppress checkpoint restarts:
v If the processing program executed in a job step does not include a CHKPT
macro instruction, RD=R allows the system to restart execution at the
beginning of the abnormally terminated step.
v If the program includes a CHKPT macro instruction, RD=R allows the system
to restart execution at the beginning of the step, if the step abnormally
terminates before the CHKPT macro instruction is executed.
v If the step abnormally terminates after the CHKPT macro instruction is
executed, only checkpoint restart can occur. If you cancel the affects of the
CHKPT macro instruction before the system performs a checkpoint restart,
the request for automatic step restart is again in effect.
RNC (Restart, No Checkpoints)
Indicates that the operator can perform automatic step restart if the job fails.
RD=RNC suppresses automatic and deferred checkpoint restarts. It
suppresses:
v Any CHKPT macro instruction in the processing program: That is, the
operator cannot perform an automatic checkpoint restart, and the system is
not to perform a deferred checkpoint restart if the job is resubmitted.
v The DD statement CHKPT parameter.
v The checkpoint at end-of-volume (EOV) facility.
NR (No Automatic Restart, Checkpoints Allowed)
Indicates that the operator cannot perform automatic step restart if the job fails.
RD=NR suppresses automatic checkpoint restart but permits deferred
checkpoint restarts. It permits:
v A CHKPT macro instruction to establish a checkpoint.
v The job to be resubmitted for restart at the checkpoint. On the JOB
statement when resubmitting the job, specify the checkpoint in the RESTART
parameter.

If the system fails, RD=NR does not prevent the job from restarting.
NC (No Automatic Restart, No Checkpoints)
Indicates that the operator cannot perform automatic step restart if the job fails.
RD=NC suppresses automatic and deferred checkpoint restarts. It suppresses:
v Any CHKPT macro instruction in the processing program.
v The DD statement CHKPT parameter.
v The checkpoint at EOV facility.

Defaults
If you do not code the RD parameter, the system uses the installation default from
the job’s job class specified at initialization.

Overrides
A JOB statement RD parameter applies to all steps of the job and overrides any
EXEC statement RD parameters.

Code EXEC statement RD parameters when each job step requires different restart
types. The system uses an EXEC statement RD parameter only when no RD
parameter is on the JOB statement and only during the job step.

Chapter 20. JOB Statement 20-39

JOB: RD
Relationship to Other Control Statements
RD=NC or RD=RNC suppresses the action of the DD statement CHKPT parameter.

Examples of the RD Parameter

Example 1
//JILL JOB 333,TOM,RD=R

RD=R specifies that the operator can perform automatic step restart if the job fails.

Example 2
//TRY56 JOB 333,DICK,RD=RNC

RD=RNC specifies that, if the job fails, the operator can perform automatic step
restart beginning with the step that abnormally terminates. RD=RNC suppresses
automatic and deferred checkpoint restarts.

Example 3
//PASS JOB (721,994),HARRY,RD=NR

RD=NR specifies that the operator cannot perform automatic step restart or
automatic checkpoint restart. However, a CHKPT macro instruction can establish
checkpoints to be used later for a deferred restart.

REGION Parameter
Parameter Type

Keyword, optional

Purpose

Use the REGION parameter to specify the amount of central or virtual storage that
the job requires. The system applies the value that you code on REGION to each
step of the job.

The amount of storage requested must include the following:

v Storage for all programs to be executed.
v All additional storage the programs request with GETMAIN macro instructions
during execution.
v Enough unallocated storage for task initialization and termination. Task
initialization and termination can issue GETMAIN macro instructions for storage
in the user’s address space.

Two installation exits, IEFUSI and IEALIMIT, can also affect the size of the user
address space assigned to the job step.

References

For more information on address space size, see z/OS MVS Initialization and
Tuning Guide, and ″Resource Control of Address Space″ in z/OS MVS JCL User’s
Guide. For more information on region size with checkpoint/restart jobs, see z/OS
DFSMS Checkpoint/Restart.

20-40 z/OS V1R3.0 MVS JCL Reference

 JOB: REGION
Syntax
REGION= {valueK}
{valueM}

Subparameter Definition
valueK
Specifies the required storage in kilobytes (1 kilobyte = 1024 bytes). The value
is 1 through 7 decimal numbers, from 1 through 2096128. Code a multiple of 4.
For example, code REGION=68K. If the value you code is not a multiple of 4,
the system will round it up to the next multiple of 4.

Note: Specifying a REGION size that gives the JOB all the available storage,
such as 0K or any value greater than 16,384K, can cause storage
problems if the IBM- or installation-supplied routine IEALIMIT or IEFUSI
is not used to establish a limiting value.
valueM
Specifies the required storage in megabytes (1 megabyte = 1024 kilobytes).
The value is 1 through 4 decimal numbers, from 1 through 2047. For example,
REGION=3M.

Note: Specifying a REGION size that gives the JOB all the available storage,
such as 0M or any value greater than 16M, can cause storage problems
if the IBM- or installation-supplied routine IEALIMIT or IEFUSI is not
used to establish a limiting value.

Defaults
If no REGION parameter is specified, the system uses the REGION parameter
specified on each EXEC statement. If no EXEC statement REGION parameter is
specified, the system uses a job step installation default specified at JES
initialization.

If your installation does not change the IBM-supplied default limits in the IEALIMIT
or IEFUSI exit routine modules, then specifying various values for the region size
have the following results:
v A value equal to 0K or 0M — gives the job all the storage available below and
above 16 megabytes. The resulting size of the region below and above 16
megabytes is installation-dependent.
v A value greater than 0K or 0M and less than or equal to 16,384K or 16M —
establishes the size of the private area below 16 megabytes. If the region size
specified is not available below 16 megabytes, the job abnormally terminates.
The extended region size is the default value of 32 megabytes.
v A value greater than 16,384K or 16M and less than or equal to 32,768K or 32M
— gives the job all the storage available below 16 megabytes. The resulting size
of the region below 16 megabytes is installation-dependent. The extended region
size is the default value of 32 megabytes.
v A value greater than 32,768K or 32M and less than or equal to 2,096,128K or
2047M — gives the job all the storage available below 16 megabytes. The
resulting size of the region below 16 megabytes is installation-dependent. The
extended region size is the specified value. If the region size specified is not
available above 16 megabytes, the job abnormally terminates.

Chapter 20. JOB Statement 20-41

JOB: REGION
Overrides
A JOB statement REGION parameter applies to all steps of the job and overrides
any EXEC statement REGION parameters.

Code EXEC statement REGION parameters when each job step requires a different
region size. The system uses an EXEC statement REGION parameter only when
no REGION parameter is on the JOB statement and only during the job step.

Relationship to the JOB ADDRSPC Parameter

When ADDRSPC=REAL

Code a REGION parameter to specify how much central storage (also called real
storage) the job needs. If you omit the REGION parameter, the system uses the
default.

When ADDRSPC=VIRT or ADDRSPC is Omitted

Code a REGION parameter to specify how much virtual storage the job needs. If
you omit the REGION parameter, the system uses the default.

Examples of the REGION Parameter

Example 1
//ACCT1 JOB A23,SMITH,REGION=100K,ADDRSPC=REAL

This JOB statement indicates that the job requires 100K of central storage.

Example 2
//ACCT4 JOB 175,FRED,REGION=250K

This JOB statement indicates that the job requires 250K of virtual storage. When
the ADDRSPC parameter is omitted, the system defaults to ADDRSPC=VIRT.

RESTART Parameter
Parameter Type

Keyword, optional

Note: Do not specify this parameter for a started task; if RESTART is specified, the
job will fail.

Purpose

Use the RESTART parameter to indicate the step, procedure step, or checkpoint at
which the system is to restart a job. You can specify that the system perform either
of two restarts:
v Deferred step restart, which is a restart at the beginning of a job step.
v Deferred checkpoint restart, which is a restart from a checkpoint taken during
step execution by a CHKPT macro instruction.

References

For detailed information on the deferred checkpoint restart, see z/OS DFSMS
Checkpoint/Restart.
20-42 z/OS V1R3.0 MVS JCL Reference
 JOB: RESTART
Considerations for an APPC Scheduling Environment

The RESTART parameter has no function in an APPC scheduling environment. If

you code RESTART, the system will check it for syntax and ignore it.

Syntax
RESTART= ({* } [,checkid] )
({stepname } )
({stepname.procstepname} )

v You can omit the outer parentheses if you code only the first subparameter.
v The RESTART parameter cannot have a null value.

Subparameter Definition
* Indicates that the system is to restart execution (1) at the beginning of or within
the first job step or (2), if the first job step calls a cataloged or in-stream
procedure, at the beginning of or within the first procedure step.
stepname
Indicates that the system is to restart execution at the beginning of or within a
job step. If stepname refers to an EXEC statement that invokes a procedure,
the step name of the step within the procedure must also be specified.
stepname.procstepname
Indicates that the system is to restart execution at the beginning of or within a
step of a cataloged procedure. Stepname identifies the EXEC statement of the
job step that calls the procedure; procstepname identifies the EXEC statement
of the procedure step. The step identified by procstepname must contain the
PGM keyword rather than invoke a procedure.
checkid
Specifies the name of the checkpoint at which the system is to restart
execution. This checkpoint must be in the job step specified in the first
subparameter.
Omit checkid to request restart at the beginning of the specified job step.
When the name contains special characters, enclose it in apostrophes. Code
each apostrophe that is part of the name as two consecutive apostrophes. For
example, code CHPT'1 as 'CHPT''1'.

Relationship to Other Control Statements

When the system is to restart execution in a job step, place a SYSCHK DD
statement immediately following the JOB statement. The SYSCHK DD statement
defines the data set on which the system entered the checkpoint for the step being
restarted.

When preparing for a deferred checkpoint, code the DISP abnormal termination
disposition subparameter in the step’s DD statements as follows:
v KEEP, to keep all data sets that the restart step is to use.
v CATLG, to catalog all data sets that you are passing from steps preceding the
restart step to steps following the restart step.

Chapter 20. JOB Statement 20-43

JOB: RESTART
In JES2 systems, you can also use the RESTART parameter on the /*JOBPARM
control statement.

In JES3 systems, you must also code the FAILURE parameter on the //*MAIN
control statement.

Cautions when Coding the RESTART Parameter

Before resubmitting a job:
v Check all backward references to steps before the restart step. Eliminate all
backward references in EXEC statement PGM parameters and DD statement
VOLUME=REF parameters.
v Review all EXEC statement COND parameters. If any of the COND parameters
reference a step before the restart step, be aware that the system ignores the
return code tests for those steps. See “Considerations when Using the COND
Parameter” on page 16-13 for more information.
v Note that the stepname and procstepname specified to identify the restart step
must be unique within the job. Otherwise, the system will not be able to
determine the correct restart step. Results will be unpredictable.
v Review all IF/THEN/ELSE/ENDIF structures. If a relational expression references
a step that is bypassed by the RESTART keyword, the system evaluates that
part of the expression as false.

Generation Data Sets in Restarted Jobs

In the restart step or following steps, do not use the original relative generation
numbers to refer to generation data sets that were created and cataloged before
the restart step. Instead, refer to a generation data set by its present relative
generation number.

For example, if the last generation data set created and cataloged was assigned a
generation number of +2, refer to it as 0 in the restart step and following steps. If
generation data set +1 was also created and cataloged, refer to it as −1.

If generation data sets created in the restart step were kept instead of cataloged,
that is, DISP=(NEW,CATLG,KEEP) was coded, then refer to them by the same
relative generation numbers used to create them.

Examples of the RESTART Parameter

Example 1
//LINES JOB ’1/17/85’,RESTART=COUNT

This JOB statement indicates that the system is to restart execution at the
beginning of the job step named COUNT.

Example 2
//@LOC5 JOB ’4/11/86’,RESTART=(PROCESS,CHKPT3)
//SYSCHK DD DSNAME=CHK,UNIT=3330,DISP=OLD

The JOB statement indicates that the system is to restart execution at checkpoint
CHKPT3 in job step PROCESS. The SYSCHK DD statement must follow the JOB
statement; it defines the data set on which the system wrote checkpoint CHKPT3.

Example 3

20-44 z/OS V1R3.0 MVS JCL Reference

 JOB: RESTART
//WORK JOB ,PORTER,RESTART=(*,CKPT2)
//SYSCHK DD DSNAME=CHKPT,UNIT=3330,DISP=OLD

The JOB statement indicates that the system is to restart execution at checkpoint
CKPT2 in the first job step. The SYSCHK DD statement defines the data set on
which the system wrote checkpoint CKPT2.

Example 4
//CLIP5 JOB ,COLLINS,RESTART=(PAY.WEEKLY,CHECK8)
//SYSCHK DD DSNAME=CHKPT,UNIT=3350,DISP=OLD

The JOB statement indicates that the system is to restart execution at checkpoint
CHECK8 in procedure step WEEKLY. PAY is the name field on the EXEC statement
that calls the cataloged procedure that contains procedure step WEEKLY. The
SYSCHK DD statement defines the data set on which the system wrote checkpoint
CHECK8.

SECLABEL Parameter
Parameter Type

Keyword, optional

Note: Do not specify this parameter for a started task; if SECLABEL is specified,
the job will fail.

Purpose

Use the SECLABEL parameter to specify the security level at which the job is to
execute when submitted to the system. The security label represents a security
level and categories as defined to RACF. You must have sufficient authority, granted
by the security administrator at your installation, to run the job with the security
label you specify.

References

For more information about security labels, see the z/OS Security Server RACF
Security Administrator’s Guide.

Considerations for an APPC Scheduling Environment

The SECLABEL parameter has no function in an APPC scheduling environment. If

you code SECLABEL, the system will check it for syntax and ignore it.

Syntax
SECLABEL=seclabel-name

Subparameter Definition
seclabel-name
Specifies the name of a security label defined by the security administrator at
your installation. The seclabel-name is one through eight alphanumeric or
national ($, #, @) characters. The first character must be alphabetic, $, #, or @.

Chapter 20. JOB Statement 20-45

JOB: SECLABEL
Defaults
If you do not specify the SECLABEL parameter, the system uses the default
security label in your RACF profile.

Relationship to Other Parameters

Use the SECLABEL parameter on the JOB statement with the DPAGELBL and
SYSAREA parameters on an OUTPUT JCL statement, as instructed by your
security administrator.

You may code SECLABEL with any other JOB statement parameters.

Example of the SECLABEL Parameter

//JOBA JOB 1,’JIM WOOSTER’,SECLABEL=CONF

In this example, JOBA executes at a security level defined for security label CONF.

SCHENV Parameter
Keyword, optional

Purpose

Use the SCHENV parameter to specify the name of the Workload Manager (WLM)
scheduling environment to associate with this job. A scheduling environment is a list
of resources and their required settings. By associating a scheduling environment
name with a job, you ensure that the job will be scheduled only on a system that
satisfies those resource state requirements.

Reference

For more information about WLM scheduling environments, see z/OS MVS
Planning: Workload Management.

Note: Do not specify the SCHENV parameter for a started task; the job will fail.

Considerations for an APPC Scheduling Environment

The SCHENV parameter has no function in an APPC scheduling environment. If

you code SCHENV, the system will check it for syntax and ignore it.

Considerations for a JES2 Environment

You can provide a SCHENV default in a JES2 environment via a JOBCLASS(c)

specification.

Syntax
SCHENV=schenv-name

20-46 z/OS V1R3.0 MVS JCL Reference

 JOB: SCHENV
Subparameter Definition
schenv-name
Specifies the name of a WLM scheduling environment to be associated with this
job. The schenv-name is 1 through 16 alphanumeric, national ($, #, @)
characters, or the underscore (_). If you include an underscore character in the
schenv-name, you must imbed the underscore and enclose the name in
apostrophes (single quotes). For example, ’PLEX_D01’ is valid, but ’PLEX_’ and
PLEX_D01 are not.

Defaults
If you do not specify the SCHENV parameter, the job will not be associated with
any WLM scheduling environment.

Relationship to Other Control Statements

You can use scheduling environments and either the SYSAFF parameter of the
/*JOBPARM control statement for JES2 or the SYSTEM parameter of the //*MAIN
control statement for JES3 together. For instance, you can restrict a job to either
SYS1 or SYS2 based on the scheduling environment associated with that work, and
then use the SYSAFF or SYSTEM parameter to further restrict that work only to
system SYS1.

Example of the SCHENV Parameter

//JOBA JOB 1,’STEVE HAMILTON’,SCHENV=DB2LATE

In this example, JOBA is associated with the DB2LATE scheduling environment.

TIME Parameter
Parameter Type

Keyword, optional

Purpose

Use the TIME parameter to specify the maximum amount of time that a job may
use the processor or to find out through messages how much processor time a job
used.

The system terminates a job that exceeds the specified time limit unless an
installation exit routine at exit IEFUTL extends the time. Exit routine IEFUTL is
established through System Management Facilities (SMF).

You can use the TIME parameter on a JOB statement to decrease the amount of
processor time available to a job or job step below the default value. You cannot
use the TIME parameter on a JOB statement to increase the amount of time
available to a job step over the default value. To increase the allowable time over
the default value, use the TIME parameter on the EXEC statement.

For releases prior to MVS/ESA SP Version 4 Release 3.0, the amount of time that a
job step receives might be slightly more or less than the requested processor time.
The exact amount of processor time is based on certain system events.

Chapter 20. JOB Statement 20-47

JOB: TIME
As of MVS/ESA SP Version 4 Release 3.0, the job step receives at least the
requested amount of CPU time. Based on system events, additional CPU time
might be provided.

Reference

See z/OS MVS Installation Exits.

Syntax
TIME= {([minutes][,seconds])}
{1440 }
{NOLIMIT }
{MAXIMUM }
You can omit the parentheses if you code only 1440 or the processor time in minutes.

Subparameter Definition
minutes
Specifies the maximum number of minutes a job may use the processor.
Minutes must be a number from 0 through 357912 (248.55 days).
Do not code TIME=0 on a JOB statement. The results are unpredictable.
seconds
Specifies the maximum number of seconds that a job may use the processor, in
addition to any minutes that you specify. Seconds must be a number from 0
through 59.
1440 or NOLIMIT
Indicates that the job can use the processor for an unlimited amount of time.
(″1440″ literally means ″24 hours.″)
Also code TIME=1440 or TIME=NOLIMIT to specify that the system is to allow
any of the job’s steps to remain in a continuous wait state for more than the
installation time limit, which is established through SMF.
MAXIMUM
Indicates that the job can use the processor for the maximum amount of time.
Coding TIME=MAXIMUM allows a job to run for 357912 minutes.

Defaults
Every job step has a time limit. If you do not specify a TIME parameter on the JOB
statement, the time limit for each job step is:
v The value you specify for the TIME parameter on its EXEC statement, or
v The default time limit (that is, the JES default job step time limit), if you do not
specify a TIME parameter on its EXEC statement.

If you specify a value other than TIME=NOLIMIT or TIME=1440, SMF uses its
current job wait time limit.

Overrides
For a JOB statement TIME parameter of TIME=NOLIMIT or TIME=1440, the system
nullifies any TIME parameters on EXEC statements as well as the default TIME
values. All steps within the job will have unlimited processor time.

20-48 z/OS V1R3.0 MVS JCL Reference

 JOB: TIME
For a JOB statement TIME parameter other than TIME=NOLIMIT or TIME=1440,
the system sets the time limit for each step to one of the following:
v The step time limit specified on the EXEC statement TIME parameter or the job
time remaining after execution of previous job steps, whichever is smaller.
v If no EXEC TIME parameter was specified: the default time limit, or the job time
remaining after execution of previous steps, whichever is smaller.

Examples of the TIME Parameter

Note: The following examples assume the default time limit (set by the installation)
to be greater than the TIME=parameter specified in each example.

Example 1
//STD1 JOB ACCT271,TIME=(12,10)

This statement specifies that the maximum amount of time the job can use the
processor is 12 minutes, 10 seconds.

Example 2
//TYPE41 JOB ,GORDON,TIME=(,30)

This statement specifies that the maximum amount of time the job can use the
processor is 30 seconds.

Example 3
//FORMS JOB ,MORRILL,TIME=5

This statement specifies that the maximum amount of time the job can use the
processor is 5 minutes.

Example 4
//RAINCK JOB 374231,MORRISON,TIME=NOLIMIT

This statement specifies an unlimited amount of time for job execution; the job can
use the processor and remain in wait state for an unspecified period of time. The
system will issue messages telling how much processor time the job used.

Examples of the TIME Parameter on JOB and EXEC Statements

Note: The following examples assume the default time limit (set by the installation)
to be greater than the TIME=parameter specified in each example.

Example 1
//FIRST JOB ,SMITH,TIME=2
//STEP1 EXEC PGM=READER,TIME=1
.
.
.
//STEP2 EXEC PGM=WRITER,TIME=1
.

In this example, the job is allowed 2 minutes for execution and each step is allowed
1 minute. If either step continues executing beyond 1 minute, the entire job
abnormally terminates beginning with that step.

Chapter 20. JOB Statement 20-49

JOB: TIME
Example 2
//SECOND JOB ,JONES,TIME=3
//STEP1 EXEC PGM=ADDER,TIME=2
.
.
.
//STEP2 EXEC PGM=PRINT,TIME=2
.

In this example, the job is allowed 3 minutes for execution, and each step is
allowed 2 minutes. If either step continues executing beyond 2 minutes, the entire
job abnormally terminates beginning with that step. If STEP1 executes for 1.74
minutes and STEP2 tries to execute beyond 1.26 minutes, the job abnormally
terminates because of the 3-minute limit specified on the JOB statement.

TYPRUN Parameter
Parameter Type

Keyword, optional

Note: Do not specify this parameter for a started task; if TYPRUN is specified, the
job will fail.

Purpose

Use the TYPRUN parameter to request special job processing. The TYPRUN
parameter can tell the system to:
v In a JES2 system, copy the input job stream directly to a sysout data set and
schedule it for output processing.
v In a JES2 or JES3 system, place a job on hold until a special event occurs.
When the event occurs, the operator, following your directions, must release the
job from its hold to allow the system to select the job for processing. Use the
JES2 /*MESSAGE statement or the JES3 //*OPERATOR statement to notify the
operator to release the job.
v In a JES2 or JES3 system, scan a job’s JCL for syntax errors.

Considerations for an APPC Scheduling Environment

The TYPRUN parameter has no function in an APPC scheduling environment. If

you code TYPRUN, the system will check it for syntax and ignore it.

Syntax
TYPRUN= {COPY }
{HOLD }
{JCLHOLD}
{SCAN }

Subparameter Definition
COPY (JES2 only)
Requests that JES2 copy the input job stream, as submitted, directly to a
sysout data set and schedule the sysout data set for output processing. The

20-50 z/OS V1R3.0 MVS JCL Reference

 JOB: TYPRUN
system does not schedule the job for execution. The class of this sysout data
set is the same as the message class of the job and is controlled by the JOB
MSGCLASS parameter.

Note: COPY is supported only in JES2 systems.

HOLD
Requests that the system hold the job before execution until the operator
releases it. The operator should release the job when a particular event occurs.
If an error occurs during input service processing, JES does not hold the job.
JCLHOLD (JES2 only)
Requests that JES2 hold the job before completing JCL processing. JES2 holds
the job until the operator releases it.

Note: JCLHOLD is supported only in JES2 systems.

SCAN
Requests that the system scan this job’s JCL for syntax errors, without
executing the job or allocating devices. This parameter asks the system to
check for:
v Spelling of parameter keywords and some subparameter keywords that is not
valid.
v Characters that are not valid.
v Unbalanced parentheses.
v Misplaced positional parameters on some statements.
v In a JES3 system only, parameter value errors or excessive parameters.
v Invalid syntax on JCL statements in cataloged procedures invoked by any
scanned EXEC statements.

The system does not check for misplaced statements, for invalid syntax in JCL
subparameters, or for parameters and/or subparameters that are inappropriate
together.

In a JES3 system, the system does not scan the JCL on the submitting system
when a //*ROUTE or XMIT JCL statement follows the JOB statement.

TYPRUN=SCAN checks the JCL only through the converter, not the interpreter.
The difference is that the converter basically checks all expressions to the LEFT
of an equal sign plus SOME expressions to the right of an equal sign (and
issues messages that start with IEFC), while the interpreter checks all
expressions to the RIGHT of an equal sign (and issues messages that start with
IEF). For example, a data set name containing a qualifier that exceeds eight
characters, such as
DSN=L9755TB.JCL.TEST19970103

would NOT be flagged by TYPRUN=SCAN but would be caught by the

interpreter.

Relationship to Other Control Statements

In a JES3 system, code PGM=JCLTEST or PGM=JSTTEST on the EXEC
statement to scan a job step’s JCL. JCLTEST or JSTTEST provides for a step the
same function as provided by TYPRUN=SCAN for a job.

Chapter 20. JOB Statement 20-51

JOB: TYPRUN
Example of the TYPRUN Parameter
//UPDATE JOB ,HUBBARD
//STEP1 EXEC PGM=LIBUTIL
.
.
.
//LIST JOB ,HUBBARD,TYPRUN=HOLD
//STEPA EXEC PGM=LIBLIST
.
.
.

Jobs UPDATE and LIST are submitted for execution in the same input stream.
UPDATE executes a program that adds and deletes members of a library; LIST
executes a program that lists the members of that library. For an up-to-date listing
of the library, LIST must execute after UPDATE. To force this execution order, code
TYPRUN=HOLD on JOB statement LIST.

If a MONITOR JOBNAMES command is executed from the input stream or by the

operator, the system notifies the console operator when UPDATE completes. The
operator can then release LIST, allowing the system to select LIST for execution.

USER Parameter
Parameter Type

Keyword, optional

Note: Do not specify this parameter for a started task; if USER is specified, the job
will fail.

Purpose

Code the USER parameter to identify to the system the person submitting the job.
The userid is used by RACF, the system resources manager (SRM), and other
system components.

If the installation contains the feature for propagation of the user and group
identification, the USER and PASSWORD parameters are required, and the
GROUP parameter is optional on JOB statements only for the following:
v Batch jobs submitted through an input stream, such as a card reader, (1) if the
job requires access to RACF-protected resources or (2) if the installation requires
that all jobs have RACF identification.
v Jobs submitted by one RACF-defined user for another user. In this case, the JOB
statement must specify the other user’s userid and may need a password. The
group id is optional.
v Jobs that execute at another network node that uses RACF protection.

Otherwise, the USER, PASSWORD, and GROUP parameters can be omitted from
JOB statements. RACF uses the userid, password, and default group id of the
submitting TSO/E user or job.

References

For more information on RACF-protected facilities, see the z/OS Security Server
RACF Security Administrator’s Guide.

20-52 z/OS V1R3.0 MVS JCL Reference

 JOB: USER
Considerations for an APPC Scheduling Environment

The USER parameter has no function in an APPC scheduling environment. If you

code USER, the system will check it for syntax and ignore it.

Syntax
USER=userid

Subparameter Definition
userid
Identifies a user to the system. The userid consists of 1 through 8 alphanumeric
or national ($, #, @) characters; the first character must be alphabetic or
national ($, #, @).

Defaults
When not required by the installation and if the JOB statement or the submitting
TSO/E user does not supply identification information, RACF assigns a default
userid and group id, unless the job enters the system via a JES internal reader. In
this case, the user and default group identification of the submitting TSO/E user or
job is used.

Relationship to Other Parameters

If the JOB statement contains a GROUP or PASSWORD parameter, the statement
must also contain a USER parameter.

Example of the USER Parameter

//TEST JOB ’D83,123456’,USER=MYNAME,PASSWORD=ABCD

This statement identifies the user submitting this job as MYNAME.

Chapter 20. JOB Statement 20-53

20-54 z/OS V1R3.0 MVS JCL Reference
Chapter 21. Null Statement
Use the null statement to mark the end of a job.

Description

Syntax

//

v The null statement consists of the characters // in columns 1 and 2.

v The rest of the statement must be blank.

Location in the JCL

Place a null statement (1) at the end of a job’s control statements and data and (2)
at the end of an input stream.

The system can also recognize the end of a job when it reads the next JOB
statement or when the input stream contains no more records.

A null statement that does not end an input stream should be immediately followed
by a JOB statement. The system ignores statements between a null statement and
the next valid JOB statement.

Note: JES2 ignores a NULL statement when it is included in a job’s JCL statements.
JES2 processes JES2 control statements following a NULL statement as part of the
job (until the next JOB statement or EOF).

If a null statement follows a control statement that is being continued, the system
treats the null statement as a blank comment field and assumes that the control
statement contains no other parameters.

Example of the Null Statement

//MYJOB JOB ,’C BROWN’
//STEP1 EXEC PROC=FIELD
//STEP2 EXEC PGM=XTRA
//DD1 DD UNIT=3400-5
//DD2 DD *
.
.
data
.
/*
//

The null statement indicates the end of job MYJOB.

© Copyright IBM Corp. 1988, 2002 21-1

21-2 z/OS V1R3.0 MVS JCL Reference
Chapter 22. OUTPUT JCL Statement
Purpose

Use the OUTPUT JCL statement to specify processing options for a system output
(sysout) data set. These processing options are used only when the OUTPUT JCL
statement is explicitly or implicitly referenced by a sysout DD statement. JES
combines the options from this OUTPUT JCL statement with the options from the
referencing DD statement.

OUTPUT JCL statements are useful in processing the output of one sysout data set
in several ways. For example, a sysout data set can be sent to a distant site for
printing, as shown in statement OUT1, while it is also printed locally, as shown in
statement OUT2:
//OUT1 OUTPUT DEST=STLNODE.WMSMITH
//OUT2 OUTPUT CONTROL=DOUBLE
//DS DD SYSOUT=C,OUTPUT=(*.OUT1,*.OUT2)

The parameters you can specify for sysout data set processing are arranged
alphabetically in the following pages.

References

For information about the JES initialization parameters that provide installation
defaults, see z/OS JES2 Initialization and Tuning Reference and z/OS JES3
Initialization and Tuning Reference. For examples of OUTPUT statement processing
on the JES3 hold queue and writer queue, see z/OS JES3 Initialization and Tuning
Guide.

Description

Syntax
//name OUTPUT parameter[,parameter]... [comments]
The OUTPUT JCL statement consists of the characters // in columns 1 and 2 and four
fields: name, operation (OUTPUT), parameter, and comments.

Name Field
Code a name in the name field of every OUTPUT JCL statement, as follows:
v Each job-level OUTPUT JCL name must be unique within a job.
v Each step-level OUTPUT JCL name must be unique within the same job step.
v The name must begin in column 3.
v The name is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The name must be followed by at least one blank.

Operation Field
The operation field consists of the characters OUTPUT and must be preceded and
followed by at least one blank. It can begin in any column.

© Copyright IBM Corp. 1988, 2002 22-1

OUTPUT JCL
Parameter Field
The OUTPUT JCL statement contains only keyword parameters. All parameters are
optional; however, do not leave the parameter field blank. You can code any of the
keyword parameters in any order in the parameter field.

KEYWORD PARAMETERS VALUES PURPOSE

ADDRESS= {(’delivery addr’[,’delivery addr’]...)}

{delivery-address }

See page 22-12

delivery address: 1 - 4 Specifies an address to
delivery-address subparameters; a be printed on output
delivery-address is 1 - 60 valid separator pages.
EBCDIC text values

BUILDING= {’building identification’} building identification: 1 - 60 valid Specifies a building

{building-identification } EBCDIC text values location to be printed on
output separator pages.
See page 22-14

BURST= {YES} YES or Y: burster-trimmer-stacker Directs output to a

{Y } NO or N: continuous forms stacker stacker on a 3800
{NO } Printing Subsystem.
{N }

See page 22-15

CHARS= {table-name } 1 - 4 table-name subparameters: Names

{(table-name[,table-name]...)} 1 - 4 alphanumeric or $, #, @ character-arrangement
{STD } characters tables for printing on a
{DUMP } STD: character-arrangement 3800 Printing
{(DUMP[,table-name]...) } table (JES3 only) Subsystem. Can request
DUMP: 204-character print a high-density dump on
See page 22-16 lines on 3800 dump a SYSABEND or
SYSUDUMP DD
statement.

CKPTLINE=nnnnn nnnnn: 0 - 32,767 Specifies the maximum

lines in a logical page.
See page 22-18 (JES3 support is limited
to 3800 Printing
Subsystem Models 3, 6
and 8.)

CKPTPAGE=nnnnn nnnnn: 1 - 32,767 Specifies the number of

logical pages to be
See page 22-18 printed or transmitted
before JES takes a
checkpoint. (JES3
support is limited to 3800
Printing Subsystem
Models 3, 6 and 8.)

CKPTSEC=nnnnn nnnnn: 1 - 32,767 Specifies how many

seconds of printing are
See page 22-19 to elapse between each
checkpoint of this sysout
data set. (JES3 support
is limited to 3800 Printing
Subsystem Models 3, 6
and 8.)

22-2 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL
KEYWORD PARAMETERS VALUES PURPOSE

CLASS= {class} class: A - Z, 0 - 9 *: same output Assigns the sysout data

{* } class as MSGCLASS parameter on set to an output class.
JOB statement
See page 22-20

COLORMAP=resource resource: 1 - 8 alphanumeric or $, #, Specifies the AFP

@ characters resource (object) for the
See page 22-22 data set that contains
color translation
information.

COMPACT=compaction-table-name compaction-table-name: 1 - 8 Specifies a compaction

alphanumeric characters table for sending this
See page 22-23 sysout data set to a SNA
remote terminal.

COMSETUP=resource resource: 1 - 8 alphanumeric or $, #, Specifies the name of a

@ characters macrofile setup resource
See page 22-23 that contains the SETUP
information.

CONTROL= {PROGRAM} PROGRAM: each logical record Specifies that the data
{SINGLE } begins with a carriage control set records begin with
{DOUBLE } character carriage control
{TRIPLE } SINGLE: single spacing characters or specifies
DOUBLE: double spacing line spacing.
See page 22-24 TRIPLE: triple spacing

COPIES= {nnn } nnn (JES2): 1 - 255 Specifies number of

{(,(group-value[,group-value]...))} nnn (JES3): 0 - 255 copies printed. For a
1 - 8 group-values (JES2): 1 - 255 3800 Printing
See page 22-25 1 - 8 group values (JES3): 1 - 254 Subsystem, can instead
specify number of copies
of each page printed
before the next page is
printed.

DATACK= {BLOCK } BLOCK: indicates errors are Indicates whether or not

{UNBLOCK} not reported print-positioning errors
{BLKCHAR} UNBLOCK: indicates errors and invalid character
{BLKPOS } are reported data-check errors are to
BLKCHAR: indicates print errors be blocked or not
See page 22-27 are blocked blocked.
BLKPOS: indicates data errors
are blocked

DEFAULT= {YES} YES or Y: this statement can be Specifies that this is a

{Y } implicitly referenced by sysout DD default OUTPUT JCL
{NO } statements statement.
{N }
NO or N: this statement cannot be
See page 22-28 implicitly referenced by sysout DD
statements.

DEPT= {’department identification’} department identification: 1 - 60 valid Specifies a department

{department-identification } EBCDIC text values identification to be
printed on output
See page 22-31 separator pages.

Chapter 22. OUTPUT JCL Statement 22-3

OUTPUT JCL
KEYWORD PARAMETERS VALUES PURPOSE

DEST=destination LOCAL: local device Sends a sysout data set

ipaddr identifies a TCP/IP routing to the specified
destination (JES2): designation. destination.
LOCAL name: named local or remote device
’IP:ipaddr’ Nnnnn: node (1 - 1000)
name NnRm: node (1 - 1000) and remote
Nnnnn work station (1 - 9999); 6 digits
NnnRmmmm to NnnnnRmm maximum for n and m combined
nodename.userid
nodename.userid: node (1 - 8
’nodename.IP:ipaddr’
Rnnnn or RMnnnn or RMTnnnn alphanumeric characters) and userid
Unnnn (1 - 8 alphanumeric characters)
Rnnnn or RMnnnn or RMTnnnn:
destination (JES3): remote terminal (1 - 9999)
ANYLOCAL Unnnn: local terminal (1 - 9999)
device-name ANYLOCAL: any local device
group-name device-name: local device (1 - 8
nodename alphanumeric or $, #, @ characters)
group-name: 1 or more local
See page 22-32 devices or remote stations
(1 - 8 alphanumeric or $, #,
@ characters)
nodename: node (1 - 8 alpha-
numeric or $, #, @ characters)
remote: remote workstation (1 - 8
alphanumeric or $, #, @ characters)

DPAGELBL= {YES} YES or Y: requests that the system Indicates whether the
{Y } print a security label on each page. system should print a
{NO } security label on each
{N } NO or N: requests that the system page of output.
not print a security label on each
See page 22-36 page.

DUPLEX= {NO } X’80’ for NO Specifies whether the job

{N } X’40’ for NORMAL prints on one or both
{NORMAL} X’20’ for TUMBLE sides of the paper.
{TUMBLE} Overrides comparable
FORMDEF.
See page 22-37

FCB= {fcb-name} fcb-name: 1 - 4 alphanumeric or $, #, Specifies FCB image,

{STD } @ characters carriage control tape for
1403 Printer, or
See page 22-38 STD: standard FCB (JES3 only) data-protection image for
3525 Card Punch.

FLASH= {overlay-name } overlay-name: forms overlay frame (1 For printing on a 3800

{(overlay-name[,count])} - 4 alphanumeric or $, #, @ Printing Subsystem,
{(,count) } characters) indicates that the data
{NONE } set is to be printed with
{STD } count: copies with overlay (0 - 255) forms overlay and can
specify how many copies
See page 22-40 NONE: suppresses flashing are to be flashed.
STD: standard forms flash overlay
(JES3 only)

FORMDEF=membername membername: 1 - 6 alphanumeric or Names a library member

$, #, @ characters that PSF uses in printing
See page 22-42 the sysout data set on a
page-mode printer (such
as a 3800 Model 3).

22-4 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL
KEYWORD PARAMETERS VALUES PURPOSE

FORMLEN=nn[.mmm]{IN|CM} nn= 0-99 Allows PSF/MVS users

mmm= 0-999 to set the length of
See page 22-43 IN= inches pages for print without
CM= centimeters reconfiguring the printer.

FORMS= {form-name} form-name: 1 - 8 alphanumeric or $, Identifies forms on which

{STD } #, @ characters the sysout data set is to
be printed or punched.
See page 22-44 STD: standard form (JES3 only)

FSSDATA=value values: 1-127 EBCDIC characters Defined by a functional

subsystem. Refer to that
See page 22-44 subsystem’s
documentation for the
intent and use of this
keyword.

GROUPID=output-group output-group: 1 - 8 alphanumeric Specifies that this sysout

characters data set belongs to a
See page 22-47 user-named output
group. (JES2 only)

INDEX=nn nn: 1 - 31 Specifies how many print

positions the left margin
See page 22-48 is to be indented for a
sysout data set printed
on a 3211 Printer with
the indexing feature.
(JES2 only)

INTRAY=nnn nnn: 1 - 255 Specifies the printer

input tray from which to
See page 22-49 take paper for the print
job. Overrides
comparable FORMDEF
specification.

JESDS= {ALL} ALL: all of the job’s JCL, Requests that the
{JCL} LOG, and MSG data sets indicated data sets for
{LOG} the job be processed
{MSG} JCL: all JCL processing data sets according to the
LOG: job’s hard-copy log parameters on this
See page 22-50 MSG: job’s system messages OUTPUT JCL statement.

LINDEX=nn nn: 1 - 31 Specifies how many print

positions to move the
See page 22-52 right margin in from the
full page width for a
sysout data set printed
on a 3211 Printer with
the indexing feature.
(JES2 only)

LINECT=nnn nnn: 0 - 255 Specifies the maximum

lines JES2 is to print on
See page 22-52 each page. (JES2 only)

MODIFY= {module-name } module-name: 1 - 4 alphanumeric or Specifies a

{([module-name][,trc])} $, #, @ characters trc: table-name in copy-modification module
CHARS parameter (0 for first, 1 for in SYS1.IMAGELIB to be
See page 22-53 second, 2 for third, and 3 for fourth used by JES to print the
table-name) data set on a 3800
Printing Subsystem.

Chapter 22. OUTPUT JCL Statement 22-5

OUTPUT JCL
KEYWORD PARAMETERS VALUES PURPOSE

NAME= {’preferred name’} preferred name: 1 - 60 valid EBCDIC Specifies the preferred
{preferred-name } text values name to be printed on
output separator pages.
See page 22-55

NOTIFY= {[node.]userid } {node.}userid: node and userid to Specifies the node and
{([node.]userid1,...[node.]userid4)} receive print complete message. userid to receive a print
complete message when
See page 22-56 the sysout data set is
printed.

OFFSETXB=mmmm[.nnn]{IN } mmmm: 0 - 9999 Specifies the offset in the

{CM } nnn: 0 - 999 X direction from the page
{MM } IN: inches origin (or partition origin
{PELS } CM: centimeters for N_UP) for the back
{POINTS} MM: millimeters side of each output
page.
See page 22-57

OFFSETXF=mmmm[.nnn]{IN } mmmm: 0 - 9999 Specifies the offset in the

{CM } nnn: 0 - 999 X direction from the page
{MM } IN: inches origin (or partition origin
{PELS } CM: centimeters for N_UP) for the front
{POINTS} MM: millimeters side of each output
page.
See page 22-58

OFFSETYB=mmmm[.nnn]{IN } mmmm: 0 - 9999 Specifies the offset in the

{CM } nnn: 0 - 999 Y direction from the page
{MM } IN: inches origin (or partition origin
{PELS } CM: centimeters for N_UP) for the back
{POINTS} MM: millimeters side of each output
page.
See page 22-58

OFFSETYF=mmmm[.nnn]{IN } mmmm: 0 - 9999 Specifies the offset in the

{CM } nnn: 0 - 999 Y direction from the page
{MM } IN: inches origin (or partition origin
{PELS } CM: centimeters for N_UP) for the front
{POINTS} MM: millimeters side of each output
page.
See page 22-58

OUTBIN=nnnnn nnnnn: 1 - 65535 Specifies the ID of the

printer output bin where
See page 22-48 the data set is to be
sent.

OUTDISP=[normal-output-disposition, normal output disposition: WRITE, Specifies the disposition

abnormal-output-disposition] HOLD, KEEP, LEAVE, or PURGE. of the sysout process
instance for normal or, in
See page 22-59 abnormal output disposition: WRITE, a non-APPC scheduling
HOLD, KEEP, LEAVE, or PURGE. environment, abnormal
termination of the job
step. (JES2 only)

OVERLAYB=name name: 1 - 8 alphanumeric or $, #, @ Specifies placing the

characters named medium overlay
See page 22-62 on the back side of each
printed sheet.

OVERLAYF=name name: 1 - 8 alphanumeric or $, #, @ Specifies placing the

characters named medium overlay
See page 22-62 on the front side of each
printed sheet.

22-6 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL
KEYWORD PARAMETERS VALUES PURPOSE

OVFL= {ON } ON: JES3 should check for forms Specifies whether or not
{OFF} overflow on an output printer. JES3 should check for
forms overflow on an
See page 22-63 OFF: JES3 should not check for output printer. (JES3
forms overflow on an output printer. only)

PAGEDEF=membername membername: 1 - 6 alphanumeric or Names a library member

$, #, @ characters sysout data set on a
See page 22-63 page-mode printer (such
as a 3800 Model 3).

PIMSG= {(YES[,msg-count])} YES: print messages from a Indicates that messages

{(NO[,msg-count]) } functional subsystem from a functional
subsystem should or
See page 22-65 NO: not print messages from a should not be printed in
functional subsystem the listing following the
sysout data set.
msg-count: number of errors to cause
printing to be terminated (0-999)

PORTNO=nnnnn nnnnn: 1 - 65535 Specifies the TCP port

number at which IP
See page 22-66 PrintWay connects to the
printer rather than
connecting to LPD on
the printer. Specify either
PORTNO or
PRTQUEUE, but not
both. PRTQUEUE
indicates the queue used
when connecting to LPD
on the printer.

PRMODE= {LINE } LINE: send data set to line-mode Identifies the process
{PAGE } printer mode required to print
{process-mode} the sysout data set.
PAGE: send data set to page-mode
See page 22-67 printer

process-mode: installation-defined
mode (1 - 8 alphanumeric characters)

PRTERROR= {DEFAULT} DEFAULT= Specifies that PSF/MVS On the OUTPUT

{QUIT } will take the standard action if a statement or dynamic
{HOLD } terminating error occurs during output descriptor,
printing. This is the default. indicates the disposition
See page 22-68 of the SYSOUT data set
QUIT= Specifies that PSF/MVS will to use if a terminating
release the data set complete even if error occurs during
a terminating error occurs during printing of the SYSOUT
printing. data with the PSF/MVS
functional subsystem.
HOLD= Specifies that if a terminating
error occurs during printing, the data
set will remain on the JES SPOOL
until the system operator releases it.

PRTOPTNS= {options data set entry name } print options: 1-16 valid EBCDIC Identifies the print
{’options data set entry name’} characters. options data.

See page 22-69

Chapter 22. OUTPUT JCL Statement 22-7

OUTPUT JCL
KEYWORD PARAMETERS VALUES PURPOSE

PRTQUEUE= {print queue name } print queue: 1-127 valid EBCDIC Identifies the target print
{’print queue name’} characters. queue name.

See page 22-70

PRTY=nnn nnn: 0 - 255 (0 is lowest, 255 is Specifies initial priority at

highest) which the sysout data
See page 22-71 set enters the output
queue.

RESFMT= {P240} P240: specifies 240 pels per inch Specifies the resolution
{P300} resolution. used to format the print
data set.
See page 22-71 P300: specifies 300 pels per inch
resolution.

RETAINS= {’<hhhh>:<mm>:<ss>’} retain time: 1-10 numeric characters The successful

{FOREVER } or FOREVER. transmission retain time
specification.
See page 22-72

RETAINF= {’<hhhh>:<mm>:<ss>’} retain time: 1-10 numeric characters The failed transmission
{FOREVER } or FOREVER. retain time specification.

See page 22-72

RETRYL= {nnn} nnnnn: one to five numeric The maximum number of

characters. retries.
See page 22-74

RETRYT= {’<hh>:<mm>:<ss>’} retry time: 1-10 numeric characters. Wait time between
transmission retries.
See page 22-74

ROOM= {’room identification’} room identification: 1-60 valid Specifies a room

{room-identification } EBCDIC text values identification to be
printed on output
See page 22-75 separator pages.

SYSAREA= {YES} YES or Y: requests that the system Indicates whether the
{Y } reserve a system area. system should reserve a
{NO } system area on each
{N } NO or N: requests that the system page of output.
not reserve a system area.
See page 22-76

THRESHLD=limit limit: 1 - 99999999 Specifies the maximum

size for a sysout data
See page 22-77 set. Use it to obtain
simultaneous printing of
large data sets or many
data sets from one job.
(JES3 only)

TITLE= {’description of output’} description of output: 1 - 60 valid Identifies a report title to

{description-of-output } EBCDIC characters be printed on separator
pages.
See page 22-79

TRC= {YES} YES or Y: data set contains TRC Specifies whether or not
{Y } codes the sysout data set’s
{NO } records contain table
{N } NO or N: data set does not contain reference codes (TRC)
TRC codes as the second character.
See page 22-80

22-8 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL
KEYWORD PARAMETERS VALUES PURPOSE

UCS=character-set-code character-set-code: 1 - 4 Specifies universal

alphanumeric or $, #, @ characters character set, print train,
See page 22-81 or character-
arrangement table for a
3800 Printing
Subsystem.

USERDATA=value From 1 to 16 values; each value may Defined by the

(value[,value]...) be from 1 to 60 EBCDIC characters. installation. Refer to your
installation’s definition on
See page 22-83 the intent and use of this
keyword. If your
installation does not
define any use for this
keyword, the information
will be syntax checked,
stored as part of the
output descriptor’s
information, and then
ignored.

USERLIB={data-set-name } data-set-name: 1 - 8 library data set Identifies libraries

{(data-set-name1,data-set-name2, names containing AFP resources containing AFP
...data-set-name8)} resources for PSF to use
when processing sysout
See page 22-87 data sets.

WRITER=name name: 1 - 8 alphanumeric characters Names an external writer

to process the sysout
See page 22-88 data set rather than JES.

Default OUTPUT JCL Statement

An OUTPUT JCL statement that contains a DEFAULT=YES parameter is called a

default OUTPUT JCL statement.

Comments Field
The comments field follows the parameter field after at least one intervening blank.

Location in the JCL

References by Sysout DD Statements

An OUTPUT JCL statement can be referenced by a sysout DD statement in two

ways:
v Explicitly. The sysout DD statement contains an OUTPUT parameter that
specifies the name of the OUTPUT JCL statement. You must place the OUTPUT
JCL statement in the input stream before any sysout DD statement that refers to
it.
v Implicitly. The sysout DD statement does not contain an OUTPUT parameter.
Implicit references are to default OUTPUT JCL statements. The sysout DD
statement implicitly references all step-level default OUTPUT JCL statements in
the same step.

Note: If the sysout DD statement does not contain an OUTPUT parameter and the
job or step does not contain a default OUTPUT JCL statement, processing of

Chapter 22. OUTPUT JCL Statement 22-9

OUTPUT JCL
the sysout data set is controlled only by the DD statement, a JES2
/*OUTPUT statement or a JES3 //*FORMAT statement, and appropriate
installation defaults.

Job-Level OUTPUT JCL Statements

This statement appears after the JOB statement and before the first EXEC
statement. It cannot be used for a started procedure.

Step-Level OUTPUT JCL Statements

This statement appears in a step, that is, anywhere after the first EXEC statement
in a job, except within a concatenated DD statement.

Location of Default OUTPUT JCL Statements

Where you place default OUTPUT JCL statements determines to which statements
a sysout DD statement implicitly refers. A sysout DD statement implicitly references
all job-level default OUTPUT JCL statements when the step containing the DD
statement does not contain any step-level default OUTPUT JCL statements.

You can place more than one job- or step-level default OUTPUT JCL statement in a
job or step.

OUTPUT JCL Statement with JESDS Parameter

Place an OUTPUT JCL statement with a JESDS parameter after the JOB statement
and before the first EXEC statement.

OUTPUT JCL Statements in Cataloged or In-Stream Procedures

OUTPUT JCL statements can appear in procedure steps. The referencing DD

statement can appear later in the procedure, in the calling job step, or in a later
step in the job.

An OUTPUT JCL statement must not be placed before the first EXEC statement in
a procedure; for this reason, procedures cannot contain job-level OUTPUT JCL
statements or OUTPUT JCL statements with JESDS parameters.

A procedure DD statement can refer to an OUTPUT JCL statement in an earlier job

step or to a job-level OUTPUT JCL statement. However, a procedure DD statement
cannot refer to an OUTPUT JCL statement in the calling step.
Table 22-1. Job- and Step-Level OUTPUT JCL Statements in the JCL

Job in Input Stream //jobname JOB ...

//name OUTPUT ... Job-level OUTPUT JCL statement
Step 1 //STEP1 EXEC PGM=X
//name OUTPUT ... Step-level OUTPUT JCL statement for STEP1
//DD1 DD ...
//DD2 DD ...
//DD3 DD ...
Step 2 //STEP2 EXEC PROC=A
//name OUTPUT ... Step-level OUTPUT JCL statement for STEP2
//DD1 DD ...
//DD2 DD ...
//DD3 DD ...

22-10 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL
Table 22-1. Job- and Step-Level OUTPUT JCL Statements in the JCL (continued)

Procedure A in
SYS1.PROCLIB // PROC ...
Procedure Step 1 //PSTEP1 EXEC PGM=G Step-level OUTPUT JCL statement for PSTEP1
//name OUTPUT ...
//DD4 DD ...
//DD5 DD ...
//DD6 DD ...
Procedure Step 2 //PSTEP2 EXEC PGM=H
//name OUTPUT ... Step-level OUTPUT JCL statement for PSTEP2
//DD7 DD ...
//DD8 DD ...
//DD9 DD ...

Overrides
v Parameters on a sysout DD statement override corresponding parameters on an
OUTPUT JCL statement.
v Parameters that appear only on the sysout DD statement or only on the
OUTPUT JCL statement are used by JES in processing the data set.

Relationship to Sysout DD Statement

Do not refer to an OUTPUT JCL statement in a sysout DD statement that defines a
JES internal reader. Such a DD statement contains an INTRDR subparameter in
the SYSOUT parameter.

Relationship to the JES2 /*OUTPUT Statement

JES2 ignores a JES2 /*OUTPUT statement when either of the following appears in
the same job or step:
v A default OUTPUT JCL statement implicitly referenced by the sysout DD
statement.
v An OUTPUT JCL statement explicitly referenced by the OUTPUT parameter of
the sysout DD statement.

In this case, JES2 uses the third positional subparameter of the DD SYSOUT
parameter as a form name, and not as a reference to a JES2 /*OUTPUT statement.

Relationship to the JES3 //*FORMAT Statement

v When a sysout DD statement implicitly or explicitly references an OUTPUT JCL
statement, JES3 ignores any default JES3 //*FORMAT statements in the job. A
default //*FORMAT statement contains a DDNAME=, parameter.
v When a JES3 //*FORMAT statement contains a DDNAME parameter that
explicitly references a sysout DD statement, JES3 ignores any default OUTPUT
JCL statements in the job.
v JES3 uses the processing options from both a JES3 //*FORMAT statement and
an OUTPUT JCL statement in a job when (1) the //*FORMAT statement
DDNAME parameter names a sysout DD statement and (2) the sysout DD
statement’s OUTPUT parameter names an OUTPUT JCL statement. Two
separate sets of output are created from the data set defined by the sysout DD
statement:
– One processed according to the options on the JES3 //*FORMAT statement
combined with the sysout DD statement.

Chapter 22. OUTPUT JCL Statement 22-11

OUTPUT JCL
– One processed according to the options on the OUTPUT JCL statement
combined with the sysout DD statement.

For more information on the use of the OUTPUT JCL statement with JES3, see
z/OS JES3 Initialization and Tuning Guide.

ADDRESS Parameter
Parameter Type

Keyword, optional

Purpose

Use the ADDRESS parameter to print an address on the separator pages of an

output data set. An installation can use the address to assist in sysout distribution.

Syntax
ADDRESS= {(’delivery address’[,’delivery address’]...)}
{delivery-address }
Valid Characters in Enclosing Apostrophes:
v A delivery address enclosed in apostrophes can contain any EBCDIC text character.
v Enclose a value that contains a blank in apostrophes.
v To code an apostrophe in the delivery address, code 2 apostrophes, and enclose the
entire delivery address in single apostrophes. For example:
//OUTDS OUTPUT ADDRESS=’O’’DARBY AVE’
v Each value may optionally be enclosed in apostrophes.

Valid Characters Without Enclosing Apostrophes: When the value for delivery address is
not enclosed in apostrophes, the following characters are valid:
v Alphanumeric and national (@, $, #) characters
v Period (.) and asterisk (*); however, an asterisk followed by a period indicates a referral
and is not allowed as the start (first and second characters) of the value.
v Ampersand (&). An ampersand that refers to a symbolic is substituted. Two consecutive
ampersands are not substituted, but they will result in a single ampersand as part of the
value.
v Plus sign (+)
v Hyphen (-)
v Slash (/)

Null Subparameters: You may code a null subparameter to cause a blank line to appear in
the delivery address. Code a comma to indicate the omitted subparameter.

Symbolic Parameters: Do not enclose symbolic parameters within apostrophes. Symbolic

parameters enclosed in apostrophes are not resolved for this keyword.

Subparameter Definition
delivery address
Specifies the delivery address for the output data set. You can code up to 4
delivery addresses. Each delivery address can be 1 - 60 EBCDIC text
characters. See “Character Sets” on page 4-3 for a description of EBCDIC text
characters.

22-12 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: ADDRESS
Defaults
v In an APPC scheduling environment:
In both JES2 and JES3 systems, if you do not code ADDRESS, the system uses
the value defined in the transaction program (TP) user’s RACF profile when:
– The user submitting the TP profile has a RACF profile defined for him, and
– The transaction program profile includes TAILOR_SYSOUT(YES).
v In a non-APPC scheduling environment:
There is no default for the ADDRESS parameter on the OUTPUT JCL statement.

Overrides
v In an APPC scheduling environment:
In both JES2 and JES3 systems, the ADDRESS parameter on the OUTPUT JCL
statement overrides the address in the RACF profile.
v In a non-APPC scheduling environment:
In both JES2 and JES3 systems, there are no override considerations for
ADDRESS.

Examples of the ADDRESS Parameter

Example 1
//OUTDS2 OUTPUT ADDRESS=(’J. Plant’,’1234 Main Street’,
// ’POUGHKEEPSIE, NY’,’zipcd’)

In this example, the address

J. Plant
1234 Main Street
POUGHKEEPSIE, NY
zipcd

is printed on the separator pages of each output data set that references OUTDS2.
You may code a name in the address field when the name associated with an
address is not the name you want to associate with the output (coded on the
OUTPUT NAME statement.) The name appears in the address field on the
separator pages.

Example 2
//OUTDS3 OUTPUT ADDRESS=(,’57 FAIR LANE’,’OMAHA,NE’,12121)

In this example, the following address is printed on the separator pages of each
output data set that references OUTDS3.

57 FAIR LANE
OMAHA,NE
12121

The first line reserved for the address on the separator page will be blank. Note that
12121 does not require enclosing apostrophes, because it contains only characters
that are valid without them.

Chapter 22. OUTPUT JCL Statement 22-13

OUTPUT JCL: BUILDING

BUILDING Parameter
Parameter Type

Keyword, optional

Purpose

Use the BUILDING parameter to print a building identification on the separator

pages of an output data set. An installation can use the building location to assist in
sysout distribution.

Syntax
BUILDING= {’building identification’}
{building-identification }
Valid Characters in Enclosing Apostrophes:
v A building identification enclosed in apostrophes can contain any EBCDIC text character.
v When the value for building identification contains a blank, enclose the value in
apostrophes.
v To code an apostrophe in the building identification, code 2 apostrophes, and enclose the
building identification in single apostrophes. For example:
//OUTDS OUTPUT BUILDING=’O’’REILLY BUILDING’
v Each value may be optionally enclosed in apostrophes.

Valid Characters Without Enclosing Apostrophes: When the value for building
identification is not enclosed in apostrophes, the following characters are valid:
v Alphanumeric and national (@, $, #) characters
v Period (.) and asterisk (*); however, an asterisk followed by a period indicates a referral
and is not allowed as the start (first and second characters) of the value.
v Ampersand (&). An ampersand that refers to a symbolic is substituted. Two consecutive
ampersands are not substituted, but they will result in a single ampersand as part of the
value.
v Plus sign (+)
v Hyphen (-)
v Slash (/)

Symbolic Parameters: Do not enclose symbolic parameters in apostrophes. Symbolic

parameters within apostrophes are not resolved for this keyword.

Subparameter Definition
building identification
Specifies the building location associated with the output data set. The value for
building location is 1 - 60 EBCDIC text characters. See “Character Sets” on
page 4-3 for a description of EBCDIC text characters.

Defaults
v In an APPC scheduling environment:
In both JES2 and JES3 systems, if you do not code BUILDING, the system uses
the value defined in the transaction program (TP) user’s RACF profile when:
– The user submitting the TP profile has a RACF profile defined for him, and
– The transaction program profile includes TAILOR_SYSOUT(YES).
v In a non-APPC scheduling environment:

22-14 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: BUILDING
There is no default for the BUILDING parameter on the OUTPUT JCL statement.

Overrides
v In an APPC scheduling environment:
In both JES2 and JES3 systems, the BUILDING parameter on the OUTPUT JCL
statement overrides the building in the RACF profile.
v In a non-APPC scheduling environment:
In both JES2 and JES3 systems, there are no override considerations for
BUILDING.

Example of the BUILDING Parameter

//OUTDS3 OUTPUT BUILDING=’920’

In this example, 920 will be printed on the line reserved for BUILDING on the
separator pages of any output data set that references OUTDS3.

BURST Parameter
Parameter Type

Keyword, optional

Purpose

Use the BURST parameter to specify that the output for the sysout data set printed
on a 3800 Printing Subsystem is to go to:
v The burster-trimmer-stacker, to be burst into separate sheets.
v The continuous forms stacker, to be left in continuous fanfold.

If the specified stacker is different from the last stacker used, or if a stacker was not
previously requested, JES issues a message to the operator to thread the paper
into the required stacker.

Note: BURST applies only for a data set printed on a 3800 equipped with a
burster-trimmer-stacker.

Syntax
BURST= {YES}
{Y }
{NO }
{N }

Subparameter Definition
YES
Requests that the printed output is to be burst into separate sheets. This
subparameter can also be coded as Y.
NO
Requests that the printed output is to be in a continuous fanfold. This
subparameter can also be coded as N.

Chapter 22. OUTPUT JCL Statement 22-15

OUTPUT JCL: BURST
Defaults
If you do not code a BURST parameter and the sysout data set is printed on a
3800 that has a burster-trimmer-stacker, JES uses an installation default specified
at initialization.

Overrides
A BURST parameter on the sysout DD statement overrides the OUTPUT JCL
BURST parameter.

Example of the BURST Parameter

//OUTDS1 OUTPUT BURST=YES

In this example, the output from the 3800 will be burst into separate sheets.

CHARS Parameter
Parameter Type

Keyword, optional

Purpose

Use the CHARS parameter to specify the name of one or more

character-arrangement tables for printing the sysout data set on a 3800 Printing
Subsystem.

Note:
v CHARS applies only for a data set printed on a 3800.
v STD applies only on a JES3 system.

References

For more information on character-arrangement tables, see the 3800 Programmer’s

Guide. Refer to SMP/E User’s Guide for information on choosing particular groups,
other than the Basic group (which is always available), during system initialization.

Syntax
CHARS= {table-name }
{(table-name[,table-name]...)}
{STD }
{DUMP }
{(DUMP[,table-name]...) }

v You can omit the parentheses if you code only one table-name.
v Null positions in the CHARS parameter are invalid. For example, you cannot code
CHARS=(,table-name) or CHARS=(table-name,,table-name).

Subparameter Definition
table-name
Names a character-arrangement table. Each table-name is 1 through 4
alphanumeric or national ($, #, @) characters. Code one to four names.

22-16 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: CHARS
STD
Specifies the standard character-arrangement table. JES3 uses the standard
table specified at initialization.

Note: STD is supported only on JES3 systems.

DUMP
Requests a high-density dump of 204-character print lines from a 3800. If more
than one table-name is coded, DUMP must be first.

Note: DUMP is valid only on the OUTPUT JCL statement referenced in a

SYSABEND or SYSUDUMP DD statement that specifies a sysout data
set for the dump.

Defaults
If you do not code the OUTPUT JCL CHARS parameter, JES uses the following, in
order:
1. The DD CHARS parameter.
2. The DD UCS parameter value, if coded.
3. The OUTPUT JCL UCS parameter value, if coded.

If no character-arrangement table is specified on the DD or OUTPUT JCL

statements, JES uses an installation default specified at initialization.

Overrides
A CHARS parameter on the sysout DD statement overrides the OUTPUT JCL
CHARS parameter.

For a data set scheduled to the Print Services Facility (PSF), the PSF uses the
following parameters, in override order, to select the font list:
1. Font list in the library member specified by an OUTPUT JCL PAGEDEF
parameter.
2. DD CHARS parameter.
3. OUTPUT JCL CHARS parameter.
4. DD UCS parameter.
5. OUTPUT JCL UCS parameter.
6. JES installation default for the device.
7. Font list on the PAGEDEF parameter in the PSF cataloged procedure.

See “PAGEDEF Parameter” on page 22-63 for more information.

Requesting a High-Density Dump

You can request a high-density dump on the 3800 through two parameters on the
DD statement for the dump data set or on an OUTPUT JCL statement referenced
by the dump DD statement:
v FCB=STD3. This parameter produces dump output at 8 lines per inch.
v CHARS=DUMP. This parameter produces 204-character print lines.

You can code one or both of these parameters. You can place both on the same
statement or one on each statement.

Example of the CHARS Parameter

//OUTDS2 OUTPUT CHARS=(GT12,GB12,GI12)

Chapter 22. OUTPUT JCL Statement 22-17

OUTPUT JCL: CHARS
In this example, the output from the 3800 will be printed in three upper and lower
case fonts: GT12, Gothic 12-pitch; GB12, Gothic Bold 12-pitch; and GI12, Gothic
Italic 12-pitch.

CKPTLINE Parameter
Parameter Type

Keyword, optional

Purpose

Use the CKPTLINE parameter to specify the maximum number of lines in a logical
page. JES uses this value, with the CKPTPAGE parameter, to determine when to
take checkpoints while printing the sysout data set or transmitting the systems
network architecture (SNA) data set.

Note: A JES3 system supports this parameter only when the functional subsystem
prints the sysout data set on a 3800 Printing Subsystem Models 3, 6 and 8.

Syntax
CKPTLINE=nnnnn

Subparameter Definition
nnnnn
Specifies the maximum number of lines in a logical page. nnnnn is a number
from 0 through 32,767.

Defaults
If you do not code the CKPTLINE parameter, JES2 uses an installation default
specified at initialization. JES3 provides no installation default.

Example of the CKPTLINE Parameter

//OUTDS3 OUTPUT CKPTLINE=4000,CKPTPAGE=5

In this example, the sysout data set will be checkpointed after every 5 logical
pages. Each logical page contains 4000 lines.

CKPTPAGE Parameter
Parameter Type

Keyword, optional

Purpose

Use the CKPTPAGE parameter to specify the number of logical pages:

v To print before JES takes a checkpoint.
v To transmit as a single systems network architecture (SNA) chain to an SNA
work station before JES takes a checkpoint.

22-18 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: CKPTPAGE
The CKPTLINE parameter specifies the number of lines in these logical pages.

Note: A JES3 system supports this parameter only when the functional subsystem
prints the sysout data set on a 3800 Printing Subsystem Models 3, 6 and 8.

Syntax
CKPTPAGE=nnnnn

Subparameter Definition
nnnnn
Specifies the number of logical pages to print or transmit before the next sysout
data set checkpoint is taken. nnnnn is a number from 1 through 32,767.

Defaults
If you do not code the CKPTPAGE parameter, JES2 uses an installation default
specified at initialization; the default may also indicate whether checkpoints are to
be based on page count or time. JES3 provides no installation default.

Relationship to Other Parameters

If you code both the CKPTPAGE and CKPTSEC parameters:
v JES2 uses the value on the CKPTSEC parameter, provided the installation did
not specify at initialization that checkpoints are to be based only on page count
or time.
v JES3 uses the value on the CKPTPAGE parameter.

Example of the CKPTPAGE Parameter

//OUTDS4 OUTPUT CKPTPAGE=128,CKPTLINE=58

In this example, the sysout data set will be checkpointed after every 128 logical
pages. Each logical page contains 58 lines.

CKPTSEC Parameter
Parameter Type

Keyword, optional

Purpose

Use the CKPTSEC parameter to specify how many seconds are to elapse between
checkpoints of the sysout data set that JES is printing.

Note: A JES3 system supports this parameter only when the functional subsystem
prints the sysout data set on a 3800 Printing Subsystem Models 3, 6 and 8.

Syntax
CKPTSEC=nnnnn

Chapter 22. OUTPUT JCL Statement 22-19

OUTPUT JCL: CKPTSEC
Subparameter Definition
nnnnn
Specifies the number of seconds that is to elapse between checkpoints. nnnnn
is a number from 1 through 32,767.

Defaults
If you do not code the CKPTSEC parameter, JES2 uses an installation default
specified at initialization; the default may also indicate whether checkpoints are to
be based on page count or time. JES3 provides no installation default.

Relationship to Other Parameters

If you code both the CKPTPAGE and CKPTSEC parameters:
v JES2 uses the value on the CKPTSEC parameter, provided the installation did
not specify at initialization that checkpoints are to be based only on page count
or time.
v JES3 uses the value on the CKPTPAGE parameter.

Example of the CKPTSEC Parameter

//OUTDS5 OUTPUT CKPTSEC=120

In this example, the sysout data set will be checkpointed after every 120 seconds,
or 2 minutes.

CLASS Parameter
Parameter Type

Keyword, optional

Purpose

Use the CLASS parameter to assign the sysout data set to an output class.

Note: If a sysout data set has the same class as the JOB statement MSGCLASS
parameter, the job log appears on the same output listing as the sysout data
set.

Syntax
CLASS= {class}
{* }

Subparameter Definition
class
Identifies the output class for the data set. The class is one character: A through
Z or 0 through 9, which you may optionally include in quotation marks. The
attributes of each output class are defined during JES initialization; specify the
class with the desired attributes.
* Requests the output class in the MSGCLASS parameter on the JOB statement.

22-20 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: CLASS
null value
Requests the output class in the MSGCLASS parameter on the JOB statement.

Overrides
The class subparameter of the DD statement SYSOUT parameter overrides the
OUTPUT JCL CLASS parameter. On the DD statement, you must code a null class
in order to use the OUTPUT JCL CLASS parameter; for example:
//OUTDS DD SYSOUT=(,),OUTPUT=*.OUT1

Held Classes in a JES2 System

An installation option at JES2 initialization determines if both the class for the
sysout data set and the class for the job’s messages must be held in order for a
sysout data set to be held.

A sysout data set is held in the following cases:

v The sysout DD statement contains HOLD=YES.
v The sysout DD statement does not contain a HOLD parameter or contains
HOLD=NO but requests a class that the installation defined as held and defined
as:
– Not requiring the message class to be a held class in order for the sysout
data set to be held. The JOB statement MSGCLASS parameter can specify
any class.
– Requiring the message class to be a held class in order for the sysout data
set to be held. The JOB MSGCLASS parameter must also specify a held
class.
v The OUTPUT JCL statement specifies OUTDISP=HOLD.

A sysout data set is not held in the following cases:

v The sysout DD statement does not contain a HOLD parameter or contains
HOLD=NO and requests:
– A class that the installation defined as not held.
– A class that the installation defined as held and defined as requiring the
message class to be a held class in order for the sysout data set to be held.
The JOB MSGCLASS parameter must specify a class that is not held.

Contact the installation to find out if holding the sysout class depends on a held
MSGCLASS class.

Held Classes in a JES3 System

If CLASS specifies a class-name that is defined to JES3 as a held class for the
output service hold queue (Q=HOLD), all of the new output characteristics might not
be included in the data set on the writer queue when (1) the data set is moved from
the hold queue to the output service writer queue (Q=WTR), (2) the data set
includes an OUTPUT JCL statement, and (3) the NQ= or NCL= keyword is used.

For more information, see z/OS JES3 Initialization and Tuning Guide.

Significance of Output Classes

To print this sysout data set and the messages from your job on the same output
listing, code one of the following:
v The same output class in the DD SYSOUT parameter as in the JOB MSGCLASS
parameter.

Chapter 22. OUTPUT JCL Statement 22-21

OUTPUT JCL: CLASS
v DD SYSOUT=* to default to the JOB MSGCLASS output class.
v DD SYSOUT=(,) to default to one of the following:
1. The CLASS parameter in an explicitly or implicitly referenced OUTPUT JCL
statement. In this case, the OUTPUT JCL CLASS parameter should specify
the same output class as the JOB MSGCLASS parameter.
2. The JOB MSGCLASS output class, if no OUTPUT JCL statement is
referenced or if the referenced OUTPUT JCL statement contains either
CLASS= or CLASS=*.

Examples of the CLASS Parameter

Example 1
//OUTDS6 OUTPUT CLASS=D
//OUT1 DD SYSOUT=(,),OUTPUT=*.OUTDS6

In this example, JES processes the sysout data set defined in DD statement OUT1
in output class D.

Example 2
//PRINTALL JOB ACCT123,MAEBIRD,MSGCLASS=H
//STEP1 EXEC PGM=PRINTER
//OUTDS7 OUTPUT CLASS=*
//OUTPTR DD SYSOUT=(,),OUTPUT=*.OUTDS7

In this example, JES processes the sysout data set defined in DD statement
OUTPTR in output class H, as specified in the JOB statement MSGCLASS
parameter. The same result could be obtained by the following:
//PRINTALL JOB ACCT123,MAEBIRD,MSGCLASS=H
//STEP1 EXEC PGM=PRINTER
//OUTPTR DD SYSOUT=H

COLORMAP Parameter
Parameter Type

Keyword, optional

Purpose

Use COLORMAP to specify the AFP Resource (object) for the data set that
contains color translation information. For more information see the PSF/MVS
Application Programming Guide.

Syntax
COLORMAP=resource

Subparameter Definition
resource
Specifies the name of an AFP resource, where the resource name is 1 through
8 alphanumeric or national ($, #, @) characters and the first must be alphabetic
or national.

22-22 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: COLORMAP
Example of the COLORMAP Parameter
//OUTCOLOR OUTPUT COLORMAP=M1SETUP

In this example, M1SETUP is the name of the AFP resource.

COMPACT Parameter
Parameter Type

Keyword, optional

Purpose

Use the COMPACT parameter to specify a compaction table for JES to use when
sending the sysout data set, which is a systems network architecture (SNA) data
set, to a SNA remote terminal.

Syntax
COMPACT=compaction-table-name

Subparameter Definition
compaction-table-name
Specifies a compaction table by a symbolic name. The name is 1 through 8
alphanumeric characters. The symbolic name must be defined by the
installation during JES initialization.

Defaults
If you do not code the COMPACT parameter, compaction is suppressed for the data
set.

Overrides
This parameter overrides any compaction table value defined at the SNA remote
terminal.

Example of the COMPACT Parameter

//OUTDS8 OUTPUT DEST=N555R222,COMPACT=TBL77

In this example, the sysout data set will be sent to remote terminal 222 at node
555; JES will use compaction table TBL77.

COMSETUP Parameter
Parameter Type

Keyword, optional

Purpose

Use the COMSETUP parameter to specify the name of a microfile setup resource
that contains setup information.

Chapter 22. OUTPUT JCL Statement 22-23

OUTPUT JCL: COMSETUP
References

For more information, see PSF/MVS Application Programming Guide.

Syntax
COMSETUP=resource

Subparameter Definition
resource
Specifies the name of a macrofile setup resource, where the resource name is
1 through 8 alphanumeric or national ($, #, @) characters. (The first must be
alphabetic or national.)

Example of the COMSETUP Parameter

//RPTDS OUTPUT COMSETUP=H1SETUP

In this example, H1SETUP is the name of a macrofile setup resource.

CONTROL Parameter
Parameter Type

Keyword, optional

Purpose

Use the CONTROL parameter to specify either that each logical record starts with a
carriage control character or that the output is to be printed with single, double, or
triple spacing.

Syntax
CONTROL= {PROGRAM}
{SINGLE }
{DOUBLE }
{TRIPLE }

Subparameter Definition
PROGRAM
Indicates that each logical record in the data set begins with a carriage control
character. You can specify in the DD statement, the DCB macro, or the data set
label that an optional control character is part of each record in the data set.
The carriage control characters are given in z/OS DFSMS: Using Data Sets.
SINGLE
Indicates forced single spacing.
DOUBLE
Indicates forced double spacing.
TRIPLE
Indicates forced triple spacing.

22-24 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: CONTROL
Defaults
If you do not code the CONTROL parameter, JES3 uses an installation default
specified at initialization.

In a JES2 system, an installation default can be provided for each local device by
an operator command.

Example of the CONTROL Parameter

//OUTDS9 OUTPUT CONTROL=PROGRAM

In this example, the sysout data set is printed using the first character of each
logical record for carriage control.

COPIES Parameter
Parameter Type

Keyword, optional

Purpose

Use the COPIES parameter to specify how many copies of the sysout data set to
print. The printed output is in page sequence for each copy.

For printing on a 3800 Printing Subsystem, this parameter can instead specify how
many copies of each page are to be printed before the next page is printed.

Syntax
COPIES= {nnn }
{(nnn,(group-value[,group-value]...))}
{(,(group-value[,group-value]...)) }

v You can omit the parentheses if you code only COPIES=nnn.

v The following are not valid:
– A null group-value, for example, COPIES=(5,(,)) or COPIES=(5,)
– A zero group-value, for example, COPIES=(5,(1,0,4))
– A null within a list of group-values, for example, COPIES=(5,(1,,4))

Subparameter Definition
nnn
A number (1 through 255 in a JES2 system, 1 through 254 in a JES3 system)
that specifies how many copies of the sysout data set to print. Each copy will
be in page sequence order.
For a data set printed on a 3800, JES ignores nnn if any group values are
specified.
group-value
Specifies how many copies of each page are to be printed before the next page
is printed. Each group-value is 1 through 3 decimal numbers from 1 through
255 in a JES2 system and from 1 through 254 in a JES3 system. You can code
a maximum of eight group-values. Their sum must not exceed 255 or 254. The
total copies of each page equals the sum of the group-values.

Chapter 22. OUTPUT JCL Statement 22-25

OUTPUT JCL: COPIES
Note:
v This subparameter is valid only for 3800 output.
v For 3800 output, this subparameter overrides an nnn subparameter, if coded.

Defaults
For JES2, on the DD, OUTPUT JCL, or /*OUTPUT statement: if you do not code a
COPIES parameter, code it incorrectly, or code COPIES=0, the system uses a
default of 1, which is the default for the DD COPIES parameter.

For JES3, on the DD, OUTPUT JCL, or //*FORMAT statement: if you do not code a
COPIES parameter, code it incorrectly, or code COPIES=0 on the DD statement,
the system uses a default of 1, which is the default for the DD COPIES parameter.

Overrides
A COPIES parameter on the sysout DD statement overrides the OUTPUT JCL
COPIES parameter.

If the OUTPUT JCL statement contains a FORMDEF parameter, which specifies a

library member, the COPYGROUP parameter on a FORMDEF statement in that
member overrides any group-value subparameters on the OUTPUT JCL COPIES
parameter or the sysout DD COPIES parameter. For more information, see
“FORMDEF Parameter” on page 22-42.

Relationship to Other Parameters

If the OUTPUT JCL or the sysout DD statement contains a FLASH parameter, JES
prints with the forms overlay the number of copies specified in one of the following:
v COPIES=nnn, if the FLASH count is larger than nnn. For example, if COPIES=10
and FLASH=(LTHD,12) JES prints 10 copies, all with the forms overlay.
v The sum of the group-values specified in the COPIES parameter, if the FLASH
count is larger than the sum. For example, if COPIES=(,(2,3,4) and
FLASH=(LTHD,12) JES prints nine copies in groups, all with the forms overlay.
v The count subparameter in the FLASH parameter, if the FLASH count is smaller
than nnn or the sum from the COPIES parameter. For example, if COPIES=10
and FLASH=(LTHD,7) JES prints seven copies with the forms overlay and three
copies without.

Relationship to Other Control Statements

For JES2, if you request copies of the entire job on the JES2 /*JOBPARM COPIES
parameter and also copies of the data set on the DD COPIES or OUTPUT JCL
COPIES parameter, JES2 prints the number of copies equal to the product of the
two requests.

Examples of the COPIES Parameter

Example 1
//RPTDS OUTPUT COPIES=4,FORMS=WKREPORT

This example asks JES to print four copies of the weekly report on forms named
WKREPORT.

Example 2
//EXPLD OUTPUT COPIES=(,(3)),FORMS=ACCT

22-26 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: COPIES
This example asks JES to print the first page three times, then the second page
three times, the third page three times, etc., on forms named ACCT.

Example 3
//QUEST OUTPUT COPIES=(,(8,25,18,80)),FORMS=ANS

This example asks JES to print each page eight times before printing the next
page, then 25 times before the next, then 18 times before the next, and finally 80
times before the next. The forms are named ANS.

Example 4
//EXMP OUTPUT COPIES=(5,(3,2))

This example asks JES to do one of the following:

v If the data set is printed on other than a 3800, to print five copies.
v If it is printed on a 3800, to print each page three times before printing the next
page and then to print each page twice before printing the next page.

DATACK Parameter
Parameter Type

Keyword, optional

Purpose

Use the DATACK parameter to indicate whether or not print-positioning and

invalid-character data-check errors are to be blocked or unblocked for printers
accessed through the Print Services Facility (PSF) functional subsystem.

A print-positioning error occurs when the designated position of any kind of printable
information is beyond the limits of either the physical page, or the overlay or logical
page of which it is part.

An invalid-character data-check error occurs when the hexadecimal representation

of a text character has no mapping in the code page to a member of the font raster
patterns.

If an error type is unblocked, the printer reports the error at the end of the page in
which it occurs, and PSF processes the error and generates an error message.
(See the PIMSG parameter for more information on the printing of error messages.)

If an error type is blocked, the printer does not report the error to PSF. Printing
continues but data may be lost on the output.

References

For more information on data-check errors and their processing through PSF, see
PSF/MVS Application Programming Guide or PSF/MVS System Programming
Guide.

Chapter 22. OUTPUT JCL Statement 22-27

OUTPUT JCL: DATACK
Syntax
DATACK= {BLOCK }
{UNBLOCK}
{BLKCHAR}
{BLKPOS }

Subparameter Definition
BLOCK
Indicates that print-positioning errors and invalid-character errors are not
reported to PSF.
UNBLOCK
Indicates that print-positioning errors and invalid-character errors are reported to
PSF.
BLKCHAR
Indicates that invalid-character errors are blocked, and not reported to PSF.
Print-positioning errors are reported normally.
BLKPOS
Indicates that print-positioning errors are blocked, and not reported to PSF.
Invalid-character errors are reported normally.

Defaults
If you do not code the DATACK parameter, the DATACK specification from the PSF
PRINTDEV statement is used. If not specified in the PRINTDEV statement, the
default is BLOCK. For information about the PRINTDEV statement, see PSF for
OS/390 & z/OS: Customization.

Relationship to Other Parameters

If DATACK is specified as UNBLOCK, BLKCHAR, or BLKPOS, and an unblocked
error occurs, the printer reports the error to PSF which processes the error. The
coding of the PIMSG parameter then determines whether or not printing of the data
set continues after the page in error, and if error messages are printed at the end of
the data set.

Example of the DATACK Parameter

//OUTDS1 OUTPUT DATACK=BLKCHAR,PIMSG=(YES,0)

In this example, when a print-position error occurs, it is reported to the user via a
printed error message. If an invalid-character error occurs, it is not reported. In
either case, the printing of the data set continues, and all functional subsystem
messages are printed.

DEFAULT Parameter
Parameter Type

Keyword, optional

Purpose

22-28 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: DEFAULT
Use the DEFAULT parameter to specify that this OUTPUT JCL statement can or
cannot be implicitly referenced by a sysout DD statement. An OUTPUT JCL
statement that contains a DEFAULT=YES parameter is called a default OUTPUT
JCL statement.

Syntax
DEFAULT= {YES}
{Y }
{NO }
{N }

Subparameter Definition
YES
Indicates that this OUTPUT JCL statement can be implicitly referenced by
sysout DD statements. This subparameter can also be coded as Y.
NO
Indicates that this OUTPUT JCL statement cannot be implicitly referenced by
sysout DD statements. This subparameter can also be coded as N.

Defaults
If you do not code DEFAULT=YES, the default is NO. In order to take effect, an
OUTPUT JCL statement without DEFAULT=YES must be explicitly referenced in an
OUTPUT parameter on a sysout DD statement.

Location in the JCL

v A step-level OUTPUT JCL statement appears within a step, that is, anywhere
after the first EXEC statement in a job.
v A job-level OUTPUT JCL statement appears after the JOB statement and before
the first EXEC statement.
v You can place more than one job- or step-level default OUTPUT JCL statement
in a job or step.
v You must place an OUTPUT JCL statement in the input stream before any
sysout DD statement that explicitly or implicitly refers to it.

References to Default OUTPUT JCL Statements

v A sysout DD statement makes an explicit reference in an OUTPUT parameter
that specifies the name of an OUTPUT JCL statement.
v A sysout DD statement makes an implicit reference when it does not contain an
OUTPUT parameter, and the job or step contains one or more default OUTPUT
JCL statements.
v A sysout DD statement implicitly references all step-level default OUTPUT JCL
statements in the same step.
v A sysout DD statement implicitly references all job-level default OUTPUT JCL
statements when the step containing the DD statement does not contain any
step-level default OUTPUT JCL statements.
v A sysout DD statement can explicitly reference a default OUTPUT JCL
statement.

Chapter 22. OUTPUT JCL Statement 22-29

OUTPUT JCL: DEFAULT
Example of the DEFAULT Parameter
//EXMP2 JOB ACCT555,MAEBIRD,MSGCLASS=B
//OUTDAL OUTPUT DEFAULT=YES,DEST=DALLAS
//OUTPOK OUTPUT DEST=POK
//STEP1 EXEC PGM=REPORT
//OUTHERE OUTPUT CLASS=D
//SYSIN DD *
.
.
.
/*
//WKRPT DD UNIT=VIO,DISP=(,PASS)
//RPT1 DD SYSOUT=(,),OUTPUT=*.OUTHERE
//RPT2 DD SYSOUT=A
//STEP2 EXEC PGM=SUMMARY
//OUTHQ OUTPUT DEFAULT=YES,DEST=HQ
//WKDATA DD UNIT=VIO,DISP=(OLD,DELETE),DSNAME=*.STEP1.WKRPT
//MONTH DD SYSOUT=(,),OUTPUT=*.STEP1.OUTHERE
//SUM DD SYSOUT=A
//FULRPT DD SYSOUT=A,OUTPUT=(*.OUTDAL,*.OUTPOK)

In this example, the JOB named EXMP2 contains two job-level OUTPUT JCL
statements: OUTDAL and OUTPOK. OUTDAL is a default OUTPUT JCL statement
because it contains DEFAULT=YES; OUTDAL can be implicitly referenced by a
sysout DD statement. OUTPOK must be explicitly referenced in a sysout DD
OUTPUT parameter for its processing options to be used. The purpose of both of
these OUTPUT JCL statements is to specify a destination for a sysout data set.

STEP1 contains a step-level OUTPUT JCL statement: OUTHERE. The purpose of

this statement is to specify that JES process the data set locally in output class D.
OUTHERE can be used only if it is explicitly referenced.

STEP2 contains a step-level default OUTPUT JCL statement: OUTHQ. The purpose
of this statement is to specify a destination for a sysout data set. OUTHQ can be
implicitly referenced.

The references in this job are as follows:

v In STEP1 and STEP2, sysout DD statements RPT1 and MONTH explicitly
reference OUTPUT JCL statement OUTHERE. These two sysout data sets are
printed locally in the same output class.

Note: You can explicitly reference an OUTPUT JCL statement in a preceding job
step.
v In STEP1, DD statement RPT2 implicitly references OUTPUT JCL statement
OUTDAL. This implicit reference occurs because all of the following are true:
1. DD statement RPT2 contains a SYSOUT parameter but does not contain an
OUTPUT parameter. Thus, this DD statement is making an implicit reference.
2. STEP1 does not contain a default OUTPUT JCL statement, so the implicit
reference must be to job-level default OUTPUT JCL statements.
3. OUTDAL is the only job-level default OUTPUT JCL statement.
v In STEP2, DD statement SUM implicitly references OUTPUT JCL OUTHQ
because all of the following are true:
1. DD statement SUM contains a SYSOUT parameter but does not contain an
OUTPUT parameter. Thus, this DD statement is making an implicit reference.

22-30 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: DEFAULT
2. STEP2 contains a default OUTPUT JCL statement: OUTHQ. Therefore, the
implicit reference is to OUTHQ and cannot be to any job-level default
OUTPUT JCL statements.
v In STEP2, DD statement FULRPT explicitly references OUTPUT JCL statements
OUTDAL and OUTPOK.

DEPT Parameter
Parameter Type

Keyword, optional

Purpose

Use the DEPT parameter to print the department identification on the separator
pages of output for a sysout data set. An installation can use the department
identification to assist in sysout distribution.

Syntax
DEPT= {’department identification’}
{department-identification }
Valid Characters Within Enclosing Apostrophes:
v A department identification enclosed in apostrophes can contain any EBCDIC text
character
v When the value for department identification contains a blank, enclose the value in
apostrophes.
v To code an apostrophe in the department identification, code 2 apostrophes, and enclose
the department identification in single apostrophes. For example:
//OUTDS OUTPUT DEPT=’JACKSON’’S DEPT’
v Each value may optionally be enclosed in apostrophes.

Valid Characters Without Enclosing Apostrophes: When the value for department
identification is not enclosed in apostrophes, the following characters are valid:
v Alphanumeric and national (@, $, #) characters
v Period (.) and asterisk (*); however, an asterisk followed by a period indicates a referral
and is not allowed as the start (first and second characters) of the value.
v Ampersand (&). An ampersand that refers to a symbolic is substituted. Two consecutive
ampersands are not substituted, but they will result in a single ampersand as part of the
value.
v Plus sign (+)
v Hyphen (-)
v Slash (/)

Symbolic Parameters: Do not enclose symbolic parameters in apostrophes. Symbolic

parameters within apostrophes are not resolved for this keyword.

Subparameter Definition
department identification
Specifies the department identification associated with the sysout. The value for
department identification is 1 - 60 EBCDIC text characters. See “Character
Sets” on page 4-3 for a description of EBCDIC text characters.

Chapter 22. OUTPUT JCL Statement 22-31

OUTPUT JCL: DEPT
Defaults
In an APPC scheduling environment:
In both JES2 and JES3 systems, if you do not code DEPT, the system uses the
value defined in the transaction program (TP) user’s RACF profile when:
– The user submitting the TP profile has a RACF profile defined for him, and
– The transaction program profile includes TAILOR_SYSOUT(YES).
In a non-APPC scheduling environment:
There is no default for the DEPT parameter on the OUTPUT JCL statement.

Overrides
In an APPC scheduling environment:
In both JES2 and JES3 systems, the DEPT parameter on the OUTPUT JCL
statement overrides the department in the RACF profile.
In a non-APPC scheduling environment:
In both JES2 and JES3 systems, there are no override considerations for DEPT.

Example of the DEPT Parameter

//OUTDS4 OUTPUT DEPT=’PAYROLL’

In this example, PAYROLL will be printed on the line reserved for DEPT on
separator pages of any sysout data set that references OUTDS4.

DEST Parameter
Parameter Type

Keyword, optional

Purpose

Use the DEST parameter to specify a destination for the sysout data set. The DEST
parameter can send a sysout data set to a remote or local terminal, a node, a node
and remote work station, a local device or group of devices, or a node and userid.

22-32 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: DEST
Syntax
DEST=destination

The destination subparameter for JES2 is one of the following:

LOCAL|ANYLOCAL
’IP:ipaddr’
name
Nnnnn
NnnRmmmm
NnnnRmmm
NnnnnRmm
nodename.userid
’nodename.IP:ipaddr’
Rnnnn
RMnnnn
RMTnnnn
Unnnn
userid

The destination subparameter for JES3 is one of the following:

ANYLOCAL
’IP:ipaddr’
device-name
group-name
nodename
’nodename.IP:ipaddr’
nodename.remote

Subparameter Definition for JES2 Systems

LOCAL|ANYLOCAL
Indicates any local device.
’IP:ipaddr’ | ’nodename.IP:ipaddr’
Identifies a TCP/IP routing designation, where ipaddr can be any printable
character string of from 1 to 124 characters. The entire parameter list is limited
to 127 characters, and it must be enclosed in single quotes. This keyword is for
use only by functional subsystems (for example, IP PrintWay). See the
documentation for the particular subsystem for additional information.
name
Identifies a destination by a symbolic name (for example, a local device, remote
device, or a userid) which is defined by the installation during JES2 initialization.
The name can be, for example, a local device, remote device, or a userid. The
name is 1 through 8 alphanumeric or national ($, #, @) characters.
Nnnnn
Identifies a node. nnnn is 1 through 4 decimal numbers from 1 through 1000.
For example, N103.
NnnRmmmm
NnnnRmmm
NnnnnRmm
Identifies a node and a remote work station connected to the node. The node
number, indicated in the format by n, is 1 through 4 decimal numbers from 1
through 1000. The remote work station number, indicated in the format by m, is

Chapter 22. OUTPUT JCL Statement 22-33

OUTPUT JCL: DEST
1 through 4 decimal numbers from 1 through 9999. Do not code leading zeros
in n or m. The maximum number of digits for n and m combined cannot exceed
six.

Note: R0 is equivalent to LOCAL specified at node Nn.

nodename.userid
Identifies a destination node and a VM or a TSO/E userid, a remote
workstation, or a symbolic name defined at the destination node. The
nodename is a symbolic name defined at the node of execution. nodename is 1
through 8 alphanumeric or national ($, #, @) characters. userid is 1 through 8
alphanumeric or national ($, #, @) characters, and must be defined at the
specified node.
Rnnnn
RMnnnn
RMTnnnn
Identifies a remote workstation. nnnn is 1 through 4 decimal numbers from 1
through 9999. Note that with remote pooling, the installation may translate this
route code to another route code.
If you send a job to execute at a remote node and the job has a ROUTE PRINT
RMTnnnn statement, JES returns the output to RMTnnnn at the node of origin.
For JES2 to print the output at RMTnnnn at the executing node, code
DEST=NnnnRmmm on an OUTPUT JCL statement or sysout DD statement.

Note: R0 is equivalent to LOCAL.

Unnnn
Identifies a local terminal with special routing. nnnn is 1 through 4 decimal
numbers from 1 through 9999.
If you send a job to execute and the job has a ROUTE PRINT Unnnn
statement, JES returns the output to Unnnn at the node of origin.
userid
Identifies a userid at the local node.

Note: JES2 initialization statements determine whether or not the node name is
required when coding a userid. See your system programmer for
information about how routings will be interpreted by JES2.

Subparameter Definition for JES3 Systems

ANYLOCAL
Indicates any local device.
’IP:ipaddr’ | ’nodename.IP:ipaddr’
Identifies a TCP/IP routing designation, where ipaddr can be any printable
character string of from 1 to 124 characters. The entire parameter list is limited
to 127 characters, and it must be enclosed in single quotes. This keyword is for
use only by functional subsystems (for example, IP PrintWay). See the
documentation for the particular subsystem for additional information.
device-name
Identifies a local device by a symbolic name defined by the installation during
JES3 initialization. device-name is 1 through 8 alphanumeric or national ($, #,
@) characters.
group-name
Identifies a group of local devices, an individual remote station, or a group of

22-34 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: DEST
remote stations by a symbolic name defined by the installation during JES3
initialization. group-name is 1 through 8 alphanumeric or national ($, #, @)
characters.
nodename
Identifies a node by a symbolic name defined by the installation during JES3
initialization. The node is 1 through 8 alphanumeric or national ($, #, @)
characters. If the node you specify is the same as the node you are working on,
JES3 treats the output as though you had specified ANYLOCAL.
nodename.remote
Identifies a destination node and either a remote work station or VM userid at
that node, as follows:
nodename
A symbolic name defined by the installation during JES3 initialization. The
nodename is 1 through 8 alphanumeric or national characters.
remote
A name for a remote work station. The name is 1 through 8 alphanumeric
or national characters and must be defined at the node. Enclose it in
apostrophes when it contains special characters or begins with a number.

Defaults
In a JES2 system, if you do not code a DEST parameter, JES directs the sysout
data set to the default destination for the input device from which the job was
submitted.

In a JES3 system, if you do not code a DEST parameter, the default destination is
the submitting location. For jobs submitted through TSO/E and routed to NJE for
execution, the default is the node from which the job was submitted, and the
destination ANYLOCAL.

If a specified destination is invalid, the job fails.

Note: Most JCL syntax errors are detected and reported by JES or the functional
subsystem that is processing the sysout data set, rather than when the
system first reads in the JCL.

Overrides
A DEST parameter on the sysout DD statement overrides the OUTPUT JCL DEST
parameter.

Relationship to Other Parameters

For JES3, you can code the DEST=nodename parameter with the OUTPUT JCL
WRITER=name parameter; however, do not code DEST=nodename.userid with
WRITER=name.

Examples of the DEST Parameter

Example 1
//REMOT1 OUTPUT DEST=R444

In this example, JES2 sends the sysout data set to remote terminal 444.

Example 2
//REMOT2 OUTPUT DEST=STAT444

Chapter 22. OUTPUT JCL Statement 22-35

OUTPUT JCL: DEST
In this example, JES sends the sysout data set to an individual remote station
named by the installation STAT444.

Example 3
//REMOT3 OUTPUT DEST=KOKVMBB8.DP58HHHD

In this example, JES sends the sysout data set to VM userid DP58HHHD at node
KOKVMBB8.

Example 4
//REMOT4 OUTPUT DEST=’NEWYORK.IP:bldprt-2’

In this example JES2 sends the sysout data set to node NEWYORK, where a
functional subsystem that can process IP-distributed data sets sends the data to the
bldprt-2 host system.

Example 5
//REMOT5 OUTPUT DEST=’IP:9.117.84.53’

In this example the functional subsystem sends the sysout data to the host machine
at IP address 9.117.84.53.

DPAGELBL Parameter
Parameter Type

Keyword, optional

Purpose

Use the DPAGELBL (data page labelling) parameter to indicate whether the system
should print the security label on each page of printed output. The security label
represents a security level and categories as defined to RACF.

The security label that the system prints is determined by the SECLABEL parameter
of the JOB statement. If you do not specify SECLABEL on the JOB statement, the
security level at which the job is executing is printed.

Reference

For additional information on data page labelling, refer to the PSF/MVS System
Programming Guide.

Syntax
DPAGELBL= {YES}
{Y }
{NO }
{N }

Subparameter Definition
YES
Requests the system to print the security label on each page of printed output.
You can also code this parameter as Y.

22-36 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: DPAGELBL
NO
Requests that the system print no security label on each page of printed output.
You can also code this parameter as N.

Defaults
If you do not code the DPAGELBL parameter, an installation default determines if a
security label is printed.

Relationship to Other Parameters

Use the DPAGELBL parameter with the SYSAREA parameter on the OUTPUT JCL
statement and the SECLABEL parameter on the JOB statement as instructed by
your security administrator.

You can code the DPAGELBL parameter with any other OUTPUT JCL statement
parameters.

Example of the DPAGELBL Parameter

//JOBA JOB 1,’JIM WOOSTER’,SECLABEL=CONF
.
.
//VPRPT OUTPUT DPAGELBL=YES,FORMS=VP20

In this example, the security label CONF (specified on the SECLABEL parameter of
the JOB statement) is printed on each page of printed output. The sysout data set
is printed on forms named VP20.

DUPLEX Parameter
Parameter Type

Keyword, optional

Purpose

Use DUPLEX to specify whether or not printing is to be done on both sides of the
sheet. This overrides what is specified in the FORMDEF in use.

Syntax
DUPLEX={NO }
{N }
{NORMAL}
{TUMBLE}

Subparameter Definition
NO or N
Specifies to print on one side only.
NORMAL
Specifies that the physical page is rotated about the Y axis. For most page
orientations (including the default orientation), the Y axis is the long edge of the
sheet. This allows for binding on the long side of the sheet.

Chapter 22. OUTPUT JCL Statement 22-37

OUTPUT JCL: DUPLEX
TUMBLE
Specifies that the physical page is rotated about the X axis. For most page
orientations (including the default orientation), the X axis is the short edge of
the sheet. This allows for binding on the short side of the sheet.

Relationship to Other Keywords on This Statement

The DUPLEX keyword overrides the duplex option from the forms definition, which
may be specified by the FORMDEF keyword.

Example of the DUPLEX Parameter

//OUTDUP OUTPUT DUPLEX=NO

In this example, the output is to be printed in simplex (printed on only one side of
the paper).

FCB Parameter
Parameter Type

Keyword, optional

Purpose

Use the FCB parameter to specify:

v The forms control buffer (FCB) image JES is to use to guide printing of the
sysout data set by a 1403 Printer, 3211 Printer, 3203 Printer Model 5, 3800
Printing Subsystem, 4245 Printer, or 4248 Printer, or by a printer supported by
systems network architecture (SNA) remote job entry (RJE).
v The page definition member to be used if the data set is line-mode and is printed
on a page-mode printer and you do not code PAGEDEF.
v The carriage control tape JES is to use to control printing of the sysout data set
by a 1403 Printer or by a printer supported by SNA RJE.
v The data-protection image JES is to use to control output by a 3525 Card Punch.

The FCB image specifies how many lines are to be printed per inch and the length
of the form. JES loads the image into the printer’s forms control buffer. The FCB
image is stored in SYS1.IMAGELIB. IBM provides three standard FCB images:
v STD1, which specifies 6 lines per inch on an 8.5-inch-long form. (3211 and
3203-5 only)
v STD2, which specifies 6 lines per inch on an 11-inch-long form. (3211 and
3203-5 only)
v STD3, which specifies 8 lines per inch on an 11-inch form for a dump. (3800
only)

References

For more information on the forms control buffer, see z/OS DFSMSdfp Advanced
Services or 3800 Programmer’s Guide.

Syntax
FCB= {fcb-name}
{STD }

22-38 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: FCB

v Code the fcb-name as STD1 or STD2 only to request the IBM-supplied images.
v Code the fcb-name as STD3 only for a high-density dump.

Subparameter Definition
fcb-name
Identifies the FCB image. The name is 1 through 4 alphanumeric or national ($,
#, @) characters and is the last characters of a SYS1.IMAGELIB member
name:
v FCB2xxxx member, for a 3211, a 3203 Model 5, or a printer supported by
SNA.
v FCB3xxxx member, for a 3800.
v FCB4xxxx member, for a 4248.

Identifies a PAGEDEF member in the PSF libraries.

STD
Indicates the standard FCB. JES3 uses the standard FCB specified at JES3
initialization.

Note: STD is supported only on JES3 systems.

Defaults
If you do not code the FCB parameter for a data set on an impact printer, the
system checks the FCB image that was last loaded in the printer; if it is a default
image, as indicated by its first byte, JES uses it. If it is not a default image, JES
loads the FCB image that is the installation default specified at JES initialization.

The FCB parameter names a default page definition to be used if the data set is
line-mode, is printed on a page-mode printer and PAGEDEF is not coded on the
OUTPUT or DD statements.

Overrides
An FCB parameter on the sysout DD statement overrides the OUTPUT JCL FCB
parameter. If the data set is line-mode and is printed on a page-mode printer and
you code PAGEDEF on the DD statement or OUTPUT statement, then PAGEDEF
overrides FCB.

Relationship to Other Parameters

The FCB parameter is mutually exclusive with the FRID subparameter of the DD
statement DCB parameter.

Requesting a High-Density Dump

You can request a high-density dump on the 3800 through two parameters on the
DD statement for the dump data set or on an OUTPUT JCL statement referenced
by the dump DD statement:
v FCB=STD3. This parameter produces dump output at 8 lines per inch.
v CHARS=DUMP. This parameter produces 204-character print lines.

You can code one or both of these parameters. You can place both on the same
statement or one on each statement.

Chapter 22. OUTPUT JCL Statement 22-39

OUTPUT JCL: FCB
Example of the FCB Parameter
//OUTDS1 OUTPUT FCB=AA33

In this example, JES will print the sysout data set using the FCB image named
AA33.

FLASH Parameter
Parameter Type

Keyword, optional

Purpose

Use the FLASH parameter to identify the forms overlay to be used in printing the
sysout data set on a 3800 Printing Subsystem and, optionally, to specify the
number of copies on which to print the forms overlay.

Note: FLASH applies only for a data set printed on a 3800.

Reference

For information on forms overlays, see the Forms Design Reference Guide for the
3800.

Syntax
FLASH= {overlay-name }
{(overlay-name[,count])}
{(,count) }
{NONE }
{STD }
The count subparameter is optional. If you omit it, you can omit the parentheses.

Subparameter Definition
overlay-name
Identifies the forms overlay frame that the operator is to insert into the printer
before printing begins. The name is 1 through 4 alphanumeric or national ($, #,
@) characters.
count
Specifies the number, 0 through 255, of copies that JES is to flash with the
overlay, beginning with the first copy printed. Code a count of 0 to flash no
copies.
NONE
Suppresses flashing for this sysout data set.
If FLASH=NONE is on an OUTPUT JCL statement in a job to be executed at a
remote node, JES3 sets the overlay-name to zero before sending the job to the
node.
STD
Indicates the standard forms flash overlay. JES3 uses the standard forms
overlay specified at JES3 initialization.

22-40 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: FLASH
Note: STD is supported only on JES3 systems.

Defaults
If you do not code a FLASH parameter and an installation default was not specified
at JES2 or JES3 initialization, forms are not flashed.

If you specify an overlay-name without specifying a count, all copies are flashed.
That is, the default for count is 255.

Overrides
A FLASH parameter on the sysout DD statement overrides the OUTPUT JCL
FLASH parameter.

Relationship to Other Parameters

If the OUTPUT JCL or the sysout DD statement also contains a COPIES parameter,
JES prints with the forms overlay the number of copies specified in one of the
following:
v COPIES=nnn, if the FLASH count is larger than nnn. For example, if COPIES=10
and FLASH=(LTHD,12) JES prints 10 copies, all with the forms overlay.
v The sum of the group-values specified in the COPIES parameter, if the FLASH
count is larger than the sum. For example, if COPIES=(,(2,3,4)) and
FLASH=(LTHD,12) JES prints nine copies in groups, all with the forms overlay.
v The count subparameter in the FLASH parameter, if the FLASH count is smaller
than nnn or the sum from the COPIES parameter. For example, if COPIES=10
and FLASH=(LTHD,7) JES prints seven copies with the forms overlay and three
copies without.

Verification of Forms Overlay Frame

Before printing starts, the system requests the operator to load the specified forms
overlay frame in the printer. A frame must be loaded but the system cannot verify
that it is the correct frame.

Printing without Flashing

To print without flashing, specify one of the following:
v FLASH=NONE on the DD or OUTPUT JCL statement.
v Omit the FLASH parameter on all of the statements for the data set and on all
JES initialization statements.
v FLASH=(,0) on the OUTPUT JCL statement.

Example of the FLASH Parameter

//OUTDS1 OUTPUT COPIES=16,FLASH=(LTHD,7)

In this example, JES issues a message to the operator requesting that the forms
overlay frame named LTHD be inserted in the printer. Then JES prints the first
seven copies of the sysout data set with the forms overlay and the last nine without.

Chapter 22. OUTPUT JCL Statement 22-41

OUTPUT JCL: FORMDEF

FORMDEF Parameter
Parameter Type

Keyword, optional

Purpose

Use the FORMDEF parameter to identify a library member that contains statements
to tell the Print Services Facility (PSF) how to print the sysout data set on a
page-mode printer (such as the 3800 Printing Subsystem Model 3). The statements
can specify the following:
v Overlay forms to be used during printing.
v Location on the page where overlays are to be placed.
v Suppressions that can be activated for specified page formats.

The member must be in the library named in the cataloged procedure that was
used to initialize the PSF, or in a library specified in the USERLIB parameter.

Note: FORMDEF applies only for data sets printed on a page-mode printer (such
as a 3800 Model 3).

References

For more information, see PSF/MVS Application Programming Guide and 3800
Programmer’s Guide.

Syntax
FORMDEF=membername

Subparameter Definition
membername
Specifies the name of a library member. membername is 1 through 6
alphanumeric or national ($, #, @) characters; the first two characters are
pre-defined by the system.

Overrides
The library member specified by the OUTPUT JCL FORMDEF parameter can
contain:
v Statements that override the installation’s FORMDEF defaults in the PSF
cataloged procedure.
v A FORMDEF statement with a COPYGROUP parameter. The COPYGROUP
parameter overrides any group-value subparameters on the OUTPUT JCL
COPIES parameter or the sysout DD COPIES parameter.

Note: The FORMDEF statement in the library member does not override a
sysout DD or OUTPUT JCL COPIES=nnn parameter.

Example of the FORMDEF Parameter

//PRINT3 OUTPUT FORMDEF=JJPRT

22-42 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: FORMDEF
In this example, PSF is to print the sysout data set on a 3800 Model 3 according to
the parameters in the library member JJPRT.

FORMLEN Parameter
Parameter Type

Keyword, optional

Purpose

A PSF/MVS user can use the FORMLEN parameter to set the length of pages for
print without reconfiguring the printer.

Syntax
FORMLEN=nn[.mmm]{IN|CM}

Subparameter Definition
nn Required. A one or two digit number, which can be zero.
.mmm
Optional. A decimal point (period) followed by up to three digits.
{IN|CM}
Required. The unit the decimal digits represent. Code IN for inches or CM for
centimeters.

Relationship to Other Control Statements

FORMLEN is coordinated with FORMDEF (which may also be specified on the
OUTPUT or PSF PRINTDEV statements).

Examples of the FORMLEN Parameter

Example 1
//OUTFORML OUTPUT FORMLEN=12.345CM

In this example the PSF/MVS user has requested that a specification of paper
length 12.345 centimeters be sent to the printer.

Example 2
//OUTFORML OUTPUT FORMLEN=2IN

In this example the PSF/MVS user has requested that a specification of 2-inch
paper length be sent to the printer.

Note: The decimal point and fractional portion are optional.

Example 3
//OUTFORML OUTPUT FORMLEN=0.1IN

In this example the PSF/MVS user has requested that a specification of 0.1-inch
paper length be sent to the printer.

Chapter 22. OUTPUT JCL Statement 22-43

OUTPUT JCL: FORMLEN
Note: You must specify at least one digit to the left of the decimal point.

FORMS Parameter
Parameter Type

Keyword, optional

Purpose

Use the FORMS parameter to identify the forms on which the sysout data set is to
be printed or punched.

Syntax
FORMS= {form-name}
{STD }

Subparameter Definition
form-name
Identifies the print or punch forms. form-name is 1 through 8 alphanumeric or
national ($, #, @) characters.
STD
Indicates that JES3 is to use the standard form specified at JES3 initialization.

Note: STD is supported only on JES3 systems.

Defaults
If you do not code a form-name subparameter, JES uses an installation default
specified at initialization.

Overrides
The form-name subparameter of the SYSOUT parameter on the sysout DD
statement overrides the OUTPUT JCL FORMS parameter. Note that the SYSOUT
form-name subparameter can be only four characters maximum while both the
OUTPUT JCL FORMS form-name and the JES initialization default form names can
be eight characters maximum.

Example of the FORMS Parameter

//OUTDS1 OUTPUT FORMS=ACCT4010

In this example, the sysout data set will be printed on forms named ACCT4010.

FSSDATA Parameter
Parameter Type

Keyword, optional

Purpose

22-44 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: FSSDATA
Use the FSSDATA parameter for the intended purpose of each functional
subsystem that documents this parameter.

Syntax
FSSDATA=value

Subparameter Definition
value
Required. A subsystem-defined parameter (maximum = 127) to pass from a
spooling product to a functional subsystem application (FSA) or other despooler.
The following considerations apply when you supply the value a functional
subsystem requires:
Characters Valid When Enclosed in Apostrophes
v You may include any EBCDIC text characters in an FSSDATA parameter
value if you enclose the value in apostrophes. See Character Set in topic
4.2 for a list and description of valid EBCDIC text characters.
v You must enclose the value in apostrophes if it contains a blank.
v The system preserves trailing blanks you include as part of a value you
enclose in apostrophes. For example, if you specify
FSSDATA=’SUNDAY ’

the parameter value for the FSSDATA keyword is eight (8) characters,
and a functional subsystem may deem it to be different from
FSSDATA=’SUNDAY’

(6 characters) or
FSSDATA=’SUNDAY ’

(7 characters).
v To code an apostrophe as part of the value, code two apostrophes, as
well as enclosing the entire value in single apostrophes. Example:
//OUT1 OUTPUT FSSDATA=’New Year’’s Day’
Characters Not Requiring Enclosing Apostrophes
Apostrophes are optional when ″value″ consists only of:
v Uppercase alphanumeric characters
v National characters @, $, and #
v Period (.)
v Asterisk (*). However, an asterisk followed by a period indicates a
referral; *. is NOT allowed as the first two characters of the value
v Ampersand (&). An ampersand referring to a symbolic is substituted. Two
consecutive ampersands are not substituted; they will result in a single
ampersand as part of the value
v Plus sign (+)
v Hyphen(-)
v Slash (/)

Chapter 22. OUTPUT JCL Statement 22-45

OUTPUT JCL: FSSDATA
Characters You May Not Enclose in Aphstrophes
Do not enclosed symbolic parameters within apostrophes. The system will
not resolve them.

Defaults
None.

Overrides
None.

Relationship to Other Keywords on this Statement

None.

Relationship to Other System Functions

None.

Examples of the FSSDATA Parameter

A functional subsystem defines its intended content for the FSSDATA parameter
value. The following are examples of the allowable syntax for the FSSDATA
parameter. Parentheses enclose the resulting values (or portions thereof) to help
distinguish them.

Example 1
//OUTDS1 OUTPUT FSSDATA=FSSVALUE

In Example 1 the FSSDATA parameter contains a value (FSSVALUE) that does not
require apostrophes around it. This is because the value contains no blanks and
consists only of characters that are valid without apostrophes.

Example 2
//OUTDS2 OUTPUT FSSDATA=’Subsystem data’

In Example 2 the FSSDATA parameter contains a single value (Subsystem data)

which you must enclose in apostrophes because of the embedded blank.

Example 3
//OUTDS3 OUTPUT FSSDATA=’AOPPT=CFF’

In Example 3 the FSSDATA parameter contains a value (AOPPT=CFF) within

apostrophes. The parameter value consists of a string that a functional subsystem
could use to identify a defined keyword (AOPPT) and its parametric value (CFF).

Example 4
//PROCC PROC PARM1=FSSDATA
//STEPC EXEC PGM=MYPGM
//OUTDS4 OUTPUT FSSDATA=&PARM1

In Example 4 the FSSDATA parameter contains a value whose first character is an

ampersand (&). ″Value″ consists of a string that a functional subsystem could use to
identify a symbolic parameter. The system takes the procedure default for the value
from the PROC statement (FSSDATA).

Example 5

22-46 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: FSSDATA
//PROCD PROC PARM1=FSSDATA
//STEPD EXEC PGM=MYPGM
//OUTDS5 OUTPUT FSSDATA=’&PARM1’

In Example 5 the FSSDATA parameter contains a value enclosed within

apostrophes, where the first character of the value is an ampersand (&). The value
consists of a string that a functional subsystem could use to identify a symbolic
parameter. Because the subsystem-defined parameter is enclosed within
apostrophes, the system does not resolve the &PARM1 symbolic; it leaves the
parameter value unchanged (&PARM1).

GROUPID Parameter
Parameter Type

Keyword, optional, JES2 only

Purpose

Use the GROUPID parameter to specify that the sysout data set belongs to an
output group. The data sets in an output group are processed together in the same
location and time. Data sets to be grouped should have similar characteristics: the
same output class, destination, process mode, and external writer name.

Note: GROUPID is supported only on JES2 systems.

Syntax
GROUPID=output-group

Subparameter Definition
output-group
Specifies the name of an output group. The output-group is 1 through 8
alphanumeric characters and is selected by the programmer to define an output
group for this job. The name is not installation-defined.

Relationship to Other Control Statements

If you code FREE=CLOSE on a sysout DD statement that references an OUTPUT
JCL statement containing a GROUPID parameter, JES2 will not group the data sets
into one output group. Instead, JES2 produces one copy of the sysout data set for
each OUTPUT JCL statement that the DD statement references.

Examples of the GROUPID Parameter

Example 1
//EXMP5 JOB ACCT1984,MAEBIRD,MSGCLASS=A
//OUTRPT OUTPUT GROUPID=RPTGP,DEFAULT=YES,DEST=TDC
//STEP1 EXEC PGM=RPTWRIT
//SYSIN DD *
.
.
.
/*
//RPTDLY DD SYSOUT=C
//RPTWK DD SYSOUT=C

Chapter 22. OUTPUT JCL Statement 22-47

OUTPUT JCL: GROUPID
In this example, the DD statements RPTDLY and RPTWK implicitly reference the
default OUTPUT JCL statement OUTRPT. JES2 creates two output groups:
1. Group RPTGP is created because of the GROUPID parameter in the OUTPUT
JCL statement. It contains the two reports from the sysout DD statements
RPTDLY and RPTWK and is printed at the destination TDC. The programmer
named this group RPTGP.
2. The other group is named by JES2. It contains the system-managed data set
for the job’s messages.

Example 2
//EXAMP JOB MSGCLASS=A
//JOBOUT OUTPUT GROUPID=SUMM,DEST=HQS,CHARS=GT10
//STEP1 EXEC PGM=RWRITE
//OUT1 OUTPUT FORMS=STD,CHARS=GS10,DEST=LOCAL
//RPT1 DD SYSOUT=A,OUTPUT=(*.OUT1,*.JOBOUT)
//STEP2 EXEC PGM=SWRITE
//OUT2 OUTPUT FORMS=111,CHARS=GB10,DEST=LOCAL
//RPT2 DD SYSOUT=B,OUTPUT=(*.OUT2,*.JOBOUT)

This job causes JES2 to produce five sets of output:

v 1.1.1, containing the system-managed data sets. This set is specified through the
JOB statement MSGCLASS parameter.
v SUMM.1.1, containing a copy of the data set defined by DD statement RPT1.
This set is specified through the second OUTPUT subparameter: *.JOBOUT. It is
for output class A.
v SUMM.2.1, containing a copy of the data set defined by DD statement RPT2.
This set is specified through the second OUTPUT subparameter: *.JOBOUT.
Because it is for output class B, it is in a separate subgroup from the SUMM.1.1
subgroup.
v 4.1.1, containing a copy of the data set defined by DD statement RPT1. This set
is specified through the first OUTPUT subparameter: *.OUT1.
v 5.1.1, containing a copy of the data set defined by DD statement RPT2. This set
is specified through the first OUTPUT subparameter: *.OUT2.

INDEX Parameter
Parameter Type

Keyword, optional, JES2 only

Purpose

Use the INDEX parameter to set the left margin for output on a 3211 Printer with
the indexing feature. The width of the print line is reduced by the INDEX parameter
value.

Note: INDEX is supported only on JES2 systems and only for output printed on a
3211 with the indexing feature. JES2 ignores the INDEX parameter if the
printer is not a 3211 with the indexing feature.

Syntax
INDEX=nn

22-48 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: INDEX
Subparameter Definition
nn
Specifies how many print positions the left margin on the 3211 output is to be
indented. nn is a decimal number from 1 through 31. n=1 indicates flush-left;
n=2 through n=31 indent the print line by n-1 positions.

Defaults
The default is 1, which indicates flush left. Thus, if you do not code an INDEX or
LINDEX parameter, JES2 prints full-width lines.

Relationship to Other Parameters

INDEX and LINDEX are mutually exclusive; if you code both, JES2 uses the last
one encountered. Note that you cannot index both the left and right margins.

Example of the INDEX Parameter

//OUT17 OUTPUT INDEX=6

In this example, because the printed report is to be stapled, extra space is needed
on the left. Assuming the data set is printed on a 3211 with the indexing feature, all
lines are indented 5 print positions from the left page margin.

INTRAY Parameter
Parameter Type

Keyword, optional

Purpose

Use INTRAY to specify the paper source. This overrides what is specified in the
FORMDEF in use.

Syntax
INTRAY=nnn

Subparameter Definition
nnn
Specifies the paper source, where nnn is a number from 1 to 255. To determine
what value to specify, see the documentation for your printer.

Relationship to Other Keywords on This Statement

If OUTBIN is specified, the paper from the INTRAY must be compatible with the
output bin.

Example of the INTRAY Parameter

//OUTTRAY OUTPUT INTRAY=2

In this example, 2 is the paper source.

Chapter 22. OUTPUT JCL Statement 22-49

OUTPUT JCL: JESDS

JESDS Parameter
Parameter Type

Keyword, optional

Purpose

Use the JESDS parameter to process the job’s system-managed data sets
according to the parameters on this OUTPUT JCL statement. The system-managed
data sets consist of:
v The job log, which is a record of job-related information for the programmer.
Printing of the job log is controlled by two JOB statement parameters: the
MSGLEVEL parameter controls what is printed and the MSGCLASS parameter
controls the system output class.
v The job’s hard-copy log, which is a record of all message traffic for the job to and
from the operator console.
v System messages for the job.

Note: In a JES3 environment, a job can complete processing before all of its
messages have been written to the job log. When this occurs, the job’s
output is incomplete. For this reason, do not use the contents of the job log
as an automation or as a programming interface.

References

For more information on the job log, see z/OS MVS System Commands.

Syntax
JESDS= {ALL}
{JCL}
{LOG}
{MSG}

Subparameter Definition
ALL
Indicates that this OUTPUT JCL statement applies to all of the job’s
system-managed data sets.
LOG
Indicates that this OUTPUT JCL statement applies only to the JESMSGLG data
set, which contains the JES and operator messages for this job.
JCL
Indicates that this OUTPUT JCL statement applies only to the JESJCL data set,
which contains the JCL statements for this job.
MSG
Indicates that this OUTPUT JCL statement applies only to the JESYSMSG data
set, which contains any JCL error messages and any system messages for this
job.

22-50 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: JESDS
Overrides
The NOLOG parameter on a JES2 /*JOBPARM statement overrides the OUTPUT
JCL JESDS=ALL parameter.

If an OUTPUT JCL statement contains both JESDS and CLASS parameters, the
CLASS parameter will override the MSGCLASS parameter on the JOB statement
for the specified JES data sets.

Location in the JCL

Place an OUTPUT JCL statement containing JESDS before the first EXEC
statement of the job. An OUTPUT JCL statement containing JESDS placed after an
EXEC statement is a JCL error.

You can place more than one OUTPUT JCL statement containing JESDS before the
first EXEC statement. JES creates a copy of the job’s system data sets for each.

Destination for the System Data Sets

If you want the job’s system data sets processed at a particular destination, code a
DEST parameter on the OUTPUT JCL statement containing JESDS. Otherwise,
JES routes the system data sets to a local device.

JES2 Processing with JESDS

JES2 processes OUTPUT JCL statements for system-managed data sets (JESDS
parameter) only if a job starts execution.

System-managed data sets are not processed for the following jobs because the
jobs do not start execution:
v Jobs that specify a TYPRUN value on the JOB statement that prevents
execution, such as COPY or SCAN.
v Jobs that do not execute because of a JCL error, an error in a JES2 control
statement, or a system failure in JES2 input processing.

JES3 Processing with JESDS

System-managed data sets are not processed by JES3 for the following jobs
because the jobs do not complete execution:
v Jobs that specify a TYPRUN value on the JOB statement that prevents
execution, such as SCAN.
v Jobs that do not execute because of a JCL error.

Example of the JESDS Parameter

//EXMP JOB MSGCLASS=A
//OUT1 OUTPUT JESDS=ALL
//OUT2 OUTPUT JESDS=ALL,DEST=AUSTIN
.
.
.

In this example, JES produces two copies of the system-managed data sets: one
copy for OUTPUT JCL statement OUT1 and one copy for OUTPUT JCL statement
OUT2. The copy for statement OUT2 is sent to AUSTIN.

Chapter 22. OUTPUT JCL Statement 22-51

OUTPUT JCL: LINDEX

LINDEX Parameter
Parameter Type

Keyword, optional, JES2 only

Purpose

Use the LINDEX parameter to set the right margin for output on a 3211 Printer with
the indexing feature. The width of the print line is reduced by the LINDEX
parameter value.

Note: LINDEX is supported only on JES2 systems and only for output printed on a
3211 with the indexing feature. JES2 ignores the LINDEX parameter if the
printer is not a 3211 with the indexing feature.

Syntax
LINDEX=nn

Subparameter Definition
nn
Specifies how many print positions the right margin on the 3211 output is to be
moved in from the full page width. nn is a decimal number from 1 through 31.
n=1 indicates flush-right; n=2 through n=31 move the right margin over by n-1
positions.

Defaults
The default is 1, which indicates flush right. Thus, if you do not code an INDEX or
LINDEX parameter, JES2 prints full-width lines.

Relationship to Other Parameters

INDEX and LINDEX are mutually exclusive; if you code both, JES2 uses the last
one encountered. Note that you cannot index both the left and right margins.

Example of the LINDEX Parameter

//OUT18 OUTPUT LINDEX=21

In this example, the author of the report wanted extra space on the right side of the
paper for notes. Assuming the data set is printed on a 3211 with the indexing
feature, all lines are ended 20 print positions from the right page margin.

LINECT Parameter
Parameter Type

Keyword, optional, JES2 only

Purpose

Use the LINECT parameter to specify the maximum number of lines JES2 is to print
on each output page.

22-52 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: LINECT
Note: LINECT is supported only on JES2 systems.

Syntax
LINECT=nnn

Subparameter Definition
nnn
Specifies the maximum number of lines JES2 is to print on each page. nnn is a
number from 0 through 255.
Specify LINECT=0 to keep JES2 from starting a new page when the number of
lines exceeds the JES2 initialization parameter.

Defaults
If you do not code the LINECT parameter, JES2 obtains the value from one of the
following sources, in order:
1. The linect field of the accounting information parameter on the JOB statement.
2. The installation default specified at JES2 initialization.

Example of the LINECT Parameter

//PRNTDS OUTPUT LINECT=45

In this example, JES2 will start a new page after every 45 lines.

MODIFY Parameter
Parameter Type

Keyword, optional

Purpose

Use the MODIFY parameter to specify a copy-modification module that tells JES
how to print the sysout data set on a 3800 Printing Subsystem. The module can
specify the following:
v Legends.
v Column headings.
v Where and on which copies to print the data.

The module is defined and stored in SYS1.IMAGELIB using the IEBIMAGE utility
program.

Note: MODIFY applies only for the 3800 Printing Subsystem Model 1 and 2 and
the 3800 Printing Subsystem Models 3, 6 and 8 in compatibility mode. For
page-mode printers (such as the 3800 Model 3), use the FORMDEF and
PAGEDEF parameters to obtain the same functions.

References

For more information on the copy modification module and the IEBIMAGE utility
program, see z/OS DFSMSdfp Utilities.

Chapter 22. OUTPUT JCL Statement 22-53

OUTPUT JCL: MODIFY
Syntax
MODIFY= {module-name }
{([module-name][,trc])}

v You can omit the module-name, thereby obtaining the initialization default. For example,
MODIFY=(,2).
v The trc subparameter is optional. If you omit it, you can omit the parentheses.

Subparameter Definition
module-name
Identifies a copy-modification module in SYS1.IMAGELIB. The module-name is
1 through 4 alphanumeric or national ($, #, @) characters.
trc
Identifies which character-arrangement table named in the CHARS parameter is
to be used. This table reference character is 0 for the first table-name
specified, 1 for the second, 2 for the third, or 3 for the fourth. The CHARS
parameter used is on the following, in override order:
1. The DD statement.
2. This OUTPUT JCL statement.
3. A statement in the library member specified on the OUTPUT JCL PAGEDEF
parameter.
4. A statement in the SYS1.IMAGELIB member obtained by default.
5. A JES3 initialization statement.

Defaults
If you do not code module-name in the MODIFY parameter, JES3 uses an
installation default specified at initialization. JES2 provides no installation default at
initialization.

If you do not specify trc, the default is 0. If the trc value is greater than the number
of table-names in the CHARS parameter, JES2 uses the first character-arrangement
table named in the CHARS parameter and JES3 uses the last
character-arrangement table named in the CHARS parameter.

Overrides
A MODIFY parameter on the sysout DD statement overrides the OUTPUT JCL
MODIFY parameter.

Relationship to Other Parameters

The second character of each logical record can be a TRC code, so that each
record can be printed in a different font. This way of specifying fonts is indicated by
the OUTPUT JCL TRC parameter.

Example of the MODIFY Parameter

//OUTDS1 OUTPUT CHARS=(GT12,GB12,GI12),MODIFY=(MODA,2)

In this example, JES loads the MODA module in SYS1.IMAGELIB into the 3800
and uses GI12, Gothic Italic 12-pitch font, which is the third table name specified in
the CHARS parameter.

22-54 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: NAME

NAME Parameter
Parameter Type

Keyword, optional

Purpose

Use the NAME parameter to print a preferred name on the separator pages of the
output for a sysout data set. The preferred name is the name associated with the
output. An installation can use the preferred name to assist in sysout distribution.

Syntax
NAME= {’preferred name’}
{preferred-name }
Valid Characters in Enclosing Apostrophes:
v A preferred name enclosed in apostrophes can contain any EBCDIC text character.
v When the value for preferred name contains a blank, enclose the value in apostrophes.
v To code an apostrophe in the preferred name, code 2 apostrophes, and enclose the
preferred name in single apostrophes. For example:
//OUTDS OUTPUT NAME=’O’’ROURKE’
v Each value may optionally be enclosed in apostrophes.

Valid Characters Without Enclosing Apostrophes: When the value for preferred name is
not enclosed in apostrophes, the following characters are valid:
v Alphanumeric and national (@, $, #) characters
v Period (.) and asterisk (*); however, an asterisk followed by a period indicates a referral
and is not allowed as the start (first and second characters) of the value.
v Ampersand (&). An ampersand that refers to a symbolic is substituted. Two consecutive
ampersands are not substituted, but they will result in a single ampersand as part of the
value.
v Plus sign (+)
v Hyphen (-)
v Slash (/)

Symbolic Parameters: Do not enclose symbolic parameters in apostrophes. Symbolic

parameters within apostrophes are not resolved for this keyword.

Subparameter Definition
preferred name
Specifies the preferred name that is associated with the sysout. The preferred
name is 1 - 60 EBCDIC text characters. See “Character Sets” on page 4-3 for a
description of EBCDIC text characters.

Defaults
v In an APPC scheduling environment:
In both JES2 and JES3 systems, if you do not code the NAME parameter on the
OUTPUT JCL statement, the system uses the value defined in the transaction
program (TP) user’s RACF profile when:
– The user submitting the TP profile has a RACF profile defined for him, and
– The transaction program profile includes TAILOR_SYSOUT(YES).

Chapter 22. OUTPUT JCL Statement 22-55

OUTPUT JCL: NAME
Otherwise, the system uses the value defined on the transaction initiator’s job
statement.
v In a non-APPC scheduling environment:
In a JES2 system, if you do not code the NAME parameter on the OUTPUT JCL
statement, the system uses the name defined on the job statement.
In a JES3 system, there is no default for the NAME parameter on the OUTPUT
JCL statement.

Overrides
v In an APPC scheduling environment:
In both JES2 and JES3 systems, the NAME parameter on the OUTPUT JCL
statement overrides the name defined in the RACF profile. The name in the
RACF profile overrides the name defined in the transaction initiator’s JOB
statement.
v In a non-APPC scheduling environment:
In both JES2 and JES3 systems, the NAME parameter on the OUTPUT JCL
statement overrides the name defined on the JOB statement.

Example of the NAME Parameter

//OUTDS7 OUTPUT NAME=’R. ROPER’

In this example, the name R. ROPER will be printed on the line reserved for NAME
on separator pages of any sysout data set that references OUTDS7.

NOTIFY Parameter
Parameter Type

Keyword, optional - Use this parameter only for PSF printers

Purpose

Use the NOTIFY parameter to have PSF issue a print completion message to up to
four users. The message identifies the output that has completed printing, and
indicates whether the printing was successful. This parameter is effective for PSF
devices and any FSS products that support the NOTIFY keyword; it has no effect
for JES-mode devices. The print completion message is issued:
v on a JES2 system: when printing for all the sysout data sets for an output group
has completed. An output group consists of the sysout data sets printed between
the output header page and the output trailer page of a job.
v on a JES3 system: when the sysout data sets for the same printer and the same
job have been printed.

Syntax
NOTIFY= [node.]userid
([node1.]userid1,[node2.]userid2,...[node4.]userid4)

v You can omit the parentheses if you code only one destination.
v For any destination, you can omit the node name.

22-56 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: NOTIFY
Subparameter Definitions
[node]userid
Specifies the node name and userid of a recipient of the print completion
message.

Defaults
If you do not code the NOTIFY parameter, the system will not issue a print
completion message. If you do not specify node, it will default to the node where
the job was submitted.

Examples of the NOTIFY Parameter

Example 1
//OUT1 OUTPUT NOTIFY=BLDVM2.RICH1

In this example, the system sends a print completion message to RICH1 at

BLDVM2.

Example 2
//OUT1 OUTPUT NOTIFY=(BLDVM2.RICH1,CARTER)

In this example, the system sends a print completion message to RICH1 at

BLDVM2, and to the userid CARTER at the node where the job was submitted.

OFFSETXB Parameter
Parameter Type

Keyword, optional

Purpose

Use OFFSETXB to specify the offset in the X direction from the page origin (or
partition origin for N_UP) for the back side of each page of output. This overrides
what is specified in the FORMDEF in use. For more information on page offsets
see the page ″Page Position″ in the PSF/MVS Application Programming Guide.

Syntax
OFFSETXB=mmmm[.nnn]{IN }
{CM }
{MM }
{PELS }
{POINTS}

Subparameter Definition
mmmm[.nnn]
Specifies a value, which may be one (m), two (mm), three (mmm), or four
(mmmm) digits (and which may be zero), and which optionally may be followed
by a decimal point (a period) and up to three (nnn) digits.
IN | CM | MM | PELS | POINTS
A mandatory unit that follows the value. The unit can be inches (IN),

Chapter 22. OUTPUT JCL Statement 22-57

OUTPUT JCL: OFFSETXB
centimeters (CM), millimeters (MM), pels, or points. If you specify the unit as
pels or points you must specify the value as a whole number with no decimal
point.

Relationship to Other Keywords on This Statement

The OFFSETXB parameter is used in conjunction with the OFFSETXF, OFFSETYB,
and OFFSETYF parameter to define the page origin.

Example of the OFFSETXB Parameter

//OUTSET OUTPUT OFFSETXB=10.5MM

In this example, the page is to be offset 10.5 millimeters in the X direction from the
page origin on the back of each sheet.

OFFSETXF Parameter
Parameter Type

Keyword, optional

Purpose

Similar to OFFSETXB (with the same units, values, and restrictions), OFFSETXF is
used to specify the offset in the X direction from the page origin (or partition origin
for N_UP) for the front side of each page of output.

OFFSETYB Parameter
Parameter Type

Keyword, optional

Purpose

Similar to OFFSETXB (with the same units, values, and restrictions), OFFSETYB is
used to specify the offset in the Y direction from the page origin (or partition origin
for N_UP) for the back side of each page of output.

OFFSETYF Parameter
Parameter Type

Keyword, optional

Purpose

Similar to OFFSETXB (with the same units, values, and restrictions), OFFSETYF is
used to specify the offset in the Y direction from the page origin (or partition origin
for N_UP) for the front side of each page of output.

22-58 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: OUTBIN

OUTBIN Parameter
Parameter Type

Keyword, optional

Purpose

The OUTBIN keyword specifies the printer output bin identifier to be used for the
sysout data set. See PSF/MVS Application Programming Guide for more
information on multiple media destinations and OUTBIN processing.

Syntax
OUTBIN = nnnnn

Subparameter Definition
nnnnn
Species the ID of the printer output bin where the data set is to be sent. nnnnn
is 1 through 5 decimal digits from 1 to 65535.

Defaults
If the OUTBIN keyword is not specified, PSF (Print Services Facility) will stack the
output in the printer default output bin. If OUTBIN specifies a value that is not one
of the supported identifiers, PSF will stack the output in the printer default output
bin and issue a message indicating that the requested bin is not available.

Overrides
The OUTBIN value can be overridden via the JES3 *MODIFY command.

Relationship to Other System Functions

JES3 printers use OUTBIN as a grouping attribute and will print header and trailer
pages around each group of data sets with unique OUTBIN specifications.

Example of the OUTBIN Parameter

//OUT1 OUTPUT DATACK=UNBLOCK,OUTBIN=2,TRC=N0

In this example, the user has specified an output bin id of ’2’.

OUTDISP Parameter
Parameter Type

Keyword, optional

Purpose

In a JES2 system, use the OUTDISP parameter to indicate the disposition of a

sysout data set. You can code different dispositions based on whether the job
completes successfully.

Considerations for an APPC Scheduling Environment

Chapter 22. OUTPUT JCL Statement 22-59

OUTPUT JCL: OUTDISP
In an APPC scheduling environment, sysout data sets are treated as spin data sets.
The system will process only the normal output disposition. If you code an abnormal
output disposition, the system will check it for syntax and then ignore it.

If the automatic restart manager (ARM) restarts a job, JES discards all non-spin
sysout data sets created during the previous execution. (You can avoid losing that
output by adding SPIN=UNALLOC to the DD statement for the SYSOUT data set.)

Syntax
{OUTDISP=(normal-output-disposition,abnormal-output-disposition)}

OUTDISP= ([WRITE] [,WRITE])

([HOLD ] [,HOLD ])
([KEEP ] [,KEEP ])
([LEAVE] [,LEAVE])
([PURGE] [,PURGE])

v If you code only the normal-output-disposition, you can omit the parentheses.
v If you code only the abnormal-output-disposition, enclose the disposition in parentheses
and precede it with a comma. For example:
//OUTDS OUTPUT OUTDISP=(,PURGE)

Subparameter Definitions
WRITE
Indicates that the system is to print the sysout data set. After printing the data
set, the system purges it.
Unless it is held by the system or operator, a sysout data set with the
disposition WRITE will always print.
HOLD
Indicates that the system is to hold the sysout data set until the user or operator
releases it. Releasing the sysout data set changes its disposition to WRITE.
If HOLD output is not released, the system holds it until the user or operator
purges it.
NJE Note: In an NJE environment, the system does not hold the data set until
it reaches its ultimate destination node.
KEEP
Indicates that the system is to print the sysout data set. After printing the data
set, the system changes its disposition to LEAVE.
LEAVE
Indicates that after the user or operator releases the sysout data set, the
disposition of the data set changes to KEEP.
If LEAVE output is not released, the system holds it until the user or operator
purges it.
PURGE
Indicates that the system is to delete the sysout data set without printing it.

22-60 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: OUTDISP
Defaults
If you do not specify OUTDISP, the system uses the installation defaults for normal
and abnormal disposition for the sysout class of the data set.

If you do not specify an abnormal output disposition, the system uses the normal
disposition that you specified.

If you specify an abnormal disposition but do not specify a normal disposition, the
normal disposition defaults to WRITE.

Overrides
The DD statement HOLD=YES parameter overrides the OUTDISP parameter.

Relationship to Other Control Statements

A data set defined by a sysout DD statement that contains a DSID parameter is
always held. The system ignores the OUTDISP parameter on an OUTPUT JCL
statement that is referenced by such a DD statement.

Examples of the OUTDISP parameter

Example 1
//OUTDS6 OUTPUT OUTDISP=(KEEP,PURGE)

When the job completes successfully, the disposition of the data set is KEEP. After
the sysout is printed, the data set disposition changes to LEAVE, and the sysout
data set is held until released by the user or operator.

If the job does not complete normally, the system purges the data set without any
post-execution processing.

Example 2
//OUTNORM OUTPUT OUTDISP=(WRITE,PURGE),DEST=ROOM111
//OUTBAD OUTPUT OUTDISP=(PURGE,HOLD),NAME=’D JONES’
//DD5 DD SYSOUT=A,OUTPUT=(*.OUTNORM,*.OUTBAD)

If the job completes successfully, the output for DD DD5 is to be sent to the
destination ROOM111. If the job does not complete successfully, the output is to be
held for a programmer named D JONES. D JONES can view the output on the
screen, and then purge it or release it to be printed if further diagnosis is required.

There are two OUTPUT statements, OUTNORM and OUTBAD. In any given case,
however, only one of the OUTPUT statements actually produces output. For
successful completion, the WRITE option on the OUTNORM statement specifies
that the output should be printed and sent to ROOM111, and the PURGE option on
OUTBAD specifies that no output is produced for the OUTBAD statement. For
unsuccessful completion, the HOLD option on the OUTBAD statement specifies that
the output should be held for D JONES, and the PURGE option on OUTNORM
specifies that no output is produced for the OUTNORM statement.

Example 3
//SYSOUTK OUTPUT OUTDISP=(WRITE,HOLD)
//REPORT1 DD SYSOUT=K,OUTPUT=*.SYSOUTK

The system processes the data set using OUTPUT statement SYSOUTK.

Chapter 22. OUTPUT JCL Statement 22-61

OUTPUT JCL: OUTDISP
When the job completes successfully, the WRITE option specifies that the system
should print and then purge the output.

When the job does not complete successfully, the HOLD option specifies that the
system should hold the output.

OVERLAYB Parameter
Parameter Type

Keyword, optional

Purpose

Specifies to place the named medium overlay on the back side of each sheet to
print.

Syntax
OVERLAYB=ovlyname

Subparameter Definition
ovlyname
Specifies the medium overlay name, where the overlay name is 1 though 8
alphanumeric or national ($, #, @) characters and the first of those characters
is alphabetic or national.

Relationship to Other Keywords on This Statement

The overlay specified is in addition to any overlays from other sources.

Example of the OVERLAYB Parameter

//OUTOVLY OUTPUT OVERLAYB=MYOVLY

In this example, the overlay named MYOVLY will be included on the back side of
each sheet for this data set.

OVERLAYF Parameter
Parameter Type

Keyword, optional

Purpose

Similar to OVERLAYB, with the same restrictions on the name, OVERLAYF

specifies to place the named medium overlay on the front side of each sheet to
print.

22-62 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: OVFL

OVFL Parameter
Parameter Type

Keyword, optional

Purpose

Use the OVFL parameter to specify whether the printer program (JES3 output
writer) should check for forms overflow (by sensing channel 12 as defined in the
FCB that is used for printing the output).

Note: OVFL is supported only on JES3 systems. Neither JES2 nor Print Services
Facility (PSF) supports OVFL.

Syntax
OVFL = [ON|OFF]

Subparameter Definition
ON
Indicates that the printer program should eject (skip to channel 1) whenever the
end-of-forms indicator (channel 12) is sensed.
OFF
Indicates that forms overflow control is not to be used.

Defaults
If you do not code the OVFL parameter, the default is ON.

Example of the OVFL Parameter

//WRTO JOB ACNO77,MAEBIRD,MSGCLASS=B
//DS23 OUTPUT DEFAULT=YES,FORMS=STD,OVFL=OFF
//STEP1 EXEC PGM=DLYRPT
//DAILY DD SYSOUT=A

In this example, sysout DD statement DAILY implicitly references the default

job-level OUTPUT JCL statement DS23. This OUTPUT JCL statement directs JES3
to print the daily report on standard forms. If no carriage control characters are
used, the JES3 output writer will print the output as a continuous stream of data
with no blank lines between pages.

PAGEDEF Parameter
Parameter Type

Keyword, optional

Purpose

Use the PAGEDEF parameter to identify a library member that contains statements
to tell the Print Services Facility (PSF) how to print the sysout data set on a

Chapter 22. OUTPUT JCL Statement 22-63

OUTPUT JCL: PAGEDEF
page-mode printer (such as the 3800 Printing Subsystem Model 3). The data set
may be sysout or a data set that is allocated directly to a printer. The statements
can specify the following:
v Logical page length and width.
v Fonts.
v Page segments.
v Multiple page types or formats.
v Lines within a page; for example:
– Line origin.
– Carriage controls.
– Spacing.
v Multiple logical pages on a physical page.

The member must be in the library named in the cataloged procedure that was
used to initialize the PSF, or in a library specified in the USERLIB parameter.

Note: PAGEDEF applies only for data sets printed on a page-mode printer (such
as a 3800 Model 3).

References

For more information, see PSF/MVS Application Programming Guide and 3800
Programmer’s Guide.

Syntax
PAGEDEF=membername

Subparameter Definition
membername
Specifies the name of the library member. membername is 1 through 6
alphanumeric or national ($, #, @) characters; the first two characters are
pre-defined by the system.

Overrides
The statements in the library member specified by the OUTPUT JCL PAGEDEF
parameter override the installation’s PAGEDEF defaults in the PSF cataloged
procedure.

The PSF uses the following parameters, in override order, to select the font list:
1. Font list in the library member specified by an OUTPUT JCL PAGEDEF
parameter.
2. DD CHARS parameter.
3. OUTPUT JCL CHARS parameter.
4. DD UCS parameter.
5. OUTPUT JCL UCS parameter.
6. JES installation default for the device.
7. Font list on the PAGEDEF parameter in the PSF cataloged procedure.

Example of the PAGEDEF Parameter

//OUTDS1 OUTPUT PRMODE=PAGE,PAGEDEF=SSPGE

22-64 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: PAGEDEF
In this example, PSF is to print the sysout data set on a 3800 Model 3 operating in
page mode. The printing is to be done according to the parameters in the library
member SSPGE.

PIMSG Parameter
Parameter Type

Keyword, optional

Purpose

Use the PIMSG parameter to indicate the handling of messages by Print Services
Facility (PSF). PIMSG is used to specify whether all error messages are to be
printed, and the number of errors sufficient to cause the printing process to be
terminated and the data set to be purged.

When you code PIMSG=YES, the system prints all these messages at the end of
the output data set.

When you code PIMSG=NO, no messages are printed unless there is an error that
forces premature termination of the printing of the data set. If an error occurs, the
system prints the set of messages (called a message group) associated with the
error that caused the termination.

As errors are detected by PSF or reported to PSF by the printer, a count is kept of
the associated message groups. When the count equals the number specified on
the PIMSG parameter, PSF terminates the printing of the current data set. PSF
interprets a count of zero as infinite, and does not terminate the printing of the data
set on the basis of the number of errors detected.

Note: PIMSG can be specified only for data sets printed through PSF.

Syntax
PIMSG= {(YES[,msg-count])}
{(NO[,msg-count]) }

v You can omit the parentheses if you do not specify msg-count.

Subparameter Definition
YES
Requests the system to print all messages generated by PSF. You can also
code this subparameter as Y.
NO
Requests that the system print no error messages, unless printing of the data
set is prematurely terminated. If a terminating error occurs, only the set of
messages (called a message group) associated with the error that caused the
termination is printed. You can also code this subparameter as N.
msg-count
Requests the system to cancel the printing of the current data set after the
specified number of errors (as represented by the associated message groups)
have been detected by PSF or reported to PSF by the printer. In this context,

Chapter 22. OUTPUT JCL Statement 22-65

OUTPUT JCL: PIMSG
errors refers to data-stream errors, and errors resulting from any malfunction
that would cause the printer to halt, such as a mechanism failure, or
out-of-paper condition. However, these errors do not include those caused by
operator intervention.
Valid values for msg-count are 0-999, where 0 is interpreted as infinite.
The types of errors that increment the message count are those that induce a
message group to be printed at the end of the data set. However, even though
the printing of the message groups is inhibited by PIMSG=NO, the associated
error still increments the message count. (A message group consists of a
primary message and variable number of informational messages that result
from a single error.)
In the case that multiple transmissions have been specified for a single data set
(user-specified multiple copies), the message count would apply on a per copy
basis. If the specified number of errors are discovered during the printing of any
copy, the subject copy is terminated, and the remaining copies are not printed.

Defaults
If you do not code the PIMSG parameter, the PIMSG specification from the PSF
PRINTDEV statement applies. If not specified in the PRINTDEV statement, the
default is PIMSG=(YES,16). For information about the PRINTDEV statement, see
PSF for OS/390 & z/OS: Customization.

Examples of the PIMSG Parameter

Example 1
//OUTDS2 OUTPUT DATACK=UNBLOCK,PIMSG=(YES,0)

In this example, regardless of how many message-generating errors are detected

by PSF or reported to PSF by the printer, the printing of the current data set
continues to completion or until a terminating error is encountered. All the
messages are printed by the system.

Example 2
//OUTDS2 OUTPUT DATACK=UNBLOCK,PIMSG=(NO,5)

In this example, after five message-generating errors are detected by PSF or

reported to PSF by the printer, the printing of the current data set is terminated.
Only the last message group is printed by the system.

PORTNO Parameter
Parameter Type

Keyword, optional

Purpose

Use the PORTNO parameter to specify the TCP/IP port number at which the FSS
(for example, IP Printway) connects to the printer.

Syntax
PORTNO=nnnnn

22-66 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: PORTNO
Subparameter Definition
nnnnn
Specifies the TCP/IP port number, where nnnnn is a number from 1 through
65,535.

Relationship to Other System Functions

The port number must match the port number configured at the printer.

Example of the PORTNO Parameter

//OUTPORT OUTPUT PORTNO=5005

In this example, 5005 is the TCP/IP port number.

PRMODE Parameter
Parameter Type

Keyword, optional

Purpose

Use the PRMODE parameter to identify the process mode required to print the
sysout data set. JES schedules the data set to a printer that can operate in the
specified mode.

For a list of valid process modes, contact your system programmer.

Syntax
PRMODE= {LINE }
{PAGE }
{process-mode}

Subparameter Definition
LINE
Indicates that the data set is to be scheduled to a line-mode printer.
PAGE
Indicates that the data set is to be scheduled to a page-mode printer.
process-mode
Specifies the required process mode. The process-mode is 1 through 8
alphanumeric characters.
For an NJE-transmitted data set, use PRMODE to request specific processing
without having to obtain output classes for the node that processes the data
set.

Defaults
If you do not code the PRMODE parameter, JES schedules output processing as
follows:
v If the sysout data set does not contain page-mode formatting controls, the
process mode of line is given to the data set.

Chapter 22. OUTPUT JCL Statement 22-67

OUTPUT JCL: PRMODE
v If the sysout data set contains page-mode formatting controls, the process mode
of page is given to the data set.

Printing a Line-Mode Data Set Using PSF

To print a line-mode data set using the Print Services Facility (PSF) and the
enhanced capabilities of the 3800 Model 3, 6 and 8, code PRMODE=PAGE. The
PSF formats this line-mode data set using the installation’s default values for
PAGEDEF and FORMDEF defined in the PSF cataloged procedure; if these
defaults are unsatisfactory, code the PAGEDEF and FORMDEF parameters on the
OUTPUT JCL statement.

Example of the PRMODE Parameter

//DS18 OUTPUT PRMODE=LINE

In this example, JES schedules the sysout data set to a printer with a process
mode of line.

PRTERROR Parameter
Parameter Type

Keyword, optional

Purpose

Specifies the disposition of the SYSOUT data set used if a terminating error occurs
during printing through the PSF/MVS functional subsystem. (A terminating error is
an error that the automated recovery of PSF/MVS cannot correct.) You can specify
which of the following actions PSF/MVS is to take for a terminating error:
v Use the default error disposition (DEFAULT),
v Release the SYSOUT data set back to JES as complete (QUIT), or
v Hold for operator action (HOLD).

Syntax
PRTERROR=(DEFAULT|QUIT|HOLD)

Subparameter Definition
DEFAULT
Specifies that PSF/MVS will take the standard (default) action if a terminating
error occurs during printing. When operator action is expected to correct the
error, PSF/MVS releases the SYSOUT data set for hold. Otherwise, it treats the
SYSOUT data as complete. For JES2, processing of the data set proceeds
according to the OUTDISP keyword value that is associated with it. For JES3,
the data set is deleted from the SPOOL. (See ″Relationship to Other Control
Statements,″ below.)
QUIT
Specifies that PSF/MVS is to release the data set complete even if a
terminating error occurs during printing. JES then disposes of the data set as if
it completed printing successfully. For JES2, processing of the data set

22-68 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: PRTERROR
proceeds according to the OUTDISP keyword value that is associated with it.
For JES3, the data set is deleted from the SPOOL. (See ″Relationship to Other
Control Statements,″ below).
HOLD
Specifies that if a terminating error occurs during printing, the data set will
remain on the JES SPOOL until the system operator releases it.

Relationship to Other Control Statements

For the JES2 subsystem, OUTDISP affects the processing when
PRTERROR=DEFAULT or PRTERROR=QUIT is performed and PSF/MVS releases
the data set as complete.

An installation can control (through the PSF PRINTDEV initialization statement)

whether the system honors or ignores the specification of the PRTERROR keyword
on the OUTPUT JCL statement or dynamic output descriptors.

Note: There are conditions under which PRTERROR has no effect. See the
applicable PSF/MVS book for additional information.

Examples of the PRTERROR Parameter

Example 1
//OUTPRTER OUTPUT PRTERROR=HOLD

In this example, if a terminating error occurs during printing, the data set remains
on the JES SPOOL until the system operator releases it.

Example 2
//OUTPRTER OUTPUT PRTERROR=QUIT

In this example, if a terminating error occurs during printing, PSF quits processing
the data set and releases it as ″complete,″ and JES applies processing appropriate
for a completed data set.

PRTOPTNS Parameter
Parameter Type

Keyword, optional

Purpose

PRTOPTNS defines a named entity that contains additional print options a

functional subsystem can use. The PRTOPTNS keyword applies only to data sets
processed by a functional subsystem that can perform Internet Protocol (IP)
transmission. JES does not use PRTOPTNS, but passes it to the functional
subsystem during data set selection. See the documentation for the particular
subsystem for additional information.

Syntax
PRTOPTNS=<options name>

Chapter 22. OUTPUT JCL Statement 22-69

OUTPUT JCL: PRTOPTNS
Subparameter Definition
<options data set entry name>
Identifies the print options data. The name can be 1 to 16 characters long. If the
name includes any special characters (for example, a dash), enclose the entire
parameter in single quotes. You can also specify this keyword by using a
dynamic output descriptor.

Relationship to Other System Functions

The PRTOPTNS parameter can be used by functional subsystem applications
(FSAs), such as IP PrintWay, that can perform Internet Protocol (IP) transmission.

Example of the PRTOPTNS Parameter

//OUTOPTNS OUTPUT PRTOPTNS=’Boulder4019Optns’

In this example Boulder4019Optns is the name of the entity used to reference

additional print options.

PRTQUEUE Parameter
Parameter Type

Keyword, optional

Purpose

PRTQUEUE defines the name of the target print queue on a remote host system.
The PRTQUEUE keyword applies only to data sets processed by a functional
subsystem that can perform Internet Protocol (IP) transmission. JES does not use
PRTQUEUE, but passes it to the functional subsystem (for example, IP PrintWay),
during data set selection. See the documentation for the particular subsystem for
additional information.

Syntax
PRTQUEUE=<print queue name>

Subparameter Definition
<print queue name>
Identifies the target print queue name. The name can be 1 to 127 characters
long and may include any printable character. If the name includes any special
character (for example, a dash or lower case letter), enclose the entire
parameter in single quotes. You can also specify this keyword by using a
dynamic output descriptor.

Relationship to Other System Functions

The PRTQUEUE parameter can be used by functional subsystem applications
(FSAs), such as PrintWay, that can perform Internet Protocol (IP) transmission.

22-70 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: PRTQUEUE
Example of the PRTQUEUE Parameter
//OUTQUEUE OUTPUT PRTQUEUE=’4019’

In this example 4019 is the name of the target print queue destination.

PRTY Parameter
Parameter Type

Keyword, optional

Purpose

Use the PRTY parameter to specify the priority at which the sysout data set enters
the output queue. A data set with a higher priority is printed sooner.

Syntax
PRTY=nnn

Subparameter Definition
nnn
Specifies the initial priority. nnn is a decimal number from 0 through 255; 0 is
the lowest priority while 255 is the highest.

Defaults
If you do not code the PRTY parameter, JES3 uses an installation default specified
at initialization. JES2 uses a priority that is calculated for all output.

Overrides
In JES2 systems, the installation can specify at JES2 initialization that JES2 is to
ignore the OUTPUT JCL PRTY parameter.

In JES3 systems, the OUTPUT JCL PRTY parameter is ignored for JES3
networking.

Example of the PRTY Parameter

//PRESRPT OUTPUT PRTY=200,FORMS=TOPSEC

In this example, JES prints one copy of the president’s report, PRESRPT, on forms
named TOPSEC. Because a priority of 200 is specified, the report is probably
printed immediately after entering the output queue.

RESFMT Parameter
Parameter Type

Keyword, optional

Purpose

Chapter 22. OUTPUT JCL Statement 22-71

OUTPUT JCL: RESFMT
Use the RESFMT parameter to specify the resolution used to format the print data
set. PSF/MVS will use this value to select the resource libraries for the resolution
indicated. For more information see the PSF/MVS Application Programming Guide.

Syntax
RESFMT = {P240 | P300}

Subparameter Definition
P240
Indicates that the data set was formatted with resources at 240 pels per inch.
P300
Indicates that the data set was formatted with resources at 300 pels per inch.

Relationship to Other Control Statements

If RESFMT is the highest priority specified resolution for a data set, then PSF/MVS
will use the corresponding resource libraries as defined by the system programmer
on the PRINTDEV statement. For information about the PRINTDEV statement, see
PSF for OS/390 & z/OS: Customization.

Example of the RESFMT Parameter

//OUTRES OUTPUT RESFMT=P240

In this example, the print data set was formatted for printing at 240 pels per inch.

RETAINS and RETAINF Parameters

Parameter Type

Keyword, optional

Purpose

RETAINS specifies the amount of time to retain a successfully transmitted data set.
RETAINF specifies the amount of time to retain a data set that failed to be
transmitted. Each of these keywords consists of a numeric value indicating hours,
minutes, and seconds.

These parameters apply only to data sets processed by a functional subsystem that
can perform Internet Protocol (IP) transmission. JES does not use the RETAINS or
RETAINF parameters, but passes them to the functional subsystem during data set
selection.

Use RETAINS= when the functional subsystem has successfully transmitted the
data set. Use RETAINF= when the functional subsystem employing the IP routing
has not successfully transmitted the data set, despite performing all the indicated
retries through any RETRY parameters specified. You have the option of
manipulating the data set through the facilities provided by the functional subsystem
before that subsystem releases the data set to JES. See the documentation for the
particular subsystem for additional information.

22-72 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: RETAINS and RETAINF
Syntax
RETAINS=’<hhhh>:<mm>:<ss>’ -or- RETAINS=FOREVER
RETAINF=’<hhhh>:<mm>:<ss>’ -or- RETAINF=FOREVER

Subparameter Definition
<hhhh>:<mm>:<ss>
Specifies the successful (RETAINS=) and failed (RETAINF=) time intervals to
retain the data set.
One to ten characters, where <hhhh>, <mm>, and <ss> are numeric. This
format requires that for either keyword you enclose the entire parameter in
single quotes due to the colon as a special character.
You may specify FOREVER to request the system to retain the data set
indefinitely.
You can also specify these keywords by using a dynamic output descriptor.
Only functional subsystems may use these keywords. See the documentation
for the particular subsystem for additional information.

Relationship to Other Control Statements

The RETAIN keywords interact with the RETRY keywords in determining how long
the functional subsystem is to hold on to the data set after either a successful or
failed transmission of the data set before releasing it back to JES.

Relationship to Other System Functions

The RETAINS and RETAINF keywords can be used by functional subsystem
applications (FSAs), such as IP PrintWay, that can perform Internet Protocol (IP)
transmission.

Examples of the RETAIN Keywords

Example 1: RETAINS and RETAINF
//OUTRETRY OUTPUT RETAINS=’0001:00:00’,RETAINF=’0002:00:00’

In this example the functional subsystem will not release the data set to JES until
one hour after a successful transmission. If the data set was not successfully
transmitted, the subsystem will not release the data set to JES until two hours after
the last unsuccessful transmission attempt.

Example 2: RETAINF Only

//OUTRETRY OUTPUT RETAINF=’0003:00:00’

In this example the functional subsystem will retain the data set for three hours
following a failed transmission before releasing it to JES.

Chapter 22. OUTPUT JCL Statement 22-73

OUTPUT JCL: RETRYL and RETRYT

RETRYL and RETRYT Parameters

Parameter Type

Keyword, optional

Purpose

Each of these keywords specifies a numeric value, as follows:

v RETRYL=limit defines the maximum number of attempts to transmit a data set
before the RETAIN keyword options take effect.
v RETRYT=’retry time’ defines how much time to wait between each attempt to
transmit the data set. It is formatted into hours, minutes, and seconds.

RETRYL and RETRYT apply only to data sets processed by a functional subsystem
that can perform Internet Protocol (IP) transmission. JES does not use the RETRYL
or RETRYT parameters, but passes them to the functional subsystem during data
set selection. See the documentation for the particular subsystem for additional
information.

Syntax
RETRYL=nnnnn
RETRYT=’<hhhh>:<mm>:<ss>’

Subparameter Definition
<nnnnn>
An integer from 0 to 32,767 (decimal) that specifies the maximum number of
retries to attempt before the RETAIN keyword options are to take effect.
<hhhh>:<mm>:<ss>
One to ten characters, where <hhhh>, <mm>, and <ss> are numeric. This
format requires that you enclose this entire parameter in single quotes due to
the colon as a special character.
These keywords are for use only by functional subsystems such as IP PrintWay.
See the documentation for the particular subsystem for additional information.
You can also specify these keywords by using a dynamic output descriptor.

Relationship to Other Control Statements

The RETRYL and RETRYT keywords interact with the RETAINS and RETAINF
keywords to determine the number and frequency of retry attempts to transmit the
data set before the values of RETAIN for successful or failed attempts, respectively,
take effect.

Relationship to Other System Functions

The RETRYL and RETRYT keywords can be used by functional subsystem
applications (FSAs), such as PrintWay, that can perform Internet Protocol (IP)
transmission.

22-74 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: RETRYL and RETRYT
Examples of the RETRY Keywords
Example 1: RETRYT and RETRYL
//OUTRETRY OUTPUT RETRYT=’0001:00:00’,RETRYL=5

In this example a retry is attempted every hour, for a maximum of five attempts.

Example 2: RETRYT Only

//OUTRETRY OUTPUT RETRYT=’0000:05:00’

In this example a retry is attempted every five minutes.

ROOM Parameter
Parameter Type

Keyword, optional

Purpose

Use the ROOM parameter to print a room identification on the separator pages of
the output for a sysout data set. An installation can use the room identification to
assist in sysout distribution.

Syntax
ROOM= {’room identification’}
{room-identification }
Valid Characters in Enclosing Apostrophes:
v A room identification enclosed in apostrophes can contain any EBCDIC text character.
v When the value for room identification contains a blank, enclose the value in
apostrophes.
v To code an apostrophe in the room identification, code 2 apostrophes, and enclose the
preferred name in single apostrophes. For example:
//OUTDS OUTPUT ROOM=’DIRECTOR’’S ROOM’
v Each value may optionally be enclosed in apostrophes.

Valid Characters Without Enclosing Apostrophes: When the value for room identification
is not enclosed in apostrophes, the following characters are valid:
v Alphanumeric and national (@, $, #) characters
v Period (.) and asterisk (*); however, an asterisk followed by a period indicates a referral
and is not allowed as the start (first and second characters) of the value.
v Ampersand (&). An ampersand that refers to a symbolic is substituted. Two consecutive
ampersands are not substituted, but they will result in a single ampersand as part of the
value.
v Plus sign (+)
v Hyphen (-).
v Slash (/)

Symbolic Parameters: Do not enclose symbolic parameters in apostrophes. Symbolic

parameters within apostrophes are not resolved for this keyword.

Subparameter Definition
room identification
Specifies the room identification to be associated with the sysout. The room

Chapter 22. OUTPUT JCL Statement 22-75

OUTPUT JCL: ROOM
identification is 1 - 60 EBCDIC text characters. See “Character Sets” on
page 4-3 for a description of EBCDIC text characters.

Defaults
v In an APPC scheduling environment:
In both JES2 and JES3 systems, if you do not code the ROOM parameter on the
OUTPUT JCL statement, the system uses the value defined in the transaction
program (TP) user’s RACF profile when:
– The user submitting the TP profile has a RACF profile defined for him, and
– The transaction program profile includes TAILOR_SYSOUT(YES).

Otherwise, the system uses the value defined on the transaction initiator’s job
statement.
v In a non-APPC scheduling environment:
In a JES2 system, if you do not code the ROOM parameter on the OUTPUT JCL
statement, the system uses the 4-character room field defined in the JES2
accounting parameter on the JOB statement.
In a JES3 system, there is no default for the ROOM parameter on the OUTPUT
JCL statement.

Overrides
v In an APPC scheduling environment:
In both JES2 and JES3 systems the ROOM parameter on the OUTPUT JCL
statement overrides the room defined in the RACF profile. The room in the RACF
profile overrides the room defined in the transaction initiator’s job statement.
v In a non-APPC scheduling environment:
In both JES2 and JES3 systems, the ROOM parameter on the OUTPUT JCL
statement overrides the 4-character room field defined in the JES2 accounting
parameter on the JOB statement.

Example of the ROOM Parameter

//OUTDS8 OUTPUT ROOM=’CONFERENCE ROOM’

In this example, CONFERENCE ROOM is printed on the line reserved for ROOM
on the separator pages of any sysout data set that references OUTDS8.

SYSAREA Parameter
Parameter Type

Keyword, optional

Purpose

Use the SYSAREA (system area) parameter to indicate whether the system should
reserve an area on each page of printed output for the security label. The security
label represents a security level and categories as defined to RACF.

Note: When a system area is reserved for a security label, the system shifts the
printed output on each page. You cannot print output data in the system
area.

22-76 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: SYSAREA
Reference

For additional information on the system area, refer to the PSF/MVS System
Programming Guide.

Syntax
SYSAREA= {YES}
{Y }
{NO }
{N }

Subparameter Definition
YES
Requests that a system area be reserved on each page of printed output for the
security label. This parameter can also be coded as Y.
NO
Requests that a system area not be reserved on each page of printed output for
the security label. This parameter can also be coded as N.

Defaults
If you do not code the SYSAREA parameter, an installation default determines if a
system area is reserved for a security label.

Relationship to Other Parameters

Use the SYSAREA parameter with the DPAGELBL parameter on the OUTPUT JCL
statement and the SECLABEL parameter on the JOB statement as instructed by
your security administrator.

The SYSAREA parameter can be coded with any other OUTPUT JCL statement
parameters.

Example of the SYSAREA Parameter

//JOBB JOB 1,’JIM WOOSTER’,SECLABEL=CONF
.
.
//PRESRPT OUTPUT DPAGELBL=YES,SYSAREA=YES,FORMS=CSEC

In this example, the security label CONF (specified on the SECLABEL parameter of
the JOB statement) is printed on each page of printed output in the system area.
The sysout data set is printed on forms named CSEC.

THRESHLD Parameter
Parameter Type

Keyword, optional, JES3 only

Purpose

Use the THRESHLD parameter to specify the maximum size for the sysout data
set. JES3 calculates the sysout data set size as the number of records multiplied by
the number of copies requested. When this size exceeds the THRESHLD value,

Chapter 22. OUTPUT JCL Statement 22-77

OUTPUT JCL: THRESHLD
JES3 creates a new unit of work, on a data set boundary, and queues it for printing.
Consequently, copies of the sysout data set may be printed simultaneously by
different printers.

Use the THRESHLD parameter for jobs that generate many large data sets or
many copies of one large data set.

Note: THRESHLD is supported only on JES3 systems.

Syntax
THRESHLD=limit

Subparameter Definition
limit
Specifies the maximum number of records for a single sysout data set. limit is a
decimal number from 1 through 99999999.

Defaults
If you do not code the THRESHLD parameter, JES3 uses an installation default
specified at initialization.

Example of the THRESHLD Parameter

//STEPA EXEC PGM=RPTWRT
//SYSDS3 OUTPUT DEFAULT=YES,THRESHLD=10000
//RPT1 DD SYSOUT=A,COPIES=10
//RPT2 DD SYSOUT=A,COPIES=2
//RPT3 DD SYSOUT=A,COPIES=5

In this example, the report data sets, RPT1, RPT2, and RPT3, are processed in
sysout class A. All three DD statements implicitly reference the step-level default
OUTPUT JCL statement SYSDS3; therefore, the THRESHLD value specified in the
OUTPUT JCL statement applies to the three reports combined. JES3 is to print the
following:

Data Records in Total

Copies Set Data Set Records
10 RPT1 1000 10000
2 RPT2 2000 4000
5 RPT3 500 2500

Total 16500

Because the total exceeds the THRESHLD limit, JES3 divides the sysout data sets
into two units of work. RPT1 is printed as one unit, and the other two data sets are
printed together as another unit. If the THRESHLD limit had been 20000, all three
data sets would have been printed as one unit of work.

22-78 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: TITLE

TITLE Parameter
Parameter Type

Keyword, optional

Purpose

Use the TITLE parameter to print a description of the output on the separator pages
of the output of a sysout data set. An installation can use the description to assist in
sysout distribution.

Syntax
TITLE= {’description of output’}
{description-of-output }
Valid Characters in Enclosing Apostrophes:
v A description of output enclosed in apostrophes can contain any EBCDIC text character.
v When the value for description of output contains a blank, enclose the value in
apostrophes.
v To code an apostrophe in the description of output, code 2 apostrophes, and enclose the
description of output in single apostrophes. For example:
//OUTDS OUTPUT TITLE=’PRESIDENT’’S REPORT’
v Each value may optionally be enclosed in apostrophes.

Valid Characters Without Enclosing Apostrophes: When the value for description of
output is not enclosed in apostrophes, the following characters are valid:
v Alphanumeric and national (@, $, #) characters
v Period (.) and asterisk (*); however, an asterisk followed by a period indicates a referral
and is not allowed as the start (first and second characters) of the value.
v Ampersand (&). An ampersand that refers to a symbolic is substituted. Two consecutive
ampersands are not substituted, but they will result in a single ampersand as part of the
value.
v Plus sign (+)
v Hyphen (-).
v Slash (/)

Symbolic Parameters: Do not enclose symbolic parameters in apostrophes. Symbolic

parameters within apostrophes are not resolved for this keyword.

Subparameter Definition
description of output
Specifies a description of output to be associated with a sysout data set. The
description of output is 1 - 60 EBCDIC text characters. See “Character Sets” on
page 4-3 for a description of EBCDIC text characters.

Example of the TITLE Parameter

//OUTDS5 OUTPUT TITLE=’ANNUAL REPORT’

In this example, ANNUAL REPORT is printed on the line reserved for title on the
separator pages of any sysout data set referencing OUTDS5.

Chapter 22. OUTPUT JCL Statement 22-79

OUTPUT JCL: TRC

TRC Parameter
Parameter Type

Keyword, optional

Purpose

Use the TRC parameter to specify whether the logical record for each output line in
the sysout data set contains table reference character (TRC) codes or not. The
TRC code identifies which table-name in the CHARS parameter is to be used to
print the record.

If present, a TRC code in the output line record is:

v The first byte, if a carriage control character is not used.
v The second byte, immediately following the carriage control character, if used.

Note: TRC is supported only for a data set processed by the Print Services Facility
(PSF).

Syntax
TRC= {YES}
{Y }
{NO }
{N }

Subparameter Definition
YES
Indicates that the data set contains TRC codes. This subparameter can also be
coded as Y.
NO
Indicates that the data set does not contain TRC codes. This subparameter can
also be coded as N.

Note: The data set DCB must not indicate that the data set contains TRC codes.
DCB=(OPTCD=J) overrides TRC=NO when the data set is printed by PSF.

Defaults
If you do not code the TRC parameter, the default is to use TRC characters only if
the data set DD statement specified DCB=(OPTCD=J).

Relationship to Other Parameters

A table reference character for the entire data set can be specified in the OUTPUT
JCL MODIFY parameter.

Example of the TRC Parameter

//WRTR JOB ACNO77,MAEBIRD,MSGCLASS=B
//DS23 OUTPUT DEFAULT=YES,FORMS=STD,CONTROL=PROGRAM,TRC=YES
//STEP1 EXEC PGM=DLYRPT
//DAILY DD SYSOUT=A,CHARS=(GT12,GB12,GI12)

22-80 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: TRC
In this example, sysout DD statement DAILY implicitly references the default
job-level OUTPUT JCL statement DS23. This OUTPUT JCL statement directs PSF
to print the daily report on standard forms, using table reference characters. The
sysout data set defined by DD statement DAILY contains carriage control characters
in the first character of each logical record and a TRC code in the second
character. The TRC characters in the records are 0 to use the font GT12; 1 to use
GB12; and 2 to use GI12.

UCS Parameter
Parameter Type

Keyword, optional

Purpose

Use the UCS parameter to identify:

v The universal character set (UCS) image JES is to use in printing the sysout
data set.
v A print train (print chain or print band) JES is to use in printing the sysout data
set on an impact printer.
v A character-arrangement table for the sysout data set printed on a 3800 Printing
Subsystem in a JES2 system. In this use, the UCS parameter acts like a CHARS
parameter.

The UCS image specifies the special character set to be used. JES loads the
image into the printer’s buffer. The UCS image is stored in SYS1.IMAGELIB. IBM
provides the special character set codes in Table 22-2.

References

For more information on the UCS parameter, see z/OS DFSMSdfp Advanced
Services.

Syntax
UCS=character-set-code

Subparameter Definition
character-set-code
Identifies a universal character set. The character-set-code is 1 through 4
alphanumeric or national ($, #, @) characters. See Table 22-2 for IBM standard
special character set codes.

Defaults
If you do not code the UCS parameter, the system checks the UCS image in the
printer’s buffer; if it is a default image, as indicated by its first byte, JES uses it. If it
is not a default image, JES loads the UCS image that is the installation default
specified at JES initialization.

On an impact printer, if the chain or train does not contain a valid character set,
JES asks the operator to specify a character set and to mount the corresponding
chain or train.

Chapter 22. OUTPUT JCL Statement 22-81

OUTPUT JCL: UCS
Table 22-2. Special Character Sets for the 1403, 3203 Model 5, and 3211 Printers
3203
1403 Model 5 3211 Characteristics
AN AN A11 Arrangement A, standard EBCDIC character set, 48
characters
HN HN H11 Arrangement H, EBCDIC character set for FORTRAN
and COBOL, 48 characters
G11 ASCII character set
PCAN PCAN Preferred alphanumeric character set, arrangement A
PCHN PCHN Preferred alphanumeric character set, arrangement H
PN PN P11 PL/I alphanumeric character set
QN QN PL/I preferred alphanumeric character set for
scientific applications
QNC QNC PL/1 preferred alphanumeric character set for
commercial applications
RN RN Preferred character set for commercial applications of
FORTRAN and COBOL
SN SN Preferred character set for text printing
TN TN T11 Character set for text printing, 120 characters
XN High-speed alphanumeric character set for 1403,
Model 2
YN High-speed preferred alphanumeric character set for
1403, Model N1
Note: Where three values exist (for the 1403, 3211, and 3203 Model 5 printers), code any
one of them. JES selects the set corresponding to the device on which the data set is
printed.

Not all of these character sets may be available at your installation. Also, an installation can
design character sets to meet special needs and assign a unique code to them. Follow
installation procedures for using character sets.

Overrides
For printing on a printer with the UCS feature, a UCS parameter on the sysout DD
statement overrides the OUTPUT JCL UCS parameter. For printing on a 3800, a
CHARS parameter on the sysout DD statement or the OUTPUT JCL statement
overrides all UCS parameters.

For a data set scheduled to the Print Services Facility (PSF), the PSF uses the
following parameters, in override order, to select the font list:
1. Font list in the library member specified by an OUTPUT JCL PAGEDEF
parameter.
2. DD CHARS parameter.
3. OUTPUT JCL CHARS parameter.
4. DD UCS parameter.
5. OUTPUT JCL UCS parameter.
6. JES installation default for the device.
7. Font list on the PAGEDEF parameter in the PSF cataloged procedure.

See “PAGEDEF Parameter” on page 22-63 for more information.

22-82 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: UCS
Using Special Characters Sets
To use a special character set, SYS1.IMAGELIB must contain an image of the
character set, and the chain or train for the character set must be available. IBM
provides standard special character sets, and the installation may provide
user-designed special character sets.

Example of the UCS Parameter

//PRTDS9 OUTPUT UCS=A11

In this example, JES uses standard EBCDIC character set arrangement A, with 48
characters, to print the sysout data set on a 3211 printer.

USERDATA Parameter
Parameter Type

Keyword, optional

Purpose

The purpose and use of this keyword is defined by the installation. Refer to your
installation’s definition on the intent and use of this keyword.

If your installation does not define any use for this keyword, the information will be
checked for syntax, stored as part of the output descriptor’s information, and will
then be ignored.

Networking Considerations

The use of the USERDATA keyword on one network node can be different from the
use on another network node. An installation will have to coordinate any sending
and receiving nodes to make use of the USERDATA keyword.

References

Refer to the z/OS MVS JCL User’s Guide, section “SYSOUT

Resources—USERDATA OUTPUT JCL Keyword” for more details on how this
keyword may be used.

Syntax
USERDATA=value
(value[,value]...)

Chapter 22. OUTPUT JCL Statement 22-83

OUTPUT JCL: USERDATA

v Your installation defines the intent and use of this keyword.

v You can omit the parentheses if you code only one value.
v Null positions in the USERDATA parameter are not allowed. For example, you cannot
code USERDATA=(,value) or USERDATA=(value,,value).
v Each value may optionally be enclosed in apostrophes.
v Valid Characters in Enclosing Apostrophes:
– A USERDATA parameter value enclosed in apostrophes can contain any EBCDIC text
character.
– Enclose a value that contains a blank in apostrophes. Trailing blanks specified as part
of a value enclosed in apostrophes are maintained. That is, if USERDATA=’SUNDAY ’
was specified, then the first parameter value for the USERDATA keyword is eight (8)
characters and may be deemed by the installation to be different than
USERDATA=’SUNDAY’ (6 characters) or USERDATA=’SUNDAY ’ (7 characters).
– To code an apostrophe as part of the parameter value, code 2 apostrophes, and
enclose the entire value in single apostrophes. For example:
//OUTDSQ OUTPUT USERDATA=’USERKEY1=User’’s value’
v Valid Characters Without Enclosing Apostrophes:
– Alphanumeric (upper case) and national (@, $, #) characters
– Period (.) and asterisk (*); however, an asterisk followed by a period indicates a
referral and is NOT allowed as the start (first and second characters) of the value.
– Ampersand (&). An ampersand that refers to a symbolic is substituted. Two
consecutive ampersands are not substituted; they will result in a single ampersand as
part of the value.
– Plus sign (+)
– Hyphen (-)
– Slash (/)
v SYMBOLIC PARAMETERS: Do not enclose symbolic parameters within apostrophes.
Symbolic parameters enclosed in apostrophes are not resolved.

Subparameter Definition
value
Specifies the installation defined values for the installation’s prescribed
processing. You can code up to 16 installation-defined values. Each value may
be from 1 to 60 EBCDIC text characters. See “Character Sets” on page 4-3 for
a description of EBCDIC text characters.

Defaults
Determined by the installation.

Overrides
Determined by the installation.

Relationship to Other Keywords on this Statement

Determined by the installation.

Relationship to Other Control Statements

Determined by the installation.

22-84 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: USERDATA
Relationship to Other System Functions
Determined by the installation.

Examples of the USERDATA Parameter

The installation defines the intended content for each of the USERDATA values.
The following examples are intended to provide samples of the allowable syntax for
the USERDATA keyword. The resulting value (or portions of the value) are enclosed
in parentheses to help distinguish them.

Example 1
//OUTDS1 OUTPUT USERDATA=USERVALUE

In this example, the USERDATA keyword contains a single parameter value

(USERVALUE). Note that the value does not require enclosing apostrophes,
because it contains only characters that are valid without them.

Example 2
//OUTDS2 OUTPUT USERDATA=’Installation data’

In this example, the USERDATA keyword contains a single parameter value within
apostrophes (Installation data).

Example 3
//OUTDS3 OUTPUT USERDATA=’LOCALKEY=Installation data’

In this example, the USERDATA keyword contains a single parameter value within
the apostrophes (LOCALKEY=Installation data). The single parameter value
contains a string within the apostrophes that could be used to identify an
installation-defined keyword (LOCALKEY) and its parameter value (Installation
data).

Example 4
//OUTDS4 OUTPUT USERDATA=’USERKEY1=User’’s value’

In this example, the USERDATA keyword contains a single parameter value

containing a string within the apostrophes that could be used to identify an
installation defined keyword (USERKEY1) and its parameter value (User’s value).

Example 5
//OUTDSA OUTPUT USERDATA=(’non-keyword data’,
// ’SOMEKEY=Some data’,
// ’PARM3=Parm3’’s value’,
// LASTVALUE)

In this example, the USERDATA keyword contains four parameter values.

v The first parameter value contains a string within the apostrophes (non-keyword
data). An installation can consider this type of parameter a positional parameter.
It is recommended that positional parameters be clearly indicated by the
installation to allow for easier specification, recognition, and processing.
v The second parameter value contains a string within the apostrophes that could
be used to identify an installation defined keyword (SOMEKEY) and its parameter
value (Some data).

Chapter 22. OUTPUT JCL Statement 22-85

OUTPUT JCL: USERDATA
v The third parameter value contains a string within the apostrophes that could be
used to identify an installation defined keyword (PARM3) and its parameter value
(Parm3’s value).
v The fourth parameter value contains a string without any enclosing apostrophes
(LASTVALUE).

Example 6
//OUTDSB OUTPUT USERDATA=(’Installation_Keyword=Installation
// defined keyword value’,
// ’PARM2=Parm2’’s value (second option)’)

In this example, the USERDATA keyword contains two parameter values.

v The first parameter value contains a string within the apostrophes that could be
used to identify an installation defined keyword (Installation_Keyword) and its
parameter value (Installation defined keyword value), assuming the ’d’ was
specified in column 71 on the first statement.
v The second parameter value contains a string within the apostrophes that could
be used to identify an installation defined keyword (PARM2) and its parameter
value (Parm2’s value (second option)).

Example 7
//PROCC PROC PARM1=POSITIONAL,SOMEDATA=SOMETHING
//STEPC EXEC PGM=MYPGM
//OUTDSC OUTPUT USERDATA=(&PARM1,
// SOMEKEY-&SOMEDATA)

In this example, the USERDATA keyword contains two parameter values. If the
installation allows a format of keyword-value, where the hyphen (-) is interpreted as
an equal sign (=), then the parameter values do not need to be enclosed within
apostrophes. Symbolic substitution of the parameter values is more straightforward.
v The first parameter value contains a string that could be used to identify an
installation defined parameter value that is defined as a symbolic parameter. The
procedure default for the value is taken from the PROC statement
(POSITIONAL).
v The second parameter value contains a string that could be used to identify an
installation defined keyword (SOMEKEY), the hyphen is considered an equal sign
(by the installation), and the parameter value that is defined as a symbolic
parameter. The procedure default for the value is taken from the PROC
statement (SOMETHING).

Example 8
//PROCD PROC PARM1=POSITIONAL,SOMEDATA=SOMETHING
//STEPD EXEC PGM=MYPGM
//OUTDSD OUTPUT USERDATA=(’&PARM1’,
// ’SOMEKEY-&SOMEDATA’)

In this example, the USERDATA keyword contains two parameter values. If the
installation allows a format where an installation-defined keyword=value format
requires the entire parameter value to be enclosed within apostrophes, symbolic
substitution of the parameter values is less straightforward than in the previous
example.
v The first parameter value contains a string within the apostrophes that could be
used to identify an installation defined parameter value that is defined as a

22-86 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: USERDATA
symbolic parameter. Since the parameter is enclosed within apostrophes, the
&PARM1 symbolic is not resolved so the parameter value is left unchanged
(&PARM1).
v The second parameter value contains a string that could be used to identify an
installation defined keyword (SOMEKEY), and the parameter value that is defined
as a symbolic parameter. However, since the entire parameter is enclosed within
apostrophes, the &SOMEDATA symbolic is not resolved so the entire parameter
is left unchanged (SOMEKEY=&SOMEDATA).

USERLIB Parameter
Parameter Type

Keyword, optional

Purpose

Use the USERLIB parameter to identify libraries containing AFP resources to be

used by Print Services Facility (PSF) when processing sysout data sets. The
system searches libraries specified on the USERLIB parameter before using any
system-defined resources. The resources specify how PSF is to print the sysout
data set. They include:
v Fonts
v Page segments
v Overlays
v Page definitions
To have PSF search the libraries specified on the USERLIB parameter for page
definitions, you must code the membername on the PAGEDEF parameter of the
OUTPUT JCL statement. If you do not code the PAGEDEF parameter, the
system searches the system libraries.
v Form definitions
To have PSF search the libraries specified on the USERLIB parameter for form
definitions, you must code the membername on the FORMDEF parameter of the
OUTPUT JCL statement. If you do not code the FORMDEF parameter, the
system searches the system libraries.

Syntax
USERLIB={data-set-name }
{(data-set-name1,data-set-name2,...data-set-name8)}

v You can omit the parentheses if you code only one data set name.
v If you code more than one data set name, each data set name may be enclosed in
apostrophes. However, apostrophes around each data set name are not required.

Subparameter Definitions
data-set-name
Specifies from 1 to 8 library data set names containing AFP resources. The
data set name must be a cataloged MVS data set. The library can contain any
AFP resources. The libraries are searched in the order in which they are
specified on the USERLIB statement.

Chapter 22. OUTPUT JCL Statement 22-87

OUTPUT JCL: USERLIB
Defaults
If you do not code USERLIB, only the system and installation print resources are
available. These resources include those available in the system libraries, and
those specified inline in the print data set.

Overrides
PSF obtains the system and installation resources in the following order:
1. Inline print data set resources
2. Libraries specified on the USERLIB statement
3. System libraries

Requirements for USERLIB Libraries

Data sets specified by USERLIB are concatenated to the system resource libraries,
and are checked before the system libraries for requested resources. Unique
member names should be defined for concatenated libraries. If the member names
are not unique, the system uses the first member that it encounters.

Examples of the USERLIB Parameter

Example 1
//OUT1 OUTPUT PAGEDEF=STNDRD,FORMDEF=CENTER,
// USERLIB=(USER.PRIVATE.RESOURCE,GROUP.PRIVATE.RESOURCE)

In this example, PSF is to print the sysout data set using PAGEDEF=STNDRD and
FORMDEF=CENTER.

When processing the sysout data set, PSF will search the user libraries before
searching the system libraries for the specified PAGEDEF and FORMDEF. When
searching the user libraries, PSF will search USER.PRIVATE.RESOURCE before
searching GROUP.PRIVATE.RESOURCE.

Example 2
//OUT1 OUTPUT PAGEDEF=STNDRD,FORMDEF=CENTER,
// USERLIB=(’USER.PRIVATE.RESOURCE’,’GROUP.PRIVATE.RESOURCE’)

You may code apostrophes around the data set names, but apostrophes are not
required. The system will process this example the same way it processes Example
1.

WRITER Parameter
Parameter Type

Keyword, optional

Purpose

Use the WRITER parameter to name an external writer to process the sysout data
set rather than JES. An external writer is an IBM- or installation-written program.

References

For information about external writers, see z/OS JES2 Initialization and Tuning
Guide or z/OS JES3 Initialization and Tuning Guide.

22-88 z/OS V1R3.0 MVS JCL Reference

 OUTPUT JCL: WRITER
Syntax
WRITER=name

Subparameter Definition
name
Identifies the member name (1 to 8 alphanumeric characters) of an
installation-written program in the system library that the external writer loads to
write the output data set.
Do not code INTRDR or STDWTR (and for JES3, NJERDR) as the writer name.
These names are reserved for JES.

Defaults
If you do not code the WRITER parameter, the installation’s job entry subsystem
processes the sysout data set.

Overrides
The writer-name subparameter of the SYSOUT parameter on the sysout DD
statement overrides the OUTPUT JCL WRITER parameter.

Relationship to Other Parameters

For JES3, you can code the OUTPUT JCL DEST=nodename parameter with the
WRITER=name parameter; however, do not code DEST=nodename.userid with
WRITER=name.

Starting an External Writer

When a statement supplying processing options for a sysout data set specifies an
external writer, the writer must be started before it can print or punch the data set.
The writer is started by a system command from the operator or in the input stream.
If the writer is not started before the job produces the sysout data set, the data set
is retained until the writer is started.

Examples of the WRITER Parameter

Example 1
//MYOUT JOB ACCT928,MAEBIRD,MSGCLASS=B
// START XWTR
//MYDS OUTPUT WRITER=MYPGM
//STEP1 EXEC PGM=REPORT
//RPT1 DD SYSOUT=A,OUTPUT=*.MYDS

The second statement is a JCL command statement to start the IBM-supplied

external writer. This writer is a cataloged procedure in SYS1.PROCLIB. The sysout
DD statement RPT1 explicitly references OUTPUT JCL statement MYDS, which
specifies that the program MYPGM is to be loaded by XWTR and process the
sysout data set.

Example 2 (for a JES3 system)

//**START XWTR
//MYOUT JOB ACCT928,MAEBIRD,MSGCLASS=B
//MYDS OUTPUT WRITER=MYPGM
//STEP1 EXEC PGM=REPORT
//RPT1 DD SYSOUT=A,OUTPUT=*.MYDS

Chapter 22. OUTPUT JCL Statement 22-89

OUTPUT JCL: WRITER

22-90 z/OS V1R3.0 MVS JCL Reference

 Chapter 23. PEND Statement
Purpose

Use the PEND statement to mark the end of an in-stream procedure. You may end
a cataloged procedure with a PEND statement, but it is not required.

Description

Syntax

//[name] PEND [comments]

The PEND statement consists of the characters // in columns 1 and 2 and three fields:
name, operation (PEND), and comments. Do not continue a PEND statement.

Name Field
A name is optional on the PEND statement. If used, code it as follows:
v The name must begin in column 3.
v The name is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The name must be followed by at least one blank.
| v The name may be preceded by up to 8 alphanumeric or national characters, and
| then separated by a period. Coding the name in this way should not be confused
| with specifying an override, as can be done when coding DD statements.

If a name is not coded, column 3 must be blank.

Operation Field
The operation field consists of the characters PEND and must be preceded and
followed by at least one blank. It can begin in any column.

Comments Field
The comments field follows PEND after at least one intervening blank.

Location in the JCL

A PEND statement follows the statements of an in-stream procedure, and may
follow the statements of a cataloged procedure.

Examples of the PEND Statement

Example 1
//PROCEND1 PEND THIS STATEMENT IS REQUIRED FOR IN-STREAM PROCEDURES

This PEND statement contains a comment.

Example 2
// PEND

© Copyright IBM Corp. 1988, 2002 23-1

PEND
This PEND statement contains only // and the operation field with the necessary
blanks.

23-2 z/OS V1R3.0 MVS JCL Reference

Chapter 24. PROC Statement
Purpose

The PROC statement marks the beginning of a procedure. The PROC statement
can assign default values to symbolic parameters, if coded, in the procedure.

Description

Syntax

For a cataloged procedure:

//[name] PROC [parameter [comments]]
//[name] PROC

For an in-stream procedure:

//name PROC [parameter [comments]]
//name PROC

A PROC statement consists of the characters // in columns 1 and 2 and four fields: name,
operation (PROC), parameter, and comments.

Multiple Parameters: When more than one parameter is coded, separate parameters by
commas. For example, //P1 PROC PARM1=OLD,PARM2=222001.

Special Characters: When a parameter value contains special characters, enclose the
value in apostrophes. The enclosing apostrophes are not considered part of the value. For
example, //P2 PROC PARM3='3400-6'.

Code each apostrophe that is part of a value as two consecutive apostrophes. For example,
//P3 PROC PARM4=‘O’‘DAY’.

However, if the symbolic parameter is enclosed within a matched pair of parentheses, you
do not need to enclose the parentheses in apostrophes.

Continuation onto Another Statement: End each statement with a comma after a
complete parameter. For example:
//P4 PROC PARM5=OLD,PARM6=’SYS1.LINKLIB(P40)’,
// PARM7=SYSDA,PARM8=(CYL,(10,1))

Name Field
A name is required on a PROC statement in an in-stream procedure and is optional
on a PROC statement in a cataloged procedure. Code it as follows:
v When coded for an in-stream procedure, each name must be unique within the
job. When coded for a cataloged procedure, the name need not be unique.
v The name must begin in column 3.
v The name is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The name must be followed by at least one blank.

If a name is not coded, column 3 must be blank.

© Copyright IBM Corp. 1988, 2002 24-1

PROC
Operation Field
The operation field consists of the characters PROC and must be preceded and
followed by at least one blank. It can begin in any column.

Parameter Field
The parameters on a PROC statement assign default values to symbolic
parameters on procedure statements. An in-stream PROC statement requires
parameters only if the procedure contains symbolic parameters. See “Using System
Symbols and JCL Symbols” on page 5-12 for details on symbolic parameters and
on how to assign values to them.

If coded, the parameter field must be preceded and followed by at least one blank.

Comments Field
The comments field follows the parameter field after at least one intervening blank.
Do not code comments unless you code the parameter field.

Overrides
To override a default parameter value on a PROC statement, code the same
parameter on the EXEC statement that calls the procedure.

Location in the JCL

A PROC statement must be the first statement in a procedure. An in-stream
procedure must appear in the same job before the EXEC statement that calls it. A
cataloged procedure appears in a procedure library, usually SYS1.PROCLIB.

Examples of the PROC Statement

Example 1
//DEF PROC STATUS=OLD,LIBRARY=SYSLIB,NUMBER=777777
//NOTIFY EXEC PGM=ACCUM
//DD1 DD DSNAME=MGMT,DISP=(&STATUS,KEEP),UNIT=3400-6,
// VOLUME=SER=888888
//DD2 DD DSNAME=&LIBRARY,DISP=(OLD,KEEP),UNIT=3350,
// VOLUME=SER=&NUMBER

Three symbolic parameters are defined in this cataloged procedure: &STATUS,

&LIBRARY, and &NUMBER. Values are assigned to the symbolic parameters on the
PROC statement. These values are used when the procedure is called and values
are not assigned to the symbolic parameters on the calling EXEC statement.

Example 2
//CARDS PROC

This PROC statement can be used to mark the beginning of an in-stream procedure
named CARDS.

24-2 z/OS V1R3.0 MVS JCL Reference

Chapter 25. SET Statement
Purpose

Use the SET statement to:

v Define and assign initial values to symbolic parameters that are to be used when
processing JCL statements.
v Change or nullify the values of defined symbolic parameters (those that are
defined on previous SET statements) by assigning new values or nullifying
current values.

The values that you assign to symbolic parameters on a SET statement are used in
v Subsequent JCL statements in the JCL stream, and
v Statements in subsequent procedures and nested procedures, when you:
– Do not assign the values for the symbolic parameters on any PROC
statements, or on any EXEC statements that call the procedures
– Do not nullify the values for the symbolic parameters on any PROC
statements, or on any EXEC statements that call the procedures.

Symbolic parameter values that are assigned or nullified by calling EXEC or PROC
statements override the values you assign or nullify with the SET statement.

The rules for symbolic parameters apply to the symbolic parameters you specify on
the SET statement. See the topics “Using System Symbols and JCL Symbols” on
page 5-12 and “Using Symbols in Nested Procedures” on page 5-26.

See also the EXEC and PROC statements, which also define and assign values to
symbolic parameters.

Description

Syntax

//[name] SET symbolic-parameter=value

// [,symbolic-parameter=value]... [comments]

© Copyright IBM Corp. 1988, 2002 25-1

SET
The SET statement consists of the characters // in columns 1 and 2 and four fields: name,
operation (SET), parameter(s), and comments.

Multiple Parameters: When more than one parameter is coded, separate parameters by
commas. For example:
//SP1 SET PARM1=OLD,PARM2=222001

Special Characters and Blanks: When a parameter value contains special characters or
blanks, enclose the value in apostrophes. The enclosing apostrophes are not considered
part of the value. For example:
//SP2 SET PARM3=’3400-6’

Code each apostrophe that is part of a value as two consecutive apostrophes. For example:
//SP3 SET PARM4=’O’’DAY’

However, if the symbolic parameter is enclosed within a matched pair of parentheses, you
do not need to enclose the parentheses in apostrophes. For example:
//SET1 SET DSP=(NEW,KEEP)

Continuation onto Another Statement: End each statement with a comma after a
complete parameter and continue the parameter field on the next statement between
columns 4 and 16. For example:
//SP4 SET PARM5=OLD,PARM6=’SYS1.LINKLIB(P40)’,
// PARM7=SYSDA,PARM8=’(CYL,(10,1))’

Name Field
A name is optional on a SET statement. If used, code it as follows:
v The name should be unique within the job.
v The name must begin in column 3.
v The name is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The name must be followed by at least one blank.

If a name is not coded, column 3 must be blank.

Operation Field
The operation field consists of the characters SET and must be preceded and
followed by at least one blank. It can begin in any column.

Parameter Field
The SET statement contains one or more parameters:
symbolic-parameter=value[,symbolic parameter=value]...
Defines a symbolic parameter and specifies the initial value to be assigned to
the symbolic parameter appearing in subsequent JCL statements. Separate
each assignment of a value to a symbolic parameter by commas.
To nullify a symbolic parameter, specify:
symbolic-parameter=

Comments Field
The comments field follows the parameter field after at least one intervening blank.

25-2 z/OS V1R3.0 MVS JCL Reference

 SET
Overrides
A value you assign to a symbolic parameter on a SET statement is overridden by:
v A subsequent SET statement
v Any default value assigned or nullified on a subsequent PROC statement for a
procedure
v Any value assigned or nullified on a subsequent EXEC statement that calls a
procedure.

When the target of an MVS START command contains a JOB statement, and the
MVS START command specifies symbolic parameters, the system inserts a SET
statement into the job to define those symbolic values. In contrast to the normal
behavior of SET statements, values defined on this SET statement override:
v Other SET statements that occur before the first IF or EXEC statement in the job
v An EXEC statement that invokes an outer (non-nested) procedure
v A PROC statement in an outer procedure.

See “Defining and Nullifying JCL Symbols” on page 5-13 and “Using Symbols in
Nested Procedures” on page 5-26 for the complete set of rules for assigning values
to symbolic parameters.

Location in the JCL

A SET statement can appear anywhere in the job after the JOB statement. The SET
statement must follow a complete JCL statement, and it cannot appear within a
concatenated DD statement.

Place a SET statement in the job’s JCL before the intended use of the symbolic
parameter.

Relationship to Other Control Statements

Symbolic parameters are also assigned values or nullified on PROC statements and
EXEC statements that call procedures.

Considerations for Using the SET Statement

v The symbolic parameters you define on the SET statement are assigned the
specified values at the location in which the SET statement is encountered in
processing the JCL.
If you use SET to define a value for a symbolic parameter that does not appear
in the JCL, the system does not issue message IEFC657I, and there is no JCL
error.
v The SET statement is not executed conditionally. For example, if the SET
statement appears in an IF/THEN/ELSE/ENDIF statement construct, the value is
assigned to the symbolic parameter regardless of the logic of the construct.

Examples of the SET Statement

Example 1

The symbolic parameter DSP is defined and initialized to the value NEW.
//SET1 SET DSP=NEW

DSP is referenced by coding &DSP in the JCL, for example:

Chapter 25. SET Statement 25-3

SET
.
.
//DD1 DD DSNAME=ALPHA.PGM1,DISP=(&DSP,KEEP)

In the example, &DSP is assigned the value NEW for execution:

//DD1 DD DSNAME=ALPHA.PGM1,DISP=(NEW,KEEP)

Example 2

The symbolic parameter DSP is defined and initialized to the value

(NEW,DELETE,KEEP).
//SETA SET DSP=(NEW,DELETE,KEEP)

DSP is referenced by coding &DSP in the JCL, for example:

//PR2 PROC DSP=(NEW,KEEP)
.
.
//DD6 DD DSNAME=ALPHA.PGM2,DISP=&DSP

&DSP is assigned the value (NEW,KEEP) from PROC statement PR2 for execution:
//DD6 DD DSNAME=ALPHA.PGM2,DISP=(NEW,KEEP)

In the example, the definition of DSP on SET statement SETA does not override
the default definition of DSP on PROC statement PR2.

Example 3

This example shows the SET statement spanning two records. The symbolic
parameters are defined and initialized to the values shown on SET statement
SETB. They are referenced by coding &AA, &BB, and &CC in the JCL, for example:
//SETB SET AA=BETA.PGM.RATE,BB=DCLAS03,
// CC=(NEW,KEEP)
.
.
//PR3 PROC ...
//S3 EXEC PGM=...
//DD7 DD DSNAME=&AA,DATACLAS=&BB,DISP=&CC
.
// PEND
.
//S1 EXEC PROC=PR3,BB=DCLAS0X
.

In the example, the values assigned on DD statement DD7 for execution are:
//DD7 DD DSNAME=BETA.PGM.RATE,DATACLAS=DCLAS0X,DISP=(NEW,KEEP)

The values defined for the symbolic parameters on SET statement SETB are
assigned to the AA and CC symbolic parameters in procedure PR3 for execution.
However, the value defined for symbolic parameter BB on EXEC statement S1
overrides the value defined on SET statement SETB.

Example 4

The following example shows the use of the SET statement assigning values to
symbolic parameters in an INCLUDE group.
//* THIS INCLUDE GROUP IS CATALOGED AS...
//* PUCHKOFF.SYSOUT.JCL(SYSOUT2)
//SYSOUT2 DD SYSOUT=A

25-4 z/OS V1R3.0 MVS JCL Reference

 SET
//OUT1 OUTPUT DEST=POK,COPIES=3
//OUT2 OUTPUT DEST=&AA,COPIES=&NC
//OUT3 OUTPUT DEST=&BB,COPIES=10
//* END OF INCLUDE GROUP...
//* PUCHKOFF.SYSOUT.JCL(SYSOUT2)

The following program is executed.

//TESTJOB JOB ...
//LIBSRCH JCLLIB ORDER=PUCHKOFF.SYSOUT.JCL
//SET1 SET AA=KINGSTON,BB=STL,NC=10
//STEP1 EXEC PGM=OUTRTN
//OUTPUT1 INCLUDE MEMBER=SYSOUT2
//STEP2 EXEC PGM=IEFBR14

The SET statement, which can be easily changed for different jobs, assigns values
to the symbolic parameters in INCLUDE group SYSOUT2.

After the INCLUDE statement is processed, the JCL stream would be executed as:
//TESTJOB JOB ...
//LIBSRCH JCLLIB ORDER=PUCHKOFF.SYSOUT.JCL
//STEP1 EXEC PGM=OUTRTN
//* THIS INCLUDE GROUP IS CATALOGED AS...
//* PUCHKOFF.SYSOUT.JCL(SYSOUT2)
//SYSOUT2 DD SYSOUT=A
//OUT1 OUTPUT DEST=POK,COPIES=3
//OUT2 OUTPUT DEST=KINGSTON,COPIES=10
//OUT3 OUTPUT DEST=STL,COPIES=10
//* END OF INCLUDE GROUP...
//* PUCHKOFF.SYSOUT.JCL(SYSOUT2)
//STEP2 EXEC PGM=IEFBR14

The INCLUDE group has been imbedded in the JCL stream (replacing the
INCLUDE statement) and values assigned to the symbolic parameters in the
INCLUDE group.

Chapter 25. SET Statement 25-5

25-6 z/OS V1R3.0 MVS JCL Reference
Chapter 26. XMIT JCL Statement
Support for the XMIT JCL Statement
v The XMIT JCL statement has no function in an APPC scheduling environment. If
you code XMIT, the system will check it for syntax and ignore it.
v The XMIT JCL statement is supported only on JES3 systems.
v For JES2, the XMIT JCL statement is not supported. Use the JES2 /*XMIT
statement to transmit records.

Purpose

Use the XMIT JCL statement to transmit records from an MVS JES3 node to a
JES3 node, a JES2 node, a VSE/POWER node, or a VM/RSCS node.

The sending system does not process or check the records for validity except when
the JCL is processed by an internal reader (such as with TSO/E submit processing).
In this case, the system recognizes /*EOF and /*DEL as internal reader control
statements and errors can occur on the sending system if /*EOF or /*DEL are
included in the XMIT JCL stream.

To transmit /*EOF and /*DEL statements as part of the XMIT JCL stream, replace /*
with two substitute characters and identify the substitute characters on the
SUBCHARS parameter. Prior to transmission, the sending system converts the two
substitute characters to /*. The receiving (execution) system can then process the
/*EOF and /*DEL statements as internal reader control statements.

Do not nest XMIT JCL statements. That is, do not include an XMIT JCL statement
between an XMIT JCL statement and its delimiter.

The system builds network job header and trailer records from information on the
JOB statement and any //*NETACCT statements, if included, preceding the XMIT
JCL statement. Then the system transmits all the records between the XMIT JCL
statement and a delimiter statement.

The records can consist of a job input stream, an in-stream DD * or DD DATA data
set, or any job definition statements recognized by the destination node. If the
records are a job input stream, and the destination node can process the JCL, the
transmitted input stream is executed at the destination node. The records must be
80 characters long.

The records end when the system finds one of the following delimiters:
v /* in the input stream, if a DLM parameter is not coded on this XMIT JCL
statement. (Refer to Chapter 12. Delimiter Statement for an explanation of /*.)
From TSO/E only, TSO/E inserts /* at the end-of-file if the default delimiter is not
supplied.
v The two-character delimiter specified by a DLM parameter on this XMIT JCL
statement.

© Copyright IBM Corp. 1988, 2002 26-1

XMIT JCL

Description

Syntax

//[name] XMIT parameter[,parameter]... [comments]

The XMIT JCL statement consists of the characters // in columns 1 and 2 and four fields:
name, operation (XMIT), parameter, and comments.

Name Field
A name is optional on the XMIT JCL statement. If used, code it as follows:
v Each name must be unique within the job.
v The name must begin in column 3.
v The name is 1 through 8 alphanumeric or national ($, #, @) characters.
v The first character must be alphabetic or national ($, #, @).
v The name must be followed by at least one blank.

Operation Field
The operation field consists of the characters XMIT and must be preceded and
followed by at least one blank. It can begin in any column.

Parameter Field
The XMIT JCL statement contains only keyword parameters. A DEST parameter is
required; the DLM and SUBCHARS parameters are optional. If your JCL is to be
processed by an internal reader and /*EOF or /*DEL is part of the XMIT JCL
stream, you must code the SUBCHARS parameter.

You can code the keyword parameters in any order in the parameter field.

KEYWORD PARAMETERS VALUES PURPOSE

DEST=nodename[.vmuserid] nodename: 1 - 8 alphanumeric or $, Identifies the destination

#, @ characters for all following records
See page 26-4 until a delimiter stops
vmuserid: 1 - 8 alphanumeric or $, #, transmission of the
@ characters records.

DLM=delimiter delimiter: 2 alphanumeric, $, #, @, or Specifies a delimiter to

special characters stop the transmission of
See page 26-5 records.

SUBCHARS=substitute substitute: 2 alphanumeric, $, #, @, Specifies a substitute for

or special characters internal reader control
See page 26-6 statements.

Comments Field
The comments field follows the parameter field after at least one intervening blank.

Location in the JCL

Place the XMIT JCL statement after a JOB statement and any //*NETACCT
statements. (Other JES3 JCL statements between the JOB and XMIT JCL

26-2 z/OS V1R3.0 MVS JCL Reference

 XMIT JCL
statements are not supported and can cause unpredictable results.) The JOB
statement must be valid for the submitting location.

Do not place any other MVS JCL statements between the JOB statement and the
XMIT JCL statement. If any of these statements intervene, the system terminates
the job.

Error on XMIT JCL Statement

If the system finds an error on the XMIT JCL statement before a specified DLM
parameter, all jobs in the batch are flushed.

If the system finds an error on the XMIT JCL statement after a specified DLM
parameter, the network job is flushed and local processing starts at the statement
following the specified delimiter.

Examples of the XMIT JCL Statement

Example 1
//JOBA JOB 25FA64,’KEN KAHN’
//X1 XMIT DEST=KGNMVS45
.
.
(records to be transmitted)
.
/*
//JOBB JOB ...
.

In this example, the records between the XMIT JCL statement and the delimiter
statement (/* in columns 1 and 2) are transmitted to the node named KGNMVS45.

Example 2
//JOBC JOB PW19,’DEPT 53’
//X2 XMIT DEST=POKVMDD3.MVSGST34,DLM=AA
.
.
/*
(records to be transmitted)
/*EOF
/*DEL
.
.
AA
//JOBB JOB ...
.

In this example, processing is not through an internal reader on the sending

system. The records between the XMIT JCL statement and the delimiter statement,
which must contain AA in columns 1 and 2 as specified in the DLM parameter, are
transmitted to the system, MVSGST34, running on the VM system at the node
named POKVMDD3.

Example 3
//JOBE JOB NS37,’NYC BX’
//X3 XMIT DEST=SANFRAN,DLM=AA,SUBCHARS=’/+’
.
.
(records to be transmitted)
.
.

Chapter 26. XMIT JCL Statement 26-3

XMIT JCL
/+EOF
.
.
/+DEL
AA
//JOBF JOB ...
.

In this example, the JCL is processed through an internal reader on the sending
system. The records between the XMIT JCL statement and the delimiter statement,
which must contain AA in columns 1 and 2 as specified in the DLM parameter, are
transmitted to the node named SANFRAN.

To transmit the /*EOF and /*DEL internal reader control statements, /* is replaced
by /+ in columns 1 and 2 on both statements in the XMIT JCL stream and
SUBCHARS=‘/+’ is coded on the XMIT statement. The sending system does not
recognize /+EOF and /+DEL as internal reader statements. Then prior to
transmission, the sending system converts /+ to /* and sends /*EOF and /*DEL to
the receiving node, which can then process the internal reader control statements.

DEST Parameter
Parameter Type

Keyword, required

Purpose

Use the DEST parameter to specify a destination for the following input stream
records. The DEST parameter can send the records to a node or, for a node that is
a VM system, to a guest system running on the virtual machine.

Syntax

DEST=nodename

DEST=nodename.vmuserid

Subparameter Definition
nodename
Identifies the destination node. The nodename identifies a JES2 system, a
JES3 system, a VSE/POWER node, or a VM system. The nodename is 1
through 8 alphanumeric or national ($, #, @) characters specified during JES
initialization. If the requested node is the same as the submitting node, the
records following the XMIT JCL statement are processed by the local system.
userid
Identifies a destination guest system. The userid is 1 through 8 alphanumeric or
national ($, #, @) characters.

Examples of the DEST Parameter

Example 1
//TRANS XMIT DEST=LAXSYS

26-4 z/OS V1R3.0 MVS JCL Reference

 XMIT JCL: DEST
This example sends the following records to a node named LAXSYS.

Example 2
//SEND XMIT DEST=VMSYS3.GUEST7

This example sends the following records to a guest system, named GUEST7,
running in the VM system at the node named VMSYS3.

DLM Parameter
Parameter Type

Keyword, optional

Purpose

Use the DLM parameter to specify a delimiter to stop transmission of input stream
records. When the DLM parameter assigns a delimiter other than the standard
delimiter (/* in columns 1 and 2), the records can include the standard delimiter.

If you use the DLM delimiter to define a delimiter, be sure to terminate the records
with the specified DLM characters. Otherwise, all jobs between the XMIT JCL
statement and the end-of-file will be transmitted, and processed at the node to
which they are sent.

From TSO/E only, TSO/E inserts /* at the end-of-file if the default delimiter is not
supplied.

Syntax

DLM=delimiter

v If the specified delimiter contains any special characters, enclose the delimiter in
apostrophes. In this case, a special character is any character that is neither
alphanumeric nor national ($, #, @).
v If the delimiter contains an ampersand or an apostrophe, code each ampersand or
apostrophe as two consecutive ampersands or apostrophes and enclose the delimiter in
apostrophes. Each pair of consecutive ampersands or apostrophes counts as one
character.

Subparameter Definition
delimiter
Specifies two characters that indicate the end of this data set in the input
stream.

Default
If you do not specify a DLM parameter, the default is the standard /* delimiter
statement.

Invalid Delimiters
If the delimiter is not two characters, the system terminates the job and does not
transmit any records.

Chapter 26. XMIT JCL Statement 26-5

XMIT JCL: DLM
Examples of the DLM Parameter
Example 1
//XX XMIT DEST=NYCNODE,DLM=AA
.
.
(records to be transmitted)
.
AA

The DLM parameter assigns the characters AA as the delimiter for the in-stream
records to be transmitted.

Example 2
//XY XMIT DEST=ATL,DLM=’A+’
//XZ XMIT DEST=BOST,DLM=’&&7’
//XW XMIT DEST=CHI,DLM=’B’’’

These examples specify delimiters of A+, &7, and B'.

SUBCHARS Parameter
Parameter Type

Keyword, optional

Purpose

Use the SUBCHARS parameter to specify a substitute (consisting of two

characters) for the first two characters of /*EOF and /*DEL internal reader control
statements. The substitute characters on the internal reader control statements
must be in columns 1 and 2.

You can use the SUBCHARS parameter for any XMIT JCL job. However,
SUBCHARS is required if you want to transmit internal reader control statements
(/*EOF and /*DEL) and the job is processed by an internal reader on the sending
system. Note that the system recognizes /*EOF and /*DEL as internal reader control
statements and errors can occur on the sending system if /*EOF or /*DEL are
included in the XMIT JCL stream.

To transmit internal reader control statements, replace /* on the /*EOF and /*DEL
statements in the records to be transmitted with two substitute characters and
identify the substitute characters on the SUBCHARS parameter. Prior to
transmission, the system converts the substitute characters to /* and sends /*EOF
and /*DEL to the receiving node for processing.

Reference

The internal reader is described in z/OS MVS Programming: Assembler Services

Guide.

Syntax

SUBCHARS=substitute

26-6 z/OS V1R3.0 MVS JCL Reference

 XMIT JCL: SUBCHARS

v If the specified substitute contains any special characters, enclose the substitute in
apostrophes. In this case, a special character is any character that is neither
alphanumeric nor national ($, #, @).
v If the substitute contains an ampersand or an apostrophe, code each ampersand or
apostrophe as two consecutive ampersands or apostrophes and enclose the substitute in
apostrophes. Each pair of consecutive ampersands or apostrophes counts as one
character.

Subparameter Definition
substitute
Specifies two characters that indicate the substitute characters for the first two
characters of internal reader control statements. The substitute characters apply
only to internal reader statements.

Default
There is no default for SUBCHARS.

Invalid Substitute
If the substitute is not two characters, the system terminates the job and does not
transmit any records.

Examples of the SUBCHARS Parameter

Example 1
//XX XMIT DEST=NYCNODE,SUBCHARS=MV
.
.
(records to be transmitted)
MVEOF
.

The SUBCHARS parameter identifies the characters MV as the substitute for the
first two characters of the internal reader control statement to be transmitted. Prior
to transmission, the system converts the MV substitute characters to /* and sends
/*EOF to the receiving node for processing.

Example 2
//XY XMIT DEST=ATL,SUBCHARS=’A+’
//XZ XMIT DEST=BOST,SUBCHARS=’&&7’
//XW XMIT DEST=CHI,SUBCHARS=’B’’’

These examples specify substitutes of A+, &7, and B'.

Chapter 26. XMIT JCL Statement 26-7

26-8 z/OS V1R3.0 MVS JCL Reference
Chapter 27. JES2 Control Statements
Code JES2 control statements with JCL statements to control the input and output
processing of jobs. The rules for coding in Chapter 3, “Format of Statements”, and
Chapter 4, “Syntax of Parameters”, apply to the JES2 control statements.

Description

Considerations for Started Tasks

The following statements are not supported for a started task:
v /*PRIORITY
v /*ROUTE XEQ
v /*SETUP
v /*XEQ
v /*XMIT
v /*$xxx

The /*PRIORITY statement is ignored. All other statements cause JES2 to fail the
job.

Considerations for an APPC Scheduling Environment

JES2 control statements have no function in an APPC scheduling environment. If
you code them, the system will detect them as JCL errors.

Location in the JCL

Place JES2 control statements, except the command and /*PRIORITY statements,
after the JOB statement and its continuations. JES2 ignores JES2 control
statements, except the command and /*PRIORITY statements, that appear before
the JOB statement or between continued JOB statements.

Do not include JES2 control statements in a cataloged or in-stream procedure.

JES2 ignores JES2 control statements in a procedure.

Internal Reader
Use the following control statements when submitting jobs to the internal reader.
The internal reader is described in z/OS MVS Programming: Assembler Services
Guide.
/*DEL
/*EOF
/*PURGE
/*SCAN

JES2 Command Statement

Purpose

Use the command statement to enter a JES2 operator command through the input
stream, the internal reader, or the system console.

Note: Do not specify this statement for a started task; if /*$xxx is specified, JES2
fails the job.

© Copyright IBM Corp. 1988, 2002 27-1

JES2: Command
JES2 usually executes an in-stream command as soon as it is read. Therefore, the
command will not be synchronized with the execution of any job or step in the input
stream. To synchronize a command with the job processing, tell the operator the
commands you want and when they should be issued, and let the operator enter
them from the console.

Examples in this book illustrate the format for commands entered through the input
stream. Commands entered through an operator console should not have /* in
columns 1 and 2.

References

For more information on the command statement and the JES2 verbs and
operands, see z/OS JES2 Commands.

Syntax
/*$command-verb,operand[,operand]... [N]

The JES2 command statement consists of:

v The characters /* in columns 1 and 2.
v $ or a character chosen by the installation in column 3. For more information, see JES2
initialization statement CONDEF, RDRCHAR=.
v The command verb beginning in column 4.
v A comma.
v Operands up through column 71.
v N in column 72 if JES2 is not to write the command on the operator console.
v Blanks in columns 73 through 80. JES2 ignores these columns.

Do not continue command statements from one statement to the next, instead code as
many command statements as you need.

Parameter Definition
command-verb
Specifies the operator command that JES2 is to perform. You can enter the
following JES2 commands in the input stream.

$A $E $I $O $T
$B $F $L $P $TRACE
$C $G $M $R $VS
$D $H $N $S $Z

operand
Specifies options for the command.
N in column 72
Indicates that JES2 is not to repeat the command on the operator console.

Location in the JCL

Place JES2 command statements before jobs being entered through the input
stream. JES2 ignores any JES2 command statements within a job.

Do not code JES2 commands in an NJE job stream. If you code JES2 commands
in an NJE job stream, the system will not process them and will issue an error
message.

27-2 z/OS V1R3.0 MVS JCL Reference

 JES2: Command
If a job contains a JES2 /*XMIT statement, and you want JES2 to process and
display the command at the input node only, place the command statement before
the /*XMIT statement.

Examples of the Command Statement

Example 1
/*$SI3-5

This command statement starts initiators three through five. The command is $S
and the operand is I3-5. JES2 executes the command immediately and repeats the
command on the operator console.

Example 2
/*$TRDR1,H=Y

In response to this command, JES2 places all jobs being read by reader 1 in a hold
status. If a job contains a JES2 /*ROUTE XEQ or /*XEQ statement that specifies an
execution node different from the input node, JES2 holds the job at the execution
node, not the input node.

/*JOBPARM Statement
Purpose

Use the /*JOBPARM statement to specify job-related parameters for JES2.

Note: For started tasks:

v The TIME parameter is ignored
v If RESTART=N, the parameter is ignored
v If RESTART=Y, JES2 fails the job
v For SYSAFF, the system on which the job is being started must be in the list of
systems implied or specified, or JES2 will fail the job.

Chapter 27. JES2 Control Statements 27-3

JES2: /*JOBPARM
Syntax
/*JOBPARM parameter[,parameter]...

The parameters are:

{BURST} = {Y}
{B } {N}

{BYTES} = nnnnnn
{M }

{CARDS} = nnnnnnnn
{C }

{COPIES} = nnn
{N }

{FORMS} = {xxxxxxxx}
{F } {STD }

{LINECT} = nnn
{K }

{LINES} = nnnnnn
{L }

{NOLOG}
{J }

{PAGES} = nnnnnnnn
{G }

{PROCLIB} = ddname
{P }

{RESTART} = {Y}
{E } {N}

{ROOM} = xxxx
{R }

{SYSAFF} = {* }
{S } {(*[,IND]) }
{ANY }
{(ANY[,IND]) }
{cccc }
{(cccc[,IND]) }
{(cccc[,cccc]...) }
{((cccc[,cccc]...)[,IND])}

{TIME} = nnnn
{T }
The /*JOBPARM statement consists of the characters /* in columns 1 and 2, JOBPARM in
columns 3 through 9, a blank in column 10, and parameters in columns 11 through 71.
JES2 ignores columns 72 through 80.

Do not continue a /*JOBPARM statement. Instead, code as many /*JOBPARM statements

as necessary in an input stream.

Code any number of the above parameters on a single /*JOBPARM statement.

27-4 z/OS V1R3.0 MVS JCL Reference

 JES2: /*JOBPARM
Parameter Definition
BURST=Y
BURST=N
Specifies the default burst characteristic of all sysout data sets that JES2
produces for this job. BURST applies only when the data set is directed to a
3800 Printing Subsystem equipped with a burster-trimmer-stacker.
Y Requests that the 3800 output is to be burst into separate sheets.
N Requests that the 3800 output is to be in a continuous fanfold.
BYTES=nnnnnn
Specifies the maximum output, in thousands of bytes, the system is to produce
from this job. The nnnnnn is 1 through 6 decimal numbers from 0 through
999999. When nnnnnn bytes are reached, JES2 gives control to an installation
exit routine and the job might or might not be terminated.
CARDS=nnnnnnnn
Specifies the maximum number of output cards to be punched for this job’s
sysout data sets. The value is 1 through 8 decimal numbers from 0 through
99999999. When the specified number of cards is reached, JES2 gives control
to an installation exit routine and the job might or might not be terminated.
COPIES=nnn
Specifies how many copies of the spool lines or bytes for this job’s sysout data
sets are to be printed or punched. The nnn is 1 through 3 decimal numbers
from 1 through 255. An installation can reduce the upper limit of this value
during JES2 initialization.
The COPIES parameter is ignored and only one copy is produced if any of the
following is true:
v FREE=CLOSE is coded on the DD statement for the output data set.
v HOLD=YES is coded on any sysout DD statement in the job.
v The output class of the sysout data set is a held class, and the message
class is also a held class. The message class is specified in the JOB
statement MSGCLASS parameter.
FORMS=xxxxxxxx
FORMS=STD
Specifies the print and/or punch forms JES2 is to use for sysout data sets for
which FORMS is not specified on the DD statement or on a JES2 /*OUTPUT
statement.
xxxxxxxx
Identifies the print or punch forms. The xxxxxxxx is 1 through 8
alphanumeric or national ($, #, @) characters.
STD
Indicates that JES2 is to use the default specified at JES2 initialization.
LINECT=nnn
Specifies the maximum number of lines that JES2 is to print on each output
page for this job’s sysout data sets. The nnn is 1 through 3 numbers from 0
through 254.
If you code LINECT=0, JES2 does not eject to a new page when the number of
output lines exceeds the page limit that the installation specified during JES2
initialization.

Chapter 27. JES2 Control Statements 27-5

JES2: /*JOBPARM
The LINECT parameter on the /*OUTPUT statement overrides LINECT on the
/*JOBPARM statement and the linect value in the accounting information
parameter of the JOB statement.
LINES=nnnnnn
Specifies the maximum output, in thousands of lines, that JES2 is to place in
the spool data sets for this job’s sysout data sets. The number is 1 through 6
decimal numbers from 0 through 999999. When the specified number of lines is
reached, JES2 gives control to an installation exit routine and the job might or
might not be terminated.
The LINES parameter applies only to line-mode data. (See also the PAGES
parameter.) If the sysout data set contains both line-mode and page-mode data,
the lines and pages are counted separately and checked separately against the
limit.
NOLOG
Requests that JES2 not print the job’s hard-copy log. The job’s hard-copy log
contains the JES2 and operator messages about the job’s processing.
PAGES=nnnnnnnn
Specifies the maximum number of output pages to be printed for this job’s
sysout data sets. The number is 1 through 8 decimal numbers from 0 through
99999999. When the specified number of pages is reached, JES2 gives control
to an installation exit routine and the job might or might not be terminated.
The PAGES parameter applies only to page-mode data. (See also the LINES
parameter.) If the sysout data set contains both page-mode and line-mode data,
the pages and lines are counted separately and checked separately against the
limit.
PROCLIB=ddname
Requests a JES2 procedure library by its ddname, as defined in the JES2
procedure used to initialize JES2. Typically, JES2 procedure library ddnames
are in the format PROCnn, where nn is either 00 or 1 or 2 decimal numbers
from 1 through 99. You can, however, use any valid ddname as long as the
name matches the ddname in the JES2 procedure. The system retrieves called
cataloged procedures from the requested JES2 procedure library.
If you omit the PROCLIB parameter, or the ddname cannot be found in the
procedure used to start JES2, JES2 uses the procedure library specified on the
PROC=nn parameter on one of the following JES2 initialization statements:
v JOBCLASS(v) for each job class
v STCCLASS for all started tasks
v TSUCLASS for all time-sharing tasks

If the PROC=nn parameter is not defined on the appropriate initialization

statement, or if it is not valid, JES2 uses the default library, PROC00. See z/OS
JES2 Initialization and Tuning Guide for information about creating the JES2
cataloged procedure and z/OS JES2 Initialization and Tuning Reference for
information about defining JES2 initialization statements.
RESTART=Y
RESTART=N
Requests one of the following, if this job is executing before a re-IPL and JES2
warm start, and the job cannot restart from a step or checkpoint.
Y Requests that JES2 queue the job for re-execution from the beginning of
the job.
N Requests that JES2 take no special action.

27-6 z/OS V1R3.0 MVS JCL Reference

 JES2: /*JOBPARM
Note: If you do not specify RESTART, JES2 assumes N. However, the
installation may override this default in JES2 initialization parameters.

If the job is registered with the automatic restart manager (ARM) at the time of
the IPL, ARM determines whether the job is restarted, regardless of whether
RESTART=YES or NO is specified.
ROOM=xxxx
Indicates the programmer’s room number. The xxxx is 1 through 4
alphanumeric characters. JES2 places the room number on the job’s separators
so that the installation can deliver the job’s sysout data sets to the programmer.
SYSAFF=*
SYSAFF=(*[,IND])
SYSAFF=ANY
SYSAFF=(ANY[,IND])
SYSAFF=cccc
SYSAFF=(cccc[,IND])
SYSAFF=(cccc[,cccc]...)
SYSAFF=((cccc[,cccc]...)[,IND])
Indicates the systems that are eligible to process the job. The parameter
indicates from 1 through 7 system affinities.

Note:

Use the SYSAFF parameter to ensure the conversion and execution of the job
will be done on a specific system. If you code SYSAFF, both processes are
done on the specified system.

For TSO-submitted jobs that specify NOTIFY in the JOB statement: after a job
has completed execution, JES2 may change the SYSAFF specification for the
job if the job executed on a processor other than the processor that the user is
logged on. This is done by JES2 during output processing to allow NOTIFY
processing to take place on the user’s processor.
* Indicates the system that read the job.
ANY
Indicates any system in the JES2 multi-access spool configuration.
cccc
Identifies a specific system, where cccc is the 1-4 alphanumeric character
system ID of one of the systems in the JES2 multi-access spool
configuration. To specify more than one system, separate the system
identifiers with commas and enclose the system ID list in parentheses; for
example, SYSAFF=(cccc,cccc,cccc). Repeat cccc up to the number of
processors in the configuration.

Note: If you specify SYSAFF=cccc on the /*JOBPARM statement and also

have a /*ROUTE XEQ or /*XEQ statement, the latter statement must
appear before the /*JOBPARM statement.
IND
After any of the other SYSAFF specifications, indicates that JES2 is to use
system scheduling in independent mode. When IND is coded, the
subparameters must be enclosed in parentheses.
TIME=nnnn
Estimates the job execution time, in minutes of real time. The nnnn is 1 through

Chapter 27. JES2 Control Statements 27-7

JES2: /*JOBPARM
4 decimal numbers from 0 through 9999. If you omit a TIME parameter and a
time subparameter in the JOB statement accounting information parameter,
JES2 uses an installation default specified at initialization. If job execution
exceeds the time, JES2 sends a message to the operator.

Overrides
v The /*JOBPARM statement parameters override the installation defaults specified
at JES2 initialization.

Note: The /*JOBPARM statement parameters cannot override JES2 installation

defaults when it is placed in a catalogued procedure for an STC.
v An OUTPUT JCL statement can override parameters on a /*JOBPARM
statement.
v A JES2 /*OUTPUT statement can override parameters on a /*JOBPARM
statement.
v Any /*JOBPARM statement parameter value overrides the equivalent parameter
value from the JES2 accounting information on the JOB statement or from any
preceding /*JOBPARM statement in this job.
v The JOB statement parameters BYTES, CARDS, LINES, and PAGES override
the /*JOBPARM parameters BYTES, CARDS, LINES, and PAGES.

Location in the JCL

Place the /*JOBPARM statement after the JOB statement.

Execution Node
JES2 normally processes /*JOBPARM statements at the node of execution.

When you place a /*JOBPARM statement before a /*ROUTE XEQ or /*XEQ

statement, JES2 at the input node checks the /*JOBPARM statement for syntax and
parameter validity. After processing the /*ROUTE XEQ or /*XEQ statement, JES2
then passes the /*JOBPARM statement to the execution node, where syntax and
parameter validity are again checked.

When you place a /*JOBPARM statement after a /*ROUTE XEQ or /*XEQ

statement, JES2 passes the /*JOBPARM to the execution node and performs all
syntax and parameter validity processing at the execution node only.

COPIES Parameter in Remote Processing

In remote processing, the COPIES parameter on the /*JOBPARM statement

determines the number of output copies only when the execution node is a JES2
node. The /*JOBPARM COPIES parameter is not supported by RSCS, DOS/VSE
POWER, or JES3.

Examples of the /*JOBPARM Statement

/*JOBPARM LINES=60,ROOM=4222,TIME=50,PROCLIB=PROC03,COPIES=5
/*JOBPARM L=60,R=4222,T=50,P=PROC03,N=5

The two statements specify the same parameters and values. The parameter
specifications mean the following:
LINES=60 or L=60
The job’s estimated output will be 60,000 lines.

27-8 z/OS V1R3.0 MVS JCL Reference

 JES2: /*JOBPARM
ROOM=4222 or R=4222
The programmer’s room is 4222. JES2 places this information in the separators
for both printed and punched data sets.
TIME=50 or T=50
The job’s estimated execution time is 50 minutes.
PROCLIB=PROC03 or P=PROC03
The procedure library that JES2 is to use to convert the JCL for this job is
PROC03.
COPIES=5 or N=5
The estimated 60,000 lines of output will be printed five times.

/*MESSAGE Statement
Purpose

Use the /*MESSAGE statement to send messages to the operator console when
JES2 reads in the job.

Syntax
/*MESSAGE message

The /*MESSAGE statement consists of the characters /* in columns 1 and 2, MESSAGE in

columns 3 through 9, a blank in column 10, and the message starting in any column from
11 through 71. JES2 ignores columns 72 through 80.

Relationship to the /*ROUTE XEQ Statement

If the /*MESSAGE statement is in a job that also contains a JES2 /*ROUTE XEQ
statement:
v Placing the /*MESSAGE statement before the /*ROUTE XEQ statement directs
JES2 to send the message to the operators at the input node and the execution
node.
v Placing the /*MESSAGE statement after the /*ROUTE XEQ statement directs
JES2 to send the message only to the operator at the execution node.

Location in the JCL

If the /*MESSAGE statement is after the JOB statement, JES2 appends the job
number to the beginning of the message.

If the /*MESSAGE statement is not within a job, JES2 appends the input device
name to the beginning of the message.

Example of the /*MESSAGE Statement

/*MESSAGE CALL DEPT 58 WHEN PAYROLL JOB IS FINISHED--EX.1946

JES2 sends this message to the operator console when the job is read in.

/*NETACCT Statement
Purpose

Chapter 27. JES2 Control Statements 27-9

JES2: /*NETACCT
Use the /*NETACCT statement to specify an account number that is available to all
the nodes in a network. JES2 uses the account number as is or translates it to local
account numbers.

Syntax
/*NETACCT network-account-number

The /*NETACCT statement consists of the characters /* in columns 1 and 2, NETACCT in

columns 3 through 9, a blank in column 10, and the network account number starting in any
column from 11 through 71. JES2 ignores columns 72 through 80.

Parameter Definition
network-account-number
Specifies the job’s accounting number. The network-account-number is 1
through 8 alphanumeric characters.

Defaults
If no /*NETACCT statement is specified, JES2 uses the local account number to
search a table for the network account number.

Overrides
If you supply both a /*NETACCT and a local account number, JES2 uses the local
account number on the input node.

Location in the JCL

Place the /*NETACCT statement after the JOB statement.

If a job contains more than one /*NETACCT statement, JES2 uses the network
account number from the last statement.

JES2 ignores the /*NETACCT statement on any node other than the input node.

Example of the /*NETACCT Statement

/*NETACCT NETNUM10

JES2 transmits the network account number, NETNUM10, with the job to the
destination node.

/*NOTIFY Statement
Purpose

Use the /*NOTIFY statement to direct a job’s notification messages to a user.

Note: The /*NOTIFY statement does not affect where the job is executed or where
output is printed or punched.

27-10 z/OS V1R3.0 MVS JCL Reference

 JES2: /*NOTIFY
Syntax
/*NOTIFY {nodename.userid }
{nodename:userid }
{nodename/userid }
{nodename(userid)}
{userid }

The /*NOTIFY statement consists of the characters /* in columns 1 and 2, NOTIFY in

columns 3 through 8, a blank in column 9, and a parameter starting in any column from 10
through 71. JES2 ignores columns 72 through 80.

Do not code a comma, a right parenthesis, or a blank character in the nodename or userid.

Parameter Definition
nodename.userid
nodename:userid
nodename/userid
nodename(userid)
Identifies a node and a TSO/E or VM userid at that node. The nodename is a
symbolic name defined by the installation during initialization; nodename is 1
through 8 alphanumeric or national ($, #, @) characters. The userid must be
defined at the node; userid for TSO/E is 1 through 7 alphanumeric or national
($, #, @) characters and for VM is 1 through 8 alphanumeric or national ($, #,
@) characters.
userid
Identifies a TSO/E or VM user. The userid for TSO/E is 1 through 7
alphanumeric or national ($, #, @) characters and for VM is 1 through 8
alphanumeric or national ($, #, @) characters. When you specify only a userid,
JES2 assumes that the userid is at the origin node.
The userid may also be a valid remote ID in the form Rnnnn or a destid for a
remote. If the userid is specified as R1-R9999, JES2 assumes the notify
message is intended for a remote and not a userid. If the remote is defined to
the system or is less than the highest defined remote for your system, the notify
message is queued to the remote. If the remote value is greater than the
highest defined remote but less than the maximum allowed remote, the notify
message is discarded. If the Rxxxx value specified is greater than R9999, JES2
considers that a TSO/E userid and not a remote ID.
A valid remote ID is only found when the node specification is for the local
node. A valid specification can be in the form of NxRy.

Overrides
The JES2 /*NOTIFY statement overrides the NOTIFY parameter on the JOB
statement.

Location in the JCL

The /*NOTIFY statement directs the notification messages of the job in which it
appears; place the /*NOTIFY statement after the JOB statement. Do not include the
/*NOTIFY statement in an in-stream procedure.

Chapter 27. JES2 Control Statements 27-11

JES2: /*NOTIFY
Examples of the NOTIFY Statement
Example 1
/*NOTIFY VMNODE.VMUSER

JES2 sends notification messages to user VMUSER on node VMNODE.

Example 2
/*NOTIFY TSOUSER

JES2 sends notification messages to user TSOUSER on the job’s origin node.

/*OUTPUT Statement
Purpose

Use the /*OUTPUT statement to specify characteristics and options for one or more
sysout data sets. This statement supplies processing options in addition to and in
place of the options specified on the sysout DD statement.

Note: You should use the OUTPUT JCL statement instead of the JES2
/*OUTPUT statement because of the OUTPUT JCL statement’s
enhanced output processing capabilities.

27-12 z/OS V1R3.0 MVS JCL Reference

 JES2: /*OUTPUT
Syntax
/*OUTPUT code parameter[,parameter]...

The parameters are:

{BURST} = {Y}
{B } {N}

{CHARS} = {xxxx }
{X } {(xxxx[,xxxx]...)}

{CKPTLNS} =nnnnn
{E }

{CKPTPGS} =nnnnn
{P }

{COMPACT} =nn
{Z }

{COPIES} = {nnn }
{N } {(nnn[,(group-value[,group-value]...)])}

{COPYG} = {group-value }
{G } {(group-value[,group-value]...)}

{DEST} = {destination } destination is:

{D } {(destination[,destination]...)}
{ANYLOCAL }
{LOCAL }
{FCB} =xxxx {name }
{C } {Nnnnn }
{NnnRmmmm }
{FLASH} = {overlay-name } {NnnnRmmm }
{O } {(overlay-name[,count])} {NnnnnRmm }
{NONE } {nodename.userid }
{nodename:userid }
{FLASHC} =count {nodename/userid }
{Q } {nodename(userid)}
{Rnnnn }
{FORMS} = {xxxx} {RMnnnn }
{F } {STD } {RMTnnnn }
{Unnnn }
{Userid }

{{INDEX |I} =nn}

{{LINDEX|L} =nn}

{LINECT} =nnn
{K }

{MODIFY} = {module-name }
{Y } {(module-name[,trc])}

{MODTRC} =trc
{M }

{UCS} =xxxx
{T }

Chapter 27. JES2 Control Statements 27-13

JES2: /*OUTPUT
The /*OUTPUT statement consists of the characters /* in columns 1 and 2, OUTPUT in
columns 3 through 8, a blank in column 9, a code beginning in column 10, followed by a
blank and the keyword parameters. JES2 ignores columns 72 through 80.

An * in column 10 indicates that this /*OUTPUT statement is a continuation of the previous

/*OUTPUT statement: JES2 treats it as a continuation, even through the previous
/*OUTPUT statement does not immediately precede the continuation.

Do not specify * in column 10 on the first /*OUTPUT statement in a job.

Parameter Definition
code
Identifies the /*OUTPUT statement. The code is 1 through 4 alphanumeric
characters. To refer to a /*OUTPUT statement, the DD statement SYSOUT
parameter must specify this code in its code-name subparameter. The
referenced /*OUTPUT statement specifies processing options for the sysout
data set defined in the referencing DD statement.
A code of * indicates that this /*OUTPUT statement is a continuation of the
previous /*OUTPUT statement.

Note: If you specify the code-name subparameter on a DD statement SYSOUT

parameter in a job or job step that contains a default OUTPUT JCL
statement, JES2 uses the default OUTPUT JCL statement instead of the
reference to the /*OUTPUT statement.

If more than one /*OUTPUT statement has the same code starting in column
10, JES2 uses the parameters from only the first /*OUTPUT statement.
BURST=Y
BURST=N
Indicates the default burst characteristic of all sysout data sets that JES2
produces for this job. BURST applies only when the data set is directed to a
3800 Printing Subsystem equipped with a burster-trimmer-stacker.
Y Requests that the 3800 output is to be burst into separate sheets.
N Requests that the 3800 output is to be in a continuous fanfold.
CHARS=xxxx
CHARS=(xxxx[,xxxx]...)
Names a character-arrangement table for all output that JES2 prints on a 3800
Printing Subsystem in this job. The xxxx is 1 through 4 alphanumeric or national
($, #, @) characters. Code one to four names.
CKPTLNS=nnnnn
Specifies the maximum number of lines or cards contained in a logical page.
The nnnnn is 1 through 5 decimal numbers from 0 through 32,767 for printers
and 1 through 32,767 for punches. The default is specified in the JES2
initialization parameter for the device.
CKPTPGS=nnnnn
Specifies the number of logical pages to be printed before the next checkpoint
is taken. The nnnnn is 1 through 5 decimal numbers from 1 through 32,767.
The default is specified in the JES2 initialization parameter for the device.

27-14 z/OS V1R3.0 MVS JCL Reference

 JES2: /*OUTPUT
COMPACT=nn
Specifies a compaction table for JES2 to use when sending this sysout data
set, which must be a systems network architecture (SNA) data set, to a SNA
remote terminal.

Note: The COMPACT parameter has no effect on compaction for NJE

sessions; it applies only to SNA RJE sessions.
COPIES=nnn
COPIES=(nnn[,(group-value[,group-value]...)])
Specifies how many copies of the sysout data set are to be printed in page
sequence order, or from a 3800 Printing Subsystem, grouped by page.
If you route a job that has a COPIES parameter, the parameter will be used
only if the receiving node is a JES2 node.
nnn
Specifies how many copies of the sysout data set are to be printed; each
copy will be in page sequence order. The nnn is 1 through 3 decimal
numbers from 1 through 255, subject to an installation-specified limit. For a
data set printed on a 3800, JES2 ignores nnn if any group values are
specified.
If you omit or incorrectly code the nnn parameter of COPIES, it defaults to
1 and a warning message is issued.
group-value
Specifies how many copies of each page are to be printed before the next
page is printed. Each group-value is 1 through 3 decimal numbers from 1
through 255. You can code a maximum of eight group-values. Their sum
must not exceed 255 or the installation-specified limit. The total copies of
each page equals the sum of the group-values.

Note: This subparameter is valid only for 3800 output. For 3800 output,
this subparameter overrides the nnn subparameter. The group-value
subparameter of the COPIES parameter overrides the group-value
subparameter of the COPYG parameter.

The following are not valid:

v A null group-value, for example, COPIES=(5(,)) or COPIES=(5,)
v A zero group-value, for example, COPIES=(5,(1,0,4))
v A null within a list of group-values, for example, COPIES=(5,(1,,4))
COPYG=group-value
COPYG=(group-value[,group-value]...)
Specifies how many copies of each page are to be printed before the next page
is printed. Each group-value is 1 through 3 decimal numbers from 1 through
255. You can code a maximum of eight group-values. Their sum must not
exceed 255. The total copies of each page equals the sum of the group-values.

Note: This parameter applies only for 3800 output. If you code COPYG and
JES2 prints the data set on an impact printer, JES2 ignores COPYG.
The group-value subparameter of the COPIES parameter overrides the
group-value subparameter of the COPYG parameter.
DEST=destination
DEST=(destination[,destination]...)
Note: JES2 initialization statements determine whether or not the node name is

Chapter 27. JES2 Control Statements 27-15

JES2: /*OUTPUT
required when coding a userid. See your system programmer for information
regarding how routings will be interpreted by JES2.
Specifies one to four different destinations for the sysout data set. The
destination subparameters follow:
ANYLOCAL
LOCAL
Indicates a local node on a local device.
name
Identifies a local or remote device by a symbolic name defined by the
installation during JES2 initialization. The name is 1 through 8 alphanumeric
or national ($, #, @) characters.
Nnnnn
Identifies a node. nnnn is 1 through 4 decimal numbers from 1 through
1000. For example, N0103.
NnnRmmmm
NnnnRmmm
NnnnnRmm
Identifies a node and a remote work station connected to the node. The
node number, indicated in the format by n, is 1 through 4 decimal numbers
from 1 through 1000. The remote work station number, indicated in the
format by m, is 1 through 4 decimal numbers from 1 through 9999. Do not
code leading zeros in n or m. The maximum number of digits for n and m
combined cannot exceed six.

Note: NnnR0 is equivalent to LOCAL specified at node Nn.

nodename.userid
nodename:userid
nodename/userid
nodename(userid)
Identifies a destination node and a TSO/E or VM userid at that node. Use
this parameter to route a sysout data set between JES2 nodes and
non-JES2 nodes. The nodename is a symbolic name defined by the
installation during initialization; nodename is 1 through 8 alphanumeric or
national ($, #, @) characters. The userid must be defined at the node;
userid for TSO/E is 1 through 7 alphanumeric or national ($, #, @)
characters and for VM is 1 through 8 alphanumeric or national ($, #, @)
characters.
Use the form nodename.userid to specify up to four destinations using
continuation statements. The continuation statement must contain the
characters /* in columns 1 and 2, OUTPUT in columns 3 through 8, a blank
in column 9, an * in or following column 10, followed by one or more
blanks, and the characters DEST= with the specified destinations. For
example:
/*OUTPUT ABCD DEST=(POK.USER27,NYC.USER31)
/*OUTPUT * DEST=(BOCA.USER58,STL.USER22)

Use the form nodename.userid to send the output to the VM user’s virtual
reader.
Rnnnn
RMnnnn

27-16 z/OS V1R3.0 MVS JCL Reference

 JES2: /*OUTPUT
RMTnnnn
Identifies a remote terminal. nnnn is 1 through 4 decimal numbers from 1
through 9999. Note that with remote pooling, the installation may translate
this route code to another route code.
If you send a job to execute at a remote node and the job has a ROUTE
PRINT RMTnnnn statement, JES2 returns the output to RMTnnnn at the
node of origin. For JES2 to print the output at RMTnnnn at the executing
node, code DEST=NnnnRmmm on an OUTPUT JCL statement or sysout
DD statement.

Note: R0 indicates any local device.

Unnnn
Identifies a local terminal with special routing. nnnn is 1 through 4 decimal
numbers from 1 through 9999.
If you send a job to execute and the job has a ROUTE PRINT Unnnn
statement, JES2 returns the output to Unnnn at the node of origin.
Userid
Identifies a userid at the local node.
FCB=xxxx
Identifies the forms control buffer (FCB) image JES2 is to use to guide printing
of the sysout data set. The xxxx is 1 through 4 alphanumeric or national ($, #,
@) characters and is the last characters of a SYS1.IMAGELIB member name:
v FCB2xxxx member, for a 3211 Printer, a 3203 Printer Model 5, or a printer
supported by systems network architecture (SNA).
v FCB3xxxx member, for a 3800 Printing Subsystem.
v FCB4xxxx member, for a 4248 Printer.

IBM provides two standard FCB images. Code STD1 or STD2 only to request
them.
v STD1, which specifies 6 lines per inch on an 8.5-inch-long form. (3211 and
3203-5 only)
v STD2, which specifies 6 lines per inch on an 11-inch-long form. (3211 and
3203-5 only)

If the printer on which JES2 is to print the data set does not have the forms
control buffer feature, JES2 sends the operator a message to mount the proper
carriage control tape.
FLASH=overlay-name
FLASH=(overlay-name[,count])
FLASH=NONE
Identifies the forms overlay to be used in printing the sysout data set on a 3800
Printing Subsystem and, optionally, specifies the number of copies on which the
forms overlay is to be printed.
overlay-name
Identifies the forms overlay frame that the operator is to insert into the
printer before printing begins. The name is 1 through 4 alphanumeric or
national ($, #, @) characters.
Do not omit the overlay-name. The count subparameter is optional. If you
omit it, you can omit the parentheses. However, if you omit it, you must not
code it as a null; for example, FLASH=(ABCD,) is invalid.

Chapter 27. JES2 Control Statements 27-17

JES2: /*OUTPUT
Before printing starts, JES2 does not verify that the operator inserted the
correct forms overlay frame for flashing.
count
Specifies the number, 1 through 255, of copies that JES2 is to flash with
the overlay, beginning with the first copy printed.
JES2 determines the maximum number of copies to flash with the forms
overlay by the value of nnn or the group-value total on the COPIES
parameter. If the FLASH count value is greater than the value from the
COPIES parameter, JES2 prints with the forms overlay the lower value.
The count subparameter of the FLASH parameter overrides the count value
of the FLASHC parameter.
NONE
Suppresses flashing for this sysout data set.

Defaults: If you omit this parameter and did not specify FLASH on the DD
statement or FLASHC on the /*OUTPUT statement, JES2 uses the default
specified at JES2 initialization.

If you specify an overlay-name without specifying a count, JES2 flashes all

copies. That is, the default for count is 255. If you specify 0 for count, JES2
also flashes all copies.
FLASHC=count
Specifies the number, 0 through 255, of copies that JES2 is to flash with the
overlay, beginning with the first copy printed.

Note: For the 3800 printer, if you specify FLASH and omit FLASHC, JES2
flashes all copies.

The count subparameter of the FLASH parameter overrides the count value of
the FLASHC parameter.
FORMS=xxxx
FORMS=STD
Identifies the forms on which JES2 is to print or punch the sysout data set.
xxxx
Identifies the print or punch forms. form-name is 1 through 4 alphanumeric
or national ($, #, @) characters.
STD
Indicates that JES2 is to use the default specified at JES2 initialization.
INDEX=nn
Sets the left margin for output on a 3211 Printer with the indexing feature. The
width of the print line is reduced by the INDEX parameter value. The nn
specifies how many print positions the left margin on the 3211 output is to be
indented. nn is a decimal number from 1 through 31. n=1 indicates flush-left;
n=2 through n=31 indent the print line by n-1 positions.
JES2 ignores the INDEX parameter if the printer is not a 3211 with the indexing
feature.

Note: INDEX and LINDEX are mutually exclusive; if you code both, JES2 uses
the value you specified in INDEX.

27-18 z/OS V1R3.0 MVS JCL Reference

 JES2: /*OUTPUT
LINDEX=nn
Sets the right margin for output on a 3211 Printer with the indexing feature. The
width of the print line is reduced by the LINDEX parameter value. The nn
specifies how many print positions the right margin on 3211 output is to be
moved in from the full page width. nn is a decimal number from 1 through 31.
n=1 indicates flush-right; n=2 through n=31 move the right margin over by n-1
positions.
JES2 ignores the LINDEX parameter on all printers except the 3211 with the
indexing feature.

Note: INDEX and LINDEX are mutually exclusive; if you code both, JES2 uses
the value you specified in INDEX.
LINECT=nnn
Specifies the maximum number of lines JES2 is to print on each output page.
The nnn is a number from 0 through 255.
Specify LINECT=0 to keep JES2 from starting a new page when the number of
lines exceeds the JES2 initialization parameter.
If you code LINECT on the /*OUTPUT statement, it overrides the LINECT value
on the /*JOBPARM statement and the linect value in the accounting information
parameter of the JOB statement.
If the LINECT parameter is omitted from the /*OUTPUT statement, JES2
obtains the value from one of the following sources, in order:
1. The LINECT parameter on the /*JOBPARM statement.
2. The linect field of the accounting information parameter on the JOB
statement.
3. The installation default specified at JES2 initialization.
MODIFY=module-name
MODIFY=(module-name[,trc])
Specifies a copy-modification module that tells JES2 how to print the sysout
data set on a 3800 Printing Subsystem. The module can specify legends,
column headings, blanks, and where and on which copies the data is to be
printed. The module is defined and stored in SYS1.IMAGELIB using the
IEBIMAGE utility program.
module-name
Identifies a copy-modification module in SYS1.IMAGELIB. The
module-name is 1 through 4 alphanumeric or national ($, #, @) characters.
Do not omit the module-name.
trc
Identifies which table-name in the CHARS parameter is to be used. This
table reference character is 0 for the first table-name specified, 1 for the
second, 2 for the third, or 3 for the fourth.
If you do not specify trc, the default is 0. If the trc value is greater than the
number of table-names in the CHARS parameter, JES2 uses the first table
named in the CHARS parameter.
The trc subparameter is optional. If you omit it, you can omit the
parentheses. However, if you omit it, you must not code it as a null; for
example, MODIFY=(TAB1,) is invalid. If you omit the trc subparameter,
JES2 uses the first table-name.
The trc subparameter of the MODIFY parameter overrides the trc
subparameter of the MODTRC parameter.

Chapter 27. JES2 Control Statements 27-19

JES2: /*OUTPUT
MODTRC=trc
Identifies which table-name in the CHARS parameter is to be used. This table
reference character is 0 for the first table-name specified, 1 for the second, 2
for the third, or 3 for the fourth.
If you do not specify trc, the default is 0. If the trc value is greater than the
number of table-names in the CHARS parameter, JES2 uses the first table
named in the CHARS parameter.
The trc subparameter of the MODIFY parameter overrides the trc subparameter
of the MODTRC parameter.
UCS=xxxx
Identifies the universal character set (UCS) image JES2 is to use in printing the
sysout data set. The xxxx is 1 through 4 alphanumeric or national ($, #, @)
characters. See Table 12-2 on page 12-201 for IBM standard special character
set codes.

Overrides
v /*OUTPUT statement parameters override all equivalent DD statement
parameters.
v If a /*OUTPUT statement contains duplicate parameters, the last parameter
overrides all preceding duplicates, except for the DEST parameter.
v Any parameter coded on subsequent /*OUTPUT statements overrides the same
parameter on previous /*OUTPUT statements.
v JES2 adds any parameter you code on subsequent /*OUTPUT statements that
you did not code on previous /*OUTPUT statements to the previous /*OUTPUT
statement.
v If you code LINECT on the /*OUTPUT statement, it overrides the LINECT value
on the /*JOBPARM statement and the linect value in the accounting information
parameter of the JOB statement.

Relationship to Other Control Statements

v JES2 processes /*OUTPUT statements placed after a /*ROUTE XEQ statement
at the execution node only.
v JES2 processes /*OUTPUT statements placed before a /*ROUTE XEQ statement
at both the input node and the execution node.

Location in the JCL

Place the /*OUTPUT statement after the JOB statement. Do not include the
/*OUTPUT statement in an instream procedure.

Example of the /*OUTPUT Statement

/*OUTPUT ABCD COPIES=6,COPYG=(1,2,3),DEST=RMT23

This statement refers to all sysout data sets defined by a DD statement that
specifies SYSOUT=(c,,ABCD). Six copies of each page of output are printed. If the
printer is a 3800, first one copy of each page is printed, then two copies of each
page, and finally, three copies of each page. If the printer is not a 3800, COPYG is
ignored and six copies of the entire data set are printed. The output is sent to
remote terminal 23.

27-20 z/OS V1R3.0 MVS JCL Reference

 JES2: /*PRIORITY

/*PRIORITY Statement
Purpose

Use the /*PRIORITY statement to assign a selection priority for your job. Within a
job class, a job with a higher priority is selected for execution sooner.

Note: The /*PRIORITY statement is ignored for a started task.

In a JES2 system, there are a number of factors that determine the order in which a
particular job is selected for execution. Therefore, you cannot be assured that job
priority (based on the PRTY you assign a job), job class, or the order of job
submission will guarantee that the jobs will execute in a particular order. If you need
to submit jobs in a specific order, contact your JES2 system programmer for advice
based on how your system honors such requests. (z/OS JES2 Initialization and
Tuning Guide provides JES2 system programmer procedures concerning job
queuing and how to control job execution sequence.)

Syntax
/*PRIORITY p

The /*PRIORITY statement consists of the characters /* in columns 1 and 2, PRIORITY in

columns 3 through 10, a blank in column 11, and the priority starting in any column from 12
through 71. JES2 ignores columns 72 through 80.

Parameter Definition
p Requests a priority. The p is 1 or 2 decimal numbers from 0 through 15. The
highest priority is 15.
Follow your installation’s rules in coding a priority.

Overrides
A priority specified on a /*PRIORITY statement overrides a priority specified in the
PRTY parameter on a JOB statement.

Relationship to Other Control Statements

The system derives the priority from the following, in override order:
1. JES2 /*PRIORITY statement.
2. The PRTY parameter on the JOB statement.
3. The accounting information on a /*JOBPARM statement.
4. The accounting information on the JOB statement.
5. An installation default specified at JES2 initialization.

Location in the JCL

The /*PRIORITY statement must immediately precede the JOB statement. If not, or
if p is not a number from 0 through 15, JES2 ignores the /*PRIORITY statement
and flushes the input stream until the next JOB statement or another /*PRIORITY
statement.

In a JES2 network, IBM recommends that the /*PRIORITY statement immediately

follow the /*XMIT statement. If you code any other statement between /*XMIT and
JOB, JES2 will ignore the statement and issue an error message.

Chapter 27. JES2 Control Statements 27-21

JES2: /*PRIORITY
Example of the PRIORITY Statement
/*PRIORITY 7

This statement assigns a job queue selection priority of 7. This value has meaning
only in relation to other jobs in the system.

/*ROUTE Statement
Purpose

Use the /*ROUTE statement to specify the destination of sysout data sets that are
not routed by a DEST parameter or to identify the network node where the job is to
execute.

Note: Do not specify the /*ROUTE XEQ statement for a started task; if /*ROUTE
XEQ is specified, JES2 fails the job.

Syntax
/*ROUTE {PRINT} {ANYLOCAL }
{PUNCH} {LOCAL }
{name }
{Nnnnn }
{NnnRmmmm }
{NnnnRmmm }
{NnnnnRmm }
{nodename.userid }
{nodename:userid }
{nodename/userid }
{nodename(userid)}
{Rnnnn }
{RMnnnn }
{RMTnnnn }
{Unnnn }
{Userid }

/*ROUTE XEQ {name }

{Nnnnn }
{nodename.vmguestid }
{nodename:vmguestid }
{nodename/vmguestid }
{nodename(vmguestid)}

The /*ROUTE statement consists of the characters /* in columns 1 and 2; ROUTE in

columns 3 through 7; at least one blank followed by PRINT, PUNCH, or XEQ; at least one
blank followed by one of the destinations or nodes; and at least one blank before column
72. JES2 ignores columns 72 through 80.

Code only one destination or node on each /*ROUTE statement.

Parameter Definition
PRINT
Requests that JES2 route the job’s sysout data sets that are printed.
PUNCH
Requests that JES2 route the job’s sysout data sets that are punched.

27-22 z/OS V1R3.0 MVS JCL Reference

 JES2: /*ROUTE
XEQ
Requests that JES2 route the job to a network node for execution.
ANYLOCAL
LOCAL
Indicates a local node on a local device.
name
Identifies a local or remote device or node by a symbolic name defined by the
installation with the JES2 DESTID initialization statement. The name is 1
through 8 alphanumeric or national ($, #, @) characters.
Nnnnn
Identifies a node. nnnn is 1 through 4 decimal numbers from 1 through 1000.
For example, N0103.
NnnRmmmm
NnnnRmmm
NnnnnRmm
Identifies a node and a remote work station connected to the node. The node
number, indicated in the format by n, is 1 through 4 decimal numbers from 1
through 1000. The remote work station number, indicated in the format by m, is
1 through 4 decimal numbers from 1 through 9999. Do not code leading zeros
in n or m. The maximum number of digits for n and m combined cannot exceed
six.

Note: NnnR0 is equivalent to LOCAL specified at node Nn.

nodename.userid
nodename:userid
nodename/userid
nodename(userid)
Identifies a node and a VM or TSO/E userid, a remote workstation, or a
symbolic name defined at the destination node. The node is a symbolic name
defined by the installation during initialization; nodename is 1 through 8
alphanumeric or national ($, #, @) characters. The userid must be defined at
the node; userid is 1 through 8 alphanumeric or national ($, #, @) characters.
A userid requires a node; therefore, code nodename.userid. You cannot code a
userid without a nodename.
If you specify a TSO/E userid, do not specify a nodename that is the same as
the origin node.

Note: If a data set is queued for transmission and an operator changes its
destination, the userid portion of the routing is lost.
Rnnnn
RMnnnn
RMTnnnn
Identifies a remote terminal. nnnn is 1 through 4 decimal numbers from 1
through 9999. Note that with remote pooling, the installation may translate this
route code to another route code.
If you send a job to execute at a remote node and the job has a ROUTE PRINT
RMTnnnn statement, JES2 returns the output to RMTnnnn at the node of origin.
For JES2 to print the output at RMTnnnn at the executing node, code
DEST=NnnnRmmm on an OUTPUT JCL statement or sysout DD statement.

Note: R0 indicates any local device.

Chapter 27. JES2 Control Statements 27-23

JES2: /*ROUTE
Unnnn
Identifies a local terminal with special routing. nnnn is 1 through 4 decimal
numbers from 1 through 9999.
If you send a job to execute and the job has a ROUTE PRINT Unnnn
statement, JES2 returns the output to Unnnn at the node of origin.
Userid
Identifies a userid at the local node.

Note: JES2 initialization statements determine whether or not the node name is
required when coding a userid. See your System Programmer for
information regarding how routings will be interpreted by JES2.
nodename.vmguestid
nodename:vmguestid
nodename/vmguestid
nodename(vmguestid)
Identifies the network node where the job is to execute. The nodename
identifies an MVS JES2 system, an MVS JES3 system, a VSE POWER node,
or a VM system. If nodename specifies the local node, the job executes locally.
The nodename is 1 through 8 alphanumeric, national ($, #, @), or special
characters specified during JES2 initialization.
The vmguestid identifies a guest system running in a virtual machine (VM), for
example, an MVS system running under VM. Do not specify a work station or
terminal in this parameter.

Location in the JCL

Place the /*ROUTE statement after the JOB statement and either before or after the
EXEC statements. Place a /*ROUTE XEQ statement before all DD * or DD DATA
statements in the job.

Processing of /*ROUTE Statements

v The system ignores the /*ROUTE XEQ statement for NJE devices.
v If you do not specify a node on the /*ROUTE PRINT or PUNCH statement,
printing or punching occurs at the input node.
v JES2 processes /*ROUTE XEQ statements on the input node only.
v When a /*ROUTE PRINT or PUNCH statement follows a /*ROUTE XEQ
statement, JES2 processes the /*ROUTE PRINT or PUNCH statement on the
execution node only. However, printing or punching occurs at the node specified
on the /*ROUTE PRINT or PUNCH statement.
v When a /*ROUTE PRINT or PUNCH statement precedes a /*ROUTE XEQ
statement, JES2 processes the /*ROUTE PRINT or PUNCH statement on both
the input and execution nodes. However, printing or punching occurs at the node
specified on the /*ROUTE PRINT or PUNCH statement.

Multiple /*ROUTE Statements

JES2 uses the last /*ROUTE statement of each category, if a job contains more
than one /*ROUTE PRINT or PUNCH or XEQ statement.

Examples of the ROUTE Statement

Example 1
/*ROUTE PRINT RMT6

27-24 z/OS V1R3.0 MVS JCL Reference

 JES2: /*ROUTE
This statement sends the printed output to remote terminal 6.

Example 2
/*ROUTE PUNCH PUN2

This statement sends the punched output to device PUN2, which was identified to
the system during initialization.

Example 3
//JOBB JOB ...
/*ROUTE XEQ DENVER
//STEP1 EXEC ...
.
.

This statement sends the job to the node named DENVER for execution. The entire
job is scanned for JCL errors on the input system before it is transmitted to the
target system. The entire job is transmitted, which includes the JOBB JOB
statement. Options on the JOBB JOB statement apply to both the input and target
system.

/*SETUP Statement
Purpose

Use the /*SETUP statement to identify volumes that the operator should mount
before the job is executed. When the job enters the system, JES2 issues a
message to the operator console, asking the operator to mount the identified
volumes. JES2 then places the job in hold status until the operator mounts the
volumes and releases the job.

Note: Do not specify this statement for a started task; if /*SETUP is specified,
JES2 fails the job.

Syntax
/*SETUP serial-number[,serial-number]...

The /*SETUP statement consists of the characters /* in columns 1 and 2, SETUP in

columns 3 through 7, a blank in column 10, and the volume serial number(s) starting in any
column from 11 through 71. JES2 ignores columns 72 through 80.

Do not continue the /*SETUP statement; code as many /*SETUP statements as necessary.

Parameter Definition
serial-number
Identifies by serial number the volume(s). A volume serial number is 1 through 6
alphanumeric, national ($, #, @), or special characters; enclose a serial number
that contains special characters, other than hyphens, in apostrophes. If the
number is shorter than 6 characters, it is padded with trailing blanks.

Location in the JCL

Place all /*SETUP statements after the JOB statement and before the first EXEC
statement.

Chapter 27. JES2 Control Statements 27-25

JES2: /*SETUP
To prevent JES2 from requesting mounting of volumes on a node other than the
node of execution, the /*SETUP statement should follow any /*ROUTE XEQ or
/*XEQ statement. If JES2 processes the /*SETUP statement before processing a
/*ROUTE XEQ or /*XEQ statement, JES2 requests the setup on both the input and
execution nodes.

Example of the /*SETUP Statement

/*SETUP 666321,149658

This statement requests that volumes 666321 and 149658 be mounted for the job.

/*SIGNOFF Statement
Purpose

Use the /*SIGNOFF statement to tell JES2 to end a remote job stream processing
session. At the completion of the current print and/or punch streams, JES2
disconnects the remote work station from the system. If JES2 is reading jobs from
the station when the output completes, JES2 disconnects the remote station when
the input is completed.

Note: The remote terminal access processor processes the /*SIGNOFF statement
if it appears in a job stream.

Both systems network architecture (SNA) and binary synchronous communication

(BSC) remote work stations can use the /*SIGNOFF statement. SNA remote
stations can also use the LOGOFF command to end a session with JES2. The
LOGOFF command has some options that the /*SIGNOFF statement does not
provide.
v /*SIGNOFF# = LOGOFF TYPE(COND) Conditional Disconnect
v LOGOFF = LOGOFF TYPE(UNCOND) Unconditional Disconnect

References

For information on the LOGOFF command, see z/OS Communications Server: SNA
Programming.

Syntax
/*SIGNOFF

The /*SIGNOFF statement consists of the characters /* in columns 1 and 2, SIGNOFF in

columns 3 through 9, and blanks in columns 10 through 80.

Location in the JCL

The /*SIGNOFF statement can appear anywhere in a local input stream or an input
stream from a SNA or BSC remote work station.

Example of the /*SIGNOFF Statement

/*SIGNOFF

This statement requests that JES2 terminate a remote job stream processing
session.

27-26 z/OS V1R3.0 MVS JCL Reference

 JES2: /*SIGNON

/*SIGNON Statement
Purpose

Use the /*SIGNON statement to tell JES2 to begin a remote job stream processing
session. For non-multi-leaving remote stations, the terminal transmits the /*SIGNON
statement alone as part of the initial connection process.

Note: The remote terminal access processor processes the /*SIGNON statement if
it appears in a job stream. When the terminal access processor processes
the /*SIGNON statement, the line being processed is restarted.

Systems network architecture (SNA) remote work stations must use the LOGON
command instead of the /*SIGNON statement to notify JES2 of a connection
request.

References

For information on the LOGON command, see z/OS Communications Server: SNA
Programming.

Syntax
/*SIGNON {REMOTEnnn} [password1] [new-password] [password2]
{RMTnnnn }
{RMnnnn }
{Rnnnn }
{NxxRnnnn }
{dest-name}

The /*SIGNON statement consists of the following. Note that all the fields in this statement
must appear in fixed locations.
Column
Contents

1-8 /*SIGNON
16-24 REMOTEnnn, RMTnnnn, RMnnnn, Rnnnn, NxxRnnnn, or dest-name beginning in
16
25-32 password1, beginning in 25
35-42 new-password, beginning in 35
73-80 password2, beginning in 73

Parameter Definition
REMOTEnnn
Specifies the identification number assigned to the remote station asking to sign
on. The nnn is 1 through 3 decimal numbers.
Code REMOTEnnn with the same characters as RMTnnn on the /*ROUTE
statement. If you code REMOTEnnn on the /*SIGNON statement, you are
restricted to coding RMTnnn with only three numbers on the /*ROUTE
statement.
RMTnnnn
RMnnnn

Chapter 27. JES2 Control Statements 27-27

JES2: /*SIGNON
Rnnnn
Specifies the identification number assigned to the remote station. nnnn is one
through four decimal numbers.
NxxRnnnn
Specifies the node number in the NJE network and the identification number
assigned to the remote station. Nxx must specify the node to which the remote
work station is connected. xx is 1 through 1000. nnnn is 1 through 4 decimal
numbers. xx plus nnnn cannot exceed 6 numbers.
dest-name
Specifies the name (one through eight characters) that you use to refer to the
JES2-defined destination. The dest-name must be defined as a remote work
station on the system to which the terminal is connected.
password1
Specifies the password assigned to a nondedicated connection that allows the
remote station access to JES2 for remote job stream processing. The
installation assigns this password during system initialization. The operator can
change or delete this password with the $T command.
new-password
Specifies a new password for the remote job entry (RJE) station that is signing
on. If the installation is controlling the sign on with JES2 password support
instead of RACF, the new password is ignored.
password2
Specifies the current password for the remote station that is signing on; this
password identifies the remote station as a valid remote job entry (RJE) station.
This parameter is assigned by either RACF, a JES2 initialization parameter (if
JES2 password support is used), or the $T command.

Location in the JCL

Place the /*SIGNON statement at the start of an input stream to be transmitted from
a remote work station. The terminal transmits the /*SIGNON statement alone as
part of the initial connection process.

Place the /*SIGNON statement at the end of the JES2/RTP input stream for
multi-leaving remote stations.

Examples of the /*SIGNON Statement

Example 1
/*SIGNON REMOTE123LINEPSWD

This statement requests that remote station 123 begin a remote job stream
processing session. LINEPSWD, beginning in column 25, is the password assigned
to the nondedicated connection.

Example 2
/*SIGNON RMT1000 LINEPSWD

This statement requests that remote station 1000 begin a remote job stream
processing session. LINEPSWD, beginning in column 25, is the password assigned
to the non-dedicated connection.

Example 3
/*SIGNON RMT1000 LINEPSWD PSWDNEW PSWD2

27-28 z/OS V1R3.0 MVS JCL Reference

 JES2: /*SIGNON
This statement requests that remote station 1000 begin a remote job stream
processing session. LINEPSWD, beginning in column 25, is the password assigned
to the nondedicated connection. PSWD2, beginning in column 73, is the password
assigned to the remote station 1000. PSWDNEW, beginning in column 35, is the
new password to be assigned to remote station 1000.

Example 4
/*SIGNON N11R123 LINEPSWD

This statement requests that remote station 123 at node 11 begin a remote job
stream processing session. LINEPSWD, beginning in column 25, is the password
assigned to the switched connection.

/*XEQ Statement
Purpose

Use the /*XEQ statement to identify the network node where the job is to execute. It
performs the same function as the /*ROUTE XEQ statement.
Notes:
1. Do not specify this statement for a started task; if /*XEQ is specified, JES2 fails
the job.
2. The XEQ statement is ignored for NJE devices.

Syntax
/*XEQ {Nnnnn }
{nodename[.vmguestid]}
{name }

The /*XEQ statement consists of the characters /* in columns 1 and 2, XEQ in columns 3
through 5, a blank in column 6, and a node starting in any column starting with 7.

Parameter Definition
Nnnnn
Identifies a node. nnnn is 1 through 4 decimal numbers from 1 through 1000.
For example, N0103.
nodename
Identifies the network node where the job is to execute. The nodename
identifies an MVS JES2 system, an MVS JES3 system, a VSE POWER node,
or a VM system. If nodename specifies the local node, the job executes locally.
The nodename is 1 through 8 alphanumeric, national ($, #, @), or special
characters specified during JES2 initialization.
vmguestid
Identifies a guest system running in a virtual machine (VM), for example, an
MVS system running under VM. Do not specify a work station or terminal in this
parameter.
name
Specifies the name (1 through 8 characters) that you use to refer to the
JES2-defined destination. The name must be defined as a node and userid at
the destination node.

Chapter 27. JES2 Control Statements 27-29

JES2: /*XEQ
Location in the JCL
Place the /*XEQ statement after the JOB statement and either before or after the
EXEC statements. Place a /*XEQ statement before all DD * or DD DATA statements
in the job.

Multiple /*XEQ Statements

JES2 uses the last /*XEQ statement, if a job contains more than one /*XEQ
statement.

Example of the XEQ Statement

//JOBB JOB ...
/*XEQ ATLANTA
//STEP1 EXEC ...
.
.

JES2 routes and executes this job on the node defined as ATLANTA. The entire job
is transmitted, which includes the JOBB JOB statement. Options on the JOBB JOB
statement apply to both the input and target system.

/*XMIT Statement
Purpose

Use the /*XMIT statement to transmit records from a JES2 node to either another
JES2 node or an eligible non-JES2 node, for example, a VM or JES3 node. JES2
does not process or check the records for JES2 validity. JES2 builds header and
trailer records from information on the JOB statement immediately preceding the
/*XMIT statement. Then JES2 transmits all records after the /*XMIT statement.

The records may consist of a job input stream or an in-stream DD * or DD DATA

data set. If the records are in a job input stream and the destination node can
process JCL (which means it is the ultimate node, not a store-and-forward node),
the system will execute the transmitted input stream provided that: (a) the record
immediately following the /*XMIT statement is a JOB statement valid at that node,
and (b) the input stream consists only of the JCL and data for the one job headed
by that JOB statement. The system will flush ALL jobs if an NJE (network job entry)
receiver finds multiple JOB statements in the input stream.

The records end when JES2 finds one of the following:

v /* in the input stream
v The two-character delimiter specified by a DLM parameter on this /*XMIT
statement
v The input stream runs out of card images
v If the records are being read from an internal reader, the internal reader is closed

Note: Do not specify this statement for a started task; if /*XMIT is specified, JES2
fails the job.

27-30 z/OS V1R3.0 MVS JCL Reference

 JES2: /*XMIT
Syntax
/*XMIT {Nnnnn } [ DLM=xx]
{nodename }
{nodename.userid }
{nodename:userid }
{nodename/userid }
{nodename(userid) }
{nodename.vmguestid }
{nodename:vmguestid }
{nodename/vmguestid }
{nodename(vmguestid)}
{name }

The /*XMIT statement consists of the characters /* in columns 1 and 2, XMIT in columns 3
through 6, a blank in column 7, a nodename or node-number starting in any column starting
with 8, and optionally followed, with an intervening blank, by a delimiter parameter.

Do not continue an /*XMIT statement.

Parameter Definition
Nnnnn
Identifies the destination node. nnnn is 1 through 4 decimal numbers from 1
through 1000. For example, N0103.
nodename
Identifies the destination node. The nodename identifies an MVS JES2 system,
an MVS JES3 system, a VSE POWER node, or a VM system. The nodename
is 1 through 8 alphanumeric, national ($, #, @), or special characters specified
during JES2 initialization.
userid
Identifies a destination terminal or work station at the node. The userid must be
defined at the node; userid for TSO/E is 1 through 7 alphanumeric or national
($, #, @) characters and for VM is 1 through 8 alphanumeric or national ($, #,
@) characters.
vmguestid
Identifies a destination guest system running in a virtual machine (VM), for
example, an MVS system running under VM. Do not specify a work station or
terminal in this parameter.
name
Specifies the name (1 through 8 characters) that you use to refer to the
JES2-defined destination. The name must be defined as a node and userid at
the destination node.
DLM=xx
Specifies a two-character delimiter to terminate the data being transmitted.
Code any two characters for the delimiter. If the specified delimiter contains any
special characters, enclose it in apostrophes. In this case, a special character is
any character that is neither alphanumeric nor national ($, #, @).
Failing to code enclosing apostrophes produces unpredictable results.
If the delimiter contains an ampersand or an apostrophe, code each ampersand
or apostrophe as two consecutive ampersands or apostrophes. Each pair of
consecutive ampersands or apostrophes counts as one character.

Chapter 27. JES2 Control Statements 27-31

JES2: /*XMIT
If you specify a DLM parameter, you must terminate the transmitted records
with the characters in the DLM parameter. The characters you assign as
delimiters override any delimiter implied by the defaults.
The characters // are not valid delimiters unless specifically indicated by
DLM=//.

Defaults
For the end of the records to be transmitted, the default is /* in the input stream.

If you specify for DLM only one character or more than two characters, JES2 uses
/*.

Location in the JCL

Place the /*XMIT statement immediately after a JOB statement. If the records being
transmitted are a job input stream, another JOB statement must follow the /*XMIT
statement.

You can code only the /*PRIORITY statement between an /*XMIT statement and a
JOB statement. If you code any other statement between /*XMIT and JOB, JES2
will ignore the statement and issue an error message.

Code only one /*XMIT statement in a job.

Examples of the XMIT Statement

Example 1
//JOBA JOB ...
/*XMIT ATLANTA DLM=AA
.
records to be transmitted
.
AA

JES2 transmits to the node ATLANTA all records following the /*XMIT statement up
to the specified delimiter, AA.

Example 2
//JOBX JOB ...
/*XMIT VMSYS1.MVS223
//JOBB JOB ...
.
job to be transmitted
.
/*

JES2 transmits the JOBB job stream to the VM guest system, MVS223, running on
node VMSYS1, which is a VM system. The job stream will be executed by the
MVS223 system.

The information specified on the JOBX statement is processed on the submitting

system and transmitted in the networking headers to the target system. The target
system, if it is a JES2 node, uses the default routing in the network job header
unless it is specifically overridden in the JCL for the transmitted job.

27-32 z/OS V1R3.0 MVS JCL Reference

 Chapter 28. JES3 Control Statements
Code JES3 control statements with JCL statements to control the input and output
processing of jobs. The rules for coding in Chapter 3, “Format of Statements”, and
Chapter 4, “Syntax of Parameters”, apply to the JES3 control statements.

Description

Considerations for an APPC Scheduling Environment

JES3 control statements have no function in an APPC scheduling environment. If
you code them, the system will ignore them, and they will appear as comments in
the job listing.

Considerations for Started Tasks

JES3 JECL statements are not supported for started tasks. Use of JECL statements
will result in JES3 failing the job.

Location in the JCL

Place JES3 control statements, except the command and //**PAUSE statements,
after the JOB statement and its continuations. JES3 ignores JES3 control
statements, except the command and //**PAUSE statements, that appear before the
JOB statement or between continued JOB statements.

Do not include JES3 control statements in a cataloged or in-stream procedure.

JES3 ignores JES3 control statements in a procedure.

Internal Reader
Use the following control statements when submitting jobs to the internal reader.
The internal reader is described in z/OS MVS Programming: Assembler Services
Guide.
/*DEL
/*EOF

Examples of JES3 Control Statements

The first example shows JES3 control statements in relation to each other and to
JCL statements for a job entered from a remote work station. No actual job should
require all of these statements.

The second example shows an ordinary job entered through the local input stream.

The remainder of this chapter shows the recommended syntax for each control
statement, with examples. Note, however, that for some JES3 control statements
(such as the //* MAIN statement) a single slash followed by an asterisk (/*), rather
than two slashes and an asterisk (//*), will be processed as syntactically acceptable.
| Your installation may disallow this option by using the ALTJCL keyword parameter
| of the STANDARDS initialization statement. For further information see z/OS JES3
| Initialization and Tuning Reference.

Example 1
//**MESSAGE,CN1,ENTER A START COMMAND FOR THIS JOB
//**PAUSE
//TEST1 JOB ,,MSGCLASS=A

© Copyright IBM Corp. 1988, 2002 28-1

JES3
//*NETACCT PNAME=MAEBIRD,ACCT=2K14920
//*NET NETID=N1,NHOLD=0
//*PROCESS CI
//*PROCESS MAIN
//*PROCESS OUTSERV
//*DATASET DDNAME=STEP1.DD1
.
.
data
.
//*ENDDATASET
//*ENDPROCESS
//*OPERATOR THIS IS TEST JOB TEST1.
//*MAIN CLASS=C
//*FORMAT PR,DDNAME=STEP1.DD2,DEST=ANYLOCAL,COPIES=2
//*ROUTE XEQ NODE1
//FARJOB1 JOB ,,MSGCLASS=A
//STEP1 EXEC PGM=CHECKER
//DD1 DD DSNAME=INPUT
//DD2 DD SYSOUT=A
/*

Example 2
//RUN2 JOB ,,MSGCLASS=A
//*MAIN CLASS=B
//*FORMAT PR,DDNAME=STEPA.DD2,DEST=ANYLOCAL,COPIES=5
//STEPA EXEC PGM=WRITER
//DD1 DD DSNAME=IN1,DISP=OLD,UNIT=3350,VOLUME=SER=MH2244
//DD2 DD SYSOUT=A
/*

JES3 Command Statement

Purpose

Use the command statement to enter a JES3 operator command through the input
stream.

JES3 usually executes an in-stream command as soon as it is read. Therefore, the

command will not be synchronized with the execution of any job or step in the input
stream. To synchronize a command with job processing, tell the operator the
commands you want and when they should be issued, then let the operator enter
them from the console.

References

For more information on the command statement and the JES3 verbs and
operands, see the section ″Entering Commands through the Input Stream″ in z/OS
JES3 Commands.

Syntax
//**command-verb[,operand]...

The JES3 command statement consists of the characters //** in columns 1 through 4, the
command verb beginning in column 5, and, if the command requires operands, a comma
followed by the operands up through column 72. JES3 ignores columns 73 through 80.

Do not continue command statements from one card image to the next.

28-2 z/OS V1R3.0 MVS JCL Reference

 JES3: Command
Parameter Definition
*command-verb
Indicates one of the following JES3 commands. Do not specify a *DUMP or
*RETURN command on a JES3 command statement.
Command
Short Form

CALL X
CANCEL
C
DELAY
D
DISABLE
H
ENABLE
N
ERASE
E
FAIL
FREE
INQUIRY
I
MESSAGE
Z
MODIFY
F
RESTART
R
SEND T
START
S
SWITCH

VARY V
operand
Specifies an operand that pertains to the command-verb.

Location in the JCL

v Place JES3 command statements before the first JOB statement in the input
stream, if you are also submitting jobs. JES3 treats any JES3 command
statements that follow the JOB statement as comment statements.
v You may enter several command statements at one time.
v You may enter command statements through card, tape, or disk readers.
v You may place command statements as the first statements in an active card
reader that you are restarting.
v You may not enter command statements through an internal reader (by issuing a
TSO/E Submit command) or from another node.

Examples of the Command Statement

Example 1

Chapter 28. JES3 Control Statements 28-3

JES3: Command
//**VARY,280,OFFLINE
//**V,281,OFFLINE
//**VARY,282,OFF

//**V,280-282,OFF

In this example, the first three statements each vary one device offline. Alternatively,
the fourth statement varies all three devices offline. If you place these statements in
card reader 01C, for example, and that card reader is currently not in use, the
operator would enter through the operator console:
*X CR,IN=01C

Example 2
//**MESSAGE,CN1,OUTPUT FROM JOB X REQUIRES SPECIAL CONTROLS

This statement instructs the operator from a remote location. Place this statement
before the first job in the input stream.

//*DATASET Statement
Purpose

Use the //*DATASET statement to identify the beginning of an in-stream data set,
which can contain JCL statements or data. (The //*ENDDATASET statement ends
the in-stream data set.) The data set can be used as input to a dynamic support
program (DSP), such as OUTSERV.

Note: Make sure the operator includes a C operand on the *CALL command for
the reader that reads a job containing this statement if it contains a
MODE=C parameter.

Syntax
//*DATASET DDNAME=ddname[,parameter]...

The parameters are:

MODE= {E}
{C}

J= {YES}
{NO }

CLASS= {NO }
{MSGCLASS}
{class }

The //*DATASET statement consists of the characters //* in columns 1 through 3, DATASET
in columns 4 through 10, a blank in column 11, and parameters in columns 12 through 72.
JES3 ignores columns 73 through 80.

Parameter Definition
DDNAME=ddname
Specifies the name of the in-stream data set that follows the //*DATASET
statement.
MODE=E

28-4 z/OS V1R3.0 MVS JCL Reference

 JES3: //*DATASET
MODE=C
Defines the card-reading mode.
E Indicates that JES3 is to read the statements as EBCDIC with validity
checking. E is the default if the MODE parameter is omitted.
C Indicates that JES3 is to read the statements in card image form, that is, in
column binary or data mode 2.
MODE=C is not valid for jobs read from disk or tape, or for jobs submitted
from remote work stations.
J=YES
J=NO
Indicates how JES3 is to recognize the end of the data set.
If you specify MODE=C, JES3 ignores the J parameter; therefore, use a
//*ENDDATASET statement to end the data set
YES
Indicates that a //*ENDDATASET statement ends the data set. Specify YES
when JOB statements appear in the data set.
NO
Indicates that a JOB statement ends the data set. NO is the default if the J
parameter is omitted, unless MODE=C is specified.
CLASS=NO
CLASS=MSGCLASS
CLASS=class
Identifies the output class JES3 is to use for the data set.
NO
Indicates that the system is to assign an output class. If you omit the
CLASS parameter, the default is NO.
MSGCLASS
Requests the output class in the MSGCLASS parameter on the JOB
statement.
class
Specifies the output class.

Location in the JCL

Place a //*DATASET statement immediately before the first record of an in-stream
data set.

Example of the //*DATASET Statement

//*PROCESS OUTSERV
//*DATASET DDNAME=MYPRINT,J=YES
.
.
data
.
.
//*ENDDATASET
//*FORMAT PR,DDNAME=MYPRINT,COPIES=5
//STEP1 EXEC ...
.
.

Chapter 28. JES3 Control Statements 28-5

JES3: //*DATASET
In this example, the //*DATASET statement marks the beginning of the in-stream
data set MYPRINT. The //*FORMAT PR statement requests five copies of it. The
//*ENDDATASET statement marks the end of the data set.

//*ENDDATASET Statement
Purpose

Use the //*ENDDATASET statement to indicate the end of an in-stream data set that
was begun with a //*DATASET statement.

Syntax
//*ENDDATASET

The //*ENDDATASET statement consists of the characters //* in columns 1 through 3 and
ENDDATASET in columns 4 through 13. Columns 14 through 80 must be blank.

Location in the JCL

Place a //*ENDDATASET statement immediately after the last record of an
in-stream data set that was begun with a //*DATASET statement.

Example of the //*ENDDATASET Statement

//*DATASET DDNAME=INFO,J=YES
.
.
data
.
.
//*ENDDATASET

In this example, the //*ENDDATASET statement marks the end of the in-stream
data set INFO.

//*ENDPROCESS Statement
Purpose

Use the //*ENDPROCESS statement to indicate the end of a series of //*PROCESS

statements in a job.

Syntax
//*ENDPROCESS [comments]

The //*ENDPROCESS statement consists of the characters //* in columns 1 through 3,

ENDPROCESS in columns 4 through 13, a blank in column 14, and, optionally, comments
starting in any column beginning with 15. JES3 ignores columns 73 through 80.

Location in the JCL

Place a //*ENDPROCESS statement immediately after the last //*PROCESS
statement in a job. The //*ENDPROCESS statement is optional if a JCL statement
follows the last //*PROCESS statement.

28-6 z/OS V1R3.0 MVS JCL Reference

 JES3: //*ENDPROCESS
Do not place any //*PROCESS statements after the //*ENDPROCESS statement.

Example of the //*ENDPROCESS Statement

//*ENDPROCESS END OF PROCESS STATEMENTS

//*FORMAT PR Statement
Purpose

Use the //*FORMAT PR statement to specify to JES3 processing instructions for

sysout data sets that are printed. These instructions permit special processing of
sysout data sets, such as:
v Multiple destinations.
v Multiple copies of output with different attributes.
v Forced single or double space control.
v Printer overflow checking.

//*FORMAT PR statements can be either specific or nonspecific. A specific

//*FORMAT PR statement contains a DDNAME parameter that specifies something
other than a null value, such as DDNAME=ddname or DDNAME=JESYSMSG. A
nonspecific //*FORMAT PR statement contains DDNAME= , with no value (null)
specified for the DDNAME parameter.

You can code multiple specific //*FORMAT PR statements for a particular sysout
data set to specify special requirements for different copies of the data set. In
addition, you can code a //*FORMAT PU statement for the same sysout data set,
thereby both printing and punching it.

You can also code multiple nonspecific //*FORMAT PR statements. In this case, the
system produces only one copy of each data set, combining any parameter values
specified on the statements. If you specify a given parameter on more than one of
these statements, the system uses the parameter value specified on the last
//*FORMAT PR statement containing that parameter.

Note: The //*FORMAT PR statement applies only to sysout data sets printed by
JES3. The statement is ignored for data sets sent to a TSO/E userid or
processed by an external writer.

Reference

For examples of //*FORMAT statement processing on the JES3 hold queue and
writer queue, see z/OS JES3 Initialization and Tuning Guide.

Chapter 28. JES3 Control Statements 28-7

JES3: //*FORMAT PR
Syntax
//*FORMAT PR,DDNAME= {ddname } [,parameter]...
{stepname.ddname } ,parameter]...
{stepname.procstepname.ddname}
{JESYSMSG }
{JESJCL }
{JESMSGLG }

//*FORMAT PR,DDNAME=[,parameter]...

The parameters are:

{ CARRIAGE= {carriage-tape-name} }
{ {6 } }
{ FCB= {image-name} }
{ {6 } }

CHARS= {STANDARD }
{table-name }
{(table-name[,table-name]...)}

CHNSIZE= {DS }
{(nnn[,mmm])}

COMPACT=compaction-table-name

CONTROL= {PROGRAM}
{SINGLE }
{DOUBLE }
{TRIPLE }

COPIES= {nnn }
{(nnn,(group-value[,group-value]...))}
{(group-value[,group-value]...) }

28-8 z/OS V1R3.0 MVS JCL Reference

 JES3: //*FORMAT PR

DEST= {ANYLOCAL }
{device-name }
{device-number }
{group-name }
{nodename[.remote] }
{(type[,device-name]) }
{(type[,device-number])}
{(type[,group-name]) }

EXTWTR=name

FLASH= {STANDARD }
{overlay-name }
{(overlay-name[,count])}

FORMS= {STANDARD }
{form-name}

MODIFY= {module-name }
{(module-name[,trc])}

OVFL= {ON }
{OFF}

PRTY=nnn

STACKER= {STANDARD}
{S }
{C }

THRESHLD=limit

TRAIN= {STANDARD }
{train-name}

The //*FORMAT PR statement consists of the characters //* in columns 1 through 3,

FORMAT in columns 4 through 9, and a blank in column 10. PR begins in column 11 or
beyond, followed by a comma, and parameters start after the command and can continue
through column 72. JES3 ignores columns 73 through 80.

Parameter Definition
PR
Indicates that this statement is associated with a sysout data set that is printed.
DDNAME=
DDNAME=ddname
DDNAME=stepname.ddname
DDNAME=stepname.procstepname.ddname
DDNAME=procstepname.ddname
DDNAME=JESYSMSG
DDNAME=JESJCL
DDNAME=JESMSGLG
(null)
Specifies that the parameters on this //*FORMAT PR statement are the
defaults for the job. These parameters then apply to all of the job’s sysout
data sets that are printed, except those covered by a //*FORMAT PR
statement with a value other than (null) for DDNAME.

Chapter 28. JES3 Control Statements 28-9

JES3: //*FORMAT PR
Overrides: Parameters coded on a nonspecific //*FORMAT PR statement
are overridden by parameters coded on sysout DD statements or by
parameters in the JES3 SYSOUT initialization statement.
ddname
stepname.ddname
stepname.procstepname.ddname
procstepname.ddname
Identifies the DD statement that defines the sysout data set to be printed;
for example, ddname indicates all DD statements with the name, ddname,
in this job. Stepname.ddname indicates DD statement, ddname, in step,
stepname, in this job. Stepname.procstepname.ddname indicates DD
statement, ddname, in procedure step, procstepname, of a procedure that
is called by a step, stepname, in this job. The ddname must match exactly
the ddname on the DD statement. (See the example for the //*DATASET
statement.) If the identified DD statement does not contain a SYSOUT
parameter, JES3 ignores the //*FORMAT PR statement.

Note: If a ddname matches more than one //*FORMAT PR statement, the

//*FORMAT PR statement that has more qualifiers for the ddname
will override the others. See page 28-16.
JESYSMSG
Requests printing of system messages for this job.
JESJCL
Requests printing of JCL statements and messages for this job.
JESMSGLG
Requests printing of JES3 and operator messages for this job.
CARRIAGE=carriage-tape-name
CARRIAGE=6
Specifies the carriage tape for the 3211, 3203 Model 5, or 1403 Printer for
printing this output class.
carriage-tape-name
Identifies the name of the carriage tape. The name is 1 through 8
characters. For the 3211 and 3203-5, SYS1.IMAGELIB must contain a
module for each carriage tape name.
6 Indicates the installation standard carriage tape.

Note: You cannot code both the CARRIAGE and FCB parameters on the same
//*FORMAT PR statement.
CHARS=STANDARD
CHARS=table-name
CHARS=(table-name[,table-name]...)
Requests one or more character-arrangement tables for printing the sysout data
set on a 3800 Printing Subsystem.
STANDARD
Indicates the standard character-arrangement table, which was specified at
JES3 initialization.
table-name
Identifies a character-arrangement table. Each table-name is 1 through 4
alphanumeric or national ($, #, @) characters. When coding more than one
table-name, parentheses are required around the list and null positions are
invalid in the list.

28-10 z/OS V1R3.0 MVS JCL Reference

 JES3: //*FORMAT PR
CHNSIZE=DS
CHNSIZE=(nnn[,mmm])
Gives the number of logical records to be transmitted to a work station as a
systems network architecture (SNA) chain and indicates whether normal output
checkpoints are to be taken for this sysout data set.

Note: This parameter is valid only when transmitting to a SNA work station.

Be careful in selecting subparameters, because each affects performance

differently. Sending the data set as a SNA chain provides the best performance,
but can cause duplicate data to be written to the output device if operator
intervention is required. The remote operator can eliminate duplicate data by
issuing commands to reposition and restart the output writers.

When an end-of-chain indicator is sent in the data set, JES3 takes an output
checkpoint. You can provide additional checkpoints for critical data by sending
an end-of-chain indicator. For example, when printing bank checks, you can
have an output checkpoint taken for each check by specifying each check as a
SNA chain.
DS
Indicates that the sysout data set is to be sent as a single SNA chain and
that JES3 is not to take normal output checkpoints. DS is the default if the
CHNSIZE parameter is omitted.
nnn
Specifies the SNA chain size in pages. nnn is a decimal number from 1
through 255. The size of a page is determined by:
v The value of mmm.
v The carriage control characters in the data that skip to channel 1.
mmm
Specifies the number of logical records in a page, when the data contains
no carriage control characters. mmm is a decimal number from 1 through
255.
COMPACT=compaction-table-name
Specifies the compaction table for JES3 to use when sending a systems
network architecture (SNA) data set to a SNA remote terminal. The
compaction-table-name is a symbolic name defined by the installation during
JES3 initialization. The name is 1 through 8 alphanumeric characters.
In the following cases, JES3 performs compaction using an installation default
table, if defined, or sends the data without compacting it, if no table was
defined. In all cases, JES3 writes a message to the console.
v No compaction table is specified.
v The specified compaction table is invalid.
v JES3 cannot find the specified compaction table.

If the remote printer does not support compaction, JES3 ignores the COMPACT
parameter and sends the data without compacting it.
CONTROL=PROGRAM
CONTROL=SINGLE
CONTROL=DOUBLE
CONTROL=TRIPLE
Indicates either that the data records control printing or that the output is to be
printed with single, double, or triple spacing.

Chapter 28. JES3 Control Statements 28-11

JES3: //*FORMAT PR
PROGRAM
Indicates that each logical record in the data set begins with a carriage
control character. You can specify in the DD statement, the DCB macro, or
the data set label that an optional control character is part of each record in
the data set. The carriage control characters can be in either the extended
USASCII code or can be the actual channel command code. The carriage
control characters are given in z/OS DFSMS: Using Data Sets.
SINGLE
Requests single spacing.
DOUBLE
Requests double spacing.
TRIPLE
Requests triple spacing.
COPIES=nnn
COPIES=(nnn,(group-value[,group-value]...))
COPIES=(group-value[,group-value]...)
Indicates how many copies of the sysout data set to print. If you do not specify
a COPIES parameter, the default is 1.
You can omit the parentheses if you code only nnn.
nnn
A number from 1 through 254 that specifies how many copies of the data
set to print. Each copy will be in page sequence order.
If you code COPIES=0 on the DD statement, the system uses a default of
1, which is the default for the DD COPIES parameter.
JES3 ignores nnn if any group-values are specified.
group-value
Specifies how many copies of each page are to be printed before the next
page is printed. Each group-value is a number from 1 through 255. You can
code a maximum of eight group-values. Their sum must not exceed 255.
The total copies of each page equals the sum of the group-values.
This subparameter is valid only for output on a 3800 Printing Subsystem.
Group values override an nnn subparameter.
DEST=destination
Routes the output from the sysout data set to a printer. This parameter
overrides the //*MAIN statement ORG parameter.
If you omit DEST, JES3 assigns the first available printer that is in the origin
group and that fulfills all processing requirements. The origin group is the group
of printers defined for the local or remote submitting location. If the job
originated at a remote job processing (RJP) terminal, JES3 returns the output to
the originating terminal group.
If the job was submitted through TSO/E to the NJE network for execution, the
default is the node from which the job was submitted, and the destination
ANYLOCAL.
ANYLOCAL
Indicates any local printer that is being used for the output class specified in
the SYSOUT parameter on the DD statement and that is attached to the
global processor.

28-12 z/OS V1R3.0 MVS JCL Reference

 JES3: //*FORMAT PR
device-name
Requests a local device by a symbolic name defined by the installation
during JES3 initialization. device-name is 1 through 8 alphanumeric or
national ($, #, @) characters.
device-number
Identifies a specific device by a 3-digit or 4-digit hexadecimal number.
Precede a 4-digit number with a slash (/). A 3-digit number can be specified
with or without a slash.
group-name
Identifies a group of local devices, an individual remote station, or a group
of remote stations by a symbolic name defined by the installation during
JES3 initialization. group-name is 1 through 8 alphanumeric or national ($,
#, @) characters.
nodename
Identifies a node by a symbolic name defined by the installation during
JES3 initialization. nodename is 1 through 8 alphanumeric or national ($, #,
@) characters.
remote
Identifies a remote work station or VM userid to which the receiving node
directs output. remote is 1 through 8 characters.
(type)
Indicates a device classification. type is in the form (gggssss) where ggg is
the general device classification and ssss is the specific device
classification. The type must be enclosed in parentheses. The type must be
defined by the installation during JES3 initialization. For example, type for a
3800 is (PRT3800).
EXTWTR=name
Identifies the external writer that is to process the sysout data set at the
destination node. name is 1 through 8 alphanumeric characters and must
identify a module defined to the remote JES3 node that is to execute the job.
(Do not code NJERDR, it is reserved for JES3.)
FCB=image-name
FCB=6
Specifies the forms control buffer (FCB) image JES3 is to use to guide printing
of the sysout data set by a 1403 Printer, 3211 Printer, 3203 Printer Model 5,
4245 Printer, 4248 Printer, or 3800 Printing Subsystem, or by a printer
supported by systems network architecture (SNA) remote job processing (RJP).
If the data set is to be produced on some other device, JES3 ignores the FCB
parameter.
image-name
Identifies the FCB image. The name is 1 through 4 alphanumeric or national
($, #, @) characters and is the last characters of a SYS1.IMAGELIB
member name:
v FCB2xxxx member for a 3211, 3203 model 5, or printer supported by
SNA.
v FCB3xxxx member for a 3800.
v FCB4xxxx member for a 4248.
6 Indicates the standard FCB. JES3 uses the standard FCB specified at JES3
initialization.

Chapter 28. JES3 Control Statements 28-13

JES3: //*FORMAT PR
Note: You cannot code both the CARRIAGE and FCB parameters on the same
//*FORMAT PR statement.
FLASH=STANDARD
FLASH=overlay-name
FLASH=(overlay-name[,count])
Identifies the forms overlay to be used in printing the sysout data set on a 3800
Printing Subsystem and, optionally, to specify the number of copies on which
the forms overlay is to be printed.
You can omit the parentheses if you code only an overlay-name. If you omit the
count subparameter or specify a count of 0, JES3 flashes all copies with the
specified overlay.
STANDARD
Indicates the standard forms flash overlay. JES3 uses the standard forms
overlay specified at JES3 initialization.
overlay-name
Identifies the forms overlay frame that the operator is to insert into the
printer before printing begins. The name is 1 through 4 alphanumeric or
national ($, #, @) characters.
count
Specifies the number, 0 through 255, of copies that JES3 is to flash with
the overlay, beginning with the first copy printed. Code a count of 0 to flash
all copies.

Note: See the Forms Design Reference Guide for the 3800 for information on
designing and making forms overlays.
FORMS=STANDARD
FORMS=form-name
Indicates the forms on which the sysout data set is to be printed.
STANDARD
Indicates the standard form. JES3 uses the standard form specified at JES3
initialization.
form-name
Names the print forms. form-name is 1 through 8 alphanumeric characters.
MODIFY=module-name
MODIFY=(module-name[,trc])
Specifies a copy modification module that tells JES3 how to print the sysout
data set on a 3800 Printing Subsystem. The module can specify how to replace
blanks or data in the data set. You can omit the parentheses if you code only a
module-name.
The module is defined and stored in SYS1.IMAGELIB using the IEBIMAGE
utility program. See z/OS DFSMSdfp Utilities for more information.
If you omit the trc subparameter, JES3 prints the data set with the first
character-arrangement table coded in the CHARS parameter.
module-name
Identifies a copy modification module in SYS1.IMAGELIB. module-name is
1 through 4 alphanumeric or national ($, #, @) characters.
trc
Identifies which table-name in the CHARS parameter is to be used. This

28-14 z/OS V1R3.0 MVS JCL Reference

 JES3: //*FORMAT PR
table reference character is 0 for the first table-name specified, 1 for the
second, 2 for the third, or 3 for the fourth.
OVFL=ON
OVFL=OFF
Indicates whether or not the printer program should test for forms overflow.
Because the overflow test is a responsibility of the terminal package for the
remote RJP terminal, JES3 ignores OVFL for remote job processing.
ON
Indicates that the printer program should eject whenever the end-of-forms
indicator (channel 12) is sensed. ON is the default if the OVFL parameter is
omitted.
OFF
Indicates that forms overflow control is not to be used.
PRTY=nnn
Specifies the priority at which the sysout data set enters the output queue. nnn
is a decimal number from 0 through 255; 0 is the lowest priority while 255 is the
highest.
STACKER=STANDARD
STACKER=S
STACKER=C
Requests a stacker for 3800 Printing Subsystem output.
STANDARD
Indicates the standard installation default. This default is specified at JES3
initialization.
S Indicates the burster-trimmer-stacker, in which the output is burst into
separate sheets.
C Indicates the continuous forms stacker, in which the output is left in
continuous fanfold.
THRESHLD=limit
Specifies the maximum size for the sysout data set. JES3 calculates the sysout
data set size as the number of records multiplied by the number of copies
requested. When this size exceeds the THRESHLD value, JES3 creates a new
unit of work, on a data set boundary, and queues it for printing. Consequently,
copies of the sysout data set may be printed simultaneously by different
printers.
Use the THRESHLD parameter for jobs that generate many large sysout data
sets. Grouping data sets as a single unit of work for an output service writer
may decrease the time required for the output service writer to process the data
sets.
The value specified in this parameter overrides the value specified during JES3
initialization.
limit
Specifies the maximum records for a single sysout data set. limit is a
decimal number from 1 through 99999999. The default is 99999999.
TRAIN=STANDARD
TRAIN=train-name
Indicates the printer train to be used in printing the sysout data set. See

Chapter 28. JES3 Control Statements 28-15

JES3: //*FORMAT PR
Table 12-2 on page 12-201 for the IBM-supplied trains. Because these trains are
not standard machine features, verify that the installation has the required
printer train before specifying it.
Do not code the TRAIN parameter for output destined for a remote job
processing (RJP) terminal.
STANDARD
Indicates the standard installation default. This default is specified at JES3
initialization.
train-name
Specifies an installation-supplied printer train. Check with your installation
for the names of trains.

Relationship to Sysout DD and OUTPUT JCL Statements

v JES3 ignores the processing options specified on a default //*FORMAT statement
when a sysout DD statement explicitly or implicitly references an OUTPUT JCL
statement.
v JES3 ignores the processing options specified on a default OUTPUT JCL
statement when a //*FORMAT statement explicitly references a sysout DD
statement.
v When a sysout DD statement explicitly references an OUTPUT JCL statement
and a //*FORMAT statement explicitly references the same DD statement, the
processing options from both the OUTPUT JCL and //*FORMAT statements
apply. Two separate sets of output are created from the data set defined by the
sysout DD statement; one according to the processing options on the OUTPUT
JCL and DD statements, and the other according to the processing options on
the //*FORMAT and DD statements.

Relationship to //*PROCESS Statement

JES3 accumulates //*FORMAT PR statements within a job and applies them to any
JES3 //*PROCESS statement that is normally affected by a //*FORMAT PR
statement.

Location in the JCL

Place all //*FORMAT PR statements for the job after the JOB statement and before
the first EXEC statement.

Examples of the //*FORMAT PR Statement

Example 1
//*FORMAT PR,DDNAME=STEP1.REPORT,COPIES=2

This statement requests two copies of the data set defined by sysout DD statement
REPORT, which appears in STEP1 of this job. Any printer with standard forms,
train, and carriage tape can be used.

Example 2
//*FORMAT PR,DDNAME=,DEST=ANYLOCAL

This statement specifies that all sysout data sets not referenced by //*FORMAT PR
statements are to be printed on any local printer.

Example 3

28-16 z/OS V1R3.0 MVS JCL Reference

 JES3: //*FORMAT PR
//*FORMAT PR,DDNAME=STEP1.REPORT,DEST=A
//*FORMAT PR,DDNAME=REPORT,DEST=B

This statement requests one copy of the data set defined by sysout DD statement
REPORT, which appears in STEP1 of this job, to be sent to destination A and one
copy of the data set defined by sysout DD statement REPORT to be sent to
destination B. The REPORT data set for STEP1 is sent to destination A because
the //*FORMAT PR statement with more qualifiers for the same ddname overrides
the other. The REPORT data set for any other step is sent to destination B.

//*FORMAT PU Statement
Purpose

Use the //*FORMAT PU statement to specify to JES3 processing instructions for

sysout data sets that are punched. These instructions permit special processing of
sysout data sets, such as:
v Multiple destinations.
v Multiple copies of output with different attributes.

Use the //*FORMAT PU statement to specify to JES3 processing instructions for

sysout data sets that are punched. These instructions permit special processing of
sysout data sets, such as:
v Multiple destinations.
v Multiple copies of output with different attributes.

//*FORMAT PU statements can be either specific or nonspecific. A specific

//*FORMAT PU statement contains a DDNAME parameter that specifies something
other than a null value, such as DDNAME=ddname or DDNAME=JESYSMSG. A
nonspecific //*FORMAT PU statement contains DDNAME= , with no value (null)
specified for the DDNAME parameter.

You can code multiple specific //*FORMAT PU statements for a particular sysout
data set to specify special requirements for different copies of the data set. In
addition, you can code a //*FORMAT PR statement for the same sysout data set,
thereby both printing and punching it.

You can also code multiple nonspecific //*FORMAT PU statements. In this case, the
system produces only one copy of each data set, combining any parameter values
specified on the statements. If you specify a given parameter on more than one of
these statements, the system uses the parameter value specified on the last
//*FORMAT PU statement containing that parameter.

Note: The //*FORMAT PU statement applies only to sysout data sets punched by
JES3. The statement is ignored for data sets sent to a TSO/E userid or
processed by an external writer.

Reference

For examples of //*FORMAT statement processing on the JES3 hold queue and
writer queue, see z/OS JES3 Initialization and Tuning Guide.

Chapter 28. JES3 Control Statements 28-17

JES3: //*FORMAT PU
Syntax
//*FORMAT PU,DDNAME= {ddname } [,parameter]...
{stepname.ddname } parameter]...
{stepname.procstepname.ddname}

//*FORMAT PU,DDNAME=[,parameter]...

The parameters are:

CHNSIZE= {DS }
{(nnn[,mmm])}

COMPACT=compaction-table-name

COPIES=nnn

DEST= {ANYLOCAL }
{device-name }
{device-number }
{group-name }
{nodename[.remote] }
{(type[,device-name]) }
{(type[,device-number])}
{(type[,group-name]) }

EXTWTR=name

FORMS= {STANDARD }
{form-name}

INT= {YES}
{NO }

The //*FORMAT PU statement consists of the characters //* in columns 1 through 3,

FORMAT in columns 4 through 9, and a blank in column 10. PU begins in column 11 or
beyond, followed by a comma, and parameters start after the comma and continue through
column 72. JES3 ignores columns 73 through 80.

Parameter Definition
PU
Indicates that this statement is associated with a sysout data set that is
punched.
DDNAME=
DDNAME=ddname
DDNAME=stepname.ddname
DDNAME=stepname.procstepname.ddname
(null)
Specifies that the parameters on this //*FORMAT PU statement are the
defaults for the job. These parameters then apply to all of the job’s sysout
data sets that are punched except those covered by a //*FORMAT PU
statement with a value other than (null) for DDNAME.
Overrides: Parameters coded on a nonspecific //*FORMAT PU statement
are overridden by parameters coded on sysout DD statements or by
parameters in the JES3 SYSOUT initialization statement.
ddname
stepname.ddname

28-18 z/OS V1R3.0 MVS JCL Reference

 JES3: //*FORMAT PU
stepname.procstepname.ddname
Identifies the DD statement that defines the sysout data set to be punched.
Use form ddname to indicate all DD statements with the name, ddname, in
this job. Use form stepname.ddname to indicate DD statement, ddname, in
step, stepname, in this job. Use form stepname.procstepname.ddname to
indicate DD statement, ddname, in procedure step, procstepname, of a
procedure that is called by a step, stepname, in this job. The ddname must
match exactly the ddname on the DD statement. (See the example for the
//*DATASET statement.) If the identified DD statement does not contain a
SYSOUT parameter, JES3 ignores the //*FORMAT PU statement.

Note: If a ddname matches more than one //*FORMAT PU statement, the

//*FORMAT PU statement that has more qualifiers for the ddname
will override the others. See page 28-22.
CHNSIZE=DS
CHNSIZE=(nnn[,mmm])
Gives the number of logical records to be transmitted to a work station as a
systems network architecture (SNA) chain and indicates whether normal output
checkpoints are to be taken for this sysout data set.

Note: This parameter is valid only when transmitting to a SNA work station.

Be careful in selecting subparameters, because each affects performance

differently. Sending the data set as a SNA chain provides the best performance,
but can cause duplicate data to be written to the output device if an operator
intervention is required. The remote operator can eliminate duplicate data by
issuing commands to reposition and restart the output writers.

When an end-of-chain indicator is sent in the data set, JES3 takes an output
checkpoint. You can provide additional checkpoints for critical data by sending
an end-of-chain indicator. For example, when punching bank checks, you can
have an output checkpoint taken for each check by specifying each check as a
SNA chain.
DS
Indicates that the sysout data set is to be sent as a single SNA chain and
that JES3 is not to take normal output checkpoints. DS is the default if the
CHNSIZE parameter is omitted.
nnn
Specifies the SNA chain size in pages. nnn is a decimal number from 1
through 255. The size of a page is determined by the value you assign to
mmm.
mmm
Specifies the number of logical records in a page. mmm is a decimal
number from 1 through 255.
COMPACT=compaction-table-name
Specifies the compaction table for JES3 to use when sending a systems
network architecture (SNA) data set to a SNA remote terminal. The
compaction-table-name is a symbolic name defined by the installation during
JES3 initialization. The name is 1 through 8 alphanumeric characters.
In the following cases, JES3 performs compaction using an installation default
table, if defined, or sends the data without compacting it, if no table was
defined. In all cases, JES3 writes a message to the console.
v No compaction table is specified.

Chapter 28. JES3 Control Statements 28-19

JES3: //*FORMAT PU
v The specified compaction table is invalid.
v JES3 cannot find the specified compaction table.

If the remote punch does not support compaction, JES3 ignores the COMPACT
parameter and sends the data without compacting it.
COPIES=nnn
Indicates how many copies of the sysout data set are to be punched. nnn is a
number from 0 through 255. If you code COPIES=0, JES3 does not punch this
data set. If a COPIES parameter is not specified, the default is 1.
DEST=destination
Routes the output from the sysout data set to a punch. This parameter
overrides the //*MAIN statement ORG parameter.
If you omit DEST, JES3 assigns the first available punch that is in the origin
group and that fulfills all processing requirements. The origin group is the group
of punches defined for the local or remote submitting location. If the job
originated at a remote job processing (RJP) terminal, JES3 returns the output to
the originating terminal group.
If the job was submitted through TSO/E to the NJE network for execution, the
default is the node from which the job was submitted, and the destination
ANYLOCAL.
ANYLOCAL
Indicates any local punch that is being used for the output class specified in
the SYSOUT parameter on the DD statement and that is attached to the
global processor.
device-name
Requests a local device by a symbolic name defined by the installation
during JES3 initialization. device-name is 1 through 8 alphanumeric or
national ($, #, @) characters.
device-number
Specifies the 3-digit or 4-digit hexadecimal device number. Precede a
4-digit number with a slash (/). A 3-digit number can be specified with or
without a slash.
group-name
Identifies a group of local devices, an individual remote station, or a group
of remote stations by a symbolic name defined by the installation during
JES3 initialization. group-name is 1 through 8 alphanumeric or national ($,
#, @) characters.
nodename
Identifies node by a symbolic name defined by the installation during JES3
initialization. nodename is 1 through 8 alphanumeric or national ($, #, @)
characters.
remote
Identifies a remote work station or VM userid to which the receiving node
directs output. remote is 1 through 8 characters.
(type)
Indicates a device classification. type is in the form (gggssss) where ggg is
the general device classification and ssss is the specific device
classification. The type must be enclosed in parentheses. The type must be
defined by the installation during JES3 initialization. For example, type for a
3525 is (PUN3525).

28-20 z/OS V1R3.0 MVS JCL Reference

 JES3: //*FORMAT PU
EXTWTR=name
Identifies the external writer that is to process the sysout data set at the
destination node. name is 1 through 8 alphanumeric characters and must
identify a module defined to the remote JES3 node that is to execute the job.
FORMS=STANDARD
FORMS=form-name
Indicates the forms on which the sysout data set is to be punched.
STANDARD
Indicates the standard form. JES3 uses the standard form specified at JES3
initialization.
form-name
Names the punch forms. form-name is 1 through 8 alphanumeric
characters.
INT=YES
INT=NO
Specifies whether or not the output is to be interpreted. If the INT parameter is
omitted, the default is NO.
YES
Requests that JES3 try to punch the sysout data set on a 3525 Card Punch
(PUN3525I) with a Multiline Card Print feature.

Note: If the DEST parameter does not send output to a 3525I, JES3
ignores INT=YES, if specified.
NO
Requests that the cards not be interpreted.

Relationship to Sysout DD and OUTPUT JCL Statements

v JES3 ignores the processing options specified on a default //*FORMAT statement
when a sysout DD statement explicitly or implicitly references an OUTPUT JCL
statement.
v JES3 ignores the processing options specified on a default OUTPUT JCL
statement when a //*FORMAT statement explicitly references a sysout DD
statement.
v When a sysout DD statement explicitly references an OUTPUT JCL statement
and a //*FORMAT statement explicitly references the same DD statement, the
processing options from both the OUTPUT JCL and //*FORMAT statements
apply. Two separate sets of output are created from the data set defined by the
sysout DD statement; one according to the processing options on the OUTPUT
JCL and DD statements, and the other according to the processing options on
the //*FORMAT and DD statements.

Relationship to //*PROCESS Statement

JES3 accumulates //*FORMAT PU statements within a job and applies them to any
JES3 //*PROCESS statement that is normally affected by a //*FORMAT PU
statement.

Location in the JCL

Place all //*FORMAT PU statements for the job after the JOB statement and before
the first EXEC statement.

Chapter 28. JES3 Control Statements 28-21

JES3: //*FORMAT PU
Examples of the //*FORMAT PU Statement
Example 1
//*FORMAT PU,DDNAME=STEP2.PUNCHOUT,DEST=PU1,FORMS=RED-STRP

This statement requests that one copy of the data set defined by sysout DD
statement PUNCHOUT in STEP2 of this job be punched on device PU1. Before
processing, the operator is requested to insert RED-STRP cards into the punch.

Example 2
//*FORMAT PU,DDNAME=STEP1.PUNCHOUT,DEST=DEVA
//*FORMAT PU,DDNAME=PUNCHOUT,DEST=DEVB

This statement requests one copy of the data set defined by sysout DD statement
PUNCHOUT in STEP1 of this job to be punched on device DEVA and one copy of
the data set defined by sysout DD statement PUNCHOUT to be punched on device
DEVB. The PUNCHOUT data set for STEP1 is sent to DEVA because the
//*FORMAT PU statement with more qualifiers for the same ddname overrides the
other. The PUNCHOUT data set for any other step is sent to DEVB.

//*MAIN Statement
Purpose

Use the //*MAIN statement to define the processor requirements for the current job.
Many of the parameters are used to override parameters on the JES3
STANDARDS initialization statement.

Note: If any parameter is misspelled or contains an invalid value, JES3 writes the
following to the JESMSG data set: the //*MAIN statement, the relative error
position on the statement, and an error message. Then JES3 abnormally
terminates the job.

28-22 z/OS V1R3.0 MVS JCL Reference

 JES3: //*MAIN
Syntax
//*MAIN parameter[,parameter]...

The parameters are:

ACMAIN=processor-id

BYTES= {([nnnnnn][,WARNING][,mmm])}
{([nnnnnn][,W][,mmm]) }
{([nnnnnn][,CANCEL]) }
{([nnnnnn][,C]) }
{([nnnnnn][,DUMP]) }
{([nnnnnn][,D]) }

CARDS= {([nnnn][,WARNING][,mmm])}
{([nnnn][,W][,mmm]) }
{([nnnn][,CANCEL]) }
{([nnnn][,C]) }
{([nnnn][,DUMP]) }
{([nnnn][,D]) }

CLASS=class-name

DEADLINE= {(time,type[,date]) }
{(time,type[,rel,cycle])}

EXPDTCHK= {YES}
{NO }

FAILURE= {RESTART}
{CANCEL }
{HOLD }
{PRINT }

FETCH= {ALL }
{NONE }
{SETUP }
{(ddname[,ddname]...) }
{/(ddname[,ddname]...)}

HOLD= {YES}
{NO }

IORATE= {MED }
{HIGH}
{LOW }

JOURNAL= {YES}
{NO }

Chapter 28. JES3 Control Statements 28-23

JES3: //*MAIN

LINES= {([nnnn][,WARNING][,mmm])}
{([nnnn][,W][,mmm]) }
{([nnnn][,CANCEL]) }
{([nnnn][,C]) }
{([nnnn][,DUMP]) }
{([nnnn][,D]) }

LREGION=nnnnK

ORG= {group-name }
{nodename[.remote]}

PAGES= {([nnnnnnnn][,WARNING][,mmm])}
{([nnnnnnnn][,W][,mmm]) }
{([nnnnnnnn][,CANCEL]) }
{([nnnnnnnn][,C]) }
{([nnnnnnnn][,DUMP]) }
{([nnnnnnnn][,D]) }

PROC= {ST}
{xx}

RINGCHK= {YES}
{NO }

SETUP= {JOB }
{HWS }
{THWS }
{DHWS }
{(stepname.ddname[,stepname.ddname]...) }
{(stepname.procstepname.ddname[,stepname.procstepname.ddname]...) }
{/(stepname.ddname[,stepname.ddname]...) }
{/(stepname.procstepname.ddname[,stepname.procstepname.ddname]...)}

SPART=partition-name

SYSTEM= {ANY }
{JGLOBAL }
{JLOCAL }
{(main-name[,main-name]...) }
{/(main-name[,main-name]...)}

THWSSEP= {IGNORE }
{PREFER }
{REQUIRE}

TRKGRPS=(primary-qty,second-qty)

TYPE= {ANY}
{VS2}

UPDATE=(dsname[,dsname]...)

USER=userid

The //*MAIN statement consists of the characters //* in columns 1 through 3, MAIN in
columns 4 through 7, a blank in column 8, and parameters in columns 9 through 72. JES3
ignores columns 73 through 80.

Parameter Definition
ACMAIN=processor-id
Identifies the job with the specified processor, even though the job was not
submitted from or run on that processor. ACMAIN allows:

28-24 z/OS V1R3.0 MVS JCL Reference

 JES3: //*MAIN
v Sysout data sets to be sent to a userid attached to the specified processor.
The userid must be named in the USER parameter. The ACMAIN parameter
applies to all sysout data sets for the job.
v Receipt of notification that a job you submitted through batch processing has
completed by coding the ACMAIN parameter on a JES3 //*MAIN statement in
addition to the JOB statement NOTIFY parameter. The ACMAIN parameter
names the processor that you, the TSO/E user, are logged onto.
processor-id
Requests a processor in the complex.
BYTES=([nnnnnn][,WARNING][,mmm])
BYTES=([nnnnnn][,W][,mmm])
BYTES=([nnnnnn][,CANCEL])
BYTES=([nnnnnn][,C])
BYTES=([nnnnnn][.DUMP])
BYTES=([nnnnnn][,D])
Specifies the maximum number of bytes of data to be spooled from this job’s
sysout data sets and the action to be taken if the maximum is exceeded.
If BYTES is not specified, the installation default for this job class applies.
nnnnnn
Specifies the number of bytes in thousands. nnnnnn is 1 through 6 decimal
numbers from 1 through 999999.
WARNING or W
If the maximum is exceeded, requests that JES3 issue an operator warning
message and continue processing.
Any messages about this parameter following the warning message will
reflect the number specified on the STANDARD initialization statement or
the system default, not the specified maximum.
mmm
Specifies the frequency that an operator warning message is to be
issued after the maximum specified by nnnnnn is exceeded. mmm is a
multiple of 10 in the range 10 to 100. mmm is a percentage of nnnnnn
that is used to calculate the number of additional bytes between
warning messages. For example, if BYTES=(100,W,20) is specified, the
first warning message is sent to the operator when 100,000 bytes of
sysout data is reached. Subsequent warning messages are sent when
each additional 20 percent of 100,000 is reached (at 120,000 bytes,
140,000 bytes, and so on). Messages are sent until the job ends or the
operator cancels the job.
CANCEL or C
If the maximum is exceeded, requests that JES3 cancel the job.
DUMP or D
If the maximum is exceeded, requests that JES3 cancel the job and ask for
a storage dump.
CARDS=([nnnn][,WARNING][,mmm])
CARDS=([nnnn][,W][,mmm])
CARDS=([nnnn][,CANCEL])
CARDS=([nnnn][,C])
CARDS=([nnnn][,DUMP])
CARDS=([nnnn][,D])
Specifies the maximum number of cards to be punched from this job’s sysout
data sets and the action to be taken if the maximum is exceeded.

Chapter 28. JES3 Control Statements 28-25

JES3: //*MAIN
If you specify CARDS=0 the zero applies only to the quantity of punched
output; it does not cancel the action to be taken if the maximum is exceeded. If
a record is then sent to a punch, JES3 will warn, cancel, or dump, depending
on the second parameter.

Note: When punching dump output, JES3 ignores CARDS=0.

If CARDS is not specified, the installation default for this job class is used.
nnnn
Specifies the number of cards in hundreds. nnnn is 1 through 4 decimal
numbers from 1 through 9999.
WARNING or W
If the maximum is exceeded, requests that JES3 issue an operator warning
message and continue processing.
Any subsequent messages about this parameter will reflect the number
specified on the STANDARD initialization statement or the system default,
not the maximum specified in the CARDS parameter.
mmm
Specifies the frequency that an operator warning message is to be
issued after the maximum specified by nnnn is exceeded. mmm is a
multiple of 10 in the range 10 to 100. mmm is a percentage of nnnn
that is used to calculate the number of additional cards between
warning messages. For example, if CARDS=(100,W,20) is specified, the
first warning message is sent to the operator when 10,000 cards of
sysout data is reached. Subsequent warning messages are sent when
each additional 20 percent of 10,000 is reached (at 12,000 cards,
14,000 cards, and so on). Messages are sent until the job ends or the
operator cancels the job.
CANCEL or C
If the maximum is exceeded, requests that JES3 cancel the job.
DUMP or D
If the maximum is exceeded, requests that JES3 cancel the job and ask for
a storage dump.
CLASS=class-name
Specifies the job class for this job. class-name is 1 through 8 characters.
If the desired class-name is a single-character, you can specify it on the
//*MAIN statement or the JOB statement.
JES3 uses the following, in override order, to assign the job to a class:
1. //*MAIN statement CLASS parameter
2. JOB statement CLASS parameter
3. The default class, which is defined during JES3 initialization.

If neither CLASS nor LREGION is specified, JES3 determines the logical region
size based on initialization parameters.
DEADLINE=(time,type[,date])
DEADLINE=(time,type[,rel,cycle])
Specifies when the job is required.
When you specify the current date but submit the job after the specified time,
JES3 changes the priorities to make the job the same priority level it would
have if it had been submitted before the deadline but not completed.

28-26 z/OS V1R3.0 MVS JCL Reference

 JES3: //*MAIN
Attention: Deadline scheduling can interfere with dumping a portion of the job
queue. For example, if JOB A is waiting to be scheduled, has a priority of 7,
and, in one minute, is due to have its priority increased to 9, JOB A could be
missed by dump job processing, if the dump job facility is dumping the entire
job queue and currently dumping priority 8 jobs. The dump job facility processes
the jobs with the highest priority first. If the dump job facility does not finish
processing priority 8 jobs before JOB A becomes priority 9, JOB A will not be
dumped.
Deadline scheduling information is not sent with a job when the job is
transferred via NJE to another node; the destination node may use different
deadline scheduling algorithms, if any.
time
Specifies the deadline time, expressed as one of the following:
nM
The job is to be scheduled within n minutes. n is 1 through 4 numbers
from 0 through 1440.
nH
The job is to be scheduled within n hours. n is 1 or 2 numbers from 0
through 24.
hhhh
The job is to be scheduled by the time of day, hhhh, in 24-hour clock
time (0800 is 8:00 a.m.). hhhh is from 0000 (start of the day) through
2400 (end of the day).
type
Identifies the deadline algorithm. The deadline algorithm is defined by the
installation, controls how the job’s priority is increased, and is one
character: A through Z or 0 through 9. If the specified algorithm is not
defined, JES3 abnormally terminates the job.
date
Specifies the date, in one of the following formats, when the time parameter
takes effect.
mmddyy
where mm is the month (01-12), dd the day (01-31), and yy the 2-digit
year (01-99).
mm/dd/yyyy
where mm is the month (01-12), dd the day (01-31), and yyyy the
4-digit year (for example, 1999). Leading zeroes are required in the day
and month fields.
Notes:
1. For dates in the format of mmddyy, a century of ‘19’ is assumed.
2. For dates in the format of mmddyy, a date of ‘00’ is not allowed.
3. For dates of January 1, 2000 and later, you must use the form
mm/dd/yyyy.
4. If both date and rel,cycle are omitted, JES3 assumes (1) the current
date, if the deadline time is later in the day, or (2) the next day’s date, if
the deadline time has already past today.
rel Specifies on which day within a cycle the deadline falls. rel is 1 through 3
numbers from 1 through 366. The value of rel depends on the specified
cycle, as follows:

Chapter 28. JES3 Control Statements 28-27

JES3: //*MAIN
v WEEKLY: Sunday is day 1; Saturday is day 7. If rel is greater than 7, it
defaults to 7.
v MONTHLY: Day 1 is the first day of the month. Days 29, 30, and 31 are
treated as the last day of the month. If rel is greater than 31, it defaults
to 31.
v YEARLY: Day 1 is January 1; day 365 is December 31, for non-leap
years, and day 366 is December 31, for leap years. If rel is greater than
365, it defaults to 365 for non-leap years or 366 for leap years.
cycle
Specifies the length of a cycle. cycle is coded as WEEKLY, MONTHLY, or
YEARLY.

For example, DEADLINE=(1200,B,1,WEEKLY) indicates that the job reaches its

deadline at 12 noon on Sunday. This job would be submitted once a week for it
to be processed every Sunday.
EXPDTCHK=YES
EXPDTCHK=NO
Indicates whether or not JES3 is to perform expiration date checking for scratch
output tape volumes with IBM standard labels (SL).
YES
Requests expiration date checking. Tape volumes premounted for SL
scratch requests must have expired dates.
NO
Requests that expiration dates not be checked.
FAILURE=RESTART
FAILURE=CANCEL
FAILURE=HOLD
FAILURE=PRINT
Indicates the job recovery option to be used if the system fails. If you do not
code a FAILURE parameter on the //*MAIN statement, JES3 assigns the job the
default failure option, which is defined during JES3 initialization for each job
class. (See also the RD parameter on the JOB statement.)

Note: If a job is registered with the automatic restart manager (ARM) at the
time of a system failure, ARM determines whether to restart the job,
regardless of the value specified on the FAILURE keyword.

If the ARM restarts the job, JES discards all non-spin sysout data sets created
during the previous execution. (You can avoid losing that output by adding
SPIN=UNALLOC to the DD statement for the SYSOUT data set.)
RESTART
Requests that JES3 restart the job when the failing processor is restarted.
Do not specify RESTART for jobs that use the DEQ at DEMOUNT facility
for tape volumes.
CANCEL
Requests that JES3 print the job and then cancel the job.
HOLD
Requests that JES3 hold the job for restart.
PRINT
Requests that JES3 print the job and then hold the job for restart.

28-28 z/OS V1R3.0 MVS JCL Reference

 JES3: //*MAIN
FETCH=ALL
FETCH=NONE
FETCH=SETUP
FETCH=(ddname[,ddname]...)
FETCH=/(ddname[,ddname]...)
Determines the fetch messages that will be issued to the operator for disk and
tape volumes for this job.
If FETCH is not specified, the installation default for this job class applies.
ALL
Requests that JES3 issue fetch messages to the operator for all removable
volumes specified in DD statements that request JES3-setup devices. This
subparameter does not apply to permanently resident volumes.
NONE
Requests that JES3 not issue fetch messages.
SETUP
Requests that JES3 issue fetch messages to the operator for the volumes
specified in all DD statements identified in the //*MAIN SETUP parameter. If
you code FETCH=SETUP without also coding the //*MAIN SETUP
parameter, JES3 will issue fetch message as though you had specified
FETCH=ALL.
ddname
Requests that JES3 issue fetch messages for only the volumes specified in
DD statement ddname.
If you code a list of ddnames and the list cannot be contained on a single
statement, FETCH= must be repeated on the continuation statement.
/ddname
Requests that JES3 not issue fetch messages for any volumes specified in
DD statement ddname.
HOLD=YES
HOLD=NO

YES
Indicates that the job is to enter the system in operator-hold status and be
withheld from processing until the operator requests its release. However, if
an error occurs during input service processing, the job is not held for
operator intervention.
This parameter has the same function as TYPRUN=HOLD on the JOB
statement.
NO
Indicates that the job is to enter the system normally. Processing does not
require operator intervention. If the HOLD parameter is omitted, NO is the
default.
IORATE=MED
IORATE=HIGH
IORATE=LOW
Indicates the I/O-to-processor ratio for a job. Use this parameter to balance the
mixture of jobs selected for execution on the processor.

Chapter 28. JES3 Control Statements 28-29

JES3: //*MAIN
If you do not code an IORATE parameter on the //*MAIN statement, JES3
assigns the job the default I/O-to-processor ratio, which is defined during JES3
initialization for each job class.
JOURNAL=YES
JOURNAL=NO
Indicates whether or not JES3 is to create a job journal for the job.
If JOURNAL is omitted, JES3 uses an installation default specified at
initialization. If you use the automatic restart manager (ARM) to restart a job,
you do not need to save the journal because ARM does not use the job journal
when restarting jobs.
YES
Indicates that the job is to have a job journal.
NO
Indicates that the job is not to have a job journal.
LINES=([nnnn][,WARNING][,mmm])
LINES=([nnnn][,W][,mmm])
LINES=([nnnn][,CANCEL)
LINES=([nnnn][,C])
LINES=([nnnn][,DUMP])
LINES=([nnnn][,D])
Indicates the maximum number of lines of data to be printed from this job’s
sysout data sets and the action to be taken if the maximum is exceeded.
If you specify LINES=0 the zero applies only to the number of lines; it does not
cancel the action to be taken if the maximum is exceeded. If a record is sent to
be printed, JES3 will warn, cancel, or dump, depending on the second
parameter.

Note: JES3 ignores any line count specification when printing the output for a
SYSABEND or SYSUDUMP sysout data set.

If LINES is not specified, the installation default for this job class applies. The
installation default is specified on the OUTLIM parameter of the OUTSERV
JES3 initialization statement.
nnnn
Specifies the number of lines, in thousands. nnnn is 1 through 4 decimal
numbers from 1 through 9999.
WARNING or W
If the maximum is exceeded, requests that JES3 issue an operator warning
and continue processing.
Any messages about this parameter following the warning message will
reflect the number specified on the STANDARD initialization statement or
the system default, not the maximum specified in the LINES parameter.
mmm
Specifies the frequency that an operator warning message is to be
issued after the maximum specified by nnnn is exceeded. mmm is a
multiple of 10 in the range 10 to 100. mmm is a percentage of nnnn
that is used to calculate the number of additional lines between warning
messages. For example, if LINES=(100,W,20) is specified, the first
warning message is sent to the operator when 100,000 lines of sysout
data is reached. Subsequent warning messages are sent when each

28-30 z/OS V1R3.0 MVS JCL Reference

 JES3: //*MAIN
additional 20 percent of 100,000 is reached (at 120,000 lines, 140,000
lines, and so on). Messages are sent until the job ends or the operator
cancels the job.
CANCEL or C
If the maximum is exceeded, requests that JES3 cancel the job.
DUMP or D
If the maximum is exceeded, requests that JES3 cancel the job and ask for
a storage dump.
LREGION=nnnnK
Specifies the approximate size of the largest step’s working set in real storage
during execution. LREGION (logical region) is used by JES3 to improve
scheduling on the processor. The nnnn is 1 through 4 decimal numbers that
indicate the size in kilobytes (1 kilobyte = 1024 bytes).
If neither CLASS nor LREGION is coded, JES3 determines the logical region
size based on initialization parameters.
Use the LREGION parameter carefully. If the values selected for LREGION are
too small, the job may take longer to run.
ORG=group-name
ORG=nodename[.remote]
Indicates that the job’s sysout data sets are to be directed to the named group
or network node. Otherwise, the job’s sysout data sets are directed to the group
of devices or node from which the job originated.
group-name
Specifies an origin group.
nodename
Specifies a network node. nodename is 1 through 8 characters.
remote
Specifies a remote work station or VM userid. remote is 1 through 8
characters and must be separated from the nodename by a period.

Overriding an ORG Parameter: If you do not want a particular data set in the
job to go to the destination on the ORG parameter, change its destination in
one of the following ways:
v If the sysout data set is not scheduled to a held class, you can override the
ORG parameter destination with the DEST parameter on a //*FORMAT,
OUTPUT JCL, or DD statement.
v If the sysout data set is scheduled to a held class, you can override the
ORG parameter destination with the DEST parameter on an OUTPUT JCL,
or DD statement.

JES3 ignores the ORG parameter for a dynamically-allocated SYSOUT data

set.
PAGES=([nnnnnnnn][,WARNING][,mmm])
PAGES=([nnnnnnnn][,W][,mmm])
PAGES=([nnnnnnnn][,CANCEL])
PAGES=([nnnnnnnn][,C])
PAGES=([nnnnnnnn][,DUMP])
PAGES=([nnnnnnnn][,D])
Indicates the maximum number of pages to be printed for this job’s sysout data
sets and the action to be taken if the maximum is exceeded.

Chapter 28. JES3 Control Statements 28-31

JES3: //*MAIN
If PAGES is not specified, the installation default for this job class applies.
nnnnnnnn
Specifies the number of pages. nnnnnnnn is 1 through 8 decimal numbers
from 1 through 16777215.
WARNING or W
If the maximum is exceeded, requests that JES3 issue an operator warning
message and continue processing.
Any messages about this parameter following the warning message will
reflect the number specified on the STANDARD initialization statement or
the system default value, not the maximum specified in the PAGES
parameter.
mmm
Specifies the frequency that an operator warning message is to be
issued after the maximum specified by nnnnnnnn is exceeded. mmm is
a multiple of 10 in the range 10 to 100. mmm is a percentage of
nnnnnnnn that is used to calculate the number of additional pages
between warning messages. For example, if PAGES=(1000,W,20) is
specified, the first warning message is sent to the operator when 1,000
pages of sysout data is reached. Subsequent warning messages are
sent when each additional 20 percent of 1,000 is reached (at 1,200
pages, 1,400 pages, and so on). Messages are sent until the job ends
or the operator cancels the job.
CANCEL or C
If the maximum is exceeded, requests that JES3 cancel the job.
DUMP or D
If the maximum is exceeded, requests that JES3 cancel the job and ask for
a storage dump.
PROC=ST
PROC=xx
Names the procedure library that the system is to search for cataloged
procedures called by EXEC statements in the job. If a procedure cannot be
found in the named library, JES3 abnormally terminates the job.
If this parameter is omitted, the default depends on the source of the job. If the
job is submitted as a batch job, the default is ST. If the job is submitted from an
internal reader, the default can be another procedure library, as specified by the
installation on the STANDARDS initialization statement (the INTPROC,
STCPROC, or TSOPROC parameters).
ST
Indicates the standard procedure library: SYS1.PROCLIB.
xx Identifies the last 2 characters of the ddname of a procedure library. xx is
defined by the installation (IATPLBxx) in the procedure used to start JES3.
If this parameter is coded, only the specified library is searched;
SYS1.PROCLIB is not searched.
RINGCHK=YES
RINGCHK=NO
Indicates whether or not JES3 is to check the status of the tape reel ring for
tape devices set up by JES3.
YES
Indicates that a validation check is to be made. If the RINGCHK parameter
is omitted, YES is the default.

28-32 z/OS V1R3.0 MVS JCL Reference

 JES3: //*MAIN
NO
Indicates that ring checking is to be by-passed for this job.
SETUP=JOB
SETUP=HWS
SETUP=THWS
SETUP=DHWS
SETUP=(stepname.ddname[,stepname.ddname]...)
SETUP=
(stepname.procstepname.ddname[,stepname.procstepname.ddname]...)
SETUP=/(stepname.ddname[,stepname.ddname]...)
SETUP=
/(stepname.procstepname.ddname[,stepname.procstepname.ddname]...)
Modifies the standard setup algorithm used in assigning devices to a job before
its execution.
If SETUP is omitted, JES3 assigns mountable tape and disk volumes based on
an installation default defined at initialization.
JOB
Requests job setup, which is allocation of all JES3-managed devices
required in the job before the job executes. JES3 mounts the initial volumes
necessary to run all steps before the job executes. JOB overrides the
SETUP parameter on the JES3 STANDARDS initialization statement.
HWS
Requests high watermark setup, which is allocation of the minimum number
of devices required to run the job. The minimum number is equal to the
greatest number of devices of each type needed for any one job step. High
watermark setup does not cause premounting of all mountable volumes.
THWS
Requests high watermark setup for tapes but job setup for disks.
DHWS
Requests high watermark setup for disks but job setup for tapes.
stepname.ddname
stepname.procstepname.ddname
Specifies explicit setup, which is allocation of the volumes needed for a DD
statement before the job executes. JES3 premounts the indicated volumes.
When requesting explicit setup, specify enough devices so that JES3 can
allocate all the required devices at any one time. If too few devices are
specified, JES3 cancels the job.
Use form stepname.ddname to indicate DD statement, ddname, in step,
stepname, in this job. Use form stepname.procstepname.ddname to
indicate DD statement, ddname, in procedure step, procstepname, of a
procedure that is called by a step, stepname, in this job. The ddname must
match exactly the ddname on the DD statement. (See the example for the
//*DATASET statement.)
If you code a list of ddnames and the list cannot be contained on a single
statement, SETUP= must be repeated on the continuation statement.
/stepname.ddname
/stepname.procstepname.ddname
Requests that JES3 not explicitly set up any volumes specified in DD
statement ddname.

Chapter 28. JES3 Control Statements 28-33

JES3: //*MAIN
SPART=partition-name
Indicates the spool partition in which JES3 is to allocate spool space to this job.
partition-name
Specifies the name of the spool partition. partition-name is 1 through 8
characters and must match a partition name specified during JES3
initialization. If the name does not match, JES3 ignores the SPART
parameter and uses the installation default.

The SPART parameter does not affect allocation for the sysout data sets for the
job; these data sets always go to the spool partitions specified during JES3
initialization for the output classes.

If SPART is not specified, JES3 allocates spool data sets to a partition, as

follows, in override order:
1. The spool partition for the job’s class.
2. The spool partition for the processor executing the job.
3. The default spool partition.
SYSTEM=ANY
SYSTEM=JGLOBAL
SYSTEM=JLOCAL
SYSTEM=(main-name[,main-name]...)
SYSTEM=/(main-name[,main-name]...)
Indicates the processor that is to execute this job. If a specific processor is
named, the processor name must also be specified on the CLASS initialization
statement for the job class.
ANY
Indicates any global or local system that satisfies the job’s requirements.
JGLOBAL
Indicates that the job is to run on the global processor only.
JLOCAL
Indicates that the job is to run on a local processor only.
main-name
Indicates that the job is to run on the named processor or processors.
/main-name
Indicates that the job is not to run on the named processor or processors.

Need for SYSTEM Parameter: If you omit a SYSTEM parameter, the job runs
on the processor used for the job’s class. Usually a SYSTEM parameter is not
needed. However, if any DD statement UNIT parameter in the job specifies a
device-number, a SYSTEM parameter must be coded.

Parameter Agreements: The following parameters must be consistent with the

SYSTEM parameter or JES3 will terminate the job:
v CLASS parameter on the JOB or //*MAIN statement. The requested
processor must be assigned to execute jobs in the specified class.
v All devices specified on DD statement UNIT parameters must be available to
the requested processor.
v TYPE parameter on the //*MAIN statement must specify the system running
on the requested processor.
v Dynamic support programs requested on //*PROCESS statements must be
able to be executed on the requested processor.

28-34 z/OS V1R3.0 MVS JCL Reference

 JES3: //*MAIN
THWSSEP=IGNORE
THWSSEP=PREFER
THWSSEP=REQUIRE
Indicates whether or not you want scratch tape requests and specific tape
requests separated and whether you want scratch tapes of different media
types separated during high watermark processing. This parameter is valid only
if high watermark setup (HWS or THWS) is specified on the SETUP parameter
or defined at JES3 initialization.
Use this parameter to direct scratch and specific tape requests to different tape
drives (for example, you may want JES3 to allocate only scratch tape requests
to an IBM 3480 that is equipped with an automatic cartridge loader).
If you omit THWSSEP, JES3 uses an installation default defined at initialization.
IGNORE
Specifies that JES3 is not to separate scratch and specific tape requests
and not separate scratch tape requests of different media types during high
watermark processing. Both scratch and specific tape requests and scratch
requests of different media types can be allocated on the same tape drive.
PREFER
Specifies that JES3 attempt to allocate scratch and specific tape requests
on separate tape drives and attempt to allocate scratch tape requests of
different media types on separate tape drives without allocating additional
devices. If JES3 cannot separate the requests, scratch and specific tape
requests and scratch tape requests of different media types are allocated
on the same tape drive.
REQUIRE
Specifies that JES3 should not allocate scratch and specific tape requests
on the same tape drive and not allocate scratch tape requests of different
media types on the same tape drive, even if JES3 must allocate additional
tape drives to satisfy the request.
TRKGRPS=(primary-qty,second-qty)
Specifies the number of track groups to be assigned to the job. A track group is
a number of spool space allocation units. The size of the track group is defined
in the GRPSZ parameter on the JES3 BUFFER or SPART initialization
statement.
primary-qty
Specifies the number of track groups to be initially allocated. This quantity is
one decimal number from 1 through 9.
second-qty
Specifies the number of track groups to be allocated when the currently
allocated groups are filled and more space is needed. This quantity is one
decimal number from 1 through 9.

The //*MAIN TRKGRPS parameter overrides a TRKGRPS parameter on the

CLASS or MAINPROC initialization statement. However, when a sysout DD
statement specifies an output class, the TRKGRPS parameter for that output
class overrides the //*MAIN TRKGRPS parameter.
TYPE=ANY
TYPE=VS2
Indicates the control program that is to execute this job. If you omit a TYPE
parameter, the job runs under the control program used for the job’s class.

Chapter 28. JES3 Control Statements 28-35

JES3: //*MAIN
ANY
Indicates that JES3 is to use any control program that satisfies the job’s
requirements. In present systems, JES3 schedules the job on MVS.
VS2
Indicates that JES3 is to schedule the job on MVS.
UPDATE=(dsname[,dsname]...)
Identifies the procedure library data set(s) that this job is to update. This
parameter causes all jobs using the identified data set and any concatenated
data sets to be held until the update is complete. See z/OS JES3 Initialization
and Tuning Guide for information about updating procedure libraries.
dsname
Specifies the data set name. The identified data set cannot be
concatenated to another data set.

Note: If a data set is dynamically allocated as both a JES3 DISKRDR data set
and a JES3 PROCLIB data set, the UPDATE = parameter (JES3
procedure library update facility) cannot be used to move the data set.
USER=userid
Identifies the job with the specified TSO/E user, even though the job was not
submitted via TSO/E by that user. USER allows:
v The TSO/E userid, interacting with a global or local processor, to issue the
TSO/E OUTPUT command to access sysout data sets from the job. If the job
executes on one processor and the TSO/E userid is attached to another
processor, the ACMAIN parameter must identify the processor for the TSO/E
userid.
v The TSO/E userid, interacting with any processor, to inquire about the status
of the job or to cancel the job.
userid
Identifies a TSO/E user. userid is 1 through 7 alphanumeric or national ($,
#, @) characters.

Location in the JCL

When you specify ORG on a //*MAIN statement, place the //*MAIN statement
before all //*FORMAT statements that do not contain a DEST parameter. If JES3
does not process the ORG parameter before the //*FORMAT statements, JES3
uses the default destination for the //*FORMAT statements; their output is sent to
the node where the job entered the system.

When you specify ORG on a //*MAIN statement that is part of a remote job, place
the //*MAIN statement immediately after the second JOB statement.

Examples of the //*MAIN Statement

Example 1
//*MAIN SYSTEM=SY1,LINES=(5,C),SETUP=HWS,
//*FAILURE=RESTART,DEADLINE=(0800,A,3,WEEKLY)

The job executes on processor SY1. It is estimated to produce not more than 5000
lines of printed output; if the output exceeds 5000 lines, JES3 is to cancel the job.
HWS specifies high watermark setup, so JES3 is to allocate the minimum number
of devices required for this job. If the system fails, JES3 is to restart the job on the

28-36 z/OS V1R3.0 MVS JCL Reference

 JES3: //*MAIN
processor SY1. JES3 is to complete this job by 8 a.m. on Tuesday (Tuesday is day
number 3) by adjusting the job’s scheduling priority using the installation-defined
A-type deadline scheduling parameters.

Example 2
//*MAIN ACMAIN=2,USER=GARYHIL

If this statement appears in a job entered from any TSO/E userid on any processor
in the complex, then the job’s sysout data sets would go to TSO/E userid GARYHIL
on processor 2.

//*NET Statement
Purpose

Use the //*NET statement to define the dependencies between jobs in a dependent
job control (DJC) network. JES3 sets up a network of dependent jobs and executes
them in a specific order. (Once set up, the structure of a DJC network cannot be
changed unless all of the jobs in the network are resubmitted.) Jobs belonging to a
DJC network cannot be registered with the automatic restart manager (ARM).

Chapter 28. JES3 Control Statements 28-37

JES3: //*NET
Syntax
//*NET {NETID} =name[,parameter]...
{ID }

The parameters are:

{ABCMP} = {NOKP}
{AC } {KEEP}

{ {ABNORMAL|AB} = {D} }
{ {F} }
{ {R} }
{ {NORMAL|NC} = {D} }
{ {F} }
{ {R} }

DEVPOOL=( {ANY} [,device-name,n]...

{NET}

DEVRELSE= {YES}
{NO }

{NETREL} =(netid,jobname)
{NR }

{NHOLD} =n
{HC }

{NRCMP} = {HOLD}
{PC } {NOHO}
{FLSH}

{OPHOLD} = {NO }
{OH } {YES}

{RELEASE} =(jobname[,jobname]...)
{RL }

{RELSCHCT} =n
{RS }

The //*NET statement consists of the characters //* in columns 1 through 3, NET in columns
4 through 6, a blank in column 7, and parameters in columns 8 through 72. JES3 ignores
columns 73 through 80.

Parameter Definition
NETID=name
Specifies the name of the DJC network for this job. name is 1 through 8
characters; the first character must be alphabetic.
All jobs put into the system with the same NETID name form a DJC network. To
add a job to an existing DJC network, specify the NETID name for that job.
ABCMP=NOKP
ABCMP=KEEP
Indicates what action JES3 is to take if the job abnormally terminates.
NOKP
Indicates that JES3 is to purge the DJC network if the job abnormally
terminates and has not been resubmitted by the time the other jobs in the

28-38 z/OS V1R3.0 MVS JCL Reference

 JES3: //*NET
network have completed. JES3 purges the network unless successor jobs
or subnetworks are missing. If the ABCMP parameter is omitted, NOKP is
the default.
KEEP
Indicates that the DJC network is to be kept in the system until (1) the job
is resubmitted and completes normally or (2) the operator forces the
network from the system. Use KEEP to make sure that the network is not
purged until the operator takes proper action.

Note: If the job abnormally terminates, you can resubmit it to the DJC network,
and the network will be retained until the job completes.
ABNORMAL=D
ABNORMAL=F
ABNORMAL=R
NORMAL=D
NORMAL=F
NORMAL=R
Indicates the action JES3 is to take for this job when any predecessor job
completes execution normally or abnormally. If the ABNORMAL parameter is
omitted, the default is R, and, if the NORMAL parameter is omitted, the default
is D.
D Requests that JES3 decrease this job’s NHOLD count, which indicates the
number of predecessors for this job. When the NHOLD count becomes
zero, JES3 can schedule this job.
F Requests that JES3 flush this job and its successor jobs from the system.
JES3 cancels the job, prints any output, and cancels all successor jobs
presently in the system, regardless of their normal or abnormal
specifications. However, JES3 admits into the system all successor jobs
that enter after the DJC network has been flushed. To flush those jobs, the
operator must cancel the jobs or the network.
R Requests that JES3 retain this job in the system and not decrease the
NHOLD count. R suspends the job and its successor jobs from scheduling
until either the predecessor job is resubmitted or the operator decreases the
NHOLD count.
DEVPOOL=(ANY[,device-name,n]...)
DEVPOOL=(NET[,device-name,n]...)
Identifies devices to be dedicated to this DJC network. The system allocates
these devices only to jobs in the network. The DEVPOOL parameter should be
coded on the //*NET statement that establishes the network; it is ignored on
other //*NET statements.
ANY
Indicates that jobs in the network can use any dedicated or undedicated
device. JES3 tries to allocate from the dedicated pool before allocating any
undedicated devices.
NET
Indicates that jobs can use only devices dedicated to the network.
device-name,n
Identifies a dedicated device. Code as many device-names with numbers
as will fit on one statement. device-name specifies (1) a device name
defined to JES3 by the installation during initialization or (2) a device-type
specified in the UNIT parameter of an IODEVICE system generation macro

Chapter 28. JES3 Control Statements 28-39

JES3: //*NET
instruction. See SMP/E User’s Guide for a list of IBM device types. n is the
number of named devices. n is a number from 1 through 32,767.
DEVRELSE=YES
DEVRELSE=NO
Indicates when devices dedicated to the DJC network are to be released. The
DEVRELSE parameter can be coded in several jobs in the network, but must
not be coded in the first job. If no network job containing DEVRELSE=YES
completes, the system releases the devices when it purges the network.
YES
Requests that JES3 release all devices at the end of this job. Completion of
any job that specified DEVRELSE=YES causes the devices dedicated to
the network to be released.
NO
Requests that JES3 release all devices only when the last job in the
network ends.
NETREL=(netid,jobname)
Indicates that this job must be executed before the named job in another DJC
network can be executed. The NETREL parameter can be specified only once
for each job of a DJC network.
netid
Identifies the NETID for the successor job.
jobname
Names the JOB statement for the successor job.
NHOLD=n
Indicates the number of predecessor job completions required before this job
can be released for scheduling. The predecessor number can include jobs from
another DJC network. n is a number from 0 through 32,767.
When the predecessor number reaches 0, the job is scheduled for execution.
The system reduces this number:
v When each predecessor job completes execution.
v By operator command.
v When a program in a predecessor job issues an assembler DJC WTO
macro.

If you specify NHOLD=0 or omit the NHOLD parameter, this job has no
predecessor jobs. JES3 can schedule it for immediate execution.

If the NHOLD count is incorrect, the following can occur:

v If n is greater than the actual number of predecessor jobs, JES3 does not
release this job for execution when all of its predecessor jobs complete
execution.
v If n is less than the actual number of predecessor jobs, JES3 prematurely
releases the job for execution.
NRCMP=HOLD
NRCMP=NOHO
NRCMP=FLSH
Indicates that a network job that completed normally is being resubmitted and
that JES3 must erase all references to the job before the job reenters the
network.

28-40 z/OS V1R3.0 MVS JCL Reference

 JES3: //*NET
HOLD
Indicates that JES3 is to hold the job until it is released by the operator.
NOHO
Indicates that JES3 is to allow the job to be scheduled as system resources
become available.
FLSH
Indicates that JES3 is to flush the job from the system.
OPHOLD=NO
OPHOLD=YES

NO
Indicates that the job is to be processed normally without operator
intervention. If OPHOLD is omitted, NO is the default.
YES
Indicates that JES3 is to hold the job until it is released by the operator.
RELEASE=(jobname[,jobname]...)
Indicates that this job must be executed before the named job(s) in this DJC
network can be executed.
jobname
Names the JOB statement for a successor job. You can specify from 1
through 50 successor jobnames.

RELEASE is the only parameter on the //*NET statement that can be split and
continued on the next statement. To continue the RELEASE parameter, end the
statement with the comma following a jobname and continue the next statement
with the next jobname. The left parenthesis appears at the beginning of the
jobname list and the right parenthesis appears at the end of the list. For
example:
//*NET NETID=EXP1,RELEASE=(JOB35,JOB27Z,MYJOB,
//*WRITJB,JOBABC)
RELSCHCT=n
Controls early set up of a dependent job’s resources. Set up begins when the
NHOLD count becomes less than or equal to n. n is a number from 1 through
32,767.
If you specify RELSCHCT=0 or omit the RELSCHCT parameter, JES3 does not
set up dependent jobs early.

Note: Use this parameter carefully; RELSCHCT can tie up devices and data
sets for long times. Do not specify the RELSCHCT parameter:
v For a job that may have catalog dependencies.
v For a job that contains one or more //*PROCESS statements.

Location in the JCL

Place the //*NET statement for a job after the JOB statement and before the first
EXEC statement. Code only one //*NET statement for each job in a DJC network.

The //*NET statement must precede any //*PROCESS statements.

Chapter 28. JES3 Control Statements 28-41

JES3: //*NET
Examples of the //*NET Statement
Example 1
//*NET NETID=NET01,NHOLD=0,DEVPOOL=(,3330,2)

This statement defines a DJC network named NET01. The network contains no
predecessor jobs. The DEVPOOL parameter, which must be coded in the first job in
the network, requests that JES3 establish a device pool of two 3330s for network
NET01.

Example 2
//*NET NETID=N1,RELEASE=B,NETREL=(N2,B2)

This statement adds a job to the DJC network named N1. This job must be
executed before job B, which is in N1, and before job B2, which is in the DJC
network named N2.

//*NETACCT Statement
Purpose

Use the //*NETACCT statement to specify accounting information that JES3 is to

transmit with a job to another node in the network.

Syntax
//*NETACCT parameter[,parameter]...

The parameters are:

PNAME=programmer’s-name
ACCT=number
BLDG=address
DEPT=dept
ROOM=room
USERID=userid

v The //*NETACCT statement consists of the characters //* in columns 1 through 3,

NETACCT in columns 4 through 10, a blank in column 11, and parameters in columns 9
through 72. JES3 ignores columns 73 through 80.
v Do not continue a //*NETACCT statement. If the parameters cannot fit on one statement,
code more than one //*NETACCT statement.
v Enclose any parameter value that contains special characters, including embedded
blanks, in apostrophes.

Parameter Definition
PNAME=programmer’s-name
Identifies the programmer. programmer’s-name is 1 through 20 characters.
ACCT=number
Gives the network account number. number is 1 through 8 characters.
BLDG=address
Gives the programmer’s building address. address is 1 through 8 characters.
DEPT=dept
Gives the programmer’s department number. dept is 1 through 8 characters.

28-42 z/OS V1R3.0 MVS JCL Reference

 JES3: //*NETACCT
ROOM=room
Gives the programmer’s room number. room is 1 through 8 characters.
USERID=userid
Gives the programmer’s network userid. userid is 1 through 8 characters.

Defaults
For any //*NETACCT parameter that is omitted, JES3 uses an installation default
specified at JES3 initialization.

Location in the JCL

Place the //*NETACCT statement(s) for a job stream to be transmitted immediately
after the first JOB statement and before any //*ROUTE XEQ or // XMIT statements.

Place the //*NETACCT statement(s) for a SYSOUT stream to be transmitted

immediately after the first JOB statement and before any //*MAIN statements
specifying ORG=nodename.

For jobs running at the submitting system and potentially having the destination
changed to a network destination via an output service modify command
(*MODIFY,U ...), place the //*NETACCT statement(s) for the SYSOUT immediately
after the JOB statement.

Example of the //*NETACCT Statement

//*NETACCT PNAME=COLLINS,ACCT=D58D921,USERID=NXT

//*OPERATOR Statement
Purpose

Use the //*OPERATOR statement to issue a message to the operator. Columns 1

through 80 are written on the operator console and in the job’s hard-copy log when
JES3 reads in the job.

Syntax
//*OPERATOR message

The //*OPERATOR statement consists of the characters //* in columns 1 through 3,

OPERATOR in columns 4 through 11, a blank in column 12, and the message for the
operator in columns 13 through 80.

Location in the JCL

Place the //*OPERATOR statement anywhere after the JOB statement.

Example of the //*OPERATOR Statement

//*OPERATOR CALL EXT. 55523 WHEN THIS JOB STARTS

//**PAUSE Statement
Purpose

Chapter 28. JES3 Control Statements 28-43

JES3: //**PAUSE
Use the //**PAUSE statement to halt an input reader temporarily. When you enter a
//**PAUSE statement through an input reader, JES3 issues a message and waits for
the operator to reply. To start the input reader, the system operator must issue a
*START command or a remote work station with console level 15 must send a start
message.

The //**PAUSE statement is intended primarily for system checkout and test. It
should be issued only by remote work stations.

Syntax
//**PAUSE [comments]

The //**PAUSE statement consists of the characters //** in columns 1 through 4, PAUSE in
columns 5 through 9, a blank in column 10, and, optionally, comments starting in any
column beginning with 11. JES3 ignores columns 73 through 80.

Location in the JCL

Place the //**PAUSE statement before the first JOB statement in an input stream. If
it appears after the first JOB statement, JES3 ignores it.

Example of the //**PAUSE Statement

//**PAUSE THIS IS A TEST.

//*PROCESS Statement
Purpose

Use the //*PROCESS statement to control how JES3 processes a job. A job that
contains //*PROCESS statements receives only the JES3 processing specified on
the //*PROCESS statements plus certain required processing.

Specifically, the //*PROCESS statement calls a dynamic support program (DSP) in

the DSP dictionary. JES3 must be able to process the called DSP.

Standard Job Processing

JES3 uses a series of processing functions to process a job. Standard processing

consists of only the standard scheduler functions:
Converter/interpreter service
Main service
Output service
Purge service

Nonstandard Job Processing

A nonstandard job uses one or more special processing functions in place of or in

addition to standard processing or skips one or more of the standard functions.
Specify a nonstandard job by following the JOB statement with a JES3
//*PROCESS statement for each processing function.

Use of Nonstandard Job Processing

28-44 z/OS V1R3.0 MVS JCL Reference

 JES3: //*PROCESS
Nonstandard job processing is useful in testing. For example, a //*PROCESS
statement can make JES3 bypass program execution so that the job’s JCL can be
checked. Another //*PROCESS statement can make JES3 bypass output
processing; then the operator can check by inquiry command whether the job
reached execution.

If the job generates spin data sets during main execution, the next scheduler
element will not be processed until the spin data sets have been processed. To
avoid long waits or system hangs, make sure that the OUTSERV scheduler element
is the next scheduler element after main processing.

Syntax
//*PROCESS dsp
[parameter[,parameter]...]

The //*PROCESS statement consists of the characters //* in columns 1 through 3,

PROCESS in columns 4 through 10, a blank in column 11, and the DSP name beginning in
column 12. The rest of the columns must be blank.

If the requested DSP requires parameters, code them on the following statement. The
parameter statement consists of parameters in columns 1 through 72, separated by
commas. Columns 73 through 80 must be blank. Only one parameter statement after a
//*PROCESS statement is allowed, any others are ignored by JES3.

Parameter Definition
dsp
Identifies the DSP that JES3 is to use in processing the job. Table 28-1 lists the
valid DSP names and whether parameters can follow.
Table 28-1. DSPs for JES3 //*PROCESS Statements
DSP DSP Function Parameters
Standard processing functions:
CI JES3 Converter/Interpreter Service, which Yes (See z/OS JES3
interprets the JCL and creates control Commands)
blocks.
MAIN Main Service, which processes the program. No
OUTSERV Output Service, which processes the job’s No
output.
PURGE Purge Service, which purges the job. This is No
the last function in any job. JES3
automatically creates this DSP.
Nonstandard processing functions:
CBPRNT Control Block Print Yes (See z/OS JES3
Commands)
DISPDJC Display Dependent Job Control Yes (See z/OS JES3
Commands)
DISPLAY Display Job Queues Yes (See z/OS JES3
Commands)

Chapter 28. JES3 Control Statements 28-45

JES3: //*PROCESS
Table 28-1. DSPs for JES3 //*PROCESS Statements (continued)
DSP DSP Function Parameters
DJCPROC Invoke Dependent Job Control Updating No

Note: A //*PROCESS DJCPROC statement

is required only when a //*PROCESS MAIN
statement is not coded.
DR Disk Reader Yes (See z/OS JES3
Commands)
ISDRVR Input Service Driver (JES3 Control Yes (Qualified ddname of
Statement Processing) input data set)
JESNEWS Use JESNEWS Facility Yes (See z/OS JES3
Commands)
xxx User-written DSP (See z/OS JES3
Customization)

Location in the JCL

v Place all //*PROCESS statements for a job immediately after the JOB statement
and before the first EXEC statement. If the job includes a //*NET statement, the
//*NET statement must appear between the JOB statement and the first
//*PROCESS statement.
v The //*PROCESS statements can be separated only by their parameter
statements.
v JES3 processes the //*PROCESS statements in the order in which they appear
in the input stream.
v The first //*PROCESS statement must request an interpreter DSP if you want
input service error messages, which indicate that a job is to be scheduled for
interpreter processing before being purged.

Examples of the //*PROCESS Statement

Example 1
//EXAM1 JOB
//*PROCESS CI
//*PROCESS MAIN
//*PROCESS OUTSERV
//S1 EXEC PGM=ANY
.
.
JCL statements
.

This example shows how to submit a simple job via //*PROCESS statements. It is
processed like a standard job. The four standard scheduler functions are used for
the job: CI, MAIN, OUTSERV, and PURGE. Note that PURGE is not specified;
JES3 automatically creates this DSP.

Example 2
//EXAM2 JOB
//*PROCESS CI
//*PROCESS MAIN
//*PROCESS OUTSERV
//*PROCESS PLOT
//*ENDPROCESS
//S1 EXEC PGM=ANY

28-46 z/OS V1R3.0 MVS JCL Reference

 JES3: //*PROCESS
//DD1 DD ...
.
.
JCL statements
.

This example shows how to request a user-written DSP: PLOT. PLOT is to be

executed after output service has completed. Note that PURGE is again not
specified but is automatically created.

Example 3
//EXAM3 JOB
//*PROCESS OUTSERV
//*FORMAT PR,DDNAME=S1.DS1,COPIES=5
//*DATASET DDNAME=S1.DS1
.
.
data
.
.
//*ENDDATASET
//S1 EXEC PGM=ANY
//DS1 DD DSNAME=DATA1
.
.

This example uses JES3 output service and the //*DATASET statement. Five copies
of data set DS1 are printed on any local printer.

//*ROUTE XEQ Statement

Purpose

Use the //*ROUTE XEQ statement to send the following input stream to a network
node where the job is then executed. JES3 stops transmitting input stream records
when it finds one of the following:
v The second JOB statement after the //*ROUTE XEQ statement.
v The input stream runs out of card images.

All output from the job is assumed to print/punch at the originating node unless
otherwise specified on a DEST parameter.

The //*ROUTE XEQ statement must be given 80 character records.

Syntax
//*ROUTE XEQ nodename[.vmguestid]

The //*ROUTE XEQ statement consists of the characters //* in columns 1 through 3,
ROUTE in columns 4 through 8, a blank in column 9, and, starting in any column from 10
through 72: XEQ, followed by at least one blank and then parameters. JES3 ignores
columns 73 through 80.

Do not imbed blanks in the nodename or vmguestid parameters.

Chapter 28. JES3 Control Statements 28-47

JES3: //*ROUTE XEQ
Parameter Definition
nodename
Indicates the node. The nodename identifies an MVS JES2 system, an MVS
JES3 (global) system, a VSE POWER node, or a VM system.
If nodename specifies a local node:
v The job executes locally if the job begins with a JOB statement.
v The job is terminated if the job begins with an NJE statement.
.vmguestid
Identifies a guest system running in a virtual machine (VM), for example, an
MVS system running under VM.

Note: Do not specify a work station or terminal in this parameter.

Location in the JCL

v Place the //*ROUTE XEQ statement after a JOB statement that is valid for the
submitting location and any //*NETACCT statements.
v JES3 requires a MVS JOB statement immediately after the //*ROUTE XEQ
statement.
v If the destination node is not a MVS system, any statement immediately following
the MVS JOB statement must be a valid JOB statement for the executing node.

JOB Statement after //*ROUTE XEQ

An error in the //*ROUTE XEQ statement can cause the JOB statement following
the //*ROUTE XEQ to be processed at the submitting node. To prevent this, code
NJB instead of JOB on the second JOB statement; JES3 changes the NJB to JOB
before transmitting the job.
Notes:
1. TSO/E users must code NJB instead of JOB on the second JOB statement.
2. If an MVS JOB statement is not immediately following the //*ROUTE XEQ
statement, the XMIT JCL statement must be used instead of //*ROUTE XEQ.

Example of the //*ROUTE XEQ Statement

//JOBN1 JOB options ...
//*ROUTE XEQ 2
//JOBN2 JOB options ...
//STEP1 EXEC PGM=REPORTER
//DD1 DD SYSOUT=A,DEST=N1R33
//DD2 DD SYSOUT=A,DEST=N2R33
//DD3 DD SYSOUT=B,DEST=R33
//DDIN DD *
.
.
data
.
/*

In this example, JOB statement JOBN1 is entered through the JES3 system at
node 1. The //*ROUTE XEQ statement tells JES3 to send the following input stream
to node 2. Transmission of the input stream is stopped by the /* delimiter statement.
JOB statement JOBN2 and all following statements until the delimiter are read and
executed by the system at node 2.

28-48 z/OS V1R3.0 MVS JCL Reference

 JES3: //*ROUTE XEQ
The sysout data sets are sent to two work stations:
v Sysout data set DD1 is produced at work station 33 attached to node 1.
v Sysout data set DD2 is produced at work station 33 attached to node 2.
v Sysout data set DD3 is produced at work station 33 attached to node 1. Because
no node is specified, the originating node is assumed.

Node 1 Node 2

Work Work
Station 33 Station 33

/*SIGNOFF Statement
Purpose

Use the /*SIGNOFF statement to tell JES3 to end a remote job stream processing
session. At the completion of the current print and/or punch streams, JES3
disconnects the remote work station from the system. If JES3 is reading jobs from
the station when the output completes, JES3 disconnects the station when the input
is completed.

Both systems network architecture (SNA) and binary synchronous communication

(BSC) remote work stations use the /*SIGNOFF statement.

References

For more information on the /*SIGNOFF command, see z/OS JES3 Initialization and
Tuning Reference.

Syntax
/*SIGNOFF

The /*SIGNOFF statement consists of the characters /* in columns 1 and 2, SIGNOFF in

columns 3 through 9, and blanks in columns 10 through 80.

Note that, unlike other JES3 statements, this statement starts with only one slash.

Location in the JCL

The /*SIGNOFF statement can appear anywhere in a local input stream or an input
stream from a SNA or BSC remote work station.

Example of the /*SIGNOFF Statement

/*SIGNOFF

Chapter 28. JES3 Control Statements 28-49

JES3: /*SIGNOFF
This statement requests that JES3 terminate a remote job stream processing
session.

/*SIGNON Statement
Purpose

Use the /*SIGNON statement to tell JES3 to begin a remote job stream processing
session. The /*SIGNON statement can override the remote identification number
normally assigned to the remote work station. This statement is optional for all work
stations except non-multi-leaving remote stations on a switched line.

Systems network architecture (SNA) remote work stations must use the LOGON
command instead of the /*SIGNON statement to notify JES3 of a connection
request.

References

For information on the LOGON command, see z/OS JES3 Initialization and Tuning
Reference and z/OS Communications Server: SNA Programming.

Syntax
/*SIGNON work-station-name {A|(blank)} {R|(blank)} passwd1 passwd2 new-passwd

The /*SIGNON statement consists of the following:

Column
Contents

1-2 /*
3-8 SIGNON
9-15 blanks
16-20 work-station-name, beginning in 16
21 blank
22 A or a blank
23 R or a blank
24 blank
25-32 password1, beginning in 25
33-34 blanks
35-42 password2, beginning in 35
43 blank
44-51 new-password, beginning in 44
52-80 blanks

Note that, unlike other JES3 statements, this statement starts with only one slash.

Parameter Definition
work-station-name
Specifies the name of the remote work station. The work-station-name is 1
through 5 characters and must have been defined on a JES3 RJPTERM
initialization statement.
A Indicates an automatic reader. A can be coded only when the work station is a
programmable terminal. Leave this column blank if you do not want to specify
an automatic reader.

28-50 z/OS V1R3.0 MVS JCL Reference

 JES3: /*SIGNON
R Indicates that print or punch output will be rescheduled if the needed device is
not ready. R can be coded only when the work station is a nonprogrammable
terminal. Leave this column blank if you do not want to specify the R option.
password1
Specifies the password for the remote job processing (RJP) line. This
parameter is one through eight characters and must have been initially defined
at system initialization.
password2
Specifies the current password for the work station. This parameter is one
through eight characters and must have been initially defined at system
initialization.
new-password
Specifies a new password for the work station. This parameter is one through
eight characters.

Location in the JCL

Place the /*SIGNON statement at the start of an input stream to be transmitted from
a remote work station.

Example of the /*SIGNON Statement

/*SIGNON QUIN A PSWD1 PSWD2

This statement requests that remote work station QUIN begin a remote job stream
processing session. The value A in column 22 specifies an automatic reader for the
programmable terminal. PSWD1, beginning in column 25, is the password assigned
to a dial line. PSWD2, beginning in column 35, is the password assigned to the
remote work station.

To change the current password PSWD2 for the remote work station, the preceding
/*SIGNON statement can be specified as:
/*SIGNON QUIN A PSWD1 PSWD2 PSWDNEW

This statement assigns PSWDNEW, beginning in column 44, as the new password
for the remote work station QUIN.

Chapter 28. JES3 Control Statements 28-51

28-52 z/OS V1R3.0 MVS JCL Reference
Appendix. Accessibility
Accessibility features help a user who has a physical disability, such as restricted
mobility or limited vision, to use software products successfully. The major
accessibility features in z/OS enable users to:
v Use assistive technologies such as screen-readers and screen magnifier
software
v Operate specific or equivalent features using only the keyboard
v Customize display attributes such as color, contrast, and font size

Using assistive technologies

Assistive technology products, such as screen-readers, function with the user
interfaces found in z/OS. Consult the assistive technology documentation for
specific information when using it to access z/OS interfaces.

Keyboard navigation of the user interface

Users can access z/OS user interfaces using TSO/E or ISPF. Refer to z/OS TSO/E
Primer, z/OS TSO/E User’s Guide, and z/OS ISPF User’s Guide Volume I for
information about accessing TSO/E and ISPF interfaces. These guides describe
how to use TSO/E and ISPF, including the use of keyboard shortcuts or function
keys (PF keys). Each guide includes the default settings for the PF keys and
explains how to modify their functions.

© Copyright IBM Corp. 1988, 2002 A-1

A-2 z/OS V1R3.0 MVS JCL Reference
Notices
This information was developed for products and services offered in the USA.

IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may be
used instead. However, it is the user’s responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you any
license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
USA

For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply to
you.

This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements and/or
changes in the product(s) and/or the program(s) described in this publication at any
time without notice.

Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those
Web sites. The materials at those Web sites are not part of the materials for this
IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes
appropriate without incurring any obligation to you.

© Copyright IBM Corp. 1988, 2002 B-1

Notices
Licensees of this program who wish to have information about it for the purpose of
enabling: (i) the exchange of information between independently created programs
and other programs (including this one) and (ii) the mutual use of the information
which has been exchanged, should contact:
IBM Corporation
Mail Station P300
2455 South Road
Poughkeepsie, NY 12601-5400
USA

Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.

The licensed program described in this information and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement, or any equivalent agreement
between us.

If you are viewing this information softcopy, the photographs and color illustrations
may not appear.

Trademarks
The following terms are trademarks of the IBM Corporation in the United States or
other countries or both:
v AFP
v C/370
v CICS
v DFSMSdfp
v DFSMShsm
v DFSMS/MVS
v IBM
v IBMLink
v IP Printway
v MVS
v MVS/ESA
v MVS/SP
v OS/390
v Print Services Facility
v Printway
v RACF
v Resource Link
v RETAIN
v SecureWay
v VTAM
v zSeries
v z/OS

UNIX is a registered trademark of The Open Group in the United States and other
countries.

Other company, product, and service names may be trademarks or service marks
of others.

B-2 z/OS V1R3.0 MVS JCL Reference

Index
Special Characters //*NET control statement
in JES3 28-37
, (comma)
description 28-37
in syntax 4-3
DJC (dependent job control) network 28-37
use of in parameter field 3-3
example 28-42
when coded in bracket or brace 4-2
location in JCL 28-41
/ (slash)
parameter 28-38
in syntax 4-3
//*NETACCT control statement
/ (slash) subparameter
in JES3 28-42
of //*MAIN FETCH parameter 28-29
default 28-43
of //*MAIN SETUP parameter 28-33
description 28-42
of //*MAIN SYSTEM parameter 28-34
location in JCL 28-43
//**PAUSE control statement
parameter 28-42
in JES3 28-43
//*OPERATOR control statement
description 28-43
in JES3 28-43
example 28-44
description 28-43
location in JCL 28-44
example 28-43
//*DATASET control statement
location in JCL 28-43
in JES3 28-4
//*PROCESS control statement
description 28-4
in JES3
example 28-5
description 28-44
location in JCL 28-5
ending 28-6
parameter 28-4
example 28-46
//*ENDDATASET control statement
location in JCL 28-46
in JES3 28-6
parameter 28-45
description 28-6
//*ROUTE XEQ control statement
example 28-6
in JES3 28-47
location in JCL 28-6
description 28-47
//*ENDPROCESS control statement
example 28-48
in JES3 28-6
location in JCL 28-48
description 28-6
parameter 28-48
example 28-7
/* (slash asterisk)
location in JCL 28-6
as delimiter statement 14-1
//*FORMAT PR control statement
/*DEL control statement
in JES3 28-7
submitting jobs to internal reader 27-1, 28-1
description 28-7
with XMIT JCL statement 26-1, 26-6
example 28-16
/*EOF control statement
location in JCL 28-16
submitting jobs to internal reader 27-1, 28-1
parameter 28-9
with XMIT JCL statement 26-1, 26-6
relationship to //*PROCESS statement 28-16
/*JOBPARM control statement
relationship to sysout DD and OUTPUT JCL
in JES2 27-3
statement 28-16
description 27-3
//*FORMAT PU control statement
example 27-8
in JES3 28-17
location in JCL 27-8
description 28-17
override 27-8
example 28-22
parameter 27-5
location in JCL 28-21
/*MESSAGE control statement
parameter 28-18
in JES2 27-9
relationship to //*PROCESS statement 28-21
description 27-9
relationship to sysout DD and OUTPUT JCL
example 27-9
statement 28-21
location in JCL 27-9
//*MAIN control statement
relationship to /*ROUTE XEQ statement 27-9
in JES3 28-22
/*NETACCT control statement
description 28-22
in JES2 27-9
example 28-36
default 27-10
location in JCL 28-36
description 27-9
parameter 28-24
example 27-10
location in JCL 27-10

© Copyright IBM Corp. 1988, 2002 X-1

/*NETACCT control statement (continued) /*SIGNON control statement
in JES2 (continued) in JES2 27-27
override 27-10 description 27-27
parameter 27-10 example 27-28
/*NOTIFY control statement location in JCL 27-28
in JES2 27-10 parameter 27-27
description 27-10 in JES3 28-50
example 27-12 description 28-50
location in JCL 27-11 example 28-51
override 27-11 location in JCL 28-51
parameter 27-11 parameter 28-50
/*OUTPUT control statement /*XEQ control statement
in JES2 27-12 in JES2 27-29
description 27-12 description 27-29
example 27-20 example 27-30
location in JCL 27-20 location in JCL 27-30
override 27-20 multiple statement 27-30
parameter 27-14 parameter 27-29
relationship to other control statement 27-20 /*XMIT control statement
/*PRIORITY control statement in JES2 27-30
in JES2 27-21 default 27-32
description 27-21 description 27-30
example 27-22 example 27-32
location in JCL 27-21 location in JCL 27-32
override 27-21 parameter 27-31
parameter 27-21 . (period)
relationship to other control statement 27-21 in syntax 4-3
/*PURGE control statement .. (two consecutive periods)
submitting jobs to internal reader 27-1 in syntax 4-3
/*ROUTE control statement ... (ellipsis)
/*ROUTE PRINT in syntax 4-2
description 27-22 ( ) (parentheses)
/*ROUTE PUNCH in syntax 4-3
description 27-22 * (asterisk)
/*ROUTE XEQ as code parameter of JES2 /*OUTPUT
description 27-22 statement 27-14
relationship to /*MESSAGE statement 27-9 in syntax 4-3
in JES2 27-22 relationship to DD DATA parameter 12-47
description 27-22 * parameter
example 27-24 of DD statement 12-18
location in JCL 27-24 default 12-19
multiple statement 27-24 description 12-18
parameter 27-22 example 12-21
processing 27-24 location in JCL 12-20
/*SCAN control statement relationship to other control statement 12-20
submitting jobs to internal reader 27-1 relationship to other parameter 12-19
/*SETUP control statement unread record 12-21
in JES2 27-25 * subparameter
description 27-25 of /*JOBPARM SYSAFF parameter 27-7
example 27-26 of DD SYSOUT parameter 12-194
location in JCL 27-25 of JOB RESTART parameter 20-43
parameter 27-25 of OUTPUT JCL CLASS parameter 22-20
/*SIGNOFF control statement *.ddname subparameter
in JES2 27-26 description 4-5, 12-78
description 27-26 of DD DCB parameter 12-55
example 27-26 of DD DSNAME parameter 12-105
location in JCL 27-26 of DD REFDD parameter 12-171
in JES3 28-49 of VOLUME=REF subparameter 12-215
description 28-49 *.label subparameter
example 28-49 of DD CNTL parameter 12-43
location in JCL 28-49

X-2 z/OS V1R3.0 MVS JCL Reference

*.name subparameter 3540 diskette input/output unit
description 4-5 with DD * statement 12-20
of DD OUTPUT parameter 12-147 with DD DATA parameter 12-48
*.procstepname.ddname subparameter with DD DCB parameter 12-56
description 4-5 with DD DSID parameter 12-97
of VOLUME=REF subparameter 12-215 with VOLUME=SER subparameter 12-218
*.stepname.ddname subparameter 3800 Printing Subsystem
description 4-5, 12-78 DD BURST parameter 12-35
of DD DCB parameter 12-55 DD CCSID parameter 12-37
of DD DSNAME parameter 12-105 DD CHARS parameter 12-39
of DD REFDD parameter 12-171 OUTPUT JCL BURST parameter 22-15
of EXEC PGM parameter 16-23 OUTPUT JCL CHARS parameter 22-16
of VOLUME=REF subparameter 12-215 specifying copy group 12-45, 22-25, 28-12
*.stepname.label subparameter
of DD CNTL parameter 12-43
*.stepname.name subparameter A
description 4-5 A parameter
of DD OUTPUT parameter 12-147 of JES3 /*SIGNON statement 28-50
*.stepname.procstepname.ddname subparameter A subparameter
description 4-5, 12-78 of DCB BFTEK subparameter 12-57
of DD DCB parameter 12-55 of DCB OPTCD subparameter 12-66
of DD DSNAME parameter 12-105 of DCB PCI subparameter 12-69
of DD REFDD parameter 12-171 of RECFM parameter 12-167, 12-168
of EXEC PGM parameter 16-24 A11 character set
of VOLUME=REF subparameter 12-215 for 3211 printer 12-202, 22-82
*.stepname.procstepname.label subparameter AB parameter
of DD CNTL parameter 12-43 of JES3 //*NET statement 28-38
*.stepname.procstepname.name subparameter ABCMP parameter
description 4-5 of JES3 //*NET statement 28-38
of DD OUTPUT parameter 12-147 ABE subparameter
[ ] (brackets) of DCB EROPT subparameter 12-62
in syntax 4-2 abend condition
| (logical or) with IF/THEN/ELSE/ENDIF statement
in syntax 4-1 construct 17-4
| (OR) operator ABEND keyword
of IF/THEN/ELSE/ENDIF statement construct 17-3 of IF/THEN/ELSE/ENDIF statement construct 17-4
& (ampersand) ABENDCC keyword
in syntax 4-3 of IF/THEN/ELSE/ENDIF statement construct 17-4
& (AND) operator ABNORMAL parameter
of IF/THEN/ELSE/ENDIF statement construct 17-3 of JES3 //*NET statement 28-39
&&dsname subparameter ABSTR subparameter
of DD DSNAME parameter 12-104 of DD SPACE parameter 12-185
= (equal sign) AC parameter
in syntax 4-3 of JES3 //*NET statement 28-38
' (apostrophe) ACB (access method control block) 12-23
use to enclose special character 4-4 ACC subparameter
use with special character 4-4 of DCB EROPT subparameter 12-62
when not needed to enclose special character 4-4 access method
{ } (braces) for dummy data set 12-112
in syntax 4-2 access method control block
See ACB
access-code subparameter
Numerics of DD ACCODE parameter 12-22
1440 subparameter accessibility A-1
of EXEC TIME parameter 16-32 ACCODE parameter
of JOB TIME parameter 20-48 of DD statement parameter 12-22
3211 Printer with indexing feature default 12-22
specifying indexing of left margin 22-48, 22-49 description 12-22
specifying indexing of right margin 22-52 example 12-23
3480 Magnetic Tape Subsystem override 12-23
specifying in UNIT parameter 12-204 subparameter 12-22

Index X-3
account-number subparameter ALL subparameter (continued)
of JOB accounting information parameter 20-7 of OUTPUT JCL JESDS parameter 22-50
accounting information 7-3 allocation
accounting-information parameter attribute
of JOB statement 20-6 on DD LIKE parameter 12-138
description 20-6 on DD REFDD parameter 12-170
example 20-9 of data set
JES2 format 20-8 holding for reuse 16-18
JES2 processing of invalid subparameter 20-9 of device
overrides of subparameters in JES2 format 20-9 from group 12-205
relationship to other control statement 20-7 number 12-205
subparameter 20-7 when unit affinity is specified 12-206
subparameters for JES2 format 20-8 ALX subparameter
specified on JES3 //*NETACCT statement 28-42 of DD SPACE parameter 12-184
accounting-information subparameter AMORG subparameter
of EXEC ACCT parameter 16-7 of DD AMP parameter 12-25
of JOB accounting information parameter 20-7 AMP parameter
ACCT parameter of DD statement 12-23
of EXEC statement 16-6 description 12-23
description 16-6 example 12-30
example 16-7 relationship to other parameter 12-30
subparameter 16-7 subparameter 12-25
of JES3 //*NETACCT statement 28-42 with DSNAME parameter 12-106
ACMAIN parameter AN character set
of JES3 //*MAIN statement 28-24 for 1403 printer 12-202, 22-82
ACS routine for 3203 Model 5 printer 12-202, 22-82
with DD DATACLAS parameter 12-51 AND (&) operator
with DD MGMTCLAS parameter 12-142 of IF/THEN/ELSE/ENDIF statement construct 17-3
with DD STORCLAS parameter 12-189 ANY subparameter
ADDRESS parameter of //*MAIN SYSTEM parameter 28-34
of OUTPUT JCL statement 22-12 of //*MAIN TYPE parameter 28-35
description 22-12 of //*NET DEVPOOL parameter 28-39
subparameter 22-12 of /*JOBPARM SYSAFF parameter 27-7
address subparameter ANYLOCAL subparameter
of //*NETACCT BLDG parameter 28-42 of //*FORMAT DEST parameter 28-12, 28-20
of DD SPACE parameter 12-185 of DD DEST parameter 12-82
ADDRSPC parameter of OUTPUT JCL DEST parameter 22-34
of EXEC statement 16-8 area subparameter
default 16-8 of DD DSNAME parameter 12-102, 12-104
description 16-8 ASCII tape record
example 16-9 converting to EBCDIC 12-68
override 16-8 attribute
relationship to REGION parameter 16-8 of data set 12-50, 12-53, 12-138, 12-170
subparameter 16-8 specifying on DD LIKE parameter 12-138
of JOB statement 20-10 specifying on DD REFDD parameter 12-170
default 20-10 specifying with DD DATACLAS parameter 12-50
description 20-10 specifying with DD DCB parameter 12-53
example 20-11 AUL subparameter
override 20-10 of DD LABEL parameter 12-132
relationship to REGION parameter 20-10 automatic cartridge loader
subparameter 20-10 use with THWSSEP subparameter of //*MAIN
AFF subparameter statement 28-35
of DD UNIT parameter 12-206 average record length
AL subparameter specifying in DD SPACE parameter 12-180
of DD LABEL parameter 12-132 AVGREC parameter
ALIGN subparameter of DD statement
of DD FCB parameter 12-117 description 12-31
alignment example 12-32
of printing form 12-117 override 12-32
ALL subparameter relationship to other parameter 12-32
of JES3 //*MAIN FETCH parameter 28-29 subparameter 12-31

X-4 z/OS V1R3.0 MVS JCL Reference

AVGREC parameter (continued) BS subparameter
of DD statement (continued) of DD RECFM parameter 12-168
with DD SPACE reclgth subparameter 12-180 BSAM (basic sequential access method)
subparameters of DD DCB parameter 12-57, 12-75
with DD CHKPT parameter 12-42
B BST subparameter
B subparameter of DD RECFM parameter 12-168
of DCB OPTCD subparameter 12-68 BT subparameter
of RECFM parameter 12-166, 12-167, 12-168, of DD RECFM parameter 12-167, 12-168
12-169 BTAM (basic telecommunications access method)
BCP (base control program) subparameters of DD DCB parameter 12-57, 12-75
in relation to JCL statement 2-1 buffer
BDAM (basic direct access method) requirements with DD AMP parameter 12-30
subparameters of DD DCB parameter 12-57, 12-75 buffer subparameter
BFALN subparameter of DCB BUFIN parameter 12-57
of DD DCB parameter 12-57 of DCB BUFNO subparameter 12-61
BFTEK subparameter of DCB BUFOUT subparameter 12-61
of DD DCB parameter 12-57 BUFIN subparameter
BINARY subparameter of DD DCB parameter 12-57
of DD FILEDATA parameter 12-120 BUFL subparameter
BISAM (basic indexed sequential access method) of DD DCB parameter 12-57
subparameters of DD DCB parameter 12-57, 12-75 BUFMAX subparameter
blank of DD DCB parameter 12-59
use in parameter 4-4 BUFND subparameter
BLDG parameter of DD AMP parameter 12-25
of JES3 //*NETACCT statement 28-42 BUFNI subparameter
BLKCHAR subparameter of DD AMP parameter 12-25
of OUTPUT JCL DATACK parameter 22-28 BUFNO subparameter
blklgth subparameter coded with DATA parameter 12-48
of DD SPACE parameter 12-180 of DD DCB parameter 12-61
BLKPOS subparameter BUFOFF subparameter
of OUTPUT JCL DATACK parameter 22-28 of DD DCB parameter 12-61
BLKSIZE parameter BUFOUT subparameter
of DD statement 12-32 of DD DCB parameter 12-61
coexistence consideration 12-34 BUFSIZE subparameter
default 12-33 of DD DCB parameter 12-61
description 12-32 BUFSP subparameter
override 12-33 of DD AMP parameter 12-25
relationship to other control statement 12-33 BUILDING parameter
subparameter 12-33 of OUTPUT JCL statement 22-14
BLKSIZE subparameter description 22-14
coded with DATA parameter 12-48 subparameter 22-14
of DD DCB parameter 12-57 BURST parameter
BLKSZLIM parameter of DD statement 12-35
of DD statement 12-34 default 12-36
default 12-35 description 12-35
description 12-34 example 12-36
example 12-35 override 12-36
override 12-35 relationship to other control statement 12-36
relationship to other parameter 12-35 relationship to other parameter 12-36, 12-37,
subparameter 12-34 16-10, 20-15
block length subparameter 12-36
specifying in the DD SPACE parameter 12-180 of JES2 /*JOBPARM statement 27-5
BLOCK subparameter of JES2 /*OUTPUT statement 27-14
of OUTPUT JCL DATACK parameter 22-28 of OUTPUT JCL statement 22-15
blocks subparameter default 22-16
of DCB LIMCT subparameter 12-63 description 22-15
BLP subparameter example 22-16
of DD LABEL parameter 12-133 override 22-16
BPAM (basic partitioned access method) subparameter 22-15
subparameters of DD DCB parameter 12-57, 12-75

Index X-5
BYTES parameter CCSID parameter (continued)
of JES2 /*JOBPARM statement 27-5 of DD statement (continued)
of JES3 //*MAIN statement 28-25 subparameter 12-37, 16-10, 20-15
of JOB statement 20-11 of EXEC statement 16-9
bytes subparameter of JOB statement 20-15
of AMP BUFSP parameter 12-25 character set 22-45
of DD DCB BLKSIZE subparameter 12-57 chart 4-3
of DD DCB BUFL subparameter 12-57 special character set
of DD DCB BUFSIZE subparameter 12-61 specifying 12-201, 22-82
of DD DCB KEYLEN subparameter 12-63 use 12-203, 22-83
of DD DCB LRECL subparameter 12-63 use in parameter 4-4
of DD DCB RESERVE subparameter 12-70 use in syntax 4-3
of DD KEYLEN parameter 12-128 universal character set (UCS)
of DD LRECL parameter 12-140 specifying 12-200, 22-81
use in statement 4-3
character-arrangement table
C specifying on DD CHARS parameter 12-39
C subparameter specifying on OUTPUT JCL CHARS
of //*DATASET DDNAME parameter 28-5 parameter 22-16
of //*FORMAT STACKER parameter 28-15 character-set-code subparameter
of //*MAIN BYTES parameter 28-25 of DD UCS parameter 12-201
of //*MAIN CARDS parameter 28-25 of OUTPUT JCL UCS parameter 22-81
of //*MAIN LINES parameter 28-30 CHARS parameter
of //*MAIN PAGES parameter 28-31 affect of DD MODIFY parameter 12-144
of DCB MODE subparameter 12-63 affect of OUTPUT JCL MODIFY parameter 22-54
of DCB OPTCD subparameter 12-66, 12-68, 12-69 affect of OUTPUT JCL TRC parameter 22-80
of DCB TRTCH subparameter 12-73 of DD statement 12-39
CANCEL subparameter default 12-40
of //*MAIN BYTES parameter 28-25 description 12-39
of //*MAIN CARDS parameter 28-25 example 12-41
of //*MAIN FAILURE parameter 28-28 override 12-40
of //*MAIN LINES parameter 28-30 printer reassignment 12-41
of //*MAIN PAGES parameter 28-31 relationship to other control statement 12-41
of JOB BYTES parameter 20-12 relationship to other parameter 12-41
of JOB CARDS parameter 20-13 subparameter 12-40
of JOB LINES parameter 20-22 of JES2 /*OUTPUT statement 27-14
of JOB PAGES parameter 20-30 of JES3 //*FORMAT PR statement 28-10
CARDS parameter of OUTPUT JCL statement 22-16
of JES2 /*JOBPARM statement 27-5 default 22-17
of JES3 //*MAIN statement 28-25 description 22-16
of JOB statement 20-13 example 22-17
cards subparameter override 22-17
JES2 format of JOB accounting information 20-8 subparameter 22-16
carriage control character checkid subparameter
specifying 22-24 of JOB RESTART parameter 20-43
CARRIAGE parameter checkpoint
of JES3 //*FORMAT PR statement 28-10 allowing and suppressing 16-26, 20-37
carriage-tape-name subparameter logical page size 22-18
of //*FORMAT CARRIAGE parameter 28-10 of data set 13-17
catalog of program 13-15
private or user restart 20-42
specification for job 13-1 written after specified number of logical
specification for step 13-7 pages 22-18
CATLG subparameter written after specified number of seconds 22-19
of DD DISP parameter 12-88, 12-89 CHKPT parameter
cccc subparameter of DD statement 12-41
of /*JOBPARM SYSAFF parameter 27-7 description 12-41
CCSID parameter example 12-42
of DD statement 12-37 for concatenated data set 12-42
description 12-37 override 12-42
examples 12-38 relationship to other parameter 12-42

X-6 z/OS V1R3.0 MVS JCL Reference

CHKPT parameter (continued) CNTL statement (continued)
of DD statement (continued) comments field 11-1
relationship to SYSCKEOV DD statement 12-42, description 11-1
13-17 example 11-2
subparameter 12-42 label field 11-1
CHNSIZE parameter location in JCL 11-2
of JES3 //*FORMAT PR statement 28-11 operation field 11-1
of JES3 //*FORMAT PU statement 28-19 parameter field 11-1
CKPTLINE parameter of DD statement 12-43
of OUTPUT JCL statement 22-18 description 12-43
default 22-18 example 12-43
description 22-18 subparameter 12-43
example 22-18 code parameter
CKPTLNS parameter parameter of JES2 /*OUTPUT statement 27-14
of JES2 /*OUTPUT statement 27-14 code subparameter
CKPTPAGE parameter of EXEC COND parameter 16-12
of OUTPUT JCL statement 22-18 of JOB COND parameter 20-18
default 22-19 code-name subparameter
description 22-18 of DD SYSOUT parameter 12-195
example 22-19 COLORMAP parameter
relationship to other parameter 22-19 of OUTPUT JCL statement 22-22
subparameter 22-19 description 22-22
CKPTPGS parameter example 22-23
of JES2 /*OUTPUT statement 27-14 subparameter 22-22
CKPTSEC parameter command statement
of OUTPUT JCL statement 22-19 in JCL 8-1
default 22-20 comments field 8-2
description 22-19 description 8-1
example 22-20 example 8-2
relationship to other parameter 22-20 location in JCL 8-2
subparameter 22-20 operation field 8-1
CLASS parameter parameter field 8-2
of JES3 //*DATASET statement 28-5 in JES2 27-1
of JES3 //*MAIN statement 28-26 description 27-1
of JOB statement 20-16 example 27-3
assigning 20-16 location in JCL 27-2
default 20-17 operand 27-2
description 20-16 parameter 27-2
example 20-17 in JES3 28-2
override 20-17 description 28-2
relationship to other control statement 20-17 example 28-3
subparameter 20-17 location in JCL 28-3
of OUTPUT JCL statement 22-20 operand 28-3
description 22-20 parameter 28-3
example 22-22 COMMAND statement
override 22-21 in JCL
subparameter 22-20 comments field 9-2
class subparameter description 9-1
of //*DATASET DDNAME parameter 28-5 example 9-3
of DD SYSOUT parameter 12-194 location in JCL 9-2
of JOB MSGCLASS parameter 20-25 name field 9-2
of OUTPUT JCL CLASS parameter 22-20 operation field 9-2
class-name subparameter parameter field 9-2
of //*MAIN CLASS parameter 28-26 command-verb parameter
CLOSE macro instruction of JES2 command statement 27-2
with DD SPACE parameter 12-183 of JES3 command statement 28-3
with the DD FREE parameter 12-124 comment statement
CLOSE subparameter in JCL 10-1
of DD FREE parameter 12-123 description 10-1
CNTL statement example 10-1
in JCL 11-1 location in JCL 10-1

Index X-7
comment statement (continued) COND parameter (continued)
in JCL (continued) of JOB statement (continued)
relationship to MSGLEVEL parameter 10-1 override 20-19
comments field subparameter 20-18
on JCL statement 3-1 summary chart 20-19
continuing 3-5 on EXEC statement 13-4
COMP subparameter effect on private job library specification 13-4
of DCB TRTCH subparameter 12-73 CONTIG subparameter
COMPACT parameter of DD SPACE parameter 12-184
of JES2 /*OUTPUT statement 27-15 continuing statement
of JES3 //*FORMAT PR statement 28-11 example 3-5
of JES3 //*FORMAT PU statement 28-19 JCL statement 3-4
of OUTPUT JCL statement 22-23 JES2 control statement 3-6
default 22-23 JES3 control statement 3-6
description 22-23 CONTROL parameter
example 22-23 of JES3 //*FORMAT PR statement 28-11
override 22-23 of OUTPUT JCL statement 22-24
subparameter 22-23 default 22-25
compaction description 22-24
of data 12-73 example 22-25
compaction table subparameter 22-24
specifying 22-23 converter/interpreter service
compaction-table-name subparameter in job processing 28-44
of //*FORMAT COMPACT parameter 28-11, 28-19 COPIES parameter
of OUTPUT JCL COMPACT parameter 22-23 of DD statement 12-44
comparison operator default 12-45
on IF/THEN/ELSE/ENDIF statement construct 17-2, description 12-44
17-3 example 12-46
completion code override 12-45
with IF/THEN/ELSE/ENDIF statement relationship to other control statement 12-46
construct 17-4 relationship to other parameter 12-45
COMSETUP parameter relationship to OUTPUT JCL COPIES
of OUTPUT JCL statement 22-23 parameter 12-46
description 22-23 subparameter 12-44
example 22-24 of JES2 /*JOBPARM statement 27-5
subparameter 22-24 of JES2 /*OUTPUT statement 27-15
concatenation of JES3 //*FORMAT PR statement 28-12
of data of JES3 //*FORMAT PU statement 28-20
block size 12-16 of OUTPUT JCL statement 22-25
checkpointing 12-42 default 22-26
coding concatenation 12-16 description 22-25
description 12-16 example 22-26
device 12-16 override 22-26
logical record length 12-16 relationship to other control statement 22-26
of job catalog 13-2 relationship to other parameter 22-26
of job library 13-4 subparameter 22-25
of step catalog 13-8 relationship to DD FLASH parameter 12-122
of step library 13-10 copies subparameter
reference 12-16 JES2 format of JOB accounting information 20-8
with dummy data set 12-18 copy
with dummy data set 12-112 attributes from a model data set 12-138
COND parameter jobstream to sysout 20-50
of EXEC statement 16-10 COPY subparameter
caution 16-13 of JOB TYPRUN parameter 20-50
description 16-10 COPYG parameter
example 16-16 of JES2 /*OUTPUT statement 27-15
override 16-13 count subparameter
subparameter 16-12 of //*FORMAT FLASH parameter 28-14
of JOB statement 20-17 of /*OUTPUT FLASH parameter 27-17
description 20-17 of /*OUTPUT FLASHC parameter 27-18
example 20-19 of DD FLASH parameter 12-121

X-8 z/OS V1R3.0 MVS JCL Reference

count subparameter (continued) data set (continued)
of OUTPUT JCL FLASH parameter 22-40 migration 12-141
CPRI subparameter multivolume
of DD DCB parameter 12-61 referenced in VOLUME=REF
CROPS subparameter subparameter 12-216
of DD AMP parameter 12-26 specifying volume 12-213
CX subparameter organization
of DCB DSORG subparameter 12-61 with DSORG subparameter 12-61
cycle subparameter partitioned (PDS)
of //*MAIN DEADLINE parameter 28-26 naming 12-102, 12-104
CYL subparameter partitioned data set extended(PDSE)
of DD SPACE parameter 12-180 naming 12-102, 12-104
cylinders passed
specifying in DD SPACE parameter 12-180 unit count 12-205
CYLOFL subparameter permanent
of DD DCB parameter 12-61 naming 12-102
record-level sharing, VSAM 12-174
requesting resource 2-2
D sequence number
D subparameter specifying in DD LABEL parameter 12-131
of //*MAIN BYTES parameter 28-25 system-managed
of //*MAIN CARDS parameter 28-25 sending to other destination 22-51
of //*MAIN LINES parameter 28-30 specifying processing 22-50
of //*MAIN PAGES parameter 28-31 temporary
of //*NET ABNORMAL parameter 28-39 naming 12-104
of //*NET NORMAL parameter 28-39 data-class-name subparameter
of DCB BFALN subparameter 12-57 of DD DATACLAS parameter 12-51
of DCB BFTEK subparameter 12-57 data-set-name subparameter
of DCB FUNC subparameter 12-62 of DD LGSTREAM parameter 12-137
of RECFM parameter 12-168 of DD LIKE parameter 12-139
DA subparameter data-set-sequence-number subparameter
of DCB DSORG subparameter 12-61 of DD LABEL parameter 12-131
data control block DATACK parameter
completing 12-55 of OUTPUT JCL statement 22-27
completion during execution 12-53 default 22-28
copying attribute 12-54 description 22-27
DATA parameter example 22-28
of DD statement 12-47 relationship to other parameter 22-28
default 12-48 subparameter 22-28
description 12-47 DATACLAS parameter
example 12-49 of DD statement 12-50
location in JCL 12-49 default 12-51
relationship to other control statement 12-49 description 12-50
relationship to other parameter 12-48 example 12-52
unread record 12-49 override 12-52
data set relationship to other parameter 12-52
attribute subparameter 12-51
specifying on DD LIKE parameter 12-138 date subparameter
specifying on DD REFDD parameter 12-170 of //*MAIN DEADLINE parameter 28-26
specifying with DD DATACLAS parameter 12-50 DAU subparameter
specifying with DD DCB parameter 12-53 of DCB DSORG subparameter 12-61
backup 12-141 DCB macro 12-53
checkpoint DCB parameter
for checkpointing data set 13-17 macro instruction 12-53
for checkpointing program 13-15 of DD statement 12-53
in generation group description 12-53
in restarted job 20-44 example 12-56
labels for 12-132 relationship to other parameter 12-56
naming 12-102 subparameter 12-54, 12-57
indexed sequential DD statement
naming 12-102, 12-104 in JCL 12-1

Index X-9
DD statement (continued) delimiter (continued)
comments field 12-15 with DD DATA statement 12-47
ddname 12-1 with XMIT JCL statement 26-5
description 12-1 delimiter statement
example 12-18 in JCL 14-1
location in JCL 12-15 comments field 14-1
name field 12-1 description 14-1
operation field 12-3 example 14-2
parameter field 12-3 location in JCL 14-2
maximum statements per job 12-1 relationship to DLM parameter 14-1
special DD statement delimiter subparameter
description 13-1 of DD DLM parameter 12-97
ddname field subparameter of XMIT JCL DLM parameter 26-5
example 12-18 DEN subparameter
invalid with DD AMP parameter 12-30 of DD DCB parameter 12-61
on DD statement 12-1 density
reserved for special use 13-1 magnetic
special ddname 12-2 specification for tape data set 12-61
DDNAME parameter DEPT parameter
of DD statement 12-75 of JES3 //*NETACCT statement 28-42
description 12-75 OUTPUT JCL statement parameter 22-31
example 12-78 description 22-31
location in JCL 12-75 subparameter 22-31
location of referenced statement 12-76 dept subparameter
override 12-75 of //*NETACCT DEPT parameter 28-42
parameters not permitted on referenced DD DEST parameter
statement 12-76 of DD statement 12-80
referenced DD statement 12-76 default 12-83
relationship to other parameter 12-75 description 12-80
subparameter 12-75 example 12-84
of JES3 //*DATASET statement 28-4 override 12-83
of JES3 //*FORMAT PR statement 28-9 relationship to other control statement 12-84
of JES3 //*FORMAT PU statement 28-18 relationship to other parameter 12-83
ddname subparameter subparameters for JES2 12-81
of //*MAIN FETCH parameter 28-29 subparameters for JES3 12-82
of /*JOBPARM PROCLIB parameter 27-6 of JES2 /*OUTPUT statement 27-16
of DD DDNAME parameter 12-75 of JES3 //*FORMAT PR statement 28-12
DEADLINE parameter of JES3 //*FORMAT PU statement 28-20
of JES3 //*MAIN statement 28-26 of OUTPUT JCL statement 22-32
default default 22-35
location of default OUTPUT JCL statement 22-10 description 22-32
OUTPUT JCL statement 22-9 example 22-35
specifying statement 22-28 override 22-35
DEFAULT parameter relationship to other parameter 22-35
of OUTPUT JCL statement 22-28 subparameter for JES2 22-33
default 22-29 subparameters for JES3 22-34
description 22-28 of XMIT JCL statement 26-4
example 22-30 description 26-4
location in JCL 22-29 example 26-4
references to default OUTPUT JCL subparameter 26-4
statement 22-29 dest-name parameter
subparameter 22-29 of JES2 /*SIGNON statement 27-28
DEFER subparameter destination
of DD UNIT parameter 12-206 for data set
DELETE subparameter specifying on OUTPUT JCL statement 22-32
of DD DISP parameter 12-87, 12-88 specifying on XMIT JCL statement 26-4
delimiter specifying on OUTPUT JCL statement 12-80
for JES3 in-stream data set 28-6 device
for transmission of input stream 26-1 sharing through unit affinity 12-206
processing when invalid 12-97, 26-5 specifying in DD UNIT parameter 12-203
with DD * statement 12-18

X-10 z/OS V1R3.0 MVS JCL Reference

device-name subparameter DPAGELBL parameter
of //*FORMAT DEST parameter 28-13, 28-20 of OUTPUT JCL statement 22-36
of DD DEST parameter 12-82 default 22-37
of OUTPUT JCL DEST parameter 22-34 description 22-36
subparameter of //*NET DEVPOOL example 22-37
parameter 28-39 relationship to other parameter 22-37
device-number subparameter subparameter definition 22-36
of //*FORMAT DEST parameter 28-13, 28-20 DS subparameter
of DD DEST parameter 12-82 of //*FORMAT CHNSIZE parameter 28-11, 28-19
of DD UNIT parameter 12-204 DSID parameter
device-type subparameter of DD statement 12-97
of DD UNIT parameter 12-204 description 12-97
DEVPOOL parameter example 12-99
of JES3 //*NET statement 28-39 relationship to other parameter 12-98
DEVRELSE parameter subparameter 12-98
of JES3 //*NET statement 28-40 DSNAME parameter
DHWS subparameter invalid with DD AMP parameter 12-30
of //*MAIN SETUP parameter 28-33 of DD statement 12-99
DIAGNS subparameter description 12-99
of DD DCB parameter 12-61 example 12-106
directory subparameter relationship to other parameter 12-106
of DD SPACE parameter 12-182 subparameter 12-101
for system assignment 12-182 subparameter for dummy data set 12-105
disability A-1 subparameters for permanent data set 12-101
DISP parameter subparameters for temporary data set 12-103
of DD statement 12-84 subparameters when copying data set
default 12-89 name 12-105
description 12-84 dsname subparameter
example 12-95 of //*MAIN UPDATE parameter 28-36
relationship to other parameter 12-90 of DD DCB parameter 12-54
subparameter 12-85 of DD DSNAME parameter 12-102
with DSNAME parameter 12-106 of VOLUME=REF subparameter 12-215
disposition DSNTYPE parameter
DISP=MOD for multivolume data set 12-91 of DD statement 12-108
of data set description 12-108
at abnormal termination 12-88 example 12-109
at normal termination 12-87 override 12-109
of generation data set 12-90 relationship to other parameter 12-109
of partitioned data set 12-90 subparameter 12-109
of QSAM data set 12-90 DSORG subparameter
of sysout data set of DD DCB parameter 12-61
at abnormal termination 22-59 DSP (dynamic support program)
at normal termination 22-59 calling 28-44
of temporary data set 12-90 dsp parameter
DJC (dependent job control) network 28-37 of JES3 //*PROCESS statement 28-45
DLM parameter dummy file
of DD statement 12-96 for OS/390 UNIX System Services 12-152
default 12-97 DUMMY parameter
description 12-96 for HFS file 12-152
example 12-97 in concatenation 12-18
relationship to other parameter 12-97 of DD statement 12-110
subparameter 12-97 description 12-110
of JES2 /*XMIT statement 27-31 example 12-112
of XMIT JCL statement 26-5 parameter 12-111
default 26-5 relationship to other control statement 12-112
description 26-5 relationship to other parameter 12-111
example 26-6 referenced in VOLUME=REF subparameter 12-218
subparameter 26-5 same effect with NULLFILE 12-105
DOUBLE subparameter dump
of //*FORMAT CONTROL parameter 28-11 duplicate request 13-14
of OUTPUT JCL CONTROL parameter 22-24 high-density 12-40, 12-118, 22-17, 22-39

Index X-11
dump (continued) EOV subparameter
printing 13-13 of DD CHKPT parameter 12-42
request on DD statement 12-41, 12-118 EQ subparameter
request on OUTPUT JCL statement 22-17, 22-39 of EXEC COND parameter 16-12
specification by SYSABEND, SYSMDUMP, and of JOB COND parameter 20-19
SYSUDUMP DD statement 13-12 EROPT subparameter
storage 13-13 of DD DCB parameter 12-62
DUMP subparameter error
of //*MAIN BYTES parameter 28-25 coding DD OUTPUT parameter 12-148
of //*MAIN CARDS parameter 28-25 in reading or writing a data set
of //*MAIN LINES parameter 28-30 specifying options for 12-62
of //*MAIN PAGES parameter 28-31 error messages
of JOB BYTES parameter 20-12 printing with PSF 22-27
of JOB CARDS parameter 20-13 ES subparameter
of JOB LINES parameter 20-22 of DD RECORG parameter 12-170
of JOB PAGES parameter 20-30 ET subparameter
on DD CHARS parameter 12-40 of DCB TRTCH subparameter 12-73
on OUTPUT JCL CHARS parameter 22-17 EVEN subparameter
DUPLEX parameter of EXEC COND parameter 16-12
of OUTPUT JCL statement 22-37 EXCP (execute channel program)
description 22-37 subparameters of DD DCB parameter 12-57, 12-75
example 22-38 EXEC statement
relationship to other parameter 22-38 in JCL 16-1
subparameter definition 22-37 comments field 16-5
DYNAM parameter description 16-1
of DD statement 12-113 example 16-5
description 12-113 location in JCL 16-5
example 12-114 name field 16-1
relationship to other control statement 12-114 operation field 16-2
relationship to other parameter 12-113 parameter field 16-2
dynamic system symbol 5-12 execution
DYNAMNBR parameter bypassing 16-10, 20-17
of EXEC statement 16-18 holding 20-50
default 16-18 of job at network node 28-47
description 16-18 restarting step 16-26, 20-37
example 16-19 specifying program 16-23
subparameter 16-18 timing 16-31, 20-47
EXPDT parameter
of DD statement 12-114
E description 12-114
E subparameter example 12-116
of //*DATASET DDNAME parameter 28-5 override 12-115
of DCB BFTEK subparameter 12-57 relationship to other parameter 12-115
of DCB CPRI subparameter 12-61 subparameter 12-115
of DCB MODE subparameter 12-63 EXPDTCHK parameter
of DCB OPTCD subparameter 12-66 of JES3 //*MAIN statement 28-28
of DCB TRTCH subparameter 12-73 expiration
EBCDIC character of data set
converting to ASCII code 12-68 deleting before 12-115, 12-174
EBCDIC text specifying in DD EXPDT parameter 12-114
description 4-3 specifying in DD LABEL parameter 12-134
END subparameter extents
of DD FREE parameter 12-123 allocation 12-182
ENDCNTL statement EXTWTR parameter
in JCL 15-1 of JES3 //*FORMAT PR statement 28-13
comments field 15-1 of JES3 //*FORMAT PU statement 28-21
description 15-1
example 15-1
label field 15-1 F
location in JCL 15-1 F subparameter
operation field 15-1 of //*NET ABNORMAL parameter 28-39

X-12 z/OS V1R3.0 MVS JCL Reference

F subparameter (continued) FLASH parameter (continued)
of //*NET NORMAL parameter 28-39 of OUTPUT JCL statement (continued)
of AMP RECFM subparameter 12-27 example 22-41
of DCB BFALN subparameter 12-57 override 22-41
of DCB OPTCD subparameter 12-66 relationship to other parameter 22-41
of RECFM parameter 12-167, 12-168, 12-169 subparameter 22-40
FAILURE parameter FLASHC
of JES3 //*MAIN statement 28-28 of JES2 /*OUTPUT statement 27-18
FB subparameter flashing
of AMP RECFM subparameter 12-27 printing with 12-120, 22-40
FCB parameter printing without 12-122, 22-41
of DD statement 12-116 relationship to DD COPIES parameter 12-45
default 12-117 relationship to OUTPUT JCL COPIES
defining for work station 12-118 parameter 22-26
description 12-116 FLSH subparameter
example 12-118 of //*NET NRCMP parameter 28-40
override 12-117 FOLD subparameter
relationship to other control statement 12-118 of DD UCS parameter 12-201
relationship to other parameter 12-118 form
subparameter 12-117 for printing or punching 12-116, 22-38
of JES2 /*OUTPUT statement 27-17 JES2 format subparameter of JOB accounting
of JES3 //*FORMAT PR statement 28-13 information 20-8
of OUTPUT JCL statement 22-38 specifying on OUTPUT JCL FORMS
default 22-39 parameter 22-44
description 22-38 specifying on sysout DD statement 12-193
example 22-40 form-name subparameter
override 22-39 of //*FORMAT FORMS parameter 28-14, 28-21
relationship to other parameter 22-39 of DD SYSOUT parameter 12-195
subparameter 22-39 of OUTPUT JCL FORMS parameter 22-44
fcb-name subparameter format
of DD FCB parameter 12-117 of statement
of OUTPUT JCL FCB parameter 22-39 field 3-1
FETCH parameter FORMDEF parameter
of JES3 //*MAIN statement 28-29 of OUTPUT JCL statement 22-42
file description 22-42
HFS example 22-42
dummy 12-152 override 22-42
file definition statement 12-53 subparameter 22-42
FILEDATA parameter FORMLEN parameter
of DD statement 12-119 of OUTPUT JCL statement 22-43
default 12-120 description 22-43
description 12-119 FORMS parameter
example 12-120 of JES2 /*JOBPARM statement 27-5
override 12-120 of JES2 /*OUTPUT statement 27-18
relationship to other parameter 12-120 of JES3 //*FORMAT PR statement 28-14
subparameter 12-120 of JES3 //*FORMAT PU statement 28-21
syntax 12-120 of OUTPUT JCL statement 22-44
FLASH parameter default 22-44
of DD statement 12-120 description 22-44
default 12-121 example 22-44
description 12-120 override 22-44
example 12-122 subparameter 22-44
override 12-121 FREE parameter
relationship to other control statement 12-122 affect on JES2 /*JOBPARM COPIES
relationship to other parameter 12-121 parameter 27-5
subparameter 12-121 of DD statement 12-122
of JES2 /*OUTPUT statement 27-17 default 12-123
of JES3 //*FORMAT PR statement 28-14 description 12-122
of OUTPUT JCL statement 22-40 example 12-124
default 22-41 override 12-123
description 22-40 relationship to other control statement 12-124

Index X-13
FREE parameter (continued) GTF (generalized trace facility)
of DD statement (continued) use 12-61
relationship to other parameter 12-123
subparameter 12-123
FRLOG subparameter 12-26 H
FSSDATA parameter H subparameter
of OUTPUT JCL statement 22-44 of DCB OPTCD subparameter 12-66, 12-68
description 22-44 H11 character set code
FUNC subparameter for 3211 printer 12-202, 22-82
of DD DCB parameter 12-62 hard-copy log
with LABEL parameter 12-134 job
request to not print 27-6
send messages to in JES3 system 28-43
G specifying processing 22-50
G11 character set HC parameter
for 3211 printer 12-202, 22-82 abbreviation of NHOLD parameter of JES3 //*NET
GAM (graphics access method) statement 28-38
subparameters of DD DCB parameter 12-57, 12-75 HFS subparameter
GE subparameter of DD DSNTYPE parameter 12-109
of EXEC COND parameter 16-12 HIGH subparameter
of JOB COND parameter 20-19 of //*MAIN IORATE parameter 28-29
generation subparameter HN character set code
of DD DSNAME parameter 12-102 for 1403 and 3203 Model 5 printer 12-202, 22-82
GENERIC subparameter HOLD parameter
of DD SECMODEL parameter 12-177 affect on JES2 /*JOBPARM COPIES
GNCP subparameter parameter 27-5
of DD DCB parameter 12-62 of DD statement 12-125
group default 12-126
output description 12-125
specifying on the OUTPUT JCL statement 22-47 examples 12-127
GROUP parameter override 12-126
of JOB statement 20-19 relationship to other control statement 12-127
default 20-20 relationship to other parameter 12-127
description 20-19 subparameter 12-126
example 20-20 of JES3 //*MAIN statement 28-29
subparameter 20-20 HOLD subparameter
group-name parameter of //*MAIN FAILURE parameter 28-28
of //*FORMAT DEST parameter 28-13, 28-20 of //*NET NRCMP parameter 28-40
of //*MAIN ORG parameter 28-31 of JOB TYPRUN parameter 20-51
of DD DEST parameter 12-82 holding
of DD UNIT parameter 12-204 job
of JOB GROUP parameter 20-20 specifying 20-50
of OUTPUT JCL DEST parameter 22-34 HWS subparameter
group-value subparameter of //*MAIN SETUP parameter 28-33
of //*FORMAT COPIES parameter 28-12
of /*OUTPUT COPIES parameter 27-15
of /*OUTPUT COPYG parameter 27-15 I
of DD COPIES parameter 12-45 I subparameter
of OUTPUT JCL COPIES parameter 22-25 of AMP OPTCD subparameter 12-26
GROUPID parameter of DCB FUNC subparameter 12-62
of OUTPUT JCL statement 22-47 of DCB OPTCD subparameter 12-69
description 22-47 ID parameter
example 22-47 abbreviation of NETID parameter of JES3 //*NET
relationship to other control statement 22-47 statement 28-38
subparameter 22-47 id subparameter
GS subparameter of DD DSID parameter 12-98
of DCB DSORG subparameter 12-61 IF/THEN/ELSE/ENDIF statement construct
GT subparameter in JCL
of EXEC COND parameter 16-12 comments field 17-7
of JOB COND parameter 20-19 comparison operator 17-2, 17-3
considerations 17-8

X-14 z/OS V1R3.0 MVS JCL Reference

IF/THEN/ELSE/ENDIF statement construct (continued) information subparameter
in JCL (continued) of EXEC PARM parameter 16-21
description 17-1 input stream
ELSE clause 17-7 description 2-1
location in the JCL 17-7 halt reading
logical operator 17-2, 17-3 in JES3 system 28-43
name field 17-1 INT parameter
NOT operator 17-4 of JES3 //*FORMAT PU statement 28-21
operation field 17-2 INTRAY parameter
relational-expression 17-2 of OUTPUT JCL statement 22-49
relationship to other parameter 17-7 description 22-49
THEN clause 17-7 example 22-49
use of parenthesis 17-7 relationship to other parameter 22-49
IGNORE subparameter subparameter 22-49
of //*MAIN THWSSEP parameter 28-35 INTRDR subparameter
IL subparameter of OUTPUT JCL WRITER parameter 22-89
of AMP OPTCD subparameter 12-26 INTVL subparameter
image-name subparameter of DD DCB parameter 12-62
of //*FORMAT FCB parameter 28-13 IORATE parameter
IN subparameter of JES3 //*MAIN statement 28-29
of DD LABEL parameter 12-134 IPCS (interactive problem control system)
of OUTPUT JCL OFFSETXB parameter 22-57 to print dump 13-14
in-stream data IPLTXID subparameter
for procedure 12-20 of DD DCB parameter 12-62
multiple in-stream data sets in a step 12-20 IS subparameter
with DD * statement 12-18 of DCB DSORG subparameter 12-61
with DD DATA statement 12-49 ISO/ANSI/FIPS Version 1 or 3 tape data set
with DSNAME parameter 12-104 indicating in DD LABEL parameter 12-132
with JES3 //*DATASET statement 28-4 restriction on DD DISP parameter 12-86
with SYSIN DD statement 13-18 with DD ACCODE parameter 12-22
INCLUDE group ISU subparameter
considerations for using 18-2 of DCB DSORG subparameter 12-61
description 18-1
INCLUDE statement
in JCL J
comments field 18-2 J parameter
considerations for using 18-2 of JES3 //*DATASET statement 28-5
description 18-1 J subparameter
example 18-2 of DCB OPTCD subparameter 12-68
location in the JCL 18-2 JCL (job control language)
name field 18-1 format 3-1
operation field 18-1 statement 1-1
parameter field 18-1 JCL subparameter
IND subparameter of OUTPUT JCL JESDS parameter 22-50
of /*JOBPARM SYSAFF parameter 27-7 JCL symbol
INDEX parameter See parameter, symbolic
of OUTPUT JCL statement 22-48 JCLHOLD subparameter
default 22-49 of JOB TYPRUN parameter 20-51
description 22-48 JCLLIB statement
example 22-49 in JCL
relationship to other parameter 22-49 comments field 19-3
subparameter 22-49 consideration 19-3
parameter of JES2 /*OUTPUT statement 27-18 description 19-1
index subparameter example 19-3
of DD SPACE parameter location in the JCL 19-3
for specific request 12-185 name field 19-2
for system assignment 12-183 operation field 19-2
indexing parameter field 19-2
of print margins JCLTEST subparameter
specifying on OUTPUT JCL statement 22-48, of EXEC PGM parameter 16-24
22-49, 22-52

Index X-15
JES (job entry subsystem) job log (continued)
running a started task 7-6 statements in listing 6-1
JES2 symbolic parameter 6-1
statement 1-1, 3-4, 27-1 JOB statement
format 3-4 in JCL 20-1
location in JCL 27-1 comments field 20-6
JES3 description 20-1
statement 1-1, 3-4, 28-1 example 20-6
example 28-1 location in JCL 20-6
format 3-4 name field 20-1
location in JCL 28-1 operation field 20-2
JESDS parameter parameter field 20-2
location of statement containing 22-10 started tasks 20-2
of OUTPUT JCL statement 22-50 JOB subparameter
description 22-50 of //*MAIN SETUP parameter 28-33
example 22-51 job-level
location in JCL 22-51 OUTPUT JCL statement level 22-10
override 22-51 job-level output
subparameter 22-50 control of 7-3
JESJCL subparameter JOBCAT DD statement
of //*FORMAT DDNAME parameter 28-9 description 13-1
JESLOG parameter of JOB statement 20-21 example 13-2
JESMSGLG subparameter location in JCL 13-2
of //*FORMAT DDNAME parameter 28-9 overriding with STEPCAT DD statement 13-8
JESYSMSG parameter 13-2
of //*FORMAT DDNAME parameter 28-9 relationship to other control statement 13-2
JGLOBAL subparameter relationship to STEPCAT 13-2
of //*MAIN SYSTEM parameter 28-34 jobclass subparameter
JLOCAL subparameter of JOB CLASS parameter 20-17
of //*MAIN SYSTEM parameter 28-34 JOBLIB DD statement
job description 13-2
background or batch jobs example 13-6
affect on DD TERM parameter 12-199 location in JCL 13-4
beginning 20-1 overriding for a step 13-4, 13-10
class parameter 13-3
assigning 20-16 relationship to other control statement 13-4
held 22-21, 27-5 relationship to passed data sets 13-5
dependent relationship to STEPLIB 13-4
specifying in JES3 system 28-37 with COND=ONLY parameter 16-14
description 2-1 jobname
entering 2-1 coding 20-1
foreground jobs jobname subparameter
affect on DD TERM parameter 12-199 of //*NET NETREL parameter 28-40
nonstandard processing of //*NET RELEASE parameter 28-41
description 28-44 JOURNAL parameter
processing 2-2 of JES3 //*MAIN statement 28-30
controlling in JES3 system 28-44 JSTTEST subparameter
specifying control 20-1 of EXEC PGM parameter 16-24
specifying control in JES3 system 28-22
restarting
with EXEC COND parameter 16-14 K
standard processing K subparameter
description 28-44 of DD AVGREC parameter 12-32
job log KEEP subparameter
assigning to an output class 20-25 of //*NET ABCMP parameter 28-38
cataloged procedure statement 7-1 of DD DISP parameter 12-87, 12-89
controlling listing 20-26 keyboard A-1
in-stream procedure statement 7-1 KEYLEN parameter
job control statement 7-1 of DD statement 12-127
listing 6-1 description 12-127
specifying processing 22-50 example 12-128

X-16 z/OS V1R3.0 MVS JCL Reference

KEYLEN parameter (continued) library (continued)
of DD statement (continued) procedure
override 12-128 adding 5-1
relationship to other parameter 12-128 use for procedure 2-1
subparameter 12-128 LIBRARY subparameter
KEYLEN subparameter of DD DSNTYPE parameter 12-109
of DD DCB parameter 12-63 LIKE parameter
KEYOFF parameter of DD statement 12-138
of DD statement 12-129 description 12-138
description 12-129 example 12-139
example 12-130 override 12-139
override 12-129 relationship to other parameter 12-139
relationship to other parameter 12-130 subparameter 12-139
subparameter 12-129 LIMCT subparameter
keys of DD DCB parameter 12-63
data set limit subparameter
specifying on DCB KEYLEN subparameter 12- of //*FORMAT THRESHLD parameter 28-15
63 of OUTPUT JCL THRESHLD parameter 22-78
specifying on DD KEYLEN parameter 12-127 limiting
specifying on DD KEYOFF parameter 12-129 of lines per printed page 20-9
KS subparameter output
of DD RECORG parameter 12-170 by specifying DD OUTLIM parameter 12-145
maximum size of sysout data set 22-77
of lines per printed page 22-52
L with JOB statement BYTES parameter 20-11
L subparameter with JOB statement CARDS parameter 20-13
of AMP OPTCD subparameter 12-26 with JOB statement LINES parameter 20-22
of DCB BUFOFF subparameter 12-61 with JOB statement PAGES parameter 20-30
of DCB OPTCD subparameter 12-66, 12-69 LINDEX parameter
label of JES2 /*OUTPUT statement 27-19
data set of OUTPUT JCL statement 22-52
copying attribute 12-54 default 22-52
specifying in DD LABEL parameter 12-132 description 22-52
type copied when DD statement example 22-52
referenced 12-218 relationship to other parameter 22-52
LABEL parameter subparameter 22-52
of DD statement 12-130 LINE subparameter
default 12-134 of OUTPUT JCL PRMODE parameter 22-67
description 12-130 LINECT parameter
example 12-135 of JES2 /*JOBPARM statement 27-5
relationship to other control statement 12-135 of JES2 /*OUTPUT statement 27-19
relationship to other parameter 12-134 linect subparameter
subparameter 12-131 JES2 format of JOB accounting information 20-9
LE subparameter of OUTPUT JCL statement 22-52
of EXEC COND parameter 16-12 default 22-53
of JOB COND parameter 20-19 description 22-52
LGSTREAM parameter example 22-53
of DD statement 12-136 subparameter 22-53
defaults 12-137 LINES parameter
description 12-136 of JES2 /*JOBPARM statement 27-6
example 12-137 of JES3 //*MAIN statement 28-30
override 12-137 of JOB statement 20-22
relationship to other parameter 12-137 lines subparameter
subparameter 12-137 JES2 format of JOB accounting information 20-8
library LOCAL parameter
private of JES2 /*ROUTE statement 27-23
cataloging procedure 5-1 LOCAL subparameter
retrieving procedure 5-2 of /*OUTPUT DEST parameter 27-16
specifying for job 13-2, 19-1 of DD DEST parameter 12-81
specifying for step 13-9 of OUTPUT JCL DEST parameter 22-33

Index X-17
log subparameter membername subparameter (continued)
JES2 format of JOB accounting information 20-9 of OUTPUT JCL PAGEDEF parameter 22-64
LOG subparameter message
of OUTPUT JCL JESDS parameter 22-50 from functional subsystem 22-65
logical operator specifying processing 22-50
on IF/THEN/ELSE/ENDIF statement construct 17-2, to operator in JES3 system 28-43
17-3 messages subparameter
LOW subparameter of JOB MSGLEVEL parameter 20-27
of //*MAIN IORATE parameter 28-29 MGMTCLAS parameter
lowercase of DD statement 12-141
in syntax 4-1 default 12-142
LRECL parameter description 12-141
of DD statement 12-140 example 12-143
description 12-140 override 12-142
example 12-141 relationship to other parameter 12-143
override 12-141 subparameter 12-142
relationship to other parameter 12-141 minutes subparameter
subparameter 12-140 of EXEC TIME parameter 16-32
LRECL subparameter of JOB TIME parameter 20-48
of DD DCB parameter 12-63 mmm subparameter
LREGION parameter of //*MAIN BYTES parameter 28-25
of JES3 //*MAIN statement 28-31 of //*MAIN CARDS parameter 28-25
LS subparameter of //*MAIN LINES parameter 28-30
of DD RECORG parameter 12-170 of //*MAIN PAGES parameter 28-31
LT subparameter of OUTPUT JCL OFFSETXB parameter 22-57
of EXEC COND parameter 16-12 MOD subparameter
of JOB COND parameter 20-19 of DD DISP parameter 12-85
LTM subparameter mode
of DD LABEL parameter 12-133 printing
specifying on OUTPUT JCL statement 22-67
MODE parameter
M of JES3 //*DATASET statement 28-5
m subparameter MODE subparameter
of //*FORMAT CHNSIZE parameter 28-11, 28-19 of DD DCB parameter 12-63
M subparameter modification
of DCB OPTCD subparameter 12-69 by specifying copy-modification module 12-143,
of DD AVGREC parameter 12-32 22-53
of DD RECFM parameter 12-167, 12-168 of procedure DD statement 5-4
MACRF operand coding 5-4
of DCB macro instruction MODIFY parameter
when coding DUMMY 12-112 of DD statement 12-143
main service default 12-144
in job processing 28-44 description 12-143
main-name subparameter example 12-145
of //*MAIN SYSTEM parameter 28-34 override 12-144
management-class-name subparameter relationship to other control statement 12-144
of DD MGMTCLAS parameter 12-142 relationship to other parameter 12-144
Master subsystem subparameter 12-144
JCL restrictions with START SUB=MSTR 7-6 of JES2 /*OUTPUT statement 27-19
restrictions with a started task 7-6 of JES3 //*FORMAT PR statement 28-14
running a started task 7-6 of OUTPUT JCL statement 22-53
MAXIMUM subparameter default 22-54
of the JOB TIME parameter 20-48 description 22-53
on the EXEC TIME parameter 16-32 example 22-54
MED subparameter override 22-54
of //*MAIN IORATE parameter 28-29 relationship to other parameter 22-54
member subparameter subparameter 22-54
of DCB INTVL subparameter 12-62 MODTRC parameter
of DD DSNAME parameter 12-102, 12-104 of JES2 /*OUTPUT statement 27-20
membername subparameter module subparameter
of OUTPUT JCL FORMDEF parameter 22-42 of AMP SYNAD subparameter 12-28

X-18 z/OS V1R3.0 MVS JCL Reference

module-name subparameter n or number subparameter (continued)
of //*FORMAT MODIFY parameter 28-14 of DCB BUFOFF subparameter 12-61
of /*OUTPUT MODIFY parameter 27-19 of DCB GNCP subparameter 12-62
of DD MODIFY parameter 12-144 of DCB INTVL subparameter 12-62
of OUTPUT JCL MODIFY parameter 22-54 of DCB NCP parameter 12-63
mounting of DCB RKP subparameter 12-70
of volumes of DCB THRESH subparameter 12-72
deferred 12-206 of DD COPIES parameter 12-44
parallel 12-206 of DD OUTLIM parameter 12-145
MSG subparameter of DD RETPD parameter 12-173
of OUTPUT JCL JESDS parameter 22-50 of EXEC DYNAMNBR parameter 16-18
msg-count subparameter of EXEC PERFORM parameter 16-22
of OUTPUT JCL PIMSG parameter 22-65 of JOB PERFORM parameter 20-34
MSGCLASS parameter of OUTPUT JCL CKPTPAGE parameter 22-19
of JOB statement 20-25 of OUTPUT JCL CKPTSEC parameter 22-20
default 20-25 of OUTPUT JCL COPIES parameter 22-25
description 20-25 of OUTPUT JCL INDEX parameter 22-49
example 20-26 of OUTPUT JCL INTRAY parameter 22-49
subparameter 20-25 of OUTPUT JCL LINDEX parameter 22-52
MSGCLASS subparameter of OUTPUT JCL LINECT parameter 22-53
of //*DATASET DDNAME parameter 28-5 of OUTPUT JCL PRTY parameter 22-71
MSGLEVEL parameter N subparameter
of JOB statement 20-26 of /*JOBPARM BURST parameter 27-5
default 20-27 of /*JOBPARM RESTART parameter 27-6
description 20-26 of /*OUTPUT BURST parameter 27-14
example 20-28 of DCB PCI subparameter 12-69
subparameter 20-27 name
MXIG subparameter in name field of OUTPUT JCL statement 22-1
of DD SPACE parameter 12-184 qualified
for data set 12-101
unqualified
N for data set 12-101
n or number subparameter name parameter
of //*FORMAT CHNSIZE parameter 28-11, 28-19 of JES2 /*ROUTE statement 27-23
of //*FORMAT COPIES parameter 28-12, 28-20 NAME parameter
of //*FORMAT PRTY parameter 28-15 of OUTPUT JCL statement 22-55
of //*MAIN BYTES parameter 28-25 description 22-55
of //*MAIN CARDS parameter 28-25 subparameter 22-55
of //*MAIN LINES parameter 28-30 name subparameter
of //*MAIN PAGES parameter 28-31 of //*FORMAT EXTWTR parameter 28-13, 28-21
of //*NET DEVPOOL parameter 28-39 of //*NET NETID parameter 28-38
of //*NET NHOLD parameter 28-40 of /*OUTPUT DEST parameter 27-16
of //*NET RELSCHCT parameter 28-41 of DD DEST parameter 12-81
of //*NETACCT ACCT parameter 28-42 of OUTPUT JCL DEST parameter 22-33
of /*JOBPARM BYTES parameter 27-5 of OUTPUT JCL WRITER parameter 22-89
of /*JOBPARM CARDS parameter 27-5 NC parameter
of /*JOBPARM COPIES parameter 27-5 abbreviation of NORMAL parameter of JES3 //*NET
of /*JOBPARM LINECT parameter 27-5 statement 28-38
of /*JOBPARM LINES parameter 27-6 NC subparameter
of /*JOBPARM PAGES parameter 27-6 of EXEC RD parameter 16-27
of /*JOBPARM TIME parameter 27-7 of JOB RD parameter 20-39
of /*OUTPUT CKPTLNS parameter 27-14 NCK subparameter
of /*OUTPUT CKPTPGS parameter 27-14 of AMP CROPS subparameter 12-26
of /*OUTPUT COMPACT parameter 27-15 NCP subparameter
of /*OUTPUT COPIES parameter 27-15 of DD DCB parameter 12-63
of /*OUTPUT INDEX parameter 27-18 NE subparameter
of /*OUTPUT LINDEX parameter 27-19 of EXEC COND parameter 16-12
of /*OUTPUT LINECT parameter 27-19 of JOB COND parameter 20-19
of AMP BUFND parameter 12-25 NET subparameter
of AMP BUFNI parameter 12-25 of //*NET DEVPOOL parameter 28-39
of AMP STRNO parameter 12-27

Index X-19
NETID parameter nodename subparameter
of JES3 //*NET statement 28-38 of //*FORMAT DEST parameter 28-13, 28-20
netid subparameter of //*MAIN ORG parameter 28-31
of //*NET NETREL parameter 28-40 of /*OUTPUT DEST parameter 27-16
NETREL parameter of DD DEST parameter 12-83
of JES3 //*NET statement 28-40 of OUTPUT JCL DEST parameter 22-34, 22-35
network-account-number parameter of XMIT JCL DEST parameter 26-4
of JES2 /*NETACCT statement 27-10 NOHO subparameter
NEW subparameter of //*NET NRCMP parameter 28-40
of DD DISP parameter 12-85 NOKP subparameter
new-password subparameter of //*NET ABCMP parameter 28-38
of JOB PASSWORD parameter 20-33 NOLIMIT subparameter
parameter of JES2 /*SIGNON statement 27-28 of the JOB TIME parameter 20-48
parameter of JES3 /*SIGNON statement 28-51 on the EXEC TIME parameter 16-32
NHOLD parameter NOLOG parameter
of JES3 //*NET statement 28-40 of JES2 /*JOBPARM statement 27-6
NL subparameter non-SMS-managed data set
of DD LABEL parameter 12-132 with DD VOLUME=REF subparameter 12-217
Nn parameter NONE subparameter
of JES2 /*ROUTE statement 27-23 of //*MAIN FETCH parameter 28-29
of JES2 /*XEQ statement 27-29 of /*OUTPUT FLASH parameter 27-17
of JES2 /*XMIT statement 27-31 of DD FLASH parameter 12-121
Nn subparameter of OUTPUT JCL FLASH parameter 22-40
of /*OUTPUT DEST parameter 27-16 NOPWREAD subparameter
of DD DEST parameter 12-81 of DD LABEL parameter 12-134
of OUTPUT JCL DEST parameter 22-33 NORMAL parameter
nnnnK subparameter of JES3 //*NET statement 28-39
of //*MAIN LREGION parameter 28-31 NORMAL subparameter
NO subparameter of OUTPUT JCL DUPLEX parameter 22-37
of //*DATASET DDNAME parameter 28-5 NOT (¬) operator
of //*FORMAT FORMS parameter 28-21 of IF/THEN/ELSE/ENDIF statement construct 17-4
of //*MAIN EXPDTCHK parameter 28-28 notation
of //*MAIN HOLD parameter 28-29 for syntax 4-1
of //*MAIN JOURNAL parameter 28-30 Notices B-1
of //*MAIN RINGCHK parameter 28-32 notification
of //*NET DEVRELSE parameter 28-40 of job completion 20-28
of //*NET OPHOLD parameter 28-41 receiving 20-29
of DD BURST parameter 12-36 NOTIFY parameter
of DD HOLD parameter 12-126 of JOB statement 20-28
of OUTPUT JCL BURST parameter 22-15 description 20-28
of OUTPUT JCL DEFAULT parameter 22-29 example 20-29
of OUTPUT JCL DPAGELBL parameter 22-37 subparameter for JES2 20-28
of OUTPUT JCL DUPLEX parameter 22-37 subparameter for JES3 20-29
of OUTPUT JCL PIMSG parameter 22-65 of OUTPUT JCL statement 22-56
of OUTPUT JCL SYSAREA parameter 22-77 description 22-56
of OUTPUT JCL TRC parameter 22-80 subparameter 22-57
NOCOMP subparameter NR parameter
of DCB TRTCH subparameter 12-73 abbreviation of NETREL parameter of JES3 //*NET
node statement 28-38
affect on JES2 /*JOBPARM COPIES NR subparameter
parameter 27-8 of EXEC RD parameter 16-27
of execution 27-8 of JOB RD parameter 20-39
node subparameter NRC subparameter
of DD DEST parameter 12-82, 12-83 of AMP CROPS subparameter 12-26
nodename parameter NRCMP parameter
of JES2 /*NOTIFY statement 27-11 of JES3 //*NET statement 28-40
of JES2 /*ROUTE statement 27-23, 27-24 NRE parameter
of JES2 /*XEQ statement 27-29 of AMP CROPS subparameter 12-26
of JES2 /*XMIT statement 27-31 NSL subparameter
of JES3 //*ROUTE XEQ 28-48 of DD LABEL parameter 12-132

X-20 z/OS V1R3.0 MVS JCL Reference

NTM subparameter OPHOLD parameter
of DD DCB parameter 12-66 of JES3 //*NET statement 28-41
null statement OPTCD subparameter
in JCL of DD AMP parameter 12-26
description 21-1 of DD DCB parameter 12-66
example 21-1 OR (|) operator
location in JCL 21-1 of IF/THEN/ELSE/ENDIF statement construct 17-3
null subparameter ORG parameter
of //*FORMAT DDNAME parameter 28-9, 28-18 of JES3 //*MAIN statement 28-31
NULLFILE subparameter organization subparameter
of DD DSNAME parameter 12-105 of DCB DSORG subparameter 12-61
NxxRnnnn OUT subparameter
parameter of JES2 /*SIGNON statement 27-28 of DD LABEL parameter 12-134
OUTBIN parameter
of OUTPUT JCL statement 22-59
O OUTDISP parameter
O subparameter of OUTPUT JCL statement 22-59
of DCB MODE subparameter 12-63 description 22-59
OFF subparameter subparameter 22-60
of //*FORMAT OVFL parameter 28-15 OUTLIM parameter
offset-to-key subparameter of DD statement 12-145
of DD KEYOFF parameter 12-129 default 12-145
OFFSETXB parameter description 12-145
of OUTPUT JCL statement 22-57 example 12-146
description 22-57 relationship to other control statement 12-146
example 22-58 relationship to other parameter 12-145
subparameter 22-57 subparameter 12-145
OFFSETXF parameter output
of OUTPUT JCL statement 22-58 class
description 22-58 assigning job log 20-25
OFFSETYB parameter held in JES2 system 12-197
of OUTPUT JCL statement 22-58 relationship to DD SYSOUT parameter 12-197
description 22-58 significance 12-197, 20-25, 22-21
OFFSETYF parameter specifying on OUTPUT JCL statement 22-20
of OUTPUT JCL statement 22-58 specifying on sysout DD statement 12-193
description 22-58 limiting from job 20-8
OH parameter specifying copy number 12-44, 22-25, 28-12
abbreviation of OPHOLD parameter of JES3 //*NET OUTPUT parameter
statement 28-38 of DD statement 12-146
OLD subparameter default 12-147
of DD DISP parameter 12-85 description 12-146
omission example 12-149
of ddname from DD statement 12-2 location in JCL 12-148
ON subparameter override 12-147
of //*FORMAT OVFL parameter 28-15 relationship to other parameter 12-148
ONLY subparameter subparameter 12-147
of EXEC COND parameter 16-13 output service
Open/Close/EOV trace option 12-62 in job processing 28-44
operating system OUTPUT statement
content 2-1 in JCL
operator comments field 22-9
messages to in JES3 system 28-43 default definition 22-9
on IF/THEN/ELSE/ENDIF statement construct 17-2 description 22-1
operator commands example of job and step-level statement 22-10
entered with JCL COMMAND statement 9-1 job-level statement 22-10
entering through JCL command statement 8-1 location in JCL 22-9
entering through JES2 command statement 27-1 location in procedure 22-10
entering through JES3 command statement 28-2 location of default statement 22-10
operator subparameter name field 22-1
of EXEC COND parameter 16-12 operation field 22-1
of JOB COND parameter 20-18 override 22-11

Index X-21
OUTPUT statement (continued) pano subparameter
in JCL (continued) JES2 format of JOB accounting information 20-8
parameter field 22-2 parameter
relationship to DD statement COPIES keyword
parameter 12-46 on DD statement 12-4
relationship to JES2 /*OUTPUT statement 22-11 on EXEC statement 16-2
relationship to JES3 //*FORMAT statement 22-11 on EXEC statement that calls procedure 16-5
relationship to sysout DD statement 22-11 on JOB statement 20-2
step-level statement 22-10 on OUTPUT JCL statement 22-2
output-group subparameter syntax 3-3
of OUTPUT JCL GROUPID parameter 22-47 usage warning 3-2
overflow positional
holding 12-61 on DD statement 12-3
overlay-name subparameter on EXEC statement 16-2
of //*FORMAT FLASH parameter 28-14 on JOB statement 20-2
of /*OUTPUT FLASH parameter 27-17 optionally required by installation 20-6, 20-35
of DD FLASH parameter 12-121 syntax 3-3
of OUTPUT JCL FLASH parameter 22-40 symbolic
OVERLAYB parameter coding 5-12, 5-17
of OUTPUT JCL statement 22-62 default substitution text 5-15
OVERLAYF parameter defining 5-13
of OUTPUT JCL statement 22-62 example 5-24
overrides in nested procedure 5-26
of cataloged and in-stream procedures location 5-17
of DD statement 5-4 nullifying 5-13, 5-16
of EXEC statement parameter 5-3 overriding a system symbol 5-15
of OUTPUT JCL statement 5-4 purpose 5-12
with DD DUMMY statement 12-112 syntax 5-14
OVFL parameter parentheses
of JES3 //*FORMAT PR statement 28-15 with relational-expression 17-7
of OUTPUT JCL statement 22-63 PARM parameter
of EXEC statement 16-20
description 16-20
P example 16-21
p parameter subparameter 16-21
of /*PRIORITY statement 27-21 partition-name subparameter
P subparameter of //*MAIN SPART parameter 28-34
of DCB FUNC subparameter 12-62 PASS subparameter
of DD UNIT parameter 12-206 of DD DISP parameter 12-87
P11 character set password
for 3211 printer 12-202, 22-82 for protection of data set 12-133
PAGE subparameter PASSWORD parameter
of OUTPUT JCL PRMODE parameter 22-67 of JOB statement 20-31
page-mode printer description 20-31
on OUTPUT JCL FORMDEF parameter 22-42 example 20-33
on OUTPUT JCL PAGEDEF parameter 22-64 relationship to other parameter 20-33
on OUTPUT JCL PRMODE parameter 22-67 subparameter 20-32
PAGEDEF parameter password subparameter
of OUTPUT JCL statement 22-63 of JOB PASSWORD parameter 20-32
description 22-63 PASSWORD subparameter
example 22-64 of DD LABEL parameter 12-134
override 22-64 password1 parameter
subparameter 22-64 of JES2 /*SIGNON statement 27-28
pages of JES3 /*SIGNON statement 28-51
in printed output password2 parameter
limiting length 20-9, 22-52 of JES2 /*SIGNON statement 27-28
PAGES parameter of JES3 /*SIGNON statement 28-51
of JES2 /*JOBPARM statement 27-6 PATH parameter
of JES3 //*MAIN statement 28-31 of DD statement 12-150
of JOB statement 20-30 defaults 12-151
description 12-150

X-22 z/OS V1R3.0 MVS JCL Reference

PATH parameter (continued) performance group
of DD statement (continued) specifying
dummy HFS file 12-152 on the EXEC statement 16-21
example 12-153 on the JOB statement 20-33
relationship to other parameter 12-151 PGM parameter
relationship to other statements 12-152 of EXEC statement 16-23
subparameter 12-150 description 16-23
PATHDISP parameter example 16-24
of DD statement 12-153 subparameter 16-23
defaults 12-154 PIMSG parameter
description 12-153 of OUTPUT JCL statement 22-65
example 12-154 default 22-66
relationship to other parameter 12-154 description 22-65
subparameter 12-154 example 22-66
PATHMODE parameter subparameter 22-65
of DD statement 12-155 PIPE subparameter
defaults 12-157 of DD DSNTYPE parameter 12-109
description 12-155 PN character set
example 12-158 for 1403 and 3203 Model 5 printer 12-202, 22-82
relationship to other parameter 12-157 PNAME parameter
subparameter 12-155 of JES3 //*NETACCT statement 28-42
PATHOPTS parameter PO subparameter
of DD statement 12-158 of DCB DSORG subparameter 12-61
defaults 12-160 PORTNO parameter
description 12-158 of OUTPUT JCL statement 22-66
example 12-162 POU subparameter
file status 12-161 of DCB DSORG subparameter 12-61
relationship to other parameter 12-161 PR parameter
subparameter 12-159 of JES3 //*FORMAT PR statement 28-9
PC parameter PREFER subparameter
abbreviation of NRCMP parameter of JES3 //*NET of //*MAIN THWSSEP parameter 28-35
statement 28-38 primary-qty subparameter
PCAN character set of //*MAIN TRKGRPS parameter 28-35
for 1403 and 3203 Model 5 printer 12-202, 22-82 of DD SPACE parameter
PCHN character set for specific request 12-185
for 1403 and 3203 Model 5 printer 12-202, 22-82 for system assignment 12-181
PCI subparameter PRINT parameter
of DD DCB parameter 12-69 of JES2 /*ROUTE statement 27-22
PDS subparameter PRINT subparameter
of DD DSNTYPE parameter 12-109 of //*MAIN FAILURE parameter 28-28
PEND statement PRINTDEV statement
in JCL 23-1 DATACK default 22-28
comments field 23-1 defined resource libraries 22-72
description 23-1 example 11-2
example 23-1 PIMSG default 22-66
location in JCL 23-1 printing
name field 23-1 output data set
operation field 23-1 controlling spacing in output 22-24, 28-11
PERFORM parameter processing instructions in JES3 system 28-7
of EXEC statement 16-21 protection
default 16-22 with OUTPUT JCL DPAGELBL parameter 22-36
description 16-21 with OUTPUT JCL DUPLEX parameter 22-37
example 16-23 with OUTPUT JCL SYSAREA parameter 22-76
override 16-22 priority
subparameter 16-22 initiation or selection
of JOB statement 20-33 specifying 20-36
default 20-34 of lines for transmission 12-61
description 20-33 of operator
example 20-34 of operator 17-2
override 20-34 output queue
subparameter 20-34 for sysout data set 22-71

Index X-23
priority (continued) procedure (continued)
queue selection cataloged and in-stream (continued)
requested on JES2 /*PRIORITY statement 27-21 statements as listed in job log 7-1
specifying 20-36 system symbol 5-12
priority subparameter testing 2-1, 5-2
of JOB PRTY parameter 20-37 using 5-2
PRIVATE subparameter nested
of DD VOLUME parameter 12-212 description 5-9
PRMODE parameter example 5-9
of OUTPUT JCL statement 22-67 modifying procedure statement 5-10
default 22-67 symbolic parameter 5-26
description 22-67 private library 5-1
example 22-68 search order 5-2
subparameter 22-67 procedure-name subparameter
PROC parameter of EXEC PROC parameter 16-25
of EXEC statement 16-25 process-mode subparameter
description 16-25 of OUTPUT JCL PRMODE parameter 22-67
example 16-25 processing
subparameter 16-25 of data set
of JES3 //*MAIN statement 28-32 for input or output 12-134
PROC statement with multiple references in DD OUTPUT
in JCL 24-1 parameter 12-148
comments field 24-2 processor-id subparameter
description 24-1 of //*MAIN ACMAIN parameter 28-24
example 24-2 PROCLIB parameter
location in JCL 24-2 of JES2 /*JOBPARM statement 27-6
name field 24-1 PROCLIB, ordering searches with JCLLIB
operation field 24-2 statement 19-1
override 24-2 procname subparameter
parameter field 24-2 of DD QNAME parameter 12-165
procedure procstepname subparameter
calling search order 5-2 of EXEC ACCT parameter 16-7
cataloged and in-stream of EXEC ADDRSPC parameter 16-9
affect of parameters on calling EXEC of EXEC COND parameter 16-12, 16-13
statement 16-5 of EXEC DYNAMNBR parameter 16-18
calling 16-25 of EXEC PARM parameter 16-21
cataloging 5-1 of EXEC PERFORM parameter 16-22
description 2-1, 5-1 of EXEC RD parameter 16-28
effect of PROC parameter on other parameters of EXEC TIME parameter 16-32
and following statement 16-25 subparameter of EXEC REGION parameter 16-31
example 5-7 profile-name subparameter
example of symbols 5-24 of DD SECMODEL parameter 12-177
in-stream data 12-20 program
indicating beginning 24-1 control 11-1
indicating end 23-1 end 15-1
JCL symbol 5-12 statement 11-2
location of DD statements when overriding or execution 16-23
adding to procedure 12-15 location of executable program 13-2, 13-9
maximum per job 5-1 PROGRAM subparameter
modifying DD statement 5-4 of //*FORMAT CONTROL parameter 28-11
modifying OUTPUT JCL statement 5-4 of OUTPUT JCL CONTROL parameter 22-24
overriding ACCT parameter 16-7 program-name subparameter
overriding ADDRSPC parameter 16-9 of EXEC PGM parameter 16-23
overriding COND parameter 16-13 programmer’s-name parameter
overriding DYNAMNBR parameter 16-18 of JOB statement 20-35
overriding EXEC statement parameter 5-3 description 20-35
overriding PARM parameter 16-21 example 20-36
overriding PERFORM parameter 16-22 parameter 20-35
overriding RD parameter 16-28 programmer’s-name subparameter
overriding REGION parameter 16-31 of //*NETACCT PNAME parameter 28-42
overriding TIME parameter 16-32

X-24 z/OS V1R3.0 MVS JCL Reference

PROTECT parameter punch
of DD statement 12-162 output data set
description 12-162 processing options in JES3 system 28-17
example 12-164 PUNCH parameter
override 12-163 of JES2 /*ROUTE statement 27-22
relationship to other parameter 12-163 purge service
requirements for protecting direct access data in job processing 28-44
set 12-164
requirements for protecting tape data set 12-163
requirements for protecting tape volume 12-163 Q
subparameter 12-163 Q subparameter
protection of DCB OPTCD subparameter 12-68
data set QISAM (queued indexed sequential access method)
by password 12-133 subparameters of DD DCB parameter 12-57, 12-75
through DD PROTECT parameter 12-162 QN character set
through DD SECMODEL parameter 12-176 for 1403 and 3203 Model 5 printer 12-202, 22-82
printed output QNAME parameter
with OUTPUT JCL DPAGELBL parameter 22-36 of DD statement 12-164
with OUTPUT JCL DUPLEX parameter 22-37 description 12-164
with OUTPUT JCL SYSAREA parameter 22-76 example 12-165
PRTOPTNS parameter relationship to other parameter 12-165
of OUTPUT JCL statement 22-69 subparameter 12-165
description 22-69 QNC character set
subparameter 22-70 for 1403 and 3203 Model 5 printer 12-202, 22-82
PRTQUEUE parameter QSAM (queued sequential access method)
of OUTPUT JCL statement 22-70 subparameters of DD DCB parameter 12-57, 12-98
description 22-70 with DD CHKPT parameter 12-42
subparameter 22-70
PRTSP subparameter
of DD DCB parameter 12-70 R
PRTY parameter R parameter
of JES3 //*FORMAT PR statement 28-15 of JES3 /*SIGNON statement 28-51
of JOB statement 20-36 R subparameter
default 20-37 of //*NET ABNORMAL parameter 28-39
description 20-36 of //*NET NORMAL parameter 28-39
example 20-37 of DCB BFTEK subparameter 12-57
subparameter 20-37 of DCB CPRI subparameter 12-61
of OUTPUT JCL statement 22-71 of DCB FUNC subparameter 12-62
default 22-71 of DCB MODE subparameter 12-63
description 22-71 of DCB OPTCD subparameter 12-66, 12-69
example 22-71 of DCB PCI subparameter 12-69
override 22-71 of EXEC RD parameter 16-27
subparameter 22-71 of JOB RD parameter 20-38
PS subparameter RACF (Resource Access Control Facility)
of DCB DSORG subparameter 12-61 discrete profile 12-162
PSF (Print Services Facility) new password 20-31
printing data set 22-42, 22-43, 22-63 protection
printing line-mode data 22-68 through DD PROTECT parameter 12-162
table reference character codes in JES2 through DD SECMODEL parameter 12-176
system 22-80 RACF-defined group 20-19
with DD CHARS parameter 12-40 RACF-defined password 20-31
with DD UCS parameter 12-202 RACF-defined user 20-52
with OUTPUT JCL CHARS parameter 22-17 with in-stream data set 12-104
with OUTPUT JCL DATACK parameter 22-27 with JOB SECLABEL parameter 20-45
with OUTPUT JCL PIMSG parameter 22-65 with OUTPUT JCL DPAGELBL parameter 22-36
with OUTPUT JCL UCS parameter 22-82 with OUTPUT JCL DUPLEX parameter 22-37
PSU subparameter with OUTPUT JCL SYSAREA parameter 22-76
of DCB DSORG subparameter 12-61 with sysout data set 12-104
PU parameter with temporary data set 12-103
of JES3 //*FORMAT PU statement 28-18 RC keyword
of IF/THEN/ELSE/ENDIF statement construct 17-4

Index X-25
RCK subparameter REFDD parameter (continued)
of AMP CROPS subparameter 12-26 of DD statement (continued)
RD parameter subparameter 12-171
of EXEC statement 16-26 reference
default 16-28 backward
description 16-26 coding 4-5, 12-78
example 16-28 example 4-6
override 16-28 to concatenated data set 12-16
relationship to other control statement 16-28 with DD DUMMY statement 12-112
subparameter 16-27 with EXEC COND parameter 16-14
of JOB statement 20-37 explicit
default 20-39 to OUTPUT JCL statement 22-9, 22-29
description 20-37 forward
example 20-40 to concatenated data set 12-16
override 20-39 implicit
relationship to other control statement 20-40 to OUTPUT JCL statement 22-9, 22-29
subparameter 20-38 using OUTPUT JCL DEFAULT parameter 22-28
reader region
internal default 16-30, 20-41
description 2-1 size
submitting job 27-1, 28-1 specifying 16-29, 20-40
with JES3 XMIT JCL statement 26-1, 26-6 REGION parameter
REAL subparameter of EXEC statement 16-29
of EXEC ADDRSPC parameter 16-8 default 16-30
of JOB ADDRSPC parameter 20-10 description 16-29
reassignment example 16-31
of printer 12-41 override 16-30
RECFM parameter relationship to the EXEC ADDRSPC
of DD statement 12-165 parameter 16-30
description 12-165 subparameter 16-29
example 12-169 of JOB statement 20-40
override 12-169 default 20-41
relationship to other parameter 12-169 description 20-40
RECFM subparameter example 20-42
of DD AMP parameter 12-27 override 20-42
of DD DCB parameter 12-70 relationship to the JOB ADDRSPC
reclgth subparameter parameter 20-42
of DD SPACE parameter 12-180 subparameter 20-41
record rel subparameter
specifying length 12-31, 12-63, 12-140 of //*MAIN DEADLINE parameter 28-26
specifying organization 12-169 relational-expression
record length on IF/THEN/ELSE/ENDIF statement construct
of new data set 12-140 continuing 17-2
specifying in the DD SPACE parameter 12-180 description 17-2
record-level sharing, VSAM 12-174 keyword 17-4
RECORG parameter operator 17-2
of DD statement 12-169 RELEASE parameter
default 12-170 of JES3 //*NET statement 28-41
description 12-169 RELSCHCT parameter
example 12-170 of JES3 //*NET statement 28-41
override 12-170 remote subparameter
relationship to other parameter 12-170 of //*FORMAT DEST parameter 28-13, 28-20
subparameter 12-170 of //*MAIN ORG parameter 28-31
REF subparameter REMOTEnnn parameter
of DD VOLUME parameter 12-215 of JES2 /*SIGNON statement 27-27
REFDD parameter requesting resources 2-6
of DD statement 12-170 tasks 2-6
description 12-170 task chart 2-6
example 12-172 REQUIRE subparameter
override 12-172 of //*MAIN THWSSEP parameter 28-35
relationship to other parameter 12-172

X-26 z/OS V1R3.0 MVS JCL Reference

RESERVE subparameter RLS parameter (continued)
of DD DCB parameter 12-70 description 12-174
reserved name example 12-175
on DSNAME parameter 12-106 override 12-175
RESFMT parameter relationship to other parameters 12-175
of OUTPUT JCL statement 22-71 subparameter 12-175
description 22-71 syntax 12-175
example 22-72 RLSE subparameter
subparameter 22-72 of DD SPACE parameter 12-183
restart Rm parameter
execution of JES2 /*ROUTE statement 27-23
at checkpoint 20-42 Rm subparameter
at step 20-42 of /*OUTPUT DEST parameter 27-16
requesting for all steps in job 20-37 of DD DEST parameter 12-81
requesting for step 16-26 of OUTPUT JCL DEST parameter 22-33
specifying 20-42 RMn parameter
with EXEC COND parameter 16-14 of JES2 /*ROUTE statement 27-23
RESTART parameter of JES2 /*SIGNON statement 27-28
of JES2 /*JOBPARM statement 27-6 RMn subparameter
of JOB statement 20-42 of /*OUTPUT DEST parameter 27-17
cautions with coding 20-44 of DD DEST parameter 12-82
description 20-42 of OUTPUT JCL DEST parameter 22-34
example 20-44 RMTn parameter
relationship to other control statement 20-43 of JES2 /*ROUTE statement 27-23
subparameter 20-43 of JES2 /*SIGNON statement 27-28
RESTART subparameter RMTn subparameter
subparameter of //*MAIN FAILURE of /*OUTPUT DEST parameter 27-17
parameter 28-28 of DD DEST parameter 12-82
RETAIN subparameter of OUTPUT JCL DEST parameter 22-34
of DD VOLUME parameter 12-212 RN character set
RETAINS|RETAINF parameter for 1403 and 3203 Model 5 printer 12-202, 22-82
of OUTPUT JCL statement 22-72 Rn parameter
description 22-72 of JES2 /*ROUTE statement 27-23
retention Rn subparameter
data set of /*OUTPUT DEST parameter 27-17
deleting before 12-174 of DD DEST parameter 12-82
specifying in DD RETPD parameter 12-172 of OUTPUT JCL DEST parameter 22-34
volume RNC subparameter
specifying by RETAIN subparameter 12-212 of EXEC RD parameter 16-27
RETPD parameter of JOB RD parameter 20-39
of DD statement 12-172 Rnnnn parameter
description 12-172 of JES2 /*SIGNON statement 27-28
example 12-174 ROOM parameter
override 12-173 of JES2 /*JOBPARM statement 27-7
relationship to other parameter 12-173 of JES3 //*NETACCT statement 28-43
subparameter 12-173 of OUTPUT JCL statement 22-75
RETRYL|RETRYT parameter description 22-75
of OUTPUT JCL statement 22-74 subparameter 22-75
description 22-74 room subparameter
return code JES2 format of JOB accounting information 20-8
with IF/THEN/ELSE/ENDIF statement of //*NETACCT ROOM parameter 28-43
construct 17-4 ROUND subparameter
RINGCHK parameter of DD SPACE parameter 12-185
of JES3 //*MAIN statement 28-32 RR subparameter
RKP subparameter of DD RECORG parameter 12-170
of DD DCB parameter 12-70 RS parameter
RL parameter abbreviation of RELSCHCT parameter of JES3
abbreviation of RELEASE parameter of JES3 //*NET //*NET statement 28-38
statement 28-38 RUN keyword
RLS parameter of IF/THEN/ELSE/ENDIF statement construct 17-4
of DD statement 12-174

Index X-27
S SET statement
in JCL
S subparameter
comments field 25-2
of //*FORMAT STACKER parameter 28-15
consideration 25-3
of DCB BFTEK subparameter 12-57
description 25-1
of DCB CPRI subparameter 12-61
example 25-3
of RECFM parameter 12-166, 12-168
location in the JCL 25-3
SCAN subparameter
name field 25-2
of JOB TYPRUN parameter 20-51
operation field 25-2
scheduling environment, WLM 20-46
override 25-3
SCHENV parameter
parameter field 25-2
of JOB statement 20-46
relationship to other control statement 25-3
default 20-47
SETUP parameter
description 20-46
of JES3 //*MAIN statement 28-33
example 20-47
SETUP subparameter
relationship to other control statements 20-47
of //*MAIN FETCH parameter 28-29
subparameter definition 20-47
shortcut keys A-1
search order
SHR subparameter
calling a procedure 5-2
of DD DISP parameter 12-85
SECLABEL parameter
SINGLE subparameter
of JOB statement 20-45
of //*FORMAT CONTROL parameter 28-11
default 20-46
of OUTPUT JCL CONTROL parameter 22-24
description 20-45
SKP subparameter
example 20-46
of DCB EROPT subparameter 12-62
relationship to other parameter 20-46
SL subparameter
subparameter definition 20-45
of DD LABEL parameter 12-132
seclabel-name subparameter
SMS (Storage Management Subsystem)
of JOB SECLABEL parameter 20-45
with data set password protection 12-133
SECMODEL parameter
with DD AMP parameter 12-23
of DD statement 12-176
with DD AVGREC parameter 12-31
description 12-176
with DD DATACLAS parameter 12-50
example 12-177
with DD DCB parameter 12-53
override 12-177
with DD DSNTYPE parameter 12-108
relationship to other parameter 12-177
with DD EXPDT parameter 12-114
subparameter 12-177
with DD KEYLEN parameter 12-127
second-qty subparameter
with DD KEYOFF parameter 12-129
of //*MAIN TRKGRPS parameter 28-35
with DD LIKE parameter 12-138
of DD SPACE parameter 12-181
with DD LRECL parameter 12-140
seconds subparameter
with DD MGMTCLAS parameter 12-141
of EXEC TIME parameter 16-32
with DD RECFM parameter 12-165
of JOB TIME parameter 20-48
with DD RECORG parameter 12-169
security label
with DD REFDD parameter 12-170
on DPAGELBL parameter 22-36
with DD RETPD parameter 12-172
on DUPLEX parameter 22-37
with DD SECMODEL parameter 12-176
on SECLABEL parameter 20-45
with DD SPACE parameter 12-186
on SYSAREA parameter 22-76
with DD SPACE reclgth subparameter 12-180
SEGMENT parameter
with DD STORCLAS parameter 12-189
of DD statement 12-177
with DD UNIT parameter 12-203
description 12-177
with DD VOLUME=REF subparameter 12-217
override 12-178
with JOBCAT DD statement 13-1
relationship to other parameter 12-178
with STEPCAT DD statement 13-8
subparameter 12-178
SMS-managed data set
sending
definition 12-189
to remote node
with data set password protection 12-133
input stream for execution 28-47
with DD MGMTCLAS parameter 12-141
SER subparameter
with DD STORCLAS parameter 12-189
of DD VOLUME parameter 12-214
with DD VOLUME=REF subparameter 12-217
serial-number parameter
with JOBCAT DD statement 13-1
of JES2 /*SETUP statement 27-25
with STEPCAT DD statement 13-8
serial-number subparameter
with temporary data set 12-103
of VOLUME=SER subparameter 12-214

X-28 z/OS V1R3.0 MVS JCL Reference

SN character set statement fields (continued)
for 1403 and 3203 Model 5 printer 12-202, 22-82 comments
SNA (systems network architecture) format 3-1
RJE (remote job entry) rules for continuation 3-5
DD * statement 12-20 continuation to following statement 3-4
RJP (remote job processing) identifier
DD * statement 12-20 format 3-1
space location in statement 3-2
in printed output name
specification 28-11 format 3-1
specifying 22-24 operation
on direct access format 3-1
request for specific track 12-185 parameter
system assignment 12-180 detailed syntax 3-3
SPACE parameter format 3-1
of DD statement 12-178 rules for continuation 3-5
description 12-178 statements subparameter
example 12-186 of JOB MSGLEVEL parameter 20-27
override 12-185 static system symbol 7-1
relationship to other parameter 12-185 See system symbol
specifying for data sets with SMS 12-186 status
subparameter 12-180 coded in DD DISP parameter 12-85
with DD AVGREC parameter 12-31 STD subparameter
SPART parameter of /*JOBPARM FORMS parameter 27-5
of JES3 //*MAIN statement 28-34 of /*OUTPUT FORMS parameter 27-18
SPIN parameter of OUTPUT JCL FCB parameter 22-39
of DD statement 12-187 of OUTPUT JCL FLASH parameter 22-40
default 12-187 of OUTPUT JCL FORMS parameter 22-44
description 12-187 on OUTPUT JCL CHARS parameter 22-17
override 12-188 STD1 forms control buffer image
relationship to other parameter 12-188 on DD FCB parameter 12-117
subparameter 12-187 on OUTPUT JCL FCB parameter 22-38
ST subparameter STD2 forms control buffer image
of //*MAIN PROC parameter 28-32 on DD FCB parameter 12-117
STACK subparameter on OUTPUT JCL FCB parameter 22-38
of DD DCB parameter 12-72 STD3 forms control buffer image
STACKER parameter on DD FCB parameter 12-117
of JES3 //*FORMAT PR statement 28-15 on OUTPUT JCL FCB parameter 22-38
STANDARD subparameter step
of //*FORMAT CHARS parameter 28-10 beginning 16-1
of //*FORMAT FLASH parameter 28-14 description 2-1
of //*FORMAT FORMS parameter 28-14, 28-21 maximum number 2-2
of //*FORMAT STACKER parameter 28-15 step-level
of //*FORMAT TRAIN parameter 28-15 OUTPUT JCL statement 22-10
START command STEPCAT DD statement
processing description 13-7
when member is job 7-3 example 13-8
when member is procedure 7-2 location in JCL 13-8
started task overriding JOBCAT DD statement 13-8
determining source JCL 7-1 parameter 13-8
determining when to use 7-1 relationship to other control statement 13-8
START command processing STEPLIB DD statement
when member is job 7-3 description 13-9
when member is procedure 7-2 example 13-11
started tasks location in JCL 13-11
JES2 considerations 27-1 parameter 13-9
JES3 considerations 28-1 relationship to JOBLIB 13-11
JOB statement 20-2 relationship to other control statement 13-10
statement fields stepname
chart 3-2 coding 16-1

Index X-29
stepname subparameter SUBSYS parameter (continued)
of EXEC COND parameter 16-12 description 12-190
of JOB RESTART parameter 20-43 example 12-193
stepname.ddname relationship to other parameter 12-192
on DD statement referenced by DD DDNAME subparameter 12-191
parameter 12-76 running under the master subsystem 7-6
stepname.ddname subparameter subsystem-name subparameter
of //*FORMAT DDNAME parameter 28-9, 28-18 of DD SUBSYS parameter 12-191
of //*MAIN SETUP parameter 28-33 subsystem-subparameter subparameter
stepname.procstepname subparameter of DD SUBSYS parameter 12-192
of JOB RESTART parameter 20-43 SUL subparameter
stepname.procstepname.ddname subparameter of DD LABEL parameter 12-132
of //*FORMAT DDNAME parameter 28-9, 28-18 symbol
of //*MAIN SETUP parameter 28-33 JCL symbol
storage See parameter, symbolic
administrator system symbol
with DD DATACLAS parameter 12-50 See system symbol
with DD MGMTCLAS parameter 12-141 SYNAD subparameter
with DD STORCLAS parameter 12-189 of DD AMP parameter 12-28
with DD UNIT parameter 12-203 syntax
with DD VOLUME=SER subparameter 12-215 for continuing statement 3-4
real format of statement 3-1
requesting for job 20-10 notation 4-1
requesting for step 16-8 of parameter 4-1
virtual scanning for error 20-50
requesting for job 20-10 scanning for errors
requesting for step 16-8 without execution 16-24
storage-class-name subparameter SYS1.PROCLIB system procedure library
of DD STORCLAS parameter 12-189 use for procedure 2-1
STORCLAS parameter SYSABEND DD statement
of DD statement 12-189 description 13-12
default 12-189 example 13-14
description 12-189 location in JCL 13-13
example 12-190 overriding 13-14
override 12-190 SYSAFF parameter
relationship to other parameter 12-190 of JES2 /*JOBPARM statement 27-7
subparameter 12-189 SYSALLDA group name
with DD UNIT parameter 12-203 assumed when in-stream data set
STRNO subparameter referenced 12-218
of DD AMP parameter 12-27 SYSAREA parameter
SUB=MSTR option of OUTPUT JCL statement 22-76
started task 7-6 default 22-77
SUBCHARS parameter 26-6 description 22-76
processing when invalid 26-7 example 22-77
XMIT JCL statement parameter 26-6 relationship to other parameter 22-77
default 26-7 subparameter definition 22-77
description 26-6 SYSCHK DD statement
example 26-7 description 13-15
subparameter 26-7 example 13-17
subparameter location in JCL 13-17
coding when multiple 3-3 parameter 13-16
syntax 3-3 relationship to other control statement 13-17
subparameter subparameter SYSCKEOV DD statement
of DD DCB parameter 12-54 description 13-17
substitute example 13-18
character location in JCL 13-18
with XMIT JCL statement 26-6 parameter 13-18
substitute subparameter relationship to DD CHKPT parameter 12-42
of XMIT JCL SUBCHARS parameter 26-7 SYSIN DD statement
SUBSYS parameter description 13-18
of DD statement 12-190 example 13-19

X-30 z/OS V1R3.0 MVS JCL Reference

SYSIN DD statement (continued) task (continued)
location in JCL 13-19 for entering jobs
parameter 13-19 chart 2-3
SYSMDUMP DD statement for processing jobs
description 13-12 chart 2-5
example 13-14 for requesting sysout data set resources
location in JCL 13-13 chart 2-8
overriding 13-14 TCAM (telecommunications access method)
sysout (system output data set) subparameters of DD DCB parameter 12-57, 12-75
associating with an OUTPUT JCL statement 12-146 with DD statement QNAME parameter 12-164
references to OUTPUT JCL statement 22-9 tcamname subparameter
specifying through DD SYSOUT parameter 12-193 of DD QNAME parameter 12-165
with DSNAME parameter 12-104 temporary data set 12-103
SYSOUT parameter TERM parameter
of DD statement 12-193 of DD statement 12-199
default 12-195 description 12-199
description 12-193 example 12-200
example 12-198 location in JCL 12-199
override 12-196 relationship to other parameter 12-199
relationship to other control statement 12-197 subparameter 12-199
relationship to other parameter 12-196 terminal
subparameter 12-194 data coming from or going to a terminal 12-199
relationship to DD COPIES parameter 12-45 termination
with DEST=(node) subparameter 12-83 abnormal
system completion code dump 13-12
with IF/THEN/ELSE/ENDIF statement evaluating 17-5
construct 17-4 normal
SYSTEM parameter dump 13-12
of JES3 //*MAIN statement 28-34 notification 20-28
system symbol testing return code 16-10, 17-4, 20-17
coding 5-13, 5-17 test
in started task 7-1, 7-8, 7-10 of on-line terminal 12-62
overridden by JCL symbol 5-15 return code
using in JCL 5-12 specifying 16-10, 17-4, 20-17
SYSUDUMP DD statement TEXT subparameter
description 13-12 of DD FILEDATA parameter 12-120
example 13-14 THRESH subparameter
location in JCL 13-13 of DD DCB parameter 12-72
overriding 13-14 THRESHLD parameter
SYSUID system symbolic parameter of JES3 //*FORMAT PR statement 28-15
description 5-23 of OUTPUT JCL statement 22-77
restriction 5-24 default 22-78
use in transaction program profile 5-23 description 22-77
example 22-78
subparameter 22-78
T THWS subparameter
T subparameter of //*MAIN SETUP parameter 28-33
of DCB EROPT parameter 12-62 THWSSEP parameter
of DCB FUNC subparameter 12-62 of JES3 //*MAIN statement 28-35
of DCB OPTCD subparameter 12-68 time
of DCB TRTCH subparameter 12-73 use by job 20-47
of RECFM parameter 12-166, 12-167, 12-168 use by job step 16-31
T11 character set TIME parameter
for 3211 printer 12-202, 22-82 of EXEC statement 16-31
table-name subparameter default 16-32
of //*FORMAT CHARS parameter 28-10 description 16-31
on DD CHARS parameter 12-40 example 16-33
on OUTPUT JCL CHARS parameter 22-16 override 16-32
task subparameter 16-32
chart 2-2 of JES2 /*JOBPARM statement 27-7
description 2-1 of JOB statement 20-47

Index X-31
TIME parameter (continued) TS subparameter
default 20-48 of DD TERM parameter 12-199
description 20-47 TUMBLE subparameter
example 20-49 of OUTPUT JCL DUPLEX parameter 22-38
override 20-48 TYPE parameter
subparameter 20-48 of JES3 //*MAIN statement 28-35
time subparameter type subparameter
of //*MAIN DEADLINE parameter 28-26 of //*FORMAT DEST parameter 28-13, 28-20
TIME subparameter of //*MAIN DEADLINE parameter 28-26
JES2 format of JOB accounting information 20-8 TYPRUN parameter
TITLE parameter of JOB statement 20-50
of OUTPUT JCL statement 22-79 description 20-50
description 22-79 example 20-52
subparameter 22-79 relationship to other control statement 20-51
TN character set subparameter 20-50
for 1403 and 3203 Model 5 printer 12-202, 22-82
TPROCESS macro instruction
accessing TCAM message 12-164 U
TRACE subparameter U subparameter
of DCB DIAGNS subparameter 12-61 of DCB OPTCD subparameter 12-68, 12-69
of DD AMP parameter 12-28 of DD AVGREC parameter 12-31
trace of DD RECFM parameter 12-166, 12-167, 12-168,
of OPEN/CLOSE/EOV 12-61 12-169
track UCS parameter
specifying in DD SPACE parameter 12-180 of DD statement 12-200
track subparameter default 12-202
of DCB CYLOFL subparameter 12-61 description 12-200
of DCB LIMCT subparameter 12-63 example 12-203
of DCB NCP parameter 12-66 override 12-202
TRAIN parameter relationship to other parameter 12-202
of JES3 //*FORMAT PR statement 28-15 subparameter 12-201
train-name subparameter of JES2 /*OUTPUT statement 27-20
of //*FORMAT TRAIN parameter 28-15 of OUTPUT JCL statement 22-81
translation default 22-81
of label description 22-81
specified by DD LABEL parameter 12-135 example 22-83
transmission override 22-82
of input stream to network node 28-47 subparameter 22-81
of input stream using XMIT JCL statement 26-1 Un parameter
TRC parameter of JES2 /*ROUTE statement 27-24
of OUTPUT JCL statement 22-80 Un subparameter
default 22-80 of /*OUTPUT DEST parameter 27-17
description 22-80 of DD DEST parameter 12-82
example 22-80 of OUTPUT JCL DEST parameter 22-34
relationship to other parameter 22-80 UNBLOCK subparameter
subparameter 22-80 of OUTPUT JCL DATACK parameter 22-28
trc subparameter UNCATLG subparameter
of //*FORMAT FORMS parameter 28-14 of DD DISP parameter 12-88, 12-89
of /*OUTPUT MODIFY parameter 27-19 unit affinity
of /*OUTPUT MODTRC parameter 27-20 specifying in AFF subparameter 12-206
of DD MODIFY parameter 12-144 when DDNAME parameter is also coded 12-76
of OUTPUT JCL MODIFY parameter 22-54 UNIT parameter
TRIPLE subparameter of DD statement 12-203
of //*FORMAT CONTROL parameter 28-11 description 12-203
of OUTPUT JCL CONTROL parameter 22-24 example 12-208
TRK subparameter location in JCL 12-208
of DD SPACE parameter 12-180 override 12-207
TRKGRPS parameter relationship to other parameter 12-207
of JES3 //*MAIN statement 28-35 subparameter 12-204
TRTCH subparameter relationship to DD COPIES parameter 12-45
of DD DCB parameter 12-73

X-32 z/OS V1R3.0 MVS JCL Reference

unit-count subparameter vmguestid parameter (continued)
of DD UNIT parameter 12-205 of JES2 /*XEQ statement 27-29
UPDATE parameter of JES2 /*XMIT statement 27-31
of JES3 //*MAIN statement 28-36 of JES3 //*ROUTE XEQ 28-48
uppercase vmguestid subparameter
in syntax 4-1 of XMIT JCL DEST parameter 26-4
user completion code volume
with IF/THEN/ELSE/ENDIF statement nonspecific request
construct 17-4 allocation 12-182
USER parameter specifying 12-218
of JES3 //*MAIN statement 28-36 volume count 12-214
of JOB statement 20-52 number
default 20-53 affect on number of devices allocated 12-205
description 20-52 specifying by volume-count subparameter 12-
example 20-53 213
relationship to other parameter 20-53 private
subparameter 20-53 specifying in PRIVATE subparameter 12-212
userid retention
data coming from or going to a user 12-199 specifying by RETAIN subparameter 12-212
userid parameter serial numbers
of JES2 /*NOTIFY statement 27-11 specifying by SER subparameter 12-214
of JES2 /*ROUTE statement 27-23 VOLUME parameter
of JES2 /*XMIT statement 27-31 of DD statement 12-210
userid subparameter description 12-210
of //*MAIN USER parameter 28-36 example 12-219
of //*NETACCT USERID parameter 28-43 in JES3 system 12-218
of /*OUTPUT DEST parameter 27-16 override 12-218
of DD DEST parameter 12-82, 12-83 relationship to other parameter 12-218
of JES3 //*NETACCT statement 28-43 subparameter 12-212
of JOB NOTIFY parameter 20-29 volume-count subparameter
of JOB USER parameter 20-53 of DD VOLUME parameter 12-213
of OUTPUT JCL DEST parameter 22-34 volume-sequence-number subparameter
USERLIB parameter of DD VOLUME parameter 12-213
of OUTPUT JCL statement 22-87 VS2 subparameter
of //*MAIN TYPE parameter 28-35
VSAM (virtual storage access method)
V record-level sharing 12-174
V subparameter referenced in VOLUME=REF subparameter 12-217
of AMP RECFM subparameter 12-27 with DD AMP parameter 12-23
of DD DSID parameter 12-98 with DD DATACLAS parameter 12-50
of DD RECFM parameter 12-166, 12-167, 12-168, with DD RECORG parameter 12-169
12-169 with DD RLS parameter 12-174
valueK subparameter
subparameter of EXEC REGION parameter 16-29
subparameter of JOB REGION parameter 20-41 W
valueM subparameter W subparameter
subparameter of EXEC REGION parameter 16-30 of //*MAIN BYTES parameter 28-25
subparameter of JOB REGION parameter 20-41 of //*MAIN CARDS parameter 28-25
VB subparameter of //*MAIN LINES parameter 28-30
of AMP RECFM subparameter 12-27 of //*MAIN PAGES parameter 28-31
verification of DCB FUNC subparameter 12-62
of FCB image 12-117 of DCB OPTCD subparameter 12-66, 12-68, 12-69
of forms overlay frame 12-122, 22-41 WARNING subparameter
VERIFY subparameter of //*MAIN BYTES parameter 28-25
of DD FCB parameter 12-117 of //*MAIN CARDS parameter 28-25
of DD UCS parameter 12-201 of //*MAIN LINES parameter 28-30
VIRT subparameter of //*MAIN PAGES parameter 28-31
of EXEC ADDRSPC parameter 16-8 of JOB BYTES parameter 20-12
of JOB ADDRSPC parameter 20-10 of JOB CARDS parameter 20-14
vmguestid parameter of JOB LINES parameter 20-22
of JES2 /*ROUTE statement 27-24 of JOB PAGES parameter 20-30

Index X-33
WLM scheduling environment 20-46 Y subparameter (continued)
work-station-name parameter of DD PROTECT parameter 12-163
of JES3 /*SIGNON statement 28-50 YES subparameter
writer of //*DATASET DDNAME parameter 28-5
external of //*FORMAT FORMS parameter 28-21
specifying on OUTPUT JCL statement 22-88 of //*MAIN EXPDTCHK parameter 28-28
specifying on sysout DD statement 12-193 of //*MAIN HOLD parameter 28-29
starting 12-197, 22-89 of //*MAIN JOURNAL parameter 28-30
with OUTPUT JCL WRITER parameter 22-89 of //*MAIN RINGCHK parameter 28-32
with SYSOUT writer-name parameter 12-197 of //*NET DEVRELSE parameter 28-40
WRITER parameter of //*NET OPHOLD parameter 28-41
of OUTPUT JCL statement 22-88 of DD BURST parameter 12-36
default 22-89 of DD HOLD parameter 12-126
description 22-88 of DD PROTECT parameter 12-163
example 22-89 of OUTPUT JCL BURST parameter 22-15
override 22-89 of OUTPUT JCL DEFAULT parameter 22-29
relationship to other parameter 22-89 of OUTPUT JCL DPAGELBL parameter 22-36
subparameter 22-89 of OUTPUT JCL PIMSG parameter 22-65
writer-name subparameter of OUTPUT JCL SYSAREA parameter 22-77
of DD SYSOUT parameter 12-195 of OUTPUT JCL TRC parameter 22-80
with DEST=(node) subparameter 12-83 YN character set
for 1403 and 3203 Model 5 printer 12-202, 22-82
yyddd subparameter
X of DD EXPDT parameter 12-115
x subparameter yyyy/ddd subparameter
of //*MAIN PROC parameter 28-32 of DD EXPDT parameter 12-115
of /*JOBPARM FORMS parameter 27-5
of /*JOBPARM ROOM parameter 27-7
of /*OUTPUT CHARS parameter 27-14 Z
of /*OUTPUT FCB parameter 27-17 Z subparameter
of /*OUTPUT FORMS parameter 27-18 of DCB OPTCD subparameter 12-68
of /*OUTPUT UCS parameter 27-20
of /*XMIT DLM parameter 27-31
of DCB EROPT subparameter 12-62
X subparameter
of DCB FUNC subparameter 12-62
of DCB PCI subparameter 12-69
of LRECL parameter 12-141
XEQ parameter
of JES2 /*ROUTE statement 27-23
XMIT statement
in JCL 26-1
comments field 26-2
description 26-1
error on statement 26-3
example 26-3
location in JCL 26-2
name field 26-2
operation field 26-2
parameter field 26-2
support 26-1
XN character set
for 1403 and 3203 Model 5 printer 12-202, 22-82

Y
Y subparameter
of /*JOBPARM BURST parameter 27-5
of /*JOBPARM RESTART parameter 27-6
of /*OUTPUT BURST parameter 27-14
of DCB OPTCD subparameter 12-69

X-34 z/OS V1R3.0 MVS JCL Reference

Readers’ Comments — We’d Like to Hear from You
z/OS
MVS JCL Reference

Publication No. SA22-7597-02

Overall, how satisfied are you with the information in this book?

Very Satisfied Satisfied Neutral Dissatisfied Very Dissatisfied

Overall satisfaction h h h h h

How satisfied are you that the information in this book is:

Very Satisfied Satisfied Neutral Dissatisfied Very Dissatisfied

Accurate h h h h h
Complete h h h h h
Easy to find h h h h h
Easy to understand h h h h h
Well organized h h h h h
Applicable to your tasks h h h h h

Please tell us how we can improve this book:

Thank you for your responses. May we contact you? h Yes h No

When you send comments to IBM, you grant IBM a nonexclusive right to use or distribute your comments in any
way it believes appropriate without incurring any obligation to you.

Name Address

Company or Organization

Phone No.
 ___________________________________________________________________________________________________
Readers’ Comments — We’d Like to Hear from You Cut or Fold
SA22-7597-02 IBMR Along Line

_ _ _ _ _ _ _Fold
_ _ _ and
_ _ _Tape
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _Please
_ _ _ _ _do
_ _not
_ _ staple
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _Fold
_ _ _and
_ _ Tape
______

NO POSTAGE
NECESSARY
IF MAILED IN THE
UNITED STATES

BUSINESS REPLY MAIL

FIRST-CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK

POSTAGE WILL BE PAID BY ADDRESSEE

IBM Corporation
Department 55JA, Mail Station P384
2455 South Road
Poughkeepsie, NY
12601-5400

_________________________________________________________________________________________
Fold and Tape Please do not staple Fold and Tape

Cut or Fold
SA22-7597-02 Along Line
IBMR

Program Number: 5694-A01

Printed in the United States of America

on recycled paper containing 10%
recovered post-consumer fiber.

SA22-7597-02