Calculating the length of the data in a character field has always been an issue with programmers. There was the traditional reverse loop that was popular and is still in widespread use today; start at the end of a field and check each character in the field for a blank until you encounter a non-blank. Voila! You have the data length.

In RPG IV, a simple--yet often overlooked--technique is to use the CHECKR operation code. This "string" operation code was introduced in RPG III (and was called CHEKR then) along with several other string opcodes, including CHECK, SCAN, CAT, and XLATE. These opcodes are referred to as "string opcodes" because they work with character string variables. They also were the first of what has become a long line of enhancements to both RPG III and RPG IV.

The CHECKR operation verifies that each character of Factor 2 is contained in the list of characters specified in Factor 1. It starts with the rightmost character in the field. Verification stops when the opcode detects a character in the field specified in Factor 2 that is not among the characters listed in Factor 1. The CHECK opcode does the same thing as CHECKR, except it starts on the left side of the field. Its purpose is to validate a field for a set of characters.

A Simple Example of the CHECK Opcode

In the example that follows, the CHECK opcode is being used on three separate lines. The first CHECK opcode verifies that each character in the field named PHONE contains only numeric digits, a left or right parenthesis, or a dash. If it finds other characters, the Result field (nBadPhone) is set to the position in the field where the "bad" character is detected. Otherwise, nBadPhone is set to zero.

The second CHECK opcode verifies that each character in the field named HEX contains only valid hexadecimal symbols (0 through 9 and A to F in upper- or lowercase). Again, if an invalid symbol is detected, its position is returned to the Result field. In this case, the nBadHex field receives the position.

The third CHECK opcode verifies that each character in the field named NAME is in uppercase only and is only A through Z. If any other symbol is detected, its position is returned to the Result field named nBadCaps.

The CHECKR operation (or CHEKR if you're running RPG III) performs a similar function, but it starts on the right side of the field in Factor 2 and checks each character from right to left. If used in place of the CHECK opcode in the previous examples, you would end up with the same results.

But what if you put the CHECKR opcode to a different use? What if it was used with a blank in Factor 1? What would be the result? The result would be that, in the Result field, the opcode would return the position of the last non-blank character in the field specified in Factor 2. For example:

In this example, the field BOOKTITLE contains 'The Modern RPG IV Language'. Since a blank is specified in Factor 1, the CHECKR opcode returns the position of the last non-blank character in the BOOKTITLE field. Therefore, the field named nLength is set to the length of the data stored in the BOOKTITLE field, or 26. You now have a way to determine the length of a field's content using the CHECKR operation code.

On the other side of the coin, you can use the CHECK opcode (note that this is CHECK, not CHECKR) to detect the starting position of the data in a field. What good is that? Consider a left-adjust routine. If a user enters a value into an input field, you normally want to make sure that value is left-justified (or in some languages, right-justified). You can use CHECK in conjunction with the %SUBST operation code to left-justify data in a field. For example:

If you're really into pain, or if you're stuck with RPG II, you can use the old SUBST opcode to substring the value and left-justify it. Or, in RPG IV, use the %subst built-in function with the nStart field as the starting point for the assignment operation.

Is There an Easier Way?

These techniques are fairly easy for most RPG programmers to work with, but with RPG IV, the methods for accomplishing these tasks are even easier, and the results are more readable.

The %LEN built-in function returns the declared length of a field. Contrast this with the %SIZE built-in function that returns the number of bytes a field occupies in memory. For example, a seven-position packed field with two decimal digits occupies 4 bytes of memory. %SIZE returns the number 4, whereas %LEN returns the number 7.

Using %LEN is easy; just wrap a variable or expression with %LEN, and the length of the variable or the length of the result of the expression is returned. For example:

In this example, the field named nLength is assigned the length of the field named BOOKTITLE, or 50. Perhaps this is useful for some applications, but not for what you're trying to accomplish. How do you calculate the length of the data in BOOKTITLE?

The answer is to use one of the %TRIMx built-in functions. You can use %TRIMR, %TRIML, or %TRIM to strip off trailing blanks, leading blanks, or both trailing and leading blanks from a value. The result is an intermediate value that you can think of as being a quoted character string. That value is then used on an assignment or as the parameter for a procedure call or expression. For example:

The result of this is just the data from the BOOKTITLE field itself without any trailing or leading blanks; that is, 'The Modern RPG IV Language'. If you assign that value to a variable, as follows, it would be the same as moving 'The Modern RPG IV Language' to the field.

Calculating the Length of a Field's Data

What if you used %TRIM along with %LEN; what would happen then? First, %TRIM would be evaluated, and 'The Modern RPG IV Language' would be returned. Then, %LEN would be evaluated, and it would determine that the length of 'The Modern RPG IV Language' is 26 characters. So the return value would be 26. For example:

Of course, trimming off leading blanks isn't necessary in this example and, in fact, isn't strictly correct. Instead, the %TRIMR (trim right) built-in function should be used as follows:

By using %TRIML, you get the true length of the data in the field without the overhead of attempting to trim off leading blanks where there are none.

You've now gone from using a loop to search for the last non-blank position, to using CHECKR, to using %Len with %TRIMR to calculate the length of data in a field. I'd say the last option is the best practice.

Left- and Right-Justifying Data

What good is %TRIML if you only need %TRIMR to calculate the length of a field? How about using it as a one-line, left-adjust routine? Or better yet, how about two one-line routines, one to left-justify a value and a second one to right-justify a value?

On line 1 in this example, the %TRIML built-in function is used to left justify a field's data into the field. If the field is already justified, no harm is done.

On line 2, the EVALR (eval with right-adjust) operation is used along with the %TRIMR built-in function to right-justify a field's data into the field.