On Nov 25, 11:43am, Seamus Browne wrote:
...
> Without going into too much detail ...
> I would like to specify in the JWEEKDAY job that
> JOB1 should terminate before JOB2 be allowed to start
> and son on for JOB3 and JOB4 etc.
>
> These are the options I have considered:
> 1. Figure out how long JOB1 takes to run and put an AT on
> on JOB2 making it not start till the JOB1 has finished.
> I don't like this option because the duration of any job is not really fixed
> and will vary with the size of my database.

IMO, not a good idea as job times can and will vary -- sometimes by a
substantial amount (data dependencies, etc.)

> 2. Daisy-chain all the jobs from one to another so that
> JOB1 would finish by streaming JOB2.
> JOB2 would finish by streaming JOB3  etc ...

This is a common method, but complicated by the fact that there can be N
other "permanent" jobs that need to run (i.e. JINETD).  And, sometimes N
is not a constant.

> Don't like that either because
> a) I would like to be able to add or delete jobs to the JWEEKDAY
> job without having to care about which order they are in and
> b) if any job in the chain flushed for any reason,
> the remaining jobs in the chain would be lost.

Good points.

> 3. Last option was to set the JOBLIMIT to 4 so as to allow
...
> Sounds OK but I can't get the LIMIT command to work inside a job.
> I get error messages telling me to use the ALLOW command.

Yes.  You need to ALLOW either @.@ (global) or specific users the LIMIT
command.  Capabilities do not matter.

I think you have a perfect reason to use User Defined Job Queues (previously
called Multiple Job Queues).  They are available in 6.0 FOS and are
documented on jazz and the 6.0 Communicator.  UDJQs allow you to define a
'weekly' job queue with its job limit set to 1.  Your other permanent jobs
can reside in the default system job queue or a different UDJQ with its
own separate limit set.  This doesn't solve the problem of inserting a
new job in the middle, however, nor do the suggestions about using the
PAUSE-for-a -job enhancement suggested by others.  A possible solution
would be to have a master file that contains the job file names to be
streamed in order.  A master job could read this file and stream each name
in it.  This master job could PAUSE until the just-streamed job (defined
in the HPLASTJOB CI variable) completes, or all of the job files could
be streamed into the same job queue with the limit set to 1.  It would then
be easy to add/delete entries.


regards,
Jeff Vance, CSY

--