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

Thanks for the replies, everyone!

On 12/16/05, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:
>
> > I don't think DDEs are an issue.  I'll have to check on *BLANKS and
> > numerics.
>
> Okay... DDEs are the same in RPG III and RPG IV unless you've specified
> IGNDECERR on the RPG III compile.  RPG IV has FIXNBR instead of IGNDECERR,
> and although they have similar purposes, they don't work identically.
>
> So, decimal data errors (as well as *blanks in a number) aren't an issue
> unless you were using the IGNDECERR workaround in RPG III.


OK, a little confused here.  I see the IGNDECERR parm on CRTRPGPGM (defaults
to *NO).  But looking at an RPG-III program object via DSPPGM is a bit
confusing.  Near the bottom of the first screen (v5r2, BTW), there is a line
"Fix decimal data" (its value is *NO).  Position cursor to that line and hit
Help and the Help panel is titled "Ignore Decimal Data - Help" but the
description is:

  The compiler may have allowed you to control this
  attribute through the FIXDECDTA parameter of the command
  used to create the program.  This parameter indicates
  whether decimal data that is not valid is corrected (*YES)
  or an error that the data is not valid is signaled to the
  program without correcting the data (*NO).

However, the help on the IGNDECERR on the CRTRPGPGM command doesn't say
anything about "fixing" the data, only that  *YES="Decimal data errors are
ignored."  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?

I'm not sure what TRUNCNBR is good for.  Help on this parameter reads:
  Note:  The TRUNCNBR option does not apply to calculations performed
  within expressions.  (Expressions are found in the Extended-Factor 2
  field.)  If overflow occurs for these calculations, an error will
  always occur.

Where else does numeric overflow occur?

   If there was a "MOVE *BLANKS   NUMBER" and NUMBER is numeric,
> > will the -IV compiler catch it?  Or will run-time act any differently
> than
> > it did under RPG-III?
>
> Correct me if I'm wrong, but neither RPG III nor RPG IV allows you to move
> blanks to a numeric field.  You'd have to go through a data structure to
> get them in there (or read bad data from a file or a parameter, etc).
> Should work the same in RPG IV as RPG III.


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).

Interesting.

Feedback appreciated!
- Dan