A Search400.com member recently asked about the last record indicator (*INLR), so I want to take a look at a couple ways you can use the last record indicator to your advantage.
As we all know, the *INLR must be set on in order to shut down a program. That does not necessarily mean the program must terminate. Or, in other words, that the program must close all its files and release itself from memory.
If you have a program that is used often in the call stack, for performance reasons you may wish to keep the program "hot" or active. You may have a central work with style program that most of your users access. Each time a program starts, the system validates security, opens files, and a host of other activities. All of that takes valuable processing time.
If the program returns to the caller with *INLR set on, then the program shuts down and all the files are closed. The next call to the program repeats all the same steps once again to validate security, opening files and everything else. If the same people use the program many times in a day, it could impact the overall performance of your system.
But if the program returns to the caller with *INLR set off, all the files remain open and all subsequent calls to that program are executed much faster. With the files already opened and security validated, there is much less overhead in executing the program.
As with any new technique, there are a few drawbacks. First, if you use an initialized subroutine (*INZSR) in the program, it will only be executed the first time the program is called. That could cause problems, depending on the logic it contains. Next, by leaving the files open, each pointer is right where you left it. Also, the program variables contain the values that were last loaded. In essence you restart the program right where you left off the last time.
Another caveat of the last record indicator is it can be used to end a program without ever executing the mainline. If *INLR is set on during the *INZSR routine, the program ends when the *INZSR subroutine ends and will not execute any of the mainline logic. This is useful in programs that you want to use conditioning logic to see if the program should execute. It's also helpful in programs that have complex mainline logic. You can code the *INZSR to test for reasons you should not execute the mainline and if any are met, turn on *INLR and let the program end.
Those are a couple of coding methodologies that you can introduce into your programs. As with all new styles, be careful in how you implement them until you fully understand their ramifications.
-----------------------------------------
About the author: John Kohan is a senior programmer analyst at CT Codeworks.
==================================
MORE INFORMATION
==================================
- Improved performance for repetitious program calls
It is customary in RPG programs to either allow the RPG cycle to set on the LR indicator after the last record in a primary file, or to manually set on *INLR when not using a primary file. That works perfectly well. However, if one program repeatedly calls another program, when the called program ends with LR on, the next call to that program must re-initialize the program. Search400.com member Michael Fiorillo presents an alternative.
- Reorganize physical files automatically
Search400.com member Kellie O'Shea provides an example in which she uses *INLR when automatically reorganizing physical files in several libraries. This tip consists of two CL programs and one RPG program. The first CL program creates a work file of the files in a given library. The RPG program reads the work file and calculates a percent of deleted records to control the file reorganization process. The second CL program reorganizes the file meeting the percentage that is coded in the RPG program.
- Rapidly growing ASP
One user said the ASP on his company's 400 seems to grow rapidly on a daily basis. They've noticed that the 'current unprotect used' on the wrksyssts screen seems to reach its specific maximum value everyday. What could be causing this? Site expert John Brandt pointed out a few things, including programs that are executed and held in memory (such as returning without setting on *INLR.
