Last month we saw minor changes to Input specifications (I-specs) and Output specifications (O-specs) necessary to accommodate 10-character file and field names, longer field lengths, and two positions for the number of decimal digits. We reviewed major changes to Calculation specifications (C-specs) including six-character operation codes and free-form arithmetic and logical expressions. Our programs should be easier to code and maintain with the ability to code complex logic in a single EVAL, DOW or DOU calculation continued over multiple lines as necessary.

What now? We continue our coverage of C-specs and Definition specifications (D- specs) with the introduction of built-in functions. Then next month we'll look at the new date, time and timestamp data types and arithmetic operations.

Built-in Functions

CL has supported built-in functions for some time. These CL functions serve as a reference point that can help you understand ILE RPG built-in functions. In CL, %SST performs a substring function, %BIN provides a binary conversion, and %SWITCH tests job switches. Similar functions are available in ILE RPG.

Built-in functions in ILE RPG begin with a percent sign (%) and are followed by one or more arguments enclosed in parentheses. In ILE RPG, multiple arguments are separated by a colon (:), consistent with other keywords we have examined. (Why Rochester's CL is smart enough to use a blank as a delimiter for arguments while Toronto's ILE RPG requires you to key in a colon remains a mystery!)

Built-in functions are supported in D-specs in the keyword entry in positions 44 to 80. Only compile-time values can be used for arguments. Variables that are computed at run time cannot be used in an argument. When used in conjunction with the keywords DIM, OCCURS, OVERLAY and PERRCD, all arguments must be previously defined in the program.

C-specs also support built-in functions in the extended factor 2 entry. Free- form expressions may be used as the argument of a built-in function and may include other built-in functions.

So what does a built-in function really do? Let's take a look at a comparison of the substring built-in function in CL, RPG/400 and ILE RPG.

%SUBST Used to Retrieve a String

The substring built-in function in CL can be used to retrieve or modify a portion of a character string contained in a CL character variable or in the local data area. Either %SST or %SUBSTRING can be used in an expression or as the VAR or VALUE parameter of the Change Variable (CHGVAR) command. The character variable name or *LDA, starting position and length must be specified as arguments.

In the CL sample in 1, four characters are extracted from the variable &BEG, starting in position 2. The variable &END contains a value of 'BCDE' if the variable &BEG has the value 'ABCDEF'. Because it exceeds the number of characters in the substring, the variable &END is automatically padded with blanks.

In the CL sample in Figure 1, four characters are extracted from the variable &BEG, starting in position 2. The variable &END contains a value of 'BCDE' if the variable &BEG has the value 'ABCDEF'. Because it exceeds the number of characters in the substring, the variable &END is automatically padded with blanks.

RPG/400 and ILE RPG support the substring operation in C-specs. The character variable from which a value is to be extracted is specified in factor 2. The start position can optionally be specified in factor 2 following the variable. A colon (:) separates these two elements in factor 2. If not specified, the start position defaults to one. The length to be extracted can optionally be specified in factor 1. If not specified, it defaults to the length of the string from the start position. The variable to contain the substring is specified in the result field.

In the RPG/400 sample in 1, four characters are extracted from the variable BEG starting in position 2. The variable END contains the value 'BCDE' if the variable BEG has the value 'ABCDEF'. Because the length of the variable END is greater than the substring length, the operation extender P is specified to pad with blanks. ILE RPG supports the SUBST operation code which is identical in function to the RPG/400 version.

In the RPG/400 sample in Figure 1, four characters are extracted from the variable BEG starting in position 2. The variable END contains the value 'BCDE' if the variable BEG has the value 'ABCDEF'. Because the length of the variable END is greater than the substring length, the operation extender P is specified to pad with blanks. ILE RPG supports the SUBST operation code which is identical in function to the RPG/400 version.

In contrast, the ILE RPG sample in 1 uses the substring built-in function and is a close comparison to the CL sample. %SUBST is used in ILE RPG instead of the %SST or %SUBSTRING used in CL. A colon (:) is used to separate the variable, start position and length arguments instead of the blank used in CL.

In contrast, the ILE RPG sample in Figure 1 uses the substring built-in function and is a close comparison to the CL sample. %SUBST is used in ILE RPG instead of the %SST or %SUBSTRING used in CL. A colon (:) is used to separate the variable, start position and length arguments instead of the blank used in CL.

Even though the operation extender P is not specified (and cannot be specified with the EVAL operation code), the variable end still has the value 'BCDE'. When used with character fields, the EVAL operation functions similar to a MOVEL(P). When using the substring built-in function, the pad with blanks is implied with the EVAL operation in ILE RPG as it is with the CHGVAR command in CL.

%SUBST Used to Modify a String

While the SUBST op code has proved valuable in RPG/400, it is limited because it only permits you to retrieve a substring, not modify one. Although the substring operation has the same restriction in ILE RPG, the EVAL op code allows you to overcome the limitation. The previous examples of %SUBST were used to retrieve a substring. Let's take a look at how to change a substring.

A substring can be modified in CL by using the substring built-in function in the VAR parameter of the CHGVAR command. In the CL sample in 2, part of the variable &MOD (starting in position 3 and extending for a length of two characters) is replaced with the value of the variable &CON. Even though the length of the variable &CON is longer than 2, only the first two characters are used. Upon execution of the CHGVAR, the value of the variable &MOD changes to 'VWabZ'.

A substring can be modified in CL by using the substring built-in function in the VAR parameter of the CHGVAR command. In the CL sample in Figure 2, part of the variable &MOD (starting in position 3 and extending for a length of two characters) is replaced with the value of the variable &CON. Even though the length of the variable &CON is longer than 2, only the first two characters are used. Upon execution of the CHGVAR, the value of the variable &MOD changes to 'VWabZ'.

2 illustrates a similar capability for ILE RPG. A substring can be changed in ILE RPG using the EVAL operation code with the %SUBST built-in function specified on the left side of the equal sign (=). Identical to the CL sample, the value of the variable mod changes to 'VWabZ'.

Figure 2 illustrates a similar capability for ILE RPG. A substring can be changed in ILE RPG using the EVAL operation code with the %SUBST built-in function specified on the left side of the equal sign (=). Identical to the CL sample, the value of the variable mod changes to 'VWabZ'.

The second ILE RPG sample in 2 shows the use of the EVAL operation code with the %SUBST built-in function specified on both sides of the equal sign. This permits the value of a substring to be set equal to the value of another substring. The third and fourth characters in the variable mod are replaced with the fourth and fifth characters of the variable con. Upon completion of the execution of the EVAL operation, the variable mod contains a value of 'VWdeZ'.

The second ILE RPG sample in Figure 2 shows the use of the EVAL operation code with the %SUBST built-in function specified on both sides of the equal sign. This permits the value of a substring to be set equal to the value of another substring. The third and fourth characters in the variable mod are replaced with the fourth and fifth characters of the variable con. Upon completion of the execution of the EVAL operation, the variable mod contains a value of 'VWdeZ'.

If desired, blanks can be used be-tween the arguments in a built-in function to make the code more readable. Coding %subst(mod:3:2) is the same as coding %subst(mod: 3: 2).

Variables can be used for the start position and length as shown in the third ILE sample in 2. The results will be identical to the previous example; i.e., the variable mod will have a value of 'VWdeZ'.

Variables can be used for the start position and length as shown in the third ILE sample in Figure 2. The results will be identical to the previous example; i.e., the variable mod will have a value of 'VWdeZ'.

Any valid expression is permitted for the start position and length when the %SUBST built-in function is used as a target as shown in the fourth ILE RPG sample. Part of the variable mod (starting in position 2 and extending for a length of three characters) is replaced with the second, third and fourth characters from the variable con. Upon completion of the execution of the EVAL operation, the variable mod has a value of 'VbcdZ'.

As we showed last month, an expression can be continued over multiple lines. Continued lines must be blank in positions 7 to 35. No special continuation character is required unless a literal is being continued.

Run-time errors can occur when using the %SUBST built-in function if the start position is less than or equal to zero, the length is less than zero, or a combination of the start position and length would cause the substring to exceed the length of the field in the first argument.

When used as a target, the first argument of the %SUBST built-in function must refer to a storage location. In other words, it must be a field, data structure subfield, array name, array element or table element.

The ability to use the %SUBST built-in function as a target to change a portion of the value of a field is a substantial improvement to ILE RPG. Think of how much code this would take in RPG/400 if the start position and length were variables vs. one line of code in ILE RPG. Once again, nice job IBM!

%TRIM

Several built-in functions are available in ILE RPG to trim blanks from character variables. %TRIMR trims trailing blanks from the right side of a character variable. %TRIML trims leading blanks from the left side of a character variable. %TRIM trims leading and trailing blanks from a character variable.

