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

Thank goodness I use an advance job scheduler with job dependency support!

Kenneth
Kenneth E. Graap
http://www.linkedin.com/in/kennethgraap


-----Original Message-----
From:midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Monday, September 12, 2011 2:33 PM
To: Midrange Systems Technical Discussion
Subject: Re: How do you determine when numerous SBMJOBs have ALL finished

On 9/12/2011 2:09 PM, CRPence wrote:

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

Eh, the delay in the submitted job is a belt and suspenders approach.
If I put a two minute DLYJOB in the monitor program, I would be able to forego the delays in any of the jobs and indeed wouldn't even need the last job to be the submitter. Any system activity that prevents a job from starting for two minutes is going to need more attention than my little monitor. But regardless, my approach has an Achilles heel, however miniscule, that the message-based approach avoids. Is it worth the cost?

> 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 */
>

And at that point, you don't really need the initial message to be CPC1221; it could be whatever message you choose. And now you're designing a lightweight dispatcher, which is probably not a bad idea, but whereas you have the voice in your head that nags about Murphy and that voice whispers to me as well, I have another voice equally as loud that really, really pounds me about over-engineering.

So while the message queue option is admittedly more bullet-proof and more extendable than my simple lock-wait mechanism, it falls into the realm of KISS vs. Murphy. Always an interested balancing act.

Joe

--