V5R4 RPG Enhancements
February 22, 2006 Ted Holt
|
The RPG compiler team is one fine bunch of practical people. From my perspective, everything they do seems to be motivated by the desire to help programmers do their jobs more easily, rather than by some theoretical, esoteric computer science concepts that have no practical value. (I will admit that I still haven’t quite forgiven them for not supporting MOVE, MOVEL, and MOVEA in free-format calculations, but I’m working on it.) Anyway, RPG V5R4 includes more practical stuff, which, thanks to Barbara Morris, I have the pleasure of sharing with you. Free Format Enhancements If you’re a free-format enthusiast, as I am, you’ll be happy about two enhancements. If you’re not using free-format calculation specs, then you have two new reasons to consider consigning fixed-format C specs to the old folks’ home, where they will be overjoyed to find themselves reunited with program-described files, the COMP op code, and indicators 01 through 99. First, V5R4 introduces syntax checking for free-format calculations. I realize that most people write perfect code that works right the first time, but klutzes like me, who need all the help we can get, really do need WDSc and SEU to point out syntactical errors. I’m tired of recompiling just because I forgot to end a command with a semicolon. Now, if IBM could come up with something to check for logic errors, I might have a chance to become a decent programmer! Second, if you have the SQL Development Kit, you may very well be happy to know that V5R4 allows you to place your SQL commands in free-format calcs. Begin the statement with EXEC SQL. Be sure both words are on the same line. Code the statement in free-format syntax across as many lines as you like, and end with a semicolon.
/free
exec sql
update SomeFile
set SomeField = :SomeValue
where AnotherField = :AnotherValue;
/end-free
EVAL-CORR The EVAL-CORR continues the hyphen-bearing tradition of the illustrious op codes Z-ADD, Z-SUB, and ON-ERROR. There the similarity ends. EVAL-CORR, which stands for Evaluate Corresponding, copies fields of one data structure to fields of the same name and compatible data definition in another data structure. At least one of the data structures must be qualified because the compiler won’t allow two unqualified data structures to have a subfield of the same name. Data structures that are defined with the LIKEREC keyword are automatically qualified. So what does “compatible” mean? It means this: If you can code a valid EVAL command between two subfields of the same name, EVAL-CORR will copy that data on your behalf. You can EVAL an alpha field into another alpha field regardless of the lengths of the two fields. You can EVAL a numeric to another numeric, even if the types and sizes are different. But you can’t EVAL a character field to a numeric one, or a numeric field to a timestamp, for example. Let’s look at an example. Suppose there are two physical files, OLD and NEW. OLD is the existing format, while NEW is the new format to which the data is being migrated. * OLD A UNIQUE A R DATAREC A IDNR 5P 0 A NAME 20A ALWNULL A DOB L ALWNULL A SEX 1A A RACE 1A A K IDNR * NEW A UNIQUE A R DATAREC A IDNR 7P 0 A NAME 20A A DOB L ALWNULL A SEX 1P 0 ALWNULL A RACE 1A ALWNULL A HEIGHT 3P 0 ALWNULL A WEIGHT 5P 2 ALWNULL A K IDNR Here are the differences.
One EVAL-CORR command would copy all data except the Sex field to the new file.
D OldRec e ds ExtName(OLDDATA)
D qualified
D NewRec e ds ExtName(NEWDATA)
D qualified
/free
eval-corr NewRec = OldRec;
The EVAL-CORR is equivalent to the following EVAL commands. eval NewRec.idnr = OldRec.idnr; eval NewRec.name = OldRec.name; eval NewRec.DOB = OldRec.DOB; eval %nullind(NewRec.DOB) = %nullind(OldRec.DOB); eval NewRec.Race = OldRec.Race; eval %nullind(NewRec.Race) = *off; The compiler lets you know what’s going on by generating messages that tell which fields will be copied and why the others won’t be. How much information you get depends on whether OPTION(*XREF) or OPTION(*NOXREF) was in effect during compilation. OPTION(*NOXREF) lists the fields for which assignment operations are not generated and why those fields are not compatible. OPTION(*XREF) gives you that information, plus the names of the fields that are compatible, plus additional information that may affect the assignment. EVAL-CORR may be used in either fixed-format or free-format calculations. When used in free-format calcs, it accepts the H, M, and R operation extenders. (There’s not enough room for an extender in the 10-character op code field of fixed-format calculations. Hmmm. Is that a third reason to switch to free-format?) I have more to say about EVAL-CORR below. PREFIX Learns to Take Away The PREFIX keyword appears in F and D specifications. It provides a way to modify the fields of an externally described record format when they are brought into the program during compilation. PREFIX has two parameters. The first is a group of characters that is to be prefixed to the external field names. The second is the number of characters to be replaced. As of V5R3, PREFIX could modify field names by adding a common character string to the beginning of each field name or replacing beginning characters with other characters. A value of zero replacement characters (the default value of the second parameter) means that the first parameter is prepended to each field name. A value greater than one indicates the number of characters that will be removed from each field name before the first parameter is prepended. A negative value means that the programmer needs to take a break, a very long one. As far as I know, prepended is not a real word, so maybe I could use a break myself. V5R4 gives PREFIX the ability to remove leading characters from field names without replacing them. To remove leading characters, the first parameter must have an empty value, which is indicated by two consecutive single quotes, and the second parameter must have a positive value to indicate the number of leading characters to remove. Here are some examples of PREFIX in action. Assume that all fields in some record format begin with the letters AA. These examples show how field AANAME might be modified.
The documentation Barbara Morris gave me suggested that EVAL-CORR might be of interest to shops where all fields of a given database file begin with a common prefix. This is by no means a far-fetched idea to me, because I sometimes work with an ERP package that uses a two-digit prefix convention. Stripping the two-digit prefix from two files, leaving only the base name of each field, would give me a convenient way to copy all applicable customer information into a new sales order, as illustrated by the following example.
D Customer e ds extname(CUSTMAST)
D prefix('':2)
D Order e ds extname(ORDERHDR)
D prefix('':2)
/free
eval-corr Order = Customer;
Improved Null Indicator Support If your database tables (physical files) allow null values, here is something else that applies to you. RPG does not allow variables to have the null value. A numeric variable, for example, must always have a numeric value, even if that value is zero. So what happens when a program reads a database field that has the null value? The program updates an internal variable, known as a null indicator, with a true or false value. The null indicator shows whether the field has the null value or not. You don’t access the null variable directly. Instead, you access it indirectly using the %NULLIND function with the field to which the null indicator pertains. Suppose a data structure is defined like a record format that includes null-capable fields. What happens if that data structure is passed as a parameter to a called program? In V5R3, the data structure is passed to the called program without the null indicators. The called program cannot determine if the data structure’s subfields have the null value or not. In V5R4, you may specify OPTIONS(*NULLIND) on the parameter definition in order to the pass the null indicator along with the data itself.
H alwnull(*usrctl)
FSomeFile if e k disk
D Xact ds LikeRec(SomeRec)
D
D SomePgm pr ExtPgm('ABCDE')
D CustRec LikeRec(XactRec)
D options(*nullind)
D
/free
callp SomePgm (Xact);
OPTIONS(*NULLIND) also applies to non-data structure parameters. For example, if you were to define a five-byte character prototyped parameter with OPTIONS(*NULLIND), you would be able to pass a null-capable five-byte character field or subfield to another procedure. Here are a few rules you have to follow if you want to pass null indicators with parameters.
XML in RPG The new RPG support for XML took me completely by surprise. After all, RPG doesn’t have op codes for CSV files, Excel spreadsheets, PDF files, or any other standard or widely used data format. Why XML? I see this support as yet more proof that the people of IBM are practical in their approach to RPG. It seems that everybody and his brother is struggling with XML, so IBM is trying to help. If you want to make an RPG program read XML, you must learn about two new op codes and two new built-in functions. The two op codes are XML-SAX and XML-INTO. Both of them extract data from an XML document, but not in the same way. XML-SAX uses the Simple API for XML to identify events–start document, end document, start element, end element, characters, etc. (The V5R4 RPG Reference has a list of all events.) When SAX finds an event, it notifies a procedure, which must determine what the event is and how to handle it. XML-INTO, on the other hand, already knows what sort of data it is looking for. That is, you can tell XML-INTO to get a name, an address, and a phone number, and it will pick out the data and put it into variables or feed it to a procedure. The two new BIF’s are %XML and %HANDLER. They are used within the parameter list of the XML-SAX and XML-INTO op codes. %XML tells these operations where to find the XML-formatted data. %HANDLER specifies the name of a procedure that will process the XML. This procedure could be a subprocedure that is part of the same program, or it could be a procedure in another module or service program. To explain how to use these op codes warrants an article in its own right, so I will quit now. The V5R4 reference has some good examples you can study and begin from. More Debugging Assistance Here’s an item of interest for those of us who can’t write three lines of RPG source code without cranking up the debugger. Before V5R4, the DEBUG keyword, which is part of the H specs, allowed only two values: *YES and *NO. In V5R4, DEBUG gets three new permissible values: *INPUT, *DUMP, and *XMLSAX. DEBUG(*INPUT) tells the compiler to retain unused input fields (the ones flagged with error 7031 in the compilation listing) in the program object. If you exclude unused fields, you will not be able to see the values of those fields while debugging. DEBUG(*DUMP) enables the DUMP op code in the module. DEBUG(*XMLSAX) tells the compiler to generate a special array, _QRNU_XMLSAX, to contain XML special words, but only if the module was created with a debug view. There is also more debugger support for null indicators. You may access the null indicators for the subfields of data structure x by referring to variable _QRNU_NULL_x. You may refer to subfield y in the same data structure by EVAL’ing variable _QRNU_NULL_x.y. It’s Not Rocket Science Those of you who were hoping for RPG support for complex numbers or matrix multiplication are out of luck. Those of us with more mundane tasks to accomplish, things like billing, shipping, buying, and paying, will find some help in V5R4.
Programmer’s Guide PDF:
Programmer’s Guide HTML:
Reference PDF:
Reference HTML: |
