RE: RPG-III to -IV conversion rehash worries - Part II

The only way to determine whether an RPGIII program was compiled with
IGNDECERR(*YES) is to place it in debug.  The technique is in the archives
somewhere. 

Ignoring a decimal data area in an RPGIII program means the field is set to
0 so it can be processed, I believe, but I don't know that for certain.  I
do know that routine use of this option can cause great havoc in a system. 

The defaults for CRTRPGPGM and CRTBNDRPG do correspond, I believe.  You
would only have an issue if someone changed the default for CRTRPGPGM or
compiled all RPGIII programs with IGNDECERR(*YES) as a matter of course. 

After you place *BLANKS into those numeric fields, what happens if you try
to use the numeric field in another operation like ADD or IF?  "ABCDE" is
translated into "12345" by EBCDIC.  Try letters like "PQRS". 

Donald R. Fisher, III
Project Manager
Roomstore Furniture Company
(804) 784-7600 extension 2124
DFisher@xxxxxxxxxxxxx

<clip>
Ignored is not the same as fixing, IMO.  But, if someone can
confirm that these are one and the same, then the program I am converting is
not fixing nor ignoring DDE's.

Also, FWIW, the defaults for CRTBNDRPG include TRUNCNBR(*YES) &
FIXNBR(*NONE), so does this "match" the default behavior of CRTRPGPGM's
defaults?
<clip>
Surprise, surprise!  RPG-III:
  H        1
  C                MOVE *BLANKS   NUMBER  50
  C                DUMP
  C                SETON                     LR
Compiles fine, RUNS FINE!  The dump shows:
    NUMBER   001176  PACKED(5,0)   0

RPG-IV:
  H DEBUG
  C          MOVE      *BLANKS       NUMBER            5 0
  C          DUMP
  C          SETON                                        LR
Compiles fine, RUNS FINE!  The dump shows:
  NUMBER            PACKED(5,0)      00000.       '00000F'X

When I substituted 'ABCDE' for *BLANKS in those two apps, both dumps
reported NUMBER = 12345 (and RPG-IV dump also showed '12345F'X).
<clip>