A key issue with mainframes is that the cohort of supporting programmers is dwindling. While normally this wouldn't be a problem in that a falling supply of programmers would be offset by an increasing amount of salary those causing a rising supply of programmers via the law of supply and demand, I'm not sure this is really happening for mainframes.

While they still form critical infrastructure for many businesses, the simple fact is there isn't an adequate number of young programmers coming up along to keep the support population populated.

Why is this? What makes mainframes unattractive to young programmers?

  • 40
    1.) They are expensive 2.) There seems to be no simulator or something you could load in a VM (?) 3.) One absolutely must wear ties when working on mainframes. :)
    – Ingo
    May 11, 2011 at 18:24
  • 8
    If I am a web developer by day, I can make a few extra $$$ doing this for someone else on a weekend. Not so with mainframes. Also, a mainframe dev cannot "conquer the world" the way Facebook and Twitter and Angry Birds did. Finally, will doing this job help me with my next one?
    – Job
    May 11, 2011 at 19:28
  • 86
    I'm a young programmer. I've never seen a mainframe, never had a sandbox/virtual mainframe to play with, never had a friend come up to me and say, "This is really cool, check it out!". I see the web every day, there's readily available - and free - webapp dev learning tools, and all my friends are doing neat stuff in it. Which am I going to choose? (Although, if I did have access to one I'd be sure to check it out, just because it might be interesting... (Comment because this is essentially a +1 for things said below...)
    – Beekguk
    May 11, 2011 at 19:51
  • 5
    If you haven't had a virtual mainframe to play with, Beekguk, it's because you haven't gone looking for one. May 12, 2011 at 0:42
  • 48
    I have been programming for about 35 years and don't know what you mean by "mainframe". If I have a 128-processor machine running Unix, is it a mainframe? Or do you mean machines running obsolete operating systems, with applications written in obsolete languages? May 12, 2011 at 4:05

20 Answers 20


I'm an old programmer and I'm not interested in mainframes. My reasons will probably be similar to the reasons given by young programmers, however, albeit without the ignorance of the technology so evident in many of these answers.

First, let's get the ignorance out of the way:

  • The various claims of inability to try out mainframes are false. Hercules has been available since 1999—likely for longer than many of the people answering have been programming—and despite IBM's whinging over it the odds of it going away anytime soon are negligible (especially given that it's open source). While it is, in fact, true that you cannot (legally) run the expensive software for it, there is plenty of software available you can run on it, including software that is actually still in fairly common use out there.
  • Again, contrary to public opinion, there is more to mainframes than COBOL, CICS and RPG2. Indeed almost (but not quite) anything you can run on your PC running Linux you can run on a mainframe. <irony>I'm not sure why.</irony>

So why is it that I've avoided mainframes for all my life after encountering them in school? Well:

  • While it is true that you can use more than COBOL, CICS, RPG2, etc. in mainframes, odds are very high that if you work with them this is what you'll be relegated to doing. Even worse, despite COBOL having been massively "modernized" in the past two decades or so (scare quotes because I still don't think it's a very modern language), most of the coding you'll do in COBOL will still be in old-style code because...
  • There's very little actual new development going on in mainframes. If you land a job at IBM working for their mainframe R&D division you might get the chance to do new development (and in that case you might even really enjoy your job!). In reality, though, face it: you won't be working there. You'll be working in the back room of some financial institution or other maintaining 50-year old COBOL code written by someone who still thinks that 64KB is a whopping huge pile'o'RAM. (This same guy will probably be your boss.)
  • While it is true that you can run Linux on mainframes, and thus have access to pretty much any programming language or environment you'd like, again, as with working for IBM's mainframe R&D, you're not going to get that job. It's back to maintaining that 50-year old COBOL.
  • Corporate programming is very efficient at sucking the soul out of you (and remember, it's corporate programming you're going to be doing as a mainframe programmer unless you're VERY lucky).
  • It's a ghetto, and an ever-shrinking one. (It's like MUMPS this way.) If you get too steeped in mainframe lore you get further distanced from anything non-mainframe. You can try to keep up, but you won't. I know someone pointed out that mainframes have grown in sales while other server sectors shrunk a bit, but server programming is the minority these days. Hell PCs in general are losing importance. The world of programming is very wide and very diverse and having one minuscule portion of it grow in comparison to another minuscule portion is meaningless when compared to, say, the sudden, explosive growth of programming in something as trivial as the iPhone (which itself is a minority platform – by far). No, start working in mainframes and you'll only have other mainframers to share your thoughts, your joys and your rages with – and they're a dying breed. This leads to a negative feedback loop which makes the herd shrink even further and faster.

