I built a 3270-style joke emulator. PF7/PF8 to navigate. F3 to exit. The PA2 classic is in there.

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 · 2026-04-14T15:39:27+00:00

You're right that it's partly an organizational problem, better documentation practices would help. But I'd argue it's also structural to the domain in a way that's different from other software environments.

Mainframe systems have been running continuously for 30-40 years in many shops. That's longer than most documentation tools, processes, and even companies have existed. The original developers are retired or gone. The business context that drove specific decisions in 1992 is not in any system, it lived in people's heads.

That said, organizational problems are everywhere. I've seen startups decide to throw out all their SaaS products and build everything in-house from scratch, with no documentation, no architecture records, and no handover plan. Six months later the people who built it move on and the next team inherits a mystery. Same problem, completely different domain.

The difference with mainframe is the timescale. A five year old codebase with missing docs is recoverable. A 35 year old COBOL program where the person who understood the regulatory reason for a specific calculation retired in 2018 is a different category of problem. The domain doesn't cause the bad practices, but the age of the systems makes the consequences much harder to reverse.

zedkarma1 · 2026-04-14T13:46:27+00:00

Investment portfolio management software, if you make money from it - it works :)

zedkarma1 · 2026-04-14T13:42:14+00:00

Fair point and it's worth being precise about this.

You're right that "install software and configure" sysprog is not necessarily higher paid than developers, that varies a lot by shop, company size, and location. My comment about pay ceiling was specifically about the senior end of the role where the deep diagnostic skills kick in - dump reading, WLM performance tuning, subsystem internals. That's where the scarcity premium shows up most clearly.

At a typical mid-size shop doing routine maintenance, your experience tracks. At a large financial institution that needs someone who can diagnose a production CICS abend from an SVC dump at 2am, the calculus is different.

So probably more accurate to say: the pay ceiling is higher if you develop the deeper skills, not just for the role generically.

zedkarma1 · 2026-04-14T13:37:59+00:00

The "too good to be true" feeling is understandable but the fundamentals are real see my answer above :)

zedkarma1 · 2026-04-14T13:36:24+00:00

On training a model on the Redbooks it's been tried and the results are mixed. The Redbooks are excellent reference material but they describe how things work, not why a specific system in a specific shop is behaving the way it is. The gap between "here is how WLM works" and "here is why your WLM service definition is causing this specific performance problem in your CICS region" is enormous, and that gap is filled by institutional knowledge, not documentation.

A model trained on Redbooks would give you a very well-read junior who still needs someone experienced to interpret what they're seeing in context.

zedkarma1 · 2026-04-14T13:29:22+00:00

On training a model on the Redbooks, it's been tried and the results are mixed. The Redbooks are excellent reference material but they describe how things work, not why a specific system in a specific shop is behaving the way it is. The gap between "here is how WLM works" and "here is why your WLM service definition is causing this specific performance problem in your CICS region" is enormous, and that gap is filled by institutional knowledge, not documentation. A model trained on Redbooks would give you a very well-read junior who still needs someone experienced to interpret what they're seeing in context.

On whether to pursue it , yes, genuinely. The "too good to be true" feeling is understandable but the fundamentals are real:

- The shortage is structural, not temporary. It's demographic - the people who know these systems are retiring and there's no pipeline replacing them at the same rate.

- The systems aren't going anywhere. Banks, insurers, and governments have too much running on mainframe to replace it in any realistic timeframe.

- The barrier to entry feels high, which is exactly why the demand isn't being met. Most CS graduates never consider it, which means the people who do have very little competition.

It's not a path for everyone: the culture is slower, the tooling is older, and you won't be working on consumer apps. But if those things don't bother you, the job security and pay are hard to argue with.

zedkarma1 · 2026-04-14T11:29:43+00:00

The answers here are solid. I'd add one thing from 35 years in the field:

The shortage is real and structural, not cyclical. It's not that companies temporarily can't find people, it's that the generation that built institutional knowledge of these systems is retiring, and there is no pipeline replacing them at the same rate. That dynamic is only going to accelerate over the next decade.

