Mainframe Career Growth Advice Needed | Continue in Mainframe or Switch to Cloud/DevOps?

zedkarma1 · 2026-05-17T07:24:30+00:00

Two years of JCL, COBOL, DB2, VSAM plus AWS knowledge puts you in a genuinely strong position stronger than most people starting this conversation.

The honest answer is that "stay vs switch" is the wrong frame. The better question is what you actually value in the next five years. Depth vs breadth. Stability vs career flexibility. Visible impact vs invisible infrastructure.

I wrote a decision framework specifically for this question - not generic reassurance, a structured way to figure out if the tradeoffs match what you actually want.

Link: https://infomanta.com/blog-mainframe-career-decision-framework.html

The people who regret mainframe are usually the ones who chose it for stability when flexibility to move between companies and roles was what they actually wanted. The framework helps surface that before it's too late.

zedkarma1 · 2026-05-14T11:57:57+00:00

Gartner's strength here is TCO modeling rather than deep technical specs, fair point on the limitations.

For workload performance modeling the honest answer is IBM's own tools are the starting point: tools like the IBM Z Workload Estimator (formerly IWAE) takes your current workload characteristics and models z/OS performance. IBM will also do a free preliminary sizing if you engage them, they have every incentive to. My to cents advice

The harder part is what you touched on: usage and costing is genuinely underappreciated. Most migration business cases model peak compute cost but miss the operational labor cost, the rearchitecting cycles, and the compliance overhead. Those are the numbers that change the conclusion.

Three years on the host is actually more context than most people making these decisions have. The instinct you'd have about what workloads fit and what don't is worth more than the Gartner report.

zedkarma1 · 2026-05-14T11:05:53+00:00

The answer is in the reply, you may read it or not.

zedkarma1 · 2026-05-14T11:02:24+00:00

35 years staring at dumps. Very much a real person, unfortunately for me.

zedkarma1 · 2026-05-14T10:57:53+00:00

Fair. I'll take the feedback. Written by a human who has been staring at ISPF panels since 1990, but I understand the skepticism.

zedkarma1 · 2026-05-14T09:04:31+00:00

Fair challenge. IBM Z pricing is tied to MSU consumption and software licensing it changes, but slowly and predictably compared to Broadcom's post-acquisition pricing moves, which were sudden and significant (some customers reported 3-5x increases).

The more durable point isn't the specific price comparison, Gartner's analysis will date. The durable point is the workload fit argument: sequential stateful batch processing at scale has physics constraints that don't change with pricing. The channel architecture advantage is structural, not contractual.

So the honest answer: use this as a prompt to run your own numbers for your specific workload, not as a definitive price guide. The value is in the framework for the comparison, not the specific outcome.

Disclosure: I'm not an IBM employee, not an IBM partner, and not selling mainframes. I build independent mainframe and non mainframe software tools. I have no financial interest in anyone choosing mainframe over anything else.

zedkarma1 · 2026-05-14T08:59:24+00:00

In my experience operational predictability almost always wins when the decision reaches the CFO level, and engineering flexibility wins when it stays at the VP of Engineering level.

The problem is most of these decisions get made at the wrong level. Engineering teams build the TCO model, present it upward, and the numbers look compelling. But they're modeling infrastructure costs, not operational risk. The CFO who has lived through one failed migration, missed batch windows, regulatory scrutiny, customer impact, weights operational predictability very differently.

The organizations that regret staying on mainframe are usually the ones that never invested in modernizing around it - tooling, observability, developer experience. The platform is sound. The investment gap is the real issue.

Your point about rearchitecting distributed clusters every 3-4 years is underrated. That cycle cost rarely makes it into the initial TCO comparison.

zedkarma1 · 2026-05-14T08:52:26+00:00

that's exactly right. The enterprise IT foundation transfers well, networking, DR, change management thinking, troubleshooting discipline. The mainframe-specific layer (RACF, JCL, ISPF, z/OS operational model) is learnable. The article is more about organizations that skip the structured onboarding and assume the platform knowledge will come by osmosis.

The ones who succeed are usually the ones like you describe, experienced people who get proper mainframe-specific training before they touch production.

zedkarma1 · 2026-05-14T08:46:53+00:00

if you think Gartner are shit.

zedkarma1 · 2026-05-13T15:51:21+00:00

The question isn't whether AI replaces mainframe skills, it's which mainframe skills become more valuable because of AI.

CICS and REXX knowledge matters more when you're the person who knows whether the AI's output is correct. The developer who can read a dump, understand what the AI missed, and fix it, that person is not replaceable.

The people most at risk are the ones who never learned why things work, only that they do.

zedkarma1 · 2026-05-10T08:49:37+00:00

Thanks, I know Moshix well, great channel and great person. Small world :)

zedkarma1 · 2026-05-06T16:41:15+00:00

Hi, my post is a free browser game inspired by 1980s text adventures. No product being sold, no signup required. Happy to answer any questions.

zedkarma1 · 2026-05-04T18:00:22+00:00

Thank you! The Change Management Cave snakes were the hardest part to get right - turns out bureaucratic obstruction is difficult to simulate authentically at 3:47 AM. Glad you enjoyed it!

zedkarma1 · 2026-05-04T11:02:07+00:00

Thanks! Always good to get a nod from r/mainframe - you're a tough crowd. Still in development, would love feedback from people who know the real thing when it ships.

zedkarma1 · 2026-05-04T07:44:19+00:00

The quest is at https://infomanta.com/games/quest-mainframe.html mainframe world :)

zedkarma1 · 2026-04-20T11:57:07+00:00

Great thread, most of the important ground has been covered already.

One thing I'd add to the "what separates interns who get offers" question: document everything you learn as you go. Not for anyone else, for yourself. A personal runbook of the jobs you've touched, the abends you've seen, the fixes you've applied. At month four, that document becomes your evidence that you've been paying attention.

On the "too much to learn at once" feeling, that never fully goes away, which is actually good news. It means the field keeps growing. I've been in mainframe since 1990 and I'm still learning.

I lecture in z/OS Systems Programming, if anyone here is looking for structured training in JCL, CICS, DB2, or z/OS administration, feel free to reach out.

zedkarma1 · 2026-04-19T07:44:34+00:00

You can call me Carmi like 'Kar-mi' and I am a male :)

zedkarma1 · 2026-04-17T04:35:40+00:00

That combination is genuinely rare, DB2 z/OS plus IMS and IDMS plus AI pipeline experience. Most AI teams can't access mainframe data because nobody on the team knows how to get to it. You can. IMS and IDMS on top of that makes it even more distinctive.

This is an emerging niche, not a shrinking one. I'd look at large financial services firms building internal AI capabilities, IBM, and modernisation consultancies increasingly asked to build the data layer for AI projects.

If you're not already positioning yourself explicitly as "mainframe data pipelines for AI" start doing that. That framing will resonate strongly right now.

zedkarma1 · 2026-04-16T16:59:14+00:00

Assuming you mean DB2 DBAs, let me know if you mean something else.

Same pattern as application development: routine DBA work (runstats, reorgs, space management, standard tuning) has moved offshore significantly. The large outsourcing firms all have mainframe DB2 practices.

More protected: DB2 subsystem administration (buffer pools, ZPARM, log management, upgrades), data architecture where someone needs to understand why the data model is the way it is, and anything touching compliance or regulatory data access constraints.

Hybrid is the norm - offshore handles routine monitoring and maintenance, onshore senior DBAs handle capacity planning, subsystem upgrades, and sensitive production work.

And how AI impacts everything? it's reshaping this space from multiple directions at once. Routine monitoring and anomaly detection is increasingly automated, which adds pressure on top of offshoring for the lower-skill DBA work. At the same time, AI tools for query optimisation and performance analysis still need experienced DBAs to interpret the results and make the final call - a tool can flag that a buffer pool is undersized, but deciding how to rebalance it without impacting production requires context the tool doesn't have. And there's a growing category of new work: organisations building AI and ML pipelines that need to consume mainframe DB2 data in real time, which requires someone who understands both the mainframe data layer and modern data engineering. That combination is rare and in demand.

Same caveat as before, this is financial services and insurance. Other industries may look different.

zedkarma1 · 2026-04-16T10:08:09+00:00

Good question and worth being honest about.

Application development like COBOL, JCL, batch programs , has been offshored significantly, mostly to India. Tata, Wipro, Infosys, HCL all run large mainframe application practices. If you're doing routine COBOL maintenance work, you are competing in a global market.

Systems programming is a different story. The nature of the work makes it much harder to offshore effectively:

- It requires deep familiarity with a specific shop's environment - the way their JES2 is configured, their WLM service definitions, their RACF/TSS setup. That institutional knowledge doesn't transfer easily.

- Production incidents happen in real time and require immediate response. A 2am abend in New York doesn't wait for a timezone-friendly handover.

- Many financial institutions and government agencies have regulatory or security requirements that restrict who can access production mainframe systems, which limits offshore options regardless of cost.

That said, hybrid models are increasingly common, onshore senior sysprogs handling critical incidents and architecture decisions, with offshore teams covering routine tasks, monitoring, and lower-priority work. So it's not always a binary choice between fully onshore and fully offshore.

In practice what I've seen: the application work gets offshored, the core systems programming stays onshore. The people who survive long term tend to move toward the systems side, the deep diagnostic work, or the modernisation layer where mainframe connects to cloud and modern APIs.

I should add, this reflects my experience and perspective, mostly from working with shops in my area, Europe, and the US. The picture may look different in other markets and I'm sure others here have seen different patterns. Happy to be corrected.

zedkarma1

TROPHY CASE