If you are into stereotypes, BIF sounds a lot like one of those names you would hear at some stodgy old Ivy League university. (“Oh, Edward! Bif and Muffy are coming over for tea, and then, perhaps, we could catch an evening at the theater.” Puh-lease!) The BIFs we are talking about were designed by IBM to help “blue-collar” AS/400 programmers like us. The BIFs we’re talking about are built-in functions. These BIFs are for doughnut-eating, coffee-drinking, techno-geek nerds who just happen to write code for a living. If you think it just may be possible that you fit into this latter stereotype, please read on.

Only a handful of today’s BIFs were announced with the original RPG IV language. And although they were limited in number, it was obvious to old code dogs like us that BIFs were going to open up some pretty interesting possibilities. We saw that the string-handling features alone were going to eliminate a lot of code. Less code generally means fewer errors. As software vendors, we liked that. Judicious use of BIFs reduces future maintenance. We really liked that! Since those early days of RPG IV, IBM has quietly added dozens of new built-in functions that can be used to cover a wide variety of needs.

Maintenance? We Don’t Need No Stinking Maintenance!

How can BIFs reduce maintenance? Let’s say, for instance, that you have to increase the size of an array in a program. Wouldn’t it be nice to simply change the definition specification and have all of the calculations using the array work correctly?

Or suppose you were loading a work array with a database field and you decide to change the size of the field for some strange reason. Wouldn’t it be nice to only have to recompile the program to make it work with the new field definition? Well, using BIFs on the definition specifications allows you to do exactly that!

Figure 1 shows an example of how using %SIZE will allow you to change the size of the database field and only have to recompile the program. Instead of hardcoding the DIM (Dimension) statement with the number of elements in the array, we used the %SIZE BIF to retrieve the size of the field Name. The Name field is defined with the keyword Like to be the same size as the CustName field from the database file. So if we decided to change the size of CustName in our database file, the Name field would automatically change, too. All we would need to do is recompile the program.

In the same example, we used %ELEM to initialize a field (DoCounter) to control the processing loop so that we process all of the elements of the array. Make sure that the size of the field (DoCounter, in our example) is large enough to contain the correct number of digits. The %ELEM BIF should be incorporated into all array- and table-handling routines. Instead of coding your processing loops with a fixed number of elements, you can tell the system to process your loop for the number of elements in your table or array. This will eliminate future errors as well as program maintenance.

A Few of My Favorite Strings

Most of the early BIFs were designed to make character-string handling easier. %TRIM was designed to “trim” both leading and trailing blanks. %TRIMR (trim right) trims trailing blanks only and %TRIML (trim left) trims leading blanks.

The %SCAN BIF was designed to help you find characters within a character string. Without this tool, you may not have known that the word mile is in the word smiles. And once you have found the word mile in our example, you can use the %SUBST (substring) BIF to extract it if you wish.

Even though we poke fun at these functions, the simple truth is that string handling has come a long way since those days when we had to use arrays and work fields to do even the simplest string handling. The new BIFs have made our jobs much easier.

Another job that used to be very tedious prior to BIFs is editing numeric fields for output. This is a very common requirement in business programming. Oh yeah, edits were easy to apply if you could use the edit codes or edit words in DDS or on the output specifications. But what did you do if you needed to embed an edited numeric value within a character string to print or present on a screen? Go back to arrays, data structures, and work fields—what a waste of time!

This single line of code will change the negative numeric field 00123456 to the character string of 1,234.56CR: While this task seems simple, it used to require a lot of code back when we were creating code with the rest of the troglodytes.

I/O, I/O, It’s Off to Work We Go...

New BIFs were added to replace those dreaded indicators that used to be required for basic I/O operations. To some degree, this was a mixed blessing. A common habit of some programmers was to key a line of code performing an I/O operation and then press the Enter key to let the editor’s error checking place the cursor at the appropriate indicator position on the screen. But once IBM added the I/O error BIFs, the editor no longer checked to see whether you had an indicator present on an I/O operation. The compiler will let you know, but that is so passé.

