(Author's Note: This week's article is an excerpt from my upcoming book RPG TNT: 101 Dynamite Tips and Techniques for RPG IV Programmers.)
The LIKE keyword works like this: When a derived field is defined using the LIKE keyword, it inherits the attributes (e.g., length; data type; VARYING, CCSID, and ALIGN keywords) of its reference field or data structure.
Although the LIKE keyword inherits the attributes of the original field, when you define the original field (a.k.a. the reference field) on the Input specification (externally described or program described), there can be an anomaly. When a zoned decimal variable from an Input specification is declared, the compiler converts that zoned decimal field to packed decimal. Don't believe me? Look at the field definition of a zoned decimal field declared on an Input specification in the compiler listing.
Here's a simple example to try:
IINPUT NS
I S 1 6 0iZoned
I P 7 10 0iPacked
In the above example, the derived field named MYZONED is defined as packed decimal even though its reference field, IZONED, is zoned decimal. This change in data type is due to the fact that the compiler converts all numeric fields declared on Input specifications to packed decimal. Since IZONED is defined on Input specifications, it is converted to packed decimal; hence, MYZONED also ends up being packed decimal.
To resolve this issue, redefine the input field in another Definition specification using the zoned decimal data type. Here's an example:
D iZoned S 6S 0
D myZoned S Like(iZoned)
IINPUT NS
I S 1 6 0iZoned
I P 7 10 0iPacked
This forces the definition of the IZONED field to be zoned decimal. Any derived fields that reference it (via the LIKE keyword) are also defined as zoned decimal.
Continually redefining zoned input fields can be tedious. An alternative to redefining each zoned decimal field by hand is to include the file's format in the program as an externally described data structure. When you do this, the record format of the file is used to create a data structure layout. All the fields of the file are generated as data structure subfields, using their original data types (no conversion to packed decimal is performed).
For example, this CUSTMAST file contains several fields, two of which are zoned decimal while the others are of various data types and lengths:
A R CUSTREC
A CUSTNO 7P 0
A COMPNAME 30A
A ORDDTE 8S 0
A SHIPDTE 8S 0
A ADDRESS 30A
A CITY 20A
A STATE 4A
A ZIPCODE 10A
A PHONE 11P 0
A EMAIL 64A VARLEN(32)
You can use this CUSTMAST file to create a data structure. Then, you can reference the zoned numeric fields ORDDTE and SHIPDTE to create derived fields that retain the zoned decimal data type, like so:
D CUST E DS ExtName(CUSTMAST)
D orderDate S Like(ORDDTE)
D shipDate S Like(SHIPDTE)
The derived fields named ORDERDATE and SHIPDATE are standalone fields, not part of the CUST data structure, and are defined as zoned decimal. The data structure named CUST does not necessarily need to be referred to in the program as we are only using the field definitions in this example.
Another option is the LIKEREC keyword introduced in OS/400 V5R2. The LIKEREC keyword, however, is not the same as EXTNAME. LIKEREC creates a qualified data structure using the current format of a file already defined in the program source. Since the compiler converts numeric input fields from zoned to packed, the data structure generated by the LIKEREC keyword also contains packed decimal field definitions. Thus, no progress is made. In addition, when deriving fields from a data structure created with LIKEREC, you have to be sure to specify the data structure and subfield name using qualified syntax; otherwise, you will not reference the proper subfield.
The following example demonstrates how zoned decimal fields defined on Input specifications (program described or externally described) are converted to packed decimal by the compiler. Then, when they're used as a reference field to create derived fields, those derived fields also become packed decimal.
A R EXTERNREC
A XZONED 6S 0
A XPACKED 7P 0
** Example RPG IV Source
** Demonstrates LIKE keyword usage.
FEXTERN IF E DISK
FINPUT IF F 64 DISK
D myZoned S 6S 0
D myPacked S 7P 0
// This field ends up as Zoned.
D lZoned S Like(myZoned)
// This field ends up as Packed.
D lPacked S Like(myPacked)
// All four of these fields end up as Packed.
D liZoned S Like(iZoned)
D liPacked S Like(iPacked)
D lxZoned S Like(xZoned)
D lxPacked S Like(xPacked)
IINPUT NS
I S 1 6 0iZoned
I P 7 10 0iPacked
I've seen this anomaly a bit more than I care to remember. There are other issues of similar style in the compiler, such as data types with externally described files, but that's a topic for a future article.
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.
LATEST COMMENTS
MC Press Online