RE: RPG400-L Digest, Vol 6, Issue 1131

Jerry, the first thing I did was to ensure that there were no In/Out with
*LOCK statements, because that is what I thought was causing the problem,
too.

Buzz Fenner
Systems Analyst/Network Administrator
870.930.3374
mailto:bfenner@xxxxxxxxxxxxxxxx



------------------------------

message: 6
date: Tue, 27 Nov 2007 09:32:32 -0600
from: Jerry Adams <jerry@xxxxxxxxxxxxxxx>
subject: Re: UDS & Allocations

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.

* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



Buzz Fenner wrote:

I have a trio of (all of this is OPM by the way) RPG programs that do
mundane A/P check writing. A CL wrapper executes AlcObj?s to get locks on
all files involved prior to executing the process (to guarantee it runs
end-to-end). I tried to extend it to allocating a data area in the CL but
that causes one of the RPG programs to throw an RPG0432 at *INIT. I

figured

the allocation would work within the job step just as it does with files.
What gives?

Buzz Fenner
Systems Analyst/Network Administrator
870.930.3374
mailto:bfenner@xxxxxxxxxxxxxxxx <mailto:bfenner@xxxxxxxxxxxxxxxx>




--
PRIVACY WARNING: For auditing purposes, a copy of this message has been
saved in a permanent database.

--
PRIVACY WARNING: For auditing purposes, a copy of this message has been
saved in a permanent database.