Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

38  
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 '11 at 18:24
7  
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 '11 at 19:28
80  
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 '11 at 19:51
4  
If you haven't had a virtual mainframe to play with, Beekguk, it's because you haven't gone looking for one. –  JUST MY correct OPINION May 12 '11 at 0:42
44  
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? –  kevin cline May 12 '11 at 4:05
show 18 more comments

23 Answers

up vote 91 down vote accepted

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?

share|improve this answer
11  
"If I got in and found I didn't like it, how do I get out?" --- leave? –  Aaronaught May 12 '11 at 1:22
34  
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. –  JUST MY correct OPINION May 12 '11 at 2:02
22  
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. –  JUST MY correct OPINION May 12 '11 at 3:44
9  
@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. –  Matthew Frederick May 12 '11 at 9:36
4  
@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. –  Matthew Frederick May 12 '11 at 15:58
show 6 more comments

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.
share|improve this answer
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. –  Satanicpuppy May 11 '11 at 16:06
show 2 more comments

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.

share|improve this answer
show 3 more comments

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.

share|improve this answer
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. –  Morgan Herlocker May 11 '11 at 18:01
show 2 more comments

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.

share|improve this answer
11  
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. –  Satanicpuppy May 11 '11 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. –  Satanicpuppy May 11 '11 at 16:41
2  
@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). –  Satanicpuppy May 11 '11 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 –  Steve314 May 12 '11 at 7:35
2  
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. –  Zoran Pavlovic Jan 15 '13 at 11:57
show 11 more comments

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.

share|improve this answer
show 1 more comment

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)

share|improve this answer
show 2 more comments

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.

share|improve this answer
4  
@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. –  Satanicpuppy May 12 '11 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). –  James Anderson Apr 3 '12 at 8:22
show 3 more comments

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.

share|improve this answer
1  
You don't need a Z-Series 900 in your basement. You can run Hercules on your PC -- even an old one. –  JUST MY correct OPINION May 12 '11 at 0:47
add comment

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

share|improve this answer
1  
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. –  James Anderson Apr 3 '12 at 8:57
show 1 more comment

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.

share|improve this answer
4  
@bot403: I believe you. Badly-designed processes are our specialty. –  Joshua Smith May 11 '11 at 15:00
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; –  Joshua Smith May 11 '11 at 20:43
show 4 more comments

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.

share|improve this answer
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. –  Morgan Herlocker May 11 '11 at 17:57
1  
Unfortunately you can still use a relation database just like a flat file, and some people do. –  Michael K Apr 3 '12 at 12:09
show 2 more comments

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.

share|improve this answer
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 Hodgson Jan 15 '13 at 5:14
add comment

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.

share|improve this answer
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))? –  David Thornley May 11 '11 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). –  JUST MY correct OPINION May 12 '11 at 0:50
1  
@David, no it does not include the (overpriced) software. Just the operating system. –  Tangurena May 12 '11 at 1:15
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
show 2 more comments

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.
share|improve this answer
1  
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 '13 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! –  James Anderson Jan 15 '13 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. –  Apprentice Queue Apr 8 '13 at 19:21
show 1 more comment

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.

share|improve this answer
add comment

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?

Ken

share|improve this answer
add comment

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.

share|improve this answer
add comment

I am Mainframe Programmer from India with 10 years' of experience in COBOL, Assembler, DB2 ,CICS and JCL. Once intriguing, but now appearing boresome and meet-the-dead-end I want to move out of Mainframe. The problem with mainframe can be squarely atributed to IBM's conservative attitude. IBM captivating z/OS in z/Architecture and not unlocking its potential in Client-Server architecture may be a good business decision in short term, but it's killing Mainframe in the long-term. Yes, I know Mainframe can take on Java workload, but tell me how many shops run Java workload on Mainframe compared to Linux? I personally would not suggest any fresh man to join Mainframe Programming where they can't exploit their full Programming intellect.

share|improve this answer
show 2 more comments

The common noodle soup pretty prevalent in mainframe systems is a horrible drain on time ressources and efficiency... common and easy tasks (such as adding a new description field to a user profile in a database and the rest of the system) that in most cases would be easy to do.

is weeks and weeks of work, mainly because the code on any running mainframe ssytem is old, never been refactored and has so many moving parts that your head will spin from the consequences of changing a single thing....oh and dont get me started on those darn bitfield everywhere.....

share|improve this answer
2  
did you check moderator notice posted right there, under the question asked? "We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed." –  gnat Sep 6 '13 at 8:40
add comment

