View previous topic :: View next topic
|
Author |
Message |
peter_schaeffer
New User
Joined: 27 Jan 2021 Posts: 2 Location: USA
|
|
|
|
Folks, this may be the wrong forum for my question. If that is true, please indicate where my question should go.
At some point, I saw an algorithm that would take fields of different types and transform them (after copying them) into bytes that can be simply compared. For example, a simple two-byte integer can not simply compared because -1 (all foxes) will appear to be greater than 0 (all hex zeros).
Of course, the problems are not limited to two-byte integers or even integers of any size. For example, the sign nibble of a packed decimal field is at the right end (and that is only one problem with packed decimal).
If I remember correctly, there were special rules for integers, packed decimal, hex float, etc.
Does anyone know where I would find this algorithm? What the rules are?
Thank you in advance. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
the question as asked does not make any sense,
explain with examples what You want/need to compare ...
DFSORT provides on its own almost everything You need for comparisons
did You try to look at the dfsort manuals to get a reminder of the data types supported
a good place to start getting hints might be
www.ibm.com/support/pages/smart-dfsort-tricks
and ... there is no generalised algorithm ....
You have to define the rules of the comparable format , convert everything to that and proceed from there |
|
Back to top |
|
|
peter_schaeffer
New User
Joined: 27 Jan 2021 Posts: 2 Location: USA
|
|
|
|
Enrico-Sorichetti, I know that standard Sort programs such as DFSORT can handle almost any kind of data and do a proper sort.
However, my goal is somewhat different. What I would like to do is to transform my data so that it can be compared using a CLC. Of course, CLC will already work for simple (single-byte) EBCDIC strings.
However, for other types (such as signed integers and/or packed decimal data, etc.) CLC will not work without transforming the data.
At some point, I saw an algorithm for doing the transformations so that CLC would work. But I can't find it now. |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2012 Location: USA
|
|
|
|
peter_schaeffer wrote: |
For example, a simple two-byte integer can not simply compared because -1 (all foxes) will appear to be greater than 0 (all hex zeros). |
You must compare ANY value using SPECIFIC FORMAT, describing the data in this field, and how to deal with them properly.
FI - the field is considered as signed binary, and the comparison (-1) < (+1) is true. That is X'FFFF' < X'0001'
BI - the field is considered as unsigned binary, and the value looking like (-1) e.g. X'FFFF' is actually considered as (+65535), and it is greater than (+1) which is X'0001'.
If you tried to compare those values as CH (character format) then you'll get what you've got.
The same story with packed decimal, unpacked decimal, etc. formats. To say nothing about floating point formats.
As usually: RTFM... |
|
Back to top |
|
|
|