(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:

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:

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:

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:

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.

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.