I'm 26 and I have NO experience in the field but i'd love to get some and learn, all the "cultural issues aside" just add up to a reason TO get involved. Why? because these kids are misinformed cocky baffoons who think they're smart but MOST of the mainframe code HASN'T been tested, the jump to servers HAS NOT happened. While you WILL be in a cloudy, musky backroom you'll be in a situation where your job is of such vital necessity you'll be able to blackmail whatever executive figured out you knew what you were doing every single time there is a crisis into paying you a bonus or you'll spontaneously quit-especially if like me you have a recongized disabiltiy and easy access to social security to fall back on. The corporations that use them while few ARE NOT Adapting, they are dinosaurs and will continue to be so for a very long time. It won't be addressed until the horrors of Y2k are actually realized. A crisis is the only thing that will trigger the "Server revolution" you arrogant fools want.

my father is a systems implementor on mainframes and I'm blown away at the level of cocky arrogance. Yes. I too grew up on windows and have tinkered around with visual studio and am blown away by The new programming langauges and their fancy smanciness

but if you think "oh. it will just be rewritten in C# or whatever bumfuck new language I want" you're an arrogant fool who like icarus is flying too close to the sun. There's over 200 billion lines of code of this shit and almost none of it is tested

it's 2013 and the banks are ALREADY experiencing glitches

and trust me, it doesn't get any more dinosaur like than the banks and insurance companies who are the ones still using them

http://www.bbc.co.uk/news/technology-21280943

There's one big bank in our country that has a total of 50 different mortgage systems as a result of history and mergers and acquisitions.

"That's insanity. It should have maybe one for retail and one for wholesale. But 50 is ludicrous... it hugely raises the danger.

If you get into this, admittedly bonesuckingly boring culture you're going to be making your arrogant cocky friends look like a bunch of fools and being paid SHITLOADS of money to be the ONLY person that can save the corporation from their own hubris.

Wake the hell up. None of your arguments are any sounder then "well the new languages are trendy" doesn't matter. The companies aren't adapting ot the trends.

Think twice. the laws of basic economics are breaking down because the banks are too damn big. institutions that god damn monolithic change glacially.

It's true that less and less people will be on them-but they're going to have to pay people for those transitions.

WAKE UP. the big banks are NOT efficient. That's a myth.

the 10% of investors who routinely beat the market are those who are CONTRARIAN to everyone else. You are the 90%.

the consensus in economics is often wrong.

while the current generation of programmers doing it keep asking "Why you'd want to do it" if you were NEW here's why: THE PEOPLE WHO ALREADY HAVE YOUR JOB ARE DYING OFF AND RETIRING.

When they're GONE, it's going to be a VACUUM where the few babyboomers left and the young kids who DId learn are basically competing over what's left if they're smart

COBOL is the one that making sure your money is safe at the bank. I know it's an ugly language, but no other language does better job. And that's a fact, Mam.

http://www.computerworld.com/s/article/9227263/The_Cobol_Brain_Drain

More than 50 years after Cobol came on the scene, the language is alive and well in the world's largest corporations, where it excels at executing large-scale batch and transaction processing operations on mainframes. The language is known for its scalability, performance and mathematical accuracy. But as the boomer generation prepares to check out of the workforce, IT executives are taking a fresh look at their options.

In a recent Computerworld survey of 357 IT professionals, 46% of the respondents said they are already noticing a Cobol programmer shortage, while 50% said the average age of their Cobol staff is 45 or older and 22% said the age is 55 or older.

Closing the talent gap Where do you find Cobol programmers these days? College graduates with Cobol training are in short supply. In Michigan, for example, state schools that offer Cobol programming education have cancelled classes because of a lack of interest. "They can't get anyone to enroll," says Jonathan Miller, director of information systems and services for the government of Michigan's Saginaw County. But some colleges are still providing Cobol training -- with help from IBM. The mainframe vendor has developed curricula in association with more than 80 colleges and universities ranging from Brigham Young to Texas A&M.

"We donate hardware and software, help with the curriculum, and they graduate hundreds of people every year," says Kevin Stoodley, an IBM fellow and CTO.

Guardian Life Insurance has recruited Cobol programmers from Workforce Opportunity Services, a nonprofit that collaborates with business clients and local colleges to train economically disadvantaged students to work in less popular technology disciplines such as Cobol programming. "They take kids from disadvantaged neighborhoods and provide them as consultants," says former Guardian CIO Frank Wander, who now has his own consultancy, IT Excellence Institute.

"It's sort of a work-study program. We have over 200 consultants today in five states, and we're expanding," says Workforce founder Art Langer.

BNY Mellon and many other organizations also increasingly rely on outsourcers to pick up maintenance and support duties. But for many users, an offshore locale is not the place to keep the institutional knowledge of the business rules behind the code. David Brown, managing director of BNY Mellon's IT transformation group, says the bank wants those skills in-house. Fortunately, it's not all that difficult to cross-train programmers in Cobol. "Right now, it's pretty easy to hire programmers. And if they understand Java, I can bring them back to procedural languages like Cobol," Brown says. The trick is to develop a curriculum that teaches not just Cobol, but the business rules behind the code that runs the company, he says, adding, "We need to make sure we can roll that forward."

share|improve this answer
add comment

protected by maple_shaft Sep 6 '13 at 9:35

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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