But what is really important to us lowly old RPG coders is what IBM has done to the development tools and to RPG. I can safely and summarily report that nothing has been done to SEU and PDM. Yes, IBM still believes we all use CODE/400 or CodeStudio, but only about 1 out of 40 of us seems to get it.

There is more news in V5R2 regarding RPG IV. This marks the first time IBM has enhanced the language in two consecutive releases since V3R2. Let's take a look at some of the RPG IV enhancements in V5R2.

Increased Numeric Field Length

Packed and zoned decimal fields may now be declared with up to 31 digits (up from 30). This subtle increase was added to provide compatibility with tables created with SQL. A new keyword is added to the Header specification. The DECPREC(31) keyword causes all expressions to use 31 digit numeric "work" fields. The keyword is not needed to simply use a 31-digit number.

Converting Character to Numeric

A long-standing requirement in RPG has been to convert number data stored in a character variable to a numeric variable. You could do this on a limited basis using the traditional MOVE opcode; however, there was no way to do this with an EVAL operation.

In V5R2, IBM is adding integrated character-to-numeric conversion to several built-in functions, including %DEC, %INT, and their associated variations. This means that if you have a numeric value stored in a character string, moving it into a valid numeric field will be unbelievably easier than before. For example:

The above example would result in the QTYSOLD field being assigned the number 18. This will come in very handy for all those CGI RPG and XML applications being created.

Data Structures Enhancements

The first thing you'll notice in V5R2 with regard to data structures is that IBM has deprecated the OCCURS keyword by introducing the DIM keyword for data structures. By using DIM, a data structure occurrence can be accessed using the same syntax as an array. This means the OCCURS opcode also becomes passé.

The overhaul of the data structure feature didn't stop there. V5R2 also introduces the concept of nested data structures--data structures that have a subfield that is also a data structure. Each nested data structure may also have the DIM keyword, providing a capability to RPG IV previously seen in C, C++, and Java.

To declare a subfield as a data structure, IBM enhanced the V5R1 LIKEDS keyword. In V5R2, LIKEDS may be specified on a data structure subfield, causing the subfield to inherit the properties of the referenced data structure.

To access a value in a subfield data structure, traditional RPG IV array syntax is used. That is, the data structure name is followed by the index, with the index enclosed in parentheses. See line 12 in Figure 1 for an example.

Figure 1: Data structure "arrays" and qualified subfield syntax

As mentioned, the LIKEDS keyword may now be specified for a data structure subfield, thus providing a nested data structures feature to RPG IV. In addition, the INZ keyword accepts a new option of INZ(*LIKEDS). This option causes the subfields of the new data structure to inherit the initial values from the subfields of the referenced data structure.

Storing RPG IV Source on the IFS

With the combination of CODE/400, Eclipse, and CodeStudio, you probably have close to five percent of the RPG developers in the world using a non-SEU solution for RPG source code editing. These tools read and save the source code onto a local PC disk or on the Integrated File System (IFS). Then, when the program needed to be compiled, the source needed to be moved into a traditional OS/400 source file member. With IBM's support for IFS in V5R2, the RPG IV compilers can compile RPG IV source directly from a text file stored on the IFS. The new SRCSTMF parameter of the CRTBNDRPG and CRTRPGMOD commands identifies the IFS source file name to compile. This is a nice option, but, of course you can continue to use the traditional source file and member structure that is familiar to you.

Short-Form Expression Arithmetic

One of the nice things about the traditional RPG ADD, SUB, MULT, and DIV operation codes was that they supported short-form syntax. That is, Factor 1 could be omitted from the operation code, and the Result field would be used in its place. Enter the EVAL opcode and free-form arithmetic. Unfortunately, the initial implementation requires complete expressions--no short-form support. So X=X+1 was required to add 1 to the variable named X. In V5R2, IBM has added short-form expression arithmetic, which allows you to omit the replication of the result variable on the left side of the expression. So to add 1 to X using the new short-form operation, X+=1 would be specified.

Short-form operations are now supported for +, - , *, /, and ** operations.

Bitwise Built-In Functions

Continuing its tradition of introducing new built-in functions in each release, IBM has nearly completed the expression support in RPG IV by introducing bitwise built-in functions. These include bitwise AND, OR, XOR, and NOT. One nice feature of these built-in functions is that they are supported on both the Definition and Calculation specifications. This means that the bitwise built-in functions may be used in expressions and as the initial value for fields.

Potpourri

A few other enhancements to RPG IV in V5R2 include the ability to specify a variable name for the name of the external data area (are people still using data areas?). Program Call Markup Language (PCML) generation by the compilers allows PCML tags to be generated so that your RPG program can be called by a Java application.

The new keyword LIKEREC allows you to declare an externally described input file record format and then use that record format as a template for a data structure. The LIKEREC keyword works similar to the LIKEDS keyword, except the referenced item is an externally described record format.

The database I/O opcodes--such as CHAIN, UPDATE, WRITE, READ, and READE--will support a list of field and host variable names that allow them to support a level of functionality similar to embedded SQL I/O commands.

The EXTNAME keyword, used for externally described data structures, can now be tailored to include only input, output, or keyfields from the external file.

Summary

All in all, this release has a couple of great enhancements, such as the updates to the %DEC and %INT built-in functions, and the DIM keyword on data structures. Some things, such as the V5R1 QUALIFIED keyword continue to confuse me. Do I need to always use it? Do I need to not use it? Is it required here and illegal there? Do I use it only when I use LIKEDS or only when I don't use LIKEDS? Is it implied when I use LIKEDS? If so, why not make it a global implication and eliminate it altogether? Not my favorite implementation. QUALIFIED should probably have never seen the light of day.