As illustrated in 3, the argument of the %TRIMR, %TRIML and %TRIM built- in functions can specify a character variable or a valid character expression. The plus sign (+) used in conjunction with character variables means concatenation (combining), not addition.

As illustrated in Figure 3, the argument of the %TRIMR, %TRIML and %TRIM built- in functions can specify a character variable or a valid character expression. The plus sign (+) used in conjunction with character variables means concatenation (combining), not addition.

Since the availability of the CAT operation code, concatenating a first name with a last name has been simple. In the RPG/400 sample in 4, the field FIRST is concatenated with the field LAST, with one blank in between. The combined name is placed in the field XNAME and padded with blanks. If the field FIRST contains the value "Charles" and the field LAST contains the value "Massoglia", the field XNAME would contain the value "Charles Massoglia". ILE RPG supports the CAT operation code which is identical in function to the RPG/400 version; it also can accomplish the concatenation with the built-in trim function as shown.

Since the availability of the CAT operation code, concatenating a first name with a last name has been simple. In the RPG/400 sample in Figure 4, the field FIRST is concatenated with the field LAST, with one blank in between. The combined name is placed in the field XNAME and padded with blanks. If the field FIRST contains the value "Charles" and the field LAST contains the value "Massoglia", the field XNAME would contain the value "Charles Massoglia". ILE RPG supports the CAT operation code which is identical in function to the RPG/400 version; it also can accomplish the concatenation with the built-in trim function as shown.

The first ILE RPG sample in 4 uses the EVAL operation in conjunction with an expression containing a built-in function. The %TRIMR trims the trailing blanks from the right side of the character variable-in this case, the field FIRST. Because the field XNAME is a character variable, the plus sign (+) means concatenation. So the field FIRST with the blanks trimmed from the right is concatenated with a single blank. The result is concatenated with the field LAST. This first ILE RPG EVAL sample yields the same results as the RPG/400 sample.

The first ILE RPG sample in Figure 4 uses the EVAL operation in conjunction with an expression containing a built-in function. The %TRIMR trims the trailing blanks from the right side of the character variable-in this case, the field FIRST. Because the field XNAME is a character variable, the plus sign (+) means concatenation. So the field FIRST with the blanks trimmed from the right is concatenated with a single blank. The result is concatenated with the field LAST. This first ILE RPG EVAL sample yields the same results as the RPG/400 sample.

Both the CAT operation and the EVAL operation with %TRIMR work well unless there are any leading blanks in the first or last name. If the field FIRST contains the value "Charles" and the field LAST contains the value " Massoglia" with two leading blanks, the field XNAME would contain the value "Charles Massoglia" with three blanks between "Charles" and "Massoglia".

The second ILE RPG sample in 4 solves this problem using the %TRIM built-in function which causes the blanks to be trimmed from both sides of the specified variable. It now makes no difference whether or not the fields FIRST and LAST have leading or trailing blanks.

The second ILE RPG sample in Figure 4 solves this problem using the %TRIM built-in function which causes the blanks to be trimmed from both sides of the specified variable. It now makes no difference whether or not the fields FIRST and LAST have leading or trailing blanks.

The %TRIM built-in function in ILE RPG reduces the amount of code required to combine two or more fields while eliminating leading and trailing blanks. ILE RPG requires a single statement to perform the same function which might have been coded as a complex subroutine or called program in RPG/400. Way to go, IBM!

%ELEM with Arrays

When arrays are used in RPG/400, the number of elements and the element length and decimal positions must be individually coded in E-specs. This means if you need to change the number of elements for these arrays, you have to modify multiple E-specs. In addition, if the number of elements is specified as a literal in factor 2 of DO loops in C-specs, these also have to be modified. Even if you use a variable in factor 2, you still have to modify at least one statement.

In the RPG/400 sample in 5, the arrays TOT1, TOT2 and TOT3 are all defined with nine elements of seven digits with two decimal positions. If you need to increase the number of elements to 11, you must modify all three E- specs. In addition, you need to modify factor 2 of all three of the DO operations in the C-specs.

In the RPG/400 sample in Figure 5, the arrays TOT1, TOT2 and TOT3 are all defined with nine elements of seven digits with two decimal positions. If you need to increase the number of elements to 11, you must modify all three E- specs. In addition, you need to modify factor 2 of all three of the DO operations in the C-specs.

The ILE RPG sample in 5 requires changing only a single line of code. The %ELEM built-in function returns the number of elements in an array. Attributes are coded only for the array total1 in the D-specs. The LIKE keyword is used to cause the data type, length and number of decimal positions for the elements in the arrays total2 and total3 to be the same as in the array total1. The %ELEM built-in function is used on the DIM keyword to cause the arrays total2 and total3 to have the same number of dimensions (elements) as the array total1.

