SORT performance variance across runs

[Abhay Gadkari]

As part of my current work, I happened to run into a scenario where Same SORT sometimes takes 3 minutes, sometimes 30. How do you pinpoint contention or dataset issues? Thanks in advance for sharing your thoughts.

[Anuj Dhawan]

A 3-minute versus 30-minute SORT usually indicates a resource wait, but first confirm that both runs processed the same amount of data with the same SORT statements and allocations.As an application programmer, compare one fast and one slow run for:

• Step CPU time versus elapsed time
• EXCP count
• SORT messages showing input records, memory and SORTWK usage
• Dataset recalls, tape mounts or allocation messages

If CPU time is similar but elapsed time is much higher, the job was probably waiting on CPU, storage or another resource. Provide the job name, job ID, system and execution times to the performance/storage team; they can then check WLM delays, RMF device response and volume contention.If EXCPs or SORTWK usage increased significantly, investigate memory availability and work-dataset allocation first.

[hollow_rowan69]

When the same SORT is three minutes one night and thirty the next, Anuj's checklist is the right order: confirm identical input counts and SORT control statements, then compare step CPU versus elapsed, EXCPs, and the SORT messages for memory and SORTWK. Similar CPU with much higher elapsed usually means wait for CPU, storage or devices rather than a worse algorithm. Handing the performance team job name, job id, system and run times lets them check WLM delay and RMF device response for that window. A jump in SORTWK or recalls points back at memory and work dataset allocation before blaming SyncSort itself.