← Back to Blog

Starting Mainframe Work at a Bank: What to Focus on in Your First 90 Days

Practical advice for interns and junior professionals entering mainframe for the first time. From someone who has been hiring, mentoring, and teaching mainframe since 1990.

Starting a mainframe role at a bank is one of the most disorienting first weeks in technology. Everything looks unfamiliar. The tooling is unlike anything you have used before. The culture moves differently. And the systems you are working on are running real financial transactions while you are still figuring out how to navigate ISPF.

The good news: the fundamentals are learnable, the community is genuinely helpful, and four months is enough time to make a real impression if you focus on the right things.

I have been in mainframe since 1990, I lecture in z/OS Systems Programming, and I have seen enough interns and junior professionals come through this door to know what separates the ones who stay from the ones who don't. Here is what actually matters in the first 90 days.

The first week: orient before you optimise

Resist the urge to start optimising immediately. Your first week has one job: understand the environment you are in.

Find out what the batch jobs you will be working with actually do for the business. A JCL job is not just code, it produces output that someone depends on. A nightly batch job that processes transactions may feed twelve downstream systems. Understanding what breaks if your job fails, and who it affects, changes how carefully you approach it.

Ask your team for the naming conventions. Every mainframe shop has them: for job names, dataset names, DDNAME structures, STEPNAME patterns. Learning the conventions early means the environment starts to make sense rather than looking like noise. In many shops the first character of a job name tells you whether it is production, test, or development. That single piece of knowledge makes SDSF immediately more readable.

ISPF and SDSF: building real fluency

If there is one thing to invest in during the first 90 days, it is ISPF and SDSF speed. Every minute you lose navigating the interface is a minute you are not spending on the actual work. Fluency here multiplies everything else.

The single biggest unlock is learning to use the ISPF command line rather than navigating menus. Type option numbers directly: 3.4 to get to the dataset list, 3.2 to allocate a dataset. Learn command stacking with semicolons to jump directly to where you want to go.

In SDSF, learn the prefix commands on the job list immediately: ? for job details, S to browse output, P to purge. These replace a significant amount of menu navigation once they become muscle memory.

Set up your PF keys early and consistently. PF3 for back, PF5 for repeat find, PF6 for flip are standard in most shops. Ask a senior colleague what their PF key setup looks like: you will often discover things that are not in any manual.

One tip that experienced practitioners use but rarely document: the ISPF LOCATE command lets you jump directly to a dataset or member rather than scrolling. In a library with thousands of members, this saves significant time every day.

JCL depth: what actually matters

You probably know the basics: JOB, EXEC, DD statements, DISP, standard utilities. The next layer that matters most in a batch operations role is flow control and data management.

COND parameter logic is the part of JCL that confuses almost everyone at first because it is counterintuitive. The best way to learn it is not to read about it but to practice it: write small test jobs that intentionally fail at different steps and watch how COND parameters affect which subsequent steps run. It only really clicks when you see it behave. Once you understand COND, also learn IF/THEN/ELSE/ENDIF: it is more readable and increasingly preferred in modern JCL.

GDGs (Generation Data Groups) are worth understanding properly rather than just knowing they exist. Set up a small GDG base in a sandbox environment and run a few generations through. The abstraction of relative generation numbers (+1, 0, -1) makes intuitive sense once you have created and consumed a few generations yourself.

For RESTART and CHECKPOINTING, ask your team whether you have existing jobs that use it and read those. Real production examples beat any documentation for this particular topic.

The SPACE parameter, mentioned by experienced practitioners as something to master, matters more than beginners expect. Understanding how to size datasets appropriately, and what happens when you get it wrong, will save you a surprising amount of troubleshooting time.

Reading COBOL without writing it

In a JCL and batch operations role, you need to read COBOL, not write it. The goal is not fluency: it is not being lost when you open a program listing.

Focus on three things:

• The DATA DIVISION tells you what a program is working with. If you can read the DATA DIVISION and understand the key fields and their sizes and types, you understand the program's data context. This matters when you are diagnosing why a job is producing unexpected output.
• The PROCEDURE DIVISION tells you what the program does. You do not need to understand every verb. You need to follow the logic at a high level: what is the main flow, what are the key conditions, what does the program produce.
• CALL statements tell you when a program is invoking another program. In a complex batch job, the main program you are looking at may be calling five others. Recognising CALL statements and knowing how to find the called programs is essential for tracing what is actually executing.

That is the minimum. It is achievable in a few weeks of reading real programs rather than training examples.

The personal runbook: your most important habit

This is the one piece of advice I give every person starting in mainframe that has the most impact and is the least obvious.

From your first day, keep a personal runbook. Not for anyone else, for yourself. A simple document, a text file, a notebook, the format does not matter. What goes in it:

• Every job you have touched, what it does, and what you learned about it.
• Every abend you have encountered, what caused it, and how it was resolved.
• Every fix you have applied and what the problem was.
• Every piece of environment knowledge you have been told that is not written down anywhere.

Two things happen when you do this consistently.

First, you stop asking the same question twice. Senior people notice immediately when someone comes back with the same question they already answered. They also notice, and remember, the person who never does. Your runbook is the mechanism that makes you that person.

Second, at month three or four when someone asks what you have been working on, you have a concrete answer. Not "I've been learning JCL" but "I diagnosed and fixed the recurring abend in the overnight settlement job, documented the GDG rotation issue in the report generation stream, and reduced the manual steps in the month-end reconciliation from five to two." That is what a job offer sounds like.

What good looks like at 90 days

Based on watching many interns and junior professionals come through mainframe roles, the ones who receive offers share three characteristics that have little to do with technical depth.

• They fix something real. Not a training exercise, an actual problem that was annoying the team. A job that regularly abends for a known reason. A process that takes five manual steps and could take two. A piece of documentation that did not exist and now does. Visible improvement on a real problem is worth more than completing ten training modules.
• They understand the business context of what they are running. A batch job is not just code. It produces output that the business depends on. The intern who knows not just how a job works but what it does for the bank, who depends on it, what breaks when it fails, why it runs at the time it runs, is the one who gets treated as a professional rather than a student.
• They ask good questions and write down the answers. This sounds simple. It is not as common as you would expect.

Also worth reading: Is Mainframe a Good Career Choice in 2026? · Shifting to Systems Programmer, Is It Worth It? · Is Mainframe Work at Risk of Being Outsourced? · Bringing IBM Mainframe Languages to the Zed Editor (also useful for COBOL developers moving to modern editors) · The Quest for the Lost Holy Mainframe Treasure (text adventure)