6.  Examples

 

 

To help you feel more comfortable using PJS, this chapter presents several common scheduling problems and solutions:

 

·         Section 6.1, How to Run a One‑Time Job, shows how to issue a job request for a job that PJS will submit once.  Minimal specifications and accepted defaults are discussed.

 

·         Section 6.2, How to Run a Daily Job, shows how to issue a job request for a job that PJS will submit every day.  Frequency option issues are discussed.

 

·         Section 6.3, How to Run a Job on the First Tuesday of Each Month, shows how to specify a PJS calendar and specify the calendar in a job request.

 

·         Section 6.4, How to Run a Job That Depends on Another Job, shows how an event can solve certain types of scheduling problems.  Job dependency factors and the PJSPOST JCL step are discussed.

 

·         Section 6.5, How to Set Up Several Dependent Jobs, shows how to use events in an environment where several job dependencies exist.

 

·         Section 6.6, How to Run a Job Whenever CICS Terminates, shows how you can use an event on the system level.

 

·         Section 6.7, How to Run a Weekly Job After a Daily Job, shows how non‑preposted events can be used to solve certain types of scheduling problems.  The rest of this chapter assumes that events are preposted.

 

·         Section 6.8, How to Run a Job After a Manual Operation, shows how PJS/TSO commands or PJS/ISPF panels can be used to post an event. The rest of this chapter assumes that events are posted by the PJSPOST JCL step.

 

·         Section 6.9, How to Reset an Event, shows how PJS/TSO commands or PJS/ISPF panels can be used to reset an event.

 

·         Section 6.10, How to Enable a Failed Job Request, shows how you can deal with a job request that specifies a job that PJS cannot submit.

 

If you are new to PJS, it's a good idea to read this chapter from start to finish.  Many of the examples assume that you know how to use PJS features illustrated in previous examples.  Later, as you become familiar with PJS, you will be able to refer to the specific examples you need.

 

PJS/TSO commands are used in the examples.  All PJS/TSO commands can be replicated on PJS/ISPF panels.

 

 

6.1 How to Run a One‑Time Job

 

Suppose you want to submit a job at 3:00 AM tomorrow morning.  You can use the following command to create the job request:

 

 

 

The new job request has the following characteristics:

 

·         The JCL data set name is QUAL.TSO.DATA(MYJOB).  The enclosing quotes make this a fully qualified data set name.

 

·         The date of submission is one day added to the current system date.  The date is specified as a relative date.

 

·         The time of submission is 3:00 AM, using an absolute time specification.  Because a 24‑hour clock is assumed, you can specify this value as 3:00 or 3:00AM:  PJS accepts either specification.

 

·         No frequency option was specified, so PJS will submit the job only once.

 

·         Because the job is only submitted once, you don't have to specify an End Date or End Time.

 

·         Assuming that your site gives you a choice, a copy of job JCL was not saved on the PJS JCL Spool.  At submission, the JCL is submitted from the JCL Data Set.

 

·         No Time Window was specified, so there is no actual deadline for job submission.  If the system is down at time of submission, the job will be submitted after the system comes up and the PJS System Task is started.

 

·         No events or job request events are specified.

 

·         The ENABLED default is accepted.  The PJS System Task puts the new job request in WAIT status.

 

 

6.2 How to Run a Daily Job

 

Suppose you want to submit a job every day at 6:00 AM  You can use the following command to create the job request:

 

 

 

The new job request has the following characteristics:

 

• The JCL data set name is QUAL.TSO.DATA(MYJOB).  The enclosing quotes make this a fully qualified data set name.

 

• Assuming that your site gives you a choice, the SAVE parameter causes PJS create a copy of the job JCL in the JCL data set, and put the copy on the PJS JCL Spool.  At submission, the JCL is submitted from the PJS JCL Spool.

 

• The time of submission is 6:00 AM, using an absolute time specification.

 

• The DAILY frequency option is specified, so PJS will submit the job every day.

 

• No Start Date was specified, so the current system date is assumed.  If the system date is today's date, and if you added the job request before 6:00 AM, the job will first be submitted at 6:00 AM today.  If it's after 6:00 AM, the job will first be submitted at 6:00 AM tomorrow.

 

• No End Date or End Time is specified.  If you don't delete the job request, or use PJREQMOD to change the job submission characteristics, the job will run every day at 6:00 AM for as long as you have PJS running on the system.

 

• No Time Window was specified, so there is no actual deadline for job submission.  If the system is down at time of submission, the job will be submitted after the system comes up and the PJS System Task is started.  If the system is down for more than a day, PJS will miss at least one job submission.

 

• No events or job request events are specified.

 

• The ENABLED default is accepted.  The PJS System Task puts the new job request in WAIT status.

 

 

6.3 How to Run a Job on the First Tuesday of Each Month

 

