Introduction

(Next) (Previous) (Table-of-Contents)

JCL defines how a job is executed on the mainframe. A job may perform many steps or execute many programs in
order to produce the requested information or output. If a segment of JCL is used repeatedly it may be coded once as
a PROC (or JCL Procedure) and then used by many different steps within the job. There are two approaches to
defining and using PROC's.

The PROC may be defined within the job (this is referred to as an In-stream PROC). If the segment of JCL code
being defined as a PROC is unique to a single job then this approach is a very good alternative. An instream PROC
should be defined first in the JCL before the EXEC statement that will reference the PROC. An instream PROC must
start with a PROC statement and be terminated with a PEND statement. The PEND is not required if the PROC is
stored as a separate member in a library.

The PROC may be defined as a separate member and stored in a separate library (i.e. PDS). If the segment of JCL
code being defined as a PROC will be used by different jobs then this approach should be used.

At execution time when an EXEC statement references a PROC the PROC source code will be copied into the job
and executed as if it is part of the JCL.

If you store a PROC in a library (i.e. Proc Library or ProcLib) the ProcLib must be known to the system. Most systems
will search a list of pre-defined ProcLibs to find a PROC. If a PROC is stored in a library that is not in the pre-defined
then the PROC will not be found. To specify additional PROC libraries to be searched use the JCLLIB statement.
This is explained in a later section of this document.

For additional flexibility substitution parameters may be used to pass different values to a PROC. This is explained in
a later section of this document.

