Yeah, that'll go over well. So much for the Transaction Response Time section of our SLAs.
Also, it's not like the underlying platform means anything in terms of the UI when talking about a large-scale transaction-based app. Put a web face on the thing and pretend it's a Mac for all I care; it ain't gonna make the back-end any faster or more reliable.
The BSCS program I went through required three core language classes (including a mandatory mainframe assembler class) during the first two years, hit on various miscellaneous topics from hardware logic to data structures, then allowed us to branch out into more specialized areas (systems, databases, business, etc.).
I think that approach has given me a far greater appreciation for what's going on behind the scenes than I might otherwise have had, and it also gave me some practical experience with writing specs, making hard deadlines, working in teams, etc.
Here, this garden hose has a standard interface -- let's replace the Mississippi River with one so everyone can hook up to it and use the resources! It should be easy!!!:-):-)
Geez... Which part of the phrase "mainframes are already using specialized clusters of modern data channel hardware that kick ass on anything else on the market" don't you understand?
It ain't out of date -- it's just built to a more sophisticated set of specifications than you're used to seeing.
Until the software that runs on those boxes matures to the point where it can actually handle what is required by some of those system, the commodity cost of that hardware means nothing.
Don't get me wrong -- there are lots of existing cases out there where companies are running legacy software on mainframes largely out of inertia, but that isn't the case in the areas I'm talking about.
Hey, I know... The airlines are looking for ways to save money. Maybe this is your chance to show them the way.:-)
The difficulty of doing this in the current climate has been discussed on Slashdot ad Nauseum.
For some, it might be a good solution. For others, it isn't. However, presenting it here as a be-all end-all solution for unemployment is just as ingenuous as saying it wouldn't work at all.
When mainframes were the only available computing solution, they were often used for tasks that can be done by lesser systems today.
Because of this, you have a point -- in some cases. Many legacy mainframe applications exist which could be ported to other smaller platforms and which would still continue to function as intended in that context.
However, it simply isn't true that all of the computing solutions currently running in a mainframe environment could be better handled by smaller boxes or clusters of smaller boxes.
In some cases, perhaps most, they would work, but they would perform the task at hand with far less efficiency than a mainframe would.
In other cases, they would simply be overwhelmed by the requirements of the application.
Put bluntly: I think you are seriously underestimating the data handling requirements of something like an Amadeus or a WorldSpan, and if you consider mainframe OSes to be some form of primitive software, you might want to compare the security models of IBM's z/OS or Unisys' OS2200 to your typical UNIX installation sometime.
Cars are more popular than trains these days for the types of applications that most people are likely to encounter, and there are larger vehicles out there for specialized applications which seem to be much more robust and more sophisticated in their approach to data transport than an automobile.
However, there are still a number of instances where good old freight trains are by far the most efficient and reliable means for transporting physical goods. That's why we still use trains; for some types of tasks, a train does the job a lot more efficiently than a fleet of cars or even trucks.
So it is with mainframes and data.
Please educate yourself. UNIX folks and PeeCee weenies might not like it, but the distributed computing model and the "monster servers" being produced by UNIX vendors like Sun are still not up to the task of handling certain types of computing tasks very efficiently.
I respect the UNIX approach -- I wouldn't be so interested in playing with BSD/Linux/Solaris myself otherwise -- but it simply does not come close to representing the pinnacle of computing.
Mainframes don't either, in my mind, but I think they come a lot closer in a number of areas.
Some types of business problems lend themselves very well to decentralization, while others don't do quite so well and are best kept in some type of centralized environment.
It's a context-sensitive problem, as most computing problems are.:-)
Sometimes processing and/or data has to be kept strictly in synch, and there are situations where whole sets of related files and databases must be locked down quickly and concurrently to meet federal requirements for data integrity (that's what an airline has to do when a flight incident occurs, for example, to ensure that the original environment is available to investigators).
Sometimes it's simply better to be able to admin a single highly-reliable system rather than manage an entire server farm. That's why IBM is selling Z boxes as virtual Linux server farms, for example.
I agree that new grads can certainly pick up on mainframe concepts but most of them, myself included, don't really want to.
I think it's a shame that so many folks seem to have this attitude, since most of the "mainframe" environments in use today are actually quite modern, and their hardware and software environments employ concepts that I suspect most UNIX and PC people would find very interesting (if only because those concepts tend to make a lot of sense but seem to be largely lacking in smaller systems).
A mainframe is a large, redundant, recoverable server capable of running critical applications and handling a very large volume of data, not a coal-fired box made of cast iron and running some batch COBOL run designed in the 60's.
If you think all those airlines and banks still use mainframes just because they're old, I'm afraid I've got some bad news for you.:-)
Based on my recent 32-month unemployment stint after 15 years of designing/supporting a variety of airline applications, it seems that one's experience isn't seen as valuable unless it's also experience with the same set of specific tools and business areas that a given company is working with.
General industry experience isn't valuable enough to obtain even an introductory interview, and one mainframe platform doesn't translate to another in an employers eyes even if the languages and core concepts are fairly similar.
Thankfully, I've been able to continue to work on that platform (and its descendants) over the years.
Once the airline industry recovers, there's probably be openings for folks with 1100 experience again...
There are positive/negative side to *all* OSes.
on
Windows 95 Turns 10
·
· Score: 1
I've been using Macs since 1993, Linux since 1992, OS/2 since 1992, and Windows since 1988, as well as a plethora of other OSes with GUIs and without, and I've seen good and bad things in all of them.
The fact that some of us have actually had a very positive experience with OS/2 over the years (hey, it's hasn't been my main-but-not-exclusive desktop OS at home for 13+ years because it doesn't work) is not a reflection at all on your experience -- it simply means I was a lot luckier, perhaps, or did better research when buying my PC hardware, or maybe I just appreciated things like HPFS, MVDM, and the WPS a lot more than you did.
Different strokes and all that.
The fact that I've been a voluntary hobbyist user of OS/2 and not in a forced corporate support role might have a lot to do with our respective attitudes, too.:-)
For what it's worth, I question your objectivity, and I think your mapping your tokenring-centric corporate experience to all possible users (and then insulting those who disagree) is a bit on the childish side. IMO, of course.
...you were already late for the party, since 1992 was the introduction of the 32-bit version and the time when heavy user movement from Windows to OS/2 actually occurred. That was the point in history when its price was a key factor.
FWIW, the full price for OS/2 Warp 3 was US$129 in the fall of 1994, and Warp 3 with WinOS2 in the spring of 1995 was US$199 if you didn't already have a copy of Windows 3.1 somewhere.
Warp Connect (the client with NIC support that was released in late 1995) was US$229/299 for the red spine and blue spine versions (without and with WinOS2 respectively), but that was intended for business users. Most home users only need dial-up TCP/IP support (SLIP or PPP) at that point in time...
It actually works well as an old-time gaming OS on PPro/Voodoo2/AWE64 hardware, and it's a fun platform to run things like Tribes 1, UT, AOEII, Homeworld, NFS3/4, or Total Annihilation on. Cheap gaming LAN!
You UNIX youngsters crack me up. ;-)
on
Windows 95 Turns 10
·
· Score: 2, Funny
The OS I still write code on for a living (OS2200) was first born as EXEC 8 on the UNIVAC 1108 and was first announced in 1966.
Windows 95 OSR2.1 and OSR2.5 both included support for USB well before Windows 98's release.
But they didn't deliver; they provided a stop-gap.
on
Windows 95 Turns 10
·
· Score: 5, Informative
Windows 95 still had a crappy FAT filesystem (even though Microsoft had developed HPFS years before) and it was still a pile of 32-bit DLLs (or VxDs) running on top of DOS instead of a compartmentalized 32-bit OS with a classic kernel/shell design.
Microsoft's older version of OS/2 was a 16-bit solution that wasn't all that competitive, but at least it had a real filesystem and an architecture that made a little bit of sense to someone with a comp sci background.
Besides, by the time Windows 95 was released, OS/2 had been an IBM product for over three years (OS/2 2.0, 2.1, and Warp 3.0 had already been released), and it had been almost completely rewritten by IBM during that time (new 32-bit kernel, new WPS desktop, new VDM subsystem, new WinOS2 subsystem, and new network stack).
NT was around then, as you say, and it had a good native 32-bit core, but it still used the Windows 3.1 desktop and had such poor support for DOS apps that many people couldn't use it effectively (at least for a few more years).
It had a slick Motif(tm)-based GUI, pinnable menus, user-selectable levels of complexity (with 1 being beginner and 4 being expert), scalable and rotatable fonts, preemptive multitasking, and two threads per process, and it could run in CGA (or Hercules!) mode on an XP-class box (pre-80286).
We saw some fairly nice areas in both Smyrna and Mableton, and since I work near the Cumberland Mall, they both seemed like a logical place to look for a house.
In the end, Mableton won.:-)
I'm just south of the EW Connector on Cooper Lake Road. Not in the big new fancy houses, though.
...the combination of more technically experienced users and less stupidly-designed mail and web clients would make those systems womewhat harder targets, I think.
Slashdot Mirror
Yeah, that'll go over well. So much for the Transaction Response Time section of our SLAs.
Also, it's not like the underlying platform means anything in terms of the UI when talking about a large-scale transaction-based app. Put a web face on the thing and pretend it's a Mac for all I care; it ain't gonna make the back-end any faster or more reliable.
Because they aren't trendy?
:-)
Highly-specialized skills seem to be somewhat less desireable in the current IT climate than common, widely used skills.
Also, consider the flip side to your question: If it's so crappy, then why is Windows so gosh darned popular?
I suspect part of it is because you aren't all that familiar with the actual capabilities of mainframes.
:-)
Maybe spending some time talking to mainframers would help.
The BSCS program I went through required three core language classes (including a mandatory mainframe assembler class) during the first two years, hit on various miscellaneous topics from hardware logic to data structures, then allowed us to branch out into more specialized areas (systems, databases, business, etc.).
I think that approach has given me a far greater appreciation for what's going on behind the scenes than I might otherwise have had, and it also gave me some practical experience with writing specs, making hard deadlines, working in teams, etc.
I thought it was an excellent program.
...that POSIX-compliant C code will run on my OS/2 box and the Unisys Clearpath IX mainframe I play with for a living at work.
;-)
Those systems would be pretty unfamiliar to you otherwise. Especially the latter, at least if all you knew was UNIX.
Here, this garden hose has a standard interface -- let's replace the Mississippi River with one so everyone can hook up to it and use the resources! It should be easy!!! :-) :-)
Geez... Which part of the phrase "mainframes are already using specialized clusters of modern data channel hardware that kick ass on anything else on the market" don't you understand?
It ain't out of date -- it's just built to a more sophisticated set of specifications than you're used to seeing.
Until the software that runs on those boxes matures to the point where it can actually handle what is required by some of those system, the commodity cost of that hardware means nothing.
:-)
Don't get me wrong -- there are lots of existing cases out there where companies are running legacy software on mainframes largely out of inertia, but that isn't the case in the areas I'm talking about.
Hey, I know... The airlines are looking for ways to save money. Maybe this is your chance to show them the way.
The difficulty of doing this in the current climate has been discussed on Slashdot ad Nauseum.
For some, it might be a good solution. For others, it isn't. However, presenting it here as a be-all end-all solution for unemployment is just as ingenuous as saying it wouldn't work at all.
GMAFB, okay...?
When mainframes were the only available computing solution, they were often used for tasks that can be done by lesser systems today.
Because of this, you have a point -- in some cases. Many legacy mainframe applications exist which could be ported to other smaller platforms and which would still continue to function as intended in that context.
However, it simply isn't true that all of the computing solutions currently running in a mainframe environment could be better handled by smaller boxes or clusters of smaller boxes.
In some cases, perhaps most, they would work, but they would perform the task at hand with far less efficiency than a mainframe would.
In other cases, they would simply be overwhelmed by the requirements of the application.
Put bluntly: I think you are seriously underestimating the data handling requirements of something like an Amadeus or a WorldSpan, and if you consider mainframe OSes to be some form of primitive software, you might want to compare the security models of IBM's z/OS or Unisys' OS2200 to your typical UNIX installation sometime.
Cars are more popular than trains these days for the types of applications that most people are likely to encounter, and there are larger vehicles out there for specialized applications which seem to be much more robust and more sophisticated in their approach to data transport than an automobile.
However, there are still a number of instances where good old freight trains are by far the most efficient and reliable means for transporting physical goods. That's why we still use trains; for some types of tasks, a train does the job a lot more efficiently than a fleet of cars or even trucks.
So it is with mainframes and data.
Please educate yourself. UNIX folks and PeeCee weenies might not like it, but the distributed computing model and the "monster servers" being produced by UNIX vendors like Sun are still not up to the task of handling certain types of computing tasks very efficiently.
I respect the UNIX approach -- I wouldn't be so interested in playing with BSD/Linux/Solaris myself otherwise -- but it simply does not come close to representing the pinnacle of computing.
Mainframes don't either, in my mind, but I think they come a lot closer in a number of areas.
Some types of business problems lend themselves very well to decentralization, while others don't do quite so well and are best kept in some type of centralized environment.
:-)
It's a context-sensitive problem, as most computing problems are.
Sometimes processing and/or data has to be kept strictly in synch, and there are situations where whole sets of related files and databases must be locked down quickly and concurrently to meet federal requirements for data integrity (that's what an airline has to do when a flight incident occurs, for example, to ensure that the original environment is available to investigators).
Sometimes it's simply better to be able to admin a single highly-reliable system rather than manage an entire server farm. That's why IBM is selling Z boxes as virtual Linux server farms, for example.
I agree that new grads can certainly pick up on mainframe concepts but most of them, myself included, don't really want to.
:-)
I think it's a shame that so many folks seem to have this attitude, since most of the "mainframe" environments in use today are actually quite modern, and their hardware and software environments employ concepts that I suspect most UNIX and PC people would find very interesting (if only because those concepts tend to make a lot of sense but seem to be largely lacking in smaller systems).
A mainframe is a large, redundant, recoverable server capable of running critical applications and handling a very large volume of data, not a coal-fired box made of cast iron and running some batch COBOL run designed in the 60's.
If you think all those airlines and banks still use mainframes just because they're old, I'm afraid I've got some bad news for you.
Based on my recent 32-month unemployment stint after 15 years of designing/supporting a variety of airline applications, it seems that one's experience isn't seen as valuable unless it's also experience with the same set of specific tools and business areas that a given company is working with.
General industry experience isn't valuable enough to obtain even an introductory interview, and one mainframe platform doesn't translate to another in an employers eyes even if the languages and core concepts are fairly similar.
There were a few exceptions, but not very many.
Thankfully, I've been able to continue to work on that platform (and its descendants) over the years.
Once the airline industry recovers, there's probably be openings for folks with 1100 experience again...
I've been using Macs since 1993, Linux since 1992, OS/2 since 1992, and Windows since 1988, as well as a plethora of other OSes with GUIs and without, and I've seen good and bad things in all of them.
:-)
The fact that some of us have actually had a very positive experience with OS/2 over the years (hey, it's hasn't been my main-but-not-exclusive desktop OS at home for 13+ years because it doesn't work) is not a reflection at all on your experience -- it simply means I was a lot luckier, perhaps, or did better research when buying my PC hardware, or maybe I just appreciated things like HPFS, MVDM, and the WPS a lot more than you did.
Different strokes and all that.
The fact that I've been a voluntary hobbyist user of OS/2 and not in a forced corporate support role might have a lot to do with our respective attitudes, too.
For what it's worth, I question your objectivity, and I think your mapping your tokenring-centric corporate experience to all possible users (and then insulting those who disagree) is a bit on the childish side. IMO, of course.
...you were already late for the party, since 1992 was the introduction of the 32-bit version and the time when heavy user movement from Windows to OS/2 actually occurred. That was the point in history when its price was a key factor.
FWIW, the full price for OS/2 Warp 3 was US$129 in the fall of 1994, and Warp 3 with WinOS2 in the spring of 1995 was US$199 if you didn't already have a copy of Windows 3.1 somewhere.
Warp Connect (the client with NIC support that was released in late 1995) was US$229/299 for the red spine and blue spine versions (without and with WinOS2 respectively), but that was intended for business users. Most home users only need dial-up TCP/IP support (SLIP or PPP) at that point in time...
Why? Because I can. :-)
It actually works well as an old-time gaming OS on PPro/Voodoo2/AWE64 hardware, and it's a fun platform to run things like Tribes 1, UT, AOEII, Homeworld, NFS3/4, or Total Annihilation on. Cheap gaming LAN!
The OS I still write code on for a living (OS2200) was first born as EXEC 8 on the UNIVAC 1108 and was first announced in 1966.
:-)
It ain't pretty, but at least it's old!
I still remember some guy selling tapes for Colorado JUMBO drives that had SLS on them so folks didn't have to download all the ZIP files.
Those were the days...
For those of us who were using OS/2 or the Mac years before, the Windows 95 desktop was a disappointment.
...an upgrade for DOS users was US$99, and an upgrade for Windows users was US$49.
It wasn't always expensive -- only for latecomers, and one of the reasons so many hobbyists jumped at the OS/2 platform in 1992/1993 was the low cost.
The price for OS/2 rose later on, but by then the war for the desktop was effectively over.
Windows 95 OSR2.1 and OSR2.5 both included support for USB well before Windows 98's release.
Windows 95 still had a crappy FAT filesystem (even though Microsoft had developed HPFS years before) and it was still a pile of 32-bit DLLs (or VxDs) running on top of DOS instead of a compartmentalized 32-bit OS with a classic kernel/shell design.
Microsoft's older version of OS/2 was a 16-bit solution that wasn't all that competitive, but at least it had a real filesystem and an architecture that made a little bit of sense to someone with a comp sci background.
Besides, by the time Windows 95 was released, OS/2 had been an IBM product for over three years (OS/2 2.0, 2.1, and Warp 3.0 had already been released), and it had been almost completely rewritten by IBM during that time (new 32-bit kernel, new WPS desktop, new VDM subsystem, new WinOS2 subsystem, and new network stack).
NT was around then, as you say, and it had a good native 32-bit core, but it still used the Windows 3.1 desktop and had such poor support for DOS apps that many people couldn't use it effectively (at least for a few more years).
It had a slick Motif(tm)-based GUI, pinnable menus, user-selectable levels of complexity (with 1 being beginner and 4 being expert), scalable and rotatable fonts, preemptive multitasking, and two threads per process, and it could run in CGA (or Hercules!) mode on an XP-class box (pre-80286).
We saw some fairly nice areas in both Smyrna and Mableton, and since I work near the Cumberland Mall, they both seemed like a logical place to look for a house.
:-)
In the end, Mableton won.
I'm just south of the EW Connector on Cooper Lake Road. Not in the big new fancy houses, though.
...the combination of more technically experienced users and less stupidly-designed mail and web clients would make those systems womewhat harder targets, I think.