SetON LR and Return

10 pts.
Tags:
RPG
SETON
What is the difference between Seton LR And Return

Answer Wiki

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

*INLR = *on files and resources are released
Return ends the program returning to calling program.
Return without *INLR = *On resources remain locked until job ends or this program is recalled and changes the value of *INLR.

————————————————
WoodEngineer’s correct – saves resources to leave *INLR off, keep in mind that initialization and *INZSR do not run on subsequent calls.
Phil

_____________________________________

Another important difference is that setting on LR ends the called program when the cycle ends, but using RETURN returns control to the calling program immediately. Therefore after LR is on, you can still continue processing additional commands.

Graybeard52

Discuss This Question: 13  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.
  • WoodEngineer
    If program A calls program B many times, you can speed up the process by not setting on *INLR in B until A is ready to end. Then A is ready to end, issue one more call to B with a parm that tells B it is time to shut down.
    7,640 pointsBadges:
    report
  • Pravs
    in Seton LR release the resources and close the files after that why commands are executed. commands should not execute. Please share the exact reason.............?????
    20 pointsBadges:
    report
  • pdsathishkumar
    Opened files are closed when exiting with LR equal to ON. Opened files remain open when using RETURN with LR equal to OFF, and the program is still resident (potentially active.) but we can't able to come out from RPG program without using the both op-code...
    3,790 pointsBadges:
    report
  • TomLiotta
    commands should not execute. Why not? "Commands" are from CL, but "SETON LR" is from RPG. Those are two separate languages, so one isn't going to affect the other. (...with some exceptions based in multiple modules...) "SETON LR" in a RPG program won't affect "commands" from a CL program. They're different programs. Tom
    125,585 pointsBadges:
    report
  • graybeard52
    Seton LR just turns on an indicator that tells the program to end at the end of the RPG cycle. So RPG commands CAN execute after LR is turned on, in fact, its often desirable to do some end of file proessing. To get out immediately, SETON LR, then do a RETURN on the next line.
    3,115 pointsBadges:
    report
  • TomLiotta
    ...its often desirable to do some end of file proessing. Yep. I've seen it set on during initialization routines. It simply helps ensure that it will be on no matter how early a return from the program. Tom
    125,585 pointsBadges:
    report
  • WoodEngineer
    One tip about setting on LR early in your program . . . don't do it in *INZSR. This will cause your program to end prematurely.
    7,640 pointsBadges:
    report
  • TomLiotta
    . . . don’t do it in *INZSR. Good point. I should have differentiated between "initialization routines" in non-cycle coding and use of an actual *INZSR routine. Tom
    125,585 pointsBadges:
    report
  • anandx
    I wanted to test impact of *inLR on attributes dbf pointer and variables on a proc call environment. Main pgm (PGM1) opens a file (File1), reads a single rec from *START, calls a *SRVPGM (PGM2) which opens the same file under sys control (no 'usropn'), reads a rec, returns, PGM1 reads next rec and so on. In one case PGM2 had *inLR (bef return) and in another there wasn't. Called PGM1 twice from command line, signed off, signed on and called again. Created PGM1 (CRTPGM) under three diff actgrp: *CALLER, *NEW and a name. PGM2 was *CALLER always.
    This is what I observed. Variables and DBF retain their status under *CALLER and named actgrps but under *NEW, they were initialized on multiple calls within the same job step.
    Using *system/DSPJOB I checked, open files, active actgrp and call stack when pgm was in PGM2. 
    Based on the results I concluded that initialization of variables and file pointers (not speed) are governed by the type actgrp an
    400 pointsBadges:
    report
  • anandx
    ...contd
    and not by *inLR.
    After those monotonous simulations I'm left with wondering: (1) in main module if *LR can be placed anywhere, pgm is going to terminate only at the last line and not when it hits *LR being *on and when pgm doesn't have LR compiler cries saying 'cannot determine how the program can end' which makes LR mandatory, and finally, when pgm terminates all resources are anyway closed, WHY LR AT ALL, in the first place (reminds of "catch22") (2) when a file is declared without 'usropn' in a called (nomain) module suggesting system will open and close files at start and at end respectively whenever it is called, how could dbf pointer not initialized under *caller and name actgrps of caller.

    400 pointsBadges:
    report
  • GregManzo
    Which makes LR mandatory, Not quite. The compiler will look for any one of several methods to end. If you have a Return op-code it knows that will end the program so it won't complain.
    LR on at exit will cause all open files to be closed, all variable space to be released and the program released from the call stack so on next call everything starts again as if this was the first call.
    LR off will keep files open & variables as they are. It's faster if you are calling multiple times but you need to be aware of any re-initialising you may need, and also it will hold record locks if you haven't explicitly released them.
    1,830 pointsBadges:
    report
  • anandx
    GregManzo: First comes first. Thanks for your reply, for one, someone is treating my reply with serious intent and for another, the qn was initiated in the 18th century and I thought lost of water must have flown under the bridge by now. Now, back to business on hand.
    Please refer the attached code. Here is some explanation and my old two questions raising their ugly heads again. I shall be obliged if you help me, one more time, to change my perception on LR. Sorry, if I am still making no sense which is not unlikely and ignore replying if so.

    PGMY (nomain) is always created in following 3 steps:
    1. crtrpgmod PGMX srcfile(qrtxsrc)
    2.CRTSRVPGM SRVPGM(PGMY) EXPORT(*ALL) SRCFILE(QRTXSRC) BNDDIR(bnddirX)
    3. add pgm1 to bnddirX

    PGMX is created in 2 steps, but under diff scenario
    1. crtrpgmod pgmX srcfile(qrtxsrc)
    2. CRTPGM PGM(pgmX) BNDDIR(bnddirX) ACTGRP(*CALLER)
    step2 was repeated for actgrp(*new) and actgrp(nameX)
    -------------------------------------------------------------------
    Results:
    (a) call PGMX (1st time)
    from PGMX: keyval: 1 
    from PGMY: keyval: 1 i val: 1
    from PGMX: keyval: 2 
    from PGMY: keyval: 2 i val: 2
    from PGMX: keyval: 3
    pgm PGMX ends.

    (b) call PGMX (2nd time)
    from PGMX: keyval: 1 
    from PGMY: keyval: 3 i val: 3
    from PGMX: keyval: 2 
    from PGMY: keyval: 2 i val: 4
    from PGMX: keyval: 3
    -------------------------------------------------
    Note: LR is indispensable to main, but optional in nomain and return is indispensable to nomain and has no place in main. That basic is covered, the core qn is why LR?
    ---------------------------------------------------
    Qn1: line '3rd read...' in main is the last line in rpg cycle, since immediately following is 1st begSR (if one exists), rpg cycle waits till last line is hit, implicitly that is last, then why LR, is it not redundant?
    Qn2: 
    Despite the presence of *INLR, file pointer is not initialized, it continues from where it was left in *prv call. Exactly same result when *LR is removed in PGMY. This is not the case when PGMX is compiled as:
    2. CRTPGM PGM(pgmX) BNDDIR(bnddirX) ACTGRP(*NEW)
    That is the reason why, ostensibly, I thought/think LR has no role in nomain procedure too. which, I suppose, implies file pointer will be re-initialized once PGMX (caller) is terminated first and called again, (this is not the same as 'multiple calls') depending only on the type of actgrp and not on LR.
    Thanks again
    pgmX:
    
    exSR    srX ; // 1st read in main
    procX()
    exSR    srX ; // 2nd read in main
    procX()
    exSR    srX ; // 3rd read in main
    
    *inLR = *on;
    
    begSR   srX ;
            read(e) fileX ;
            dsply   key_fieldX ;
    endSR ;
    
    // handling (e) not shown here
    // let's say, *key is single and unique in fileX
    
    PGMY:
    
    dcl-f     fileX  usage(*input)  keyed ;
    dcl-s     i packed(2:0) inz(0) ;
    dcl-proc  procX  export ;
      dcl-pi  procX ;
      end-Pi
      read(e)   filex ;
      dsply     ('from PGMY, keyval: ': ' + key_fieldX + 
                  'i val: ' + %char(i) ) ;
      *inLR = *on ;
      return ;
    end-proc ;

    400 pointsBadges:
    report
  • GregManzo
    LR goes all the way back to RPG 1 and the program cycle (I think I'm one of about 5 people left on the planet that still remembers / understands the cycle). It means Last Record, and comes on automatically at end of file for a PRIMARY file (and all secondary files if specified). It will cause the program to exit at the end of the last C-spec, including any LR total-time C-specs if specified. It will also close all files and free up variable space & program code in the PAG (=Process Access Group, refer to work management for another discussion). All this LR logic is built into the RPG cycle in every program UNLESS you specify NOMAIN. The use of NOMAIN is to tell the compiler you are writing a dynamic procedure that doesn't need the RPG cycle logic built in. (If it helps think of the cycle as including logic at the bottom of the program like this: If LR on, print totals, close all files, clear all variables, return, EndIf.)
    Note that if you don't have a Primary file you need to set on LR explicitly to do this.
    In contrast, a RETURN op-code will exit the program immediately and leave all files & variables untouched (including holding record locks if any). A return without LR will mean your next call will be faster because you don't re-open files or re-initialise variables. Note that you can use both: seton LR then RETURN - this will exit immediately (skipping total-time logic) but still close files & free variable space. Good if you don't intend to call again (or too lazy to work out what needs re-init).
    LR is not applicable to sub-procedures - they use dynamic variables and so will be re-init on every call.
    1,830 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.

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

Following

Share this item with your network: