IBM Mainframe Forum

You're welcome

Is there any chance the current release of Syncsort might be installed soon?

but am under management direction until I can prove them wrong.

Unfortunately, all too common. Something you might be able to counter with is that the cobol code is not an hour's work (not counting promotion/turnover) and if "they" want this quickly, cobol is an option.

Will the current version of SYNCSORT provide the functionality to handle this problem? If so, I can try to push for an upgrade, although I'm in a relatively new job and am not sure if I have any chance of success as I don't know how these things work around here. There are some folks around here who could possibly push it through, but I need to know for sure that it will solve our problem before pursuing it.

I suggested the COBOL approach as well. FYI - the overall task is to take 240 separate files, all of which key on SSN, and combine them into one file. The main file has one record per SSN, all of the other files can have from 0 to 300+ records per file, and I need to end up with one file that has all of the information for a SSN on one record. Then, that file is going into a COBOL program for processing. My boss thinks everything up to the COBOL processing can be done with a sort, but I'm not sure it's the best approach. If the new version can help us out, I'll look into that. Otherwise, I'm going to have to come up with an alternative.

Thanks for your help and have a good weekend.

Thanks,

Will the current version of SYNCSORT provide the functionality to handle this problem?

I'm not sure. . . The free format of the data adds complexity. If the data in the "built" records was fixed, it would be possible (how to do that is already posted<g>). Also, in the receiving program, if the data is variable, how will the "receiving" cobol code know where to break the individual fields? There aren't any delimiters.

111111111morefields111111111evenmorefields
222222222stuff
333333333yada333333333yadayada333333333yadayadayada

If there are 240 files and many of these may have 300 records, i believe the overall record length will soon need to be dealt with also. You might want to run a process to identify the largest possible collection for an ssn.

How is the single file of all of the component pieces going to be build as input to this "sort"? If there is no single input file planned, how will all of the 240 sets of data get into this process (unless they all have the same dcb info, concatenation probably won't work)?

You too have a great weekend - i'll check in to see what's up,

d

Dick,

Thanks again for all your input - I was happy to discover that I wasn't the only one who had serious doubts about this attmept. I was finally able to convince management that this was not the correct approach to take so they are going to hit it from another direction and it's no longer my problem. It certainly did bring up some interesting questions, though, didn't it?!!

Jennifer

Hi Jennifer,

Thanks for the update

It certainly did bring up some interesting questions, though, didn't it?!!

Yup

Have a good one,

d