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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.