r/mainframe

I have 0 knowledge in mainframe..should I switch company (I majored in AI and DS)?

I freaked out when theY mapped me to a mainframe role..but I'm okay with it rn (no harm in exploring right!)

Also, mainframe is becoming a niche..so focusing on this might open doors for better opportunities ig, not sure (iam hella new to this field, this is just my assumption)

Please help me out! Tell me what I shld do..

I'm delighted to release the latest version of GIBSON, my IBM z/OS mainframe simulator and education environment that is now 70,000 lines of python code built from the ground up. I'm currently writing a book for No Starch Press on 'Hacking Mainframes' and out of necessity, due to the fact most folks who will be reading it would not have the chance to to touch a mainframe, I decided to build it. It has most of the features of the modern mainframe, is open source, free, and can be downloaded from Github https://github.com/kmilne40/GIBSON - why not have a look and provide some feedback. I'm generally never on here - didn't know the group existed as usually on LinkedIn. Glad I found this spot. Some screen shots below! I've even added an email system, ISPF web browser and ISPF RSS feed (just for nostalgia). Of course it runs over EBCDIC. If you are looking to get into mainframes, need a bit a safe space to try everything out, or even have a mainframe you can't run free on, then have this is designed for you. (The server is really low footprint, runs on a Pi, VMs and I also have it running on an unused Android phone.

https://preview.redd.it/rpytncryyyah1.png?width=1815&format=png&auto=webp&s=0c7a264a2013e0fe6edd002672ea5f42de255ef4

https://preview.redd.it/an437dryyyah1.png?width=1733&format=png&auto=webp&s=cf1535bbd0b474985e2090960c88e00c7c660c0b

https://preview.redd.it/ym7hbdryyyah1.png?width=2057&format=png&auto=webp&s=3b497407205b2921fa6fbb39eccb8ec74360d486

https://preview.redd.it/ujd4ycryyyah1.png?width=1837&format=png&auto=webp&s=d41f3cbb63280754015ede07d17aa70980c006b5

https://preview.redd.it/ohcqwdryyyah1.png?width=2061&format=png&auto=webp&s=f611106ef7fda728e13813148902fd41091b3269

https://preview.redd.it/6zsbudryyyah1.png?width=2064&format=png&auto=webp&s=564f3b23a542e68973837bed37f02ff106032f97

Hey everyone,

I’m looking for some candid advice on how to stand out and actually get a foot in the door in this space. I graduated with a B.S. in Computer Science & Engineering from UC Merced a few weeks ago.

My college curriculum was heavily focused on standard Software Engineering, but the more I've looked into the mainframe space, the more fascinated I've become with them. I think applying my background to modernization would be a really rewarding challenge.

I'm currently preparing to interview for an upcoming mainframe apprenticeship, and I want to make sure I hit the ground running if selected. To prep, I've been putting in the groundwork:

• Finished the IBM Z Xplore All-Star badge.
• Completed the IBM Z 101 Certificate.
• Currently reading Introduction to the New Mainframe: z/OS Basics and Murach's Mainframe COBOL. (They seemed like the most popular book recommendations here)

My questions:

1. How does a US-based candidate actually work their way into this field? When looking at job boards, true entry-level mainframe roles seem practically non-existent. Are there specific sectors, companies, or hidden pathways I should be aggressively targeting?
2. Coming from the standard SWE world, I'm used to the idea of building GitHub portfolios, but I'm realizing that might not translate perfectly to enterprise iron. Do entry-level portfolio projects even exist/matter in this space?
3. If portfolios don't carry weight, what specific topics are the absolute most important for a junior to master in order to prove they have the right foundation and aren't just a tourist?

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).

Hey everyone,
I am pretty new to the concept of TSO Transmit. I was looking at the documentations on the internet and did find all the instructions I needed to transfer a file using XMIT.
I could only see the commands to convert one pds into XMIT, and had me wondering how can I get 3-4 pds convert into one XMIT file. Maybe using REXX?
Any advice is appreciated.

Some organizations go fully outsourced (hardware, software, operations, DR, support, the whole environment) while others keep ownership of hardware and software but bring in managed services for day-to-day operations.

For teams that have evaluated both models, I'm curious what made the biggest difference in the decision, whether it came down to cost, control, compliance, staffing, risk, or internal politics. Did full outsourcing simplify things or raise concerns about visibility and flexibility? And does managed services make more sense when a company wants to retain control but needs deeper operational coverage?

There's probably no one-size-fits-all answer, so I'm interested in how people are weighing these tradeoffs.

Hi all,

I’m a Mainframe Developer with 5.6 years of experience in Banking & Financial Services, currently based in Bangalore. I have good experience in COBOL, JCL, DB2, along with working knowledge of VSAM and basic CICS concepts. I have also worked on the FIS Systematics core banking platform and have onsite exposure in Belgium.

Currently exploring new opportunities in Bangalore. My notice period is 90 days.

I’m also open to remote opportunities (including international/US-based roles) where I can work from India.

Would really appreciate any referrals or lead via DMs. Thanks in advance!

Hi everyone,

I have 17 years of experience in Network and security. I'm working for a Tier 1 bank and I got asked to take a look in the Mainframe environment.

I simply don't understand what is the buzz around the trend of moving off the mainframe?

What are we trying to accomplish by moving off the mainframe? What do you get out of it? Do the benefits compensate the effort?

What are the challenges on the mainframe that justify decade long migration?

Is the whole moving off the mainframe thing is just a big buzz filled with executive kool-aid?

I'm at lost, I don't know what to think of it.

How are mainframes doing in your shop? Does upper management recognize their importance? Is your company investing or is it considered legacy tech that just works? How about staff? Is there aging staff with lots of technical debt?

I want to see how everyone is doing and the state of mainframes in different shops.

Are we slowly being replaced by other tech or will the mainframes be here 10-20 years from now?

Compensation & Location: $75 to $80/hr | Fully remote (Charlotte, NC 28262)

Role Overview: z/OS & z/VM Systems Programmer

• OS Administration: Design, install, configure, and maintain mainframe z/OS and z/VM systems software, hardware, and components.
• z/OS Specialization: Manage Unix System Services, SMP/E, hardware configurations, capacity planning, and Independent Software Vendor (ISV) product support.
• z/VM Specialization: Administer CP, CMS, RACF, GCS, RSCS, and VM/VTAM environments.
• Upgrades & Infrastructure: Build Mainframe LPARs, execute OS upgrades, manage catalogs, and apply critical patches and fixes.
• Architecture Expertise: Utilize deep knowledge of System z architecture and IBM system utilities to optimize performance.

If you are interested in this position, please share your updated resume with hr@cloudracksys.com.

I'm not a COBOL developer by profession, but I've been spending a lot of time trying to understand how large COBOL applications are maintained in the real world.

One thing I'm curious about:

Imagine someone drops a change request on your desk for a COBOL application you've never worked on before.

What does your process actually look like?

Do you start with:

• JCL?
• Program search?
• Copybooks?
• Existing documentation?
• Dependency analysis?
• Talking to someone who knows the system?

And what usually ends up consuming the most time?

I'm asking because from the outside it seems like the coding part might be easier than figuring out where the change needs to be made and what else it could affect.

Would love to hear real stories from people who work on these systems.

I’ve been interested in working on software vendor packages lately, how can i get into the development of these vendor software packages?

I retired a couple of years ago and have decided I want to go back to work. I have over 50 years experience in both technical and managerial positions. While I am keeping up with current stuff (doing a react frontend/c# backend app for a friend) I think my real strength is in legacy systems (very legacy, like IBM assembler, CICS, DB2). Is there any demand for these skills? Thanks for any feedback.

Serious question for people who actively work with COBOL.

If you had a magic button that could instantly solve ONE problem when maintaining or modifying a large COBOL application, what would it be?

Examples:

• Finding where business logic lives
• Understanding dependencies
• Impact analysis
• Tracing data flow
• Outdated documentation
• Knowledge trapped with a few senior developers
• Something else entirely

I'm curious whether the biggest challenges today are technical problems, documentation problems, or simply understanding systems that have evolved over decades.

Would love to hear what your "magic button" would solve.

I'm trying to understand how real mainframe applications are actually structured, and I'd value the perspective of people who've worked on them.

When you look at a production COBOL estate, how much of the meaningful business logic lives within a single program versus emerging across a chain of programs in a job stream? If you took one program out and ran it in isolation, would its behaviour be self-contained, or is so much driven by shared state, run order, and upstream/downstream steps that a single program doesn't mean much on its own?

I ask because I keep reading that COBOL programs are "more like modules" that work together as an application — so I'm trying to gauge how decomposable a real system actually is into pieces you could understand (or test) independently. Is that realistic, or a beginner's misunderstanding?

JOB OPENING: z/OS Systems Programmer

Rate: $75 to $80/hr

Location: Fully Remote – Charlotte, NC 28262, USA

Top 5 Skills:

z/OS & z/VM Administration: Complete installation, configuration, and maintenance.

Subsystem Management: Core handling of Unix System Services, SMP/E, and ISV products.

Infrastructure Upgrades: Proven experience building Mainframe LPAR and executing OS upgrades.

Component Mastery: Deep knowledge of CP, CMS, RACF, GCS, RSCS, and VM/VTAM.

System Utilities: Expertise in Catalog management and installing patches or fixes.

Hi everyone, if any experienced z/OS professional is looking for a new position, please feel free to share your resume with us at: ✉️ hr@cloudracksys.com

Hi - what is the salary range for someone with 20+ years experience in NJ? TIA

A question about how these systems behave when the data goes wrong, rather than the happy path. 

When a batch program hits something like a divide-by-zero, a numeric field overflowing its size, or an invalid value where a number should be — in practice, does the typical production program abend (and the job stops), or does it carry on, maybe with ON SIZE ERROR handling, maybe with a leftover or default value in the field? 

I ask because I imagine the ‘normal’ answer varies a lot — some shops code defensively with ON SIZE ERROR everywhere, others let it abend so nothing bad slips through silently. What's been your experience of how these edge cases are actually handled, and have you seen cases where a program quietly continued with a wrong value rather than failing loudly? Any war stories there would be really helpful. 

For those who've worked in production mainframe environments (banking, insurance, building societies especially): in practice, do shops retain their overnight batch input and output files long enough, and in a usable enough form, that you could take a historical run and replay the same inputs to check you get the same outputs? Or is that data typically gone, archived beyond practical reach, or just not kept that way?

Trying to understand whether "compare against what the system actually produced in production" is realistic, or whether you're usually forced to reconstruct expected results some other way.