Re: How do you determine when numerous SBMJOBs have ALL finished

On 9/12/2011 11:16 AM, CRPence wrote:

On 12-Sep-2011 08:00 , Joe Pluta wrote:

<<SNIP>> You wait until all the jobs finish via the exclusive lock,
and then check the data area. If it's zero, all jobs finished
successfully. If not, then at least one job failed (in fact, the
number in the data area tells you how many failed). Simple!

Since the exclusive lock might be obtained during any transitional
phases of the job start activity, some polling would still be required
for a complete solution.

If you try to handle every conceivable possibility, no simple solution works (in my opinion, submitting a list of jobs to a message queue handling job is not a simple solution). But a little common sense would make it work for a specific situation.

In reality, for the vast majority of cases, the original as posted would work fine. A simple tweak makes it NEARLY invincible, without a lot of code: the last job in the list submits the job that acquires the exclusive lock (after it gets its own read lock). There is almost no conceivable way this could fail. It would require job 17 to actually start and end while other submitted jobs have not even started. Even in the case of a single-threaded queue, since the last job submits the exclusive locking job the architecture still holds.

I'm sure you I could come up with some scenario in which 17 jobs are submitted, and job 17 starts AND ends before job 1 even gets enough time slice to perform a lock, but the probability of such a scenario occurring is vanishingly small (at least without some serious fat-fingering of things like classes and run priorities). And even then I could fix it: each job before it starts does the non-exclusive lock then performs a DLYJOB for five seconds.

Most obviously, awaiting the first job(s) to
start and obtain the shared lock, although ideally awaiting all jobs
having actually started and obtained the shared lock. Imagine also if
the effect of the job start\complete activity was the same as if,
perhaps because, the job queue being utilized were single-threaded; a
conclusion that all others had failed is not a desirable outcome.

I would just use the MSGQ() and job completion messages as
specifically provided to detect when and how the submitted jobs
complete. I would probably pass the list of jobs [and the message queue
to monitor] as input to the final job, submitting that job without
delay, allowing that final job to do the polling awaiting the completion
messages for that list of jobs; allowing for the submitter to continue
doing something other than the polling for completions.

I think it's a matter of personal style. Passing a list requires maintaining that list every time a new job is ended or a job name changes. Locking a data area works pretty well for me.

Joe