× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Question! what happens if every single sbmjob job is held up in a job queue (or even just one when all others have finished)? And when the last program runs, it'll see zero in the data area. Thus executing. If you do this method, I would make sure that you add to the data area before the submit occurs. However let the submitted job handle the subtraction.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark Murphy/STAR BASE Consulting Inc.
Sent: Monday, September 12, 2011 10:48 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: How do you determine when numerous SBMJOBs have ALL finished

Of course the OP doesn't say whether the jobs must complete successfully, or just be finished running. The add 1 subtract 1 method does not work if you are just waiting for all the jobs to be gone. Say something ends abnormally, the data area will never get back to zero.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx

-----midrange-l-bounces@xxxxxxxxxxxx wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Joe Pluta
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Date: 09/12/2011 10:07AM
Subject: Re: How do you determine when numerous SBMJOBs have ALL finished

I'm not sure about this, Jim. I think Alan will have all the jobs
submitted and running simultaneously, and I don't think they necessarily
end in a specific order. I think what I would do is have each job put a
read lock on an object (data area is perhaps the easiest) when they
start. When each job ends, it will automatically release the lock. The
PROGRAMLAST job would then attempt an exclusive lock on the data area;
when it is able to acquire said lock, all jobs are done and it can continue.

The potential downside to this approach is that canceling a job removes
the lock the same as if the job completed normally. It's up to you to
decide whether, in your specific situation, that's a feature or a bug.
If you need successful completion, the data area with add one and
subtract one works quite nicely.

Joe

Assuming you do not have the advanced job scheduler so you cannot just
put a dependent job on the schedule, how about using a data queue rather
than the data area? Each job enques an entry as its first action and a
second entry as its last. The next job checks the queue with a non
destructive read to be sure its ready to run. That will leave you a
nice history, and queues are faster and, in my view, an easier thing to
manage. Your last job just needs to sit on a Dequeue wait on a keyed
queue until the proper entry appears. More efficient than the data area
check every so often.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 9/12/2011 8:36 AM, Alan Shore wrote:
Good morning all
I have one job that submits numerous (a lot) of submit jobs
Once ALL of them have finished SUCCESSFULLY, I need to submit another one (let's call it PROGRAMLAST)
I was just wondering if anyone else is doing or has done the same thing, what process was used.
I am toying with the idea of using a data area and within each SBMJOB adding 1 to this data area and checking for a particular value in the PROGRAMLAST program
This would mean that PROGRAMLAST would need to be always submitted, but waiting for a value to appear in the data area


Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

--

--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

________________________________

Notice from Bob Evans Farms, Inc: This e-mail message, including any attachments, may contain confidential information that is intended only for the person or entity to which it is addressed. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.