I'm sure there's lots of reasons that a mainframe programmer could give why the career is rewarding and full of joys and interesting challenges. Indeed I've heard many of them from people trying to recruit me into the field. In the end, however, I remained unconvinced, mostly because of the ghetto problem. If I got in and found I didn't like it, how do I get out?

  • 11
    "If I got in and found I didn't like it, how do I get out?" --- leave?
    – Aaronaught
    May 12, 2011 at 1:22
  • 36
    Leave for where? My skills at maintaining 50-year old COBOL don't transfer to writing sexy web apps or iPhone/Android apps or whatever. May 12, 2011 at 2:02
  • 24
    If you can figure out the ins and outs of a whole realm of work in two months you're a far brighter man than I. May 12, 2011 at 3:44
  • 11
    @Aaronaught In a competitive IT world if you spent the couple of years it would take to actually come up to the beginnings of reasonable speed in mainframes, you wouldn't lose your previous skills but you'd automatically be less appealing when looking for other work, just like if you'd spent two years doing forestry or managing a Starbucks: looking like you're out of the loop even a little bit does you no favors when being compared to someone who doesn't look that way. May 12, 2011 at 9:36
  • 5
    @Aaronaught I agree that you can get out and that it won't ruin your career forever, nothing that hyperbolic. I do argue that it would make you less competitive, and that to most modern employers it wouldn't help your career much more than other thinking jobs -- I didn't use "landscaping" as an example, I used jobs that require thinking. May 12, 2011 at 15:58

I am 27 and have been a professional developer for more than 4 years (so I hope that qualifies me as still young). I also work as an Integration specialist so I get a lot of exposure to the mainframe development world.

  1. There appears to be little or no innovation going on in the community.
    I know that this is not exactly the case, but to the casual observer it seems so. No one want to get involved in an area where it is difficult to 'leave your mark'.
  2. How much new development or new projects are happening?
    None as far as I can tell. If you go into this area you are condemning yourself to be a maintenance programmer forever.
  3. It is not accessible to the casual learner.
    Most people started off learning how to program on their PC at home. Again, most people do not like to switch from what they know. So making the transition from one to the other take time and motivation. Given the other 2 reasons, there are not many takers.
  • 20
    +1: This jibes well with my experience. The absolute last resort is to put new code on old systems, and a lot of the venerable lines are going out of support, so the old "reliability" line is starting to fray. One thing that you don't mention is that mainframe maintenance is very specific and very proprietary. You put years of your life into a dead or dying branch of tech. It's not going to help you get any job except a job working on the same sort of system, and there are fewer of those all the time. May 11, 2011 at 16:06
  • Even in a generally crappy economy, IBM's sales of mainframes are growing. It's not really fast growth, but it's more than their competitors (they just recently passed HP to take first place in server sales). May 11, 2011 at 20:46
  • I'm inclined to wander what is considered "innovation" in the community. What I have found is that it is a comparatively closed community which leads to a lack of wider knowledge about what is happening in the world of the mainframe. ~ I agree it's not accessible to the casual learner. In IBM terms, while I think addressing access at universities is interesting, I think something like this really needs to be addressed particularly in a reasonably well-connected world.
    – temptar
    May 12, 2011 at 8:56

I will turn 40 in September so I don't know if that qualifies me as a young person any longer but I do have first hand personal knowledge of why someone might not want to be a mainframe programmer.

The last 10 years of my working life has been dedicated to mainframe programming. Learning all there is to know about batch, jcl, Cobol, Assembler, Easytrieve, CICS and Web Services and I enjoyed it immensely and would still be doing it if not for noticing a trend. My last place of employment had me working side by side with web developers (jsp, javascript, spring and hibernate) and I noticed that the company was bringing in web developers with comparable years experience for a lot more money. Not to mention the fact that the web developers position was a lot less stressful.

After getting fed up with this trend I decided to get out of the mainframe business. Now I am in a position where I develop web services with java and front end UI with javascript. This style of programming is no more difficult than what I did on the mainframe but now I earn more money and have less head ache. I no longer get that call at 2:00 am that something abended and the core system processes are waiting on me to fix my issues. So, give me one good reason why I would stay as a mainframe programmer when I can earn more money and have less stress in my life as a distributed systems programmer?

I'm sure there are circumstances where companies pay mainframers as well as distributed systems guy's but I personally haven't found them. Also, I began doing job searches from both perspectives and discovered the distributed systems job listings outnumbered the mainframe job listings at least 10 to 1. That tells me that at the present moment for me to have better job opportunities the mainframe is not the place to be.

  • Interesting that you say that. I'm a year younger than you and have noticed very similar. It's pretty much why I asked the question.
    – temptar
    Aug 1, 2011 at 11:48
  • I thought mainframe guys were payed by truckloads
    – Kemoda
    Sep 6, 2013 at 9:38
  • 2
    I think if you wanted to make a million dollars a year as a programmer, the way to do it would be to be the last guy at BigAmericanBank who knows how their bank systems work.
    – Warren P
    Dec 24, 2013 at 15:14
  • How is it that you earn less money maintaining critical banking systems, people who are on alert, i.e. get called at 2 AM usually earn the most.
    – ALXGTV
    Aug 2, 2015 at 21:51

