DFSORT: the product with no bill of its own.

DFSORT is IBM's high performance sort, merge, copy, and data manipulation engine for z/OS, the workhorse underneath a vast share of batch processing on the platform. Almost every batch stream that sorts, filters, summarizes, or reformats records leans on it, directly through job control or indirectly through utilities and applications that call it. It is invisible to most users precisely because it is everywhere, and that ubiquity is what makes its consumption matter to the bill even though it never shows up as its own invoice.

On modern installations DFSORT is delivered as a priced element of the z/OS base operating system, under product ID 5650-ZOS, and is therefore licensed under the same Monthly License Charge (MLC) terms as z/OS itself. It is billed sub-capacity on the Rolling 4-Hour Average (R4HA) MSU figure reported through the Sub-Capacity Reporting Tool (SCRT), but it does not appear as a separate line. The consequence for a buyer is specific: there is no DFSORT price to negotiate on its own. Its cost is part of the z/OS MLC charge, and the sort workload it runs simply contributes general purpose MSU to the peak that z/OS is billed on.

Because DFSORT has no standalone charge, DFSORT cost work is z/OS MLC work plus sort efficiency. Treat the two together.

The cost driver is CPU consumed by sort work and, critically, when it runs. Heavy batch sorts burn general purpose MSU, and if a large sort overlaps the online business day or any other concurrent load, it can lift the Rolling 4-Hour Average that the whole sub-capacity stack is billed on. The second driver is efficiency: inefficient sort specifications, oversized work data sets, and jobs that sort more data than they need all consume more MSU than necessary. Because the cost surfaces inside the z/OS MLC charge rather than a DFSORT line, these drivers are easy to overlook when modeling a renewal, which is exactly why they are worth isolating.

DFSORT itself rarely drives a compliance finding because it travels with z/OS entitlement, but the area around it does. Common traps we see at pattern level:

You cannot negotiate a DFSORT price, so the levers are about shrinking the MSU that sort contributes to the z/OS peak. The five that pay:

The credible alternative is a competing sort engine such as Precisely MFX, formerly Syncsort MFX, which some sites run to reduce the CPU heavy sort jobs consume and therefore the MSU those jobs add to the peak. It is a real option, but not a free one: the alternative carries its own license, the saving depends on how much of your peak is genuinely sort driven, and running two engines in parallel during a transition adds complexity. Treat any pitch promising a flat sort saving with caution, and insist on measuring your own sort contribution to the R4HA first. For most estates the larger and lower risk win is tuning and scheduling rather than replacement.