|
View previous topic :: View next topic
|
| Author |
Message |
rally
New User
Joined: 28 Jul 2005
Posts: 37
|
|
|
|
Hi,
I have an case need advise:
there are 2 files A & B, A with 100,000,000 records
and B with 20,000 records, the 1st 10 bytes of each records is the key of
final VSAM files.
currently, we use below scenario.
Sortin dd dsn=A
dd dsn=B
sortout DD dsn=C.
Is it possible use below scenario? need ensure all records in file A remain.
and records in file B add to proper postion of file A.
sortin dd dsn=B
sortout dd dsn=A |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| I believe that you will not be able to use that method as you will need to have the records in KEY sequence to load to the VSAM file. |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
That depends on the type of VSAM file (KSDS, ESDS, etc).
A VSAM KSDS must have the records in order of its key. So you can't "append" the B records to the end of the A file unless the B records are in key order and the first key of the B file is higher than the last key of the A file.
For the other types of VSAM files (e.g. ESDS), you may be able to do the append.
Note that to do the append, either the VSAM data set must be defined without REUSE, or you must use DFSORT's NORESET option. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
You might consider a MERGE rather than sorting the 100million (assuming they are already in the key sequence).
If you needed to sort B before the merge, that would not require many machine resources. |
|
| Back to top |
|
|
rally
New User
Joined: 28 Jul 2005
Posts: 37
|
|
|
|
| dick scherrer wrote: |
Hello,
You might consider a MERGE rather than sorting the 100million (assuming they are already in the key sequence).
If you needed to sort B before the merge, that would not require many machine resources. |
Thanks for your suggestion, file A and B are key sorted seq file.
do you mean we will get better perforamnce if we use 'MERGE' to put A & B to new SEQ file C, compare with 'SORT' to put A & B to new SEQ file C? |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| rally wrote: |
| do you mean we will get better perforamnce if we use 'MERGE' to put A & B to new SEQ file C, compare with 'SORT' to put A & B to new SEQ file C? |
If I understand, yes, why resort already sorted records......
But, from what I recall of sort, it will be smart enough to realize that the bulk of the data is already in sequence and will quickly be into its final merge out. |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
| Quote: |
| do you mean we will get better perforamnce if we use 'MERGE' to put A & B to new SEQ file C, compare with 'SORT' to put A & B to new SEQ file C? |
Yes, a MERGE is more efficient than a SORT. A SORT may need to use intermediate storage (hiperspace or work data sets) - a MERGE never has to use intermediate storage. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
I get the impression that both files A and B are sorted previously.
I suppose if this is the case that you could omit the previous sorts and just sort the two files once as a concatenated SORTIN. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
If both are in sequence, MERGE is the faster choice.
MERGE need only read both files and write the output - no work files are ever needed. |
|
| Back to top |
|
|
|
|
