RE: RPG Data Area *LOCK

If memory serves...when you do a "*LOCK IN" and do not perform an OUT on the data area, the lock is in place until the job ends.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Arthur Marino
Sent: Friday, October 01, 2010 10:09 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: RPG Data Area *LOCK

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


This message, including its attachments, constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. Section 2510. This message is the confidential property of RockTenn, and disclosure is strictly limited to recipients intended by the sender. Unless previously authorized in writing, this message does not constitute an offer, acceptance, or agreement of any kind. This message may contain confidential attorney-client privileged information and attorney work product. If you are not the intended recipient, or responsible for delivering e-mail to the intended recipient, you are advised that use, dissemination, forwarding, printing, or copying of this message is STRICTLY PROHIBITED. If you receive this message in error, please notify the sender immediately by return e-mail and delete the message entirely from your system. Sender is not liable for damage caused by viruses transmitted with this message, or errors or omissi!
ons in content caused by transmission.
(c) RockTenn, Norcross, GA.