Re: Monitor for existing job.

Mike:

"Wills, Mike N. \(TC\)" wrote

> I have a job that is always running. However, I want to make
sure that there
> is only one instance of this job running. How do I monitor for
this?

It seems to me to be simple... don't submit it twice. At least,
it _seems_ simple; but how to enforce it?

That is, you have a startup program that gets your monitor job
running (or you use an auto-start job entry or whatever technique
to get it going in the first place). If nothing else submits the
job, there will mostly only be a problem if the submitted job
ends abnormally or is deliberately cancelled, etc. So...

1. Create a single-threaded job queue for this function.

2. Have the submitted job submit itself to the job queue as the
first step in the job.
* Now the job will restart if the first job ends but only one
copy will run from that job queue at a time so duplicates are
restricted by OS/400 itself and jobname is irrelevant as are
locks/semaphores/mutexes/whatever. And the new job will
re-submit; this keeps the job running.

3. As the last step in the submitted job, i.e., as part of normal
termination (however you define it), remove the job that's
sitting on the job queue or place the job queue on hold or
whatever you choose.
* This lets you create some control mechanism such as a data
queue that can be used to gracefully end your job for those times
when you want to recompile or whatever.

4. As a possible safety net, the submitted job could call
QUSRJOBI (Retrieve Job Information API) for itself and check
format JOBI0300 to make sure it started from the allowed job
queue; if it started through some other route, it should end. If
you did this, this would probably be the best first step in the
job.
* This eliminates the possibility of the job being started by
some unknown process.

Come to think of it, if you use a startup program to submit the
job, it should verify that there isn't one on the job queue to
begin with, perhaps via CLRJOBQ; and you wouldn't start the
subsystem until after your monitor job was handled. You might
need to run some tests if you use an auto-start job; e.g., the
best way to hold/release the job queue or how to tell if the
running copy is the auto-start instead of a job queue copy.

In short, checking for job name will be trouble because job names
can be duplicated in numerous ways and checking for locks will be
trouble because locks can be established in numerous ways --
depending on pure bad luck, a save might get a momentary lock,
for example, and fool your job into ending prematurely.

Therefore, use a facility such as a single-threaded job queue to
keep multiples from running concurrently. That alone handles most
of the problem; the rest is simply in how fancy you want to get
by having the job itself do most of the management.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788
Fax  253-872-7904
http://www.400Security.com
___________________________________________________
The ALL NEW CS2000 from CompuServe
 Better!  Faster! More Powerful!
 250 FREE hours! Sign-on Now!
 http://www.compuserve.com/trycsrv/cs2000/webmail/