Joined: 27 Apr 2005 Posts: 248 Location: Cincinnati OH USA
The number of fields involved in the sort does not indicate quantity of work files. Input volume was the usual guide in the past along with sequence randomness of input. Spreading the work files across multiple volumes and devices expedited the sorting. With caching and physical dasd architecture shielded by logical architecture, I'm not sure there's any benefit other than handling the sheer volume of records.
See when ever temporary storage is needed we need to take working file so in case of sorting even in merging working file is needed..
That is for our system use so that it can store any temporary data in it.
correct m if i m wrong but i m sure so dont wory.
I would correct you more specifically if I understood what you were saying here, but I don't.
Work data sets (SORTWKdd) are only needed for a SORT application. They are not needed and are ignored if specified for a MERGE or COPY application. Work data sets for a SORT application can be dynamically allocated by DFSORT (recommended) or specified via DD statements.