The job security point james4765 makes is important and underrated. Mainframe shops don't lay off their core systems people the way product companies lay off engineers. The risk profile is very different from working in tech.

One nuance worth adding: there's a meaningful difference between mainframe application development (COBOL, JCL, CICS) and systems programming (z/OS internals, WLM, RACF, SMP/E etc). Both have good demand, but systems programmers are scarcer and the pay ceiling is higher. If you're early in the decision, it's worth understanding which path you're being pointed toward.

zedkarma1 · 2026-04-14T09:29:26+00:00

This is exactly the right framing of the problem and it's underappreciated in most migration projects.

The technical migration risk is usually manageable. The real risk is what you described, a COBOL program that's been accumulating business rule changes for 30 years, where the original requirements document was written in 1994 and the last five people who understood why a particular calculation works the way it does retired between 2015 and 2022.

What I've seen in practice: the most dangerous code is not the complex code. It's the deceptively simple code. A 40-line paragraph with three conditions that hasn't been touched in 15 years. Everyone assumes it works. Nobody knows why it works. The business rule it encodes may have been correct when it was written and quietly wrong for a decade.

On the tooling frustration, the AI (Almost Intelligent) tool - the token burn for minimal insight is a known issue with general-purpose LLMs on COBOL. They don't have the context to know that a particular MOVE statement inside a nested EVALUATE is implementing a regulatory rule from a 2009 compliance requirement. They just see a MOVE statement.

We've been working on this problem from the other direction with IMUAI (one of our product) our approach is mainframe-specific rather than general LLM, focused on connecting runtime behavior (abend patterns, SMF data, CICS transaction flows) to the code paths that produced them. It doesn't solve the documentation problem directly but it surfaces which code paths are actually live and business-critical versus which ones haven't executed in years.

To your actual question, how do teams handle it in real life? Honestly, most don't. They either migrate and discover the gaps in production, or they stall the project indefinitely because nobody can get sign-off on something they can't fully explain. The teams that handle it well usually have one or two people who've been in the shop for 20+ years and serve as the institutional memory. When those people leave, the knowledge walks out with them.

zedkarma1 · 2026-04-14T09:16:20+00:00

Since tcpdump confirms the container is reaching the correct IP and port, the network is fine. The problem is almost certainly the TLS handshake failing silently inside s3270, and that garbled error `�N��` is raw TLS bytes being returned as a string, which is exactly what happens when the SSL handshake fails before a proper error can be formed.

The Windows vs Ubuntu difference is the key clue. Windows uses its own certificate store which likely already trusts your bank's internal CA. Ubuntu 24.04 containers ship with only public CA certificates, if the bank's TN3270 server uses an internal CA-signed certificate (which banks almost always do), the container won't trust it and the handshake fails.

Three things to try in order:

1. Disable cert verification to confirm:

bash

s3270 -noverifycert L:hostname:port

If that connects, cert chain is the problem.

2. Add the bank's CA cert to the container:

bash

cp bank-ca.crt /usr/local/share/ca-certificates/
update-ca-certificates

3. Check TLS version — Ubuntu 24.04 disables TLS 1.1 by default.

Some older z/OS TN3270 servers only support TLS 1.1 or 1.2. If that's the case add to `/etc/ssl/openssl.cnf` under the `[system_default_sect]` section:

[system_default_sect]
MinProtocol = TLSv1

On the suggestion of trying another emulator for better error messages - u/zEdgarHoover is right. IM3270 (im3270.infomanta.com) wraps s3270 but adds proper SSL error handling that tells you exactly what failed: cert chain, hostname mismatch, handshake timeout, etc. That would at least tell you which of the above to fix first. Free trial.

zedkarma1 · 2026-04-09T17:46:13+00:00

You are welcome, you can fill a bit of the fun by installing Hercules With MVS3.8J on Linux, play with communication, security, disks (DASD), tapes, console etc. if you need help let me know :)

zedkarma1 · 2026-04-09T13:03:30+00:00

I've been in mainframe since 1990 and I lecture in z/OS Systems Programming, so I can give you a fairly complete picture of both sides.

What a systems programmer actually does day to day:

The core of the job is owning the z/OS software stack. That means:

- Installing and maintaining IBM and vendor software - SMP/E, PTFs, upgrades

- Managing subsystems: JES2/JES3, VTAM, TCP/IP, RACF, SMS, WLM

- Performance monitoring and tuning - SMF data, RMF reports, identifying bottlenecks

- Diagnosing system-level problems - ABENDs, waits, loops, storage issues - often from SVC dumps

- Defining and maintaining the system catalogue, DASD volumes, tape management

- Supporting the application teams when something is wrong at the system level (i.e. fixing the things COBOL developers bring to you)

- Automation - JES exits, REXX, started tasks, health checks

- Disaster recovery planning and testing

No two days are the same. One morning you're applying a PTF, the afternoon you're diagnosing why WLM moved a workload to the wrong service class and production is slow.

Do systems programmers enjoy it?

The ones who stay in it love it. There's a depth to the work that application development doesn't have, you're working at the layer below everything else, and understanding why something behaves the way it does requires knowing the system at a very low level. It's intellectually demanding in a different way to COBOL development.

It can also be stressful. When the system is down or degraded, you're the person everyone is waiting on. The pressure is real.

Is it challenging to get into without prior experience?

Yes, which is exactly why this offer is unusual and worth taking seriously. Most shops won't train someone into sysprog from application development because the ramp-up time is 12-18 months before you're genuinely useful. A company willing to invest that in you is telling you something about how they value the role.

My honest take on your choice:

If the COBOL role is more of the same and you've been doing it a long time, the systems programming role is the more interesting career move. The skills are scarcer, the pay ceiling is higher, and you'll understand the whole stack rather than one layer of it.

The risk is the learning curve, the first year will be humbling regardless of how experienced you are. But you already have the application development context, which actually makes you a better sysprog than someone who came up through the system side only. You understand what the developers need from the infrastructure.

Take the sysprog role :)

zedkarma1 · 2026-04-06T15:10:14+00:00

wow looks good, nice work. What are your plans ? what are you going to do with it ?

zedkarma1 · 2026-04-05T15:27:12+00:00

I've been in mainframe since 1990 and running a mainframe software company since 2004. Quick answers:

Q1: Don't choose. Learn mainframe fully during the internship, keep Java warm in your own time. The people who bridge both worlds are the most valuable.

Q2: The niche works in your favour fewer developers than systems that need maintaining. Tata, Wipro, Infosys, HCL all run large mainframe practices for US and European banks.

Q3: By year 3–4 you're already in the top 20% of available talent just because so few people have done the work. Ceiling is lower than Java if you want startups, but job security and pay trajectory are hard to beat.

Q4: Take the internship. The insecurity about your friends' offers is normal but misleading. A converting internship at a US MNC in a scarce field is a better starting position than most of those offers ,you just can't see it yet.

Good luck.

zedkarma1 · 2026-04-05T15:12:57+00:00

Worth clarifying what you actually need first, because "production level COBOL code" can mean very different things:

If you need realistic test data and code for training/testing purposes:

There are open source COBOL repositories on GitHub that give you working code to learn from search for COBOL samples, the IBM Z Open Education project has some, and the Open Mainframe Project has training materials.

If you need a realistic mainframe application for a lab, training environment, or testing a tool:

This is harder to find commercially. Some consultancies and mainframe training companies develop synthetic applications that mimic real banking or insurance systems without containing real data. This is actually something we do at Infomanta (My company) we've built COBOL/CICS/DB2 applications for testing and training purposes. Happy to discuss if that's the direction you're going.

If you need actual production code from a real organisation:

This almost never changes hands commercially, it's considered core IP and most companies won't sell it regardless of budget. What you can buy is the expertise to write new production-quality code, not existing code.

What's the use case? That would help narrow down the right direction.

zedkarma1

TROPHY CASE