Modify this JCL sample to create a new data set, using the IBM® program IEFBR14.

//jobname  JOB  (start of JOB statement parameters)
//stepname EXEC PGM=IEFBR14  
//ddname   DD   DSN=dsname,
//     DISP=(NEW,CATLG),   
//     UNIT=SYSALLDA,SPACE=(TRK,1)
/*

1. Required: Modify the JOB statement to uniquely identify your job and to provide additional company-specific information.

   //jobname  JOB  (start of JOB statement parameters)

   1. Replace jobname with a unique name to identify this job. A common convention is to use your TSO logon ID followed by a number (for example: ZUSER031).
      Syntax rules for the name field are:

      • The name must begin in column 3 of the JCL statement.
      • The name can be one through eight characters in length.
      • The first character in the name must be an alphabetic character (the letters A through Z) or a special character (the symbols #, @, and $).
      • The remaining characters can be alphanumeric (the letters A through Z and numbers 0 through 9) or special characters.
      • Blank spaces cannot be included in a name.
   2. Replace (start of JOB statement parameters) with parameters and values that conform to guidelines set at your company.
2. Required: Modify the EXEC statement to uniquely identify the job step and the utility to be run.

   //stepname EXEC PGM=IEFBR14 

   1. Replace stepname with a unique name to identify this step. Syntax rules for stepname are identical to those listed for jobname. Aside from changing the step name, no further changes are required.
3. Required: Modify this input DD statement to define the data set to be created.

   //ddname   DD   DSN=dsname,
   //     DISP=(NEW,CATLG),   
   //     UNIT=SYSALLDA,SPACE=(TRK,1)

   1. Replace ddname with a unique name for this JCL DD statement; this label in the name field of a DD statement is known as a ddname. Syntax rules for ddnames are identical to those listed for job and step names on JOB and EXEC statements.
   2. Replace dsname with the name that you want to use for your new data set. Naming and syntax rules for DSN parameter values vary depending on the type of data set you are identifying. If you want to create a permanent data set to store your own collection of JCL samples, you can specify a qualified name that starts with your TSO logon ID; for example: DSN=ZUSER03.JCL
   3. Change the value for the DISP parameter, if necessary. The DISP parameter tells the system about the status of your data set and what to do with it when your job ends, either normally or abnormally. As coded in this sample, the status subparameter value NEW tells the system to create your data set. Only one subparameter value for job-end processing is specified, so the system will add an entry in the system or user catalog (CATLG), whether the job step ends normally or abnormally.

      If you want to understand more about disposition processing, refer to the summary of disposition processing in z/OS MVS JCL Reference (SA22-7597), in the DD statement topic for the DISP parameter.

   4. Change or replace the UNIT parameter, if necessary. Coding UNIT=SYSALLDA tells z/OS to find the most appropriate storage unit for your new data set. You may use this parameter and value to define either an SMS-managed or non-SMS-managed data set. If you are using SMS, however, you may replace the UNIT parameter with the STORCLAS parameter and a storage class name that your company uses.
   5. Change or replace the SPACE parameter, if necessary. Coding SPACE=(TRK,1) tells z/OS to do one of the following:
      • For a non-SMS-managed data set, allocate one track of space for your new data set.
      • For an SMS-managed data set, override the space attributes specified through the default data class. If you are defining an SMS-managed data set, you have these choices:
        • Leave the SPACE parameter as shown in the sample.
        • Replace the SPACE parameter value to specify different space attributes.
        • Replace the SPACE parameter and its value with a DATACLAS parameter and data class name that your company uses.
        • Remove the SPACE parameter and its value to accept the space attributes defined in the default data class.
4. Optional: Check for JCL syntax errors by submitting the job with TYPRUN=SCAN on the JOB statement.

   //jobname  JOB  (start of JOB statement parameters),TYPRUN=SCAN

   Using TYPRUN=SCAN does not catch all possible JCL errors, but it's a good start to ensuring that your job will run. TYPRUN=SCAN requests that the system scan this job's JCL for syntax errors, without executing the job or allocating devices. This parameter asks the system to check for:
   • Spelling of parameters and some subparameters that is not correct.
   • Characters that are not correct.
   • Unbalanced parentheses.
   • Misplaced positional parameters on some statements.
   • In a JES3 system only, parameter value errors or excessive parameters.
   • Incorrect syntax on JCL statements in cataloged procedures invoked by any scanned EXEC statements.

   You might still encounter JCL errors after using TYPRUN=SCAN, because this request checks the JCL only through the converter, not the interpreter. The difference is that the converter basically checks all expressions to the left of an equal sign plus some expressions to the right of an equal sign (and issues messages that start with IEFC), while the interpreter checks all expressions to the right of an equal sign (and issues messages that start with IEF). For example, a data set name containing a qualifier that exceeds eight characters, such as DSN=L9755TB.JCL.TEST19970103 would not be flagged by TYPRUN=SCAN but would be caught by the interpreter.

5. Required: Remove TYPRUN=SCAN from the JOB statement and submit the job. The system response is:

   JOB jobname(jobnumber) SUBMITTED
   ***