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

On 12-Sep-2011 10:25 , Joe Pluta wrote:

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

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.

Agreed.

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).

A very good improvement.

There is almost no conceivable way this could fail. <<SNIP>>

I just prefer not to code to chance when there seems to be a means to be thorough without significantly more effort. That there "is almost no conceivable way this could fail" warns me [via those nagging voices in my head ;-) ] that Murphy will surely rear his ugly head at the most inopportune time, and that debugging those eventual failures will likely be difficult.

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.

Perhaps. Updating a list within the controlling program seems to me much less work and less error-prone than the maintenance required to ensure that the [first] called program in each additional submitted job is properly implemented to get the lock. I would prefer to be able to add a new submitted job without having to code actions in external entities; to instead take advantage of what is already provided by the OS. Plus if one of the jobs [added] is just a CL command versus a program, I would not even need to have a CLP to effect any locking, I would need effectively only to update the list of jobs being submitted.

Besides, I would probably implement a solution that used a CPC1221 "job submitted" message sent to the same message queue coded on each SBMJOB request. The final job would, for each job named as submitted in one message, find the corresponding "job completed" message on that same queue, with continued polling until every "job submitted" message has a pairing of "job completed"; reacting in some way to any failure versus successful completion code perhaps as an early exit from polling.

Something like the pseudo-code:

jnq=sbmrqs('call pgmx') /* sbmjob cmd('...') msgq(l/mq) */
sndmsg msgid(cpc1221) msgdta(jnq) tomsgq(l/mq)
/* above two stmts repeat for each [added] request, then: */
jnq=sbmrqs('call wrapup') /* pgm wrapup awaits cpc1221\cpf1241 pairs for above repeated paired requests, before continuing */

Regards, Chuck