Start of change

IBM Integrated Accelerator for Z Sort

The IBM z15 provides a new sort accelerator known as the IBM Integrated Accelerator for Z Sort. A new hardware instruction SORTL instruction is introduced to allow use of a hardware accelerated approach to sorting. To take advantage of the IBM Integrated Accelerator for Z Sort, a z15 or later processor is required.

The IBM Integrated Accelerator for Z Sort feature termed as "ZSORT" helps to reduce the CPU costs and improve the elapsed time for eligible workloads. One of the primary requirements for ZSORT is providing enough virtual, real and auxiliary storage. Sort jobs which run in memory constrained environments, where the amount of memory available to be used by DFSORT jobs is restricted, may not achieve optimal performance results or may not be able to exploit ZSORT.

The 64-bit memory objects (above-the-bar-storage) are used to exploit the ZSORT accelerator for sort workloads for optimal results. Since ZSORT is part of the CPU and memory latency is much lower than disk latency, sorting in memory is more efficient than sorting with both memory and disk workspace.

By allowing ZSORT to process the input completely in memory, it can achieve the best results in both elapsed time and CPU time. It may usually require a memory object size to be approximately 2x the input size (actual size may vary depending on record format, record length (LRECL), and key length) to process the sort completely in memory. For simplicity the installation default MOSIZE=MAX is recommended, which allows obtaining the optimal size of memory object. At a minimum, the memory object size must be at least 75% of the input file size to be eligible for ZSORT.

When a sort workload is not able to be processed completely in memory, disk workspace is used in combination with memory object sorting. When using ZSORT enhanced I/O technologies are used and if the sort workload cannot be contained entirely in memory, then it may require work datasets that support zHPF (z High Performance FICON). This is needed to provide the benefit of reducing elapsed and CPU time.

When using ZSORT with disk workspace, make sure enough disk workspace to be allocated and available. The amount of disk workspace required is at least the size of the input file. For jobs that define the sort disk workspace using SORTWKxx DD statements, you must specify enough primary and secondary space in the JCL space parameters.

If enough 64-bit storage for ZSORT cannot be allocated, or enough disk space when using sort works, DFSORT will transition to traditional sort processing. Message ICE267I indicates whether the ZSORT accelerator was used with a reason code to explain the condition the sort job met.

The exploitation of ZSORT is shipped as disabled by default. Enabling the new function via DFSORT installation option allows you to quickly use the new function without having to modify JCL and programs. Consider first enabling ZSORT for individual jobs. This allows you to evaluate ZSORT in your overall batch framework. These options can be activated using one of the following methods in:
  • ICEPRMxx members of concatenated PARMLIB
  • An ICEMAC macro option
  • OPTION control statement

For the first two methods See z/OS DFSORT Installation and Customization. For the third method See OPTION control statement.

IBM’s zBNA tool (V2.2) provides modeling support for identifying potential ZSORT-eligible candidate jobs and estimates the benefits of ZSORT. The tool uses information in the SMF type 16 records.

Please note that not all sorts would be eligible to use ZSORT. Below is a list of restrictions that will disable ZSORT and will revert to using traditional sorting technique:
  • SORTL facility is not enabled/unavailable on the processor
  • ZSORT is not enabled
  • OPTION COPY or SORT FIELDS=COPY is specified
  • Usage of INREC
  • Usage of JOINKEYS
  • Usage of MERGE FIELDS
  • Usage of MODS(EXITS) statements
  • Usage of OUTREC
  • Usage of OUTFIL
  • Usage of SUM FIELDS
  • Program invoked sorts
  • Memory objects cannot be created
  • Insufficient memory object storage available (required more than currently available)
  • Unsupported sort fields specified (examples Unicode, Locale, ALTSEQ …)
  • Unknown file size or file size=0.
  • SIZE/FILSZ=Uxxxxxx is specified
  • SORTIN/SORTOUT is a VSAM Cluster
  • Sort control field positions is beyond 4092 and VLSHRT is specified
  • Usage of EXCP access method was requested
  • Insufficient storage (example above the line or below the line)
  • Sorting key greater than 4088 bytes or greater than 4080 bytes if EQUALS is specified
  • For variable records, the record length (LRECL) must be greater than 24
  • ZHPF is unavailable for a sort that could not be performed entirely in memory
  • Insufficient amount of sort workspace.
Note:
  1. Since ZSORT's goal is to reduce CPU time and elapsed time, it can require more storage than a DFSORT application that does not use ZSORT. It is recommended to have REGION=0M and MEMLIMIT=NOLIMIT for ZSORT jobs.
  2. For below-the-bar memory requirements, DFSORT must be able to obtain enough memory for its various control blocks that reside both below and above the 16MB line. Specifying a SIZE/MAINSIZE=MAX is recommended to achieve the best performance.

    For sorts under 100GB, the shipped default DSA value of 128 is enough. For sorts larger than 100GB, consider increasing DSA to 256. Note that this is only a limit. DFSORT’s dynamic storage adjustment calculates the optimal virtual storage allocation for each sort. Increasing the DSA limit impacts only very large sorts that DFSORT determines would benefit from increased virtual storage.

End of change