Suppose you want PJS to submit a job on the first Tuesday of every month in 2003 at 6:00 PM.  From MINUTES through YEARS, none of the periodic frequency options give you a way to specify the first Tuesday in every month.  However, you can regard the first Tuesday of every month is an arbitrary set of dates.  You can select arbitrary sets of dates in a PJS calendar, which must be specified before you can issue a job request that uses the calendar.

 

You can use the following command to create the PJS calendar:

 

 

 

The created calendar has the following characteristics:

 

• The name of the calendar is FIRSTTUE.  The owner‑ID will take the default value, which is your TSO user‑ID.

 

• The DATES parameter is inclusive, so the specified dates will be selected on the PJS calendar.

 

After the calendar has been created, you can specify the calendar as the frequency option in a PJS job request:

 

 

 

PJS will now submit the job at 6:00 PM on each of the dates specified in the calendar.

 

 

6.4 How to Run a Job That Depends on Another Job

 

Suppose you want PJS to submit two jobs.  JOB1 is to be submitted at 6:00 PM today, and JOB2 should be submitted after JOB1 finishes execution.  You can approach this problem in a couple of ways:

 

• You can guess when JOB1 will stop executing, and specify an appropriate Start Time value for JOB2.  However, you may underestimate the amount of time JOB1 will need.  JOB1 submission may be delayed, in which case JOB2 may execute at the same time as JOB1.  Making JOB2 job submission time‑specific may cause problems.

 

• You can think of "completion of execution" as an event.  An event is not time‑specific.

 

First, make JOB1 post an event by adding the following step to the end of its JCL statements:

 

 

 

The new job step has the following characteristics:

 

• The stepname is PJSPOST.  Any validly formed name will be accepted.

 

• The PGM=PJSPOST statement is required, as is the PARM statement.

 

• The PARM statement must specify a full event‑ID. In this case, your owner‑ID is USER01 and the event‑name is JOB1END.

 

Next, create a job request to run JOB1:

 

 

 

Finally, create a job request to run JOB2:

 

 

 

PJS will submit JOB1 at 6:00 PM.  JOB2 is also scheduled to run at 6:00 PM, but it also has an event (JOB1END) that must be posted before it will be submitted.  This event is posted by the last step of JOB1.  So when JOB1 completes, and the last step is run, the PJSPOST batch program will post the JOB1END event.  PJS can then submit JOB2.

 

 

6.5 How to Set Up Several Dependent Jobs

 

Suppose you want to submit six jobs, and suppose you have the following constraints:

 

1. JOB1 does not depend on other jobs, and is to be submitted at 10:00 PM.

 

2. JOB2 does not depend on other jobs, and is to be submitted at 12:00 AM.

 

3. JOB3 depends on JOB1, and can be submitted only after JOB1 finishes.

 

4. JOB4 depends on JOB1 and JOB2, and cannot be submitted before 2:00 AM.

 

5. JOB5 depends on JOB2, and cannot be submitted before 1:00 AM.

 

6. JOB6 depends on JOB3, JOB4, and JOB5, and can be submitted as soon as all are finished.

 

First, make all of the jobs post an event by adding the following step to the end of each job:

 

 

 

In each job, n is the number of the job.  (The actual job names and event names are not significant.  These names are used for clarity.)

 

After all six jobs are modified, issue a job request for each job:

 

 

 

After creating these job requests:

 

• JOB1 is scheduled to run at 10:00 PM tonight, with no dependencies.

 

• JOB2 is scheduled to run at 12:00 AM tomorrow morning (midnight tonight), with no dependencies.

 

• JOB3 is scheduled to run at 10:00 PM tonight (the same time as JOB1), but will not actually run until JOB1 posts the event JOB1END as it finishes.

 

• JOB4 is scheduled to run at 2:00 AM tomorrow morning, but will wait until both JOB1 posts the event JOB1END, and JOB2 posts the event JOB2END.  If both jobs finish before 2:00 AM, JOB4 will wait and run at its scheduled run time.  Otherwise it will wait for the jobs to complete.

 

• JOB5 is scheduled to run at 1:00 AM tomorrow morning, and will wait until JOB2 posts the event JOB2END.  If JOB2 finishes before 1:00 AM, JOB5 will wait and run at its scheduled run time.  Otherwise it will wait for JOB2 to complete.

 

• JOB6 is scheduled to run at 2:00 AM tomorrow morning (the same start time as it’s latest predecessor job, JOB4), but will wait until JOB3, JOB4, and JOB5 post the events JOB3END, JOB4END, and JOB5END, respectively.  You don’t need to specifically wait for JOB1 and JOB2, because JOB4 (as well as JOB3 and JOB5) is already waiting for them.  But there would be no harm in specifying those events as well.

 

 

6.6 How to Run a Job Whenever CICS Terminates

 

