Reason behind the *INLR = *OFF process

320 pts.
Hi, it may be dump question for you, but can anyone please clearly explain me, what is happening when I do *inlr = *off. I have tried with the sample example code as below:
HDFTACTGRP(*NO)  Option(*NODEBUGIO)                  
FEmployee1 iF   E           k Disk                   
DNum1             S              2S 0 inz(4)         
DNum2             S              2S 0 inz(4)         
DRes              S              4S 0                
    Setll *loval Employee1;                          
    Read Employee1;                                  
    Dow not %Eof(Employee1);                         
      Dsply Empname;                                 
      Read Employee1;                                
    *inlr = *off;                                    
    //Close Employee1;                               
  Begsr *Inzsr;                                      
     Res = Num1 + num2;                              
     Dsply Res;                                      
    Clear Num1;    
    Clear Num2;    
    Clear Res;     
    Res = 8;       
My questions are:
1) When I do the *inlr = *off without the close file, it going in infinite loop.
2) When i do the Close file it execute till the EOF.
3) Please tel me what is happening here, its only because of the File is open.
if so,
And i tried with the concept with out file, even it going in the loop.
Please anyone clearly explain me the system behind this.

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

Discuss This Question: 7  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.
  • TheRealRaven
    1. There is almost never a reason explicitly to set *INLR to *OFF. It's most likely that you will never see a situation where *OFF has a reason to be assigned to it. There are almost always only reasons to set it *ON. When set *OFF, a program that is written as your example is written has no way to end. It has no RETURN statement nor any other way to end.

    2. You have no error checking. When you CLOSE the file and then execute a READ statement, an I/O error will cause the program to end with an error. If the file is not closed, a READ statement will not cause an error in this program; it will only signal an end-of-file condition when all records have been processed. Since you never issue a RETURN, the end-of-file with *INLR = *OFF simply allows the program "Cycle" to go back to the beginning and start again.

    3. See #2 above.

    For details, read the RPG Cycle and other implicit Logic topics from the ILE RPG Language Reference in the Information Center.
    37,005 pointsBadges:
  • azohawk

    I used to work with an ERP system that the primary program that did something would call programs for each file being used and pass the record information between the two. The relevence here: the file program would be called to open then return with *INLR = *off. The next call call might be to read the file and return with *INLR = *off. and so on. Only when the first program was ending would it call the file program requesting a call and *INLR would be turned *on in the file program. 

    I have encountered a couple of other programs that did secondary processing that would return with *INLR = *off, but those situations were rare by comparison.

    While that ERP application seemed like a lot of unnecessary overhead, it did work and explains a situation where the program might return with *INLR = *off.

    4,075 pointsBadges:
  • philpl1jb

    INLR off keeps the resources (files) open so subsequent calls to the program don't need to open the resources. These resources will remain open until either the program(s) issue a INLR *on or the job ends

    54,090 pointsBadges:
  • philpl1jb

    INLR is always off when programs start .. so the trick is to avoid issuing a *INLR = *ON but if you like you can issue an *INLR = *OFF

    54,090 pointsBadges:
  • philpl1jb

    Further, the later calls to the program do not run the *INZSR or initialization of data structures and the like .. so care should be taken in using the *INLR off end to the program

    54,090 pointsBadges:
  • TheRealRaven
    Yes, there are reasons for leaving *INLR set to off; that's not the same as explicitly setting it to *OFF. Setting it to *OFF implies that something set it to *ON. If it hasn't been set *ON, there's no reason to set it *OFF since that's already the state it has.

    If it's *ON, then either some coded instructions set it or some internal process set it. Either way, if the value is expected to be *OFF and needs to be set, it's likely a part of a logic error and should be corrected. It shouldn't have been *ON.

    That's especially true when there is no RETURN statement. Without a RETURN, *INLR = *OFF is just a bug in coding.
    37,005 pointsBadges:
  • aceofdelts
    For a program that I expect will be called repeatedly by other program(s), I will include a line "Eval *inlr = *off" but it is commented out - only to document that LR was intentionally not set on (so no doubt whether or not I just forgot).
    2,550 pointsBadges:

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.


Share this item with your network: