I was told I wouldn’t survive as a Mainframe Performance Engineer without learning SAS. So, I built a zero-MSUs, off-host Python parser instead
Hey everyone,
I’ve been working as a mainframe performance engineer for the last 5 years. As you all know, SMF data processing and analysis is easily 50% to 60% of the day-to-day job.
When I first started, almost every client environment I touched relied on heavy, legacy SAS-based tools (MXG, CA MICS, etc.) to extract the binary data from SMFDUMP. Coming from a modern development mindset, I always leaned heavily toward Python and really didn't want to spend my career writing legacy SAS macros.
Senior folks literally told me: "If you don’t learn SAS MXG, MICS, or TDS, you won't survive in this performance niche for long." (Thankfully I knew IBM TDS since it's just SQL, but you get the point).
Over the last couple of years, I noticed a massive, widening gap in the industry. Big banks and massive enterprises can easily absorb the astronomical licensing fees for legacy SAS suites. But what about the small insurance companies or small MSU footprint accounts (think under 10 MSU to 50 MSU monthly usage)?
They are priced out. They end up just coasting on standard SCRT or IFAURP reporting because it’s free. But the moment a system-level performance issue hits or a single job spikes their rolling 4-hour average, they are completely flying blind. They don't have the tools, the budget, or the dedicated SAS expertise to figure out what happened.
I figured—at the end of the day, an SMF record is just data packed in EBCDIC and packed-decimal. Why are we still burning expensive, production mainframe MSUs to parse this stuff on-host using legacy languages?
To solve this for small MSU consuming customers—and honestly, to prove a point to the folks who said it couldn't be done without SAS—I spent my spare time developing an off-host platform called SMF Peak (smfpeak.site).
The logic is simple: you upload a standard tersed dump (SMF.DUMP.TERSE). The platform decompresses it, decodes the EBCDIC/packed-decimals entirely off-host on modern cloud compute (zero-MSUs footprint), and automatically parses Type 30 (job accounting) and Type 70 (CPU capacity) logs.
The end result? You instantly download structured, clean CSV/Excel-ready reports showing your jobs, steps, LPAR weights, and billing averages. It gives small shops the exact analytics they need during a crisis without a thousand-dollar software contract or a single line of SAS.
I’m currently rolling this out for early testers and want to make sure it handles every weird edge case out there. If you work in mainframes just test it, I’d love for you to throw a dummy dump at it and tell me what you think.
(Currently supports parsing of SMF type 30 and type70 dumps only working on supporting more smf data types in updates).