× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



That is true for OPM programs - not necessarily for ILE things - maybe I'm thinking service programs.

I don't ever us Return, if I've set *inlr *on already. Old-time habit, perhaps, but when using the cycle, it's enough to turn on LR.

OK, back to real work!!
Vern

On 2/4/2022 9:20 AM, Sean Courtney wrote:
Hi,

The LR or (Last Record) indicator is just a way of telling the program that have read the last record and when I exit the program you can close all the files.

If you just go back with Return the ODP remains open....

Correct me if I am wrong ...

If I want to close down a program then I normally do..

*inlr = *on;
Return;


Mit freundlichen Grüßen / Kind regards / Bien à vous,

sean

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of K Crawford
Sent: Freitag, 4. Februar 2022 15:36
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: 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


--
KCrawford
--
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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

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.