Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
No, there's no formula. The amount of time for a sort run depends on many factors including the sort product used, number of records, RECFM and LRECL of the file, resources available, etc.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
It's a simple COPY so it should run fine as is. However, you should remove the //SORTWKdd DD statements as they are NOT used for a COPY, so they are just causing the system to do needless allocations.
Adding more storage might make it run faster, depending on how much storage you're allowing it to use now.
If you're using DFSORT and you want me to take a look, add the following to the job so I can see the diagnostic messages:
//SORTDIAG DD DUMMY
and show me the //SYSOUT messages. (Remove the SORTDIAG statement afterwards since it produces extra messages you don't normally need.)
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Could adding BUFNO to the input and output DDs help?
Not for DFSORT. It does it own buffer optimization and ignores BUFNO.
Large BLKSIZEs can help. Note that DFSORT will generally use them for output automatically since System Determined Blocksizes (SDB) is the shipped default. Of course, DFSORT has no control over the input blocksizes.