The ILE RPG sample in Figure 5 requires changing only a single line of code. The %ELEM built-in function returns the number of elements in an array. Attributes are coded only for the array total1 in the D-specs. The LIKE keyword is used to cause the data type, length and number of decimal positions for the elements in the arrays total2 and total3 to be the same as in the array total1. The %ELEM built-in function is used on the DIM keyword to cause the arrays total2 and total3 to have the same number of dimensions (elements) as the array total1.

This means if you need to modify the number of elements for these arrays, you only need to change the D-spec defining the array total1. When you recompile your program, the arrays total2 and total3 are automatically defined the same as the array total1.

The numeric constant numelem is defined as the value of the number of elements in the array total1 using the %ELEM built-in function in D-specs. Instead of coding a 9 in factor 2 of the DO loops in C-specs, numelem is coded instead. Now if the number of elements in the arrays changes, no changes are required to C-specs. When the program is recompiled, the numeric constant numelem automatically reflects the new value.

The way the %ELEM built-in function works with tables is similar to the way it is used with arrays. Whenever identically defined arrays or tables are defined in ILE RPG, they should be defined based upon the main array or table using the %ELEM built-in function. Any time an array is used in a DO loop in C-specs, the number of elements should also be coded in factor 2 using the %ELEM built-in function. Using these techniques can improve program maintainability and reduce debugging time.

%ELEM with Multiple Occurrence Data Structures

The number of occurrences of a multiple occurrence data structure is coded in I-specs in RPG/400. When the multiple occurrence data structure is used in a DO loop in C-specs, the number of occurrences is generally coded in factor 2. This means if the number of occurrences changes, you must change multiple lines of code.

In the RPG/400 sample in 6, the multiple occurrence data structure GLDS is defined in I-specs with 500 occurrences. The number 500 is also hard-coded in factor 2 of the DO loop in C-specs. Both specifications have to be modified if the number of occurrences is changed.

In the RPG/400 sample in Figure 6, the multiple occurrence data structure GLDS is defined in I-specs with 500 occurrences. The number 500 is also hard-coded in factor 2 of the DO loop in C-specs. Both specifications have to be modified if the number of occurrences is changed.

The ILE RPG sample in 6 requires changing only a single line of code. The %ELEM built-in function returns the number of occurrences in a multiple occurrence data structure. The OCCURS keyword makes the data structure glds a multiple occurrence data structure with 500 occurrences.

The ILE RPG sample in Figure 6 requires changing only a single line of code. The %ELEM built-in function returns the number of occurrences in a multiple occurrence data structure. The OCCURS keyword makes the data structure glds a multiple occurrence data structure with 500 occurrences.

The numeric constant numocc is defined as the value of the number of occurrences in the multiple occurrence data structure glds using the %ELEM built-in function in D-specs. Instead of coding a 500 in factor 2 of the DO loop in C-specs, numocc is coded instead. Now if the number of occurrences in the multiple occurrence data structure changes, the C-specs require no alteration. When the program is recompiled, the numeric constant numocc automatically reflects the new value.

The %ELEM built-in function can be used anywhere a numeric constant is valid within the functions column of the D-specs or the extended factor 2 of the C- specs.

%SIZE Built-in Function

The %SIZE built-in function returns the number of bytes of storage occupied by a literal, named constant, data structure, data structure subfield, field, array or table name specified as the first argument.

When used with a character or hexadecimal literal, %SIZE returns the number of bytes occupied by that literal. For numeric literals, the number of digits including leading and trailing zeroes is returned.

If %SIZE is used with a numeric variable stored in packed format, the packed length is returned (e.g., a seven-digit, packed field would return a size of 4 since it take four bytes to store the number in packed format). For binary numbers, the binary length (4 or 2) is returned.

When the first argument of the %SIZE built-in function is an array name or table name, the size of a single element is returned. If a multiple occurrence data structure is used, the size of a single occurrence is returned. If *ALL is specified as the second argument, the size of all elements or occurrences is returned.

7 illustrates some examples of values returned when the %SIZE built-in function is used. %SIZE can be used anywhere a numeric constant is valid within the functions column of the D-specs or the extended factor 2 of the C-specs.

