itwbennett writes "Businesses that cut experienced mainframe administrators in an effort to cut costs inadvertently created a skills shortage that is coming back to bite them. Chris O'Malley, CA's mainframe business executive VP, says that mainframe workers were let go because 'it had no immediate effect and the organizations didn't expect to keep mainframes around.' But businesses have kept mainframes around and now they are struggling to find engineers. Prycroft Six managing director Greg Price, a mainframe veteran of some 45 years, put it this way: 'Mainframes are expensive, ergo businesses want to go to cheaper platforms, but [those platforms] have a lot of packaged overheads. If you do a total cost of ownership, the mainframe comes out cheaper, but since the costs of a mainframe are immediately obvious, it is hard to get it past the bean-counters of an organization.'"
As early as 2002, I started to half-jokingly tell young co-workers that were asking that they should learn COBOL as a way to insure them a prosperous career.;-) Back then, most schools were removing or had removed COBOL programming from their course list.
I was half-jokingly telling them that by 2015 they should be earning 150-200K a year as a simple COBOL developer;-)))
See this article from last year saying basically the same thing :
Being a maintenance programmer sucks. Designing is fun, and modern languages are far less tedious than their ancestors.
But bloody hell, if I can make six figures writing cobol, I'll grab myself a cobol book and quit this programming job. A sucky day job isn't so bad when it means you can retire a decade earlier than otherwise.
But bloody hell, if I can make six figures writing cobol, I'll grab myself a cobol book and quit this programming job. A sucky day job isn't so bad when it means you can retire a decade earlier than otherwise.
My advice for new programmers has been exactly this: learn COBOL, study mainframes, move to large cities, make big bucks. Sure, you'll want to gouge your eyes out with a fork, but then you'll be able to afford to have robotic eyes grafted back in!
As a second, I recommend that they learn Unix skills, c, and databases. Still lots of money there, and your original eyeballs will last longer. (It's the path I chose, and I do quite well for myself)
I don't classify myself as a programmer preferring to consult instead. If I have to program my order of preference is Borne/Korn shell followed by Perl then as a last resort C. If there is a need for more esoteric languages I either learn them or just work out what the requirements are and then get a programmer to implement the coding side of the job. Surprisingly you actually get allot more money by delegating responsibility and suffer less stress as well. In addition when the job is complete the consulta
Like you I generally prefer to be referred to as a consultant since it wasn't until recently that I found the proper term (synthesist). I operate across multiple problem domains, engineering disciplines, sciences, etc. By the time I left the Navy, I had trained two other individuals to approach systems analysis and engineering my way and I'm certain they did quite well. The problems are, as I see it: (1) an inability to systematically deconstruct the processes to there core (layered) components, and reengineer them as needed; (2) the inability to delegate to subject matter experts that are available; and (3) the inability to foster teamwork. Usually it's 1 that kills most projects, but 2 & 3 can lead to far larger financial loses as well as losses in prestige and personnel.
About five years into my naval career, they handed me a key to the front (control) panel to every Harris 300/301 computer and the master password for Pacific Fleet. A Harris system engineer also gave an unexpurgated system generation tape (all the compilers, tools, and documentation were uncut). I never knew where I was going on some days but it was sure fun since it was all about understanding the processes and making them tick correctly be it hardware, software, or people. And teaching, of course!
You not only have to know the application field pretty well (or have the bent to intuit it), but you will have to get used to living without local variables and to a one-call-deep call stack.
Don't ignore the naming conventions. It's what they do to work around the lack of re-entrance.
And never, never, never try anything fancy. If you can't keep the state machine in your head, trying to debug it interactively will eat your lunch and your breakfast, dinner, and midnight snacks, as well.
I was subjected to 3 semesters of that crap in college, which caused me to set my price for doing COBOL programming to $300/Hour (USD). It's an awful language which you write using awful tools in an awful operating system.
I rather like mainframes in general though. Hell I can at least tolerate Fortran if it comes down to it. COBOL... not so much.
Perhaps because COBOL isn't very similar to python, PHP or vbscript?
(I regularly use python, PHP and vbscript at work and I've messed around with COBOL at home on a few occasions and while the language is by no means hard to grasp it is a bit peculiar and I could never stand working on a large COBOL project.)
COBOL is an odd beast, with no pointer/references and barely even has the concept of arrays. It makes processing a stream of input records to create a stream of output records, with occasional DB updates along the way, very straightforward. It's fine at text-oriented work and formatting as well (I bet it would work fine to implement an AJAX backend). Anything else, not so much.
MULTIPLY FOO BY BAR GIVING QUX. - Actual math syntax (never used, I expect, but humorous).
The funny thing was, if you used COBOL in its intended problem domain (record-oriented processing), the lack of local variables just wasn't a problem. If your program was to read an employee record from the database, compute tax withholding, print a paycheck accoring to his current pay, and update the tax database with the new totals (known as a "card walloping program") you didn't need local variables, or even arrays. Amusingly, most business programming today is still card walloping. Businesses seem kee
> Why would you higher a "Cobol" coder to program Cobol
Because most "web programmers" we know of do not know how to spell. Our COBOL programming interface (terminal based) doesn't have auto-completion or auto-correction features so misspelled words cause errors only when the programmer hits the compile key.
Compiler errors are cryptic and it takes a lot of time to find and fix the misspellings. So even if the logic of the code was flawless (for which we also have doubts), simple spelling errors cost us too much money thus making HIRING web developers a non viable alternative for us.
I speak COBOL, FORTRAN and can do Job Control Language like an old pro, oh wait. I also program in IBM 360/370 assembler. I'll bet that is almost a lost art.
A vasy amount of 370 programming, perhaps the majority, was done against a late version of mainframe DOS (I can't rememebr the exact name now, but basically the last thing before MVS), because IBM licensed the source cheap. It wasn't true "open source" of course, but you had the source and could customize it and fix bugs and whatnot.
It did not have processes memory protection, or threads. It relied on programs respecting their memory partitions (which was easy to get right in COBOL),
Heck I'd take a job. Fortran, WatFor, WatFiv, Assembler 360 and 370 (loved it), and I could JCL with the best. Archive 5 (removable disk pack) was practically mine for five years at our local UC. I still recall reading the JCL manual and right there on one page for JCL Job Class ranking that if you picked a particular set (J,K,L, or M) and set TIME=24.00.00 it turned off all acounting;-). 12-17 yo back then, but I still have some life left (48 now). Actually, learning from the IBM system engineers is
I learned and taught cobol for awhile, and i can say that cobol is not too far from data entry. It is way too much work to do simple things, and it is way too weak of a language for most things. Its functionality is low that it takes a lot of code to implement simple things. The compiler gives you weird error messages. The language is archane. It is a very miserable language to write in, and I wouldn't code in it for less than several hundreds of dollars per hour, just because its so boring and takes way too much typing to do simple things that would be a snap in other languages.
it's no worse than C and many people use that every day. COBOL runs many many bank's accounting systems and has been doing it for decades, so it must have something going for it. i think the summary is right - people are crazy not to get into this field, mainframes are here to stay inspite of what many people think is a dead technology. in many cases ONLY a mainframe can do the work.
Except for C having "+" "-" and "=" instead of "MULTIPLY units AND cost GIVING total"
If Perl is the archetypal "write only" language, COBOL is the one true "read only" language.
people are crazy not to get into this field
The whole point of TFA was that entry level jobs where people could "get in" went away, then all the senior staff retired or expired, leaving the companies with nothing.
The whole point of TFA was that entry level jobs where people could "get in" went away, then all the senior staff retired or expired, leaving the companies with nothing.
I'd have to say that this is by no means unique for mainframe developers/admins, here in Sweden it seemed like no one was hiring entry-level coders or admins between 2002 and 2008 or so (it seems to have picked up now as companies realise that entry-level coders and admins can be paid less than some guy with 10+ years experience).
Of course, if you looked in the job ads you could easily have been fooled into thinking there were plenty of entry-level jobs, until you read the requirements for just about every
And don't forget that in COBOL, not only is all of your data global to your program, in a typical batch cycle all of the data is global to ALL of the programs.
I used to hate discovering that field XYZ was being modified in jobs that were completely unrelated to XYZ, because the programmer was too lazy to check the appropriate code out of the repository. "Why bother? I can make the change right here and it'll work just fine!"
My favorite line was "Being on a COBOL dev team is like living in a dorm."
They weren't all running in one memory space -- they were all running on one common set of files. For example, you might have a system that accepts 15 files from various other systems, processes those files against a set of master VSAM files and/or against a database, and then creates a set of 15 files that get sent out to other systems. The system itself consists of a series of JCL jobs. Each job consists of multiple COBOL programs and utilities. It's just like bash, except in a way that's nothing at all like bash....
But because any program which opens a file can change any data contained in the file, it's tempting to make tweaks wherever it's handy. Nobody claims it's good practice, but these systems have been under constant tweaking for 30 or 40 years by dozens of programmers. After the first decade nobody even knows what the programs were supposed to do in the first place. (Especially since they have names like AB1243A, where 3 of the 7 characters identify the application, leaving only 4 characters to describe what the program does.)
So the typical bug-hunt consists of noticing that a field has the wrong value, and then checking each individual intermediate file from start to finish to see which job changed it. And if you're on a system that doesn't save its intermediate files it means running all the jobs one step at a time to see where the field gets modified. And THEN you have to open the program and find out what it's doing and why.
It's not all that different from any other system that has data which is shared between various components, but somehow solving the problem using TSO makes it all seem so primitive.
(XEDIT is one of the best text editors I've ever used, though.)
It is a very miserable language to write in, and I wouldn't code in it for less than several hundreds of dollars per hour, just because its so boring and takes way too much typing to do simple things that would be a snap in other languages.
Couldn't you write in a more concise language, and have a simple compiler generate the equivalent COBOL code?
Even if it couldn't reverse-translate existing COBOL code, it could make your life a lot easier for newly written code.
I wonder if a sorta COBOL decompiler would be helpful. Something that would interpret COBOL into a modern language with 100% perfection (not neccesarily perfection in looking good but perfection in producing the same program bug for bug) ?? IS this possible?
What do you mean? COBOL is such an easy language, it uses natural sentence construction. Why do you need specialized programmers, anyway? It can be easily used by managers to generate reports and suchlike.
There's this new language on the horizon, though - it "basically" makes programming a snap for non-programmers, and is likely to eliminate the job of programmers entirely except for a few high-level system engineering projects.
If recruitment would be any easier if the offer included the right to shout "Where is your 'right-sizing' now, bitches?" into the face of the nearest PHB at will, in addition to the fat salary?
"Sam? Sam, this is Frank, CIO back at Engulf and Devour. How is the transition away from the mainframe going? Well, listen. That's what I'm calling about. Yes, yes, I know you're retired, but the cloud isn't working out quite as we'd planned, what with the economy and all, and the kids are having a bit of trouble keeping ol' Betsy going. Yes, I did read that memo you wrote, and it turns out you had some good points. Listen, would you be up for a bit of consulting? Say, $100/hr, 100 hours minimum? Oh. That much? And a car and driver? Well, I'm afraid my budget won't quite stretch that far...No! Please don't hang up! Let me talk to the CEO and get back to you, ok? Please?"
We were just discussing VAX at work. I personally never got to work on one, but a guy I work with grew up learning on them. He said only guys his age really knew much about VAX and I said he was wrong as several guys I grew up with worked at banks that used them.
Mainfames are like Cobol, they aren't going away until the systems that use them die.
O'Malley said in 2000 there were more people in system programming than there are today despite the workloads having quadrupled which is quite an anomaly.
This is an actual sentence from the story. I guess reporters don't need to learn how to use clauses, and editors don't edit.
If E. B. White [bbc.co.uk] were alive today, he'd be spinning in his grave.
I went from UNIX in the late 1970's to mainframe zOS (MVS/OS) to VM and Linux on the mainframe. Anything you can do on an Intel box (or a room full of them), you can do on a mainframe, cheaper and more reliably, once you get past the first big financial hit. I've seen the so-called cost studies that supposedly show the room full of Intel white boxes are cheaper. Once you factor in the "unseen" costs, like the article says, and get past the startup, the mainframe looks VERY good.
Current mainframes aren't what people remember from the past. They're (physically) small, agile, and well suited to certain workloads (can you do 256 concurrent DMA transfers on an Intel box?). The problem is, the only companies that seem to be able to justify them for new workloads are ones that already have them for legacy work. IBM hasn't shown much interest in the low-end of the market (sell small boxen, then discontinue them, push licensed emulation, then kill it, etc).
Our biggest problem is finding people who know the technologies. I give classes to our Linux SA's on this, and they're usually surprised at what the current zSeries boxes can do.
Don't misunderstand, there are plenty of applications where Intel boxes make sense, I work both sides of the fence. I just hate to see mainframes maligned as "obsolete" by people who don't understand what they are now.
...If you do a total cost of ownership, the mainframe comes out cheaper, but since the costs of a mainframe are immediately obvious, it is hard to get it past the bean-counters of an organization.
I've found this to be true of many aspects of IT, not just concerning mainframes. I've watched customers struggle to get decent performance and constantly hit limitations with a certain database product (not Oracle) because it was virtually free and they didn't want to spend the capital cost on an Oracle license. The total man hours spent, time lost, etc on getting their "free" db up to speed vastly exceeded the cost of the Oracle licenses and they still have problems with it.
Finding people who know how to properly use oracle is a real bear. Sure, you can hire people with oracle experience, but most of them were the 'corporate DBA' types who don't know how to do anything out side of the script. I can't tell you how many clients I've seen struggling with their oracle installs; either because the system does not perform as promised, or because the 'cluster' needs to be rebooted every time one node crashes in an unexpected manner.
The Mainframe does it job and does it well. Nothing comes close in Data Throughput Processing with the amount of reliability that a mainframe brings.
Computer 'Experts' have been saying that the mainframe is dead since the early 90s, but here we are 20 years later and I still have a job programming for it, and I don't see it going away anytime soon. Small to mid-level servers just don't have the capacity to deal with the growing about of data generated. Fedex does in the neighborhood of 2 billion transactions a day, you cant just wipe together a Beowulf Cluster and think it will do the job reliably.
Or the better question is. How much do you trust the Federal Reserve to run all its processing on Windows machines. Or Wall Street. Ever consider if a transaction there is 'lost' because a windows blue screen? Even linux machines arent as dependable as a Mainframe. The IBM Z boxes actually have their own redundant parts included in them already. Not to mention that it will phone in its own tech support request.
Mainframes are not for everyone, but they do fulfill their job well when you do need them.
There are also enough tools out there like SOA so that even Java "Kids" can write applications for them easily.
I have been tracking worldwide server revenues for a few years. Over the past 2-3 years the market share between Mainframe, UNIX, Linux and Windows has been very flat: Windows 40%, Unix 35% Linux 14%, mainframe (ZOS) 11% (IDC Worldwide Server Revenue marketshare).
Please define "revenues" as I haven't paid anything to install Linux on any of my Linux servers... EVER. Conversely, this year alone I have spent around $25,000 on various Windows Server licenses.
Does this mean that Windows has 100% "market share" in my server rooms?
I've long been sold on mainframes, but they suffer from a scalability problem - they don't scale down that far.
Here I am, at a small, organically growing company. We've been growing about 25% - 75% per year, and with the economic slowdown, our growth has accelerated. (since we save our prospective clients money) We're too small to afford mainframes. We have about $50,000 invested in our primary hosting hardware now.
We are having to bust some humps to keep up with this year's growth. We've hit the performa
But I bet google loses lots of data. They certainly have had massive amounts of down time (by main frame standards).
search from 2 places, different results. They don't have highly critical data, so they can sloppily store and syncronize as needed. A liberty that Fedex does not.
Easier said than done, matey. Some of these systems are running engines that cause me to cower. I have had issues with SQL/Oracle databases and the financial apps of companies that can afford a few hours, or even days downtime. Systems where it was feasible to run two separate versions at once with duplicate data entry. I've only run theoretical experiments with some of the systems in other companies I've worked at that COULDN'T go down, except for very special periods of time (easter and christmas and ne
Mainframes are fucking rock solid, reliable pieces of equipment.
They do the damned job like nobody's business. The only issue with mainframes is that we haven't kept the people along with the software we chose to run on them decades ago.
Also from the Tao of Programming:
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
Not a new phenomenon (Score:5, Interesting)
As early as 2002, I started to half-jokingly tell young co-workers that were asking that they should learn COBOL as a way to insure them a prosperous career. ;-) Back then, most schools were removing or had removed COBOL programming from their course list.
I was half-jokingly telling them that by 2015 they should be earning 150-200K a year as a simple COBOL developer ;-)))
See this article from last year saying basically the same thing :
http://www.computerweekly.com/Articles/2008/08/07/231774/cobol-programmer-shortage-starts-to-bite.htm [computerweekly.com]
Note: I am to old to start to learn COBOL, this is stuff for young people... ;-)
Re: (Score:2)
Being a maintenance programmer sucks. Designing is fun, and modern languages are far less tedious than their ancestors.
But bloody hell, if I can make six figures writing cobol, I'll grab myself a cobol book and quit this programming job. A sucky day job isn't so bad when it means you can retire a decade earlier than otherwise.
Re:Not a new phenomenon (Score:5, Funny)
But bloody hell, if I can make six figures writing cobol, I'll grab myself a cobol book and quit this programming job. A sucky day job isn't so bad when it means you can retire a decade earlier than otherwise.
My advice for new programmers has been exactly this: learn COBOL, study mainframes, move to large cities, make big bucks. Sure, you'll want to gouge your eyes out with a fork, but then you'll be able to afford to have robotic eyes grafted back in!
As a second, I recommend that they learn Unix skills, c, and databases. Still lots of money there, and your original eyeballs will last longer. (It's the path I chose, and I do quite well for myself)
Parent
Re: (Score:3, Interesting)
Re:Not a new phenomenon (Score:4, Interesting)
About five years into my naval career, they handed me a key to the front (control) panel to every Harris 300/301 computer and the master password for Pacific Fleet. A Harris system engineer also gave an unexpurgated system generation tape (all the compilers, tools, and documentation were uncut). I never knew where I was going on some days but it was sure fun since it was all about understanding the processes and making them tick correctly be it hardware, software, or people. And teaching, of course!
Parent
be prepared (Score:3, Interesting)
You not only have to know the application field pretty well (or have the bent to intuit it), but you will have to get used to living without local variables and to a one-call-deep call stack.
Don't ignore the naming conventions. It's what they do to work around the lack of re-entrance.
And never, never, never try anything fancy. If you can't keep the state machine in your head, trying to debug it interactively will eat your lunch and your breakfast, dinner, and midnight snacks, as well.
Oblig. Ref. (Score:4, Funny)
Parent
Re:Not a new phenomenon (Score:4, Informative)
I rather like mainframes in general though. Hell I can at least tolerate Fortran if it comes down to it. COBOL... not so much.
Parent
Re:Not a new phenomenon (Score:4, Interesting)
Perhaps because COBOL isn't very similar to python, PHP or vbscript?
(I regularly use python, PHP and vbscript at work and I've messed around with COBOL at home on a few occasions and while the language is by no means hard to grasp it is a bit peculiar and I could never stand working on a large COBOL project.)
/Mikael
Parent
Re:Not a new phenomenon (Score:5, Interesting)
COBOL is an odd beast, with no pointer/references and barely even has the concept of arrays. It makes processing a stream of input records to create a stream of output records, with occasional DB updates along the way, very straightforward. It's fine at text-oriented work and formatting as well (I bet it would work fine to implement an AJAX backend). Anything else, not so much.
MULTIPLY FOO BY BAR GIVING QUX. - Actual math syntax (never used, I expect, but humorous).
Parent
odd beast (Score:3, Interesting)
Odd by today's standards.
No flow-of-control stack. No local variables.
Re: (Score:3, Interesting)
The funny thing was, if you used COBOL in its intended problem domain (record-oriented processing), the lack of local variables just wasn't a problem. If your program was to read an employee record from the database, compute tax withholding, print a paycheck accoring to his current pay, and update the tax database with the new totals (known as a "card walloping program") you didn't need local variables, or even arrays. Amusingly, most business programming today is still card walloping. Businesses seem kee
Re:Not a new phenomenon (Score:4, Interesting)
So you don't like working with COBOL. I haven't ever heard of a "small COBOL project".
Parent
Re: (Score:3, Funny)
What would the advantage be in highering a coder? It would be more difficult to reach the keyboard for a start.
Re:Not a new phenomenon (Score:5, Funny)
> Why would you higher a "Cobol" coder to program Cobol
Because most "web programmers" we know of do not know how to spell. Our COBOL programming interface (terminal based) doesn't have auto-completion or auto-correction features so misspelled words cause errors only when the programmer hits the compile key.
Compiler errors are cryptic and it takes a lot of time to find and fix the misspellings. So even if the logic of the code was flawless (for which we also have doubts), simple spelling errors cost us too much money thus making HIRING web developers a non viable alternative for us.
Parent
Re: (Score:3, Funny)
... simple spelling errors cost us too much money thus making HIRING web developers a non viable alternative for us.
Did you mean "non-viable"? Syntax is important too.
Re: (Score:3, Informative)
Web "programmer"... Hahaha, good one!
Web programming != web interface design. Welcome to the 21st century.
Ohhhhh (Score:2, Interesting)
I speak COBOL, FORTRAN and can do Job Control Language like an old pro, oh wait.
I also program in IBM 360/370 assembler. I'll bet that is almost a lost art.
Re: (Score:3, Interesting)
MVS? Get off my lawn!
A vasy amount of 370 programming, perhaps the majority, was done against a late version of mainframe DOS (I can't rememebr the exact name now, but basically the last thing before MVS), because IBM licensed the source cheap. It wasn't true "open source" of course, but you had the source and could customize it and fix bugs and whatnot.
It did not have processes memory protection, or threads. It relied on programs respecting their memory partitions (which was easy to get right in COBOL),
Re: (Score:3, Interesting)
Teaching UNIX security experts to use mainframes (Score:2, Informative)
If you'll excuse the shameless self promotion, this book teaches UNIX security people how to use Mainframes: http://www.amazon.com/Mainframe-Basics-Security-Professionals-Getting/dp/0131738569/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1202746607&sr=8-1 [amazon.com]
Cobol vs. Data Entry (Score:4, Insightful)
I learned and taught cobol for awhile, and i can say that cobol is not too far from data entry. It is way too much work to do simple things, and it is way too weak of a language for most things. Its functionality is low that it takes a lot of code to implement simple things. The compiler gives you weird error messages. The language is archane. It is a very miserable language to write in, and I wouldn't code in it for less than several hundreds of dollars per hour, just because its so boring and takes way too much typing to do simple things that would be a snap in other languages.
Re: (Score:2)
Re:Cobol vs. Data Entry (Score:5, Informative)
no worse than C
Except for C having "+" "-" and "=" instead of "MULTIPLY units AND cost GIVING total"
If Perl is the archetypal "write only" language, COBOL is the one true "read only" language.
people are crazy not to get into this field
The whole point of TFA was that entry level jobs where people could "get in" went away, then all the senior staff retired or expired, leaving the companies with nothing.
Parent
Re: (Score:3, Interesting)
The whole point of TFA was that entry level jobs where people could "get in" went away, then all the senior staff retired or expired, leaving the companies with nothing.
I'd have to say that this is by no means unique for mainframe developers/admins, here in Sweden it seemed like no one was hiring entry-level coders or admins between 2002 and 2008 or so (it seems to have picked up now as companies realise that entry-level coders and admins can be paid less than some guy with 10+ years experience).
Of course, if you looked in the job ads you could easily have been fooled into thinking there were plenty of entry-level jobs, until you read the requirements for just about every
Re: (Score:2)
Might I add one point, since this about programming on mainframes. Ken Thompson once said:
"Using TSO is like kicking a dead whale along the beach!"
Actually, TFA was about sysadmins, and not programmers.
Re:Cobol vs. Data Entry (Score:4, Funny)
Hey!
***
I quite enjoyed TSO
***
Oh wait
***
That was ISPF that I enjoyed.
***
Parent
Re:Cobol vs. Data Entry (Score:5, Interesting)
I used to hate discovering that field XYZ was being modified in jobs that were completely unrelated to XYZ, because the programmer was too lazy to check the appropriate code out of the repository. "Why bother? I can make the change right here and it'll work just fine!"
My favorite line was "Being on a COBOL dev team is like living in a dorm."
Parent
Re:Cobol vs. Data Entry (Score:4, Interesting)
But because any program which opens a file can change any data contained in the file, it's tempting to make tweaks wherever it's handy. Nobody claims it's good practice, but these systems have been under constant tweaking for 30 or 40 years by dozens of programmers. After the first decade nobody even knows what the programs were supposed to do in the first place. (Especially since they have names like AB1243A, where 3 of the 7 characters identify the application, leaving only 4 characters to describe what the program does.)
So the typical bug-hunt consists of noticing that a field has the wrong value, and then checking each individual intermediate file from start to finish to see which job changed it. And if you're on a system that doesn't save its intermediate files it means running all the jobs one step at a time to see where the field gets modified. And THEN you have to open the program and find out what it's doing and why.
It's not all that different from any other system that has data which is shared between various components, but somehow solving the problem using TSO makes it all seem so primitive.
(XEDIT is one of the best text editors I've ever used, though.)
Parent
Re: (Score:2)
It is a very miserable language to write in, and I wouldn't code in it for less than several hundreds of dollars per hour, just because its so boring and takes way too much typing to do simple things that would be a snap in other languages.
Couldn't you write in a more concise language, and have a simple compiler generate the equivalent COBOL code?
Even if it couldn't reverse-translate existing COBOL code, it could make your life a lot easier for newly written code.
Re: (Score:2)
I wonder if a sorta COBOL decompiler would be helpful. Something that would interpret COBOL into a modern language with 100% perfection (not neccesarily perfection in looking good but perfection in producing the same program bug for bug) ?? IS this possible?
Re: (Score:3, Funny)
There's this new language on the horizon, though - it "basically" makes programming a snap for non-programmers, and is likely to eliminate the job of programmers entirely except for a few high-level system engineering projects.
Re: (Score:3, Insightful)
Which is allright if you're Sisyphus...
I wonder... (Score:4, Funny)
Re:I wonder... (Score:5, Funny)
"Sam? Sam, this is Frank, CIO back at Engulf and Devour. How is the transition away from the mainframe going? Well, listen. That's what I'm calling about. Yes, yes, I know you're retired, but the cloud isn't working out quite as we'd planned, what with the economy and all, and the kids are having a bit of trouble keeping ol' Betsy going. Yes, I did read that memo you wrote, and it turns out you had some good points. Listen, would you be up for a bit of consulting? Say, $100/hr, 100 hours minimum? Oh. That much? And a car and driver? Well, I'm afraid my budget won't quite stretch that far...No! Please don't hang up! Let me talk to the CEO and get back to you, ok? Please?"
Parent
VAX (Score:3)
We were just discussing VAX at work. I personally never got to work on one, but a guy I work with grew up learning on them. He said only guys his age really knew much about VAX and I said he was wrong as several guys I grew up with worked at banks that used them.
Mainfames are like Cobol, they aren't going away until the systems that use them die.
Re: (Score:3, Informative)
A VAX is not a mainframe.
Run-on sentence FTW (Score:3, Insightful)
O'Malley said in 2000 there were more people in system programming than there are today despite the workloads having quadrupled which is quite an anomaly.
This is an actual sentence from the story. I guess reporters don't need to learn how to use clauses, and editors don't edit.
If E. B. White [bbc.co.uk] were alive today, he'd be spinning in his grave.
steveha
The modern mainframe - Who cares about COBOL? (Score:5, Interesting)
I went from UNIX in the late 1970's to mainframe zOS (MVS/OS) to VM and Linux on the mainframe. Anything you can do on an Intel box (or a room full of them), you can do on a mainframe, cheaper and more reliably, once you get past the first big financial hit. I've seen the so-called cost studies that supposedly show the room full of Intel white boxes are cheaper. Once you factor in the "unseen" costs, like the article says, and get past the startup, the mainframe looks VERY good.
Current mainframes aren't what people remember from the past. They're (physically) small, agile, and well suited to certain workloads (can you do 256 concurrent DMA transfers on an Intel box?). The problem is, the only companies that seem to be able to justify them for new workloads are ones that already have them for legacy work. IBM hasn't shown much interest in the low-end of the market (sell small boxen, then discontinue them, push licensed emulation, then kill it, etc).
Our biggest problem is finding people who know the technologies. I give classes to our Linux SA's on this, and they're usually surprised at what the current zSeries boxes can do.
Don't misunderstand, there are plenty of applications where Intel boxes make sense, I work both sides of the fence. I just hate to see mainframes maligned as "obsolete" by people who don't understand what they are now.
Bad bean counting (Score:4, Interesting)
...If you do a total cost of ownership, the mainframe comes out cheaper, but since the costs of a mainframe are immediately obvious, it is hard to get it past the bean-counters of an organization.
I've found this to be true of many aspects of IT, not just concerning mainframes. I've watched customers struggle to get decent performance and constantly hit limitations with a certain database product (not Oracle) because it was virtually free and they didn't want to spend the capital cost on an Oracle license. The total man hours spent, time lost, etc on getting their "free" db up to speed vastly exceeded the cost of the Oracle licenses and they still have problems with it.
huh. from what I have seen, (Score:3, Insightful)
Now, I'm just the Linux janitor, not a DBA,
Re:Here is to.... (Score:5, Insightful)
The Mainframe does it job and does it well. Nothing comes close in Data Throughput Processing with the amount of reliability that a mainframe brings.
Computer 'Experts' have been saying that the mainframe is dead since the early 90s, but here we are 20 years later and I still have a job programming for it, and I don't see it going away anytime soon. Small to mid-level servers just don't have the capacity to deal with the growing about of data generated. Fedex does in the neighborhood of 2 billion transactions a day, you cant just wipe together a Beowulf Cluster and think it will do the job reliably.
Or the better question is. How much do you trust the Federal Reserve to run all its processing on Windows machines. Or Wall Street. Ever consider if a transaction there is 'lost' because a windows blue screen? Even linux machines arent as dependable as a Mainframe. The IBM Z boxes actually have their own redundant parts included in them already. Not to mention that it will phone in its own tech support request.
Mainframes are not for everyone, but they do fulfill their job well when you do need them.
There are also enough tools out there like SOA so that even Java "Kids" can write applications for them easily.
Mainframes run the world.
Parent
Re:Here is to.... (Score:4, Informative)
Quarter Windows Linux UNIX ZOS
02/06 34.20% 12.60% 35.00%
03/06 34.40% 12.40% 34.20% 11.30%
04/06 34.90% 11.40% 33.50% 11.40%
01/07 38.80% 17.00% 35.00%
02/07 38.20% 13.60% 31.70% 9.50%
03/07 40.40% 13.40% 31.10%
04/07 36.60% 12.70% 33.20%
01/08 39.20% 13.70% 30.60% 8.40%
02/08 36.50% 13.40% 32.70% 11.80%
03/08 40.80% 14.00% 29.70% 9.40%
04/08 35.30% 13.60% 36.20%
01/09 37.30% 13.80% 33.10% 9.00%
ZOS is not always reported in press releases and I don't purchase the IDC report.
Looks like neither Mainframe or UNIX is dying, or that Linux is dominating.
Parent
Re: (Score:3, Insightful)
Does this mean that Windows has 100% "market share" in my server rooms?
Re: (Score:3, Interesting)
I've long been sold on mainframes, but they suffer from a scalability problem - they don't scale down that far.
Here I am, at a small, organically growing company. We've been growing about 25% - 75% per year, and with the economic slowdown, our growth has accelerated. (since we save our prospective clients money) We're too small to afford mainframes. We have about $50,000 invested in our primary hosting hardware now.
We are having to bust some humps to keep up with this year's growth. We've hit the performa
Re:Here is to.... (Score:4, Insightful)
But I bet google loses lots of data. They certainly have had massive amounts of down time (by main frame standards).
search from 2 places, different results. They don't have highly critical data, so they can sloppily store and syncronize as needed. A liberty that Fedex does not.
Parent
Re: (Score:3, Informative)
I've only run theoretical experiments with some of the systems in other companies I've worked at that COULDN'T go down, except for very special periods of time (easter and christmas and ne
Re:Here is to.... (Score:5, Insightful)
Uh, why?
Mainframes are fucking rock solid, reliable pieces of equipment.
They do the damned job like nobody's business.
The only issue with mainframes is that we haven't kept the people along with the software we chose to run on them decades ago.
Parent
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Mr. Balmer go back to bed, you can count your stock options tomorrow to feel better.