From what I have seen so far, and comparing to Linux and Windows, the basic problem with mainframes and midframes is that you MUST pay up front to use them. And pay a lot. Every year. For everything.

This is simply not the way to make students interested in something, because they cannot afford it. If it doesn't interest them, they will probably not voluntarily make a career of it.

Unfortunately IBM's business model does not allow for making the machines cheaply available to students, or they might have a chance for changing this.

  • 4
    +1- Not only are the servers expensive, but the licenses can be over the top as well to get any sort of basic interop. May 11, 2011 at 18:01
  • Yes though IBM mostly targets larger government and corporate organisation. They sell on sight training and maintence. The license is only a small fraction of the total cost of operating the system and the people you need to keep it moving. Why does IBM charge so much, its because they have specialized people to deal with this domain.
    – Chad
    May 12, 2011 at 5:06
  • NO it's because they are aware that they can keep on screwing their customers, who have no choice in the matter. It's called lock-in for a reason.
    – Warren P
    Dec 24, 2013 at 15:37
  • IT is weird industry. You can't play with mainframes in your basement, the same way you cant play with, say, jet engines in your basement, still there are people working on those Dreamliners and F-35s. Oct 5, 2015 at 9:50

One of my first summer jobs as a programmer was largely based around scraping green-screens and PRN files. Back then I probably wouldn't have minded getting my hands dirty in COBOL (that is if they had trusted me enough as a student to let me into that code), but I'm not sure if I would feel the same way about the same prospect today.

I don't think the issue is really with mainframes per se. It's our industry's (often justified) obsession with the new and shiny.

