× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We’re apparently talking at cross purposes. I think I must have read your post backwards.

But I said nothing about the OPM compiler. I said "RPG III style op-codes” meaning the use of ADD/SUB/etc. in RPG IV.

We were both apparently talking about the same thing. Sorry for any misunderstanding.



On Nov 2, 2015, at 11:31 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 02-Nov-2015 17:01 -0600, Jon Paris wrote:
On Nov 2, 2015, at 4:58 PM, CRPence wrote:

Was not that overflow error prevented with the Truncate Numeric
(TRUNCNBR) specification of *YES, so as to "Ignore numeric overflow
and move the truncated value to the result field" [to mimic] just
like what happened in the older RPG? And that parameter
specification defaulted to *YES, so that problem would not become
an issue for that calculation with the newer compiler, unless
explicitly changed was the default or the explicit specification to
the value of *NO, asking to cause the overflow error to be exposed
at run-time? I was too lazy to test; but interested enough to
overcome my laziness to look up the parameter name, the parameter
help text, and the default :-)


No Chuck - in fact the exact opposite.

The point of TRUNCNBR is to make RPG III style op-codes such as
MULT/ADD/etc. behave the _same_way_ as their more intelligent RPG IV
operations i.e. to fail in the event of an overflow condition.


There is no Truncate Numeric feature on the OPM compiler command that I can find. I can find that parameter only on the ILE compiler commands. Perhaps thinking instead, of the Ignore Decimal Data Errors (IGNDECERR) parameter?

Just to confirm:

I compiled the following source having SRCTYPE(RPG), with the 14=Compile the command CRTRPGPGM effected a compile with defaults:


FQSQPTABLIP F 4 DISK
IQSQPTABLXX
C Z-ADD110215 MMDDYY 60
C MMDDYY MULT 10000.01 YYMMDD 60
C Z-ADD151102 YMD6 60
C YYMMDD IFEQ YMD6
C 'ALL GOOD'DSPLY
C ENDIF

The effect for CALL of the program was displaying the text "ALL GOOD".

I then converted the above source using CVTRPGSRC, which effected the following source [member having SRCTYPE(RPGLE)], after which with the 14=Compile the command CRTBNDRPG effected a compile with defaults:


FQSQPTABL IP F 4 DISK
IQSQPTABL XX
C Z-ADD 110215 MMDDYY 6 0
C MMDDYY MULT 10000.01 YYMMDD 6 0
C Z-ADD 151102 YMD6 6 0
C YYMMDD IFEQ YMD6
C 'ALL GOOD' DSPLY
C ENDIF

Just like the pre-converted program, the effect for CALL of the new program was displaying the text "ALL GOOD". There was no error.

To force the msg RNQ0103 to transpire instead, during run-time in response to the msg MCH1210, I had to explicitly specify the value *NO for the Truncate Numeric (TRUNCNBR) on the compile request.

Seems the default behavior for the new compiler was to honor [to mimic] the old\bad way of ignoring overflow for the simple MULT operation [while also moving the truncated result to the result field]. That seems only natural, to best protect someone who might be using the CVTRPGSRC and then just compiling their new source to replace the old; i.e. their expectation is that the program created [from the post-cvt src] with the new compiler should work the same as the program created [from the pre-cvt src] with the old compiler. From the help text is also the "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."; but that would not apply to a merely-converted source, because the older RPG did not have that capability, and CVTRPGSRC will not generate any code changes, for example to make use of an EVAL.

--
Regards, Chuck

--
This is the Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.