Re: RPGLE Return vs *INLR

Brian said create a test case. I thought DUH I should do that. So I did.
Thanks for the push.
Summary of the test case.
pgmA used *INLR=ON
pgmB used *INLR=ON
pgmC used RETURN
pgmD used RETURN
All of the programs were basically the same. Upon entry display values of 4
strings. change value of string associated with that program. display
values of 4 strings to prove they changed. call the next program in the
stack (A>B>C>D). When coming back to the calling program display the 4
strings again.

Results were that the first call to pgmA everything as expected. Second
call to pgmA when we got to pgmC and pgmD they had values populated from
the memory from the first call. Third and after calls to pgmA when we got
to pgmC and pgmD they had values populated from the memory from all of the
previous calls. It did this no matter what I did with the activation
groups. This was not the same result when in the Sys36E. When called from
OCL memory was cleared.

With that being said the LR on in the first two programs in the stack did
not clear the values of the last two programs in the stack unless in S36E.
In this case I can change the RETRUN to LR on. Talking with the boss/other
programmer on what to do.

Once again thanks for the help. This group has saved me and helped me more
than you know.


On Thu, Feb 3, 2022 at 3:57 PM Brian Parkins <goodprophet.bp@xxxxxxxxx>
wrote:

Kevin, are you trying to fix a bug, design a solution, or understand a
conundrum?

Is my understanding correct; all of the programs were created with
DFTACRGRP(*NO) ACTGRP(*CALLER)? Assuming Program A was initiated from a
menu in the *DFTACTGRP, then they all have their resources - in
particular working storage - in the *DFTACTGRP - correct?. Others have
pointed out this is not ideal. However, putting this aside you asked.

1). If we call ProgramA and it makes it to ProgramD. Let’s say
LastClient = ‘AS’. Then goes back to the menu. Then, from same
session/job we call ProgramA again and it makes it to ProgramD. Will
LastClient still have ‘AS’ upon entry?

A). Difficult to say. Is LastClient a parameter, using STATIC storage,
part of a Data Structure based on an external Data Area? Are the
programs using subprocedures? Is RCLRSC being employed? If none of these
situations are apparent, then I would suggest the answer to your
question is "yes".

2). If ProgramB has LastClient field. If ProgramB changes LastClient
value. Will that new value be carried in to ProgramC and ProgramD?

A). Again, depends on how LastField is defined. But assuming the same
conditions as 1). above, I would suggest "no".

This is a HUGE simplification; with traditional, non-ILE coding:
- RETURN with LR *OFF - leaves variables intact
- RETURN with LR *ON - causes variables to be "cleared"
- End of Program with LR *ON - causes variable to be "cleared"

CAVEAT: This assumes I've understood the question correctly! Bottom
Line: Set up a simple test case and try it out for yourself to prove it.
The situation you describe would be quick and easy to construct.

HTH,
Brian.

On 03/02/2022 19:33, K Crawford wrote:

If I have the following:

ProgramA calls ProgramB

ProgramB calls ProgramC

ProgramC calls ProgramD



ProgramA ends with *INLR = *ON

ProgramB ends with *INLR = *ON

ProgramC ends with RETURN

ProgramD ends with RETRUN



If program C and D have some Last Changed values like LastClient. No INZ
value on it in program C and D.



First question:

If we call ProgramA and it makes it to ProgramD. Let’s say LastClient =
‘AS’. Then goes back to the menu.

Then, from same session/job we call ProgramA again and it makes it to
ProgramD. Will LastClient still have ‘AS’ upon entry?



Second question:

If ProgramB has LastClient field. If ProgramB changes LastClient value.
Will that new value be carried in to ProgramC and ProgramD?

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com