Understanding how to use the EVAL op code and the %CHAR, %EDITC, %EDITFLT, and %EDITW BIFs will help you remove even more of those MOVE and MOVEL statements from your code.

One of MOVEL's many uses is the implicit data type conversion from numeric to character. You probably have quite a few of these conversions in your code and don't even realize it. While they're not as error-prone as the reverse operation, it's preferable to have a more controlled conversion, especially because many of these operations are part of something that the end-user will see—either a message on the screen or a line on a printout, for instance. As usual, there are several ways to do this.

Converting Numeric Data to Character with %CHAR

There’s not much to say about %EDITC, %EDITW, and %EDITFLT because they're quite straightforward. There are a few examples of each in this article. So let's start the article by discussing %CHAR. This BIF converts the value of the expression from numeric, date, time, or timestamp data (and others that I won't mention to keep things as simple as possible) to type character. The converted value remains unchanged but is returned in a format compatible with character data. In other words, the numeric value 123.456 becomes the string '123.456' when you pass it as the first parameter of %CHAR. Just like the BIFs presented in a previous TechTip, %CHAR has a mandatory parameter—the expression to be converted to character. It also has an optional parameter that allows you to specify the format in which the converted data will be presented. For instance, for a Date expression, you can specify *ISO in the format parameter:

D MyDate         S               D   INZ(D'2014/11/16')

D result         S           100A   VARYING

(…)

C                   EVAL    result = 'Today is ' + %CHAR(MyDate : *ISO)

* "result" is now 'Today is 2014-11-16'

However, you can use the format parameter only with certain data types, such as date, time, and timestamp, because those are the data types that have predefined formats. There's no predefined format for a decimal, for instance. So, to "beautify" a decimal expression when converting it to character, you need something else. If you think about it, you probably know the answer already: how do you format numeric fields on a display file? You use either an edit code or an edit word, right? Well, turns out that those familiar concepts also exist as BIFs. Let's go over %EDITC first.

Using Edit Codes and Edit Words to "Beautify" Numeric Data

The %EDITC BIF has two mandatory parameters: the numeric value to be converted and the edit code to apply. It also has an optional parameter that can have one of three values:

• *ASTFILL, which replaces the leading zeros with asterisks. For example, %EDITC(-0012.3 : 'K' : *ASTFILL) returns '***12.3-'.
• *CURSYM, which indicates that a floating currency symbol is going to be inserted in the converted string, just before the first significant (non-zero) digit. For instance, %EDITC(0045.6 : 'K' : *CURSYM) returns '   $45.6 '.
• A user-specified currency symbol. It must be a 1-byte character constant (literal, named constant, or expression that can be evaluated at compile time). This means that %EDITC(0078.9 : 'K' : '£') will return '   £78.9 '.

If this isn't enough for you, you can always use %EDITW. It's similar to the DDS keyword, and you can use whatever edit word you want, as long as you follow some rules, described in the Parts of an Edit Word section of IBM's ILE RPG Reference Manual. Just to consolidate this, here's an example adapted from the same manual:

D amount         S             30A

D salary         S             9P 2

D editwd         C                   '$ ,   , **Dollars& &Cents'

 * If the value of salary is 2451.53, then the edited version of

 * (salary * 12) is '$***29,418*Dollars 36 Cents'. The value of

 * amount is 'The annual salary is $***29,418*Dollars 36 Cents'.

C                   EVAL    amount = 'The annual salary is '

                            + %EDITW(salary * 12 : editwd)

Just a note of caution: neither BIF accepts float expressions. If you need to convert a float, then convert it to decimal format first, using either %DEC or the %EDITFLT BIF. I usually don't use the %EDITFLT BIF because it returns the float expression as the character external display representation of float. For example, if you have a float variable containing 2.3, applying %EDITFLT to it will return the string "+2.299999999999999E+000". It might not be exactly what your user is expecting, so it might be best to use %DEC, customizing the precision and decimal places to your needs. This can be achieved in a single step, using a BIF within another BIF, something like %EDITC(%DEC(<float variable name> : <precision> : <decimal places>) : <edit code> ).

Yet Another Use of MOVE You Can Do Without

Finally, there's yet another common use of MOVE and MOVEL that you probably have in your code: sometimes a customer ID or a product code is a big number, but in reality is a concatenation of two or more codes. For instance, I've seen customer IDs that started with the sales channel, followed by the customer country ISO code, and ended with the customer number. At first glance, it's simply a huge number that's being decomposed using MOVE, MOVEL, and three variables. In this type of situation, you can use an EVAL op code and a data structure to replace those pesky MOVEs. Let's take this example and assume that the complete customer ID has 10 characters: 1 for the sales channel, 3 for the ISO country code, and 6 for the customer ID. You'd use a series of MOVE and MOVEL statements to extract each part from the customer ID.

Or you can use a data structure that mimics the internal structure of the customer ID, like this:

D                 DS              

D CUST_ID               1     10

D SAL_CHN               1     1

D COUNTRY               2     4

D CUST_NBR               5     10

D P_CUST_ID       S             10   INZ('1351000024')

(…)

* Using the data structure fields to decompose the customer id

C                   EVAL    CUST_ID = P_CUST_ID

 * After this operation: SAL_CHN = '1', COUNTRY = '351'

 * and CUST_NBR = '000024'

It's not mandatory that all fields of the data structure share the same type; you can mix types freely. Just be careful because, as I said before, the implicit conversions might not always work as you expect. A side note: another way to define a data structure involves using the OVERLAY keyword instead of the from/to positions. I'll talk about that later in the series.

That's all for now! The next TechTip will continue to explore the BIFs RPG provides, focusing on the ones that are related to string operations.

I hope that these tips will help you remove MOVE and MOVEL from your source code. Contribute with your own techniques, ideas, and questions in the comments section below or in the LinkedIn groups where these TechTips usually pop up.

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.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