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.
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.
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.
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.
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.
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.
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.
Heck every time I think I should look into the beasts, I can't even find decent technical documentation describing things.
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...
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.
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.
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.
I'm not saying that this makes it easy to get access to, which is still a real problem.
I could very well be wrong about this though. Maybe they exist and I just don't know the ecosystem terminology, but that itself is a problem, I can't even figure out how to get into the ecosystem if it exists.
for MVS, z/OS, pretty much any mainframe system (other than S390 linux, which is kinda cheating)
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.
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.
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.
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.
Look at it this way, go see what major medical systems, distributors, and even what the casinos use. You might be surprised.
> The majority of our code is free form
> I enjoy coding as much on my Mac as the i.
> They see green screens and freak.
Her company's reason for the switch was making it easier to train new cashiers. I'm expecting they'll see a net decrease in overall cashier speed though.
I understand a lot of big orgs use them - likely because when those orgs started there were no other compelling options. There are more options today, generally more cost-efficient, partially because it's easier and cheaper to find people with expereice with modern hardware and software.
Given that I don't see much trend for small businesses to use them, and many small businesses grow in to the larger businesses, it seems like it's going to be a continual marginalization of "mainframes" as part of business. They'll never go away entirely, but it'll be harder to find people to work on them. I don't think it's an issue of 'sexy' as much as 'demand'.
If 'sexy' was a huge component in job skills, I couldn't explain so many Java developers. :)
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.
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.
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.
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.
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.
I feel the difficulty that's quickly arising is knowing when to get out before the pigeonhole widens.
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.
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 come across mainframes all the time at work, but I'm an IT auditor and I deal with legacy systems on a daily basis.
Its a close analogy to nuclear engineers.
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.
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.
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.
(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).
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).
Mainframe development suffers from crufty tools, a batch-oriented workflow with VERY slow turn-around times, an OS that was positively stupid (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.
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 that 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.
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.
There are offshore people on mainframes in the banking industry, but the problem faced is more in explaining why or how to do something business-wise. Once some of the older ranks , and thus their experience/knowledge, retire there will be less people who understand why the system does what it does, with hoards of offshore who just pump code leading to a crippling process to which I imagine will hinder any non-trivial change.
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).
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!
Have you ever come over a discussion here on HN and someone said "Let's use a mainframe for that"?
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 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.
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.
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).
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?
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 modern 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?
LOL that's a pretty good description of what the financial services company I was working at 20 years ago. Right next to my WAN cabinets was a fully automated tape robot holding something like 4 exabytes possible. 60 gigs on each new 3590 tape cartridge times 100 on a shelf times 10 shelves per "bookcase" times 2 cases per track segment times 30 or so segments long (oh yes I'm well aware that's like 100 yards long and that was a huge PITA WRT my WAN cabinets) that's 3.6 exabytes if stuffed full. Thats alot today. But this story is from 20 years ago.
I was not involved in the DB side but supposedly they had a continuous stream of IRS/SEC related inquiries about individual stock transactions from 7 years ago or whatever.
Supposedly the recent tapes store 4 TB per cartridge, so run the math again and ...
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.
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.
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.
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.
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.
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.
It is interesting to see that the applications themselves move very slowy, despite addition of colors/animations. Corporate apps are still mainly forms and databases systems. The technologies change, but they still have same architecture than in 60s/70s. Nothing new since mainframe, lisp and smalltalk.
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.
First, mainframes are awesome 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.
Or, mainframes have been doing virtual machines for decades. 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.
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.
So why aren't young people interested?
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.
The OP is right that mainframes aren't available to learn on. And they're so different from the concepts we are familiar with that it is difficult to jump in. "Learn z/OS The Hard Way?" "Codecademy: OMVS Edition"
Do realize that every time you swipe your credit card, you are very likely hitting a mainframe in a bank somewhere. Talk about throughput.
The OP is correct in that if you're not working for IBM 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.
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.
But 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 types of young folks 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.
My experience as a web developer, though, has led me to believe that while mainframes do some really neat things, they just aren't necessary anymore. I'm certainly more than a little biased, but I don't see any reason why they shouldn't just transition to cloud or virtual web servers.
We have a mainframe in our university (donated by IBM) which is used exclusively for teaching. As far as i know, this isn't the only one here in Germany.
Allthough the material isn't as omnipresent like tutorials for beautifull HTML pages, one can sure find some. It's probably that most of the material is hard to find and not really sexy.
In case you are interested (only in German, though):
Why do "mainframe" computers stick around? (I use quotes because I'm not sure what qualifies a machine as a "mainframe"). I'm curious, and not trying to start an argument.
Is it that more popular operating systems and languages we see on HN/SO aren't up to the task of operating at the scale/responsiveness required by financial institutions? Technical lock-in? If-it-aint-broke-don't-fix-it?
I'm mildly surprised that these systems haven't been replaced by something more modern (or at least, modern sounding), but I am blissfully unaware of the world here and am likely missing important data that causes these types of institutions to use mainframe hardware/software.
But mainframes have a lot of advantages because they are integrated systems designed for exactly the sort of high-throughput tasks that businesses use them for. Their (single-threaded) processing power is good but not outstanding; where they really shine is parallel I/O performance which lets you execute large numbers of operations per second, or distribute workloads across large numbers of processors with extremely high bandwidth inter-processor communication.
They're also designed to be highly reliable, redundant and modular. You can do things like upgrade and replace processors, RAM, and disk drives without interrupting applications. And speaking of processors and RAM, modern mainframes can scale to >100 processors and terabytes of RAM in one system.
Yes, you can build systems with similar specs and capabilities with clusters of commodity hardware, but then you have the complexity of managing a distributed system. With a mainframe, you have a single beefy machine. You'll also have a support contract with the manufacturer to call when things break, so they can be responsible for doing any complicated maintenance.
On the downside, of course, they're expensive in the "Q: how much does it cost? A: how much do you have?" way that enterprise pricing works.
It should be noted that the industry is trying to make a push for porting the COBOL applications to Java to help resolve issues regarding an aging workforce, hiring, and documentation.
Compliance does not mean just "meets all the unit tests", but also meets specifications like guaranteed uptime, stringent physical security (that alone could rule out many cloud services), tight audit trails, recoverable failures, incorruptible data, and so on.
It opens up a whole can of worms that will dwarf the development cost of the software conversion alone. It's easy to see why many banks stick with their current working system.
I am wondering if in 40 years from now, youngsters would love (or not) to work with [ruby|java|js|nodejs] programmers.
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.
But what has changed in the last 20 years? Credit cards payments? Not really.
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 so many other things.
So, sure, I could have decided to work on back-end payment processing. We get it. It's important.
But young programmers much prefer to either work for --or try to build-- companies shaping the future.
And it very much looks like the future ain't build on mainframe computers...