Skip to main content

Logical File vs OPNQRYF

1. The main difference between Logical file and OPNQRYF is that, Logical file is a permanent 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. i.e. access path will be permanent for a logical file.

2. 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 an 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.

3. QRYSLY keyword can be used on OPNQRYF command to setup Record Selection process. Key fields can be mentioned on a File using KEYFLD keyword.

4. Since a LF is a permanent object it will incur permanent storage needs which will also affect overall system performance.

5. If you are always going the same sort order and sequence again and again, then a LF is the best way to go, because it will be almost a readily available access path. It will save the processing time.

6. Now if you need a multiple sort order and random filtering, then maybe you should use OPNQRYF, but performance will be an issue.

7. Another aspect to consider is interactive updating. Persistent Access paths need to frequently update to be useful. Typically the best time for this to happen is when a record gets added or updated.

8. This of course affects performance, especially with large record sets that need to be reordered/ recalculated for each update. Especially when specific logical file doesn’t need to be updated for the process.

9. DYNSLT keyword on Logical File provides an advantage of performing a Selection Criteria during initialization time of program. This method is preferred when there is limited use of specific Logical File.

10. OPNQRYF would be the best option when you have database files with smaller amount of data and you have multiple selection criteria to be applied or criteria can be changed by job.

Labels:

Comments

Post a Comment

Popular posts from this blog

All about READ in RPGLE & Why we use it with SETLL/SETGT?

READ READ is one of the most used Opcodes in RPGLE. As the name suggests main purpose of this Opcode is to read a record from Database file. What are the different READ Opcodes? To list, Below are the five Opcodes.  READ - Read a Record READC - Read Next Changed Record READE - Read Equal Key Record READP - Read Prior Record READPE - Read Prior Equal Record We will see more about each of these later in this article. Before that, We will see a bit about SETLL/SETGT .  SETLL (Set Lower Limit) SETLL accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Corresponding Record (or Next Record if exact match isn't found).  SETGT (Set Greater Than) SETGT accepts Key Fields or Relative Record Number (RRN) as Search Arguments and positions the file at the Next Record (Greater Than the Key value). Syntax: SETLL SEARCH-ARGUMENTS/KEYFIELDS FILENAME SETGT  SEARCH-ARGUMENTS/KEYFIELDS FILENAME One of the below can be passed as Search Arguments. Key Fiel
4 comments
Read more

What we need to know about CHAIN (RPGLE) & How is it different from READ?

CHAIN READ & CHAIN, These are one of the most used (& useful) Opcodes by any RPG developer. These Opcodes are used to read a record from file. So, What's the difference between CHAIN & READ?   CHAIN operation retrieves a record based on the Key specified. It's more like Retrieving Random record from a Database file based on the Key fields.  READ operation reads the record currently pointed to from a Database file. There are multiple Opcodes that start with READ and all are used to read a record but with slight difference. We will see more about different Opcodes and How they are different from each other (and CHAIN) in another article. Few differences to note.  CHAIN requires Key fields to read a record where as READ would read the record currently pointed to (SETLL or SETGT are used to point a Record).  If there are multiple records with the same Key data, CHAIN would return the same record every time. READE can be used to read all the records with the specified Ke
Post a Comment
Read more

Extract a portion of a Date/Time/Timestamp in RPGLE - IBM i

%SUBDT Extracting Year, Month, Day, Hour, Minutes, Seconds or Milli seconds of a given Date/Time/Timestamp is required most of the times.  This can be extracted easily by using %SUBDT. BIF name looks more similar to %SUBST which is used to extract a portion of string by passing from and two positions of the original string. Instead, We would need to pass a value (i.e., Date, Time or Timestamp ) and Unit (i.e., *YEARS, *MONTHS, *DAYS, *HOURS, *MINUTES, *SECONDS or *MSECONDS) to %SUBDT.  Valid unit should be passed for the type of the value passed. Below are the valid values for each type. Date - *DAYS, *MONTHS, *YEARS Time - *HOURS, *MINUTES, *SECONDS Timestamp - *DAYS, *MONTHS, *YEARS, *HOURS, *MINUTES, *SECONDS, *MSECONDS Syntax: %SUBDT(value : unit { : digits { : decpos} }) Value and Unit are the mandatory arguments.  Digits and Decimal positions are optional and can only be used with *SECONDS for Timestamp. We can either pass the full form for the unit or use the short form. Below i
2 comments
Read more