Over the years, I've published a few articles on using QlgConvertCase and XLATE to convert lowercase to uppercase and uppercase to lowercase. One of the problems with those examples is that they use a long return value to return the converted text to the caller. As you may know, returning long character strings to the caller from a procedure is painfully slow. To improve performance, we have two choices.

• We can pass two parameters, convert the data to uppercase, and copy it to the second parameter.
• We can convert the input parameter itself.

Let's look at each of these options.

First, passing two parameters will require that the length of the data coming into the procedure be implied. To do this, we use the VARYING keyword. This causes the input parameter to be converted into a variable-length field. Thus, we can use %LEN to determine the length of the data passed to the procedure. To do this, however, we also have to specify CONST or VALUE for that input parameter. Otherwise, we would only be able to convert variable-length fields. Specifying CONST or VALUE allows us to convert either fixed- or variable-length fields.

Here's the code for this style of conversion:

In this example, the first parameter, szTextIn, is a variable-length field passed by VALUE. The VALUE keyword causes the compiler to copy the input value to a work field, which is then passed down into our procedure. The benefit of VALUE over CONST is that we can use the input parameter as a work field in our procedure; that is, we can modify the content. So rather than copy the data to a local variable, we simply use the input parameter itself. Since the compiler generated code to copy our input value to a work field, the data we are changing is a copy of the data, not the original data itself.

The second parameter uses the OPTIONS(*VARSIZE) keyword. This keyword allows a variable of any length to be specified. Our procedure will only be able to access up to 6,000 bytes of that variable (which should be plenty). Without OPTIONS(*VARSIZE), the input parameter specified when calling this procedure would have to be at least 6,000 bytes in length. Not a likely scenario.

You would use the following syntax to call this procedure:

This syntax is pretty clean and easy to use with fixed-length fields. You could also do this, however:

This technique would improve performance because VARYING fields have a "current" length. The current length of the NAME field is 12 positions (the length of text "Robert Cozzi" in the initial value keyword). This means that 12 bytes will be converted instead of the entire field--a subtle yet important point if performance is a concern.

By avoiding the long return value, the compiler does not need to copy the data back to the caller; that is done by the assignment statement in our procedure. In addition, when a long return value is returned, not only does the compiler copy it back when you do the return, but that copied value gets copied once again into the original place of the call to the procedure. Then it gets copied to your variable by an EVAL opcode. So, for example...

...is much more efficient than...

But can we be even more efficient? Yes. If you can allow the data to be maintained in place--that is, if the requirement is to convert a field to uppercase rather than copy the uppercase version of the data in one field to another field--then there is an even better solution.

With this technique, you have to tell the procedure how many characters to convert to uppercase. You are also restricted to converting the existing data, not a copy of it. So this particular technique may not work in most situations.

You would use the following syntax to call this procedure:

To calculate the length, we use %TRIMR and %LEN. If you don't need to do the %TRIMR, you'll save even more time, but that function's performance has been improved, and a copy of the data is no longer made by the compiler. So it isn't as much overhead as it used to be.

This technique uses %XLATE instead of the opcode to convert the data to uppercase. IBM cleverly added a starting position to %XLATE so we can start the translation after a certain position; however, they foolishly avoided allowing us to indicate the number of characters we want to translate, so I had to use a nested %SUBST to make it work correctly.

There are always multiple ways to do things in RPG IV. Finding the best solution is up to you.

Bob Cozzi is a programmer/consultant, writer/author, and software developer. His popular RPG xTools add-on subprocedure library for RPG IV is fast becoming a standard with RPG developers. His book The Modern RPG Language has been the most widely used RPG programming book for more than a decade. He, along with others, speaks at and produces the highly popular RPG World conference for RPG programmers.

---

MC Press books written by Robert Cozzi available now on the MC Press Bookstore.

		RPG TnT Get this jam-packed resource of quick, easy-to-implement RPG tips! List Price $65.00 Now On Sale
		The Modern RPG IV Language Cozzi on everything RPG! What more could you want? List Price $99.95 Now On Sale

Also Read

Programming in ILE RPG - Defining Data Structures, Part I

H and F Position-less Specs

Practical RPG: AI and IBM i