Helge Bichel wrote:
The LDA defined with an ext. PF for having fields common to programs
where used. Feel free to add additional fields (addfield1, addfield2).

Do an IN at start, change desired fields, do an OUT before calling the NextPgm,
do an IN after return from NextPgm.

d MYLDA e ds extname(MYLDA) dtaara(*lda) d addfield1 501 501 d addfield2 502 503 0

/free
in MYLDA;
addfield1 = 'X';
addfield2 = 10; out MYLDA;
NextPgm();
IN MYLDA;
/end-free

or, reduced to its essentials and put into traditional RPG format:
DFOO DS D BAR 1 10 C *ENTRY PLIST C PARM NEWVAL 10 C *DTAARA DEFINE *LDA FOO C CLEAR BAR C BAR DSPLY C IN FOO C BAR DSPLY C MOVE NEWVAL BAR C OUT FOO C CLEAR BAR C BAR DSPLY C SETON LR

This little program, inspired by Helge Bichel's example (and written to see whether said example answered my question), will DSPLY whatever parameter you gave it the last time you called it, between 2 blank lines (these blank lines, the CLEAR statements, the DSPLY statements immediately after them, and the SETON LR are in there simply to verify that FOO is really being stored in, and retrieved from, the LDA).

The confusing part is that the manual insists that you can't explicitly *LOCK the LDA, but it also says you have to *LOCK the IN statement if you want to have a subsequent OUT statement, and doesn't say that the LDA is an exception to this rule.


Thanks, Helge, for giving me something that cut through the confusion.


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].