its giving like this as these records are having differences, you you observe records got sorted and came as output, but my requirement is these records needs to get compared, but needs to get sorted only on a key which is starting at 18th position to 10 bytes
my comparision till 3500 bytes will do.... as i will have only spaces in remianing bytes...
I tried to write a PLI for this, my input files are having lakhs of records, so every record needs to be comapred with all the records in other files...its taking hell lot of IO operations....and my program running for 10+ hours.
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
Why not just sort the 3500 bytes of each file since that CAN be done via sort? Then your PL/I comparison program is a simple two-way match program and will finish in a reasonable amount of time.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
so every record needs to be comapred with all the records in other files...its taking hell lot of IO operations..
The worst possible solution. . . (generating a qsam cartesian product). Unless your family has the hardware sales contract
As Robert suggests, you simply need a "two-way" match program. Just for such a need, there is a "Sticky" near the top of the COBOL part of the forum with working 2-file match/merge code. You should be able to easily adapt this to your requirement.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
Hima1985,
I don't understand as to why you need 4 passes of data when both files are of the same LRECL. Since both files are of the same length can't you concatenate them together and perform the sorting on 3500 and look for duplicates?
Here is a sample JCL which will give you the desired results. we create a 1 byte header record in step0100 and concatenate it with your input files which would be used to identify the record to the file when using the group function. Since you wanted the data to be sorted on the key at 18 , we put it at the beginning at pos and followed by your data and it is sorted so that we retain the sequence you wanted. Any matching records will be summed and total would be gt > 2 , so we ignore them and select the records with indicator 1 and 2.
I have tried the solution you have provided.....but no luck
Its comapring records perfectly....but giving out put in a sorted order on all the fields...not only on 18th to 10 bytes....as well why we are using build BUILD=(1,4,16) please suggest
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
Hima1985 wrote:
Kolusu
I have tried the solution you have provided.....but no luck
Its comapring records perfectly....but giving out put in a sorted order on all the fields...not only on 18th to 10 bytes....as well why we are using build BUILD=(1,4,16) please suggest
Please suggest.
Hima,
Did the comparison work or did it fail? The Inrec reformats the records as follows
Code:
RDW |IND|KEY(22-31)|ACTUAL DATA
1-4 |5-5|6-15 |16 - END
--------------------------------
ZZLL| 1 |12345672BB|file1 data
ZZLL| 1 |12345671CC|file1 data
ZZLL| 1 |12345673AA|file1 data
ZZLL| 2 |12345673AA|file2 data
ZZLL| 2 |12345672BB|file2 data
ZZLL| 2 |12345671CC|file2 data
Now we sort on rdw (4) + key we added at the beginning(10) +3500 data and sum on byte 5.
The reason we stick the key in the beginning is to sort on the key first and then data. If rdw+key+data is a match in file 2 the sum will be equal to 3. if it did not find a match then the indicator will have 1 or 2 and we are writing that to the respective output file and removing the indicator and key which we added at the beginning.
When you say something does not work you need to do a better job of explaining the requirements with sample input from 2 files and desired output from them. I am not going to guess anymore.
which means its sorting on all the record not on the key position 18 please observe the record which is having D in it. My requirement is compare should happen on complete record but sort should be on key position...which means my expected output is
as you said you wanted. Since Kolusu is sorting on the key in 18-27 first, 1234567898 there would sort before 1234567899 there and the N and D wouldn't matter.
Note that we're assuming all of your records are the same length (at least 3504 bytes). If they are, in fact, different lengths, that could explain what you're seeing because we're sorting on the length first, so a shorter record would appear before a longer record.
We don't know exactly what your data looks like (you don't show the record lengths), so we can only go by what you tell us (or what we assume).
We have DFSORT development work to do, so we can't afford the time to play guessing games.
