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

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.