Suppose you want PJS to submit a job whenever CICS terminates.  You can consider CICS termination an event, just you do with a batch job.  However, this will probably require the assistance of the CICS system programmer, and may also require the assistance of the PJS administrator.

 

Add the PJSPOST job step to the end of the CICS Task (this will probably have to be done by the CICS system programmer):

 

 

 

Note that the event‑ID uses an owner‑ID of CICSA. (The exact name is not important.)  This name is used instead of your own TSO user-ID so that others can also use the same event.

 

Also, the jobstep includes the COND=EVEN JCL parameter to ensure that the post runs even if CICS abends.  You may wish to consider if this is appropriate for your application.

 

Then create the job request:

 

 

 

This new job request is scheduled to run once a minute, starting just one minute from now!  But, since the job request also waits on an event, it has the effect of running the job request whenever the event is posted.  The time of day is not significant.

 

When you specify the event‑ID, you must include the owner‑ID (CICSA), since it is different than your TSO user-ID.  To do this you may need your PJS site administrator to change the site security to allow you to do this.  Also the site security policy must allow the CICS Task to post the PJS event.

 

 

6.7 How to Run a Weekly Job After a Daily Job

 

Suppose you want to submit two jobs.  JOB1 is to be submitted Monday through Friday at 6:00 PM  JOB2 is to be submitted only on Friday and only after JOB1 finishes.

 

First, make JOB1 post an event by adding the following step to the end of its JCL statements:

 

 

 

Next, issue a job request for JOB1:

 

 

 

Finally, issue a job request for JOB2.

 

 

 

JOB1 is scheduled to run every Monday through Friday at 6:00 PM.  JOB2 is scheduled to run every Friday, also at 6:00 PM

 

The EVENT parameter is used to require that JOB2 wait for JOB1 to finish.  However, JOB1 runs and posts the event every Monday, Tuesday, Wednesday, and Thursday, as well as Friday.  Without the /NOPREPOST option, JOB2 will run on Friday at 6:00 PM, without waiting for JOB1 can finish, because the event was posted earlier in the week.  The event normally is not reset in the job request for JOB2 until JOB2 is submitted.

 

The /NOPREPOST option for event posting means that PJS cannot post the job request event before the Next Run Date and Time. Since JOB2 is not scheduled to run until Friday at 6:00 PM, the job request event will not posted when JOB1 runs on Monday through Thursday.  However, when JOB1 runs on Friday (which will be after the 6:00 PM scheduled run time for JOB2) the job request event will be posted, and JOB2 will be submitted.

 

 

6.8 How to Run a Job After a Manual Operation

 

Suppose that you, USER01, want to submit a long job after your colleague, USER02, leaves for the day.  You can define an event that USER02 can post before leaving.

 

Assuming you are authorized, you can use the following command to create the job request:

 

 

 

Then, before leaving, USER02 can use the following command to post the event:

 

 

 

The event will be posted and the job will be submitted at 5:00 PM.  If it is already past 5:00 PM the job will be submitted (almost) immediately.

 

 

6.9 How to Reset an Event

 

Suppose that you, USER01, want to submit a long job after your colleague, USER02, leaves for the day.  You can use the procedure detailed in Section 6.8.

 

First, you can issue the following job request:

 

 

 

Then, USER02 can post the event:

 

 

 

Suppose that USER02 returns to the office before the 5:00 PM runtime for the job.  The condition for job submission was USER02's absence.  USER02, realizing this, can issue the following command:

 

 

 

The event is reset, and posting is removed from the event and related job request events.  If this command is issued before PJS submits the job, the job is not submitted.

 

 

6.10 How to Enable a Failed Job Request

 

Suppose you issue two job requests, and make JOB2 dependent on JOB1.  Now, suppose that the job JCL for JOB2 was accidentally deleted after the job requests were added but before the jobs were submitted.

 

When JOB1 completes, the USER01.JOB1END event is posted.  The PJS System task then tries to submit JOB2, but fails.  The PJS System Task sends an error message to the user.

 

Assuming that the request‑ID is USER01.002, you can use the following command to check job request status:

 

 

 

This command generates the following display:

 

 

 

You see that the job request was placed in ERROR status.  The error messages and a little bit of exploration reveal the cause of submission failure.  To fix the job request, you can:

 

• Put JCL in the JCL data set.

 

• Issue the PJREQMOD command and specify a new JCL data set in the JCLDSN parameter.

 

After you fix the problem, you need to enable the job request:

 

 

 

The job request status will change to WAIT.  In this case, if nothing else is changed, the job will be submitted (almost) immediately, since the Next Run Date and Time is in the past and all job request events are still posted.  If this is not appropriate then the STARTDATE and STARTTIME parameters should be used to change the Next Run Date and Time, or the RESETEVENTS parameter should be used to reset the job request events before enabling the job request.