Look at C. C is still obviously a critically important language. Almost all embedded code and most operating systems are written in C. It's not going anywhere anytime soon. And yet it's getting harder to find C programmers. A quick gander at the Stack Overflow tag page places it at 1/6 the size of [c#] and 1/4 the size of [java]. Does anyone remember when C was essentially the dominant language, arguably the only game in town?

Programmers love powerful tools. Maybe that's because (SPECULATION ALERT) most programmers are guys. You give a Java or .NET programmer the task of, say, copying a file, and many if not most will still choose to write it in Java or C# instead of writing a DOS batch file or *nix shell script that would be 50 times quicker to write and deploy. Why use a rod and reel to catch a fish when you've got a gigantic retractable net that can catch 500 fish?

Yes, COBOL and PL/I are old, but so is Pascal, and it's still alive and kicking in the form of Delphi. The aversion to the former probably stems from the fact that those languages are unwieldy compared to modern tools. Object-orientation is still a relatively new concept in the COBOL world (emphasis on relatively), but in the C# world, LINQ and generics and AJAX stopped being revolutionary years ago. Asking a developer accustomed to those tools to start programming on mainframes is like asking a rock musician to start playing on a banjo.

Of course there's also the problem of the self-perpetuating stereotype. As long as younger programmers believe that there's nothing for them in mainframes (whether or not it is true), then any young programmers who do choose to go into it will end up spending most of their days around people much older. IT isn't much of a socially-appealing profession to begin with, but the added disincentive of a generation gap tends to bring it below a lot of people's pain thresholds. No offense meant - I personally have spent most of my life working with people a good deal older, but not everybody has that background or that capability.

Finally, most programmers don't enjoy maintenance work, and almost all mainframe work is maintenance. There isn't a lot of new software being written in PL/I. Any job that is defined entirely or largely around maintenance code automatically starts off with a negative score.

There are positives to working on legacy code ("legacy" encompassing mainframes and many other things), which you'll probably need to play up if you're trying to attract a younger crowd:

  • The systems are, as you say, critical infrastructure. Younger developers, at least in the business world (not Google/Microsoft), often don't get a chance to make any real impact. It's disheartening to work on a system that you know is just going to be abandoned or superseded after a few months or years. Mainframe apps that have already been running for 50 years are probably going to run for a lot more because it makes no sense for the companies to rebuild them, so the work you do in them is actually important to a lot of people.

  • If you are one of those few companies that actually does have an inclination to "upgrade", then a lot of programmers, both young and old, will be attracted by that opportunity, because then there are twin opportunities to work on mission-critical code and to flex some of those C#/Java muscles. Obviously no sane company would just scrap the mainframe and rebuild from scratch, but I've seen systems which (for example) have a COBOL core that integrates with Java components.

  • Finally, there's the indispensability - at least, as we outsiders perceive it. When all your code is in .NET then there's always the risk that the owners will trade you in for a fresh-out-of-college graduate or worse, an offshore team, in a misguided attempt to cut costs. I don't think that happens very often in the mainframe world, especially if what you say is true and supply seems to be dwindling. Of course, this point is moot if you don't pay well enough; salaries need to be adjusted to reflect that dwindling supply, otherwise people won't "sell."

I'm sure there are a lot of younger developers out there who wouldn't refuse a reasonably generous offer from a company that appeared to be going out of its way to make the work environment appealing to younger employees. But if you want to reach them then you'd be wise to play on your strengths, and you might even have to start doing some marketing; we tend to view mainframes as a different and very foreign world, and I'm pretty sure I didn't see you guys at the campus job fair 10 years ago working to change that perception.

To boil it down to a single sentence: Nothing makes mainframes unattractive, it's just that nothing makes them attractive either, and that puts them at a serious disadvantage when compared to the bleeding edge which offers us huge productivity boosts and free soft drinks.

  • 12
    We had 4 20+ year mainframe programmers at my shop 6 years ago, and now we have none. Don't start thinking experience will make you indispensable. May 11, 2011 at 16:01
  • 1
    @aaronaught: Fired, fired, buy out, quit. What newer technologies? It's a mainframe environment. It hasn't changed significantly in 30 years. New hardware, upgraded OS, same crappy programs. When they were gone, we offloaded 95% of what they did to external systems, and we do minimal maintenance on the rest. For my corporation this is pretty much how it's gone the last 10 years or so. May 11, 2011 at 16:41
  • 3
    @aaronaught: You have to understand the process, but the code can usually go take a walk. So many things are done to get around the limitations of the system. If I have to send an encrypted credit card batch to our Merchant provider (for example), it's actually easier to do that from a modern Linux machine. And reporting is vastly easier: we do tons of reports and projections, most of which are done on historical data, and so we can offload datasets and put them on a modern database, and then generate flashy reports with Crystal reports (or whatever). May 11, 2011 at 19:36
  • 2
    On C - maybe the issue is less "few developers" and more "language is simpler and more stable, with fewer questions needing to be asked"? It's hardly surprising that C# generates a lot of questions - the neverending stream of new APIs etc reminds me of joelonsoftware.com/articles/fog0000000339.html
    – user8709
    May 12, 2011 at 7:35
  • 3
    Programming has moved away from the low-level abstraction that C offers, and we're all the better for it. Unless you're a C-only-expert developer, then writing in C will take you much longer. And infinitely more time if you're a code-monkey type developer. I prefer to waste my time solving interesting problems that are domain-specific, and not weird/odd language-specific. Jan 15, 2013 at 11:57

I'm young-ish (mid 30's) and currently work in mainframe support. RPG, COBOL, propietary 4GL crap. Development is slow, and where possible, is migrated to more modern hardware using more modern languages.

Mainframe development is so cumbersome compared to modern systems that the mainframe itself tends to get relegated to the back-end, while more modern languages are used to do the sorts of reporting and data transforms that used to be done on the mainframe itself. At this point, we've even turned most of the data entry into a batch driven process, so the only things that remain on the server are billing related.

