① Journal · Benchmarks
Syncsort (Precisely) sells the high performance sort and the data integration engine that move mainframe data into the rest of the enterprise. After the Syncsort and Pitney Bowes software combination created Precisely, those tools, MFX, Connect, and Ironstream, bill on engine footprint and connectors rather than z/OS MSU. That makes the benchmark a sizing exercise. Here is how to read Syncsort (Precisely) spend against what you actually run.
48 hour mobilization Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →Precisely was formed from the combination of Syncsort and the Pitney Bowes software and data business, and the mainframe relevant catalog reflects two distinct jobs. MFX is the high performance sort that competes with IBM DFSORT inside the z/OS batch window. Connect, the former Syncsort DMExpress and DMX integration engine, moves data off the mainframe into data lakes, warehouses, and cloud targets. Ironstream forwards mainframe operational data into Splunk, ServiceNow, and similar platforms. These are licensed on engine footprint, typically nodes or cores, plus the connectors you enable, governed by Precisely license keys, rather than on z/OS MSU capacity.
So the benchmark is a sizing question, not a capacity one. Is the engine footprint matched to the throughput you actually need, and are you paying for connectors that touch systems you have already retired. Two shops moving similar volumes can pay very differently depending on how generously the footprint was sized at purchase.
The Syncsort (Precisely) bill concentrates around engine sizing and the connector list. The benchmark is to match each driver to live, demonstrated need:
| Spend driver | How it works | Where it bloats |
|---|---|---|
| MFX sort | Engine footprint on the z/OS side | Licensed where DFSORT already covers the workload |
| Connect integration engine | Nodes or cores plus enabled connectors | Footprint sized for a peak migration, kept after it ended |
| Connectors | Per source or target system enabled | Connectors live for systems already decommissioned |
| Ironstream | Footprint plus target platform | Forwarding paths nobody consumes downstream anymore |
The recurring pattern is footprint that was sized for a project and never resized when the project closed. A data migration spins up a wide Connect footprint with many connectors, the migration finishes, and the engine keeps billing at migration scale for steady state trickle. The MFX sort raises a second question worth asking at every renewal: is the premium sort earning its keep against the DFSORT you already own. The largest lever here is re-sizing the footprint and pruning dead connectors, not negotiating the per node rate.
A defensible Syncsort (Precisely) benchmark maps the engine footprint to current, demonstrated throughput rather than to the high water mark of a past project. Inventory the enabled connectors and switch off the ones pointing at systems that no longer exist, since each live connector is a line on the bill. Re-test the MFX sort against DFSORT on the actual jobs, because the value of a premium sort is workload specific and worth re-proving at renewal rather than assuming. External rate bands inform the per node and per connector discussion, but with footprint licensing the sizing decision is where most of the money sits.
The general method is in the guide on benchmarking your mainframe software spend, and the integration engine is detailed in Precisely Connect licensing. The sibling reads are benchmarking IBM spend and benchmarking BMC spend. When the Precisely renewal lands, our Precisely audit and compliance response work sizes the footprint to the workload before it is re-committed. The estate view sits in the Syncsort (Precisely) licensing hub.