Figure 7 illustrates some examples of values returned when the %SIZE built-in function is used. %SIZE can be used anywhere a numeric constant is valid within the functions column of the D-specs or the extended factor 2 of the C-specs.

Pointer Support

You may have heard about pointers, particularly if you are a C programmer. While RPG/400 does not support pointers, ILE RPG now provides pointer support. Two other built-in functions work with this data type. %ADDR returns a basing pointer containing the address of the variable specified as the argument. %PADDR returns a procedure pointer containing the return address of the entry point specified as the argument.

Pointer support permits ILE RPG to easily use application program interfaces (APIs) but is an advanced topic beyond the scope of this article. For further information on pointers and APIs, please consult the System Programmer's Interface Reference.

What's Next?

We've seen how built-in functions can substantially reduce program development and maintenance time, in some cases reducing complex routines or called programs in RPG/400 to a single line of code in ILE RPG.

In our next article, we will tackle date and time data types including the new date/time arithmetic operation codes.

Charlie Massoglia, president of Massoglia Technical Consulting, Inc. in Okemos, Michigan, has authored a number of midrange books. His cowboy hat is his trademark for his frequent speaking tours throughout the United States, Canada, Europe, and Australia. Charlie can be reached at 517-676-9700.

Reference System Programmer's Interface Reference (SC21-8223, CD-ROM QBKA8402).

An Introduction to ILE RPG: Part 4

