Re: Native way to lock an object in RPG?

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

Outstanding!! Glad it will work for you

Vern

On 8/26/2016 10:18 AM, Bob Cagle wrote:
> This is exactly what I was looking for - program is already using the IN opcode.  I wasn't aware you could specify *LOCK with it.  Thanks Verne!
>
> Bob
>
> -----Original Message-----
> From: Vernon Hamberg
>
> You can specify a data area as external in the program and you can specify to lock it with the IN opcode - or somewhere - then you can also have an error to test, or use monitor or whatever - do whatever you do, wait, retry, all that.
>
> So look at the IN opcode - lots of useful stuff there, I just saw.
>
> HTH
> Vern
>
> On 8/25/2016 12:32 PM, Bob Cagle wrote:
> > Yes, maybe I shouldn't have said 'native'.  I'm perfectly fine with accessing either a CLLE or another service program to access the function.  I was just curious if there was a %BIF or RPG opcode that I was missing - doesn't sound like it though.
> >
> > The reason for wanting to attempt the lock is I have a process that cannot run while another process is running.  This other process puts a lock on a specific data area.  I just need to check if that data area is locked or not before allowing my process to continue.
> >
> > -----Original Message-----
> > From: Mark S Waterbury
> >
> >
> > Bob:
> >
> > What do you mean  by "native"? On OS/400 and IBM i, you can not get much more "native" than invoking MI (machine interface) instructions directly from within ILE programs as built-in functions.
> >
> > What kind(s) of object type(s) are you wanting to "lock"?  And for what purpose(s)?
> >
> > Here  is one way  to accomplish this:
> >
> > Create a CLP *PGM  or CLLE procedure you can call from RPG, that issues the ALCOBJ command to "lock" an object, and uses MONMSG CPF1002  to detect if the object could not be allocated; specify WAIT(0) on the ALCOBJ command so it does not wait for the lock, but if the object cannot immediately be "allocated" (locked), the command signals an exception  by throwing an *ESCAPE message CPF1002. Then, your CL program or  procedure can return some kind of "return code" to indicate success or failure.
> >
> > IMHO, using CL commands and a CLP program or CLLE program or procedure
> > in this way is still considered  "native." :-)
> >
> > HTH,
> >
> > Mark  S.Waterbury