While it may seem like a good niche to jump into, I think many companies are coming to the realization that they don't really need these systems anymore. Change happens slowly in the world of finance, but it does happen.

  • You are aware, I presume, at some level, even if not at a conscious one, that ANY language can be used on a mainframe, right? Here's a little clue. May 12, 2011 at 0:48
  • @JUST: Linux is a programming language? Posting a linux site kinda outs you as a youngster. The vast majority of mainframes were deployed before linux hit any kind of maturity. Once mainframes were the rule, not the exception: they were the servers, and all the terminals were dumb terminals with green screens. Lumping modern supercomputers in with those kinda misses the point of the original question. May 12, 2011 at 1:18
  • Satanicpuppy: Apparently you young'uns weren't taught to read between the lines, so allow me to spell it out for you: if you can run Linux on a mainframe, you can run much of Linux software on that same mainframe. That means you can run most programming languages that can be compiled without machine-specific chunks on it. Was that clear enough? (There's a reason why I called it a "clue" and not an "answer".) May 12, 2011 at 2:04
  • 5
    @just: With what connectors for the proprietary databases? With what support for proprietary numeric formats (BCD anyone?) Why would I muck around on that machine? You're just forcing yourself to do MORE work on a machine you should be trying to move away from. May 12, 2011 at 13:56
  • 1
    You don't even need to run LINUX. The current z/OS generation supports C, C++, Java etc. natively. The USS environment is 100% POSIX compliant (which is more than can be said for Solaris). Apr 3, 2012 at 8:22

Personally I don't understand what the marketable advantage is to mainframes.

Fast number and data crunching? Why can't I distribute that across a farm for processing, or buy a beefy "normal" server.

High redundancy and scalability? I'd rather have a Linux server farm or a set of virtual servers.

Virtualization and multiple OS's? Perhaps there is a sizable performance difference for using this instead of a "cloud" strategy?

While I would love to understand all these things in more detail, lack of useful explanations of what differentiates a mainframe is the primary reason as to why I don't program for those systems.

  • Jordan, Most of what you have in *nix was around for years on IBM mainframes. The high redundancy and scalability is very attractive and there are some indications that a mainframe has a lower carbon/energy footprint (and hence energy cost) than an equivalent server farm. Whether this is ultimately salable in the long term depends on whether there will be people willing to run the things. I don't think there will be.
    – temptar
    May 13, 2011 at 9:35

I'm 25 and currently in an MSCS program (my background is not CS) and I'm definitely interested in mainframes. The problem is, I'm not sure where to even get started. I've looked at COBOL and don't know where to get a decent compiler (not even sure what a decent compiler is for COBOL, I know there is an open-source compiler, but not sure what quality it has). I just don't see a lot of information for it and to be honest, time spent looking for that is time that I could be working actively on a project in .Net or Java (I prefer .Net but school work is in Java). Like @Joshua Smith, I do worry that if I were to get into mainframes it would be my life, but I also find them more interesting then web apps and the whole Web 2.0 craze (call me crazy). To me though, it would be a lot easier to learn Java and then tether myself to SAP, as I know that can get plenty of jobs as well.

Bottom line is this:

(1) Information isn't readily available for me to learn what I would need to learn to do mainframe programming
(2) At this point in my life, I just want to be able to program for a living and .Net and Java allows me to work towards this goal while in school because there are plenty of resources that I can turn to and learn what I need to come away with a portfolio at the end of my academic career
(3) It would be hard for me to get stuck doing something that I don't enjoy and the possibility of getting stuck only doing mainframes for a career is something that kind of scares me (although, I know that there are ways around it such as brushing up on new things in my free time and contributing to open source)

  • A quick Google reveals freebyte.com/programming/cobol - I don't advocate learning COBOL, but there are compilers available if you decide to do it.
    – user8709
    May 12, 2011 at 9:39
  • Assembler is also an option if you don't want to go at Cobol and although I don't use it, it's possible you may be able to find an assembler tool on the Hercules emulator.
    – temptar
    May 13, 2011 at 9:33

This is just my personal perspective as a young programmer. I've never worked on a mainframe before so I can't talk from first hand experience on one. But, that's the thing, I've never worked on one and don't foresee it happening any time soon. I'm not sure where you want to draw the line between mainframe and a simple server but when I think mainframe, I envision some behemoth IBM machine like the Z-Series 900 eating away $35/day just in electricity. I'm not going to have one of those in my basement any time soon to tinker with in my spare time. Especially when I can grab an old machine, throw ubuntu-server on it, and host whatever I feel like very easily. If I have a problem, the Linux community is huge and chances are someone else has encountered my problem and posted a solution online. I'm only guessing, but I wouldn't expect to see that level of information available for mainframe issues online.

  • 1
    You don't need a Z-Series 900 in your basement. You can run Hercules on your PC -- even an old one. May 12, 2011 at 0:47
  • I don't get the "basement" argument. You can't play with jet engine in your basement, there are no tutorials on how to make a submarine and there are no open source software for nuclear reactors to play with, yet somehow engineers around the world learn those things. Oct 5, 2015 at 10:20

I started off doing mainframe work when I entered the workforce 10 years ago. I had never touched a mainframe before.

There were several aspects I didn't enjoy, so that I stopped doing mainframe work as soon as I could:

  1. Editing code was very primitive. You were basically just working in a text editor, fixed to ALL CAPS and 80 character lines. No code completion or syntax checking.
  2. Compilation was done by starting a batch job, that then was scheduled and ran at some point, usually in the next 5 minutes if you were lucky. If you had a typo and the code didn't compile, repeat several times.
  3. There was no debugger of any sort. Debugging was done by printing variable values out, and repeating that lengthy compilation step.
  4. The changes that we did make were always incredibly conservative. We were building on 20 years of legacy code where the only documentation was handwritten on paper in a file cabinet, somewhere. In addition, this was financial code, so there was no tolerance for errors. So the actual coding step was minimal compared to the research that was required beforehand.

(OTOH, they did have very advanced version control and code promotion, for the time period.)

  • 2
    Try "CAPS OFF" to use lower case, "SYNTAX" to get highlighting and error checking, your records are 32K long then you can edit them with ease. Interactive compilation has been available since 1974, but most programmer prefer the background batch jobs for much the same reasons Java programers use ANT scripts. Debuggers have been around forever. Apr 3, 2012 at 8:57
  • I imagine that there could be a bank where none of the programmers know how to use the existing primitive 1960s command line debugger that comes with their giant dinosaur of an operating system.
    – Warren P
    Dec 24, 2013 at 15:17

Two reasons to consider joining the mainframe workforce:

  1. It pays well
  2. There are tons of openings

The greying workforce in the mainframe field is, and will be creating huge numbers of openings in the field.

I work for a large financial company, and within the next 5 years, we'll be losing about 30% of our workforce to retirement. That number will increase exponentially in 10-15 years.

More reasons:

  • I've been in the field for 25+ years and have never been bored.
  • Less competition for jobs.
  • Stop complaining about the technology (see some posts above)... it may be old, but in many ways it's light years ahead of open systems. HTML - give me a break. It's so similar to Basic which I took 30 years ago in college. We're way beyond that.
  • The mainframe is fast and reliable, tried and true.
  • Try Systems Programming if you're very bright and love trouble shooting.
  • As a team leader, I wish I could find young, trained technicians to fill openings.
  • Did I mention it pays well?
  • Other mainframe career options besides software development - hardware engineers, storage techs, networking, and more.
  • It's fun, exciting, challenging, and there's great career growth.
  • Stop thinking of mainframe as just old technology - check it out and verify all that I've said.

Also check out IBM's System z Academic Initiative.


I'm still a young-ish programmer (I'm 29) and I'm definitely not interested in learning to develop for the mainframe. I work for an insurance company on a .NET team, but we also work with a large team of old-school mainframe programmers.

