I expect the 1st 142 bytes OF THE SORTOUT of both the runs to compare equal since i the SORTIN dataset is compare equal in the 1st 141 bytes
The difference in the i/p file structures of the 2 runs is that the field @ 142 is 2 bytes in BASE & it is 3 bytes in the CHANGED JCL
The o/p shows paired changes.
So i checked the o/p for each sort card by adding the cards incrementally E.g. a run with
SORT FIELDS=(142,2,CH,A)
then
SORT FIELDS=(142,2,CH,A,
1,3,CH,A)
,etc
In this case the SORTOUT compare equal And after adding all the cards i found no difference as well. I do not understand why. Pls throw some light.
The i/p files have atleast 10000 records So i dont know if i can ZIP & ATTACH in this forum _________________ deepa
Joined: 07 Jan 2003 Posts: 1056 Topics: 91 Location: The Blue Planet
Posted: Sat Sep 17, 2005 12:05 am Post subject:
Deepa,
I hope you are comparing the outputs of the following
1.
Code:
SORT FIELDS=(142,2,CH,A....)
AND
2.
Code:
SORT FIELDS=(142,3,CH,A....)
There is a high possibility of differences listed out during this comparison. It all depends upon the contents of your 144th Column in the input file. If they are same for all 10,000 odd records then there should be no differences listed out in your comparison.
Though you say there should be no impact on the first 142 bytes, you will DEFINITELY find some differences if your 144th byte changes. This is because the records will be arranged in different order by SORT FIELDS command. I would like to know what kind of comparison you are using SUPERC / SORT / FILEAID / COMPAREX ???
Pls post your comparison JCL. If you use ISPF's COMPARE in edit/view mode then you will definitely find differences due to the order in which records are grouped.
Joined: 05 Apr 2005 Posts: 131 Topics: 64 Location: chennai
Posted: Sun Sep 18, 2005 9:55 am Post subject:
Sorry ...I forgot to tell you 1 whole big thing. At 142nd byte the expanded field in the 2nd run contains only 0 prefix i.e the BASE jcl sortin file is expanded at 142nd position with a 0 prefix to make 3 byte field for the changed jcls SORTIN
That is why i expect that the SORTED O/P should also come in the same order _________________ deepa
Joined: 26 Nov 2002 Posts: 12378 Topics: 75 Location: San Jose
Posted: Sun Sep 18, 2005 10:23 am Post subject:
deepa12,
In your first post you said
Code:
The i/p file is LRECL=143 FB for the BASE RUN (AS IN PRODUCTION RUN)
And your control cards are
Code:
SORT FIELDS=(142,2,CH,A,
..
i.e you are sorting on the last 2 bytes of the file i.e 142 and 143.
Code:
The i/p file to the chaned sort jcl step is FB LRECL=144
And your control cards are
Code:
SORT FIELDS=(142,3,CH,A,
..
Now you are sorting on the last 3 bytes of the file 142,143 and 144 which is not present in the first run file.
Now if you compare those 2 files they wouldn't be the same.
See my example posted above. Imagine that the 3rd byte does not exist for the old file. Since we are sorting on the first 2 bytes it does not matter what the 3rd byte is.
Try this and see if it works
Code:
SORT FIELDS=(142,2,CH,A,
1,3,CH,A,
4,5,CH,A,
10,1,CH,A,
11,2,CH,A,
14,5,CH,A,
116,5,PD,D,
144,1,CH,A) <=== new field
OUTREC FIELDS=(C'2',1,144)
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Sun Sep 18, 2005 2:55 pm Post subject:
I don't understand your 1st example. I ran it both ways (lengths 2 and 3) and got the same answer (2nd output as expected). What was this supposed to show and why did I get a different answer? Why would numerics ever sort before alpahabetics (w/o a specific collating sequence)?
produces (results of both steps shown separated by 1 line):
Code:
AB0
A11
A9
AB0
A11
A9
I just don't see why one would expect it to be anything else. My reading of CH was that it is just a straight bitwise sort in this case. Or did I just misread something?
Joined: 07 Jan 2003 Posts: 1056 Topics: 91 Location: The Blue Planet
Posted: Mon Sep 19, 2005 12:16 am Post subject:
Kolusu & Semigeezer,
My output was same as what Semigeezer's in both cases (1,2 and 1,3).
I think your SORTIN is not good enough to highlight the difference b/w sorting first 2 columns and sorting first 3 columns. Lets go through the sample data you used in SORTIN.
Code:
A11
A9
AB0
In this example,
1. First character 'A' is same across all three rows. So, this would not make any difference during sorting.
2. Look at the second character. They are all different ('1', '9' & 'B'). Irrespective of whether you issue 1,2,CH,A or 1,3,CH,A, the sort order is first determined by the second character and only after that does the third character come into picture.
Now that 'B' < '1' as per EBCIDIC sequence, AB0 comes first, followed by A11 and then comes A9.
If you really want to see the difference due to the third character, you need to have an example like this.
Code:
A11
A19
A10
A14
AB0
AB9
AB7
AB4
A9
A8
Now the output of 1,2,CH,A would be (Note: you have OPTION EQUALS enabled by default which would retain the order of duplicates as it is in input).
Code:
AB0
AB9
AB7
AB4
A11
A19
A10
A14
A8
A9
and 1,3,CH,A would result in this:
Code:
AB0
AB4
AB7
AB9
A10
A11
A14
A19
A8
A9
Please try and let me know if you get different output.
Joined: 26 Nov 2002 Posts: 12378 Topics: 75 Location: San Jose
Posted: Mon Sep 19, 2005 7:56 am Post subject:
Semigeezer,
My bad. I actually had the data starting at pos 2 instead of position 1 and hence the wrong the results. Sorry about that. Once I corrected that both outputs are the same.
As phantom pointed out , my test wasn't enough to prove that sorting on an additonal byte would make a difference to the results.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
