Yes, that's very true -- even a data center a couple of miles away needs to have redundant power sources and communications at least.
Sometimes even due diligence on the part of the company owning the data center isn't enough, though.
I still remember the incident at NWA where the airline was paying for redundant fiber connections between the computer center where the mainframes lived and the operations center (SOC) where most of the users were, but the communications company they contracted with decided to put the two fiber lines in close proximity to each other.
It only took a single backhoe to cut through both fibers and cause a major outage.:-(
In that case, the folks in the SOC who needed access to the mainframe system were able to jump in their cars and cross the river to use our (the programming staff's) terminals.
Try doing that with the data center located halfway across the planet!
I would speculate that a company which is too cheap to invest in its own domestic data center is also going to be too cheap to pay for the level of redundancy that you're talking about.
Sadly, upper management (in general) doesn't seem to possess a very good understanding of IT or related issues, so the various risks inherent to a distributed infrastructure are likely as opaque to them as are most other technical issues.:-(
Having one's data center (and one's critical corporate data) on the other side of the planet can be extremely unsettling to a company when the comm link between the company and the data center goes down...
Some software companies or IT shops might have a highly compartmentalized (stratified?) software development process with senior people doing mainly design work and junior people writing the actual code and doing little else, but that really hasn't been the case in most the places I've worked during my career.
The beginning programming jobs I've been exposed to over the years have *not* been just "coding" positions -- writing code is only one of the tasks involved in the job. The person also has to do a number of other things, often including the initial requirements gathering and various follow-up tasks with the end users or customers, creating the interface/program/database design, doing the actual coding itself, writing or updating any technical documentation which might exist, doing formal unit testing before acceptance testing, doing regression testing if required, and finally providing the actual support to the customer after the code is loaded into production.
That was the case for me when I first came out of school (I was effectively put in charge of a particular set of programs and had to do it all), and it's still the case in my current place of employment.
Maybe some companies can actually afford to have dedicated design people who don't actually write the code themselves, but I guess the places I worked didn't have the resources required to have that type of functional separation. The one or two experts in each area had to do it all, since there wasn't anyone else who know each area well enough to produce an effective design.
Word has serious issues between versions, however.
on
The Browser Wars Are Back?
·
· Score: 2, Insightful
It's a nice tool for documents of small or medium size, but the document format is a nightmare. Try changing the margins in Word 97, for example, and then reading the result in Word 2000. The margins are all messed up in many cases...:-(
If only they'd kept the document format simple and added a nice "review codes" feature like WordPerfect used to have...
That isn't why we implemented it at first (it was initially put in place because we had a few offshore contractors imposed on us and we wanted to do sanity checking of their code before we allowed it on the production system we supported), but we found that such code reviews could also be an excellent teaching tool when someone new came on board.
In the Fortran variant I was working in until a few years ago, local variable names were limited to five (5) characters, and many otherwise obvious functions were performed by a series of external subroutines with six-character names usually beginning with SY (for "System").
That meant that the code itself could be quite hard to follow without some sort of logical commentary accompanying it.
I tended to comment my code quite heavily in that context, since I'd already had experience with uncommented code in that context and knew how hard it could be to follow...
(Try reading Fortran that's all in column 7 and which is mainly composed of arithmetic IFs and CALL statements sometime and see how intuitive it is!)
When using more modern languages, I tend to comment less, sometimes a lot less. It usually comes down to a judgement call on my part as to whether or not I think the code would be easy for a newcomer to maintain...
We used to implement code reviews at my former workplace, but they were more "sanity checking" peer reviews than anything else. They didn't take very long, and it gave one or two other people a chance to see how understandable or generally logical the changes were.
That type of thing doesn't work as well for large changes, but we found that for small ones it sometimes can be a useful thing.
They actively mark the start and end of each block of commercial messages at record time, and then can either skip those blocks automagically (with around 80% reliability in my experience) during playback or can quickly skip back and forth between program segment start locations (end-of-commercial block markers) using the arrow keys.
The former turns several minutes of intrusive commercial messages into a fractional-second screen blip and a little icon in the lower righthand corner indicating commercial skip, while the latter has the general effect of breaking a show up into chapters that can be navigated between at will.
A 30-second forward skip button doesn't compare...
An e-mail is on its way... I'd not considered teaching (I like mentoring, but the idea of being in front of an expectant classroom makes me a bit nervous), but it's certainly worth considering...
I'm a former Northwest Airlines applications programmer/analyst with a BSCS and 15 years of pretty solid experience who has been looking for a new permanent place to work for over 2.5 years now, and my local area (the Minneapolis/St. Paul metro) has had a number of large companies lay off a large number of people over the past few years including my former employer (NWA), Unisys (which has a heavy airline/mainframe presence in the Twin Cities), Lawson, IBM, Qwest, Verizon, and a number of others.
In the case of NWA, many IT people were laid off based on the organization or project they were affiliated with, and whole trees of people were lopped off from the manager on down. I know several folks who I considered top-quality techie types who were let go in October 2001 because they had moved to a project that was more technically interesting or high-profile a few years ago, but which was considered a non-critical project by management in the post-9/11 airline environment).
In other cases (such as in my case), cuts were made based purely on seniority, and my 13 years put me on the bottom of the ladder compared to the remaining folks I was working with in Flight Operations (I survived the major IT cuts in late 2001 only to find myself nickel-and-dimed out a few months later when we all thought it was over).
Given the experience level of my peers I was a logical choice, at least by that measure, but I'll frankly put my general level of technical acumen against anyone here. Or there, for that matter.:-)
Unfortunately, that wasn't the measurement used. Ability rarely factors into such choices, as two layoffs in the past 15 years have taught me, particularly when the layoff parameters are being determined mainly by bean counters rather than technical management.
With such a glut in unemployed techie folks in the local area, many of them quite senior, it's hard for someone with only 10-15 years of experience to get any sort of contract work because there are a fair number of 20-30 year people also laid off who are now competing for a much smaller number of positions. And contract work is almost all there is. A few firms seem to be hiring real permanent employees, but competition is so fierce that one has to be an almost perfect tech-skill+line-of-business match in order to get a first-level interview.
I know several folks who have roughly my experience level who are still out of work after more than a year, and it sure isn't due to a lack of technical ability or a lack of effort. From what I can tell, it's mainly due to a large number of people seeking a small number of positions, and to an increasing tendency for companies to require more and more specialized business and technical skillsets even for general IT positions.
The folks who have "left IT" according to common statistical measures are a mix of all types.
Some fit the stereotype of being "less skilled" or interested only in the financial aspects of an IT career, and I'm in agreement with those who say "good riddance" to such folks, but there are probably at least as many others who are hard-core bit twiddlers or talented designers or whatnot who just happened to be in the wrong place at the wrong time, and who are finding it difficult to obtain employment in IT at a time when companies are hiring specialized short-term contractors in lieu of more generalized long-term employees.
When an IT position isn't available, and when the six months or so of unemployment runs out, a former IT person has to do *something* in order to make ends meet. In my case, it will probably end up driving a truck or doing some sort of generic office work so I can continue to pay the bills.
That doesn't make me any less interested in IT, and I'll still be looking when I'm not working at a lesser position, but for statistical purposes I'll have dropped off the radar and will no longer count as an unemployed IT position. It's a very misleading statistic...
If this comes across as a bi
Try adding the following to ~/.inputrc
on
Bash 3.0 Released
·
· Score: 1
Add the following two lines to the.inputrc file in your home directory (or create it if it doesn't exist):
That produces 4DOS-like command history behavior, at least on my box (Mandrake 8.2).
Try using a "CD replacement" like WCD instead...
on
Bash 3.0 Released
·
· Score: 1
This CD command replacement acts much like the well-known ACD utility used to under DOS -- it allows the user to move to a subdirectory even if only part of that subdirectory name is entered (regardless of its position in the tree), it shows an interactive picklist of options if more than one subdirectory matches the entered string, and it also provides a nice ncurses-bases interactive interface for traversing the directory tree in a visual manner.
Information, source, and binaries for various OSes can be obtained here:
Yes, z/OS is apparently certified as a UNIX(tm), but its history is certainly not the same as Unix-like OSes, and neither is its feature set.
Also, mainframes like the Unisys A-series and 2200-series boxes use MCP and OS2200, and those are about as different from a "Unix" as one can get and still be running in text-mode.:-)
Are you talking about things like Sun E10k's and the like (which might fit a loose definition of mainframe)?
The typical UTS terminal connected to Unisys 1100 and 2200 mainframes in the 80's and 90's did all text and screen editing (line/character insertions and deletions) locally and could protect, justify, and even selectively enforce input in defined character fields on the screen without communicating with the host box at all.
That's why such terminals are called "block mode" terminals, and why they behave so differently from host-dependent terminals like the VT1xx.
Some of the later UTS terminals also did graphics and I think one could even use a mouse with MAPPER on the mainframe under some configurations.
Check out the following site for more information.
If you've ever wondered what hard drives were like in 1968, this might be the page for you.:-) OK, it was a drum, but it's almost the same as a disk!
Bargain PDA? I took the low road and found one...
on
Zaurus SL-6000 Review
·
· Score: 1
I purchased a Palm M105 (B&W screen w/toggleable backlight, 160x160, 8MB, PalmOS 3.5.1 in ROM) from a nice guy on eBay with a new serial cradle, a new Palm folding keyboard, padded case, a trio of spare styluses, and four different colored faceplates for $49.95 + S&H. And that isn't an atypical price.
Is it the latest and greatest? No, far from it, but it'll work with a standard serial port via Pilot Link (available for OS/2 and Linux and maybe other OSes), it'll keep track of lots of things here at home thanks to the freeware "DB" database (and the various database templates I'm creating), it helps me keep track of the stars at night thanks to a nifty Palm program called Sky Chart, it plays a mean game of both Hearts and Fluxx, and it uses standard AAA batteries so I won't have to worry about its proprietary recharacable battery dying on me. It doesn't have one!:-)
It's not for the type of user that likes all those whistles and bells, but believe me those older Palm models can be useful -- and used ones are CHEAP (as in inexpensive, not as in poorly made ).
Want a bargain? Buy an older PDA. It'll be a lot more useful than many of you might suspect, and if it gets stolen by the neighbor's kid, eaten by your dog, or falls overboard during that fishing trip, and you have a proper backup (not hard to do with the aforementioned software), it only takes a little bit of time and money to get a full replacement.
Unfortunately, a lot of that software doesn't run under Linux, making Linux less useful to me.
Another interesting point, though: many of the programs I prefer to GIMP are shareware programs that were written by individuals or by very small development teams, and those programs don't seem to have some of the UI usability issues that I see in GIMP.
Maybe GIMP needs to fork into specialized versions with smaller development teams? As it is, it's a huge monolithic program which seems very awkward to use compared to some of its competitors...
Thanks for the link, also. However, the article you indicate seems to state that USAir got most of the US$1.5 billion in load guarantees, America West got some, and the rest was scattered among three other airlines (one of them being World, I assume), and it roughly corresponds to my own impressions (i.e., not many).
You must have other information sources? I see nothing at all in that article indicating that WN has received anything, for example, not to mention a few other airlines you listed.
not all of the mainframes in current use (or which are currently being marketed) are from IBM, or are even based on IBM's mainframe architecture.
At least two of the top four airlines in the US are still heavily using Unisys mainframes, for example. Those are based on the Sperry UNIVAC 1100-series boxes of the 1960's and 70's (a 36-bit architecture which is word-addressible, not byte-addressible) and an OS called OS2200 (or OS 2200), and many of them are still running applications software that was originally designed and written during that era (though it is constantly being modified in-house, of course).
As others here have said, mainframes are simply not the old coal-fired boxes that they are sometimes portrayed to be, certainly not on the hardware side of things. What they really are is a centralized server whose design is specialized around very high levels of reliability/recoverability and high levels of data throughput combined with the ability to serve applications to thousands of users with very low levels of system and communications overhead for each user action.
That makes them exceedingly efficient at what they do, not just large and expensive.:-)
Also, while most of them tend to have some "stone age" elements on the applications software side, keep in mind that most of the older software tends to be found at the API level, not in the core of the OSes which support that API.
While application code on those boxes might be very old indeed, or at least based on very old software interfaces, the hardware and software platforms which form the guts of those mainframe boxes have been moving forward over the past few decades just as quickly in many areas as they have been in the desktop and smaller server world.
Part of the reason that such systems still exist is certainly tied to various economic factors like the difficulty of porting applications and such (when one has several million lines of code which is tightly tied to one's business rules, one doesn't rewrite that software arbitrarily).
However, some companies still use mainframes for another reason: they have a few applications which simply cannot fail if the company is to operate effectively. In some cases, even a small outage can cause cascading effects thorughout the company and cost the company millions of dollars. Or more.
My own experience is with major airlines, and they are one of the largest users of such systems in key areas, but financial entities such as NASDAQ have been using similar large systems for years because they need a very high level of reliability and recoverability.
I really think it's a shame that more people are not exposed to these types of systems in college so they can get some sense of what those machines are actually designed for (and what the hardware and software in those boxes is actually capable of).
While Unix, Windows, and Mac systems are ubiquitous these days, they simply do not define all existing computing architectures by themselves, nor can they effectively or efficiently handle all types of computing tasks. Not yet, anyway...
Slashdot Mirror
I still visit Exec-PC BBS from time to time to grab older DOS or OS/2 files that I can't easily find anywhere else.
Curious? Click here to telnet
Yes, that's very true -- even a data center a couple of miles away needs to have redundant power sources and communications at least.
:-(
Sometimes even due diligence on the part of the company owning the data center isn't enough, though.
I still remember the incident at NWA where the airline was paying for redundant fiber connections between the computer center where the mainframes lived and the operations center (SOC) where most of the users were, but the communications company they contracted with decided to put the two fiber lines in close proximity to each other.
It only took a single backhoe to cut through both fibers and cause a major outage.
In that case, the folks in the SOC who needed access to the mainframe system were able to jump in their cars and cross the river to use our (the programming staff's) terminals.
Try doing that with the data center located halfway across the planet!
I would speculate that a company which is too cheap to invest in its own domestic data center is also going to be too cheap to pay for the level of redundancy that you're talking about.
:-(
Sadly, upper management (in general) doesn't seem to possess a very good understanding of IT or related issues, so the various risks inherent to a distributed infrastructure are likely as opaque to them as are most other technical issues.
Many of the icons for OS/2 Warp were designed by Susan Kare, who also designed many of the icons for the original MacOS and for Windows 3.x...
Here are some of the Warp icons she created for IBM.
Having one's data center (and one's critical corporate data) on the other side of the planet can be extremely unsettling to a company when the comm link between the company and the data center goes down...
Some software companies or IT shops might have a highly compartmentalized (stratified?) software development process with senior people doing mainly design work and junior people writing the actual code and doing little else, but that really hasn't been the case in most the places I've worked during my career.
The beginning programming jobs I've been exposed to over the years have *not* been just "coding" positions -- writing code is only one of the tasks involved in the job. The person also has to do a number of other things, often including the initial requirements gathering and various follow-up tasks with the end users or customers, creating the interface/program/database design, doing the actual coding itself, writing or updating any technical documentation which might exist, doing formal unit testing before acceptance testing, doing regression testing if required, and finally providing the actual support to the customer after the code is loaded into production.
That was the case for me when I first came out of school (I was effectively put in charge of a particular set of programs and had to do it all), and it's still the case in my current place of employment.
Maybe some companies can actually afford to have dedicated design people who don't actually write the code themselves, but I guess the places I worked didn't have the resources required to have that type of functional separation. The one or two experts in each area had to do it all, since there wasn't anyone else who know each area well enough to produce an effective design.
It's a nice tool for documents of small or medium size, but the document format is a nightmare. Try changing the margins in Word 97, for example, and then reading the result in Word 2000. The margins are all messed up in many cases... :-(
If only they'd kept the document format simple and added a nice "review codes" feature like WordPerfect used to have...
IBM can "manage" software; they just can't MARKET it worth a damn. :-)
Yes, you're quite right.
That isn't why we implemented it at first (it was initially put in place because we had a few offshore contractors imposed on us and we wanted to do sanity checking of their code before we allowed it on the production system we supported), but we found that such code reviews could also be an excellent teaching tool when someone new came on board.
In the Fortran variant I was working in until a few years ago, local variable names were limited to five (5) characters, and many otherwise obvious functions were performed by a series of external subroutines with six-character names usually beginning with SY (for "System").
That meant that the code itself could be quite hard to follow without some sort of logical commentary accompanying it.
I tended to comment my code quite heavily in that context, since I'd already had experience with uncommented code in that context and knew how hard it could be to follow...
(Try reading Fortran that's all in column 7 and which is mainly composed of arithmetic IFs and CALL statements sometime and see how intuitive it is!)
When using more modern languages, I tend to comment less, sometimes a lot less. It usually comes down to a judgement call on my part as to whether or not I think the code would be easy for a newcomer to maintain...
We used to implement code reviews at my former workplace, but they were more "sanity checking" peer reviews than anything else. They didn't take very long, and it gave one or two other people a chance to see how understandable or generally logical the changes were.
That type of thing doesn't work as well for large changes, but we found that for small ones it sometimes can be a useful thing.
They actively mark the start and end of each block of commercial messages at record time, and then can either skip those blocks automagically (with around 80% reliability in my experience) during playback or can quickly skip back and forth between program segment start locations (end-of-commercial block markers) using the arrow keys.
The former turns several minutes of intrusive commercial messages into a fractional-second screen blip and a little icon in the lower righthand corner indicating commercial skip, while the latter has the general effect of breaking a show up into chapters that can be navigated between at will.
A 30-second forward skip button doesn't compare...
An e-mail is on its way... I'd not considered teaching (I like mentoring, but the idea of being in front of an expectant classroom makes me a bit nervous), but it's certainly worth considering...
Thanks!
I'm a former Northwest Airlines applications programmer/analyst with a BSCS and 15 years of pretty solid experience who has been looking for a new permanent place to work for over 2.5 years now, and my local area (the Minneapolis/St. Paul metro) has had a number of large companies lay off a large number of people over the past few years including my former employer (NWA), Unisys (which has a heavy airline/mainframe presence in the Twin Cities), Lawson, IBM, Qwest, Verizon, and a number of others.
:-)
In the case of NWA, many IT people were laid off based on the organization or project they were affiliated with, and whole trees of people were lopped off from the manager on down. I know several folks who I considered top-quality techie types who were let go in October 2001 because they had moved to a project that was more technically interesting or high-profile a few years ago, but which was considered a non-critical project by management in the post-9/11 airline environment).
In other cases (such as in my case), cuts were made based purely on seniority, and my 13 years put me on the bottom of the ladder compared to the remaining folks I was working with in Flight Operations (I survived the major IT cuts in late 2001 only to find myself nickel-and-dimed out a few months later when we all thought it was over).
Given the experience level of my peers I was a logical choice, at least by that measure, but I'll frankly put my general level of technical acumen against anyone here. Or there, for that matter.
Unfortunately, that wasn't the measurement used. Ability rarely factors into such choices, as two layoffs in the past 15 years have taught me, particularly when the layoff parameters are being determined mainly by bean counters rather than technical management.
With such a glut in unemployed techie folks in the local area, many of them quite senior, it's hard for someone with only 10-15 years of experience to get any sort of contract work because there are a fair number of 20-30 year people also laid off who are now competing for a much smaller number of positions. And contract work is almost all there is. A few firms seem to be hiring real permanent employees, but competition is so fierce that one has to be an almost perfect tech-skill+line-of-business match in order to get a first-level interview.
I know several folks who have roughly my experience level who are still out of work after more than a year, and it sure isn't due to a lack of technical ability or a lack of effort. From what I can tell, it's mainly due to a large number of people seeking a small number of positions, and to an increasing tendency for companies to require more and more specialized business and technical skillsets even for general IT positions.
The folks who have "left IT" according to common statistical measures are a mix of all types.
Some fit the stereotype of being "less skilled" or interested only in the financial aspects of an IT career, and I'm in agreement with those who say "good riddance" to such folks, but there are probably at least as many others who are hard-core bit twiddlers or talented designers or whatnot who just happened to be in the wrong place at the wrong time, and who are finding it difficult to obtain employment in IT at a time when companies are hiring specialized short-term contractors in lieu of more generalized long-term employees.
When an IT position isn't available, and when the six months or so of unemployment runs out, a former IT person has to do *something* in order to make ends meet. In my case, it will probably end up driving a truck or doing some sort of generic office work so I can continue to pay the bills.
That doesn't make me any less interested in IT, and I'll still be looking when I'm not working at a lesser position, but for statistical purposes I'll have dropped off the radar and will no longer count as an unemployed IT position. It's a very misleading statistic...
If this comes across as a bi
Add the following two lines to the .inputrc file in your home directory (or create it if it doesn't exist):
y -search-forward
"\M-[A":history-search-backward
"\M-[B":histor
That produces 4DOS-like command history behavior, at least on my box (Mandrake 8.2).
This CD command replacement acts much like the well-known ACD utility used to under DOS -- it allows the user to move to a subdirectory even if only part of that subdirectory name is entered (regardless of its position in the tree), it shows an interactive picklist of options if more than one subdirectory matches the entered string, and it also provides a nice ncurses-bases interactive interface for traversing the directory tree in a visual manner.
Information, source, and binaries for various OSes can be obtained here:
WCD Wherever Change Directory
Yes, z/OS is apparently certified as a UNIX(tm), but its history is certainly not the same as Unix-like OSes, and neither is its feature set.
:-)
Also, mainframes like the Unisys A-series and 2200-series boxes use MCP and OS2200, and those are about as different from a "Unix" as one can get and still be running in text-mode.
Are you talking about things like Sun E10k's and the like (which might fit a loose definition of mainframe)?
I'm mainly just curious.
The typical UTS terminal connected to Unisys 1100 and 2200 mainframes in the 80's and 90's did all text and screen editing (line/character insertions and deletions) locally and could protect, justify, and even selectively enforce input in defined character fields on the screen without communicating with the host box at all.
That's why such terminals are called "block mode" terminals, and why they behave so differently from host-dependent terminals like the VT1xx.
Some of the later UTS terminals also did graphics and I think one could even use a mouse with MAPPER on the mainframe under some configurations.
At least to activate peer-to-peer.
If you've ever wondered what hard drives were like in 1968, this might be the page for you. :-) OK, it was a drum, but it's almost the same as a disk!
I purchased a Palm M105 (B&W screen w/toggleable backlight, 160x160, 8MB, PalmOS 3.5.1 in ROM) from a nice guy on eBay with a new serial cradle, a new Palm folding keyboard, padded case, a trio of spare styluses, and four different colored faceplates for $49.95 + S&H. And that isn't an atypical price.
:-)
Is it the latest and greatest? No, far from it, but it'll work with a standard serial port via Pilot Link (available for OS/2 and Linux and maybe other OSes), it'll keep track of lots of things here at home thanks to the freeware "DB" database (and the various database templates I'm creating), it helps me keep track of the stars at night thanks to a nifty Palm program called Sky Chart, it plays a mean game of both Hearts and Fluxx, and it uses standard AAA batteries so I won't have to worry about its proprietary recharacable battery dying on me. It doesn't have one!
It's not for the type of user that likes all those whistles and bells, but believe me those older Palm models can be useful -- and used ones are CHEAP (as in inexpensive, not as in poorly made ).
Want a bargain? Buy an older PDA. It'll be a lot more useful than many of you might suspect, and if it gets stolen by the neighbor's kid, eaten by your dog, or falls overboard during that fishing trip, and you have a proper backup (not hard to do with the aforementioned software), it only takes a little bit of time and money to get a full replacement.
Unfortunately, a lot of that software doesn't run under Linux, making Linux less useful to me.
Another interesting point, though: many of the programs I prefer to GIMP are shareware programs that were written by individuals or by very small development teams, and those programs don't seem to have some of the UI usability issues that I see in GIMP.
Maybe GIMP needs to fork into specialized versions with smaller development teams? As it is, it's a huge monolithic program which seems very awkward to use compared to some of its competitors...
Thanks for the link, also. However, the article you indicate seems to state that USAir got most of the US$1.5 billion in load guarantees, America West got some, and the rest was scattered among three other airlines (one of them being World, I assume), and it roughly corresponds to my own impressions (i.e., not many).
You must have other information sources? I see nothing at all in that article indicating that WN has received anything, for example, not to mention a few other airlines you listed.
One or two at most. The conditions were too harsh for most to even consider.
not all of the mainframes in current use (or which are currently being marketed) are from IBM, or are even based on IBM's mainframe architecture.
:-)
At least two of the top four airlines in the US are still heavily using Unisys mainframes, for example. Those are based on the Sperry UNIVAC 1100-series boxes of the 1960's and 70's (a 36-bit architecture which is word-addressible, not byte-addressible) and an OS called OS2200 (or OS 2200), and many of them are still running applications software that was originally designed and written during that era (though it is constantly being modified in-house, of course).
As others here have said, mainframes are simply not the old coal-fired boxes that they are sometimes portrayed to be, certainly not on the hardware side of things. What they really are is a centralized server whose design is specialized around very high levels of reliability/recoverability and high levels of data throughput combined with the ability to serve applications to thousands of users with very low levels of system and communications overhead for each user action.
That makes them exceedingly efficient at what they do, not just large and expensive.
Also, while most of them tend to have some "stone age" elements on the applications software side, keep in mind that most of the older software tends to be found at the API level, not in the core of the OSes which support that API.
While application code on those boxes might be very old indeed, or at least based on very old software interfaces, the hardware and software platforms which form the guts of those mainframe boxes have been moving forward over the past few decades just as quickly in many areas as they have been in the desktop and smaller server world.
Part of the reason that such systems still exist is certainly tied to various economic factors like the difficulty of porting applications and such (when one has several million lines of code which is tightly tied to one's business rules, one doesn't rewrite that software arbitrarily).
However, some companies still use mainframes for another reason: they have a few applications which simply cannot fail if the company is to operate effectively. In some cases, even a small outage can cause cascading effects thorughout the company and cost the company millions of dollars. Or more.
My own experience is with major airlines, and they are one of the largest users of such systems in key areas, but financial entities such as NASDAQ have been using similar large systems for years because they need a very high level of reliability and recoverability.
I really think it's a shame that more people are not exposed to these types of systems in college so they can get some sense of what those machines are actually designed for (and what the hardware and software in those boxes is actually capable of).
While Unix, Windows, and Mac systems are ubiquitous these days, they simply do not define all existing computing architectures by themselves, nor can they effectively or efficiently handle all types of computing tasks. Not yet, anyway...