Re: OVRDBF EOFDLY, 'TERMINATE' (was system to hold my program)

[Rich Duzenbury <rduz@xxxxxxxxxxxxxxxxxxx>]

At 04:38 PM 12/3/02, you wrote:
> Rich you are right.
> In my old age I forget things.
> The problem I had with ENDJOB was keeping track of
> the job number.
Yes, it does seem to be somewhat of a problem.  Many of these kind of jobs
(for me) are interfaces, so I wound up putting them in their own
subsystems.  Ending the subsystem in a controlled manner starts ending the
jobs in a controlled manner.  The subsystems have an autostart job to fire
up the interface, so starting the whole shebang is simply done by STRSBS
FOO_INTF.  ENDSBS FOO_INTF OPTION(*CNTRLS) DELAY(60) drops everything
nicely.  I seem to recall that we set delay to be about two times the
EOFDLY,  to make sure the EOFDLY job had a chance to end.

The only hair in the soup is that sometimes I want to be sure the interface
is completely stopped before some other action happens.  Turns out that you
can do the ENDSBS in a loop (with a short DLYJOB).  One message is
signalled indicating that the end of the subsystem is in progress.  Another
different message is signalled when the subsystem is no longer active.

> To prevent multiple 'Terminations' I do one of 2 things.
> 1. I check for locks on a data area. This requires the
> active job to apply a lock on a data area.
> 2. I have a CHKJOB command that tells me if the job
> is active or on a jobq.  This second method is also useful
> to prevent multiple 'Starts' as it detects jobs in JOBQs.
This seems like another good way to get things to work.  I like the idea of
using operating system based locking because it's nice and reliable.


> I think I got the original code from MC Computing Magazine
> by Ernie Malaga and modified it. (WRKJOBS)
> I would post the code here if someone can clarify the
> copyright issues.
Frank, I don't know a thing about the MC Copyright issues.