Lately, I've been asked more questions on this topic than on any other: "How do I convert numeric data stored in a character field to a numeric field, when the character field also has some non-numeric elements in it?"

This situation occurs when you have a character field that contains a number as well as other pieces of data--such as edit codes or EDI symbols--or just plain old garbage.

Suppose you just read a record from an EDI transaction or from a Web page. All the data comes into the program in character form. In this case, the data is numeric and is transferred in character format, along with some garbage. Here's an example:

Not very pretty, is it? So how do you convert this value from character to numeric? Or, the question I get all the time: "Is there an easy way to convert character to numeric and remove the garbage from the character field?" The operative word here is "easy." That word does, however, make the answer rather easy: No, there is no easy way to do this.

Filtering Garbage

One of the first things we learn in computer programming classes is the now infamous "garbage in, garbage out" saying. If we have garbage coming into the program, we're probably going to get garbage going out of the program. But why not create a subprocedure that fixes up the data by filtering out the garbage?

To solve this problem, we need to think critically. So let's look at the problem. The data is stored in a character field. Throughout the numeric data, there are non-numeric symbols and embedded blanks. We need to take that value and somehow return only the pure numeric value (with the decimal point, if applicable).

The first thing we need to do is isolate the garbage data. That is, the non-numeric data needs to be removed. In this case, it is the left and right brackets and parentheses, but we really want to do that dynamically (not hard code it), so we need a solution.

The solution I've come up with requires only one line of code to do the isolation and then a few more lines to format the data to be removed.

I've selected the XLATE opcode to do the work for me. It allows us to translate data from one set of characters to another. For example, we could easily convert lowercase letters to uppercase with XLATE.

For our purposes, we need to isolate the garbage data so that we can subsequently remove it. Therefore, what we need to do first is delete the numeric data--that's right, delete the numeric data--so that we have a variable that contains only the garbage we want to remove. Figure 1 illustrates how to accomplish this task.

Figure 1: This routine isolates the garbage.

The work field named SAVEME contains the characters we will eventually want to keep. However, since the goal of this step is to isolate the non-numeric data, we need to figure out what characters are present in the original character variable. So we translate the numeric values into blanks, thus leaving only the garbage.

Now that we have the garbage isolated, we need to compress out embedded blanks so that there's not a lot of redundancy in translating blanks into blanks.

If we had the RPG ToolKit available for this example, we would simply use the FINDREPLACE() procedure and be done with it in one statement. However, I have decided to use this opportunity to illustrate the %SCAN and %REPLACE built-in functions and show how you can use them to accomplished the same task, albeit with several more lines of code. Figure 2 illustrates how to compress out the embedded blanks that resulted from the originally isolated garbage text.

Figure 2: Compress out embedded blanks.

In Figure 2, we scan the GARBAGE variable for a blank. If a blank is found, the %REPLACE built-in function deletes the embedded blank from the variable. Since GARBAGE is a VARYING field, when we reach the end of the field, 0 is returned from the %SCAN built-in function, and we know it has completed.

A little-known fact about %REPLACE is that if you specify an empty value for the first parameter, you can delete text from within the variable. The position of the text to be deleted is specified on the third parameter, and the number of characters to be deleted is specified on the fourth parameter. An empty value, by the way, is two consecutive apostrophes without any embedded blanks.

Once the compression routine has run, the value of the GARBAGE variable will be as follows:

Note that all the embedded blanks are removed and the garbage characters are up against one another. We now have a clean list of garbage to be removed from our original numeric string. Removing the garbage now becomes a one-line operation, as follows:

The XLATE opcode is used once again, but this time it removes the garbage from the original character string. Note the fixed-length field named BLANK in Factor 1 of the XLATE operation. I'm using this instead of *BLANKS or ' ' because I want a one-to-one match of the garbage to blanks. I supposed I could have made BLANKS a VARYING field and then set its length to be equal to the length of GARBAGE, as follows:

But I'm not sure that would add any benefit to the task at hand.

Once the XLATE operation has run, the original string, which looked like this...

now looks like this:

The next step is to compress the digits together. Fortunately, we just wrote a routine to do that with the garbage data, so we clone that routine and modify it to work with the digits, as illustrated in Figure 3.

Figure 3: Compress out blanks from the numeric value.

The only difference between the routine in Figure 3 and the routine in Figure 2 is the field name on which it is operating. If RPG IV had a macro capability, I would have written a macro to do this task. I could have also created another subprocedure to do the compression, and you might consider doing that for your implementation.

And that's it. The data is now clean. What was once this...
'<<12,345.67>> (())'

is now this:
'12345.67'

If you are on OS/400 V5R2, you can use the %DEC built-in function to convert this value to numeric. If you are on V5R1 or earlier, you would use the CharToNum() procedure in the RPG ToolKit or the MOVE opcode, if applicable.

Figure 4 contains a complete working source member that demonstrates the capability of this routine. It's all wrapped up nicely in a standalone subprocedure named CleanDec().

Figure 4: CLEANDEC cleans up a character field that contains numeric data so that it can be converted to a real numeric field.

To compile the code in Figure 4, use PDM option 14 or 15. Use PDM option 14 when you want to test and demonstrate the subprocedure using something like STRDBG, for example. Use PDM option 15 to create a *MODULE object that could be stored in a service program or bound by copy into your program.

Bob Cozzi has been programming in RPG since 1978. Since then, he has written many articles and several books, including The Modern RPG Language--the most widely used RPG reference manual in the world. Bob is also a very popular speaker at industry events such as RPG World and is the author of his own Web site and of the RPG ToolKit, an add-on library for RPG IV programmers.

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