Kurt,
You're right. Of course I am. Silly me.
I just tried is specifying
out(e) *lock ExtraParm
and the data area remains locked throughout the entire process. The called
program crashes because it can't obtain a lock.
So in order for this process to simulate a CONST parameter, I'd simply have
to save the 'parameter' value, do an OUT (without a *LOCK) and then, when
control is returned, use the saved value rather than the data area value
(since one of the called programs might have changed it.
So I create a new program TEST1 as follows:
D ExtraParm UDS 32 Dtaara(EXTRAPARM)
/free
ExtraParm = *all'abc';
dsply ExtraParm;
return;
begsr *pssr;
return;
endsr;
/end-free
If I call TEST1 and return without setting on *INLR, the data area remains
locked (as I would expect, given the RPG manual). However, if I then
manually change EXTRAPARM call TEST1 again (with EXTRAPARM already locked),
TEST1 doesn't crash, but EXTRAPARM isn't automatically read in either. So
there seems to be an inconsistency somewhere, since this behavior (defining
a data area as a UDS and then calling the program when the data area is
already locked) *did* result in an error in the called program when the data
area was still locked by the caller.
Plus there's some optimization going on because if I call the TEST1 once
(leaving EXTRAPARM locked) and then delete EXTRAPARM, then when I call TEST1
again, it doesn't create EXTRAPARM automatically.
Perhaps I'm just worrying too much....
Rory
On Tue, Jan 13, 2009 at 12:45 PM, Kurt Anderson <
kurt.anderson@xxxxxxxxxxxxxx> wrote:
Rory, you're performing an OUT prior to the call, which is unlocking the
data area. Check this out:
"You can specify the optional reserved word *LOCK. When *LOCK is
specified, the data area remains locked after it is updated. When *LOCK
is not specified, the data area is unlocked after it is updated."
However I'm not so sure the called program can access that locked data
area.
midrange.com
