THREADS and Parallelism

What Parallel Processing Means for Sort

A traditional sort runs as a single flow of work: read data, build runs, merge, write output. In a parallel design, the product can split work across multiple threads or subtasks—for example, one thread reading and building runs while another merges, or several threads each sorting a portion of the data. On a system with multiple CPUs or engines, that can use more of the available capacity and reduce elapsed time. DFSORT (and z/OS Beyond Sort) may support this via an option such as THREADS; the exact implementation and option name are product-dependent.

When Parallelism Can Help

• Large sorts — When the data volume is large enough, spreading work across threads can reduce elapsed time.
• Enough CPU and memory — The system must have available processors and memory for the extra threads; otherwise parallelism may not show a benefit.
• Not already I/O-bound — If the job is limited by disk or tape I/O, adding more threads may not help much until I/O is improved (e.g. faster devices, more sortwork spread across volumes).

For small sorts, the overhead of coordinating threads can outweigh the benefit. So parallelism is typically a tuning option for larger, CPU-bound workloads.

Typical Syntax and Placement

If your product supports a THREADS (or similar) option, it is usually specified in the OPTION statement in SYSIN or via the EXEC PARM/DFSPARM. The option might take a value (e.g. number of threads) or be a simple switch. Example (syntax may vary):

1
2
  OPTION THREADS=4,SIZE=MAX,FILSZ=E10000000
  SORT FIELDS=(1,80,CH,A)

The allowed values and default (e.g. whether parallelism is on by default) depend on your DFSORT/Beyond Sort release and installation. Check your Application Programming Guide for “THREADS,” “parallel,” or “multi-task.”

Interaction with Other Tuning Options

Parallelism does not replace memory or sortwork tuning. You still need:

• SIZE/MOSIZE — Enough memory for each thread’s work (if applicable).
• FILSZ — A good size estimate so DFSORT can plan allocation.
• DYNALLOC or SORTWK — Sufficient sortwork; parallel threads may increase total resource use.

So THREADS is often used together with SIZE, FILSZ, and DYNALLOC when tuning large sorts. Your product’s tuning guide should describe recommended combinations.

Product and Version Differences

Not every DFSORT or sort product offers the same parallelism features. Some releases may have no THREADS option; others may use a different name (e.g. a PARM value or installation option). IBM z/OS Beyond Sort and newer DFSORT releases may document options that older DFSORT does not have. If you cannot find “THREADS” in your documentation, search for “parallel,” “multi-task,” or “concurrent” in the index, or ask your systems programmer what is available for your installation.

Explain It Like I'm Five

Sorting cards alone means one person does everything. If we have four friends (threads), we can split the deck: each person sorts a pile, then we merge the piles. That can be faster if we have enough table space (memory and sortwork) and enough friends (CPUs). THREADS is like saying “use this many friends.” The exact way to say it depends on your school’s (product’s) rules!

Exercises

1. Search your DFSORT (or Beyond Sort) documentation for “THREADS,” “parallel,” or “multi-task.” What option name and syntax are documented for your version?
2. Your large sort is CPU-bound and you have multiple engines. What options (THREADS, SIZE, FILSZ, DYNALLOC) would you consider and in what order would you tune them?
3. Why might adding THREADS=8 to a very small sort (e.g. 1000 records) not improve elapsed time?
4. If your product does not document THREADS, what other tuning levers (SIZE, FILSZ, sortwork, blocksize) can still improve sort performance?