There are a few things which make the mainframe world unattractive to me. First, there is COBOL. I understand that much of the world runs on COBOL, but that doesn't make the language any less ugly to my eyes.

Next, there is the concept of the 'cycle'. I don't know if this is common to mainframes or is just the way we do things, but our mainframe has to run an overnight cycle before we can get current data from it. The .NET side of our shop is heavily involved in sending data to and dealing with data from the mainframe (specifically, displaying a ton of data on an internal LOB website for agents). The Business wants the data displayed to the agents to be current to-the-minute. However, the mainframe doesn't operate within my (limited) concept of real time. We have some insane workarounds in place to simulate on the website what we expect to be the actual output from the mainframe the following day.

Finally, I firmly believe that if I were to move towards mainframe development at this point, it would come to dominate my career. I think my skills as a modern developer would fall further and further behind, eventually reaching the point where COBOL maintenance would be my only option. I know that there is good money to be made, now and especially ten years from now, but money is fourth or fifth on my list of priorities for my career. I'd rather continue making my decent salary if it means working on new and interesting things.

  • Your cycle just sounds like a badly designed process. Mainframes can easily deliver real time or near real time data. Its expensive but it can be done.
    – bot403
    May 11, 2011 at 14:56
  • 4
    @bot403: I believe you. Badly-designed processes are our specialty. May 11, 2011 at 15:00
  • @Joshua, any particular reason why it looks ugly? And why other languages look better to you?
    – user1249
    May 11, 2011 at 17:07
  • @Joshua I am in a strikingly similar situation (it is on the up and up though). From what I have seen, a lot of the main framers have a history of processing data in batches. When do you run a batch? At midnight. The processes take 5 hours every night because they do an entire day's (or month's) work all at one time. How some of them missed the whole "Event driven programming" thing seems a bit odd, but realtime just was not a big priority for main frames in the 80's. May 11, 2011 at 18:12
  • 2
    @Thorbjørn Ravn Andersen: I'm not disparaging COBOL programmers. The language just seems unnecessarily verbose. I can't get my head around typing MULTIPLY Num1 BY Num2 GIVING Result. when I can type result = num1 * num2; May 11, 2011 at 20:43

I work mainly with Java, but we use mainframes for our backend which means I have to deal with them a lot (RPG). The biggest problem I have is the lack of publicly available documentation. You can find SQL documentation for DB2 that will mostly translate to iSeries DB2, but publib.boulder is horrible compared to the Sun javadocs.

Another thing I don't like is the hard to read syntax of the major mainframe languages. RPG does not have the concept of local scope, which means you need huge variable declaration blocks. I think Cobol suffers from the same problem. It also leads to meaningless variable names and hidden meanings. It also has many, many different built-in functions that I have a hard time finding out about (see above). It reminds me of why I don't use BASIC anymore for serious programming. Thankfully IBM is trying to move everyone to Java, but those legacy languages aren't going away anytime soon.

