RE: SBMJOB query

Holy smokes I learn a lot from Scott's posts.  Thank you for the effort
you put into them.

Joe Cox
Director Information Systems
MSU Foundation Inc.
1501 S 11th Avenue
Bozeman, MT  59717
(406) 994-2416
joecox@xxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, September 02, 2005 11:24 AM
To: Srinivasan, Sriram
Cc: midrange-l@xxxxxxxxxxxx
Subject: Re: SBMJOB query


Hello Sriram,

Since your question has nothing to do with RPG, I'm replying to the 
MIDRANGE-L mailing list, but I've CC:ed you directly in case you're not 
subscribed to it.

> I have a cl prog with multiple sbmjob commands, where in I need to
make sure
> that one job on the list is completed successfully and run the other
job.
> Please anybody can guide on that.

There are several solutions, the best one will depend on your exact 
requirements:

a) A job queue can be created so that only one job will be run at a
time. 
When you submit jobs to the queue, it'll queue them all up, but it won't

start the 2nd one until the first one has completed.  And it won't start

the 3rd one until the 2nd one has completed, and so on...  This is the 
traditional solution, and the one that I'd recommend for you at this 
point.

b) When you use SBMJOB, there's a MSGQ parameter that specifies where 
messages about the job starting up, completing, and any error messages
get 
sent to.  You can easily set this message queue to something that you've

created for this application, and write a program that submits one job, 
waits on the message queue for the completion message, then submits 
another job, etc.  The advantage to this approach is that you can 
determine if the job was successful, or whether it ended in error, and
you 
can use that to determine whether the next job should be submitted or
not.

c) If you want all of the jobs to be submitted and running at once, and
to 
only stop and wait if they absolutely HAVE TO wait, then you can use 
object locks.  Have the first program that needs to use a particular
file 
allocate that file (with the ALCOBJ command) and have the other ones
wait 
until that object is available (also using ALCOBJ).  That way, any 
preliminary work can be done, and they can stop and wait only when they 
need the file.  This can improve performance in some circumstances, but 
does require careful planning.

d) There's also an API that can be used to check the status of a job.
When 
a job is submitted, it sends you back a message that contains the job 
name/user/number of the newly created job.  You can take this info and 
call an API to check the status of the job.  You can do that
periodically 
if you want to verify that a job completed successfully.

e) Data queues make a great way to synchronize activity between jobs as 
well. Jobs can use data queues to send messages to each other, and to
wait 
for messages to appear. When a job starts, it can send a message to the 
queue that says "I've started".  When it completes a particular task,
such 
as updating a file, it can send a message saying "File Updated".  Other 
jobs can wait on these messages.  It can also send a message when it 
completes, and you can wait for that message so that you know that the
job 
is done.

So there are tons of possibilities for what you want to do, and most of 
them are pretty simple.

Good luck