MAINFRAME > Tips & Techniques > Systems Management

New Job Scheduling Functions in JCL


This is the second of five articles on Job Ececution Contraol (JEC). Read the first article here.

A number of new functions are introduced in z/OS V2.2 that allow the Job Control Language (JCL) writer to have additional control over when and how jobs are scheduled for execution. These functions are available through the new SCHEDULE JCL statement.

The most significant new function in this area is Job Execution Control (JEC). It’s invoked via JOBGROUP keyword on the SCHEDULE statement. JEC is discussed in detail in other publications. However, there are other new features provided by the same SCHEDULE statement. They complement JEC, and may also be used on their own for day-to-day tasks of managing jobs in z/OS.

Functions discussed in this article are the:

  • Ability to hold a job until a specified time (HOLDUNTL)
  • Ability to tell the system that it is desirable that a particular job should start by a specified time (STARTBY). The STARTBY function is also known as deadline scheduling control.
  • Ability to run a job at the same time and on the same system as another job (WITH)

HOLDUNTL

Sometimes it may be desirable to submit a job now but have the system run it at a later time. It can be accomplished by submitting a job in a held state and have some kind of automation to release the job at a predetermined time. The HOLDUNTL function allows that directly via the JCL of a job. HOLDUNTL keyword on the new SCHEDULE statement tells the system that job must be placed in the held state at the submit time and be released at the specified time.

HOLDUNTL allows to specify the time in one of two formats.

1. Interval notation: Some number of hours and minutes from the time the job was submitted to the system, e.g., the syntax HOLDUNTL=’+03:20’ means that job must be released three hours and 20 minutes after the submission. Note that interval notation is not impacted by the change to the local time of the system. E.g., if the system enters daylight saving time, the moment when the job is released won’t be affected by that, it will still be three hours and 20 minutes after the submission.

2. Point In Time Notation: Direct specification of the time and optionally date when a job must be released, e.g., the syntax HOLDUNTL=( '13:15',’01/05/2016’) means that job must be released at 1:15 p.m. on Jan. 5, 2016. Note that point in time notation specifies the local time on the system where the job was submitted and therefore is impacted by the change to the local time of the system. E.g., if the system enters the daylight saving time, the moment when the job is released will be sooner, when the system local time reaches 1:15 p.m. Individual systems in the sysplex may have different local times. This may cause some confusion because HOLDUNTL is always managed in the local time of the system where job has been submitted. E.g., local time change on a system other than the one where the job was submitted won’t affect the time when the job is released.

A job held according to HOLDUNTL specification is placed in a special type of hold. $DJ command shows this in the following way:

$dj45,hold                                 
$HASP890 JOB(SCHTEST)   HOLD=(JOB,HOLDUNTL)

The job is in the job level HOLD state qualified by HOLDUNTL.

Release time for the job requested by the HOLDUNTL keyword can be displayed by $DJ command with HOLDUNTL keyword:

$dj45,holduntl                                      
$HASP890 JOB(SCHTEST)   HOLDUNTL=(2015.279,18:34:00)

The $DJ command always displays the time in the local time of the system where the command was issued, not the time of the system where the job was submitted or will eventually run.

When explicit “hold a job” command ($HJ) is applied to the job in this state, the job remains in the held state but it loses the special scheduling provided by the HOLDUNTL function. It’s assumed that by using the explicit command the operator has taken over the responsibility for the management of this job.

At any time the operator can manually release the job by explicit “release a job” command ($AJ).

HOLDUNTL can only be requested by using the SCHEDULE statement when the job is submitted. HOLDUNTL attribute can’t be set for a job that didn’t have it originally requested. When job has lost its HOLDUNTL status because of an explicit hold or release command, the HOLDUNTL status of the job cannot be restored. Similarly, the target release time of the job can’t be modified after it was set via JCL.

Extended Status SubSystem Interface (SSI) (SSI 80) has been updated to return appropriate information about job that had HOLDUNTL specified. This allows applications to access related information programmatically.

To correctly interpret HOLDUNTL time, SSI caller may need to know the time reference—the JESPLEX member where the job was submitted and the time offset in effect on that member. Application can obtain this information from the data returned by the Extended Status SSI and the JESPLEX information option of the JES Properties SSI (SSI 82).

STARTBY

Often a batch job has a deadline—the time by which the job must complete. The system can’t guarantee that a job finishes its execution by a certain time because there are too many variables beyond the control of the system. Also, the system can’t guarantee that a job will actually begin its execution by a certain time. However, the system can now take measures so that job has a fair chance to be the first in line to begin its execution by a specified time.