I find it difficult to get excited about learning to program in an environment like this.

  • 3
    +1 for meaningless names. I'm in the process of replacing a big ERP system that was in RPG to .Net. The programmer who wrote it had a background in some language that had a 6 character variable name limit. Along with keeping that convention alive, he also continued to use punchcard notation on all the code files, so they each have "CardID" and have to be executed in the order of the files ID. Combine that with almost never using unique IDs or any relational designs in the data and it just about makes me never want to touch a mainframe ever. May 11, 2011 at 17:57
  • "The biggest problem I have is the lack of publicly available documentation". +1 Also - possibly because of the age profile of a lot of mainframers, the internet support community is severely limited compared to other technology branches.
    – temptar
    May 13, 2011 at 9:36
  • @Morgan -- relational databases were invented on mainframes. The i Series in particular uses a relational database for everything. Apr 3, 2012 at 8:25
  • 1
    Unfortunately you can still use a relation database just like a flat file, and some people do.
    – Michael K
    Apr 3, 2012 at 12:09

Look, I'm 42 and I'm not interested in mainframes. Well, let's qualify that. I'm interested in the history of computing. I've studied mainframe architectures to some extent, and understand how for instance IBM mainframes influenced microprocessor architectures such as the Motorola 68000 or 80386. In the 1960's mainframes already blazed at speeds exceeding 30 Mhz, and sported advanced multi-tasking operating systems with virtual memories. To people used to those environments, early microprocessors were disappointing in many ways, and it took quite a while for microprocessor based architectures to catch up with similar capabilities and performance.

But catch up those architectures did, and mainframes stopped being "hip" long ago. It happened when hackers could get minicomputers on their benches and soon after that workstations running Unix.

Mainframes have been alien to young programmers since early 1980-something. That might have been an excellent time for mainframe companies to ask themselves your very question.

Today the answer is cross-generationally recursive: young programmers are not interested in mainframes because even if they have parents or teachers interested in computing, those parents and teachers (40+ geezers like me) were already not interested in doing anything with mainframes a quarter century ago.

Anyway, today, a cell phone can handle the tasks that mainframes were used for 30 years ago! Farms of inexpensive server boxes are the new mainframe. So in a way there are new mainframe programmers today, only their specialty is racking together networked machines to build clouds. In a stretch, we could say that Mark Zuckerberg and his gang were doing a new kind of mainframe programming when they produced Facebook, in the sense that it's not just a little application that just runs on a simple microprocessor with a disk.

By the way one of the last specialties of the mainframe was virtualization. But that is now ubiquitous in desktop/server machines. People started doing it badly at first, using software techniques. VM's were so useful that users didn't mind the performance hit. Then Companies like Intel looked at the mainframe again and learned a couple of more lessons by supporting virtualization in hardware to make it fast.

  • 1
    +1 for "Mainframes have been alien to young programmers since early 1980-something. That might have been an excellent time for mainframe companies to ask themselves your very question."
    – Kyle
    Jan 15, 2013 at 5:14

Learning web, mobile phone or PC development is rather cheap and easy.

The hardware costs for even a beat up old mainframe are terribly high, and IBM frequently gets upset about the Hercules emulator project (which lets you emulate System/370, ESA/390 and the zSeries). Without Hercules, this makes the entry costs to learn mainframe architecture and application development out of the reach of all but the most wealthy hobbyists.

No college I've attended since the 80s has had any mainframe available for student use. I think IBM and the rest of the ghosts of the mainframe industry shot themselves in the foot making them less accessible to learning.

  • 1
    Does Hercules also simulate the assorted expensive pieces of software you need (used to be things like IMS and CICS; DB2 has replaced IMS (or I sincerely and deeply hope so))? May 11, 2011 at 18:23
  • 1
    Of course it doesn't simulate the software. You have to acquire that software from elsewhere (or use Linux/390 or similar and do whatever you like). May 12, 2011 at 0:50
  • 1
    @David, no it does not include the (overpriced) software. Just the operating system.
    – Tangurena
    May 12, 2011 at 1:15

Lets start with some facts about IBM mainframes and specifically zSeries.

The hardware is brand spanking shiny and new. It contains some of the most advanced electronics and chip designs available and they are fast.

While z/OS has its roots in the 1960s it has undergone continual development and at least two complete re-writes so apart from the quirks resulting from IBM's fetish for backward compatibility its probably one of the newer OSes in general use.