The %FOUND BIF will logically tell you whether the operation you submitted found the result you were looking for. The I/O operations that this BIF works with are CHAIN, SETLL (Set Lower Limits), SETGT (Set Greater Than), and DELETE. You just use the %FOUND in lieu of the operational indicator. You should note that %FOUND can be used for the CHECK, CHECKR, and SCAN string-handling operations as well as for table or array lookups.

%EOF is used to indicate that your operation has encountered an end-of-file condition. This BIF is used for I/O operations only. Instead of using resulting indicators with READ (and others) or WRITE operations, you can simply use the %EOF BIF field. The value will be either *ON (1) or *OFF (0) and will refer to the READ or WRITE operation that most closely precedes the occurrence of the %EOF. If you are dealing with

Eval OutDta = %EditC(InNbr : ‘B’)

more than one file, it is generally safer to qualify the %EOF with the file name, as seen in Figure 2.

Another useful I/O-related BIF is %OPEN. The %OPEN BIF will tell you whether a file has been opened within your program. As we have often advocated in our previous articles, it is often a wise choice to open some database files yourself instead of letting program initialization open all of your files for you. Why incur the overhead of opening and closing a file if it may not be used? Using the User open parameter on the file specification, you can elect to open the file if and when it is needed. We have generally advocated using an indicator or status field to keep track of whether or not you have opened each file, but this can prove to be rather cumbersome. Instead, you can check to see if a file is open using the %OPEN BIF. If the file is not open, simply use the OPEN operation code to do so. You can see an example of this in Figure 3.

Information Is the Key

Some of the information that is available to you in BIFs was formerly only available within the various information data structures of the AS/400. For example, the number of parameters passed to your program used to be available only in the program information data structure, but now you can use %PARMS. The status of file operations used to be available only within the file information data structure, but now there is %STATUS, which will serve you the same information.

The %ERROR BIF is much like the I/O BIFs we discussed. Any operation that can be coded with an error positional indicator will trigger the %ERROR BIF as well. And just like the I/O BIFs, %ERROR will be on (a value of 1) if an error condition exists and off (a value of 0) if no error condition exists. Note that the condition of %ERROR will change each time an operation is performed that could potentially be coded with an error indicator.

Information that was never available to RPG programmers is now available in the form of BIFs. The %PADDR (get procedure address) and %ADDR (get address of variable) BIFs are used to retrieve addresses in memory. Although you may not need this information every day, it can be very useful when you are working with the AS/400’s numerous APIs.

Numerically Speaking

Many of the BIFs that have been added make dealing with numbers easier. As IBM tried to broaden the market appeal of the AS/400, it needed to introduce ways to handle some of the more complex numerical computations. Many of these computations are completely foreign to traditional business software, but these data types were required to enable RPG and C programs to communicate with one another. When was the last time you needed to use floating-point decimals and absolute values in writing a sales analysis report?

Other new BIFs allow you to convert one field type to another easily. The %CHAR BIF will automatically convert other field types to an alphanumeric field. This can come in handy for comparison with another alphanumeric field or for the purposes of output. If you want to embed data that is of a date or time data type, you would normally need to move it to an alphanumeric field first. But that is not the case if you simply use the %CHAR BIF. The %DEC BIF will convert other data types to packed decimal, %FLOAT to floating-point decimal, %UNS to unsigned numeric, %INT to integer, and so on.

BIFfy the Debug Slayer

BIFs are extremely useful when debugging a program. The %SUBST (substring) BIF allows you to display or change the value of a portion of a character field. You can even use %SUBST to set conditional break points based on a portion of a character field.

The %INDEX BIF is used to change the current index of a table. For example, if you are at a program debug break point, simply key Eval TableName = %INDEX(2) to set

