On Sun, Oct 5, 2014 at 4:00 PM, Carel Teijgeler <coteijgeler@xxxxxxxxx> wrote:
Is it not simpler to SBMJOB the progamme in STATUS(*HOLD).
If there are no conditions to ENDJOB, you can RLSJOB. If the ENFJOB is done
while the job is active you may have to reverse all transactions already
made (Commitment control).
I appreciate the thoughts, but it would not be simpler to RLSJOB
because then I would have to have some method of scheduling the RLSJOB
to execute at a specified future date. Under normal conditions, the
RLSJOB would need to execute on that date, but under the cancel
conditions, I'd have to have a way to cancel the RLSJOB. So I would
be right back where I started, just with one extra layer.
As for not ending a job while it's running, I have a few options
available to me. The simplest would be to execute ENDJOB with a very
high controlled delay (like, say, an hour). It's not fool-proof, but
if the job is running for more than 20 or 30 minutes, something is
already wrong. And under normal circumstances, the job will not have
started yet, so it will end immediately with no ill consequences.
More robust would be to include logic in the "job canceler" program
that does some checks before executing the ENDJOB. The most reliable
way to check would be to use APIs to get the status of the job in
question to see if it's actually running. (Or at least I haven't
heard of a way to get the job status other than through APIs, or
kludgy DSPJOB spool-parsing, for those allergic to system APIs.) In
practice, for my situation, it should be reliable enough simply to
check whether we've reached the originally scheduled run time for the
submitted job. (The only way this would be wrong is if someone else
or some other process changed the scheduled run time so that it's
running earlier than expected.) A combination of checking the current
datetime against the scheduled datetime and a long controlled delay
should be more than robust enough for my purposes.
(I am not allergic to APIs, but I can't say I look forward to using
them either, and I don't yet have convenient wrappers for what I would
need.)
John Y.
midrange.com
