JES2 initialization statements give the system programmer a single point of control to define an installation's policies regarding the degree of control users have over their jobs. If users were allowed to define their own job classes and priorities, users would tend to define their own jobs as top priority, resulting in no effective priority classifications. Although a user can use job control language (JCL) options to define a priority, a JES2 initialization statement (defined by the system programmer) determines whether JES2 acknowledges that priority.

This same type of control (validation of user specification and provision for a default) extends to many JCL definitions. For example, JES2 can specify the maximum time a particular job is allowed to run, the storage a job may consume, the number of copies of output a job can print, and the type of paper (form) on which the output prints.

Users can override system and JES2 specifications at three distinct levels: user-specified JCL, installation-specified JCL, and JCL defaults. The hierarchy of control is as follows, from highest to lowest priority:

1. JCL specification on a user job.

   This user JCL overrides:

2. JCL default, which z/OS® uses if there is no user definition or the user specification is disallowed.

   This JCL default overrides:

3. JES2 default, which z/OS uses if:
   1. No JCL default exists
   2. The user specification is disallowed or undefined
   3. The JCL default definition is not supported.

Note that the user can override the JCL defaults and the JCL defaults can override the JES2 specifications, but the ability to override is either permitted or disallowed by specifications that only the system programmer can control. This structure thereby puts the system control in the hands of the system programmer, not the individual user who is submitting the job. JES2 becomes the base for input and output specifications that can then be overridden, as allowed by your installation, through the JCL and job submitter.