Re: Lock on command processing program ignored

Another consideration is that I want to minimize the window during which
another job could start the command/program. So I'll allocate either the
CPP or the VCP in the VCP, first thing.

As for renaming, we can't protect 'those' people from everything they
try, can we?   <bg>

thomas@inorbit.com wrote:
>
> Mark:
>
> On Wed, 13 February 2002, "Mark Phippard" wrote:
>
> > If it is your own command, then you should change the CPP to ALCOBJ *EXCL
> > on some *DTAARA object and release the lock when it is finished.
>
> Just out of curiosity, why lock an external object? The lock can still be 
>established against the *PGM object even if the program establishes it itself. 
>And subsequent attempts will fail until the lock is released.
>
> Although establishing a lock will not prevent a program from being run, the 
>lock still exists and can be tested. I suppose the program could even adapt 
>itself by retrieving its own name so that a rename wouldn't upset the basic 
>scheme, though renaming the object of _any_ lock attempt can be trouble.
>
> Tom Liotta
>
--
Vern Hamberg

Would you like to see a challenging little arithmetic puzzle
that might get you or your kids or grandkids more interested
in math? Go to <http://cgi.wff-n-proof.com/MSQ-Ind/I-1E.htm>

Sillygism--

Something is better than nothing.
Nothing is better than a ham sandwich.
Ergo
Something is better than a ham sandwich.