The key selling points are:-

  • The aforementioned backward compatibility if it a program ran in 1976 on an MVS/MVT machine the chances are it will run on the latest zSeries without being re-compiled and produce exactly the same results.
  • Bandwidth it can move access and store massive amounts of data, at massive speed and at a very fine grained level.
  • Availability. SYSPLEX which has been available for the last 15 years or so provides seamless clustering over multiple sites, complete with load balancing, automatic fail over etc. much of which is implemented in hardware. It makes most *nix clustering look primitive.
  • Convergence. This one sounds a bit weird but with full POSIX support and a superfast JVM a modern mainframe is practically indistinguishable from any other *NIX box if that's how you want to use it.

So far the mainframe has outlived nearly everything that the pundits said were going to replace it.

There are a number of downsides:-

  • Backward compatibility means that many shops are running twenty, thirty and in some cases forty year old systems. While they work well and perform their business functions well (or they wouldn't still be running!) they reflect the coding styles and obsessions of a bygone age.
  • backward culture. Programmers working in a ghetto of ancient COBOL systems don't seem to have realized the world has moved on, or if they do a fossilized management won't let them.
  • Lack of availability. Unless you are actually being paid to work on one of these monsters you will not get access to one. There may even be one where you work but if your immediate job description does not include working on it you will not get a login. Much has been said in other postings about the "herecules" emulation software and it is indeed excellent but its very much for experts only, it runs an ancient version of the operating system, it lacks most of the standard components such as CICS,COBOL and DB2 which form the framework of most running mainframe applications.
  • This is just the same thing as Fortran being shiny and new, with a recently revised ISO standard, and operator overloading, object orientation. You can be updated, yet irrelevant.
    – Kaz
    Jan 15, 2013 at 2:58
  • 2
    Regarding availability, why don't they make small devices which run the same architecture? Where can I get a $50 board running embedded z/OS on a small system-on-a-chip? Why not?
    – Kaz
    Jan 15, 2013 at 3:01
  • 2
    For the same reason you cannot get an up to date OS for Hercules. There are many mainframe applications which have a light workload but are too expensive to replace. They could easily run on today's PC commodity hardware but if IBM let you they would lose mainframe sales and license revenue. Capitalism wonderful! Jan 15, 2013 at 3:57
  • 1
    I had worked during the summer in the early 90s on mainframes. The culture was a turn off for me. Many of those mainframe programmers didn't know why or how things work and didn't seem interested in that sort of thing. They were using COBOL85 which didn't support such concepts like local variables or anything regarding good software engineering. It was difficult to access detailed technical information on mainframes because so much of it was from expensive manuals that were treated like holy treasures locked away from all but a few. Apr 8, 2013 at 19:21

Funny you should ask this. We have just had a talk at University regarding mainframes, and that IBM are displeased about the level of Mainframe developers, such that they are implementing a mainframe module at our University, teaching us mainframe programming, and having access to one of their mainframes remotely.

I am actually taking this module in September, it may not be something that I will do again, but it will give me a chance to work on something 'different', and open my eyes to new paradigms.

  • That is really cool. That's great that you're taking advantage of it as well. While (most) people seem to be down on mainframes, it would be cool to actually get hands on experience with one!
    – Jetti
    May 11, 2011 at 15:08
  • It's cool to do something outside field once in a while and also because there's a certain element of the tech world being where it is because of how mainframes were used in business in the early days...I hope you enjoy it. Have fun.
    – temptar
    May 13, 2011 at 9:37

I am 28 and I have been a professional developer for 10 years. I spent 3 years working on a mainframe.

The environment was esoteric, stale, stagnant, confusing (JCL and ISPF anyone?). With that said I did have an enormous amount of respect for the system, how it all worked, the scale of it. The system had something like 150M SLOC, supported a midrange farm of UNIX servers via SOA and literally ran a major part of the country.

With that said, why are young programmers not interested? Here's my take, as a "young" programmer (I started on this system at the age of 23). Bare in mind this is my perspective from the system I was working on, and the research I did:

  • There is little new mainframe development. A lot of it is legacy.
  • There are huge barriers to entry
  • The work done is for financials, big business and government. None of this is bleeding edge.
  • The development tools are old and largely antiquated. Debugging is nothing like VS.

Mainframes will always have a place in the economy. They just don't drive early businesses due to their enormous cost and and support requirements.


While I think there's probably very interesting work in mainframes, I would be terrified to actually move my career in that direction. There's far too big a chance that 10 years down the line, my experience has become useless and there's no work available for a mainframe programmer. I don't want to obsolete myself by spending a lot of time in a stagnant technology with a shrinking install base.


That answer is that there's no future in it. I have twenty-two years of experience as a mainframe programmer and I've been out of work for five years. I'm going back to school to get my Bachelor degree in web development. Why would anyone in their right mind want to be a mainframe COBOL programmer?


Not the answer you're looking for? Browse other questions tagged or ask your own question.