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. 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.
Regards, Chuck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.