View previous topic :: View next topic
|
Author |
Message |
DavidZilch
New User
Joined: 13 Dec 2005 Posts: 2
|
|
|
|
Hi,
I have data that contains a sort key that is 22 bytes long. The first 8 bytes are constant alpha numerics (for now), 8 bytes random alpha/numerics (or 8 spaces), a space & then 5 bytes of 'FF'x
So a typical record is "4810375V2345679X ...."
These happen to be in a VSAM file but my results are the same in a sequential file.
If I sort using BI I get a very strangly sorted file. Records are all over the place and even ones that are the same are placed at several places through the file. The results are in a consistent order for every time I sort the file and sorting descending or ascending reverses the sequence.
Given that the first 8 characters are always the same I shortend my sort parms to start after them and the sort works as I would have expected in the first place. Extending the sort field wider shows that it is the row of 0's where the problem occurs.
If I use CH in my sort everything works.
It's obviously my understanding of what Binary data is in regards to DFSORT. Can someone explain to me where I am going wrong.
Thanks,
David |
|
Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
|
|
|
|
DFSORT sorts BI and CH data the same unless there's an option in effect that affects the collating sequence of the CH data like LOCALE or CHALT.
What you say you see with BI vs CH doesn't make sense to me. Especially the part where you say "Records are all over the place and even ones that are the same are placed at several places through the file". For sort, BI data is just a string of 1s and 0s.
Something must be going on that you're not mentioning (maybe you're not aware of it).
I'd need to see your complete JCL and control statements, the JES and //SYSOUT messages, a sample of the input records and a sample of the sorted output records. You can send them to me offline (yaeger@us.ibm.com) if you like. Just put "DFSORT" somewhere in your Subject line to catch my attention.
But one thing you might check out is whether DFSORT is treating the records as F or V and whether you have the corresponding starting positions specified correctly. Look at message ICE201I. If it says 'TYPE IS V', then DFSORT is treating the records as variable-length and the starting position has to account for the RDW in bytes 1-4. The first data byte starts at 5. If you're not counting the RDW, then add 4 to your starting position. But this wouldn't account for any difference you're seeing in the use of BI vs CH. |
|
Back to top |
|
|
DavidZilch
New User
Joined: 13 Dec 2005 Posts: 2
|
|
|
|
Quote: |
But one thing you might check out is whether DFSORT is treating the records as F or V and whether you have the corresponding starting positions specified correctly. Look at message ICE201I. If it says 'TYPE IS V', then DFSORT is treating the records as variable-length and the starting position has to account for the RDW in bytes 1-4. The first data byte starts at 5. If you're not counting the RDW, then add 4 to your starting position. But this wouldn't account for any difference you're seeing in the use of BI vs CH |
It was indeed that we had not taken into account the RDW. Thanks for pointing this out. |
|
Back to top |
|
|
|