In some cases, I guess, but the software and firmware I'm talking about is usually also protected by much stronger measures like copyright, specific development/support contract or similar legal language, by federal law in the case of avionics and certain types of airline ground systems, and sometimes also by physical security measures (you can't run ACARS software on something that ain't an ACARS box from the same manufacturer, for example, so the specialized nature of the box itself provides a certain element of security and outsider inaccessibility).
I'm not talking about simple applications, either, although the airline I worked for had hundreds of specialized applications for everything from crew scheduling to aircraft parts inventory to flight planning to yield management. We also had specialized comm software (some of it written in house, some of it written by external vendors specifically for our network, some standard products like Tuxedo or MQ that are proprietary products in their own right. Much of the hardware was specialized for the airline industry and driver by specialized firmware written in=house or by third parties to our specifications, etc.
Think about one airline doing that sort of thing with 1000 of their own people (and supporting a few dozen external vendors on the side) for 40 years. Now multiply that by 50 or so. That gives you the software and firmware in just one industry -- the airline industry.
How much software do you think that is?
How much specialized functionality?
Now... How much of the above do you think you're EVER going to see exposed in a public forum?
There are dozens of such industries, each with a huge array of specialized hardware and software systems developed under wraps for their own specific purposes, protected by copyright and contract, and probably hidden away from the public eye forever.
Billions upon billions of lines of sophisticated, time-tested, and reliable code. All prior art in one sense or another, and all unavailable.
The current FOSS development community is a little blip on the radar in comparison.
IBM Z-boxes and Unisys Clearpath boxes are to high=end Sun boxes as High=end Sun boxes are to UNIX workstations and high-end PCs.
There's a very large performance gap between all three of those groups of computing hardware.
I would also put SuperComputers in a fourth unrelated group.
The difference isn't just software. Believe me. And most Big Iron isn't "old" -- it has been going through the same types of advancements that single-user desktop machines have been, but their focus in advancement has been on wider and faster I/O channels, on clustering, and on hardware and software redundancy and integrated failover/recovery rather than 3D video graphics and faster CPU MIPS values.
Architecturally, the focus is different, mainly focusing on I/O bandwidth, redundant components that can be swapped on the fly, and very high levels of reliability. Also, the software tends to be very different (and far more sophisticated) in the way it handles things like logical machine partitioning, multi-machine clusters, and so on.
Entry-level Unisys Clearpath Dorado boxes weigh 650 pounds and are the size of a small fridge, which is a lot smaller than their older slower cousins used to be (a Unisys 1100/80 mainframe was a water-cooled box that used to take up a considerably large amount of computer floor, and that didn't include peripheral cabinets).
The airline industry still heavily uses mainframes for what are called "real-time transaction systems", mainly things like reservations systems and the like which require a locked-down highly centralized database with excellent performance and recovery features and the ability to handle hundreds or thousands of concurrent connections with very low latency.
The little mainframe application I play with isn't very impressive in terms of the number of transactions it handles (perhaps 5-7 transactions per second right now at peak, with each of them performing a dozen or so I/O's in the process and parsing/validating a simple text screen), but what is somewhat impressive is the fact that it does so while averaging just under.030 seconds (30 milliseconds) of actual response time per transaction, and it does so while only taking up a fraction of one percent of the smaller Unisys Clearpath server on which it runs.
Most of the box is used by a completely different (and much larger) airline application, and it tends to handled 250 trans/second or so coming from a few thousand concurrent users with similar response time. Parse an incoming screen, do several I/O's, build a response screen, and send it to a terminal... all in less than a tenth of a second.
I can't even get that sort of response time out of MS Word 2000 on my XP box sometimes.:-)
DEC VAXen were minicomputers, not mainframes, although large VAX clutsters had decent capabilities for their time. Not quite the same scale as OS/390 or OS1100 boxes, though.
Re:Some want to see the demise of the mainframe?
on
The Mainframe Still Lives!
·
· Score: 2, Informative
Think again. I used to work on a large flight operations mainframe application that powers one of the largest US airlines (actually two, I think, if UAL is still running UNIMATIC), and while some of the code sucked, most of it was easy to maintain, and the application was (and is) both efficient and well-liked by the folks who use it.
The main issue with management wanting to leave the mainframe environment centers around licensing fees, not software quality, maintainability, or performance.
Re:Not to mention things non-mainframes don't atte
on
The Mainframe Still Lives!
·
· Score: 2, Informative
It's not just IBM either. For instance there's Amdahl (now wholly owned by Fujitsu).
And don't forget that Unisys still maintains and sells descendants of both the old Sperry UNIVAC 1100-series mainframe line and the Burroughs MCP-based A-series mainframe boxes (both are part of their Clearpath mainframe line). Both are quite dissimilar from IBM's in terms of architecture and software, but each is quite similar to IBM's big iron in terms of basic capablities.
Re:Some want to see the demise of the mainframe?
on
The Mainframe Still Lives!
·
· Score: 3, Informative
Because they're a burden to maintain, but have developed "traction" because they've invaded every part of a business.
The main reason companies have decided to move off mainframes has more to do with extravagant licensing fees than anything else. Well-written mainframe software (even old Fortran or COBOL stuff) is no harder to maintain than newer stuff, and it's often much less susceptable to things like memory overflows and the like.
I don't do mainframe stuff (and hope I never will), but the little I've heard is ugly. Ancient COBOL (yick) code written 40 years ago running on a dinosaur OS.
That's one problem with hearsay -- it can sometimes be accurate, but sometimes wildly offbase.:-)
Almost all of our mainframe stuff is Fortran with some MASM and other languages thrown in, but we're not using IBM mainframe, either (our older stuff is all running on Unisys big iron).
I've played on mainframes professionally now for 18 years (19 years in August!), and I love the history of the platform as well as the relatively bulletproof application environment I get to work in. If only we had some of the same tools on Solaris!
Too much software development over the past 40+ years has occurred behind closed doors, either literally or figuratively behind an NDA or employment contract, and that removes a very large portion of existing software from public consideration (most employers/agencies would not allow their intellectual property to be exposed in any way on a public site).
Because of this, I believe it is impossible for all prior art to be located or described in a publicly-accessible manner, and I suspect most prior art is actually hidden from public view in a large subset of software application areas.
People themselves and the decisions they make are the biggest obstacle they have to overcome.
Tell that to the corporate layoff machine. I know a LOT more people who've been severely hurt by that than I do people who hurt themselves by making stupid financial decisions...
Of course, coming from the IT segment in the airline industry, I've probably known more folks who've been laid off than most. Most of us are working now, but it took a while. 2002 was not a good year to be out of work...
Yeah, that was my approach for a while. Charge in at high speed at a slight angle, dueling all the way, then spin quickly at the end to attempt a cheap in-close laser shot at the victim's back shield in passing.:-)
Eventually I encountered a group of folks who were consistently better than I was, and I started trying out different strategies with actual movement patterns, and I finally figured out how to do a zig-zag rush at people, which is what I think the infamous Coiled Snake did. I also got relatively good at estimating shots on the fly, but against some people it didn't seem to help. Most folks were fairly poor at shooting, though, so I still ended up dying more slowly than my opponents more often than not and building up a semi-decent kill count.
I also admit I took cheap kills when I could, watching battles taking place far away and backstabbing the loser just before his rightful victor got in the deathblow. I feel so guilty!:-):-)
I remember MU,COMBAT,USMK001 (the first one I played, I think), and MU,CCOMBAT,USMK031 which is still around on a tape I think. I also remember a COMBAT variant where the missles went "CLANG" instead of BLAM and that was more tailored for 110 baud terminals, but I don't remember the name (and it wasn't around very long).
I don't remember anymore if those should be comma-separated or not...:-(
I knew a John back in the MTS days. Argiledhel in Rochester. I also remember folks like Coiled Snake on COMBAT taking me out far too many times to recall. Bastage.:-)
One of my former employers (Northwest Airlines) went the Mac route in many departments because PC networking sucked rocks in the early 1990's.
They've almost completely converted over to Windows now (with a few islands like the SSOC still using Macs and Solaris workstations), but at the time the Mac was light years ahead of the PC.
I think you're right, though -- DOS PCs running Novell were very common during the late 1980's. That's what we used at my first place of employment (Unisys).
I'm not sure I agree. Apple had a huge penetration into suburban schools in the US -- we had literally dozens of them in my high school during the years I was there (fall 1978 - spring 1981), and we actively used them in coursework, so a lot of graduating students came out of school knowing about Apples and what they could do.
The fact that you could queue movements, builds, attacks, and various other things by simply using the shift key was a huge plus in TA. I wish more RTS game makers would implement that sort of consistent UI in their games.
How many times does some manager who has never coded an app think that an entire company should move to Java or.NET and replace all legacy programs only to be shot down when someone explains that it would cost millions of dollars to replace all of the stuff that's working just fine right now?
We're doing a feasibility study now to see if we can replace some F77 message processing code with Java. It might work, but the old mainframe code can currently receive a message, perform a dozen I/O's, validate it, reformat it, and still get the reformatted response out in around 60 milliseconds on average (from start to finish), and that includes the time spent on the OS2200 system input and output queues.
Getting that sort of low latency using a traditional UNIX+Java+RDMS setup will be challenging.
Can you imagine being the GM/DM and putting hex city maps or scrolling terrain/encounter maps on such a table display? Have the players put their characters' figures on the table, and you're good to go.
You're not alone. The F77 code I play with now is newer (maybe 12 years old at the oldest), but some of the F66 code I played with at a previous job dated from the mid-1960's and is still running in production.
Slashdot Mirror
In some cases, I guess, but the software and firmware I'm talking about is usually also protected by much stronger measures like copyright, specific development/support contract or similar legal language, by federal law in the case of avionics and certain types of airline ground systems, and sometimes also by physical security measures (you can't run ACARS software on something that ain't an ACARS box from the same manufacturer, for example, so the specialized nature of the box itself provides a certain element of security and outsider inaccessibility).
I'm not talking about simple applications, either, although the airline I worked for had hundreds of specialized applications for everything from crew scheduling to aircraft parts inventory to flight planning to yield management. We also had specialized comm software (some of it written in house, some of it written by external vendors specifically for our network, some standard products like Tuxedo or MQ that are proprietary products in their own right. Much of the hardware was specialized for the airline industry and driver by specialized firmware written in=house or by third parties to our specifications, etc.
Think about one airline doing that sort of thing with 1000 of their own people (and supporting a few dozen external vendors on the side) for 40 years. Now multiply that by 50 or so. That gives you the software and firmware in just one industry -- the airline industry.
How much software do you think that is?
How much specialized functionality?
Now... How much of the above do you think you're EVER going to see exposed in a public forum?
There are dozens of such industries, each with a huge array of specialized hardware and software systems developed under wraps for their own specific purposes, protected by copyright and contract, and probably hidden away from the public eye forever.
Billions upon billions of lines of sophisticated, time-tested, and reliable code. All prior art in one sense or another, and all unavailable.
The current FOSS development community is a little blip on the radar in comparison.
IBM Z-boxes and Unisys Clearpath boxes are to high=end Sun boxes as High=end Sun boxes are to UNIX workstations and high-end PCs.
There's a very large performance gap between all three of those groups of computing hardware.
I would also put SuperComputers in a fourth unrelated group.
The difference isn't just software. Believe me. And most Big Iron isn't "old" -- it has been going through the same types of advancements that single-user desktop machines have been, but their focus in advancement has been on wider and faster I/O channels, on clustering, and on hardware and software redundancy and integrated failover/recovery rather than 3D video graphics and faster CPU MIPS values.
Architecturally, the focus is different, mainly focusing on I/O bandwidth, redundant components that can be swapped on the fly, and very high levels of reliability. Also, the software tends to be very different (and far more sophisticated) in the way it handles things like logical machine partitioning, multi-machine clusters, and so on.
Entry-level Unisys Clearpath Dorado boxes weigh 650 pounds and are the size of a small fridge, which is a lot smaller than their older slower cousins used to be (a Unisys 1100/80 mainframe was a water-cooled box that used to take up a considerably large amount of computer floor, and that didn't include peripheral cabinets).
The airline industry still heavily uses mainframes for what are called "real-time transaction systems", mainly things like reservations systems and the like which require a locked-down highly centralized database with excellent performance and recovery features and the ability to handle hundreds or thousands of concurrent connections with very low latency.
The little mainframe application I play with isn't very impressive in terms of the number of transactions it handles (perhaps 5-7 transactions per second right now at peak, with each of them performing a dozen or so I/O's in the process and parsing/validating a simple text screen), but what is somewhat impressive is the fact that it does so while averaging just under .030 seconds (30 milliseconds) of actual response time per transaction, and it does so while only taking up a fraction of one percent of the smaller Unisys Clearpath server on which it runs.
Most of the box is used by a completely different (and much larger) airline application, and it tends to handled 250 trans/second or so coming from a few thousand concurrent users with similar response time. Parse an incoming screen, do several I/O's, build a response screen, and send it to a terminal ... all in less than a tenth of a second.
I can't even get that sort of response time out of MS Word 2000 on my XP box sometimes. :-)
DEC VAXen were minicomputers, not mainframes, although large VAX clutsters had decent capabilities for their time. Not quite the same scale as OS/390 or OS1100 boxes, though.
Think again. I used to work on a large flight operations mainframe application that powers one of the largest US airlines (actually two, I think, if UAL is still running UNIMATIC), and while some of the code sucked, most of it was easy to maintain, and the application was (and is) both efficient and well-liked by the folks who use it.
The main issue with management wanting to leave the mainframe environment centers around licensing fees, not software quality, maintainability, or performance.
And don't forget that Unisys still maintains and sells descendants of both the old Sperry UNIVAC 1100-series mainframe line and the Burroughs MCP-based A-series mainframe boxes (both are part of their Clearpath mainframe line). Both are quite dissimilar from IBM's in terms of architecture and software, but each is quite similar to IBM's big iron in terms of basic capablities.
The main reason companies have decided to move off mainframes has more to do with extravagant licensing fees than anything else. Well-written mainframe software (even old Fortran or COBOL stuff) is no harder to maintain than newer stuff, and it's often much less susceptable to things like memory overflows and the like.
That's one problem with hearsay -- it can sometimes be accurate, but sometimes wildly offbase. :-)
Almost all of our mainframe stuff is Fortran with some MASM and other languages thrown in, but we're not using IBM mainframe, either (our older stuff is all running on Unisys big iron).
I've played on mainframes professionally now for 18 years (19 years in August!), and I love the history of the platform as well as the relatively bulletproof application environment I get to work in. If only we had some of the same tools on Solaris!
Too much software development over the past 40+ years has occurred behind closed doors, either literally or figuratively behind an NDA or employment contract, and that removes a very large portion of existing software from public consideration (most employers/agencies would not allow their intellectual property to be exposed in any way on a public site).
Because of this, I believe it is impossible for all prior art to be located or described in a publicly-accessible manner, and I suspect most prior art is actually hidden from public view in a large subset of software application areas.
Tell that to the corporate layoff machine. I know a LOT more people who've been severely hurt by that than I do people who hurt themselves by making stupid financial decisions...
Of course, coming from the IT segment in the airline industry, I've probably known more folks who've been laid off than most. Most of us are working now, but it took a while. 2002 was not a good year to be out of work...
Er... My Abacus is most certainly programmable. :-)
Looks like Windows 2.1 to me given the screen shots. That'd make it between 1988 and 1990. :-)
Yeah, that was my approach for a while. Charge in at high speed at a slight angle, dueling all the way, then spin quickly at the end to attempt a cheap in-close laser shot at the victim's back shield in passing. :-)
:-) :-)
Eventually I encountered a group of folks who were consistently better than I was, and I started trying out different strategies with actual movement patterns, and I finally figured out how to do a zig-zag rush at people, which is what I think the infamous Coiled Snake did. I also got relatively good at estimating shots on the fly, but against some people it didn't seem to help. Most folks were fairly poor at shooting, though, so I still ended up dying more slowly than my opponents more often than not and building up a semi-decent kill count.
I also admit I took cheap kills when I could, watching battles taking place far away and backstabbing the loser just before his rightful victor got in the deathblow. I feel so guilty!
I remember MU,COMBAT,USMK001 (the first one I played, I think), and MU,CCOMBAT,USMK031 which is still around on a tape I think. I also remember a COMBAT variant where the missles went "CLANG" instead of BLAM and that was more tailored for 110 baud terminals, but I don't remember the name (and it wasn't around very long).
Waiting... Waiting... Check that watch... Now!
:-(
:-)
L2000,M2,M2
Whew!
I don't remember anymore if those should be comma-separated or not...
I knew a John back in the MTS days. Argiledhel in Rochester. I also remember folks like Coiled Snake on COMBAT taking me out far too many times to recall. Bastage.
*GILDOR*/UN=H7LT263
MMT - Multi Mouse Talk? I also remember MTC and later XTALK, and DDT let you roll dice in the various channels.
:-)
Those programs were rather addictive.
*GILDOR*/UN=H7LT263
One of my former employers (Northwest Airlines) went the Mac route in many departments because PC networking sucked rocks in the early 1990's.
They've almost completely converted over to Windows now (with a few islands like the SSOC still using Macs and Solaris workstations), but at the time the Mac was light years ahead of the PC.
I think you're right, though -- DOS PCs running Novell were very common during the late 1980's. That's what we used at my first place of employment (Unisys).
I'm not sure I agree. Apple had a huge penetration into suburban schools in the US -- we had literally dozens of them in my high school during the years I was there (fall 1978 - spring 1981), and we actively used them in coursework, so a lot of graduating students came out of school knowing about Apples and what they could do.
Darn right. 3D0G, baby! :-)
Obviously not. Most of the folks I know who own firearms fall into the following categories:
:-)
(1) They use a gun to hunt. That's why my Dad and brother each have a 30-06 rifle, for example.
(2) They have a gun in the home for self-protection. Many of the folks I know personally who fall into this category are ex-military.
(3) They live in a rural area and have one or more guns simply because they can.
The fact that you could queue movements, builds, attacks, and various other things by simply using the shift key was a huge plus in TA. I wish more RTS game makers would implement that sort of consistent UI in their games.
We're doing a feasibility study now to see if we can replace some F77 message processing code with Java. It might work, but the old mainframe code can currently receive a message, perform a dozen I/O's, validate it, reformat it, and still get the reformatted response out in around 60 milliseconds on average (from start to finish), and that includes the time spent on the OS2200 system input and output queues.
Getting that sort of low latency using a traditional UNIX+Java+RDMS setup will be challenging.
Can you imagine being the GM/DM and putting hex city maps or scrolling terrain/encounter maps on such a table display? Have the players put their characters' figures on the table, and you're good to go.
:-)
I'd LOVE to have something like this as a GM.
They are if you wanna work for an airline. :-)
Of course, finding one that will hire anyone at all might be more challenging these days...
You're not alone. The F77 code I play with now is newer (maybe 12 years old at the oldest), but some of the F66 code I played with at a previous job dated from the mid-1960's and is still running in production.
:-)
We have a lot of Fortran *and* C code here.