OPNQRYF vs. Logical

5 pts.
Programming Languages
Hi, I am not very clear as to when should we use OPNQRYF and when should we use Logical file? Since logical file also offers DYNSLT facility, when is the use of OPNQRYF desirable?? Please advise.

Answer Wiki

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

If the file is reasonably small (less than 100,000 records) and the program using it is run infrequently the opnqryf would probably be better. An advantage of opnqryf is that you can put select criteria in it based on responses keyed on a screen. Jim Sloan’s TAATOOLs has a command to easily create the selection criteria. An example where I used it is:
The & fields are fields from my screen. The other fields are from the file being processed. Good luck.

Discuss This Question: 2  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.
  • Lpgast
    The main thing to understand is that a logical file is a persistant object and OPNQRYF is not. Therefore a logical file almost always(depending on your AS400 setup) will have usable access path to sort the records. An OPNQRYF will always need to determine what access path to use based on the sort order and filtering set in the command call. If a access plan exists that it can use it will, otherwise it will copy the data and do what is called a table scan to find the records. Since a LF is a persistant object it will incur persistant storage needs which will also affect overall system performance. That Being said, you then need to look at the application and which method will best suit your purpose. If you are always going the same sort order and sequence then a LF is the best way to go, because it will almost a readily available access path. Now if you need a multiple sort order and random filtering, then MAYBE you should use OPNQRYF, but performance will be an issue. Another aspect to consider is interacive updating. Persitant Access paths need to frequently update to be usefull. Typically the best time for this to happen is when a record gets added or updated. This of course affects performance, espicially with large recordsets that need to be reorderd/ recalculated for each update. shit...i'm rambling, i'll cut it short...hopethis helps a little...let me know if you need more help....
    0 pointsBadges:
  • TomLiotta
    Note that DYNSLT has essentially no bearing on the question of LFs and OPNQRYF except when multiple PFs are joined and a selection comparison is made between two (or more) fields from different PFs. Often, a new PF is created with a field that can be updated and that acts as the controller over which records will be read from the original PF. A LF source is created to define the join of the two PFs and to indicate which field is the controller. The source is compiled to create the LF object. An OPNQRYF doesn't need a second PF and no LF object needs to exist. Further, the structure of the OPNQRYF can be changed dynamically at run-time, where the LF must always be recompiled from changed source if a new structure is wanted. The time to build any OPNQRYF index at run-time must be balanced against development and maintenance of the LF object (and the second PF) plus continual system maintenance of any associated LF index. Tom
    125,585 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: