2

I have recently stumbled on a service program in which *inlr = *on is used after explicit close of a file (code below). It feels rather excessive for me. From what I have found it is rpg cycle that handles releasing of resources. So if there is no cycle (ie. in programs with main/nomain h-specs) there is no way for *inlr = *on to have any effect, but... I have not been able to find any confirmation, and since cycle related issues are very new to me I might be missing something...

if %open(file);      
  close file;        
endif;                  
*inlr = *on;            
return *on;
ime
  • 23
  • 2
  • Taking the line *inlr=*on out won't even make a measurable change in performance. You'll come across more of these in the wild best to leave them alone lest you change the signature of the service program while changing it and every program that calls the service program breaks. – danny117 Sep 12 '17 at 16:58
  • 1
    `*inlr` does not change the signature of the service program. The only way to change that is by changing the exports. Not even changing parameters can change the signature of a service program, unless you are meaning something different from the signature that can be generated by the binder source. – jmarkmurphy Sep 12 '17 at 19:50

3 Answers3

4

In short no.

"last record" indicator is only used by the cycle. It's not used in a NOMAIN service program or a linear MAIN program.

The RPG IV Programmer's Guide says

Note No cycle code is generated for subprocedures or when MAIN or NOMAIN is specified on the control specification.

Additional References
IBM's Barbara Morris (RPGLE Compiler developer, in a post to the RPG mailing list)

The linear-main procedure will just end when it gets to the end of the calculations. You can set on *INLR if you want, but it won't do any of the cycle-related things like closing files.

Here is a comparison of a cycle-main module and a linear-main module.http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzasd%2Fsc09250802.htm "

Charles
  • 21,637
  • 1
  • 20
  • 44
  • 1
    you beat me by 10 seconds – jmarkmurphy Sep 11 '17 at 13:33
  • Slept in today did 'ya? :) – Charles Sep 11 '17 at 13:34
  • I do not think this is correct. Even in a MAIN procedure, the *LR indicator causes variables to be unloaded. If you RETURN from a program without setting *LR on, the variables will remain with the same values on the next call. The RPG Programmer's guide alludes to this: "The ILE RPG run time manages data so that the semantics of ending programs and reinitializing the data are the same as for OPM RPG, although the actual storage is not deleted as it was when an OPM RPG program ended. **Data is reinitialized if the previous call to the procedure ended with LR on, or ended abnormally.**" – Mike Oct 04 '17 at 20:42
  • @Mike ...that's referring to a cycle main program. The same sentence is in v5 of the [https://public.dhe.ibm.com/systems/power/docs/systemi/v5r4/en_US/sc092507.pdf] (RPG Programmer's Guide) before linear main was introduced. See additional references...I've added to my answer. – Charles Oct 04 '17 at 20:56
  • Thank you for the additional reference. Sounds like good authority. The software I have been working with calls other programs without setting *LR on, so that when you come back, all your variables are still set, but that must be because that older code is OPM style and is treated like a cycle main program, even when you don't have an input primary file to cycle on. – Mike Oct 04 '17 at 21:22
  • correct, in an RPG module, the cycle is always there unless a control spec with `main(someproc)` or `nomain` is there. – Charles Oct 04 '17 at 21:26
3

In a linear main, or nomain module, *inlr has no effect. As far as I know, there is no explicit documentation of this, but the ILE RPG Programmer's Guide, on page 4, states

Note: No cycle code is generated for subprocedures or when MAIN or NOMAIN is specified on the control specification.

Since checking *inlr is part of the cycle, this inferrs no function

jmarkmurphy
  • 11,030
  • 31
  • 59
-2

try this:

cl program to call rpg program

    pgm
    call testlrr
    call testlrr
    call testlrr
    endpgm

then this for the rpg

    ctl-opt  dftactgrp(*no) actgrp('QILE');

    dcl-pr TESTLRR   extpgm('TESTLRR');
    end-pr;

    dcl-pi TESTLRR;
    end-pi;

    dcl-s counter      zoned(5:0);

    counter = counter + 5;

    dsply counter;

    return;

you'll see the values of the variables continue to increment in the subsequent calls.

yes...you can deal with it via activation groups, inz statements, etc....but *inlr is pretty cheap and pretty foolproof.

lou wilkinson
  • 19
  • 3
  • The opportunity was asking about service programs and/or linear main programs. You're talking about a cycle main program. – Charles Oct 12 '17 at 03:08
  • dude this answer is so confusing as it's completely unrelated sorry – Luigi Nov 22 '22 at 14:33