Tips and Techniques: Converting to Uppercase

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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:

P ToUpperEx       B
D ToUpperEx       PI            10I 0
D  szTextIn                   6000A   Value Varying          
D  szTextOut                  6000A   OPTIONS(*VARSIZE)
     
D upper           C                   'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
D lower           C                   'abcdefghijklmnopqrstuvwxyz'

C     lower:UPPER   xLate     szTextIn      szTextIn
C                   eval      %subst(szTextOut:1:%Len(szTextIn)) = 
C                               szTextIn 
C                   return    %len(szTextIn)
P ToUpperEx       E

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:

     D Name            S             25A   Inz('Robert Cozzi')    
     D NewName         S             25A
     
     C                   callp     ToUpperEx(Name:NewName)

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

     D Name            S             25A   Inz('Robert Cozzi') VARYING
     D NewName         S             25A
     
     C                   callp     ToUpperEx(Name:NewName)

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

     C                   callp     ToUpperEx(Name:NewName)

...is much more efficient than...

     C                   eval     NewName = ToUpper(Name)

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.

     P ToUpperEx2      B
     D ToUpperEx2      PI            
     D  szTextIn                  32766A   OPTIONS(*VARSIZE)
     D  nTextLen                     10I 0 Const
     
     D upper           C                   'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
     D lower           C                   'abcdefghijklmnopqrstuvwxyz'

     C     lower:UPPER   xLate     szTextIn      szTextIn
     C                   eval      szText = %xlate(Lower:UPPER:
     C                               %subst(szText:1:nTextLen))
     C                   return    
     P ToUpperEx2      E

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:

     D Name            S             25A   Inz('Robert Cozzi')
     D NewName         S             25A
     
     C                   callp     ToUpperEx2(Name:%len(%TrimR(Name)))

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 of the RPG xTools, a popular add-on subprocedure library for RPG IV. His book The Modern RPG Language has been the most widely used RPG programming book for nearly two decades. He, along with others, speaks at and runs the highly-popular RPG World conference for RPG programmers.

BOB COZZI

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 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 The Modern RPG IV Language
Cozzi on everything RPG! What more could you want?
List Price $99.95

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  •  

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: