Your IFL gets faster when you do a frame upgrade. For example, if you bought an IFL in early 2001 it'd be about 200 MIPS. When you did your late 2005 frame upgrade to a System z9 EC it's more like 600 (three times faster), and you didn't pay a dime for the speed bump (except the frame charge). When the next frame comes, the same thing happens. Over and over.
Of course that's not including the other stuff you get. Actually you could have purchased a 31-bit IFL, and the upgrade to 64-bit would have been free with your frame charge. Likewise, any instruction set improvements are free, and that's already happened even within the 64-bit processors (e.g. for crypto -- the EC has AES embedded in the processor hardware, and yes Linux uses it).
That's correct, and you make a very good point. Moreover, the execution integrity applies to any operating system running on the IBM machine, including Linux. That's a very important distinction, by the way. This functionality is pushed way down into the hardware layers. Linux just goes along for the ride -- a very cushy, comfortable, secure ride.
Every 2066 model (including the -002) has a minimum of 8 GB main memory. It is impossible to get one with less. Maximum is 32 GB. It was 2002's mid-range model for perspective. Quite a nice little system, but it's dated.
For reference, the likely replacement model would be a System z9 BC. However, if a lot of additional capacity (e.g. Linux) is desired, it would be economical to leap up to the System z9 EC because you can buy fractional z/OS capacities on that model now (i.e. something that would be a good match for the 350 MIPS they have rather than jumping up to ~600 MIPS for a full CPU). The BC also has a minimum 8 GB memory but can expand up to 64 GB. The EC is 16 GB minimum and 512 GB maximum (per frame).
Most mainframe shops use a 4 year lifecycle in their budget analysis, but many do upgrades much more quickly than that. The big shops often upgrade as soon as something new is available: the economics are overwhelmingly in favor of doing so for such large installations.
These can be in place upgrades, by the way. You don't junk the whole system unlike, say, Dells.
Also, if you're looking at prices, please don't unless you understand what you're looking at. The price for a new mainframe is much different than the price for a capacity neutral upgrade (same number of MIPS) of an existing mainframe. MUCH different. In simple terms, when you buy a mainframe you pay a one-time processor capacity charge. So if you buy 350 MIPS you've got 350 MIPS. When it comes time to upgrade you pay a frame charge, but you don't pay again for the 350 MIPS. The same goes for Linux processors: buy a System z9 BC Linux processor at $95,000 and you own it forever and never pay it again. You only pay the frame charge when you're ready for an upgrade.
So where are the savings? How much lower are their z800 operating costs? (Hint: not much.) So they took some workload off the z800, moved it to somewhere else, spent quite a bit of money doing it, and...what happened to their total IT budget?
I agree, I'd be very interested to know what it would cost to do the whole project on a 2007 System z9, i.e. a new mainframe that's a lot cheaper to operate and which can run both Linux (much faster than a z800) and whatever is still running on the z800. And aside from all that, what's the service quality? It the Dell grid more or less reliable and available? How secure is it? What does the cost profile look like when it comes time to replace it? (Mainframes tend to have more residual value, while Dells get junked.) What are the software licensing impacts? (Mainframe Linux is extremely cheap in this regard.) Lots and lots of questions unanswered, and a lot of really bad economics. Why are some IT people so bad at economics anyway?
The latest and greatest mainframe is the System z9 EC, with a single main CPU rating (Model 2094-701) of ~600 zMIPS. It was introduced in 2005 (as the System z9-109) and renamed (with some non-processor enhancements) in 2006.
IBM mainframes hit 450 MIPS per CPU back in 2003, I believe (z990). Time marches on.
The replacement for the z800 rates about 480 zMIPS per CPU. It's the z9 BC. Between the z800 and the z9 BC was the z890, actually. I agree with the comments upthread that it's pretty silly to compare 2007 (or even 2006) hardware with circa 2002 hardware (and midrange hardware at that). And cost comparisons are wacky anyway: the company still has the old mainframe and is still paying to run it. What would the costs be to consolidate everything onto one shiny new mainframe? (Hint: new mainframes are substantially cheaper to operate than old mainframes, for a variety of reasons.) That question isn't apparently answered, perhaps because the answer would be embarrassing to the team that just spent a lot of money.
I'm always fascinated by the programming language debates here at Slashdot. They don't make any sense to me.
English is a terrible, confusing mess of a spoken language (and not so great written). Some of the Asian languages are written language monstrosities. Modern Japanese has four alphabets (including romanji)! Esperanto allegedly fixes all that. So we'll all be speaking and writing Esperanto any day now, right? No.
COBOL thrives because it gets its job done, and it has an enormous (and growing -- 2 billion net new lines each year) installed value. That's not going to change any time soon although, just like English, COBOL will evolve.
Speaking of evolution, there's an awful lot of dated knowledge about COBOL in this long discussion. It's hard to know where to begin to address that. Looking just at the relatively recent IBM stuff, modern COBOL (called "Enterprise COBOL" in IBM parlance) is now object oriented (if you want or need), has language syntax to parse and generate XML, and has well specified cross-language calling conventions in every direction you can imagine (COBOL to Java, Java to COBOL, C to COBOL, COBOL to C, etc.) The environmentals and tooling keep getting more and more interesting, and that's probably a lot more important than the language itself. Something called WebSphere Developer for System z puts all COBOL development onto a graphical Eclipse framework. (Want to set a breakpoint? Drag a stop sign. Can't remember what verb comes next? Use Code Assist. Want to map copybooks to/from XML? Drag and drop.) No more TSO/ISPF/PF12 stuff (unless you want). The IBM Debug Tool U&AF has great code coverage measurements as you test. Application Performance Analyzer lets you peer into all your code to tweak it and optimize it extremely rigorously. Fault Analyzer zeros in on exactly where an abend occurred and helps you figure out what was going on in order to quickly fix the problem. The source code libraries/change management tools (SCLM, Endevor, Panvalet, ChangeMan, etc.) are first rate for team development and, at least in the case of SCLM and Endevor, plug into WebSphere Developer for z so you can do check-ins/check-outs from your PC. The testing tools (IBM's or Compuware's) are also first rate and keep getting better. You can even do many wild things most other languages can't, like instantiate COBOL as EJBs running inside WebSphere Application Server for z/OS alongside Java EJBs, interoperating transparently and as full peers. Re: Linux (including mainframe Linux), AccuCOBOL, a commercial compiler, seems to be getting reasonably popular. For code analysis and understanding IBM's WebSphere Studio Asset Analyzer, Asset Transformation Workbench, and CICS Interdependency Analyzer are all quite helpful, and I don't think I've seen that level of sophistication in comparable tools for other programming languages. It's probably also worth mentioning Language Environment, which puts COBOL on the same common runtime foundation as every other programming language for tracing, debugging, abend analysis, etc. LE started about 20 years ago, but it has evolved and matured quite nicely and keeps getting better.
I would like to see a 64-bit z/OS COBOL compiler. IBM hasn't pulled the trigger yet, out of an abundance of caution I think. (COBOL requirements tend to get driven by "we're going to need it in X years" rather than "wouldn't it be cool to have?" And I think we're only just getting into the time when direct support for 64-bit data structures looks like it might be moving into the "need soon" category.) C, C++, Assembler (obviously), and Java have all already made the leap on z/OS, so my suspicion is that COBOL is next. Note that 64-bit v. 31-bit -- yes, 31-bit -- isn't really the same issue as on other machines. You can mix 64-bit and 31-bit code freely on z/OS, including cross calling conventions. The only issue is whether a single address space running a COBOL program can itself contain a 64-bit data object of some kind. Right now that's 1.8 GB of data objects, or thereabouts.
You made the assertion that Dehomag was the only available supplier to the Nazis of tabulating equipment. It's just not true.
IBM indeed did have a substantially greater marketshare than Remington Rand. But I mentioned the 1910 U.S. Census specifically concerning your point. Remington Rand's equipment handled the largest tabulating problems of the day. The Nazis simply chose the most popular equipment. It was a bit like Betamax v. VHS back then, actually.
The Swiss appeals court decided according to a very low standard: whether the case should be tossed out of court or not. The case survived, but now the plaintiffs have to prove their case. Their case depends on a theory that's even more convoluted than the previous case. The plaintiffs' attorneys allege that IBM Geneva aided Dehomag during World War II and that IBM's New York headquarters had a relationship, with knowledge of Dehomag's actions and alleged IBM Geneva support, during the same time. Two degrees of separation to prove, in other words. (The alleged IBM Geneva connection is apparently to help the case maintain standing in a Swiss court.) The case has already been tossed out once by the lower court. On the surface, at least, this case does not appear strong.
Whether the tabulating equipment was more or less important than, say, Nazi-seized Ford factories is rather beside the point. IBM (and Remington Rand) manufactured tabulating equipment during peacetime, tabulating equipment which made the world a much better place in many countries. (Remember, IBM tabulating equipment found many uses helping the Allies beat the Nazis, including all sorts of military-related accounting.) Some evil people then went on to use the seized equipment/subsidiary to aid their "Final Solution." Of course that's awful, but I don't see how that fact alone leads to any sort of culpability, any more than it would for any other legal product (including guns, fire trucks, vacuum tubes, titanium, diamonds, phosphorous, radio transmitters, aircraft and aircraft parts, etc.) sold in Germany pre-War.
But, again, as with the paperclips, the Nazis could have sourced cars from other companies. They couldn't have sources tabulators (or the skills required to run) them from anyone else.
That's just not historically accurate. Remington Rand manufactured and sold punched card tabulating equipment in direct competition with IBM prior to (and after) World War II. (James Powers beat Hollerith to win most of the 1910 U.S. Census business, and the Powers Accounting Machine Corporation became part of Remington Rand in 1927.) Remington Rand equipment was available to the Nazis over the same period. The British Tabulating Machine Company's products were also available at the time. While it is true that BTM paid IBM royalties for patent rights, Remington Rand did not since they used a 45/90-column round hole card format instead of IBM's 80-column rectangular hole format. Remington Rand's format actually held more data per card and, although it's pure speculation, it's possible Remington Rand's format would have helped the Nazis more efficiently pursue their atrocities.
Germany also lead the world in computing technology before the war and well into it and thus had plenty of domestic capability (on top of Dehomag and any German Remington Rand and BTM assets). Konrad Zuse finished the Z1 by 1938, in particular. Fortunately the Nazis were slow to understand what they had in Zuse's work.
It's also worth nothing that the lawyers who filed against IBM in U.S. court, alleging that IBM had responsibility for Dehomag's assistance to the Nazis during World War II, dropped their own lawsuit two months after filing it. There is another lawsuit still pending in Swiss courts, filed by lawyers representing five gypsies. IBM says the case is without merit.
Would you believe 32 CPUs can indeed do the work of thousands of processors?
First of all, a single System z9 mainframe has up to 54 main processors, not 32. And you can buy more than one of them. There's no rule that says you can't. If you want 108, buy two mainframes, and two costs much less than 2X one.
Those 54 main processors actually have a couple hundred or so secondary processors in support for I/O, cryptography, network, service assist, spares, etc. The 54 number is pretty deceptive, actually -- there's a lot of other silicon executing instructions, too.
And now here's the interesting bit: those 54 processors typically run 90+ percent busy 24x7x365. And about all they do is real work (business logic), not stupid stuff like loading bytes from a disk or pushing bytes onto a network. And it's a super-CISC design -- there are some monster instructions on those processors which aren't just adding two numbers together.
Another interesting fact is that all your applications and data are co-resident. You don't have to take network hops from your application to your database cluster. This means incredible efficiency, so those 54 mains get an awful lot of work done with your typical applications.
Then there's cache. Gobs and gobs of it. It hits a LOT on mainframes, and it's available to all 54 processors. Does no good to one distributed processor if the instruction is over on another processor's cache. Mainframe processors rarely ever wait -- the philosophy is to keep them well fed at all times.
So, yeah, absolutely, those relatively few processors tear through a bunch of work and are real world competitive with the work that thousands of distributed processors can do with a typical, real world mix of business applications. If you're doing weather modeling or digital film rendering, no, but that's not what most businesses do.
As with hundreds of foreign-owned companies that did business in Germany at that time, Dehomag came under the control of Nazi authorities prior to and during World War II.
The same is true of, say, Ford. Did Ford also have a role in the Holocaust because its (seized by the Nazis) German subsidiary produced vehicles which probably transported SS officers to/from death camps? I'd say not, but perhaps you have another opinion.
Well, for z/VSE it is. But that's the fun part, that there are at least five operating systems available for IBM mainframes, and if you want one where TCP/IP is optional you can get one that way. The whole reason it's optional is that you can choose from among at least two different TCP/IP stacks for z/VSE. Choice is good.
There can be real wierdness though as to schedule a Java program....
Not really. On Linux it's the same as any other Linux -- cron or whatever. On z/OS it's the same as z/OS, particularly when you use JZOS. On WebSphere Application Server it's the same as WebSphere Application Server. What would be really weird is if scheduling was different than scheduling anything else in your chosen runtime environment.
Of course scheduling on z/OS is different than scheduling on, say, Microsoft Windows. For one thing it actually works.:-) But I wouldn't call it weird.
There is no license charge for Java on IBM mainframes, regardless of the operating system. It's included with your z/OS or z/OS.e license, and it's a free download for Linux.
It's even better than that, actually. Since one does pay for z/OS that might ordinarily be an issue, but Java on IBM z/OS has its own accelerator called zAAP. The zAAPs are dedicated Java processors, and there is no software license charge for any zAAP processors. Roughly speaking it brings the actual, full cost of running Java rather close to optimized COBOL. Cheap, in other words.
Now guess what happens on the weekend early in the morning...
That is entirely your company's decision. There is absolutely no technical reason why a weekly -- or any -- reboot is required, especially one triggering any sort of service interruption. Somebody decided about 30 years ago to implement that operational policy, and no one in your operations center has ever bothered to update the procedure manual. It's probably that simple.
I met with a construction equipment manufacturer that did the same thing. Somebody in another department asked, "Why are we doing this? We need the Web site to be up all the time. Mainframe is down every week. Maybe we should move this to a PC...." And the operations people replied, in about 2 seconds, "No problem. You now have continuous service." They just stopped rebooting each weekend. Now they never do.
Indeed there are some application designs that require an outage because of a coding decision somebody made, usually long ago. These are called "batch windows" on mainframes, when a particular application or part of a system is "down" (unavailable to a user) because a batch process is updating some of that application's files. But again, there's nothing requiring perpetuation of that sort of application design. Everything supports fully continuous online access...and has for at least 20 years. Even the "classic" environments like IMS (with online reorg and HALDB) support 24x7 online.
Chargebacks are entirely your company's doing, not IBM's. The mainframe has excellent facilities (SMF, in particular) for keeping track of everything that occurs on the system. Other systems don't, at least not with standard configurations. Thus it's very common for stupid companies -- I use the word stupid correctly -- to lump every IT cost you can possibly think of into their mainframe chargebacks simply because SMF exists as a convenient vehicle.
High priced analysts keep pointing out the absurdity of how companies levy chargebacks. I think Meta Group estimated that mainframe chargebacks are about triple what they really should be, on average. (In your case you could be way above the average. Test work, particularly at a low service class, shouldn't really get charged much at all.)
One interesting side effect for companies that can't come up with rational chargebacks (or get rid of them entirely if they have other, better cost accounting) is that the worst of them tend to sign outsourcing contracts. Eventually CEO-types say, "Enough" with an IT organization that has no clue what its own true costs are, and she/he outsources the whole rancid bunch.
By the way, I'm frankly puzzled by the reputation of mainframes as only being able to run old technology. The only thing that distinguishes a mainframe (in terms of modern code compatibility) from any other server is that the old code doesn't break, by design. If you've got a piece of 40 year old code (literally) that you still like, that's still useful, you can still run it. But you can run it alongside 64-bit Java or Linux code that you wrote 5 minutes ago. And the old code and new code can interact in lots of different ways, all with careful protections of course so that everything runs smoothly. Mainframes are as old or as new as you want them to be -- it's entirely, completely your operational choice. If something is old, no longer useful, and your company is still running it, no problem -- get something new. The mainframe will run it.
IBM does. Anyone with so much as a Perl script to test (from what I can tell) qualifies as a "developer" to get a free 30-day mainframe Linux system with root access all to yourself. That's right, you get one complete Linux instance (SuSE or Red Hat) running on a real mainframe under real z/VM. Have fun.
If you're a Linux programmer (or Java programmer, for that matter) you're already a mainframe programmer.
I'm really offended by all this IBM boosterism at Slashdot. Didn't you all hear Steve Ballmer say that IBM doesn't innovate? He's right, you know. And this carbon nanotube business is yet more evidence. IBM's work is hardly original. Carbon has been around forever. Steve Ballmer himself is made of carbon and other elements.
Now let's talk about REAL innovation. Microsoft just announced a new facial feature pack for Office's "Clippy." Now you can customize Clippy according to your facial preferences. Options include complexion, hair style, nose shape and size, and ear/nose jewelry.
Mainframes = Both Java and LAMP, Together
on
Java Is So 90s
·
· Score: 1
Excellent point. Another point to ponder is that mainframes run Java really well and LAMP stacks (plural) really well, all on a single piece of equipment together, at the same time. That's quite unlike the.NET programming model, where your platform is forced on you (leaving the Mono project aside). What if Windows isn't fit to purpose? With both Java and LAMP you get choice.
Who the hell is going to pirate Neil Diamond tunes? Is there rampant copyright violation involving Neil Diamond's music? Are thousands of new U.S. citizens trading illegal MP3s of Diamond's anthem "Coming to America"? Does Neil Diamond's demographic even know how to rip a CD? Did I just miss the Tower Records "midnight madness" sale of the new Neil Diamond CD? Is Neil Diamond really the most pirated name in the music industry?
Slashdot Mirror
Your IFL gets faster when you do a frame upgrade. For example, if you bought an IFL in early 2001 it'd be about 200 MIPS. When you did your late 2005 frame upgrade to a System z9 EC it's more like 600 (three times faster), and you didn't pay a dime for the speed bump (except the frame charge). When the next frame comes, the same thing happens. Over and over.
Of course that's not including the other stuff you get. Actually you could have purchased a 31-bit IFL, and the upgrade to 64-bit would have been free with your frame charge. Likewise, any instruction set improvements are free, and that's already happened even within the 64-bit processors (e.g. for crypto -- the EC has AES embedded in the processor hardware, and yes Linux uses it).
Make sense now?
That's correct, and you make a very good point. Moreover, the execution integrity applies to any operating system running on the IBM machine, including Linux. That's a very important distinction, by the way. This functionality is pushed way down into the hardware layers. Linux just goes along for the ride -- a very cushy, comfortable, secure ride.
Every 2066 model (including the -002) has a minimum of 8 GB main memory. It is impossible to get one with less. Maximum is 32 GB. It was 2002's mid-range model for perspective. Quite a nice little system, but it's dated.
For reference, the likely replacement model would be a System z9 BC. However, if a lot of additional capacity (e.g. Linux) is desired, it would be economical to leap up to the System z9 EC because you can buy fractional z/OS capacities on that model now (i.e. something that would be a good match for the 350 MIPS they have rather than jumping up to ~600 MIPS for a full CPU). The BC also has a minimum 8 GB memory but can expand up to 64 GB. The EC is 16 GB minimum and 512 GB maximum (per frame).
Most mainframe shops use a 4 year lifecycle in their budget analysis, but many do upgrades much more quickly than that. The big shops often upgrade as soon as something new is available: the economics are overwhelmingly in favor of doing so for such large installations.
These can be in place upgrades, by the way. You don't junk the whole system unlike, say, Dells.
Also, if you're looking at prices, please don't unless you understand what you're looking at. The price for a new mainframe is much different than the price for a capacity neutral upgrade (same number of MIPS) of an existing mainframe. MUCH different. In simple terms, when you buy a mainframe you pay a one-time processor capacity charge. So if you buy 350 MIPS you've got 350 MIPS. When it comes time to upgrade you pay a frame charge, but you don't pay again for the 350 MIPS. The same goes for Linux processors: buy a System z9 BC Linux processor at $95,000 and you own it forever and never pay it again. You only pay the frame charge when you're ready for an upgrade.
So where are the savings? How much lower are their z800 operating costs? (Hint: not much.) So they took some workload off the z800, moved it to somewhere else, spent quite a bit of money doing it, and...what happened to their total IT budget?
I agree, I'd be very interested to know what it would cost to do the whole project on a 2007 System z9, i.e. a new mainframe that's a lot cheaper to operate and which can run both Linux (much faster than a z800) and whatever is still running on the z800. And aside from all that, what's the service quality? It the Dell grid more or less reliable and available? How secure is it? What does the cost profile look like when it comes time to replace it? (Mainframes tend to have more residual value, while Dells get junked.) What are the software licensing impacts? (Mainframe Linux is extremely cheap in this regard.) Lots and lots of questions unanswered, and a lot of really bad economics. Why are some IT people so bad at economics anyway?
The latest and greatest mainframe is the System z9 EC, with a single main CPU rating (Model 2094-701) of ~600 zMIPS. It was introduced in 2005 (as the System z9-109) and renamed (with some non-processor enhancements) in 2006.
IBM mainframes hit 450 MIPS per CPU back in 2003, I believe (z990). Time marches on.
The replacement for the z800 rates about 480 zMIPS per CPU. It's the z9 BC. Between the z800 and the z9 BC was the z890, actually. I agree with the comments upthread that it's pretty silly to compare 2007 (or even 2006) hardware with circa 2002 hardware (and midrange hardware at that). And cost comparisons are wacky anyway: the company still has the old mainframe and is still paying to run it. What would the costs be to consolidate everything onto one shiny new mainframe? (Hint: new mainframes are substantially cheaper to operate than old mainframes, for a variety of reasons.) That question isn't apparently answered, perhaps because the answer would be embarrassing to the team that just spent a lot of money.
I'm always fascinated by the programming language debates here at Slashdot. They don't make any sense to me.
English is a terrible, confusing mess of a spoken language (and not so great written). Some of the Asian languages are written language monstrosities. Modern Japanese has four alphabets (including romanji)! Esperanto allegedly fixes all that. So we'll all be speaking and writing Esperanto any day now, right? No.
COBOL thrives because it gets its job done, and it has an enormous (and growing -- 2 billion net new lines each year) installed value. That's not going to change any time soon although, just like English, COBOL will evolve.
Speaking of evolution, there's an awful lot of dated knowledge about COBOL in this long discussion. It's hard to know where to begin to address that. Looking just at the relatively recent IBM stuff, modern COBOL (called "Enterprise COBOL" in IBM parlance) is now object oriented (if you want or need), has language syntax to parse and generate XML, and has well specified cross-language calling conventions in every direction you can imagine (COBOL to Java, Java to COBOL, C to COBOL, COBOL to C, etc.) The environmentals and tooling keep getting more and more interesting, and that's probably a lot more important than the language itself. Something called WebSphere Developer for System z puts all COBOL development onto a graphical Eclipse framework. (Want to set a breakpoint? Drag a stop sign. Can't remember what verb comes next? Use Code Assist. Want to map copybooks to/from XML? Drag and drop.) No more TSO/ISPF/PF12 stuff (unless you want). The IBM Debug Tool U&AF has great code coverage measurements as you test. Application Performance Analyzer lets you peer into all your code to tweak it and optimize it extremely rigorously. Fault Analyzer zeros in on exactly where an abend occurred and helps you figure out what was going on in order to quickly fix the problem. The source code libraries/change management tools (SCLM, Endevor, Panvalet, ChangeMan, etc.) are first rate for team development and, at least in the case of SCLM and Endevor, plug into WebSphere Developer for z so you can do check-ins/check-outs from your PC. The testing tools (IBM's or Compuware's) are also first rate and keep getting better. You can even do many wild things most other languages can't, like instantiate COBOL as EJBs running inside WebSphere Application Server for z/OS alongside Java EJBs, interoperating transparently and as full peers. Re: Linux (including mainframe Linux), AccuCOBOL, a commercial compiler, seems to be getting reasonably popular. For code analysis and understanding IBM's WebSphere Studio Asset Analyzer, Asset Transformation Workbench, and CICS Interdependency Analyzer are all quite helpful, and I don't think I've seen that level of sophistication in comparable tools for other programming languages. It's probably also worth mentioning Language Environment, which puts COBOL on the same common runtime foundation as every other programming language for tracing, debugging, abend analysis, etc. LE started about 20 years ago, but it has evolved and matured quite nicely and keeps getting better.
I would like to see a 64-bit z/OS COBOL compiler. IBM hasn't pulled the trigger yet, out of an abundance of caution I think. (COBOL requirements tend to get driven by "we're going to need it in X years" rather than "wouldn't it be cool to have?" And I think we're only just getting into the time when direct support for 64-bit data structures looks like it might be moving into the "need soon" category.) C, C++, Assembler (obviously), and Java have all already made the leap on z/OS, so my suspicion is that COBOL is next. Note that 64-bit v. 31-bit -- yes, 31-bit -- isn't really the same issue as on other machines. You can mix 64-bit and 31-bit code freely on z/OS, including cross calling conventions. The only issue is whether a single address space running a COBOL program can itself contain a 64-bit data object of some kind. Right now that's 1.8 GB of data objects, or thereabouts.
IBM indeed did have a substantially greater marketshare than Remington Rand. But I mentioned the 1910 U.S. Census specifically concerning your point. Remington Rand's equipment handled the largest tabulating problems of the day. The Nazis simply chose the most popular equipment. It was a bit like Betamax v. VHS back then, actually.
The Swiss appeals court decided according to a very low standard: whether the case should be tossed out of court or not. The case survived, but now the plaintiffs have to prove their case. Their case depends on a theory that's even more convoluted than the previous case. The plaintiffs' attorneys allege that IBM Geneva aided Dehomag during World War II and that IBM's New York headquarters had a relationship, with knowledge of Dehomag's actions and alleged IBM Geneva support, during the same time. Two degrees of separation to prove, in other words. (The alleged IBM Geneva connection is apparently to help the case maintain standing in a Swiss court.) The case has already been tossed out once by the lower court. On the surface, at least, this case does not appear strong.
Whether the tabulating equipment was more or less important than, say, Nazi-seized Ford factories is rather beside the point. IBM (and Remington Rand) manufactured tabulating equipment during peacetime, tabulating equipment which made the world a much better place in many countries. (Remember, IBM tabulating equipment found many uses helping the Allies beat the Nazis, including all sorts of military-related accounting.) Some evil people then went on to use the seized equipment/subsidiary to aid their "Final Solution." Of course that's awful, but I don't see how that fact alone leads to any sort of culpability, any more than it would for any other legal product (including guns, fire trucks, vacuum tubes, titanium, diamonds, phosphorous, radio transmitters, aircraft and aircraft parts, etc.) sold in Germany pre-War.
That's just not historically accurate. Remington Rand manufactured and sold punched card tabulating equipment in direct competition with IBM prior to (and after) World War II. (James Powers beat Hollerith to win most of the 1910 U.S. Census business, and the Powers Accounting Machine Corporation became part of Remington Rand in 1927.) Remington Rand equipment was available to the Nazis over the same period. The British Tabulating Machine Company's products were also available at the time. While it is true that BTM paid IBM royalties for patent rights, Remington Rand did not since they used a 45/90-column round hole card format instead of IBM's 80-column rectangular hole format. Remington Rand's format actually held more data per card and, although it's pure speculation, it's possible Remington Rand's format would have helped the Nazis more efficiently pursue their atrocities.
Germany also lead the world in computing technology before the war and well into it and thus had plenty of domestic capability (on top of Dehomag and any German Remington Rand and BTM assets). Konrad Zuse finished the Z1 by 1938, in particular. Fortunately the Nazis were slow to understand what they had in Zuse's work.
It's also worth nothing that the lawyers who filed against IBM in U.S. court, alleging that IBM had responsibility for Dehomag's assistance to the Nazis during World War II, dropped their own lawsuit two months after filing it. There is another lawsuit still pending in Swiss courts, filed by lawyers representing five gypsies. IBM says the case is without merit.
First of all, a single System z9 mainframe has up to 54 main processors, not 32. And you can buy more than one of them. There's no rule that says you can't. If you want 108, buy two mainframes, and two costs much less than 2X one.
Those 54 main processors actually have a couple hundred or so secondary processors in support for I/O, cryptography, network, service assist, spares, etc. The 54 number is pretty deceptive, actually -- there's a lot of other silicon executing instructions, too.
And now here's the interesting bit: those 54 processors typically run 90+ percent busy 24x7x365. And about all they do is real work (business logic), not stupid stuff like loading bytes from a disk or pushing bytes onto a network. And it's a super-CISC design -- there are some monster instructions on those processors which aren't just adding two numbers together.
Another interesting fact is that all your applications and data are co-resident. You don't have to take network hops from your application to your database cluster. This means incredible efficiency, so those 54 mains get an awful lot of work done with your typical applications.
Then there's cache. Gobs and gobs of it. It hits a LOT on mainframes, and it's available to all 54 processors. Does no good to one distributed processor if the instruction is over on another processor's cache. Mainframe processors rarely ever wait -- the philosophy is to keep them well fed at all times.
So, yeah, absolutely, those relatively few processors tear through a bunch of work and are real world competitive with the work that thousands of distributed processors can do with a typical, real world mix of business applications. If you're doing weather modeling or digital film rendering, no, but that's not what most businesses do.
Ever priced support costs for anything else? Mainframes are cheap. Really cheap. And you actually get real support.
As with hundreds of foreign-owned companies that did business in Germany at that time, Dehomag came under the control of Nazi authorities prior to and during World War II.
The same is true of, say, Ford. Did Ford also have a role in the Holocaust because its (seized by the Nazis) German subsidiary produced vehicles which probably transported SS officers to/from death camps? I'd say not, but perhaps you have another opinion.
Well, for z/VSE it is. But that's the fun part, that there are at least five operating systems available for IBM mainframes, and if you want one where TCP/IP is optional you can get one that way. The whole reason it's optional is that you can choose from among at least two different TCP/IP stacks for z/VSE. Choice is good.
Not really. On Linux it's the same as any other Linux -- cron or whatever. On z/OS it's the same as z/OS, particularly when you use JZOS. On WebSphere Application Server it's the same as WebSphere Application Server. What would be really weird is if scheduling was different than scheduling anything else in your chosen runtime environment.
Of course scheduling on z/OS is different than scheduling on, say, Microsoft Windows. For one thing it actually works. :-) But I wouldn't call it weird.
It's even better than that, actually. Since one does pay for z/OS that might ordinarily be an issue, but Java on IBM z/OS has its own accelerator called zAAP. The zAAPs are dedicated Java processors, and there is no software license charge for any zAAP processors. Roughly speaking it brings the actual, full cost of running Java rather close to optimized COBOL. Cheap, in other words.
That is entirely your company's decision. There is absolutely no technical reason why a weekly -- or any -- reboot is required, especially one triggering any sort of service interruption. Somebody decided about 30 years ago to implement that operational policy, and no one in your operations center has ever bothered to update the procedure manual. It's probably that simple.
I met with a construction equipment manufacturer that did the same thing. Somebody in another department asked, "Why are we doing this? We need the Web site to be up all the time. Mainframe is down every week. Maybe we should move this to a PC...." And the operations people replied, in about 2 seconds, "No problem. You now have continuous service." They just stopped rebooting each weekend. Now they never do.
Indeed there are some application designs that require an outage because of a coding decision somebody made, usually long ago. These are called "batch windows" on mainframes, when a particular application or part of a system is "down" (unavailable to a user) because a batch process is updating some of that application's files. But again, there's nothing requiring perpetuation of that sort of application design. Everything supports fully continuous online access...and has for at least 20 years. Even the "classic" environments like IMS (with online reorg and HALDB) support 24x7 online.
High priced analysts keep pointing out the absurdity of how companies levy chargebacks. I think Meta Group estimated that mainframe chargebacks are about triple what they really should be, on average. (In your case you could be way above the average. Test work, particularly at a low service class, shouldn't really get charged much at all.)
One interesting side effect for companies that can't come up with rational chargebacks (or get rid of them entirely if they have other, better cost accounting) is that the worst of them tend to sign outsourcing contracts. Eventually CEO-types say, "Enough" with an IT organization that has no clue what its own true costs are, and she/he outsources the whole rancid bunch.
By the way, I'm frankly puzzled by the reputation of mainframes as only being able to run old technology. The only thing that distinguishes a mainframe (in terms of modern code compatibility) from any other server is that the old code doesn't break, by design. If you've got a piece of 40 year old code (literally) that you still like, that's still useful, you can still run it. But you can run it alongside 64-bit Java or Linux code that you wrote 5 minutes ago. And the old code and new code can interact in lots of different ways, all with careful protections of course so that everything runs smoothly. Mainframes are as old or as new as you want them to be -- it's entirely, completely your operational choice. If something is old, no longer useful, and your company is still running it, no problem -- get something new. The mainframe will run it.
How about licensing z/OS? Thousands do. Or you can run Linux on the P390.
If you're a Linux programmer (or Java programmer, for that matter) you're already a mainframe programmer.
Now let's talk about REAL innovation. Microsoft just announced a new facial feature pack for Office's "Clippy." Now you can customize Clippy according to your facial preferences. Options include complexion, hair style, nose shape and size, and ear/nose jewelry.
Excellent point. Another point to ponder is that mainframes run Java really well and LAMP stacks (plural) really well, all on a single piece of equipment together, at the same time. That's quite unlike the .NET programming model, where your platform is forced on you (leaving the Mono project aside). What if Windows isn't fit to purpose? With both Java and LAMP you get choice.
25? How about one server, and with several more applications tossed in for good measure? Yup, runs Linux reeeaaaalllly well. :)
I wonder how PETA feels about this factory. Methinks the intersection between biodiesel consumers and PETA members is nonzero.
Who the hell is going to pirate Neil Diamond tunes? Is there rampant copyright violation involving Neil Diamond's music? Are thousands of new U.S. citizens trading illegal MP3s of Diamond's anthem "Coming to America"? Does Neil Diamond's demographic even know how to rip a CD? Did I just miss the Tower Records "midnight madness" sale of the new Neil Diamond CD? Is Neil Diamond really the most pirated name in the music industry?
...voided?