I need that ICETOOL to do it one step..i have the ICETOOL it wil merge all the 25 files and extracting in another step..If posible can you please share the syntax for ICETOOL with merging many files aong with extarct condtion
I read the below in DFSORT programming guide
The input data set is copied to output. No merge takes place.
MERGE Control Statement
Chapter 3. Using DFSORT Program Control Statements 167[/img]
In my case, the input files having the below
KSDS key length: 0
KSDS key location: 0
Average record size: 3000
Maximum record size: 10000
Please tel me in this case how the merge fields should be given since its a VB.
do You have a reasonable sequence key for Your records
Since its an ESDS ti wont be in sequence based on key fields. But we have key starts from 17 position to 48th position 32 length...also since its an VB file we need to add 4 bytes to get correct length. Here i mentioned without adding those 4 bytes.
If my understanding of what you have and want to do is correct, one way would be to extract the needed data from each file, sort it by the "merge key(s)", and then merge the selected data as needed.
Yes you correct Dick, but i said there are 25 files. So we need 25 similar steps with different files as input. I don't think your idea won't suite for effective coding. Instead if we know the merging logic of VSAM files we can Merge in single step and extract the records it in another step or same step if feasible.
I think you need to contact SyncSort. They have a software update which allows multiple VSAM files to be specified as input to a SORT.
Your other possibility is to write an "EXIT" program, which can be in Cobol, which will read the 25 VSAM files passing the data records one-at-a-time back to SORT to represent a single input file which can then be SORTed and have other processing applied to it.
Short of either of these, you are looking at the 25 copies to "flat" files and concatenating to SORTIN.
enrico had already posted a tested and working approach of MERGEing on keys and keeping the VSAM file as output. If the order of output records is not a matter of concern, would it not be enough to MERGE on an arbitrary key field and write into output. Is there a problem the OP cannot follow the same approach?
Am I missing something!
Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix
I don't think your idea won't suite for effective coding.
What might you mean by "effective"? Just that with the suggestion there would be multiple sort steps?
It would take less than 1/2 an hour to copy a working "step" 24 times. . . Then one step for the merge. Pretty simple actually and is easily maintained. This is a holdover from wanting on ly 1 step . . .