SETON LR and RETURN.

425 pts.
Tags:
AS/400
SETON
Diff between SETON LR, RETURN. Please tell with an example

Software/Hardware used:
Iseries

Answer Wiki

Thanks. We'll let you know when a new response is added.

When INLR is *On the program will finish the current cycle and then exit.
RETURN immedialely exists the program from the spot it is in. INLR does not have to be *ON for this to happen

=========================================================

Setting on LR tells the program what to do after the last statement in the C-specs is run. Executing RETURN exits the program.

Note that executing RETURN will cause it to become the last C-spec that is run.

The program can be exited by executing a RETURN, by falling through the bottom of the C-specs with LR on, or by falling through the bottom of the C-specs with RT on.

The RT indicator will cause an exit at the end of a Cycle whether LR is on or not.

The “Cycle” exists in almost all RPG programs. (There are some exceptions.)

It is like there is a hidden DOUNTIL just before the first C-spec in your program and a hidden ENDDO just after the last C-spec (before the first BEGSR). The condition on the hidden DOUNTIL is something like (*INLR = *ON or *INRT = *ON).

One way to see what the “Cycle” means:<pre>
D NxtCycle s n inz( *OFF )
D LastCycle s n inz( *OFF )

D Cnt s 3p 0 inz( 0 )

C if ( LastCycle = *ON )
c eval *INLR = *ON
c endif

C if ( NxtCycle = *ON )
c eval LastCycle = *ON
c endif

C eval NxtCycle = *ON
C eval Cnt += 1
</pre>Compile that as RPGLE with full debug. Run it under debug and put a breakpoint on the last statement. See if you can figure out what value Cnt will have in it when the program ends.

Once you figure out what happens, you’ll have a much better understanding of what the “Cycle” is.

Tom

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Kar
    Can you expalin little bit clear with *INLR, finish of current cycle means?
    425 pointsBadges:
    report
  • CharlieBrowne
    It would mean when you get to the end of the C specs in your program. At the point you SETON LR, the prorgam will continue processing. For example, if you are in a DO Loop, that will continue normally. The RPG language is designed around a Cycle. Get a record, process it, do Output, Get another record, etc. Files in the F spces were defined as 'P'rimary or 'S'econdary. There was no need for a READ command as it was automatic. When it got the the end of the C specs, it had completed one cycle. Today's programmers seldom use those file types. We do the READs in the C specs and actually onll go through the C specs one time. (Or one cycle)
    41,380 pointsBadges:
    report
  • ASWDEVELOPER
    to clarify charliebrowne's answer a bit ... if you are using an IP or UP file (primary), the RPG cycle will automatically read each record of the input file and then make a pass through the detail C-specs ... at completion of the processing cycle of the last record, LR is set on automatically and a pass is made through the control section C-specs (if any exist) and then the program ends ... if you are NOT using primary files, essentially the C-specs are processed as top-down or "fallthru" processing ... you have to code your own file processing and loop iterations, and you must manually set on LR before ending the program ... since any RPG program ending with LR on will automatically return control to the next statement in a calling program or procedure, i have never found it necessary to use RETURN ... maybe someone else could give you a scenario where RETURN would actually be needed ...
    405 pointsBadges:
    report
  • TomLiotta
    maybe someone else could give you a scenario where RETURN would actually be needed … Many of my programs in the past decade never turn LR on at all nor even reference it. Since ILE and activation groups became part of the RPG environment, RETURN and AG management have been more important for me. One might ask when LR would actually be needed. Tom
    125,585 pointsBadges:
    report
  • Koohiisan
    I use RETURN without LR when I want a program to stay in memory until it gets called again. I have some triggers that call these kind of programs. So, that way the next time the trigger fires, it calls this already-running program to process a new record. I have set up the program so that I can insert a specially-coded record to tell it to set on LR and then RETURN, so that it terminates, in case I need to recompile it or perform some other maintenance.
    5,020 pointsBadges:
    report
  • aceofdelts
    I do that, too. Here is a partial program using Return with LR - I did not want to let this program stay in memory. One other very minor point is that the Seton LR command compiles to a larger size than Move *on to *inlr. Not sure about Eval. Program size is rarely an issue nowadays. * Return conversion factor if match C If $DATE >= CCEFDF or CCEFDF = 0 C If $DATE <= CCEFDT or CCEFDT = 0 C Eval OUTRAT = CCCNVF C Eval *inlr = *on C Return C Endif C EndIf
    1,975 pointsBadges:
    report
  • TomLiotta
    ...when I want a program to stay in memory... There are at least three "parts" to (ILE) programs. (Often many more than three, but most don't make much difference to us.) 1. Program variables 2. File buffers, ODPs, etc. 3. Program instructions Which of those would you expect to be affected by LR and/or RETURN if the AG hasn't been reclaimed? What effects would you expect? Tom
    125,585 pointsBadges:
    report
  • Koohiisan
    1. Program variables 2. File buffers, ODPs, etc. 3. Program instructions Per my understanding, files which have been opened stay opened and variables are not reset to any values they had been assigned as defaults in your declarations (inz). I always make sure my variables are set properly myself, so that is not so important to me. But, I wanted to benefit from the savings of not reopening data paths on each invocation of the program. Perhaps my understanding is a bit narrow, or even maybe somewhat inaccurate. But...I've had wonderful success with it, and the programs do exactly what I want them to do. Is there some hidden 'gotcha' that I am missing?
    5,020 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following