RE: Monitor for existing job.

Hi

I've tried both the data in a data area method and the practise of locking
an object for controlling never ending processes. I've never been happy
with the idea of relying on the contents of something as there are too many
ways, in my opinion, that it can be left in an incorrect state. I
originally started using locks to test whether the data area I was using
was correct and decided at that point that using the contents was just
getting in the way if I had to check that it was correct anyway. Using
locks always left me with what I considered a heap of ugly and convoluted
code. (of course this might be helped if MONMSG had an ELSE statement or a
NOTMONMSG function was available but that ain't gonna happen)

I have since reverted to something similar to the data area method using a
user space (largely by accident) but using some specific generic functions.
What I do now is write some control information into the user space
including job number/name/user into the user space (using based pointers
and some externally described structures this is pretty straight forward. I
have a generic routine to write/retrieve this data and a generic RTVJOBSTS
command which uses the API's to get the job status of a particular job.

When my NEP starts up I retrieve the process status from the designated
user space . If the user space doesn't exist or is empty I go ahead and
start the process as normal (performing clean up if necessary), if it
retrieves the details successfully then I simply check the returned job
contained in the details to see if it is active. If it is active I exit
gracefully, otherwise I proceed with starting the NEP.

The control point for the process is pretty much the user space name.

Hope this is useful as another point of view or possibility.

regards
Evan Harris

>This would cause a problem if the job ends abnormally.
>
>If I understand correctly, the purpose is to really check for an active
>process rather than an active job per se.
>
>I use the procedure of locking a data area. This has worked well for me for
>years.
>
>I put all of the data areas in one library, which does no need to be backed
>up, since the data areas are created as needed.
>
>Albert York
>
>
>
>         -----Original Message-----
>         From:   Wills, Mike N. (TC) [SMTP:MNWills@taylorcorp.com]
>         Sent:   Tuesday, April 09, 2002 10:03 AM
>         To:     'midrange-l@midrange.com'
>         Subject:        RE: Monitor for existing job.
>
>         Leif, What I am doing (forgot who suggested it) is to create a data
>area. If
>         there is a '1' in the data area, it is running, if there is a '0',
>it isn't
>         running.
>
>         -----Original Message-----
>         From: Leif Svalgaard [mailto:leif@attglobal.net]
>         Sent: Tuesday, April 09, 2002 11:53 AM
>         To: midrange-l@midrange.com
>         Subject: Re: Monitor for existing job.
>
>
>         From: Hall, Philip <phall@spss.com>
>         > > what am I missing? jobs are UNIQUE on the system. The 26
>character
>         >
>         > I think the poster was after a singleton job, i.e. there must be
>only one
>         of
>         > these jobs running on the system at anytime, like inetd on Unix,
>because
>         > it's function (or resources) can not be shared or would cause a
>conflict.
>         >
>
>         How would you specify such a job? And how would you prevent another
>         one with the same simple name but using completely different
>resources
>         to run or maybe it would be ok to run this as there is no conflict.
>         I guess I may be taking too broad a view of what a job is. Maybe
>         people running a production system manage things by naming
>         convention: they would never dream about submitting jobs with
>         the same name doing different things...