Re: Monitor for existing job.

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Dan,

You're 100% right.  I was just saying that the other fellow was right too.
 He just wanted to lock the program.  And, yes, you're right on another
point.  I would have thought that an *EXCL lock would have locked the .pgm
object to the point that it could not have been accessed again.  Might be
nasty for debugging batch jobs though.  Anyone care to see if *EXCL is
documented to work this way on .pgm objects or should this be reported as
a bug?

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin




"Dan Bale" <dbale@samsa.com>
Sent by: midrange-l-admin@midrange.com
04/09/2002 01:48 PM
Please respond to midrange-l


        To:     <midrange-l@midrange.com>
        cc:
        Fax to:
        Subject:        Re: Monitor for existing job.


Rob,

Perhaps I should have described the presumptions I was making.  Obviously,
the best way to make the data area lock work as we're looking to here is
to lock it at the very beginning of the program, before any files are
opened if necessary; if the program can't get an *EXCL lock on the data
area, then RETURN with LR on.  So, yes, the program would be called in the
subsequent job(s), but would be cancelled in short order.  I think that's
about the best we can hope for.

- Dan Bale
offsite today

---------- Original Message ----------------------------------
From: rob@dekko.com
Reply-To: midrange-l@midrange.com
Date:  Tue, 9 Apr 2002 13:33:15 -0500

>Dan,
>
>If you were to use the data area method, could you call a program that
>accessed that data area, while it was locked by another job?  Yes.  You
>would only have problems when the new program tried to lock the data
area.
>
>Same thing as the .dtaara object, is the .pgm object.  The lock would
only
>be checked on the .pgm object when you tried to allocate it in the new
>program.
>
>Rob Berendt
>--
>"They that can give up essential liberty to obtain a little temporary
>safety deserve neither liberty nor safety."
>Benjamin Franklin
>
>
>
>
>"Dan Bale" <dbale@samsa.com>
>Sent by: midrange-l-admin@midrange.com
>04/09/2002 01:20 PM
>Please respond to midrange-l
>
>
>        To:     <midrange-l@midrange.com>
>        cc:
>        Fax to:
>        Subject:        Re: Monitor for existing job.
>
>
>Carsten, I just tried ALCOBJ *EXCL on an program object in one job and
was
>able to call it in another job.  Which was the gist of what your code in
>the archive post was getting at.  Did I miss something else that your
code
>was doing?
>
>In fact, when I do a WRKOBJLCK on that program, I see the job where I did
>the ALCOBJ, but not the job that currently is running it.  I have never
>understood this mystery.
>
>I think that locking the data area is the easiest and most reliable way
to
>go.
>
>- Dan Bale
>offsite today

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.