requirement is to write matching records i.e
300 bytes from file1 to output file and also have to fill many fields which are empty in file1 record from file2 field data(extracted bytes) in output file.
Showing your job that didn't work without clearly explaining what you're trying to do makes it difficult to help you.
Please show an example of the records in each input file (relevant fields only) and what you expect for output. Explain the "rules" for getting from input to output. Give the starting position, length and format of each relevant field. Give the RECFM and LRECL of the input files. If file1 can have duplicates within it, show that in your example. If file2 can have duplicates within it, show that in your example.
Also, run the following DFSORT job and post the //SYSOUT messages so I can see what level of DFSORT you're at.
i have to write cobol program which generates this icetool job as output and input for this cobol program is another pgm which is of not related to mf.
in the i/p pgm they are writing the file first and then overwriting from file1 data .
If i have to calculate the positions(exact positions as coded in icetool) is quite tough to generalise in cobol pgm .
I am not sure what you meant by "first write file 2 record and then overlay file 1 record values." The following JCL will give you the desired results. The file 1 values(the entire 150 bytes) are starting from pos 311 in the output record. You can pick the fields you want from there.
With the JCL mentioned below I’m trying to move key values from both files (Both in position 1-12 & I don’t want to retain key @ 1-12 position) to 151-163 bytes and build data as per control3 card for matching records.
File1 is of length 150 and File2 is of length 300
File2 is having Duplicates and I need duplicates too in output file.
Can anyone help me to understand why does the output file is having key value from position 151-160 which was supposed to be data from file2.(file2 is having spaces in these position)
I can't tell enough about what you're trying to do from your description to analyze it completely, but the INREC statement in CTL2CNTL looks suspicious to me
Since you're doing an OVERLAY, you are first moving positions 1-12 into 151-162. Then you're moving the "changed" positions 1-300 to 163-462.
The changed 151-162 is part of that 1-300 bytes you're moving. Not sure if this makes a difference or not, but perhaps you meant so use:
which would move the original 1-300 input bytes to 163-462.
If that's not it, then you really need to do a better job of explaining what you're trying to do.