Can anyone explain why the PULL step below takes about 3 times longer
than the PUSH step ? (I was hoping they would take equal elasped time as
the PULL step merges exactly the data created in the PUSH step).
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
It's hard to tell anything given that you haven't said which sort product you're using or showed us any of the messages.
The EXCP vs BSAM difference could be caused by the use of extended format for the permanent data set or something else.
I notice you're using INCLUDE for the PULL step, so that could reduce the number of output records.
Also, "repeating" each input record 9000 times to three output data sets for the PUSH step is more costly than just reading the three input data sets for the PULL step.
Your hunch was right about the extended datasets (PS-E). When I change to using permanent, non-extended (PS) datasets I get even better results - the lowest EXCP's, CPU, and elapsed !
Upon further investigation, this is not a DFSORT issue at all.
Nor is it a BSAM vs EXCP issue.
Nor is it a permanent vs temporary dataset issue.
Nor is it an extended addressability issue.
It is a HARDWARE issue. All the slow read elapsed times were
from volumes on a StorageTek SVA960 box. I tested this with
the MERGE step above and also with simple COPY steps in 3
separate jobs running in parallel. The SVA960 just performs
horribly with this workload.