Creating Multiple Partitioned Data Sets (PDS's)

(Next) (Previous) (Table-of-Contents)

This example will demonstrate the use of JCL PROCs to create three Partitioned Data Sets (PDS's). The first
example will use an instream PROC and the second example will use a JCL member with a separate PROC
member. The use of a substitution parameter will also be explained.

The PROC will contain the source code to create (or delete) a PDS using the DSN specified in the substitution
parameter ($DSNAME) provided by the JCL member. The JCL member will contain the code to set a substitution
parameter with a Data Set Name (or PDS name for this example).

A JCL Member with an Instream PROC

(Next) (Previous) (Table-of-Contents)

The following is the source code for a JCL member with an instream PROC. Notice the instream PROC is defined
before the first step.

//PDSCRTJ4 JOB SIMOTIME,ACCOUNT,CLASS=1,MSGCLASS=0,NOTIFY=CSIP1

//* *******************************************************************
//* This program is provided by: *
//* SimoTime Enterprises, LLC *
//* (C) Copyright 1987-2010 All Rights Reserved *
//* *
//* Web Site URL: http://www.simotime.com *
//* e-mail: [email protected] *
//* *******************************************************************
//*
//* Subject: Define a PDS using the IEFBR14 with a DD Statement
//* Author: SimoTime Enterprises
//* Date: January 1,1998
//*
//* The JCL member executes the instream PROC called PDSCRTP3 and
//* passes a fully qualified data set name (DSN) via the symbolic name
//* called DSNAME and referenced in the PROC as &DSNAME.;//*
//*********************************************************************
//* The instream PROC for creating a PDS. The Data Set Name (&DSNAME)
//* is provided by the job step that EXECs the PROC.
//*
//PDSCRTP3 PROC
//PDSCRTS1 EXEC PGM=IEFBR14
//TEMPLIB1 DD DISP=(NEW,CATLG),DSN=&DSNAME,
// STORCLAS=MFI,
// SPACE=(TRK,(45,15,50)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=800,DSORG=PO)
// PEND
//*
//* *******************************************************************
//* Step 1 of 3 Create a PDS using SET and EXEC
//*
// SET DSNAME=SIMOTIME.DEMO.TEMP01
//STEPJ41 EXEC PDSCRTP3
//*
//* *******************************************************************
//* Step 2 of 3 Create a PDS using EXEC and DSNAME substitution
//*
//STEPJ42 EXEC PDSCRTP3,DSNAME=SIMOTIME.DEMO.TEMP02
//*
//* *******************************************************************
//* Step 3 of 3 Create a PDS using EXEC and DSNAME substitution
//*
//STEPJ43 EXEC PDSCRTP3,DSNAME=SIMOTIME.DEMO.TEMP03
//*

In the preceding example the PROC starts with the PROC statement and ends with the PEND statement.

//PDSCRTP3 PROC
...
...
// PEND

As stated earlier the PEND statement is required for an instream PROC but is optional for a separately defined
PROC. Step 1 uses a SET statement to set a value for the DSNAME substitution parameter. Steps 2 and 3 define the
DSNAME substitution parameter as part of the EXEC statement. The PROC accesses the substitution parameter by
using the ampersand as a prefix or &DSNAME. In this example by using the &DSNAME substitution parameter the
PROC may be used to create multiple PDS's with different names.

The JCL Member to Create Three PDS's

(Next) (Previous) (Table-of-Contents)

This example uses a single JCL member (PDSCRTJ3.JCL) and a separate PROC member (PDSCRTP3.JCL) to
create three PDS's . Notice the use of the JCLLIB statement to tell the system where to find the PROC.

//PDSCRTJ3 JOB SIMOTIME,ACCOUNT,CLASS=1,MSGCLASS=0,NOTIFY=CSIP1

//* *******************************************************************
//* This program is provided by: *
//* SimoTime Enterprises, LLC *
//* (C) Copyright 1987-2010 All Rights Reserved *
//* *
//* Web Site URL: http://www.simotime.com *
//* e-mail: [email protected] *
//* *******************************************************************
//*
//* Subject: Define a PDS using the IEFBR14 with a DD Statement
//* Author: SimoTime Enterprises
//* Date: January 1,1998
//*
//* The JCLLIB tells the mainframe where to look for PROCs.
//*
//* The JCL member executes the PROC called PDSCRTP3 and passes a
//* fully qualified data set name (DSN) via the symbolic name
//* called DSNAME and referenced in the PROC as &DSNAME.
//*
//*********************************************************************
//*
//PROCLIB JCLLIB ORDER=SIMOTIME.PDS.PROCLIB1
//*
//* *******************************************************************
//* Step 1 of 3 Create a PDS using SET and EXEC
//*
// SET DSNAME=SIMOTIME.DEMO.TEMP01
//STEPJ01 EXEC PDSCRTP3
//*
//* *******************************************************************
//* Step 2 of 3 Create a PDS using EXEC and DSNAME substitution
//*
//STEPJ02 EXEC PDSCRTP3,DSNAME=SIMOTIME.DEMO.TEMP02
//*
//* *******************************************************************
//* Step 3 of 3 Create a PDS using EXEC and DSNAME substitution
//*
//STEPJ03 EXEC PDSCRTP3,DSNAME=SIMOTIME.DEMO.TEMP03
//*

The PROC to Create a PDS

(Next) (Previous) (Table-of-Contents)

The following is the PROC that will be used to create a PDS. Notice the PROC and PEND statements are not
required.

//* *******************************************************************
//* This program is provided by: *
//* SimoTime Enterprises, LLC *
//* (C) Copyright 1987-2010 All Rights Reserved *
//* *
//* Web Site URL: http://www.simotime.com *
//* e-mail: [email protected] *
//* *******************************************************************
//*
//* Subject: Define a PDS using the IEFBR14 with a DD Statement
//* Author: SimoTime Enterprises
//* Date: January 1,1998
//*
//* This PROC needs the &DSNAME defined by the calling JCL member...
//* // SET DSNAME=AAAA.BBBB.CCCC
//* // EXEC PDSCRTP3
//*
//* Also, the JCLLIB statement may be required and placed after
//* the JOB card.
//* //PROCLIB JCLLIB ORDER=SIMOTIME.DEMO.PROCLIB1
//*
//* Technically speaking, IEFBR14 is not a utility program because it
//* does nothing. The name is derived from the fact that it contains
//* two assembler language instruction. The first instruction clears
//* register 15 (which sets the return code to zero) and the second
//* instruction is a BR 14 which performs an immediate return to the
//* operating system.
//*
//* IEFBR14's only purpose is to help meet the requirements that a
//* job must have at least one EXEC statement. The real purpose is to
//* allow the disposition of the DD statement to occur.
//*
//* For example, the following DISP=(NEW,CATLG) will cause the
//* specified DSN (i.e. PDS) to be allocated.
//* Note: a PDS may also be referred to as a library.
//*********************************************************************
//PDSCRTS1 EXEC PGM=IEFBR14
//TEMPLIB1 DD DISP=(NEW,CATLG),DSN=&DSNAME,
// STORCLAS=MFI,
// SPACE=(TRK,(45,15,50)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=800,DSORG=PO)
//*

Deleting Multiple Partitioned Data Sets (PDS's)

(Next) (Previous) (Table-of-Contents)

This section provides an example of how to use a PROC to delete a PDS. Please note, if the PDS is deleted all the
members in the PDS are also deleted.

The JCL Member to Delete Three PDS's

(Next) (Previous) (Table-of-Contents)

The following is the JCL member that will use a PROC to delete the PDS's created in the Create Multiple PDS's
example.

//PDSDELJ3 JOB SIMOTIME,ACCOUNT,CLASS=1,MSGCLASS=0,NOTIFY=CSIP1

//* *******************************************************************
//* This program is provided by: *
//* SimoTime Enterprises, LLC *
//* (C) Copyright 1987-2010 All Rights Reserved *
//* *
//* Web Site URL: http://www.simotime.com *
//* e-mail: [email protected] *
//* *******************************************************************
//*
//* Subject: Delete Temporary PDS's with IEFBR14 and a DD Statement
//* Author: SimoTime Enterprises
//* Date: January 1,1998
//*
//* The JCLLIB tells the mainframe where to look for PROCs.
//*
//* The JCL member executes the PROC called PDSDELP3 and passes a
//* fully qualified data set name (DSN) via the symbolic name
//* called DSNAME and referenced in the PROC as &DSNAME.;//*
//*********************************************************************
//*
//PROCLIB JCLLIB ORDER=SIMOTIME.DEMO.PROCLIB1
//*
//* *******************************************************************
//* Step 1 of 3 Delete a PDS using SET and EXEC
//*
// SET DSNAME=SIMOTIME.DEMO.TEMP01
//STEPJ01 EXEC PDSDELP3
//*
//* *******************************************************************
//* Step 2 of 3 Delete a PDS using EXEC and DSNAME substitution
//*
//STEPJ02 EXEC PDSDELP3,DSNAME=SIMOTIME.DEMO.TEMP02
//*
//* *******************************************************************
//* Step 3 of 3 Delete a PDS using EXEC and DSNAME substitution
//*
//STEPJ03 EXEC PDSDELP3,DSNAME=SIMOTIME.DEMO.TEMP03
//*

The PROC to Delete a PDS

(Next) (Previous) (Table-of-Contents)

The following is the PROC that will delete a PDS based on the value of the substitution parameter (&DSNAME)
provided by the JCL member.

//* *******************************************************************
//* This program is provided by: *
//* SimoTime Enterprises, LLC *
//* (C) Copyright 1987-2010 All Rights Reserved *
//* *
//* Web Site URL: http://www.simotime.com *
//* e-mail: [email protected] *
//* *******************************************************************
//*
//* Subject: Delete Temporary PDS's with IEFBR14 and a DD Statement
//* Author: SimoTime Enterprises
//* Date: January 1,1998
//*
//* This PROC needs the &DSNAME defined by the calling JCL member...
//* // SET DSNAME=AAAA.BBBB.CCCC
//* // EXEC PDSDELP3
//*
//* Also, the JCLLIB statement may be required and placed after
//* the JOB card.
//* //PROCLIB JCLLIB ORDER=SIMOTIME.DEMO.PROCLIB1
//*
//* Technically speaking, IEFBR14 is not a utility program because it
//* does nothing. The name is derived from the fact that it contains
//* two assembler language instruction. The first instruction clears
//* register 15 (which sets the return code to zero) and the second
//* instruction is a BR 14 which performs an immediate return to the
//* operating system.
//*
//* IEFBR14's only purpose is to help meet the requirements that a
//* job must have at least one EXEC statement. The real purpose is to
//* allow the disposition of the DD statement to occur.
//*
//* For example, the following DISP=(OLD,DELETE) will cause the
//* specified DSN (i.e. PDS) to be deleted.
//* Note: a PDS is also referred to as a library.
//*********************************************************************
//PDSDELS1 EXEC PGM=IEFBR14
//TEMPLIB1 DD DISP=(OLD,DELETE),DSN=&DSNAME,
// STORCLAS=MFI,
// SPACE=(TRK,(45,15,50)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=800,DSORG=PO)
//*

Summary
(Next) (Previous) (Table-of-Contents)

The purpose of this document is to assist as a tutorial for new programmers or as a quick reference for experienced
programmers. In the world of programming there are many ways to solve a problem. This suite of JCL members and
PROC's is provided as a possible approach to creating and deleting multiple, temporary PDS's.

TABLE OF CONTENTS

 Preface
 General Syntax
o Continuation
o Line Numbering
o Statement Identification
o Field Justification
o Unauthorized Statements
o Authorized Statements
 The JOB Statement
o The Job Name
o The Positional Parameters
 The Pano Parameter
 The Room Parameter
 The Lines Parameter
 The Cards Parameter
 The Form Parameter
 The Copies Parameter
o The Programmer's Name Parameter
o The Keyword Parameters
 The CLASS Parameter
 The COND Parameter
 The MSGCLASS Parameter
 The PRTY Parameter
 The TIME Parameter
 The TYPRUN Parameter
 The USER Parameter
 The PASS Parameter
 The JOBPARM StatementM
 The UQ Statement
 The ROUTE PRINT STATEMENT
 The MESSAGE Statement
 The SETUP Statement
 The COMMENT Statement
 The OUTPUT Statement
 o The Output Name
o The Keyword Parameters
o The CLASS Parameter
o The COPIES Parameter
o The DEFAULT Parameter
o The DEST parameter
o The FCB Parameter
o The FORMS Parameter
o The JESDS Parameter
 The System Output DD Statement
o The SYSOUT Parameter
 The Class Subparameter
 The Program Subparameter
 The Forms Subparameter
o The COPIES Parameter
o The DEST Parameter
o The FCB Parameter
o The FREE Parameter
o The HOLD Parameter
o The OUTLIM Parameter
o The OUTPUT Parameter
 Alternatives for System Output
o The Primary Method
o The Alternate Method
 The EXEC Statement
o The Step Name
o The PROC and PGM Parameters
o The Keyword Parameters
 The COND parameter
 The PARM parameter
 The REGION parameter
 The TIME parameter
 Other Parameters
 The DD Statement
o Overriding Procedures
o The Keyword Parameters
o The DSN Parameter
 Temporary Data Sets
 Permanent Data Sets
o The DISP Parameter
 The Status Subparameter
 The Normal Termination Disposition Subparameter
 The Abnormal Termination Disposition Subparameter
o The UNIT Parameter
o The VOL Parameter
o The LABEL Parameter
o The SPACE Parameter
 o The DCB Parameters
 System Input and Output data sets
 The DSORG Subparameter
 The RECFM Subparameter
 The LRECL Subparameter
 The BLKSIZE Subparameter
 The DEN Subparameter
 The Other Subparameters
o The FREE Parameter
 JCL Examples
o Temporary Disk Data Sets
o Sorting Data Sets
o Catalogued Data Sets
o Generation Data Sets

 Appendix A. Crib Card

 Appendix B. Estimating Disk Space

LIST OF ILLUSTRATIONS

 Figure 1. Job Name

 Figure 2. System Style Job Name
 Figure 3. User Style Job Name
 Figure 4. Converted MVT Style Job Name
 Figure 5. Pano parameter
 Figure 6. Room parameter
 Figure 7. Lines parameter
 Figure 8. Cards parameter
 Figure 9. Form parameter
 Figure 10. Copies parameter
 Figure 11. JOB statement positional parameters
 Figure 12. CLASS parameter
 Figure 13. COND parameter
 Figure 14. MSGCLASS parameter
 Figure 15. PRTY parameter
 Figure 16. TIME parameter
 Figure 17. TYPRUN parameter
 Figure 18. USER parameter
 Figure 19. PASS parameter
 Figure 20. JOBPARM statement
 Figure 21. UQ statement
 Figure 22. ROUTE PRINT statement
 Figure 23. MESSAGE statement
 Figure 24. SETUP statement
 Figure 25. COMMENT statements
 Figure 26. Output Name
 Figure 27. CLASS Parameter
 Figure 28. COPIES parameter
 Figure 29. DEFAULT parameter
 Figure 30. DEST parameter
 Figure 31. FCB parameter
 Figure 32. FORMS parameter
 Figure 33. JESDS parameter
 Figure 34. Class Subparameter
 Figure 35. Forms subparameter
 Figure 36. COPIES parameter
 Figure 37. DEST parameter
 Figure 38. FCB parameter
 Figure 39. FREE parameter
 Figure 40. HOLD parameter
 Figure 41. OUTLIM parameter
 Figure 42. OUTPUT parameter
 Figure 43. // OUTPUT statement
 Figure 44. Primary Method
 Figure 45. Alternate Method
 Figure 46. Alternate Method For Separating System Output
 Figure 47. Step Name
 Figure 48. PROC and PGM parameters
 Figure 49. MBR and LIB parameters
 Figure 50. COND parameter
 Figure 51. PARM parameter
 Figure 52. TIME parameter
 Figure 53. EXEC statement
 Figure 54. Overriding DD statement
 Figure 55. Temporary DSN parameter created by system
 Figure 56. Temporary DSN parameter using ampersand notation
 Figure 57. Temporary DSN parameter referback notation
 Figure 58. Permanent DSN parameter
 Figure 59. DISP parameter
 Figure 60. UNIT parameter
 Figure 61. Use the catalogue
 Figure 62. Minimize SER usage
 Figure 63. VOL parameter
 Figure 64. LABEL parameter showing file numbers and label type
 Figure 65. SPACE parameter
 Figure 66. System Input and Output Data Sets
 Figure 67. Opens to Avoid DCBs for System Input and Output
 Figure 68. DSORG subparameter
 Figure 69. RECFM subparameter
 Figure 70. LRECL subparameter
 Figure 71. BLKSIZE subparameter
  Figure 72. DEN subparameter
 Figure 73. DCB parameter
 Figure 74. FREE parameter
 Figure 75. Very temporary disk data sets
 Figure 76. Passed temporary disk data sets
 Figure 77. Sorting data sets
 Figure 78. Catalogued data sets
 Figure 79. Generation data sets
 Figure 80. Disk and Tape generation data sets
 Figure 81. Crib card
 Figure 82. Track capacities

PREFACE

This standard is defined within the requirements of OS MVS. Some considerations are that the jobs
which result from this standard:

1. execute in UCSB's OS MVS and JES2 environment,

2. do not unnecessarily adversely impact the Computer Center operations staff,
3. are easily read, interpreted and used by our staff and administrative users.

The use of JCL control statements is encouraged and the use of JES control statements is discouraged.
This is to reduce our dependence on either JES2 or JES3 and to reduce the effort required to migrate
from one JES to another.

These guidelines will apply to all jobs created, modified, imported, or assumed by the Information Systems Office.

The objectives of the Job Control Language Standard are correctness, maintainability, clarity, and simplicity.

Note: We have attempted to write a useful JCL standard, but it can be improved. Please submit suggestions, to Barry
J. Cunningham.

GENERAL SYNTAX

IBM OS MVS job control language (JCL) control statements and IBM OS utility control statements allow
free format coding within columns one through seventy one, optional or required continuation
notations in column seventy two, and optional line numbering in columns seventy three through eighty.

Continuation
The continuation notations in column 72 shall NOT be used except in those specific instances where
utility control statements require it. Continuation will be implied by a comma following an operand.

Line Numbering

Jobs will not be stored with line numbers. Line numbering may cause problems if data lines are
numbered.

Statement Identification

The JCL control statements start with a "//" in columns one and two, with the exception of the delimiter
control statements which start with a "/*" in columns one and two and will only be used for JES2 control
statements. Comment statements are further identified by a "//*" in columns one through three.
The //*UQ comment statement is also identified as a Com-Plete control statement.

Field Justification

The remainder of the control statements consist of four fields: Name, Operation, Operand, and
Comment. Name, the first field, is left justified in column three in JCL and JES2. It is typically absent in
utility control statements, but if present may be left justified in column two. Operation, the second field,
is right justified in column fourteen. Very few exceptions to this alignment are allowed; however, a DD
statement may require a stepname and a DD name with a combined length which will not allow right
justification in column fourteen. Operand, the third field, is left justified in column sixteen of each line of
the statement. Comment, the fourth field, must be separated from the preceding field by at least one
space. Additional spaces preceding the comment may improve readability.

Unauthorized Statements

JES3 and HASP statements are unnecessary and may not be used.

Most JES2 statements may not be used because MVS control statements may be used instead. MVS control
statements are preferred over JES2 control statements.

The following statements may not be used:

 // command
 // CNTL
 // ENDCNTL
 //JOBLIB DD
 //JOBCAT DD
 //STEPCAT DD
 /*$command
 /*NOTIFY
 /*OUTPUT
 /*PRIORITY
  /*SIGNOFF
 /*SIGNON
 /*XEQ
 /* delimiter - The "/*" delimiter control statements will only be used for JES2 control
statements. Delimiter control statements will not follow data lines in the input stream.

The following statement has two special uses:

 /*JOBPARM - replaces the /*MAIN FAILURE=RESTART card. The format is /*JOBPARM

RESTART=Y
 /*JOBPARM is also used with the TSO TRANSMIT command when more than 9,999 card images
will be transmitted. The format is /*JOBPARM CARDS=9999999

Authorized Statements

The following statements may be used at the beginning of the job:

 // JOB
 //*UQ
 /*ROUTE
 /*MESSAGE
 /*SETUP
 //* ** comment
 // OUTPUT

The following statements may be used for each in-stream PROC:

 // PROC
 //* comment
 // EXEC
 // DD
 // PEND

The in-stream PROCs will follow the statements at the beginning of the job and will precede any
statements for an ordinary job step, that is, a job step that is not part of an in-stream PROC.

The following statements may be used for each ordinary job step:

 //* comment
 // EXEC
 // DD
THE JOB STATEMENT

The JOB statement is used to pass accounting information and control parameters to the MVS operating
system and JES2 spooling system.

The Job Name

The job statement is identified by a "//" in columns one and two, followed by a job name, and the word
JOB. The job name will be left justified in column three. The word JOB will be in columns twelve through
fourteen.

+------------------------------------------------+
[ 0 1 1 ]
[ 1234567890123456 ]
[ ]
[ //SRPRJ012 JOB ( ]
[ //CRGEJ004 JOB ( ]
[ //ANSMI47 JOB ( ]
[ //HEJON08 JOB ( ]
[ //ISS02050 JOB ( ]
[ //ISS01588 JOB ( ]
[ ]
[ Figure 1. Job Name ]
+------------------------------------------------+
There will be three styles of job names. The first style is based on the system and subsystem with which
the job is associated. The system style job name is in a "ssuuJnnn" format where the "ss" is the system
abbreviation, the "uu" is the subsyste m abbreviation, and the "nnn" is a three digit number assigned by
the project leader responsible for the system. For example, job twelve of system "SR" and subsystem
"PR" would be assigned a system style name of "SRPRJ012".

+--------------------------------------------------+
[ 0 1 1 ]
[ 1234567890123456 ]
[ ]
[ //SRPRJ012 JOB ( ]
[ //CRGEJ004 JOB ( ]
[ ]
[ Figure 2. System Style Job Name ]
+--------------------------------------------------+
The second style is based on the user who submits the job. The user style job name is in a "uuuuuunn"
format where the "uuuuuu" is the user identification, and the "nn" is a two digit number taken from the
seconds portion of the operating system timer. For example, a job for user "ANSMI", "Alicia N. Smith",
where the system timer was sampled during the forty seventh second of the minute would have a user
style name of "ANSMI47".
+----------------------------------------------+
[ 0 1 1 ]
[ 1234567890123456 ]
[ ]
[ //ANSMI47 JOB ( ]
[ //HEJON08 JOB ( ]
[ ]
[ Figure 3. User Style Job Name ]
+----------------------------------------------+
The system style job name will be used as the job name of the JOB statement of most jobs associated
with an application system, but the user style job name may be used in those jobs associated an
application system where many copies of the same job, submitted by different users, might be in the
operating and spooling system at one time. The system style name should appear in the comments at
the beginning of a job when the user style name is used as a job name of the JOB statement.

+------------------------------------------------------+
[ 0 1 1 ]
[ 1234567890123456 ]
[ ]
[ //ISS02550 JOB ( ]
[ //ISS01588 JOB ( ]
[ ]
[ Figure 4. Converted MVT Style Job Name ]
+------------------------------------------------------+
The third style reflects the MVT ISO convention of ISSnnnnn. Most jobs which were moved from MVT
will retain this style.

The Positional Parameters

The next parameters in the JOB statement are the positional JES2 accounting information parameters
starting in column sixteen. These parameters are enclosed by parentheses and separated by commas
(without imbedded blanks). The commas identify the param eter's relative positions and must be
present up to the last positional parameter stated.

The following positional parameters may not be used:

 Time
 Log
 Linect

The following positional parameters may be used:

 Pano
 Room
 Lines
 Cards
The following positional parameters may be contained in JCL converted from MVT, but their use is
discouraged.

 Form
 Copies

The Pano Parameter

The first positional parameter is Pano, or programmer's accounting number. The Pano parameter is
required and consists of the catenation of the four character Computer Center "account number" and
the one to eight character Computer Center "account name". It provides the information for billing the
resources used by the job.

+-----------------------------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ //SRPRJ012 JOB (IS00RWK ]
[ //CRGEJ004 JOB (RP00STAT ]
[ //ANSMI47 JOB (AN05PAYM ]
[ //HEJON08 JOB (NP00LAB ]
[ ]
[ Figure 5. Pano parameter ]
+-----------------------------------------------------------------+

The Room Parameter

The second positional parameter is Room. The Room parameter is required and may be one to four
characters. It prints on the JES2 separator sheets and indicates the bin or locker for distribution of
printed output. Room will usually be specified as a one or two digit locker number, followed by the
initials of the first and last name, for administrative users.

+---------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ //SRPRJ012 JOB (IS00RWK,18BK ]
[ //CRGEJ004 JOB (RP00STAT,48EM ]
[ //ANSMI47 JOB (AN05PAYM,3AS ]
[ //HEJON08 JOB (NP00LAB,64HJ ]
[ ]
[ Figure 6. Room parameter ]
+---------------------------------------------+

The Lines Parameter

The fourth positional parameter is Lines and specifies the printed line kill in thousands of lines. This
parameter is optional and defaults to ONE thousand lines.

+---------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ //SRPRJ012 JOB (IS00RWK,18BK) ]
[ //CRGEJ004 JOB (RP00STAT,48EM,,50) ]
[ //ANSMI47 JOB (AN05PAYM,3AS,,5) ]
[ //HEJON08 JOB (NP00LAB,64HJ,,120) ]
[ ]
[ Figure 7. Lines parameter ]
+---------------------------------------------+

The Cards Parameter

The fifth positional parameter is Cards and specifies the punched card kill in individual cards. This
parameter is optional and defaults to 1000 for 1,000 cards. This parameter consists of one through four
decimal digits, representing 0 through 9,999 car ds.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //SRPRJ012 JOB (IS00RWK,18BK) ]
[ //CRGEJ004 JOB (RP00STAT,48EM,,50,3500) ]
[ //ANSMI47 JOB (AN05PAYM,3AS,,5) ]
[ //HEJON08 JOB (NP00LAB,64HJ,,120,9999) ]
[ ]
[ Figure 8. Cards parameter ]
+----------------------------------------------------------------------------+
The Cards parameter is infrequently used because the MVS and JES2 environment does not have a card
punch.

Occasionally information is transmitted from the MVS and JES2 environment to another node (using the system
output punched card format of eighty characters per record). An example of this is the use of the TSO TRANSMIT
command in a batch job to transmit punched card records to another node. It is recommended that you use the
CARDS keyword parameter of the /*JOBPARM statement (which will allow for up to 9,999,999 punched cards).

The Form Parameter

The sixth positional parameter is Forms and specifies the printerform to be used for all output (JCL,
messages, output, etc.). Note: usage of the form parameter is discouraged in the job card.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //CRGEJ004 JOB (RP00STAT,48EM,,50,3500,3410) ]
[ ]
[ Figure 9. Form parameter ]
+----------------------------------------------------------------------------+

The Copies Parameter

The seventh positional parameter is Copies and specifies the number of copies of all printer output (JCL,
messages, output, etc.). Note: usage of the copies parameter in the job card is discouraged.

+-----------------------------------------------------------------------------
+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6
7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012
]
[
]
[ //CRGEJ004 JOB
(RP00STAT,48EM,,50,3500,3410,2) ]
[
]
[ Figure 10. Copies
parameter ]
+-----------------------------------------------------------------------------
+

The Programmer's Name Parameter

The Programmer's name parameter follows the right parenthesis of the positional parameters. The
Programmer's Name parameter is used to specify the user's name for the distribution of printed output.
It is preceded by a comma, is enclosed within apostrophes, and may be up to twenty characters long.
Within the apostrophes, the last name is first, followed by a comma, and the remainder of the name.

To represent Harry E. Jones, we would key the following:

),'JONES,HARRY E.'

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
{ ]
[ //SRPRJ012 JOB (IS00RWK,18BK),'KUNTZ,ROBERT W.' ]
[ //CRGEJ004 JOB (RP00STAT,48EM,,50),'MARTINEZ,ESTABAN E.' ]
[ //ANSMI47 JOB (AN05PAYM,3AS,,5),'SMITH,ALICIA N.' ]
[ //HEJON08 JOB (NP00LAB,64HJ,,120),'JONES,HARRY E.' ]
[ ]
[ Figure 11. JOB statement positional parameters ]
+----------------------------------------------------------------------------+

The Keyword Parameters

The keyword parameters follow the Programmer's Name parameter. Each keyword parameter is
preceded by a comma.
The following keyword parameters may not be used:

 ADDSPC
 MSGLEVEL
 NOTIFY
 PERFORM
 RD
 REGION
 RESTART

The following keyword parameters may be used:

 CLASS
 COND
 GROUP
 MSGCLASS
 PRTY
 TIME
 TYPRUN

...... with some qualifications.

The CLASS Parameter

The CLASS keyword parameter is used to control the execution of jobs using specific resources. It is
determined by whether the job uses Adabas, cartridge tape drives, and/or reel tape drives. CLASS will
always be explicitly stated.

CLASS Adabas Cartridge Reel

-------- ---------------------------
N No 0 0
T No 0 1
C No 1 0
B No 1 1
F No 2 0
P No 2 1
J No 3 0
Q No 0 2
R No 0 3
A Read 0 0
D Read 1 0
G Read 2 0
K Read 3 0
U Update 0 0
W Update 0 1
X Update 0 2
Y Update 0 3
E Update 1 0
H Update 2 0
 L Update 3 0
S All other cases

"No" indicates the job does not use Adabas.

"Read" indicates the job only reads Adabas files.

"Update" indicates the job may read OR update Adabas files AND uses the
number of cartridge or reel tapes drives available to the CLASS
keyword parameter.
Note: When using class "S", please use a SETUP card to tell the operator how many tape drives of each
type will be needed.

+--------------------------------------------+
[ CLASS=A ]
[ CLASS=N ]
[ CLASS=U ]
[ ]
[ Figure 12. CLASS parameter ]
+--------------------------------------------+

The COND Parameter

The next keyword parameter is COND=(0,NE) and is used for multiple step jobs that do not have
condition parameters on each EXEC statement. It is preferable to use this keyword parameter on the
JOB statement for production jobs, instead of the COND param eter on EXEC statements, if successful
execution can be determined by a zero condition for all job steps.

+---------------------------------------+
[ COND=(0,NE) ]
[ ]
[ Figure 13. COND parameter ]
+---------------------------------------+

The MSGCLASS Parameter

The MSGCLASS keyword parameter specifies the output class for the job log. The CLASS=* parameter of
the // OUTPUT statement and the Class * subparameter of the SYSOUT parameter of the DD statement
refer to and use the output class specified in the MSGCLA SS parameter.

The MSGCLASS keyword parameter can be useful for holding system output after execution or for discarding system
output. The MSGCLASS will always be explicitly coded, and will usually be MSGCLASS=A.

A normal, do not hold job.

S place system output in hold for release by user. Discarded after 1
day.
X place system output in hold for release by user. Discarded after 7
days.
Z throw system output away after execution.
NOTE: MSGCLASS=X causes VM/XA to hold the output when routed to UCSBVM.

+---------------------------------------------+
[ MSGCLASS=A ]
[ MSGCLASS=S ]
[ MSGCLASS=X ]
[ MSGCLASS=Z ]
[ ]
[ Figure 14. MSGCLASS parameter ]
+---------------------------------------------+

The PRTY Parameter

JES2 selects jobs for execution by priority (PRTY) within a job CLASS. A job with a higher priority (a larger
number) is selected for execution sooner. PRTY will always be explicitly stated. Always state the highest
number in the selected range (15, 11, 7, or 3) as discussed below:

12 to 15 high priority, pays a surcharge.

8 to 11 regular priority, default, normal charge, weekday daytime.
4 to 7 low priority, receives a discount, after 6:00 PM and weekends.
0 to 3 deferred priority, receives a bigger discount, runs when they
get to it, no guarantee of overnight processing.

+-------------------------------------------+
[ PRTY=15 ]
[ PRTY=11 ]
[ PRTY=7 ]
[ PRTY=3 ]
[ ]
[ Figure 15. PRTY parameter ]
=-------------------------------------------+

The TIME Parameter

The TIME=x or TIME=(x,y) keyword parameter is used to provide a CPU kill time to the operating system.
The purpose of this parameter is to limit the time the job may run, in case an error is made that causes
the job to perform extra processing needlessly. You should use this TIME keyword parameter of the JOB
statement instead of the third positional parameter, Time, of the JOB statement. The "x" is the number
of minutes of CPU time and the "y" is the number of seconds of CPU time. The number of seconds of
CPU time may range from zero to fifty nine. The system only checks about every 10.5 seconds to see if
the CPU time used has exceeded the TIME keyword parameter. This would indicate that it doesn't pay to
be very precise in the specification of the number of seconds of CPU time, and it may be practical to
specify only the number of minutes of CPU time in many cases.

The default is for no time maximum, so jobs will never die on time unless a time parameter is supplied.

+--------------------------------------+
[ TIME=5 ]
[ TIME=(2,30) ]
[ TIME=(0,15) ]
[ TIME=(,3) ]
[ ]
[ Figure 16. TIME parameter ]
+--------------------------------------+
The TYPRUN Parameter

The TYPRUN keyword parameter may be used to request special processing. This could be useful when
testing a job, when scheduling a series of jobs, or when you wish to view the system output before it is
printed.

COPY copy to system output

HOLD hold job before execution
JCLHOLD hold before JCL processing
SCAN scan for syntax errors

+----------------------------------------------------------+
[ TYPRUN=COPY ]
[ TYPRUN=HOLD ]
[ TYPRUN=JCLHOLD ]
[ TYPRUN=SCAN ]
[ ]
[ Figure 17. TYPRUN parameter ]
+----------------------------------------------------------+
See "The MSGCLASS Parameter" for another way of requesting special processing.

The USER Parameter

The USER and PASS parameters are needed because we use RACF protection. They are supplied by the
system for any jobs submitted under Com-Plete (UEDIT and Natural). However, they may have to be
supplied by the user when submitting from Wylbur by using 'run racuser=fmlll racpass=pppp'. They can
also be supplied as options to the MVSFILE command in VM with USE and PAS. If you use the MVSRUN
command in VM, the USER and PASS parameters need to be stored in the JOB card in the appropriate
MVS library.

+--------------------------------------------+
[ USER=userid ]
[ ]
[ Figure 18. USER parameter ]
+--------------------------------------------+

The PASS Parameter

The USER and PASS parameters are needed because we use RACF protection. They are supplied by the
system for any jobs submitted under Com-Plete (UEDIT and Natural). However, they may have to be
supplied by the user when submitting from Wylbur by using 'run racuser=fmlll racpass=pppp'. They can
also be supplied as options to the MVSFILE command in VM with USE and PAS. If you use the MVSRUN
command in VM, the USER and PASS parameters need to be stored in the JOB card in the appropriate
MVS library.

+-----------------------------------------+
[ PASS=password ]
[ ]
[ Figure 19. PASS parameter ]
+-----------------------------------------+

THE JOBPARM STATEMENT

The JOBPARM statement is needed when using the TRANSMIT command in batch to transmit data to
another system. The sata is sent as 'cards' and the system default to terminate a job punching cards is
1000. When sending a lot of data, this parameter needs to be set higher.

+-----------------------------------------------+
[ /*JOBPARM CARDS=100000 ]
[ ]
[ Figure 20. JOBPARM statement ]
+-----------------------------------------------+

THE UQ STATEMENT

The UQ statement is used to inform Com-Plete of the restrictions placed on the use of certain keyword
arguments for the Com-Plete UQ utility.

It is identified by "//*UQ" in columns one through five. The operation starts in column sixteen. The operation may
consist of one of the following:

 the phrase "USERID", a space, and a list of Com-Plete user identifications separated by commas.
This restricts UQ operations to these specific users.
 the phrase "ACCOUNT", a space and a list of accounts separated by commas. Accounts consist of
the four character "account number" and up to eight character "account name", keyed without
intervening spaces. This restricts operations to these accounts.
 the phrase "ALLOW", which does not impose any restrictions, should be used advisedly.
 the phrase "DISALLOW" may not be used.

+-----------------------------------------------------------------------------
+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6
7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012
]
[
]
[ //*UQ USERID
CHET03 ]
[ //*UQ USERID
CHET03,ANG01 ]
[ //*UQ ACCOUNT
AB02SMITH ]
[ //*UQ ACCOUNT
BX99WAGNRE,IM00JONES ]
[ //*UQ
ALLOW ]
[
]
[ Figure 21. UQ
statement ]
+-----------------------------------------------------------------------------
+

THE ROUTE PRINT STATEMENT

NOTE: The use of the OUTPUT statement rather than the ROUTE PRINT statement is encouraged, as the
OUTPUT statement has greater flexibility.

The ROUTE PRINT statement is used to specify the destination of SYSOUT datasets that are not routed by a DEST
parameter on an OUTPUT card. The destination may be a JES printer, RSCS printer, or another user specified by
node and userid.

This statement is identified by "/*ROUTE PRINT" in columns 1 thru 14 and the printdestination starting in column 16.
The format for destinations is either UCSBMVS.Rnnn for JES printers or node.userid, or node.printername. Columns
beyond 70 should not be used. There can only be one destination on a ROUTE PRINT statement.

The ROUTE statement is used in some systems because the job deck containing it was brought over by the MVT-to-
MVS conversion team. To simplify the conversion effort and user training, this statement was retained. The OUTPUT
statement is, however, the preferred method for routing system output.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ /*ROUTE PRINT UCSBMVS.R1 ]
[ /*ROUTE PRINT UCSBMVS.R0 ]
[ /*ROUTE PRINT UCSBVM.IS00KS ]
[ ]
[ Figure 22. ROUTE PRINT statement ]
+----------------------------------------------------------------------------+

THE MESSAGE STATEMENT

The MESSAGE statement is used to inform the operator of the job's special requirements. It is identified
by "/*MESSAGE" in columns one through nine. The operation is left justified in column sixteen.

The MESSAGE statement places the job in hold, and should be used only when other control statements cannot
convey necessary information to the operator or system. The MESSAGE statement may be used to inform the
operator that the job cannot be run until a particular time. Then the operand might appear as follows:

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ /*MESSAGE HOLD UNTIL 3:00 AM, FRIDAY, MARCH 23 ]
[ ]
[ Figure 23. MESSAGE statement ]
+----------------------------------------------------------------------------+
It might also be used to provide information to the operator about printer form alignment on a one-time
basis, when permanent form setup instructions are not available.

THE SETUP STATEMENT

The SETUP statement is used to inform the operator to "enable writing" on one or more tape volumes.

In MVS, when a tape mount message is displayed on the operator's console, all of the SETUP statements in the job
are displayed also. The presumption is that tapes will be mounted with "writing disabled" unless the volume serial
numbers appear in the SETUP statement with the notation "WRITE ENABLE". Therefore, tapes that will only be read
need not appear in a SETUP statement.

Tape cartridges are normally stored and mounted with the "file protect selector" set to the "file protected" position.
The "file protect selector" is set to the "file unprotected" position to "write enable" it in response to a SETUP
statement. Tape reels are normally stored and mounted with the "write enable ring" removed. A "write enable ring" is
placed in the tape reel to "write enable" it in response to a SETUP statement.

MVS normally has the tape cartridge drives available or "VARIED ON LINE" to it. The tape reel drives are not
normally available to MVS and must be "VARIED OFF LINE" from another system and "VARIED ON LINE" to MVS
before they are available to a MVS job.

The SETUP statement is identified by "/*SETUP" in columns one through seven. The notation "WRITE ENABLE"
appears in columns sixteen through twenty seven. The first volume serial number starts in column twenty nine.
Additional volume serial numbers may follow, separated by commas. Characters beyond column seventy will not be
seen by the operator because of implementation restrictions. It is recommended that columns beyond seventy not be
used.

When using CLASS S, use a SETUP card to tell the operator how many of each type ofdrive will be needed.

Up to six SETUP statements are allowed per job. Do not use two if one will do.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ /*SETUP WRITE ENABLE AM2047 ]
[ /*SETUP WRITE ENABLE T02149,T02631 ]
[ /*SETUP WRITE ENABLE AM2135,AM2241,AM2412,T02196,T02349,T02256 ]
[ /*SETUP 1(REEL),2(CART) ]
[ ]
[ Figure 24. SETUP statement ]
+----------------------------------------------------------------------------+

THE COMMENT STATEMENT

The COMMENT statement is used to inform the user of the functions the job performs, the functions the
job step performs, how the job might be modified, what must be done before and after the job is run,
and so forth, so the user might successfully submitthe job.

The COMMENT statement is identified, to the system, by a "//*" in columns one through three. The COMMENT
statement does not have an operation or operand. It will have a "//* ** " in columns one through seven for easy visual
identification. The text of the COMMENT statement may be anywhere within columns eight through seventy one. A
single COMMENT statement, or a series of COMMENT statements with text in columns eight through seventy one,
must be preceded by and followed by a COMMENT statement without text.

A comment statement containing the system style job name should appear at the beginning of any job which uses the
user style job name as the job name of the JOB statement.

See "The Job Name" for a description of system style, user style, and MVT style job names.

COMMENT statements should appear at the beginning of the job and should explain the function the job performs.
More COMMENT statements may appear before each EXEC statement in a multiple step job to explain the function
each following job step performs. A COMMENT statement may precede a DD statement to identify the file with a
translation of the DDNAME and DSN. Additional COMMENT statements may appear at those points where the user
must change a JCL statement or insert control information or data.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //* ** ]
[ //* ** PRINT THE MECHANICS AUDIT REPORT IN VEHICLE SEQUENCE. ]
[ //* ** ]
[ //* ** ]
[ //* ** SEE FORM 129C FOR ADDITIONAL INSTRUCTIONS. ]
[ //* ** COLUMNS 1-6 PAYROUT DATE MMDDYY. ]
[ //* ** COLUMNS 7-15 OPTIONAL STARTING SOCIAL SECURITY NO. ]
[ //* ** ]
[ ]
[ Figure 25. COMMENT statements ]
+----------------------------------------------------------------------------+

THE OUTPUT STATEMENT

This is the // OUTPUT statement, not the /*OUTPUT statement. The /*OUTPUT statement may not be
used. The // OUTPUT statement is used to specify system output, SYSOUT, processing options. The //
OUTPUT statement is identified by a "//" in columns one and two, followed by the output name, and the
word OUTPUT. The output name is left justified in column three. The word OUTPUT will be in columns
nine through fourteen.

The Output Name

The output name consists of the word OUT followed by a one or two digit number. Each output name in
a job must be unique.
+-------------------------------------------------+
[ 0 1 1 ]
[ 1234567890123456 ]
[ ]
[ //OUT0 OUTPUT ]
[ //OUT1 OUTPUT ]
[ //OUT23 OUTPUT ]
[ ]
[ Figure 26. Output Name ]
+-------------------------------------------------+

The Keyword Parameters

The keyword parameters will be left justified in column sixteen, and continued in column sixteen of
subsequent lines if necessary.

The following keyword parameters are unnecessary and may not be used.

 BURST
 CHARS
 CKPTLINE
 CKPTPAGE
 CKPTSEC
 COMPACT
 CONTROL
 FLASH
 FORMDEF
 GROUPID
 INDEX
 LINDEX
 LINECT
 MODIFY
 PAGEDEF
 PIMSG
 PRTY
 PRMODE
 THRESHLD
 TRC
 UCS

The following keyword parameters may be used:

 CLASS
 COPIES
 DEFAULT
 DEST
 FCB
  FORMS
 JESDS

... with some qualifications.

The CLASS Parameter

The CLASS keyword parameter specifies the output class for system output data sets referencing the //
OUTPUT statement containing the parameter. We will ordinarily code CLASS=* in each // OUTPUT
statement. The CLASS=* parameter of the // OUTPUT statement refers to and uses the output class
specified in the MSGCLASS parameter.

+--------------------------------------------+
[ CLASS=* ]
[ ]
[ Figure 27. CLASS Parameter ]
+--------------------------------------------+
See "The MSGCLASS Parameter" for a description of the valid output classes.

The COPIES Parameter

The COPIES keyword parameter specifies how many copies are to be made of system output data sets
referencing the // OUTPUT statement containing the parameter. It also specifies how many copies are to
be made of the system managed data sets if the JESDS parameter is specified. For example, a "3" would
indicate that three copies of the system output data sets would be printed. The COPIES keyword
parameter of the appropriate DD SYSOUT statements will be used instead of this parameter, when
possible. The default is 1 copy and may not be explicitly stated. The "group-value" subparameters of the
COPIES parameter may not be used.

+--------------------------------------------------+
[ COPIES=3 ]
[ COPIES=5 ]
[ ]
[ Figure 28. COPIES parameter ]
+--------------------------------------------------+

The DEFAULT Parameter

The DEFAULT=YES keyword parameter specifies that this // OUTPUT statement can be implicitly
referenced by a system output DD statement. A step-level // OUTPUT statement with a DEFAULT=YES
parameter is implicitly referenced by system output DD statements in the step, which do not contain an
OUTPUT parameter. A job-level // OUTPUT statement with a DEFAULT=YES parameter is implicitly
referenced by system output DD statements which do not contain an OUTPUT parameter and which are
in a step without a default // OUTPUT statement.
+----------------------------------------------+
[ DEFAULT=YES ]
[ ]
[ Figure 29. DEFAULT parameter ]
+----------------------------------------------+

The DEST parameter

The DEST keyword parameter specifies a destination for system output which references the // OUTPUT
statement. Use the "nodename.userid" notation. Use UCSBMVS.R0 to print at UCSB's MVS system
printer. The "nodename" for UCSB's VM is "UCSBVM". The ="userid" = could also specify any valid VM
RSCS printer name or node (e.g. a CMS account like IS00XX).

+-------------------------------------+
[ DEST=UCSBMVS.R0 ]
[ DEST=UCSBMVS.R3 ]
[ DEST=UCSBVM.IS00X ]
[ ]
[ Figure 30. DEST parameter ]
+-------------------------------------+

The FCB Parameter

The FCB keyword parameter of the // OUTPUT statement specifies the forms control buffer image to be
used to guide the printing of system output data sets. An FCB image indicates the vertical spacing in
lines per inch, the number of lines per page, the print train, the location of any channels for skipping, the
location of the top of page for skipping, and other such factors.

The default FCB indicates 6 lines per inch, 66 lines per page, and the "TN" print train. The FCB keyword parameter
should not be specified if the default FCB is adequate. The operations group of the Computer Center should be
contacted if you require a new unique FCB. It is the operations groups custom to assign an FCB name which is the
same as the form number, as specified in the FORMS keyword parameter of the // OUTPUT statement, or as
specified in the forms subparameter of the SYSOUT pa rameter of the DD statement.

+--------------------------------------------------+
[ FCB=51 ]
[ FCB=108 ]
[ ]
[ Figure 31. FCB parameter ]
+--------------------------------------------------+

The FORMS Parameter

The FORMS keyword parameter specifies the form for printing of system output data sets referencing
the // OUTPUT statement containing the parameter. It also specifies the forms for printing the system
managed data sets if the JESDS parameter is specified. The form number on the appropriate DD
statements will be used instead of this parameter, when possible. Regular forms (form 1) is the default
and may not be explicitly stated.

+-------------------------------------+
[ FORMS=8 ]
[ FORMS=3279 ]
[ ]
[ Figure 32. FORMS parameter ]
+-------------------------------------+

The JESDS Parameter

The JESDS keyword parameter specifies the processing of system managed data sets by the // OUTPUT
statement containing the parameter. The JESDS=ALL will ordinarily be used, but usually only on the //
OUTPUT statement with the DEFAULT=YES parameter.

+-----------------------------------------+
[ JESDS=ALL ]
[ JESDS=JCL ]
[ JESDS=LOG ]
[ JESDS=MSG ]
[ Figure 33. JESDS parameter ]
+-----------------------------------------+

THE SYSTEM OUTPUT DD STATEMENT

The system output DD statement is used to specify SYSOUT processing options, in addition to those
processing options specified by the // OUTPUT statement.

The SYSOUT Parameter

A system output DD statement is one which contains a SYSOUT keyword parameter.

The Class Subparameter

The first positional subparameter of the SYSOUT parameter is Class. The Class positional parameter
specifies the output class for the DD statement containing the SYSOUT parameter. We will ordinarily
code CLASS=(,) in each system output DD statement. This defaults to the CLASS parameter of the
corresponding OUTPUT statement, or if there is none, to the MSGCLASS parameter of the JOB
statement.

The CLASS=* parameter of the // OUTPUT statement and the Class * subparameter of the SYSOUT parameter of
the DD statement refer to and use the output class specified in the MSGCLASS parameter.

+-------------------------------------------------+
[ 123456789012345678901234567890 ]
[ ]
[ //SYSPRINT DD SYSOUT=(,) ]
[ //REPRT3X DD SYSOUT=(, ... ) ]
[ ]
[ Figure 34. Class Subparameter ]
+-------------------------------------------------+
See "The MSGCLASS Parameter" for a description of the valid output classes.

The Program Subparameter

The 2nd positional subparameter of SYSOUT is Program. We do not use this subparameter.

The Forms Subparameter

The third positional subparameter of the SYSOUT parameter is Forms. The Forms positional
subparameter specifies the form for printing of system output for the DD statement containing the
SYSOUT parameter. Regular forms (form 1) is the default and may not be explicitly stated.

+------------------------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ //SYSPRINT DD SYSOUT=(,,8) ]
[ //CHECKS DD SYSOUT=(,,3279) ]
[ ]
[ Figure 35. Forms subparameter ]
+------------------------------------------------------------+

The COPIES Parameter

The COPIES keyword parameter specifies the number of copies (1 to 254) that are to be made of the
system output of the DD statement containing the SYSOUT parameter. (Example: a "3" specifies that
three copies of the system output data set are to be printed). The default is 1 copy and may not be
explicitly stated. The "group-value" subparameters of the COPIES parameter may not be used.

+----------------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ //SYSPRINT DD SYSOUT=(,),COPIES=3 ]
[ //LISTONE DD SYSOUT=(,),COPIES=5 ]
[ ]
[ Figure 36. COPIES parameter ]
+-----------------------------------------------------+

The DEST Parameter

The DEST keyword parameter of the DD statement may be used to send a system output data set to a
single destination. The Primary and Alternate Methods are preferred over the use of the DEST keyword
parameter on the DD statement. See "Alternatives for System Output" for a description of the system
output alternatives. See "The DEST parameter" for additional destination information.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //CHECKS DD SYSOUT=(,),DEST=UCSBMVS.R3 ]
[ //ERROR DD SYSOUT=(,),COPIES=3,DEST=UCSBVM.ISOPRT4 ]
[ ]
[ Figure 37. DEST parameter ]
+----------------------------------------------------------------------------+

The FCB Parameter

The FCB keyword parameter of the DD statement specifies the forms control buffer image to be used to
guide the printing of system output data sets. The FCB keyword parameter of the // OUTPUT statement
may be used instead. See "The FCB Parameter" for additional information on FCB parameters.

+-----------------------------------------------------------------------------
+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6
7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012
]
[
]
[ //PAYMENT DD
SYSOUT=(,,51),COPIES=2,DEST=UCSBMVS.R0,FCB=51 ]
[ //INVENT DD
SYSOUT=(,,109),DEST=UCSBMVS.R0,FCB=109 ]
[
]
[ Figure 38. FCB
parameter ]
+-----------------------------------------------------------------------------
+

The FREE Parameter

JES2 normally schedules all system output data sets for printing at the end of the job. Consider using the
FREE=CLOSE parameter to deallocate, or spin-off, a system output data set so that JES may print it
before the job has finished execution, and before JES starts to print other portions of the job.

The FREE parameter might be used if a system output data set is closed at a relatively early point in the execution of
a job, and it is important to see the information in the data set soon. It might also be used if it is important to see
information ina system output data set, so that the user may determine whether or not to print other, perhaps large,
portions of the job.

The FREE parameter does separate the system output data set into a system output "set", with its own JES2
separator sheets. This can be an inconvenience in distributing printed output, therefore do not use the FREE
parameter unnecessarily.

+-----------------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ //SYSPRINT DD SYSOUT=(,),FREE=CLOSE ]
[ ]
[ Figure 39. FREE parameter ]
+-----------------------------------------------------+

The HOLD Parameter

Consider using the HOLD=YES parameter to hold a system output data set, for subsequent release by the
user. The user may use Com-Plete's UQ utility to release or cancel it, after examination. This only works
with datasets remaining in MVS (not routed to another node).

+-----------------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ //STATRPT DD SYSOUT=(,),HOLD=YES ]
[ ]
[ Figure 40. HOLD parameter ]
+-----------------------------------------------------+

The OUTLIM Parameter

The OUTLIM keyword parameter is used to provide a line kill to the operating system for DD statement
containing the SYSOUT parameter. The OUTLIM parameter limits the number of logical records in the
system output data set. The OUTLIM parameter may be used for testing. It may not be used for
production jobs.

+----------------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ //STATRPT DD SYSOUT=(,),OUTLIM=500 ]
[ ]
[ Figure 41. OUTLIM parameter ]
+----------------------------------------------------+

The OUTPUT Parameter

The OUTPUT keyword parameter is to explicitly associate a system output data set with an // OUTPUT
statement. The OUTPUT parameter is used with the Alternate Method of system output. See
"Alternatives for System Output" for a description of the system output alternatives.

+-----------------------------------------------+
[ DD SYSOUT=(,),OUTPUT=*.OUT2 ]
[ DD SYSOUT=(,),OUTPUT=(*.OUT3,*.OUT5) ]
[ ]
[ Figure 42. OUTPUT parameter ]
+-----------------------------------------------+
ALTERNATIVES FOR SYSTEM OUTPUT

There are many ways one can deal with system output. In the interest of simplicity and understanding,
we will limit the alternatives.

With either of the two approved alternatives we will have an // OUTPUT statement with an output name of "OUT0"
and with DEFAULT=YES and JESDS=ALL parameters. Ordinarily, forms and copies will not be specified in this
statement, although they may be used if necessary.

+---------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //OUT0 OUTPUT CLASS=(,),DEFAULT=YES,DEST=UCSBMVS.R0,JESDS=ALL ]
[ //OUT1 OUTPUT CLASS=(,),COPIES=2,DEFAULT=YES,DEST=UCSBMVS.R3,JESDS=ALL ]
[ ]
[ Figure 43. // OUTPUT statement ]
+---------------------------------------------------------------------------+

The Primary Method

The Primary Method will use only one // OUTPUT statement, the "OUT0". The // OUTPUT statement will
be used for all system output for the entire job. Forms and copies will be specified in the individual
system output DD statements, as needed. If special forms are used, the form is the third positional
subparameter with parentheses of the SYSOUT keyword parameter. If more than one copy is to be
printed, the COPIES keyword parameter will follow the SYSOUT parameter. The DEST keyword
parameter of the DD statement will not be used.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //OUT0 OUTPUT CLASS=*,DEFAULT=YES,DEST=UCSBVM.950MPRNT,JESDS=ALL ]
[ ]
[ //SYSPRINT DD SYSOUT=(,) ]
[ //STATS DD SYSOUT=(,,3279),COPIES=3 ]
[ //REPORT DD SYSOUT=(,),COPIES=4 ]
[ //STATS DD SYSOUT=(,,2238) ]
[ ]
[ Figure 44. Primary Method ]
+----------------------------------------------------------------------------+
For jobs moved from MVT, the destination will usually be indicated by a /*ROUTE PRINT statement. The
SYSOUT statement will be constructed as shown above. There will be no // OUTPUT statement.

The Alternate Method

The Alternate Method allows for greater flexibility in directing system output to multiple destinations.
The Alternative Method will use multiple // OUTPUT statements. The "OUT0" // OUTPUT statement
would still be used for all of the system output that isn't defined by the other // OUTPUT statements.
Additional // OUTPUT statements will be defined to specify forms, copies, and destinations, as
necessary. Forms, copies, and destinations will not be specified in the DD statements, but rather the DD
statements will explicitly reference an // OUTPUT statement via the OUTPUT parameter.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //OUT0 OUTPUT CLASS=*,DEFAULT=YES,DEST=UCSBMVS.R4,JESDS=ALL ]
[ //OUT1 OUTPUT CLASS=*,DEST=UCSBMVS.R0,FORMS=3279,COPIES=3 ]
[ //OUT2 OUTPUT CLASS=*,DEST=UCSBVM.PERSNL1,COPIES=3 ]
[ //OUT3 OUTPUT CLASS=*,DEST=UCSBMVS.R0,FORMS=2238 ]
[ ]
[ //SYSPRINT DD SYSOUT=(,) ]
[ //STATS DD SYSOUT=(,),OUTPUT=*.OUT1 ]
[ //REPORT DD SYSOUT=(,),OUTPUT=(*.OUT0,*.OUT2) ]
[ //STATS DD SYSOUT=(,),OUTPUT=*.OUT3 ]
[ ]
[ Figure 45. Alternate Method ]
+----------------------------------------------------------------------------+
One common use of this method is to have one //OUTPUT statement for the JES logs, where CLASS=Z
(suppress print) and another //OUTPUT statement for the other print datasets.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //OUT0 OUTPUT CLASS=Z,DEFAULT=YES,DEST=UCSBMVS.R0,JESDS=ALL ]
[ //OUT1 OUTPUT CLASS=*,DEST=UCSBMVS.R0 ]
[ ]
[ Figure 46. Alternate Method For Separating System Output ]
+----------------------------------------------------------------------------+

THE EXEC STATEMENT

The EXEC statement is used to identify the program or procedure to be executed and to tell the system
how to process the job step.

The Step Name

The EXEC statement has "//" in columns one and two, followed by a stepname and the word EXEC. The
step name will be left justified in column three. The word EXEC will be in columns eleven through
fourteen. The stepname shall consist of an "S" followed by a single digit or double digit number. For
example, the first "EXEC" statement would have a stepname of "S1", while the twelfth would have a
stepname of "S12".

+----------------------------------------------+
[ 0 1 1 ]
[ 1234567890123456 ]
[ ]
[ //S1 EXEC ]
[ //S12 EXEC ]
[ ]
[ Figure 47. Step Name ]
+----------------------------------------------+

The PROC and PGM Parameters

The operation will be left justified in column sixteen. It will be continued in column sixteen of the next
line if necessary. Most EXEC statements will call a procedure, in which case the procedure name will
start in column sixteen. All production Information Systems Office programs must be run by calling a
procedure. Only systems utilities may be run using PGM=xxxxxxx. Specific justification and approval by
your project leader is required for any exceptions.

If the EXEC statement does not call a procedure, the "PGM=" will start in column sixteen. In this case, the EXEC
statement will be immediately followed by a STEPLIB DD statement if one is required.

+----------------------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ //S3 EXEC DBNONE ]
[ //S1 EXEC ISOSORT ]
[ //S12 EXEC PGM=IEBCOPY ]
[ ]
[ Figure 48. PROC and PGM parameters ]
+----------------------------------------------------------+
If the name of the program is a parameter to the procedure as in MBR=xxxxxxxx, it will follow the
procedure name. If the program library is a parameter to the procedure as in LIB=x...x, it will follow in
turn. The entire data set name should be stated within apostrophes. Additional parameters may be
continued on the same or next line if necessary.

+----------------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ MBR=SRPRP008,LIB='AM2T.SR.LOAD' ]
[ MBR=BARTP079,LIB='AM2P.BART.LOAD' ]
[ ]
[ Figure 49. MBR and LIB parameters ]
+----------------------------------------------------+

The Keyword Parameters

The keyword parameters will follow the PROC and PGM parameters, and are separated by commas.

The following keyword parameters are unnecessary and may not be used.

 ACCT
  ADDRSPC
 DPRTY
 DYNAMNBR
 RD

The following keyword parameters may be used:

 COND
 PARM
 REGION
 SORTSPA
 TIME

... with some qualifications.

The COND parameter

When possible, it is preferable to use the COND parameter on the job statement, rather than the EXEC
statement for production jobs.

+-----------------------------------------+
[ COND=(0,NE,S4) ]
[ COND=(4,GT,S2) ]
[ ]
[ Figure 50. COND parameter ]
+-----------------------------------------+

The PARM parameter

The PARM parameter may be used to pass information to the program executed by a job step.

+-----------------------------------+
[ PARM='47,X=5' ]
[ PARM.G='LIMIT=21,START=4' ]
[ ]
[ Figure 51. PARM parameter ]
+-----------------------------------+

The REGION parameter

The REGION parameter will NOT be explicitly stated (therefore omitted). Use the operating system's
default REGION size.

The TIME parameter

The TIME=(x,y) keyword parameter provides a CPU kill time to the operating system. The TIME keyword
parameter may be used for testing. It may not be used for production jobs. The "x" is the number of
minutes of CPU time and the "y" is the number of seconds of CPU time. The number of seconds of CPU
time may range from zero to fifty nine.

+-----------------------------------------+
[ TIME=(2,30) ]
[ TIME=(0,15) ]
[ TIME=(,3) ]
[ ]
[ Figure 52. TIME parameter ]
+-----------------------------------------+

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //S1 EXEC PGM=IEBCOPY,REGION=200K ]
[ ]
[ //S3 EXEC DBSTDS,MBR=SRPRP008,LIB='AM2T.SR.LOAD',REGION=400K, ]
[ // DB=A,DISP=OLD,SORTSPA='8560,25' ]
[ ]
[ //S12 EXEC MAPTAPE,VOL=AM2043 ]
[ ]
[ //S4 EXEC ISOSORT,SORTSPA='8608,150' ]
[ ]
[ //S1 EXEC IMSXCL,MBR=RMAXP043,LIB='AM3P.RM.LOAD' ]
[ ]
[ Figure 53. EXEC statement ]
+----------------------------------------------------------------------------+

Other Parameters

Other parameters specific to a procedure may be required and/or supplied on the EXEC statement.

THE DD STATEMENT

The DD statement describes a data set to be used in a job step and specifies the input and output
facilities required for the use of the data set. The DD statement is identified by a "//" in columns one and
two, a ddname left justified in column three (except in concatenated DD statements), and "DD" in
columns thirteen and fourteen. The operand will be left justified in column sixteen, and continued in
column sixteen of subsequent lines if necessary.

Overriding Procedures
When executing a multiple step procedure, it may be necessary to specify the procedure step name on
the first overriding or additional DD statement in the job stream for a procedure step. This is done by
preceding the ddname with the procedure step name and a period. This will be done for the first DD
statement per procedure step in multiple step procedures only. An exception to left justifying in column
sixteen is allowed, if necessary, in this case.

+--------------------------------------------+
[ 0 1 1 2 2 ]
[ 1234567890123456789012345 ]
[ ]
[ //ALPHA DD DSN= ]
[ //S1.ALPHA DD DSN= ]
[ //G.SYSPRINT DD SYSOUT=(,) ]
[ ]
[ Figure 54. Overriding DD statement ]
+--------------------------------------------+

The Keyword Parameters

The following keyword parameters are unnecessary and may not be used.

 DYNAM
 ACCODE
 AMP
 BURST
 CHARS
 CHKPT
 CNTL
 DDNAME
 DLM
 DSID
 FLASH
 MODIFY
 MSVGP
 PROTECT
 QNAME
 SUBSYS
 TERM
 UCS

The following keyword parameters may be used for system output data sets:

 COPIES
 DEST
 FCB
 FREE
 HOLD
  OUTLIM
 OUTPUT
 SYSOUT

.... with some qualifications. See "Alternatives for System Output" for a description of the parameters for
system output data sets.

The following keyword parameters may be used for other data sets:

 DSN
 DISP
 FREE
 LABEL
 SPACE
 UNIT
 VOL
 DCB

.... with some qualifications. The DSN parameter of a DD statement will be placed first and the DCB
parameter will be placed last, with the other parameters in between in any sequence.

The DSN Parameter

The Data Set Name (DSN) parameter is used to assign a name to a data set when it is created and is
subsequently used to identify the data set.

Temporary Data Sets

Any data set created and deleted within a job is a temporary data set. It is preferable to let the system
assign a unique name by omitting the DSN parameter in the DD statement (see below).

+---------------------------------------------------------------+
[ //DATA1 DD UNIT=SYSDA,DISP=(NEW,PASS),... ]
[ ]
[ Figure 55. Temporary DSN parameter created by system ]
+---------------------------------------------------------------+
Another way of assigning a temporary dataset is by coding DSN=&&dsname.

+------------------------------------------------------------------+
[ DSN=&&BARGUZ3 ]
[ DSN=&&COMPRESS ]
[ ]
[ Figure 56. Temporary DSN parameter using ampersand notation ]
+------------------------------------------------------------------+
System assigned data set names will be referred back to by using the DSN=*.referback parameter.
+---------------------------------------------------------------+
[ DSN=*.S3.SORT.SORTOUT ]
[ DSN=*.S1.EXTRACT ]
[ ]
[ Figure 57. Temporary DSN parameter referback notation ]
+---------------------------------------------------------------+

Permanent Data Sets

Any data set that is to exist beyond the duration of a job is a permanent data set. Permanent data sets
will be assigned qualified names that specify either a user or an application using the first and second
level qualifiers, or a WYLBUR dataset naming convention.

For non-WYLBUR datasets, the following information applies. The first level qualifier of all permanent data set names
will be used to allow for the existence and balancing of multiple system catalogues, in order to optimize system
throughput. The second level qualifier will be used to distinguish between users, systems, departments and for billing
purposes. Use of the remaining levels are not prescribed, although planning can reduce problems.

All Computer Center data sets will have a first level qualifier of either SYS1 or UCSB. The second level qualifier will
be an application of their choosing.

The first level qualifier for administrative users and applications is "AMnx" ("n" is either '1' or '2'). The "x" will be:

A Archive data set

P Production data set

T Test data set

D Development data set

The second level qualifier will be to identify user, system or department (PREDICT should be checked to
make sure the qualifier exists, or isn't already in use). Special characters in data set names will be
avoided, especially if they require that the data set name be specified within apostrophes.

WYLBUR datasets will be assigned names in the format of WYL.groupname.acctname.datasetname.

+-------------------------------------------------------------+
[ DSN=AM1P.SY.LOAD(WAZX20 ]
[ DSN=AM1T.PR.RESTORE(0) ]
[ DSN=SYS1.PROCLIB(CONTROL) ]
[ DSN=WYL.QVA999.SMITH.EXTRACT ]
[ ]
[ Figure 58. Permanent DSN parameter ]
+-------------------------------------------------------------+

The DISP Parameter

The disposition (DISP) parameter describes to the system the status of a data set and indicates what is
to be done with the data set after termination of a job step, or, at the end of the job. There are three
positional subparameters in the DISP parameter.
The Status Subparameter

The first subparameter specifies whether the data set existed before this job step and should be
explicitly stated.

DISP=(NEW,,,) is the default and specifies that the data set is to be created in this job step.

When a temporary disk data set is created and deleted in the same job step use DISP=(NEW,DELETE,DELETE).

OLD, SHR and MOD specify that the data set existed before this job step.

SHR indicates the data set is only to be read and may be shared with other jobs. SHR should be used when reading
permanent disk data sets. SHR may not be used with tape data sets.

OLD should be used when reading existing tape data sets, when reading passed temporary disk data sets, and when
updating or deleting permanent or disk data sets.

MOD indicates the data set is to have records appended after the last record in the data set. MOD should be used
with care, if at all, because data set recovery after a job or system failure may be difficult. Coding (MOD,CATLG)
when extending a disk data set ensures the catalogue entry is updated so MVS can locate the entire data set when it
is requested next.

The Normal Termination Disposition Subparameter

The second subparameter indicates what is to be done with the data set at the end of this job step and
should be explicitly stated.

The default is that if a data set was NEW it will be deleted, and if a data set existed it will be kept. The default will be
allowed when the DISP parameter is not coded, the default being DISP=(NEW,DELETE,DELETE), and when a
permanent data set existed in which case DISP=OLD, DISP=SHR, or DISP=MOD will be coded.

New, permanent data sets will be coded DISP=(NEW,CATLG). Temporary data sets passed to another step will be
coded DISP=(NEW,PASS) when created, DISP=(OLD,PASS) in intermediate job steps, and DISP=(OLD,DELETE) in
the last job step in which they are accessed. They will never be catalogued with CATLG.

The Abnormal Termination Disposition Subparameter

The third subparameter indicates what is to be done with the data set at the end of the job step if the
job step abnormally terminates and should be explicitly stated. It will always be defaulted for temporary
data sets. DELETE may follow the CATLG for new permanent data sets if necessary to ease the
restartability of the job or job step.

+-----------------------------------------------------+
[ DISP=SHR ]
[ DISP=OLD ]
[ DISP=(NEW,CATLG) ]
[ DISP=(NEW,KEEP,DELETE) ]
[ DISP=(NEW,PASS) ]
[ DISP=(OLD,PASS) ]
[ DISP=(OLD,DELETE) ]
[ ]
[ Figure 59. DISP parameter ]
+-----------------------------------------------------+

The UNIT Parameter

The UNIT parameter provides the system with information it needs to assign a device to a data set. The
unit parameter will be used as follows:

 The group name DISK parameter will be used for the creation of permanent user disk data sets.
 The group name REEL will be used for tape reel requests. The group name REEL will designate a
6250/1600 BPI dual density tape reel device. This would ordinarily default to the highest density
for the device, which is 6250 BPI, when writing the first data set on a tape reel. At all other
times, the density of the label and the first data set will be the default. An 800 BPI device will
not be available.
 The group name CART will be used for tape cartridge requests.
 Tape cartridge requests are preferred over tape reel requests. Tape reels may be used to import
or export data from the MVS system only if it cannot be done via tape cartridge or disk.
 The group name SYSDA will ordinarily be used for the creation of temporary disk data sets.
 The virtual disk name VIO may be used, instead of SYSDA, for temporary data set requests of
eight or less blocks of space at the standard block size.

See "The BLKSIZE Subparameter" and "Appendix B. Estimating Disk Space" for more information about the
standard block size. Other virtual disk names such as V3390 will not be used.

 Device addresses, such as 560 or 283, will not be used for disk or tape requests.
 Device types, such as 3400, 3400-3, 3400-4, 3400-5, 3480, or 3390, will not be used for disk or
tape requests.
 UNIT=AFF=ddname may be used to reduce the number of tape units used in a job step.
 DEFER may be used to delay a tape mount request until the data set is opened. This avoids a
mount request if the data set is never opened. The device allocation occurs at the beginning of
the job step, whether DEFER is used or not.
 SEP for separation will not be used.
 Unit count will not ordinarily be used.
 P for parallel mounting will not be used.

+------------------------------------------+
[ UNIT=DISK ]
[ UNIT=CART ]
[ UNIT=REEL ]
[ UNIT=(CART,,DEFER) ]
[ UNIT=(REEL,,DEFER) ]
[ UNIT=SYSDA ]
[ UNIT=AFF=MASTIN ]
[ ]
[ Figure 60. UNIT paramete ]
+------------------------------------------+

The VOL Parameter

The Volume (VOL) parameter provides information about the volume or volumes on which an input data
set resides or on which an output data set will reside.

It is a goal of Information Systems to have all permanent disk data sets catalogued. We want to catalogue each
permanent data set when it is created, and use the catalogue for any subsequent references to the data set. This
would reduce a DD statement, when subsequently referencing a permanent data set, to only DSN and DISP
parameters

+--------------------------------------------------------+
[ DD DSN=AM1P.RN.LOAD(RNAXP014), ]
[ DISP=OLD ]
[ DD DSN=AM1T.PR.RESTORE(0), ]
[ DISP=SHR ]
[ DD DSN=AM1T.BART.EXTRACT.#860125, ]
[ DISP=SHR ]
[ ]
[ Figure 61. Use the catalogue ]
+--------------------------------------------------------+
It is also a goal to minimize the number of specific volume references when creating permanent tape
and disk data sets. This is easily done on most disk data sets by omitting the SER subparameter of the
VOL parameter, or omitting the entire VOL parameter, while specifying UNIT=DISK. It may be impossible
on some tape data sets, but can be accomplished for generation data sets on tape (or disk) as explained
in "Generation Data Sets". You may use the SER subparameter when creating permanent data sets on
tape.

+---------------------------------------------------+
[ DD DSN=AM1P.XNBT.MASTER, ]
[ DISP=(NEW,CATLG), ]
[ UNIT=DISK ... ]
[ ]
[ DD DSN=AM1A.PR.EDB.#871102, ]
[ DISP=(NEW,CATLG), ]
[ VOL=AM2132, ]
[ LABEL=(3,SL) ... ]
[ ]
[ Figure 62. Minimize SER usage ]
+---------------------------------------------------+
All of our disk volumes are private, cannot be demounted. PRIVATE will not be used. RETAIN will be used
on tape volumes if the volume is not to be demounted after its last use in the job step, so it may be used
in a subsequent job step. The volume sequence number and the volume count are not ordinarily used
because we do not have many multiple volume data sets.

Again, use of the SER parameter will be minimized. It will not be used to create disk data sets to be accessed from
MVS. It may be used to create some tape data sets. It will not be used to read catalogued data sets nor passed data
sets. The REF parameter should be used instead of the SER parameter to reference the first DD statement for a
volume when more than one data set is being created or accessed on the same volume. The REF parameter may be
used instead of the SER parameter to reference the catalogue when any tape or disk data set is being created. REF
should be used to reference an older generation when creating a generation data set using a round robin set of
tapes. REF may be used to reference a model data set when creating a generation data set on disk.

+----------------------------------------------+
[ VOL=SER=DISK81 ]
[ VOL=SER=T02497 ]
[ VOL=(,RETAIN,SER=AM2126) ]
[ VOL=REF=AM1P.SR.MASTER.MODEL ]
[ ]
[ Figure 63. VOL parameter ]
+----------------------------------------------+

The LABEL Parameter

It is a goal of Information Systems to use standard label data sets on IBM standard labeled tapes. The
LABEL parameter will be used when writing standard labeled (SL) tape data sets.

If this goal cannot be met (due to off-campus hardware limitations when we transmit or receive tape data sets):

1. non labeled tapes (NL) should be used;

2. user labels (SUL or NSL) or ASCII labels (AL or AUL) should not be used except when required by
an off-campus system.

NOTE:

 Tape data sets are NOT catalogued at UCSB.

 The data set sequence number (aka file number) is always explicitly stated (even for file 1, which
is the default).
 The standard label (SL) is to be explicitly stated (even though it is the default).

+-------------------------------------------------------------------+
[ LABEL=(1,SL) ]
[ LABEL=(3,SL) ]
[ LABEL=(1,NL) ]
[ ]
[ Figure 64. LABEL parameter showing file numbers and label type ]
+-------------------------------------------------------------------+

The SPACE Parameter

The SPACE parameter is used to allocate space on disk volumes for new data sets. Space will ordinarily
be allocated by block length. Use the same block length as specified in the DCB BLKSIZE subparameter.

Track (TRK) or cylinder (CYL) may be used for data set organizations that do not allow for allocation by block length.
Space will not be allocated by ABSTR, SUBALLOC or SPLIT.

Primary and secondary quantities should be specified considering anticipated growth patterns, volatility of record
sizes and record counts, and the historical pattern of limited SYSDA and private disk volume space. Fragmentation of
private volumes by multiple extent data sets is also a concern. Do not unnecessarily over allocate SYSDA space.
Specify secondary quantities so that production jobs will run successfully even when the number of records changes
significantly.

See "Appendix B. Estimating Disk Space" for further information.

Directory quantity must be specified for partitioned data sets although they are not usually allocated in production
jobs. Contiguous space (CONTIG) should only be specified when it is necessary. Release (RLSE) should be used to
release unused space when a data set is created and then subsequently opened only for input. ROUND is not to be
used.

+----------------------------------------------------+
[ SPACE=(8608,(50,20)) ]
[ SPACE=(8594,(250,40),RLSE) ]
[ SPACE=(8608,(80,10,8)) ]
[ SPACE=(CYL,(5,,2)) ]
[ SPACE=(TRK,(100,25),RLSE) ]
[ ]
[ Figure 65. SPACE parameter ]
+----------------------------------------------------+

The DCB Parameters

DCB parameters will be present only when creating a data set. There may be a few exceptions, but these
will be determined by operating system requirements. You may use the DCB refer back when creating
more than one data set with the same DCB characteristics.

System Input and Output data sets

See "Alternatives for System Output" for a description of the parameters for system output data sets.

+----------------------------------------------------------+
[ 0 1 1 2 2 3 ]
[ 123456789012345678901234567890 ]
[ ]
[ //SYSPRINT DD SYSOUT=(,) ]
[ //STATS DD * ]
[ ]
[ Figure 66. System Input and Output Data Sets. ]
+----------------------------------------------------------+
Code programs in a manner that will avoid DCB parameters for print data sets and for input stream data
sets.

+-------------------------------------------------------------------------+
[ OPEN FILE (STICKER) PRINT LINESIZE (132) PAGESIZE (63); ]
[ OPEN FILE (CONTROL) INPUT STREAM; ]
[ ]
[ Figure 67. Opens to Avoid DCBs for System Input and Output ]
+-------------------------------------------------------------------------+

The DSORG Subparameter

The Data Set Organization (DSORG) parameter may be defaulted for physical sequential data sets. While
there are many data set organizations to choose from, use the simplest that will perform the function.
Do not use "unmovable" or DA data sets unnecessarily.

+---------------------------------------------+
[ DSORG=IS ]
[ DSORG=PO ]
[ ]
[ Figure 68. DSORG subparameter ]
+---------------------------------------------+

The RECFM Subparameter

Record Format (RECFM) specifies the format and characteristics of the records in the data set. Do not
default the RECFM for new disk or tape data sets. Block records when possible for economy of space
and I/Os. Use ASCII data sets only when necessary to transport data from and to other machines. Avoid
"standard" S data sets and "spanned" S data sets. Keep it simple.

+--------------------------------------------+
[ RECFM=FB ]
[ RECFM=VB ]
[ ]
[ Figure 69. RECFM subparameter ]
+--------------------------------------------+

The LRECL Subparameter

The Logical Record Length (LRECL) specifies the actual or maximum length of a record. Do not use
LRECL=X. Record length may be omitted if the records are unblocked and BLKSIZE is specified as the
record length, as in system output data sets.

+---------------------------------------+
[ LRECL=8608 ]
[ LRECL=8527 ]
[ ]
[ Figure 70. LRECL subparameter ]
+---------------------------------------+

The BLKSIZE Subparameter

The Block Size (BLKSIZE) specifies the maximum length of a block. The maximum length that can possibly
be specified is 32,760 or a smaller number near the capacity of a track on a disk. Use a block size less
than or equal to 32,760 for tapes. Use a block size less than or equal to 8,608 for disks. 8,608 is most
efficient block size. However, when saving datasets on WYLBUR without explicit blocksize, WYLBUR will
chose the 'best' blocksize for the type of unit. For instance, SAVE CARD in WYLBUR to a 3390 will cause
WYLBUR to select a blocksize of 11440. Exceptions may be made for very small tape data sets, when
data is transported from and to other machines with memory limitations, or when the data set is
sometimes written to disk and sometimes written to tape.

+----------------------------------------------------+
[ BLKSIZE=8608 ]
[ BLKSIZE=8560 ]
[ BLKSIZE=32767 ]
[ ]
[ Figure 71. BLKSIZE subparameter ]
+----------------------------------------------------+

The DEN Subparameter

The Density (DEN) parameter specifies the tape density used to write a tape data set to a tape reel, but
not to a tape cartridge. DEN will always be specified for a data set for a tape reel when the DISP is NEW.

DEN=4: 6250 bits per inch

DEN=3: 1600 bits per inch

DEN=2 (800 bits per inch) is not available.

DEN=4 will be used for any local tape data sets except where the hardware is incapable of higher
densities. To send data off campus, the receiving party must usually agree to the tape density on a
system by system basis. It is a goal of Information Systems to use the highest possible density.

+-------------------------------------------+
[ DEN=4 ]
[ DEN=3 ]
[ DEN=2 ]
[ ]
[ Figure 72. DEN subparameter ]
+-------------------------------------------+

The Other Subparameters

The OPTCD subparameter may be used for ASCII data sets. Avoid other DCB subparameters. Keep it
simple.

+-----------------------------------------------------------------------------
+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6
7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012
]
[
]
[ //
DCB=(RECFM=VB,LRECL=150,BLKSIZE=8608) ]
[
]
[ //
DCB=(RECFM=FB,LRECL=225,BLKSIZE=32625,DEN=4) ]
[
]
[ //
DCB=(DSORG=IS,RECFM=FB,LRECL=150,BLKSIZE=8550, ]
[ //
KEYLEN=8,RKP=4,OPTCD=WRMLY,NTM=1,CYLOFL=5) ]
[
]
[ //
DCB=*.S1.OUTPUT ]
[
]
[ Figure 73. DCB
parameter ]
+-----------------------------------------------------------------------------
+

The FREE Parameter

The FREE=CLOSE parameter specifies deallocation of resources such as, devices, volumes, or exclusive
use of a data set, for this DD statement when the data set is closed. Consider using it to deallocate the
tape unit associated with a tape data set, so that the tape unit is made available to another job.

+----------------------------------------------+
[ FREE=CLOSE ]
[ ]
[ Figure 74. FREE parameter ]
+----------------------------------------------+

JCL EXAMPLES

Temporary Disk Data Sets

Temporary disk data sets created and deleted within a job step will have only the UNIT=SYSDA, SPACE
and DCB parameters.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //ALPHA DD UNIT=SYSDA,SPACE=(8560,(50,20)), ]
[ // DCB=(RECFM=FB,LRECL=80,BLKSIZE=8560) ]
[ ]
[ Figure 75. Very temporary disk data sets ]
+----------------------------------------------------------------------------+
Temporary disk data sets created in one job step and deleted in another job step will have only the
UNIT=SYSDA, DISP, SPACE, and DCB parameters when created, and the DSN and DISP parameters when
subsequently accessed.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //ALPHA DD DISP=(NEW,PASS),UNIT=SYSDA,SPACE=(8560,(50,20)) ]
[ // DCB=(RECFM=FB,LRECL=80,BLKSIZE=8560) ]
[ ]
[ //BETA DD DSN=*.S2.ALPHA,DISP=(OLD,PASS) ]
[ ]
[ //THETA DD DSN=*.S2.ALPHA,DISP=(OLD,DELETE) ]
[ ]
[ Figure 76. Passed temporary disk data sets ]
+----------------------------------------------------------------------------+

Sorting Data Sets

PL1SORT will always be used. The STEPLIB statement for PL1SORT as well as the //SYSOUT DD SYSOUT=A
statement are required but usually present in an applicable procedure. Three equal sized SORTWK data
sets will be used and also must be present. Procedure ISOSORT will be used for separate job step
sorting.

A SORTSPA parameter must be provided to the applicable procedure to indicate the size of the block for space
allocation and the number of primary blocks in the space allocation of each sort work data set. Usually a
UNIT=SYSDA and a SPACE=(block length,primary) parameter is all that is needed in a SORTWK DD statement if a
procedure cannot be used.

+---------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //S3 EXEC ISOSORT,SORTSPA='8560,35' ]
[ //SORTIN DD DSN=*.S2.DETAIL,DISP=(OLD,DELETE) ]
[ //SORTOUT DD DISP=(NEW,PASS),UNIT=SYSDA,SPACE=(8560,(80,20)), ]
[ // DCB=(RECFM=FB,LRECL=80,BLKSIZE=8560) ]
[ ]
[ //S1 EXEC DBSTDS,MBR=ISS1527,LIB=PR15,REGION=260K,DB=A, ]
[ // DISP=SHR,PSB=PSB215,SORTSPA='8560,35' ]
[ //SORTIN DD UNIT=SYSDA,SPACE=(8560,(80,20)), ]
[ // DCB=(RECFM=FB,LRECL=80,BLKSIZE=8560) ]
[ //SORTOUT DD UNIT=SYSDA,SPACE=(8560,(80,20)), ]
[ // DCB=(RECFM=FB,LRECL=80,BLKSIZE=8560) ]
[ ]
[ //SORTWK01 DD UNIT=SYSDA,SPACE=(8560,(35,10)) ]
[ //SORTWK02 DD UNIT=SYSDA,SPACE=(8560,(35,10)) ]
[ //SORTWK03 DD UNIT=SYSDA,SPACE=(8560,(35,10)) ]
[ ]
[ Figure 77. Sorting data sets ]
+---------------------------------------------------------------------------+

Catalogued Data Sets

Catalogued disk data sets will have only the DSN and DISP parameters when retrieving or updating.
Avoid specific disk volume references by using the catalogue. Conversions to new disk volumes are
eased by using the catalogue and by not changing job decks unnecessarily.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //DEPT DD DSN=USER.RWKUN.SOURCE,DISP=SHR ]
[ //INPUT DD DSN=AM2P.CSIV.MASTER,DISP=SHR ]
[ //BSL090 DD DSN=AM3T.BSL.HISTORY.TRANS,DISP=OLD ]
[ ]
[ Figure 78. Catalogued data sets ]
+----------------------------------------------------------------------------+

Generation Data Sets

Generation data sets are a special form of catalogued data set. Several generations of a data set are kept
with the data set name varying only in the generation number. Generation data sets may be retrieved
and created using a generation number that is relative to the latest catalogued generation prior to the
start of the job. For example, the latest catalogued generation may be referenced by specifying a zero in
parentheses. The previous generation may be specified by a minus one in parentheses. The first
generation created by this job may be referenced by a plus one in parentheses, the second generation
created by a plus two, and so forth.

+---------------------------------------------+
[ DSN=AM2P.BSL.TRANS(0) ]
[ DSN=AM1P.ADABAS.CLOG(-1) ]
[ DSN=AM3T.RSLS.MAST(+1) ]
[ DSN=AM1P.FM.KEY.MASTER(+2) ]
[ ]
[ Figure 79. Generation data sets ]
+---------------------------------------------+
Before creating a generation data set, have the Data Manager build a generation data group base entry
specifying the number of generations to be kept in the catalogue. The Data Manager must also create
and catalogue a model data set label, on the same volume as the catalogue, to provide DSORG, RECFM,
LRECL, and BLKSIZE information for the generation data group.

It may be convenient for tape generation data sets to reserve a set of tapes with contiguous tape numbers. At least
five tapes should be used for this round robin. The catalogue should have several more generations than there are
tapes, even twice as many, because it may become necessary to uncatalogue some generations at times.

There must be an extra DD statement in the job step that writes a new generation. This DD statement will reference
the data set that was last written on the tape on which you are going to write the new generation. The relative
generation number would be minus nine for a set of ten tapes, or minus four for a set of five tapes. This technique will
not work for large data sets that require more than one tape volume.

+----------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //NEWMAST DD DSN=AM1P.CSIV.MAILING(+1),DISP=(NEW,CATLG,DELETE), ]
[ // UNIT=DISK,SPACE=(8460,(100,50),RLSE), ]
[ // DCB=(ISS.MODEL,RECFM=FB,LRECL=180,BLKSIZE=8460) ]
[ ]
[ //DUMMY DD DSN=AM1P.GD.MASTER(-9),DISP=SHR ]
[ //INPUT DD DSN=AM1P.GD.MASTER(0),DISP=SHR ]
[ //OUTPUT DD DSN=AM1P.GD.MASTER(+1),DISP=(NEW,CATLG,DELETE), ]
[ // UNIT=AFF=DUMMY,VOL=REF=*.DUMMY,LABEL=(1,SL), ]
[ // DCB=AM1P.GD.MASTER ]
[ ]
[ Figure 80. Disk and Tape generation data sets ]
+----------------------------------------------------------------------------+

APPENDIX A. CRIB CARD

+---------------------------------------------------------------------------+
[ 0 1 1 2 2 3 3 4 4 5 5 6 6 7 ]
[ 123456789012345678901234567890123456789012345678901234567890123456789012 ]
[ ]
[ //job name JOB (pano,room,,lines,cards,form,copies),'pgmr name',CLASS= , ]
[ // COND= ,MSGCLASS= ,PRTY= , ]
[ // TIME= ,TYPRUN= ,USER= ,PASS= ]
[ /*JOBPARM RESTART=Y ]
[ /*JOBPARM CARDS=nnnnnnn ]
[ //*UQ USERID xxxxxx,xxxxxx ]
[ //*UQ ACCOUNT xxxxxxxxxx,xxxxxxxxx ]
[ //*UQ ALLOW ]
[ /*ROUTE PRINT destination ]
[ /*MESSAGE message to operator ]
[ /*SETUP WRITE ENABLE xxxxxx,xxxxxx,xxxxxx,xxxxxx,xxxxxx,xxxxxx ]
[ //* ** job comment ]
[ //* ** more job comments ]
[ //OUTx OUTPUT CLASS= ,COPIES= ,DEFAULT= ,DEST= ,FCB= ,FORMS= ,JESDS= ]
[ // PROC ]
[ //* ** proc comment ]
[ //* ** more proc comments ]
[ //Sx EXEC PGM= ,REGION= ,COND= ,PARM= ]
[ //xxxxxxxx DD ]
[ // PEND ]
[ //* ** step comment ]
[ //* ** more step comments ]
[ //Sx EXEC proc ,parms ,REGION= ,COND= ,PARM= , parms ]
[ //xxxxxxxx DD * ]
[ SYSOUT=(,) or SYSOUT=(,),COPIES=copies or ]
[ SYSOUT=(,,forms) or SYSOUT=(,,forms),COPIES=copies ]
[ DUMMY ]
[ DSN=NULLFILE ]
[ DSN=xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx ]
[ DSN=*.ddname or DSN=*.stepname.ddname ]
[ or DSN=*.stepname.procstepname.ddname ]
[ DISP=SHR or OLD or (NEW,KEEP) or (NEW,CATLG ]
[ or (NEW,KEEP,DELETE) or (NEW,CATLG,DELETE) ]
[ or (NEW,PASS) or (OLD,PASS) or (OLD,DELETE) ]
[ UNIT=SYSDA or VIO or DISK or CART or REEL ]
[ or (CART,,DEFER) or (REEL,,DEFER) ]
[ UNIT=AFF=xxxxxxxx ]
[ VOL=SER=xxxxxx ]
[ VOL=(,RETAIN,SER=xxxxxx) ]
[ VOL=REF=dsname ]
[ VOL=REF=*.ddname or VOL=REF=*.stepname.ddname ]
[ or VOL=REF=*.stepname.procstepname.ddname ]
[ LABEL=(x,SL) or (x,NL) ]
[ SPACE=(block length,(50,20)) ]
[ SPACE=(CYL,(5,2)) ]
[ SPACE=(TRK,(100,25),RLSE) ]
[ FCB=fcb-name ]
[ DCB=dsname or DCB=*.ddname or DCB=*.stepname.ddname ]
[ or DCB=*.stepname.procstepname.ddname ]
[ DCB=(dsname,DSORG= ,RECFM= ,LRECL= ,BLKSIZE= ,DEN= ) ]
[ DEN is 4 for 6250 or 3 for 1600 BPI. ]
[ ]
[ Figure 81. Crib card ]
+---------------------------------------------------------------------------+

APPENDIX B. ESTIMATING DISK SPACE

The disk space required for a data set is dependent on things like the size of the records, the size of the
blocks, the number of blocks per track, the number of records in the data set, the data set organization,
and so forth. Primarily we will be concerned with estimating space for physical sequential data sets.

First the number of records in the data set must be estimated. Allowances must be made for data set growth or
variation.

Next a block size must be chosen. The maximum standard block size is 27998.

The goal is to use the largest block size that is less than or equal to the maximum standard block size of 27998.

Record formats of U, V or VB will use the maximum standard block size. The maximum standard block size will be
divided by the record length for fixed length records. Any fractional part of the quotient is dropped. The integer
indicates the number of records per block, which is multiplied by the record length to get the block size.

For example, if a physical sequential disk data set with variable length records up to 1774 were to be allocated, the
block size would be the maximum standard block size of 27998.

If a physical sequential data set with fixed length records of 206 were to be allocated, the maximum standard block
size of 27998 would be divided by 206. The quotient of 135.91 would be truncated to 135, multiplied by 206, giving a
block size of 27810.

The next step is to determine how many records will fit in a block. This is easy for fixed length records: it is the
number you just multiplied times the record length. The number of records per block may be harder to determine for
variable length records. Sometimes there may be several kinds of records of specific sizes, in which case it becomes
a matter of determining the typical number of records of each size. Other times it is a matter of determining the
average record size or just guessing. It is easier if the dataset has been sorted because the number of records in the
data set and the number of bytes in the data set have been printed and a simple division produces an average record
size.

The last step is determining the number of blocks needed. This is done by dividing the number of records in the data
set by the number of records per block and rounding the quotient up to an integer. You may allocate by block length
using this number.

+---------------------------------------------------------------------------+
[ 3390 ]
[ ]
[ Block Block length ]
[ Blocks length with key ]
[ per without less than ]
[ track key 56 bytes ]
[ ]
[ 1 56664 56302 ]
[ 2 *27998 27630 "Maximum Standard Block Size" ]
[ 3 18452 18090 ]
[ 4 13682 13314 ]
[ 5 10796 10434 ]
[ 6 8906 8544 ]
[ 7 7548 7186 ]
[ 8 6518 6156 ]
[ 9 5726 5358 ]
[ 10 5064 4696 ]
[ 11 4566 4198 ]
[ 12 4136 3768 ]
[ 13 3768 3406 ]
[ 14 3440 3072 ]
[ 15 3174 2806 ]
[ 16 2942 2574 ]
[ 17 2710 2342 ]
[ 18 2546 2178 ]
[ 19 2376 2014 ]
[ 20 2212 1850 ]
[ 21 2082 1714 ]
[ 22 1946 1584 ]
[ 23 1850 1482 ]
[ 24 1748 1386 ]
[ 25 1646 1284 ]
[ 26 1550 1182 ]
[ 27 1482 1120 ]
[ 28 1386 1018 ]
[ 29 1318 950 ]
[ 30 1250 888 ]
[ 31 1182 820 ]
[ 32 1154 786 ]
[ 33 1086 718 ]
[ 34 1018 656 ]
[ 35 984 622 ]
[ 36 950 588 ]
[ 37 888 520 ]
[ 38 854 486 ]
[ 39 820 458 ]
[ 40 786 424 ]
[ 41 752 390 ]
[ 42 718 356 ]
[ 43 690 322 ]
[ 44 656 288 ]
[ 45 622 254 ]
[ 46 588 226 ]
[ 48 554 192 ]
[ 49 520 158 ]
[ 50 486 124 ]
[ ]
[ Figure 82. Track capacities ]
+---------------------------------------------------------------------------+
 Table of Contents ----------------------------------------------

JCL Example

Sample JCL DD Statements

Just Examples

JCL Example
 

This is an example of a JCL job.

The small numbers are notes that will be explained later.

This set of JCL will execute the program SAMPLE1, which is shown below.

The JCL tells the system what files are to be used by the program.

The system will verify that the files are available before allowing the program to run.

There are three major parts to this set of JCL.

JOB information, the first two lines

program execution information, line 4

information about the data files, line 5 to the end.

In all the examples, TSOUSR1 is an imaginary TSO user id, a logon id, an account.

Replace it with your own user id.

Anything shown in bold print is required by JCL syntax: it’s a keyword.

Anything in regular print is a user-chosen name: you could have chosen a different name.
2 3 4 5

1 1//TSOUSR1A JOB (12345),’JOE DOKES’,

6 7 8

2 // MSGCLASS=X,CLASS=A,NOTIFY=TSOUSR1
9

3 //* SAMPLE JOB

10 11 12

4 //STEP1 EXEC PGM=SAMPLE1

13 14

5 //STEPLIB DD DSN=TSOUSR1.LOAD,DISP=SHR
15 16 17

6 //INFILE DD DSN=TSOUSR1.DATA(MEMBER),DISP=SHR
18 19

7 //OUTFILE DD SYSOUT=*
20

8 //SYSOUT DD SYSOUT=*

1 The two slashes indicate that a line is JCL

they are found in columns 1 and 2

2 A typical job used for testing programs is named after the

user id of the person who is submitting it.

A letter or number is added to the end of the user id.

3 The word JOB in this position indicates that this line is the

JOB statement which defines the job being submitted.

4 You put accounting information in this position,

in the parentheses. This is different for every company.

5 You put your name inside the apostrophes.

This appears on the job print and identifies who submitted it.

6 Message class specifies a print class for the job.

A print class refers to a specific printer, a type of printer,

or a printer in a specific location.

Find out what you are supposed to use here

and substitute it for m.

7 Class tells the system how important your job is.

Find out the proper testing job class to use here,

and substitute it for c.

8 Notify asks the system to send a message to the

TSO user id specified when the job ends,

telling if the job ended with no apparent problems,

or had serious problems.

9 This whole line is a comment. It does nothing.

The sign of a comment is //* in columns 1 - 3.

10 This line tells the system to execute the program named SAMPLE1.

STEP1 is a descriptive name that you choose.

The system uses it in messages about your job;

you use it when creating overrides for procedure JCL. (not covered here)

11 EXEC PGM= says that this is a program that the system is to execute.

12 This is the name of the program.

13 STEPLIB tells the system that the executable program is found on this

library. Find out if your company requires this.

14 DSN says that this is the name of the dataset. Dataset

is IBM’s term for a file, or for a library (a file containing

smaller files known as members)

15 INFILE is the name used in the program to refer to the file.

(see note 3 in the program)

Its only purpose is to enable the system to find the

correct JCL statement which further describes the file.

16 This DSN (Data Set Name) refers to a member in a library.

The name in parentheses is the member name you wish to use in the library
specified

17 DISP=SHR means that the dataset specified already exists,

and that the system is to go search for it, and that you don’t mind if

other jobs are using it at the same time as you.

18 OUTFILE is the name used in the program to refer to the file.

19 SYSOUT here means system output, a generic term which really

means printer class. See the note about the JOB MSGCLASS.

20 SYSOUT here refers to the file that is automatically

created by the COBOL compiler when you use the COBOL

verb DISPLAY. See note 8 in the program.

This is the COBOL program that might be used with the above JCL.

The small numbers are notes that will be explained later.

This is not a book on COBOL. For better explanations of COBOL see the

book on COBOL.

IDENTIFICATION DIVISION.

PROGRAM-ID. 'SAMPLE1' 1

ENVIRONMENT DIVISION.

INPUT-OUTPUT SECTION.

FILE-CONTROL.

SELECT IN-FILE ASSIGN INFILE. 3

4

SELECT OUT-FILE ASSIGN OUTFILE. 5

DATA DIVISION.

FILE SECTION.

FD IN-FILE 6

RECORD CONTAINS 80 CHARACTERS

RECORDING MODE F.

01 IN-FILE-RECORD PIC X(80).

FD OUT-FILE 7

RECORD CONTAINS 96 CHARACTERS

RECORDING MODE F.

01 OUT-FILE-RECORD PIC X(96).

WORKING-STORAGE SECTION.

77 EOF-FLAG PIC X(3) VALUE SPACE.

PROCEDURE DIVISION.

DISPLAY 'I AM THE SAMPLE1 PROGRAM STARTING' 8

OPEN INPUT IN-FILE 9

OPEN OUTPUT OUT-FILE 10

READ IN-FILE

AT END

DISPLAY 'EMPTY FILE'

MOVE 'EOF' TO EOF-FLAG

END-READ

MOVE IN-FILE-RECORD TO OUT-FILE-RECORD

WRITE OUT-FILE-RECORD

MOVE 'HELLO THERE' TO OUT-FILE-RECORD

WRITE OUT-FILE-RECORD

CLOSE IN-FILE OUT-FILE

DISPLAY 'I AM THE SAMPLE1 PROGRAM ENDING'

GOBACK.

1 This is the program name. With many compile procedures this name

is the name that is used in the JCL

2 The name IN-FILE is a user-chosen name for one of the files

used by this program. This name is used everywhere else in

the program to talk about the file.

3 The name INFILE is the JCL name for the file, officially called

the DDNAME. It is found only once in the program. Its only purpose

is to link the program’s file definition to the JCL’s file definition

known as the DD statement.

The system will use information from both the program and the JCL

to fully define the file. Information found in the program

will override information found in the JCL.

By default, this says that the file is not a VSAM file,

but that it is an ordinary sequential file or a member of a PDS/Library.

4 OUT-FILE. See IN-FILE.

5 OUTFILE. See INFILE.

6 This is the FD or file description for IN-FILE. It contains the following

information

Record length obtained from the pictures on the record

Record format whether the file

is F - Fixed format, all records are the same length

or V - Variable format, records may be of different lengths.

It does not say anything about blocking.

The system handles blocking.

7 OUT-FILE. See IN-FILE.

8 The COBOL DISPLAY verb creates a file with a JCL DDNAME of SYSOUT.

There is no need to further define this file in the program.

9 Opening IN-FILE for INPUT, reading, means that the file must be present.

The JCL DD statement for INFILE must reference a file that exists.

10 Opening OUT-FILE for OUTPUT, writing, means that the file is not

normally present, that the JCL DD statement for OUTFILE

will specify a file that is to be created.

If the JCL DD specifies a file that exists, it will be clobbered.

Sample JCL DD Statements

You’ll find here examples of JCL DD statements covering most of the possibilities. Any
statement not shown is rare indeed. Use the statements for existing data with files which are
opened for INPUT in the program. Use the statements for creating data with files that are opened
for OUTPUT. Your company’s requirements may be different from the generic statements
shown.

I will show you those that are practical. I’ve eliminated the ones that are unrealistic.

This is one possible hierarchical breakdown of the different types of files.

Disk

permanent, catalogued

sequential (generic) non generation dataset

generation dataset

a PDS member: acts like sequential

VSAM
temporary

sequential (generic)

Tape

permanent, catalogued

sequential (generic) non generation dataset

generation dataset

Some definitions.

Permanent Not deleted until you request it, or for generation datasets, when a dataset

exceeds the limit and is deleted by the system.

Temporary Automatically deleted by the system before the job ends.

Catalogued Everything except temporary is catalogued. Its name is placed in the

system catalog, like a directory, to make it easy to find it later.

Sequential Not VSAM. Records accessed sequentially, from beginning of the file onward.

No random access. No reading backwards.

Generation Type of sequential where the system assign a new name each time

you create a new file.

PDS member A subset of a PDS (Partitioned Data Set) or library. A file within a PDS or library.

PDS A file containing smaller files known as members.

VSAM A file type that is beyond the scope of this book.

Sample DD Statements for Existing data

In-stream data

//ddname DD *
data goes here

/*

Example:

//INFILE DD *

Maria

Christine

/*

Permanent disk, sequential non-gdg, non-pds member. Previously

Catalogued.

//ddname DD DSN=dataset-name,DISP=SHR

Example:

//INFILE DD DSN=MY.DATASET.DATA,DISP=SHR

Tape. Previously Catalogued.

//ddname DD DSN=dataset-name,DISP=OLD

Example:

//INFILE DD DSN=MY.DATASET.DATA,DISP=OLD

Permanent disk, sequential gdg. Previously Catalogued.

//ddname DD DSN=dataset-name(0),DISP=SHR

Example:

//INFILE DD DSN=MY.DATASET.DATA(0),DISP=SHR

Permanent disk, PDS member. Previously Catalogued.

//ddname DD DSN=dataset-name(member-name),DISP=SHR

Example:

//INFILE DD DSN=MY.DATASET.DATA(M1),DISP=SHR

Temporary disk. Previously Passed

//ddname DD DSN=&&dataset-name,DISP=(OLD,DELETE) or OLD,PASS

Example:

//INFILE DD DSN=&&TEMP,DISP=(OLD,DELETE)

Tape, gdg. Previously Catalogued.

//ddname DD DSN=dataset-name(0),DISP=OLD

Example:

//INFILE DD DSN=MY.DATASET.DATA(0),DISP=OLD

File is not present.

//ddname DD DUMMY,

// DCB=(LRECL=rec-len,BLKSIZE=blk-size,RECFM=rec-format)

Example:

//INFILE DD DUMMY,

// DCB=(LRECL=80,BLKSIZE=800,RECFM=FB)

Sample DD Statements for Creating data

Spooled to printer
//ddname dd SYSOUT=printer-class

Example:

//OUTFILE DD SYSOUT=*

Permanent disk, sequential non-gdg, non-pds member. Cataloguing.

//ddname DD DSN=dataset-name,DISP=(NEW,CATLG,DELETE),

// UNIT=diskunit,SPACE=(TRK,1)

Example:

//OUTFILE DD DSN=MY.DATASET.DATA,DISP=(NEW,CATLG,DELETE),

// UNIT=SYSDA,SPACE=(TRK,1)

Tape, non-gdg. Cataloguing.

//ddname DD DSN=dataset-name,DISP=(NEW,CATLG,DELETE),

// UNIT=tapeunit

//* other parameters may be required by your company

Example:

//ddname DD DSN=MY.DATASET.DATA,DISP=(NEW,CATLG,DELETE),

// UNIT=TAPE

//* other parameters may be required by your company

Permanent disk, sequential gdg. Cataloguing.

//ddname DD DSN=dataset-name(+1),DISP=(NEW,CATLG,DELETE),

// UNIT=diskunit,SPACE=(TRK,1),
// DCB=model-dscb optional at some companies

Example:

//OUTFILE DD DSN=MY.DATASET.DATA(+1),DISP=(NEW,CATLG,DELETE),

// UNIT=SYSDA,SPACE=(TRK,1),

// DCB=MODEL.DSCB optional at some companies. find out your co's

name

Permanent disk, new or existing PDS member. Existing member will

be overwritten

PDS was Previously Catalogued.

//ddname DD DSN=dataset-name(member-name),DISP=SHR

Example:

//OUTFILE DD DSN=MY.DATASET.DATA(M1),DISP=SHR

Temporary disk. Passing.

//ddname DD DSN=&&dataset-name,DISP=(NEW,PASS,DELETE),

// UNIT=diskunit,SPACE=(TRK,1)

Example:

//OUTFILE DD DSN=&&TEMP,DISP=(NEW,PASS,DELETE),

// UNIT=SYSDA,SPACE=(TRK,1)

Temporary disk. Not used again in same job. A work file.

//ddname DD UNIT=diskunit,SPACE=(TRK,1)

Example:

//OUTFILE DD UNIT=SYSDA,SPACE=(TRK,1)
Tape, gdg. Cataloguing.

//ddname DD DSN=dataset-name(+1),DISP=(NEW,CATLG,DELETE),

// UNIT=tapeunit,

// DCB=model-dscb optional at some companies

Example:

//OUTFILE DD DSN=MY.DATASET.DATA(+1),DISP=(NEW,CATLG,DELETE),

// UNIT=TAPE,

// DCB=MODEL.DSCB optional at some companies. find out your co's

name

Throw away the file.

//ddname DD DUMMY,

// DCB=(LRECL=rec-len,BLKSIZE=blk-size,RECFM=rec-format)

Example:

//OUTFILE DD DUMMY,

// DCB=(LRECL=80,BLKSIZE=800,RECFM=FB)

Just Examples
//* GDG1DEF DEFINE A GENERATION DATA GROUP

//GDG1DEF EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSIN DD *
DEFINE GDG (NAME(TSOUSR1.SAMPLE.GDG.BASE) -

LIMIT(10) NOEMPTY SCRATCH)

/*

//*GDG2MAKE ACTUALLY CREATE A NEW G. D. SET

//STEP1 EXEC PGM=IEBGENER

//SYSPRINT DD SYSOUT=*

//SYSIN DD DUMMY

//SYSUT1 DD *

JANE

MARIANNE

ANTONETTA

/*

//SYSUT2 DD DSN=TSOUSR1.SAMPLE.GDG.BASE(+1),DISP=(NEW,CATLG),

// SPACE=(TRK,1),

// DCB=model-dscb optional at some companies

//* GDG3ALT CHANGE A GENERATION DATA GROUP'S DEFINITION

//GDG3ALT EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSIN DD *
ALTER TSOUSR1.SAMPLE.GDG.BASE -

LIMIT(15)

/*

//* GDG4DEL THIS WILL DELETE ALL THE MEMBERS OF THE GROUP

//ADIOS EXEC PGM=IEFBR14

//BYEBYE DD DSN=TSOUSR1.SAMPLE.GDG.BASE,DISP=(OLD,DELETE)

//* THIS WILL REMOVE THE GD GROUP FROM THE CATALOG

//* BE SURE TO DO GDG3DEL FIRST

//GDG5DEL EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

DELETE TSOUSR1.SAMPLE.GDG.BASE GDG

/*

//* DEFINE A VSAM KSDS

//DEFKSDS EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSIN DD *
DELETE (TSOUSR1.VSAM.KSDS) CLUSTER

DEFINE CLUSTER +

NAME(TSOUSR1.VSAM.KSDS) +

CYLINDERS(1,1) +

KEYS(10,0) +

RECORDSIZE(80,80) +

INDEXED)

/*

//* DEFINE A VSAM ESDS

//DEFESDS EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

DELETE (TSOUSR1.VSAM.ESDS) CLUSTER

DEFINE CLUSTER +

NAME(TSOUSR1.VSAM.ESDS) +

CYLINDERS(1,1) +

RECORDSIZE(80,80) +

NONINDEXED)

/*

//* DEFINE A VSAM RRDS

//DEFRRDS EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*
//SYSIN DD *

DELETE (TSOUSR1.VSAM.RRDS) CLUSTER

DEFINE CLUSTER +

NAME(TSOUSR1.VSAM.RRDS) +

CYLINDERS(1,1) +

RECORDSIZE(80,80) +

NUMBERED)

/*

//* LOAD A VSAM DATASET (KSDS, ESDS, RRDS) THEN PRINT IT

//LOADVSAM EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

REPRO INFILE(INDD) OUTDATASET(TSOUSR1.VSAM.xxxx)

PRINT INDATASET(TSOUSR1.VSAM.xxxx) CHARACTER

/*

//INDD DD *

MARIA

CHRISTINE

ANIE

SUSAN

NADIA

/*
 

//* COPY ONE PDS TO ANOTHER DO NOT REPLACE LIKE-NAMED MEMBERS

//LIBCOPY EXEC PGM=IEBCOPY

//SYSPRINT DD SYSOUT=*

//SYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(3,3))

//SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(3,3))

//SYSUT4 DD UNIT=SYSDA,SPACE=(CYL,(3,3))

//INLIB DD DSN=library-containing-members,DISP=SHR

//OUTLIB DD DSN=library-to-put-members-in,DISP=SHR

//SYSIN DD *

COPY INDD=INLIB,OUTDD=OUTLIB

/*

//* OPTIONAL THINGS:

//*

//* TO COPY BUT EXCLUDE TWO MEMBERS:

//* COPY INDD=INLIB,OUTDD=OUTLIB

//* EXCLUDE MEMBER=(m1,m2)

//*

//* TO COPY AND REPLACE:

//* COPY INDD=((INLIB,R)),OUTDD=OUTLIB