Re: Different results *like define opcode RPG/400 versus RPG/IV

[Hans Boldt <boldt@xxxxxxxxxx>]

L. Maartens wrote:
> I have different results using the *LIKE DEFINE opcode in RPG/400 and, after
> converting, in RPG/IV.
>
> For example in program A:
> - file TEST is used, which contains a field named NUMB: Zoned 8,0
> - there is a datastructure where the record format of TEST is externally
> described (field NUMB = Zoned 8,0)
> - there is *like define opcode, where field PGNUMB is defined like field
> NUMB
> - program B is called
>
>
> RPG/400:
> -------
> FBGFIATL2  UF   E           K DISK
> IDSTEST    EIDSTEST
> C           *LIKE     DEFN NUMB      PGNUMB
>
> When looking at the Field references in the compiler listing, I see that:
> - field NUMB is Zoned decimal 8,0
> - field PGNUMB is Packed decimal 8,0
>
>
>
> After coverting to RPG/IV:
> -------------------------
> FTEST      UF   E           K DISK
> D DSTEST        E DS                  EXTNAME(TEST) INZ
> D PGNUMB          S                   LIKE(NUMB)
>
> When looking at the Field references in the compiler listing, I see that:
> - field NUMB is Zoned decimal 8,0
> - field PGNUMB is also Zoned decimal 8,0 and not packed as in RPG/400.
>
> In program B:
> PGNUMB is also defined via *LIKE DEFINE, but without datastructure DSTEST,
> PGNUMB is Packed 8,0, both in RPG/400 and in RPG/IV (as RPG converts Zoned
> to Packed for internal usage).
>
> When RPG/400 program A calls RPG/400 B there is no problem.
> When ILE program A calls ILE program B, I get a decimal data error on PGNUMB
> as the two field formats PGNUMB differ.
>
> Is this a known problem ? Is there maybe a PTF which solves this?

Loek:  Regarding LIKE definitions, this is working as designed as a
result of customer requests for a LIKE function where the field being
defined should have the same format as the original.  *LIKE DEFINE will
define numeric fields with packed format,  but coding LIKE on a D-Spec
defines the field with the same format as the original.

Some 3rd party conversion tools are a little too aggressive in their
conversions, and although they may improve the "style" of the program,
the resulting program may not work quite the same way as the original.
If you use CVTRPGSRC (which comes with the RPG IV compiler, the
semantics of the program should remain largely the same.

(One common possibly incompatible conversion of the 3rd party tools is
to convert the old style fixed format arithmetic operations to
expressions.  This is usually a good thing, since it will clearly
identify bugs in your code where numeric overflow occurs.)

This also raises the frequently asked question of how RPG defines the
format of numeric fields.  First, when the format entry is blank for
numeric fields, the default is packed decimal for standalone fields and
fields defined on C-Specs and I-Specs that don't have an explicit
definition on a D-Spec.  For subfields, the default numeric format is
zoned decimal.  Furthermore, numeric subfields defined in externally
described data structures are defined using the format defined in the DDS.

What can you do?  First, you could continue to use *LIKE DEFINE to
define that particular numeric field.  Second, you could look at how
that particular numeric value is used when passed to the other program.
  If program B does not change the value of the numeric variable, you
could pass it as a CONST parameter, and in that case, RPG will convert
the numeric parameter value to the proper format.

Cheers!  Hans