Using the STARTBY keyword on the SCHEDULE statement, user can specify an approximate time in the future when it’s desirable to start the job.

The purpose of this new function is relatively modest. The system will manage priority of the job in such a way that the job ends up near the top of the relevant job class or service class queue by the target time. In a sense, this function provides a time-controlled alternative to traditional priority aging.

STARTBY syntax is identical to the syntax of the HOLDUNTL function discussed earlier. Target time can be specified in one of the same two formats: Interval or point in time notion.

Target time for the job requested by the STARTBY keyword can be displayed by $DJ command with STARTBY keyword:

$dj57,startby
$HASP890 JOB(SCHTEST)   STARTBY=(2015.279,22:45:00)

The target time is displayed in the local time of the system where $DJ command is issued, not the time of the system where the job was submitted or the time of the system where the job will eventually run.

There’s no particular unique state for jobs under control of the STARTBY function. The simplest way to find all the jobs under STARTBY control is to use $DJ command to find all jobs that had STARTBY requested:

$dj*,startby<>0 

The system observes the progress of a job with the STARTBY target through the relevant job class or service class queue. If the system decides that a job is unlikely to meet the target time, the job’s priority is increased and the job is moved up the job queue it’s in. This process is called promotion. A rate of job’s promotion can be managed on a job class basis using a new job class attribute PROMO_RATE that determines how aggressively the job can be moved up the queue. If job class has PROMO_RATE set to 0 (which is the default value), no jobs in this class will ever be promoted; essentially STARTBY request for jobs in that job class has no effect. PROMO_RATE greater than 0 indicates how many positions a job can be moved in a single promotion cycle (one minute).

There aren’t restrictions as to which commands can be used on the jobs with STARTBY request; jobs can be held, released, changed from one job class to another, etc. Some commands may impact the current position of the job in its queue, but the system will take this into account and continue to manage the job toward the target time. Some job changes may make it harder or impossible for a system to achieve the target time—e.g., the explicit change to a job’s priority can cause the job to lose its hard-won position in the queue and start the process of promotion all over again.

It’s important to understand that this function doesn’t start the job “at” the specified time. All usual conditions that decide when a job is eligible for execution still apply to a job under control of the STARTBY function—e.g., initiator availability, system affinity considerations, etc.

When the target time is reached, the job may not begin execution if those standard conditions for a job to become selectable aren’t met. In other words, the system won’t force the job to run when the target time is reached.

If job selection criteria are satisfied and there aren’t any other eligible jobs preceding this job in a relevant job class or service class queue, the job may begin execution before the specified time. If all the conditions are right, the job may even begin execution immediately after having been submitted.

If this isn’t the desired outcome, STARTBY function can be used together with HOLDUNTL function. HOLDUNTL will make sure that job is not released until the HOLDUNTL target time. STARTBY will make sure that job is near the top of the queue by the STARTBY target time. In this way, it’s possible to specify the execution window for a job. When used together, STARTBY and HOLDUNTL must use the same syntax—either interval notation or point in time notation. Also, HOLDUNTL time must precede STARTBY target time—otherwise there would be a logical contradiction.

STARTBY function can only be requested by the SCHEDULE statement when the job is submitted. STARTBY attribute can’t be set for a job that didn’t have it originally requested. Similarly, the STARTBY target time of the job can’t be modified after it was set via JCL.

The STARTBY function isn’t available for jobs associated to a job group. I.e., the STARTBY keyword is mutually exclusive with the JOBGROUP keyword of the SCHEDULE statement.

Similarly to HOLDUNTL attribute, the Extended Status SSI (SSI 80) has been updated to return appropriate information about job that had STARTBY specified.

Alexei Pytel is an advisory software engineer working in z/OS JES2 development since 2007. He has been with IBM for 22 years.

Bruce Talbott is an advisory software engineer performing development for JES2 since 2007. His 15 years with IBM have included development and Level3 experience on IBM i in areas such as work management, local and remote workstations, and data communications.

Kevin Kathmann is an advisory software engineer working in JES2 development since 2008. He has worked more than 20 years with IBM.

Steve Simonson is a Senior Software engineer who has worked for IBM for 31 years and 8 years on JES2 as a developer.

Tom Wasik is the team leader in JES2 Design and Development at IBM Rochester. He has spent 28 years working on JES2 at IBM.



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.


comments powered by Disqus

Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Optimal Service Delivery

Overcome eight key challenges and reduce costs

MAINFRAME > TIPS & TECHNIQUES > SYSTEMS MANAGEMENT

An Accurate Benchmark Is Important

Advice for the Lazy Administrator

Steps you can take to avoid late nights and system frights.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters