Why aren't young programmers interested in mainframes?

I remember being offered a local position that required me to maintain the company mainframe (with RPG2). It was quite interesting because they were doing a lot of things by hand that could simply be achieved with a little scripting (in this case, Python and Perl). Things like daily sales numbers were still added up in some obscure Excel spreadsheet (this is the biggest restaurant franchise operator in the Caribbean). The potential to innovate inside the company was huge. But no, their mainframe <i>guy</i> made it clear that the job was to continue on with his legacy of writing obscure <i>job-securing</i> (as he put it) code. I declined all the offers they made, and they are still looking for someone to fill in the position (and will be for a long time). It was sad to experience such situation. A new chance to inject some productivity inducing innovation being shut down by mediocrity. Still, it was fun talking to an old RPG programmer. Even C sounded like an exotic language to him. :)

I'm 28 and I work in mainframes. Or rather, I write compilers for mainframes and I have to say that I disagree with the top voted post.<p>Mainframes have an amazing CPU architecture that is different enough from x86 to really open your mind. Ever move 2GB of memory with 1 instruction? (Well 2 really if I'm being pedantic.) It's got what's easily the industries most complicated branch predictor, and runs at well over 5Ghz. If you're interested in that, you should check out the slides from Hot Chips. Oh right, and it's got hardware transactional memory.<p>Now I'll readily admit that using z/OS through a 3270 terminal is quite painful, and using USS through SSH isn't much better, but thankfully mainframes now run RHEL. That's right, big iron runs linux. Yes, you'll likely have to recompile your favourite software, but you can run vim, emacs, bash, zsh, and whatever else you want, and you don't even have to deal with EBCDIC.<p>As for the comment that there's no development on mainframes, well that's just plain wrong. There's a ton of development, to the point where nearly every single financial transaction you make in a day goes through a Z mainframe, and nearly all major retailers use one.<p>You just can't beat the security and stability. Can you think of another platform where you can hot swap EVERY part? Reportedly, the Z in SystemZ stands for Zero downtime, and that includes OS upgrades and hardware upgrades.<p>No, you're not going to write PHP, Ruby, or node.js on a mainframe, you're going to be using C/C++, Java, or COBOL (surprisingly good language in some cases). But you're also not falling behind technologically.<p>This might come off as preachy, but I really do enjoy working on zLinux, it's a really nice environment, and I think that young people might actually enjoy the experience of working on something that's not x86.

I am interested in mainframes. They have some pretty awesome hardware, great reliability parameters, and some seriously interesting modes of operation. You know how we like to throw data at a hadoop cluster and do a lot of big batch map-reduce jobs? A lot of those end up being very similar to the types of batch jobs mainframes are great at. Distributed transactions/shards/etc for our databases? Again, stuff mainframes have been doing for decades.<p>The problem as I see it is access. Sure, like the SO poster mentioned, Hercules exists, but you can't really run modern mainframe OSes on it (legally and easily that is). Further, you can't really get the same experience, because you don't have the hardware offload or partitioning available to you for real.<p>Heck every time I think I should look into the beasts, I can't even find decent technical documentation describing things.<p>Compare most of the stacks people on this site use - there are complaints if the documentation isn't formatted right, let alone if it is incomplete or wrong...<p>I regularly see things people are talking about and/or doing here, and think "man I think mainframes solved that years ago, it sure would be nice to play around with doing this on a Z series". Of course since I can't just do that, I say whatever and play with it on a few linux instances and then can use it myself - with actual knowledge and some experience.<p>This is why I think no one is interested in mainframes: we can't play. We can't say, how can I...? We can't cut our chops by building a million and one little tools that grow up into really helpful software for everyone. We can't just whip out our phones and read about it when we are whiling away our time in line at the coffee shop or futz with things on an airplane.<p>It's that when compared to the availability of software and information of the bazaar, the high priesthood of mainframes with their mysteries and closed access can't provide us with what we need to just build.

Do I work on a mainframe? What is a mainframe?<p>I work on system i, old name was AS/400. Yes we use RPG, occasional COBOL is around, and CL is the wrapper. Sine RPG has no standards committee it adapts to the times. The majority of our code is free form, looking more like Pascal/C than anything else. We run web services and the like all in combinations of C, RPG, JAVA, embedded SQL, and such. I even have a PhP based wiki out there and some other oddities. Its nice that one program can easily incorporate modules from multiple languages. Don't even get me into the ease of maintaining large databases, adding tables, indexes, or views. It is so simple as to not require an army of people to support our large systems.<p>So why aren't people getting into these systems? The easiest explanation is that its not "sexy" enough. I love sitting in meetings hearing all about how certain groups do X, Y, and Z, and how the platform I work on does not, even though we usually do and with far more reliability and less work.<p>Its all fun in the end, I enjoy coding as much on my Mac as the i. I work with people in daily who interface to us through ODBC, web, and more. I do find that most people don't think we can do something; including so called experts on my platform; simply because they don't even bother to do a google search. My favorite reply to most inquiries is, we might not be doing that today, but by the end of the day I will tell you how we can.<p>Face it, its boring to many people. They see green screens and freak. Its only part of our work, most of the development is fully web faced or similar provided it suits the business needs. Warehouse and much of retail doesn't need more than fast efficient access to information and input.<p>Look at it this way, go see what major medical systems, distributors, and even what the casinos use. You might be surprised.

I do the odd bit of mainframe security stuff now and again. You can argue the toss all you like about hercules, but the fact is that it's not up to scratch for running a proper stack. Saying you can run Z/OS on it with CICS and RACF and DB2 and all the rest to learn is fine, but you try finding half of this stuff.<p>The reason young programmers (and not so young programmers) aren't interested in mainframes is pretty simple, it's largely alien to modern computing users. Mainframes are rarely taught in CS degrees, most people go their entire careers without going near a mainframe and when they do see them, the fundamental concepts (batch rather than interactive, segregating security from the main OS etc.) they recoil in horror.<p>It's also a highly specialist field. Mainframes are typically designed for repetitive tasks with extreme reliability, in the same way that GPUs are designed for specialist programming cases. It's unsurprising then that there isn't exactly a rush to fill the niche.

HPC seems a lot more interesting than mainframes. One of my first UNIX accounts was on a CDC Cyber 205 (shortly before it got decommissioned, I'm not <i>that</i> old) and an ETA 10P supercomputer. The hardware solutions Cray and others came up with to things like cooling (inert liquid fluorocarbon?), wiring looms, etc. were amazing. All but the largest mainframes were kind of boring by comparison.<p>Modern virtualization covers most of the interesting parts of mainframes. There was a lot of weirdness with asymmetric multiprocessing (channel processors for storage, etc.), but a lot of that is fundamentally uninteresting since it is dealing with special cases in an inelegant way. One of the more interesting parts of mainframes were Tandem and other redundant/fault tolerant systems, with multiple processors executing the same instructions in parallel to compare output. I don't know what the state of the art is for that -- obviously in the normal open systems Internet world you could just do this at the application level with multiple machines, but chip/instruction level redundancy might get used more in embedded systems. Conceptually really interesting.<p>The other really interesting hardware areas, to me, are FPGAs/network ASICs, and HSMs. Trusted Computing, specifically enhancements to EFI, Intel TXT, etc. are all really interesting too.

So this is a problem I've been dealing with. Been working out of school for almost two years at a big financial firm, working on Mainframes. I would say I'm relatively lucky in terms of mainframe horror stories you hear, in terms of new software being developed, but yes, ultimately for every "unit" of new work I do, I would reckon there's two units of maintenance.<p>The one main benefit I've seen working on my team, however, is the proximity to some of our business users and knowledge gained about the business that we conduct. I value that more than some of my colleagues working on an internal toolbar, even though they may be using a more modern technology.<p>I feel the difficulty that's quickly arising is knowing when to get out before the pigeonhole widens.

For those that might be, have a look at <a href="http://www.hercules-390.org/" rel="nofollow">http://www.hercules-390.org/</a>

He named MUMPS, here it is: <a href="http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx" rel="nofollow">http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx</a>

I played with an IBM mainframe when I was in university (mostly for the free t-shirt), and the reason I don't really want to work on mainframes for a living is because too much of what I was doing revolved around the machine, as opposed to problems.<p>For example, one problem revolved around creating a file, which required me to specify how many lines and how many columns it was before I could open it.<p>I suppose this is why I prefer higher level languages e.g. Python, as I can spend more time thinking about the problem at hand than, say, the details of HTTP.

I worked at a mainframe facility about 20 years ago in the financial services industry specifically a service provider for brokerages. For multiple generations since about 1975 when the Altair came out, everyone both in and out of the field is certain they'll all be perma-unemployed in about 5 years, yet here they are and there's even a shortage.<p>Its a close analogy to nuclear engineers.<p>The next thing is its MOSTLY a single company ecosystem. The private companies are all "How long did you work for IBM? Never? Then why are you even applying here?". Also if you think buzzword bingo and crazy inflated requirements are an issue outside mainframes, its much worse on big iron.<p>Finally it tends to be very poorly understood. 20 years ago it was all full screen editors and IDEs and automated testing and such but even today all you'll hear about is how 2013 mainframe programmers still have to punch physical card decks. I'm sure there are places that haven't upgraded their mainframe dev tools since MVS/360 in '68, just like you'll find PC places that require devs and/or journalists to use "notepad.exe" as their primary editor.<p>This closely ties into weird ideas about "power" and a demand that "the mainframe" is one individual thing from 1960 which has never advanced since then in any manner, therefore a modern mainframe must be hilariously underpowered compared to a modern iphone. Its actually pretty funny to watch if you have a window into each world.

Too expensive to keep in your bedroom.<p>(Mark Crispin /did/ have a Dec 2020 in his spare bedroom. And I was once jokingly offered NBS-10, but I was in college and renting a room at the time).<p>I visited the Living Computer Museum here in Seattle recently. It's got some great minis in a raised-floor machine room. I wanted to open up cabinets and get my hands dirty again. (Booting up 4.2 bsd on our 11/780 used to walk the disk drive about an inch /thataway/, and it had to be repositioned periodically. You don't get visceral stuff like that now).

For me it was mainly the life-sucking corporate culture that is referred to. I was very interested in mainframes as a young programmer (still quite recently) and I even did a few projects in school centered around Linux for s/390 and Hercules. When it came time to find a job somewhere away from school I couldn't get close to a mainframe without losing interest because of the (sorry to reuse the same phrase) life-sucking corporate culture I would have to penetrate.

Because once you've programmed a computer interactively with good tools there really is no going back to anything else.<p>Mainframe development suffers from crufty tools, a batch-oriented workflow with VERY slow turn-around times, an OS that was positively <i>stupid</i> (mainframes were expected to run mission-critical applications in as little as 32 KiB of memory; not a whole lot of room for user-friendly OS smarts) -- all relics from the dark ages of computing. Kids these days are spoiled by interactive consoles (graphical consoles even!), free-form programming languages like C and Python, fancy full-screen editors and free compilers. They don't have time for mainframe shit.<p>Yes, yes, I know. Modern mainframes can be time-shared and z/Architecture systems run Linux now. But Linux on a System z is not <i>that</i> much different from Linux on your PC or a SPARC-based server; there's nothing inherently "mainframey" about it except the hardware it happens to run on. When people speak of mainframe development they usually mean MVS, JCL, COBOL, and all those horrors.

The fact is that mainframe (emulated at least) COBOL still makes most of the world go around. There are billions of loc in play and maintained. It's out there, cutting your paycheck, processing your loan, or billing your premium.<p>There are some who claim we're approaching a talent shortage due to the sector's inherent underpaying and uncoolness, while others who poo-poo such shortage on the grounds there are plenty of offshore shops trained and lined up to take on the business for less than the old, local talent. The only thing I could contribute there is there are some sectors, banks for example, who cannot outsource because of privacy/financial regs, so they are stuck with internal hires.

The accepted answer relies too much on hindsight and experience, something that young programmers definitely don't have available to base decisions upon.<p>The real answer is: no young programmer today grew up using anything other than a PC or Mac, and no CS graduate today was instructed on a mainframe in college (AFAICT that trend ceased in the late '90s).<p>I'm a very occasional mainframe programmer myself (though I get to use RPG4 rather than RPG2), and I distinctly remember the inner incredulity I experienced during my job interview that anyone (other than banks) was actually still using these things!

I never considered it because I can't think of a problem I need a mainframe for. If there is something really CPU intensive I would use the cloud (map-reduce XYZ) for it.<p>Have you ever come over a discussion here on HN and someone said "Let's use a mainframe for that"?<p>I know there are a few disciplines is science where it is important, but then I would have an interest in meteorology etc. to even consider it. So all the rest I associate with legacy stuff, where I heard horror stories from people. Never "Wow that AS/400 is so cool for X".

I remember using an AS/400 mainframe as a kid (I have fond memories of essentially IM'ing back and forth with my father when I was 4 in his office).<p>I used one helping him with some database migration/upgrade at the same office when I was in my teens. So I've touched mainframes at least, but now all of that is in the fog of time and memory.<p>Now, I'm a Ruby developer and I honestly don't know what I'd use a mainframe for. I don't know when I'd deploy one, what an appropriate task is for them, etc.<p>I get the sense they are good for when you have "big data" stuff to deal with, but it feels more like a 1980's definition of "big data" (MILLIONS of rows, omg!) than datasets in the billions/trillions of rows (or huge datasets like a human genome sequence).<p>I assume on a technical level, being turing complete machines, that I can do 'anything' with them, but realistically what can I do? Can I run a web server? Do data analysis using Hadoop across a huge dataset? Can I easily setup background tasks and queues? Do they do 64 bit instructions? What are the limitations? Can I run Lisp on them? What is the toolset like? Do they support Unicode? What is their database, and what is it capable of?<p>And what's the best place to learn about this stuff? I can go to Barnes and Noble and get a book on C, Ruby, Java or PHP... but finding good <i>modern</i> documentation on mainframes? I dunno where to look, or what would be considered 'too old' for documentation. Anything about Ruby from 2002 is ancient, but perhaps that's the new hip stuff when it comes to COBOL?

I can give you one good reason: Money<p>I was a developer at a bank in my youth. I lived in a very rural area and it was one of the only nearby places willing to hire a kid with a half complete CS degree. I dabbled in web development while there and officially made the switch four years later. I make more than five times as much now as I did back then.<p>Before you say that it's because I was a junior developer, I knew many senior devs there were only making a little more than I was.<p>For the record, that job was the low point of my career. The developers were terrified of technology. Everything was in COBOL (with occasional bits of assembly), and all data was stored in flat files. I remember one developer proudly proclaiming that she didn't "surf the inter-links." I blew their minds by writing a simple regex once. None of them had even heard of regexes.<p>A fair number (not a majority, I hope) of companies using mainframes are still on COBOL. The language isn't OO (there's an OO variant, but no one uses it). It doesn't even support functions! Code re-use means copy/paste, and you can forget about metaprogramming and higher order functions.<p>While it's true that COBOL is turing complete and anything that can be written in C can be done in COBOL, I'd point out that the same is true of Brainfuck and LOLCode. You wouldn't write a non-trivial app in either of those languages, nor would expertise in either of them alone make you a good programmer.<p>I'm sure there are some places using mainframes who are doing cool stuff and aren't terrified of new things, but I still wouldn't want to work there. These days I'm surrounded by really smart people who love learning new things. The fact that I'm also paid an obscene amount of money to do something I love is a plus.

A couple of years ago they actually started a one year COBOL/Mainframe education program here in Stockholm. Mostly backed by banks and insurance companies and from what I have heard many of the people that have applied and graduated have been quite young (for example I read an interview with someone straight out of high school who was about to graduate).

Everything that was good about mainframes does still exist, and is popular, we just call it "the cloud" now.

I think the top-voted answer here is totally off.<p>In c2008, during college, I worked at IBM on mainframes for internships and co-ops. I worked on the Omegamon products on z/OS. Later I worked at Fidelity, where I was minimally involved with mainframe programming.<p>First, mainframes are <i>awesome</i> from an architectural perspective. As one example: when you run a program, you must (I'm simplifying a bit) specify exactly which files it is allowed to access. Moreover, when you create those files, they aren't allowed to grow infinitely - OS will enforce a maximum rate at which a file can grow, and a maximum file size.<p>Or, mainframes have been doing virtual machines for <i>decades</i>. In fact, the only sane way to run a mainframe is to slice it up and run VMs on it. "zVM" is written in assembly and runs z/OS VMs. Nowadays it also runs RHEL VMs. I hear they're putting Intel CPUs in mainframes to run Windows VMs too.<p>There's more, but I just want to illustrate that the granularity from a security perspective is fantastic. There are tons of technical and features that, in my view, would be very interesting to the computer crowd.<p>So why aren't young people interested?<p>First, nobody knows what mainframes are, except that they are dinosaurs and old and slow and whatever. Sun used to give universities pallets of computers running Unix - so guess what university students learned! IBM is trying to bring awareness with their Master the Mainframe competition (which is fun!) or sponsoring Senior Project courses throughout the country.<p>The OP is right that mainframes aren't available to learn on. And they're so <i>different</i> from the concepts we are familiar with that it is difficult to jump in. "Learn z/OS The Hard Way?" "Codecademy: OMVS Edition"<p>Do realize that every time you swipe your credit card, you are <i>very likely</i> hitting a mainframe in a bank somewhere. Talk about throughput.<p>The OP is correct in that if you're not working <i>for IBM</i> writing their mainframe products, you're probably at an awful soul-sucking bank writing COBOL. And really, the COBOL itself is probably not as bad as the fact that nobody knows it and these banks are notoriously bad at documentation or mentoring young people to bring them up to speed. Honestly working at a bank sucks. But banks user mainframes, and banks == bad, and mainframes == slow (somehow), so they are a no-go.<p>If you do work for IBM on their mainframe teams, those guys are honestly the smartest engineers I have ever worked with. They're all, well, old, but they know C and assembly (lots of mainframe software is written in those languages) inside and out. They understand networks. How to increase throughput. If your webapp crashes, nobody cares. If your bank's mainframe has a segfault you are fucked.<p><i>But</i> then you are working in a very specific part of a very large company. Many young people work at IBM and are content there! They recruit heavily from my alma mater. But perhaps the <i>types of young folks</i> who are on HN, stackoverflow, etc are not really interested in working at IBM, much less learning about an esoteric technology. It will only keep you employable in a narrow (and soul-sucking) part of the industry.

I've never seen a mainframe, I don't really even know what one is or why anyone would use one. I'd think that's the main reason, but if you want to go past that, there's pretty much nothing appealing about working on legacy code in ancient languages with people 40 years older than me. I can't imagine COBOL experience looks particularly good on a resume nowadays when you want to leave the mainframe world.

Because not many people think microoptimisations are cool.

I remember working on OS/390 and doing COBOL stuff.<p>I understand how "important" money transactions are. Every time I make a transaction with my VISA or a wire transfer a mainframe is implicated in the process. We get it. It's important.<p>But what has changed in the last 20 years? Credit cards payments? Not really.<p>What has changed is that I know have ubiquitous Internet access, things like Google Maps or Open Maps, things like blogs, forums/discussions websites like Hacker News, eBay, Amazon, price comparators, plane fligths finders, StackOverflow and Quora and all the others helping to disseminate knowledge, Youtube and Vimeo, online university lessons, on demand computer instances and storage and <i>so</i> many other things.<p>So, sure, I <i>could</i> have decided to work on back-end payment processing. We get it. It's important.<p>But young programmers much prefer to either work for --or try to build-- companies shaping the future.<p>And it very much looks like the future ain't build on mainframe computers...