Re: Eval-corr

On 14 May 2013 07:09, Buck Calabro wrote:

On 13 May 2013 17:25, Barbara Morris wrote:

On 5/13/2013 10:47 AM, CRPence wrote:

...
Does that claim imply that the 12 byte string [with character b
representing blanks] 'bbbbbb-79349', when stored in a zoned
decimal variable, will compare as less than a zero value? Please
tell me that is not so!

As requested, "That is not so." :-)

'bbbbbb-79349' would be handled the same as '000000079349', so it
would not compare less than 0.

<<SNIP>>

The reference I'd cite: "If you move a character field to a zoned
numeric, the sign of the character field is fixed to zoned positive
or zoned negative. The zoned portion of the other bytes will be
forced to 'F'. However, if the digit portion of one of the bytes in
the character field does not contain a valid digit a decimal data
error will occur."

ILE RPG Reference, IBM i 7.1 Information Center-> Programming->
Programming languages-> RPG-> ILE RPG Language Reference->
Definitions-> Chapter 9. Data Types and Data Formats->
Numeric Data Type-> Considerations for Using Numeric Formats
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzasd/sc092508280.htm

The difference between "ignoring" and "fixing" [aka "correcting"] the zone portion of the [sign] digit data _can be_ a *very important* distinction. The given doc refers to /moving/ data and /correcting/ the numeric data, by literally changing the zone portion on each byte. For the given scenario, it is obvious that the effects described in that quoted doc was not put into effect for the zoned decimal variable. Although there was an assignment of the DS to the value of the buffer data, that did not effect any such correction, even though that request effectively /moved/ the data into a zoned decimal variable. That is because the movement was actually from a character [buffer] to a character [DS] rather than being assigned\MOVEd from character data scalar to a zoned numeric scalar.

Using instead the MOVE opcode to move the 12-byte character data into the 12-byte zoned decimal variable, the result will actually be /corrected/ zoned BCD data; i.e. the zone portion of all digits will be changed, with the non-sign digits all set to the x'F' and the sign digit set\forced to x'F' if not already x'D' or x'F'. I am unsure why RPG does that, because to be consistent with the MI numeric algorithms, all of the x'A' to x'F' are valid sign digits, with the x'B' as a valid negative. The zone portion for the sign digit would *not* be forced to x'F' from x'B' by the MI numeric algorithms because that is a valid sign digit to denote /negative/ and thus it would be forced to x'D'. Yet another inconsistency :-(

In this case I expect that the zoned portion of the digits was merely /ignored/ for the comparison; at least we know the original data [in the variable being compared] remained /unchanged/ as far as the programmer is concerned. If the effect of the proper comparison is due to the value being copied into a packed decimal intermediate that is then used for the actual comparison, or that the value was /corrected/ into an intermediate [as would the MOVE] that is then used for the actual comparison, or that the comparison algorithm actually just skips\ignores the zoned portions in comparing just the nibbles... I do not know [the actual implementation].