IBM Mainframe Forum

Hello,

The below SORT:


yields:


Whereas, when 'ZD' is changed to 'PD', it returns:


Query: What is causing the difference in behaviour (the dropping of second record) when 'ZD' is coded?
I am fairly confident that I am misunderstanding how packed-decimal-data and zoned-decimal-data is read byte-per-byte, when the input format itself is PD.

It will be very helpful if one can guide on this.

Thank you!

You are using the wrong format ZD
and the wrong length for PD

the first three chars are NOT ZD/PD numbers

for the PD format the length should be 4

reread the principle of operations to get a grasp of number representations

Thank you for the inputs Enrico; indeed you're right on the PD length for 4 bytes, and data-wise it is '2020008C' (for example).
But my query was when this same data is tested with '1,3,ZD' format, what are the actual data-bytes out of '2020008C' being checked.

I will revisit the POP manual for details around PD/ZD data bits.

The data values in first 3 bytes - X'202002', and X'202000' - are neither ZD, nor PD data.

There is nothing to talk about. The example is just wrong from the very beginning.

Period.

Hello Sergey,

As stated in my response to Enrico, I am aware that the data format for initial 3 bytes doesn't correspond to PD or ZD data types.
This is an example of badly written code from a live environment, which has now been rectified; so while the example is questionable - it is a replica of a live ecosystem.

My query was when coded in the manner it is coded currently, how does *SORT process these 3 bytes, which makes it drop 1 record or select it when coded differently; because either way *SORT doesn't return a warning, it processes these basis its interpretation of data types.

Since this is a very trivial question (thus the forum-section where this query was logged), but it has got me stumped on how *SORT treats such data for processing.

I have been away from mainframes for a few years hence my basics are rusty, and I am going through POP to get my head around this, but any guidance/pointers to the aforementioned crux-of-the-query are deeply appreciated.

I suspect that SORT is packing the ZD data for the comparison to zero -- in which case X'2020008C' would pack into X'000' since the zones would be discarded when packed, and X'2020020C' would pack into X'002' and thus the difference in behavior.

Greetings and wishes for the new year Mr. Sample.
You're spot on; I wasn't sure, but reading your reply it does make sense; as always thanks a ton.

ZD in INCLUDE COND instructs *SORT to process the data as zoned-decimal, since an identifier for the same is not found in the data being processed, it will be packed to nearest translated value, hence the actual data being compared would be '000' or '002'. In case of PD the zones will be picked as-is, hence the different results.

Why not just to run a primitive test, to get all answers immediately???!!!