While going through this post of yours, i have come up with quite a few questions. I guess im not very clear on these and thus am getting confused.
1. Regarding the very first post, the code for the JCL given by you, how is the key matching done? Is it for sure that the input files File1 and File2 will have the keys in the same order and all keys will coresspond.
What happens if these are the input files? What happens if the key is not the first 18 characters?
2. For the other approach that you linked too, I am unclear on that too. How are the CNTL fields specified. And how is the sum done? Also the Outrec format given in OUTFIL.
What if the keys for the 2 files are in separate locations? What if we have input files like this:
Sorry for the long list of questions, but the answers here are great and as I am going through all these posts, I keep coming up with something. This place is really really helpful. Thanks!
For the lengths of the input file, the first one lets take it to be exactly 10 and the second top be 100. (The spaces I showed in the I/P files are just for clarity)
Joined: 26 Nov 2002 Posts: 12402 Topics: 75 Location: San Jose
Posted: Tue Mar 04, 2003 7:05 am Post subject:
manojagrawal,
Thanks for the goodwords about mvsforums. I am happy that you are finding this place quite helpful. Spread the word about mvsforums to your friends and co-workers.
Now coming to your questions.
Quote:
Regarding the very first post, the code for the JCL given by you, how is the key matching done? Is it for sure that the input files File1 and File2 will have the keys in the same order and all keys will coresspond.
NO they can be any order without duplicates. The final step any way sorts it on the key and with OPTION EQUALS ensures that we take the first record from the set of duplicates.
Quote:
For the other approach that you linked too, I am unclear on that too. How are the CNTL fields specified. And how is the sum done? Also the Outrec format given in OUTFIL.
I am just want to mention it again , all the above posted solutions will not work for duplicte keys.It works only if both the files are unique.so for sample data you showed this method of merging will not work.Even if the position of key fields is not the same, we will change the postions of the key fields to be in the position of file1.
Quote:
For the lengths of the input file, the first one lets take it to be exactly 10 and the second top be 100. (The spaces I showed in the I/P files are just for clarity)
If the input file lenghts are different, we make them equal by padding with binary zeroes.
About how cntl fields are specifed and summing is done.
Let us take this simple ex:
so basically I am adding 'kolusu' at the end of the file 1
now the control cards for file 1. since we want the entire file1 rec as is we will write it out and also pad with 6 binary zeroes for the word 'kolusu'
Code:
OUTFIL FNAMES=T1,OUTREC=(1,20, $ INPUT AS IS
6Z) $ PAD WITH 6 BINARY ZEORES FOR SUMMING
from file2 all you need is the matching key and text kolusu from it.so you just copy them
Code:
OUTFIL FNAMES=T2,OUTREC=(50,4, $ KEY ABCD STARTS AT 50 FOR 4 BYTES
10Z, $ PAD WITH 10 BINARY ZEORES FOR THE 2 FIELD IN FILE1
60,6) $ THE TEXT KOLUSU FOR 6 BYTES
now both the files are of lrecl 26 and we can contatenate them together and do the sum on the bytes 21 thru 26.Since the sum fields are binary are you can sum them in chunks 2, 4 bytes.
Code:
SORT FIELDS=(1,4,CH,A) $ SORT ON KEY
SUM FIELDS=(21,4,BI, $ SUM SORT ON 21 THRU 24
25,2,BI) $ SUM SORT ON 25 THRU 26
Yep! That did help clear quite a few things for me. But does that mean that what I mentioned CANNOT be done using JCL's? Would I have to go for a programmatical solution for that? I mean read through the first flat file records one at a time, find the corresponding key in the second file, and then merge the fields to a third output file?
Joined: 26 Nov 2002 Posts: 12402 Topics: 75 Location: San Jose
Posted: Tue Mar 04, 2003 8:13 am Post subject:
manojagrawal,
If you are planning to merge a file with duplicates then syncsort is not an ideal product to do that. You still can do that using syncsort as long as there are few records in the file.ie..a max upto 2400 if the matching key is equal to 8 bytes.
But if you have easytrieve at your shop then it is very simple and it need not be a program. It can be a parm and you can use it in a jcl
Hope this helps...
cheers
kolusu
Last Edit: Made changes to the reflect syncsort
Last edited by kolusu on Tue Mar 04, 2003 11:58 am; edited 2 times in total
What my aim is to basically get what i mentioned above. If we take the first 7 bytes, you will notice that it is unique. In the second file, bytes 5-7 are unique. I want for each record in file1, i get the corresponding value from file2. Thus file 1 would have unique records if we consider the first 7 bytes (or the entire record) but I want the merge to be done on the last 3 bytes.
As far as easytrieve goes, I have no idea about it. Could you please say something about it, or any link that would help. Thanks!!
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Tue Mar 04, 2003 11:31 am Post subject:
Manoj,
If you have DFSORT PTF UQ90053 (Feb, 2003) installed, you can use the new SPLICE operator of ICETOOL to do the lateral merge you asked about in 2. of your post above. For complete details on SPLICE, see:
_________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Last edited by Frank Yaeger on Wed Mar 19, 2003 4:41 pm; edited 1 time in total
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Tue Mar 04, 2003 12:10 pm Post subject:
Kolusu,
Fair enough.
Being able to impress you with SPLICE really makes my day. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
My Luck, but I think we dont have DFSORT PTF UQ90053 (Feb, 2003) installed, as it says INVALID OPERATOR for splice. What would be the procedure to get it installed?
I think we dont have EASYTRIEVE too. How can we find out whether we have it installed?
Does this mean, we go back to the first method, of a programmatical solution(I'm using PLI)? Thanks for all the suggestions.
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Wed Mar 05, 2003 11:13 am Post subject:
Manoj,
If you have DFSORT R14, then your System Programmers can install DFSORT R14 PTF UQ90053 (it's free). Tell them you want it to improve your productivity. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Thu Jul 10, 2003 10:33 am Post subject:
Sandipan,
Your DFSORT level is very old! The SEQNUM parameter was introduced with DFSORT R14 PTF UQ99323 way back in July, 2000. The syntax error for SEQNUM indicates that you do NOT have this functional PTF or any of the subsequent functional PTFs (UQ99331-March, 2002, UQ90053-Feb, 2003) installed. So you can't use any of the DFSORT/ICETOOL function available with those PTFs.
Ask your System Programmer to install DFSORT R14 PTF UQ90053 (Feb, 2003). That will bring you up to the current functional level for DFSORT/ICETOOL.
You can see all of the functions available with the July, 2000 and follow-on PTFs at:
Your site is paying for these functions (it's part of the basic DFSORT R14 license), so you should be able to take advantage of them. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
All times are GMT - 5 Hours Goto page Previous1, 2, 3, 4Next
Page 2 of 4
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