Figure 1 %SUBST Used to Retrieve a String

 DCL VAR(&BEG) TYPE(*CHAR) LEN(6) VALUE('ABCDEF') DCL VAR(&END) TYPE(*CHAR) LEN(8) VALUE('XXXXXXXX') CHGVAR VAR(&END) VALUE(%SST(&BEG 2 4)) /* &END = 'BCDE ' */ *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 CL0N01N02N03Factor1+++OpcdeFactor2+++ResultLenDHHiLoEqComments+++++++...... C MOVE 'ABCDEF' BEG 6 C MOVE 'XXXXXXXX'END 8 C 4 SUBSTBEG:2 END P END = 'BCDE ' *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9 ...+... 0 CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq....Comm ents++++++++++++ C eval beg = 'ABCDEF' C eval end = 'XXXXXXXX' end prev defined C eval end = %subst(beg:2:4) Pad w/blank implied 
 
 An Introduction to ILE RPG: Part 4
 
 Figure 2 %SUBST Used to Modify a String
 
 DCL VAR(&MOD) TYPE(*CHAR) LEN(5) VALUE('VWXYZ') DCL VAR(&CON) TYPE(*CHAR) LEN(5) VALUE('abcde') CHGVAR VAR(%SST(&MOD 3 2)) VALUE(&CON) /* &MOD = 'VWabZ' */ *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9 ...+... 0 DName+++++++++++ETDsFrom+++To/L+++IDc.Functions............................Comm ents++++++++++++ D mod S 5 INZ('VWXYZ') D con S 5 INZ('abcde') D start1 S 5 0 INZ(3) D length S 5 0 INZ(2) D start2 S 5 0 INZ(4) CL0N01Factor1+++++++Opcode(E)+Extended- factor2+++++++++++++++++++++++++++++Comments++++++++++++ C eval %subst(mod:3:2) = con mod = 'VWabZ' C eval %subst(mod: 3: 2) = %subst(con: 4: 2) mod = 'VWdeZ' C eval %subst(mod: start1: length) = same as previous C %subst(con: start2: length) mod = 'VWdeZ' C eval %subst(mod: start1-1: length+1) = mod:2:3 con:2:3 C %subst(con: start2/2: length+1) mod = 'VbcdZ' 
 
 An Introduction to ILE RPG: Part 4
 
 Figure 3 %Trim Function Examples
 
 Function Value Result %triml ' Charlie Massoglia ' 'Charlie Massoglia ' %trimr ' Charlie Massoglia ' ' Charlie Massoglia' %trim ' Charlie Massoglia ' 'Charlie Massoglia' %triml 'same' 'same' %trimr 'same' 'same' %trim 'same' 'same' %triml ' ab ' + ' cd ' 'ab cd ' %trimr ' ab ' + ' cd ' ' ab cd' %trim ' ab ' + ' cd ' 'abcd' %triml ' ' '' %trimr ' ' '' %trim ' ' '' 
 
 An Introduction to ILE RPG: Part 4
 
 Figure 4 %TRIM Function
 
 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 CL0N01N02N03Factor1+++OpcdeFactor2+++ResultLenDHHiLoEqComments+++++++...... C FIRST CAT LAST:1 XNAME P Combine first & last *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9 ...+... 0 CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq....Comm ents++++++++++++ C eval XNAME = %TRIMR(FIRST) + ' ' + LAST Combine first/last C eval XNAME = %TRIM(FIRST) + ' ' + %TRIM(LAST) Trim blanks 
 
 An Introduction to ILE RPG: Part 4
 
 Figure 5 %ELEM Function with Arrays
 
 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 E....FromfileTofile++Name++N/rN/tbLenPDSArrnamLenPDSComments............... E TOT1 9 7 2 E TOT2 9 7 2 E TOT3 9 7 2 CL0N01N02N03Factor1+++OpcdeFactor2+++ResultLenDHHiLoEqComments+++++++...... C *LIKE DEFN TOT1 OUT C DO 9 X 50 C MOVE TOT1,X OUT C EXCPTPRINT1 C ENDDO C DO 9 X 50 C MOVE TOT2,X OUT C EXCPTPRINT1 C ENDDO C DO 9 X 50 C MOVE TOT3,X OUT C EXCPTPRINT1 C ENDDO *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9 ...+... 0 DName+++++++++++ETDsFrom+++To/L+++IDc.Functions++++++++++++++++++++++++++++Comm ents++++++++++++ D total1 S 7 2 dim(9) D total2 S like(total1) dim(%elem(total1)) D total3 S like(total1) dim(%elem(total1)) D out S like(total1) D numelem C const(%elem(total1)) = 9 D x S 5 0 CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq....Comm ents++++++++++++ C do numelem x C move tot1(x) out C except print1 C enddo C do numelem x C move tot2(x) out C except print1 C enddo C do numelem x C move tot3(x) out C except print1 C enddo 
 
 An Introduction to ILE RPG: Part 4
 
 Figure 6 %ELEM Function with Multiple Occurrence Data Struc
 
 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 IDsname....NODsExt-file++..............OccrLen+............................ IGLDS DS 500 I............Ext-field+..............PFromTo++DField+...................... I 1 9 GLNUM I 10 182GLAMT CL0N01N02N03Factor1+++OpcdeFactor2+++ResultLenDHHiLoEqComments+++++++...... C DO 500 X 50 C X OCUR GLDS C EXCPTPRINT C ENDDO *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9 ...+... 0 DName+++++++++++ETDsFrom+++To/L+++IDc.Functions++++++++++++++++++++++++++++Comm ents++++++++++++ D glds DS occurs(500) D glnum 9 D glamt 9 2 D numocc C const(%elem(glds)) = 500 D x S 5 0 CL0N01Factor1+++++++Opcode(E)+Factor2+++++++Result++++++++Len++D+HiLoEq....Comm ents++++++++++++ C do numocc x C x occur glds C except print C enddo 
 
 An Introduction to ILE RPG: Part 4
 
 Figure 7 %SIZE Function
 
 *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9 ...+... 0 DName+++++++++++ETDsFrom+++To/L+++IDc.Functions++++++++++++++++++++++++++++Comm ents++++++++++++ D packnum S 13P 4 D binnum S 9B 0 D signnum S 15S 0 D charvar S 40A D packarr S 5P 0 DIM(10) D signarr S 5S 0 DIM(10) D chararr S 11 DIM(5) D multoccds DS 8 OCCURS(20) D charcon C 'abcdefgh' D numcon C 500 D size_of_ds C const(%size(multoccds:*all)) = 160 CL0N01Factor1+++++++Opcode(E)+Extended- factor2+++++++++++++++++++++++++++++Comments++++++++++++ C eval num = %size(-005.00) = 5 C eval num = %size(005.00) = 5 C eval num = %size('Charlie Massoglia') = 17 C eval num = %size(' Charlie Massoglia ') = 21 C eval num = %size(packnum) = 7 (packed length) C eval num = %size(binnum) = 4 (binary length) C eval num = %size(signnum) = 15 C eval num = %size(charvar) = 40 C eval num = %size(packarr) = 3 (single element) C eval num = %size(packarr: *all) = 30 (whole array) C eval num = %size(signarr) = 5 (single element) C eval num = %size(signarr: *all) = 50 (whole array) C eval num = %size(chararr) = 11 (single element) C eval num = %size(chararr: *all) = 55 (whole array) C eval num = %size(multoccds) = 8 (single occur) C eval num = %size(multoccds: *all) = 160 (all occur) C eval num = %size(charcon) = 8 C eval num = %size(numcon) = 3