Using IEFJOBS to define started tasks

If MSTJCLxx contains a DD named IEFJOBS, the source JCL for a started task can be placed in one of the data sets within the IEFJOBS concatenation. Doing so allows jobs and the procedures they invoke to have the same name. These jobs can contain the minimum set of JCL needed to define the job level characteristics (for example, JOB statements, JCLLIB, and JECL), and then either invoke an existing procedure or use the INCLUDE keyword to invoke the desired set of JCL.

Use a name that allows you to quickly identify the data set. For example, the entry in MSTJCLxx could appear as:

//IEFJOBS  DD DSN=SYS1.STCJOBS,DISP=SHR

For this example, you can put the source JCL for the started tasks in the SYS1.STCJOBS data set.

Consider these reasons for using IEFJOBS to define started tasks:

MVS™ and other products ship procedures placed in procedure libraries. Your modifications to the members that contain your source JCL for started tasks might be lost if a new version of the procedure is received and placed into the procedure library.
Defining data sets for IEFJOBS allows you to have the member name containing the source JCL invoke a procedure of the same name. For example, member name DUMPCHK in the IEFJOBS data set SYS1.STCJOBS is a job that invokes procedure DUMPCHK in SYS1.PROCLIB. This minimizes the effect on commands that might be issued from a variety of sources, and allows job parameters to be added transparently.
Note: Do not attempt to change the IEESYSAS procedure to a started job, or place a member named IEESYSAS in the IEFJOBS data set concatenation. IEESYSAS is reserved for use by the system for starting address spaces.
Maintaining procedures in procedure libraries and jobs in an IEFJOBS data set can reduce potential confusion. For example, if you place a job in a procedure library, a user could mistakenly assume that the job is a procedure and invoke it as a procedure within a job; a job invoked as a procedure within a job fails.