RE: UDS & Allocations

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Jerry Adams
>
> Never tried this, Buzz, but apparently the error message says it all:
>
> Message . . . . : &1 &2 *LOCK for data area &5 was not granted (C G S D
> F).
> Cause . . . . . : The RPG program &1 in library &3 tried to access and
> lock
> data area &5 at statement &2. The data area has already been locked by a
> program in this process or by an ALCOBJ command in this process.
>
> You might check the program. If it is using the IN op-code with *Lock,
> you might want to re-think either the program logic or the ALCOBJ.

What's weird about this, Jerry, is that RPG seems to be specifically
checking to see if there is a lock and then disallowing its own lock.
Because I can sit and lock a data area (or indeed any other object) nine
ways from Sunday within the same job and get no problems.  I had three
*EXCL, two *EXCLRD, two *SHRNUP and two *SHRUPD on the same data area and
none of them complained.

Typically, you can lock something multiple times.  You can't allocate a
record for update multiple times, and it seems that the RPG runtime is
trying to emulate that behavior for the UDS.  My guess is that it doesn't
want you to lock the data area in one program and then call another program
that ALSO tries to lock the data area.

Joe