Now I was hoping to see the PDS members containing the following after the JCL had run:

Code:

MY.PDS(FILE1): MY FAVOURITE TOOL IS A HAMMER AND MY FAVOURITE NUMBER IS 111111

MY.PDS(FILE2): MY FAVOURITE TOOL IS A CHISEL AND MY FAVOURITE NUMBER IS 222222

MY.PDS(FILE3): MY FAVOURITE TOOL IS A DRILL AND MY FAVOURITE NUMBER IS 333333

What we are actually getting is the final FINDREP being applied to all specified OUTFIL files:

Code:

MY.PDS(FILE1): MY FAVOURITE TOOL IS A DRILL AND MY FAVOURITE NUMBER IS 333333

MY.PDS(FILE2): MY FAVOURITE TOOL IS A DRILL AND MY FAVOURITE NUMBER IS 333333

MY.PDS(FILE3): MY FAVOURITE TOOL IS A DRILL AND MY FAVOURITE NUMBER IS 333333

It works fine if the various OUTFIL FILES are in a different PDS, but never when it's the same PDS.

I'm guessing it has something to do with the way SORT handles multiple outputs in a single PDS, but wondered if there is something we can do to override that? A wider part of our solution relies on the outputs (100 of) to be in the same PDS.

What you are doing, multiple DD names writing at the same time, should not be attempted with a PDS. The open for each DDNAME will get a separate copy of the directory, and then with each close you will successively lose the data from the previous directory written by the previous close.

You could check if it is possible with a PDSE, or write one sequential file in a format to load data into multiple members of a PDS.

Edit: You beat me enrico. I've always assumed it was the directory getting mashed - I guess same results either way :-)