Re: RPG Data Area *LOCK

Hi, Arthur:

You asked exactly the same question two days ago, and Barbara Morris of IBM ToroLabs answered your question. (She is the lead developer for ILE RPG IV compilers and runtime libraries at IBM ToroLabs, so she is "the expert" in this area.) In case you somehow "missed" her reply, it is here:
http://archive.midrange.com/rpg400-l/201009/msg00492.html

Based on her answer, I suggest you remove the *LOCK on the IN statement in your RPG program, since the calling CL program has already locked it, or, if this RPG program may be called from other programs, remove the ALCOBJ and DLCOBJ of this data area from that CL program and leave it to the RPG program to handle locking and unlocking of this data area.

HTH,

Mark

> On 10/1/2010 11:08 AM, Arthur Marino wrote:

We have jobs that run all day long - sleep 5 minutes, wake up looking
for something to process, go back to sleep...
In an effort to prevent our newly-mandated 'save while active' strategy
from causing file and data area lock conflicts with these jobs, I
inserted an ALCOBJ *EXCLRD on the relevant file(s) and/or data area(s)
in the CLLE program. If a lock fails, it branches around the RPG call
and sleeps for another 5 minutes. With file locks, things worked as
expected. But with the data areas, when the CL gets the lock the called
RPG then fails saying it can't obtain the lock. When I do a WRKOBJLCK, I
find the only object that has a lock is the very same CL program that
called the RPG. (The RPG does a "*lock in".)

How come the RPG isn't sharing the lock that its own CL caller obtained?
Are data area locks handled differently? Thanks for any help.

Arthur J. Marino
RockTenn Corporation
(631) 297-2276