the current index for the table to 2. Keying Eval TableName would then show the current contents of the second entry in the table.

BIFs to the Rescue!

When coding your programs, the built-in functions are often easy to overlook. But if you take a few minutes to study them, you may find that you can save yourself both time and trouble. We have provided a complete list in Figure 4 that shows all built-in functions available as of OS/400 Version 4 Release 4. Take those few minutes. You may find yourself a gem.

D DS
D Name LIKE(Custname)
D Array 1 OVERLAY(Name)
D DIM(%SIZE(Name))
D DoCounter 5 0 INZ(%ELEM(Array))

c Do DoCounter

* your favorite code goes here....

c EndDo

Figure 1: Use BIFs to reduce maintenance programming.

* Read detail records, summarize totals, and print the results
c DoU %EOF
c TestKey ReadE SalesRec
c If %EOF(SalesFile)
c Exsr PrintTotl
c Leave
c Else
c Exsr Total
c EndIf
c EndDo

Figure 2: Use %EOF to indicate the success of an I/O operation.

fSalesFile if e k disk UsrOpn

c If Not %Open(SalesFile)
c Open SalesFile
c EndIf
c Read SalesRec

Figure 3: Use %OPEN to determine whether a database file is open.

Function Name Description Value Returned Release
%ABS Absolute value of expression Absolute value of expression V3R7 %ADDR Get address of variable Address of variable V3R1 %CHAR Convert to character format Value in character format V4R1 %DEC Convert to packed decimal format Value in packed numeric format V3R7 %DECH Convert to decimal format, half adjust Half-adjusted value in packed numeric format V3R7 %DECPOS Get number of decimal positions Number of decimal digits V3R7 %DIV Return integer portion of quotient Quotient V4R4 %EDITC Edit value using an edit code String with edit code applied V3R7 %EDITFLT Convert to float external representation Character representation of floating V3R7 %EDITW Edit value using an edit word String with edit word applied V3R7 %ELEM Get number of elements Number of elements or occurrences V3R1 %EOF Return end or beginning of file condition 1 if beginning or end of file V4R2 %EQUAL Return exact match condition 1 if SETLL/LOOKUP found exact V4R2 %ERROR Return error condition 1 if op code with extender errored V4R2 %FLOAT Convert to floating format Value in floating format V3R7 %FOUND Return found condition 1 if record, element, or match found V4R2 %GRAPH Convert to graphic value Value in graphic format V4R4 %INT Convert to integer format Value in integer format V3R7 %INTH Convert to integer format, half adjust Half-adjusted value in integer format V3R7 %LEN Get or set length Length in digits or characters V3R7 %NULLIND Query or set null indicator 1 or 0, indicating null setting V3R7 %OPEN Return file open condition 1 if file is open V4R2 %PADDR Get procedure address Address of procedure V3R1 %PARMS Return number of parameters Number of parameters passed in V3R2 %REM Return integer remainder Remainder from the division V4R4 %REPLACE Replace character string String with replaced value inserted V4R2 %SCAN Scan for characters First position of search argument, or 9 V3R7 %SIZE Get size in bytes Size of variable or literal V3R1 %STATUS Return file or program status If error, value set for program or file status V4R2 %STR Get or store null terminated string Characters addressed by pointer V3R7 %SUBST Get substring Subset of a string V3R1 %TRIM Trim blanks at edges String with blanks trimmed front/back V3R1 %TRIML Trim leading blanks String with leading blanks trimmed V3R1 %TRIMR Trim trailing blanks String with trailing blanks trimmed V3R1 %UCS2 Convert to UCS-2 value (Unicode) Value in UCS-2 format V4R4 %UNS Convert to unsigned format Value in unsigned format V3R7 %UNSH Convert to unsigned format, half adjust Half-adjusted unsigned value V3R7 %XFOOT Sum array expression elements Sum of the elements of array V4R4

Figure 4: These are the RPG IV BIFs available with OS/400 V4R4.