There is a big difference. France lost militarily to the Viet Minh at Dien Bien Phu. The U.S. did not lose militarily to the Viet Minh. In fact, by 1971 the Viet Minh (or Viet Cong if you prefer, it was the same thing, different name) were essentially destroyed as an effective force of any sort above the level of basic terrorism. The North Vietnamese Army, descended from the Viet Minh as well, had pretty well lost every stand up battle it fought with the U.S. Army up til then as well, except perhaps the Ia Drang, which was pretty much a draw.
The U.S. won the military side of the war and lost it politically. In fact it had been lost politically long before the military issue was decided one way or another.
None of this is to take away from the NVA or the Viet Minh, both extremely capable light infantry and had some excellent leaders including Ho Chi Minh and Giap, among others.
Well, except for France - they haven't successfully beaten off an invasion force in the last thousand years...
While I really don't like the French government, this just isn't true. French military history since WWI is pretty sorry, including the defeat by the Germans in 1940, defeat by Viet Minh guerilla forces in the 1950's and defeat in Algeria in the early 60's. But go back just a bit. From about 1650 to 1870, roughly, France was the pre-eminent land power in Europe, and by extension the world given that Europe completed dominated the rest of the world during those years. France managed to dominate the entire European continent essentially single handedly from 1800 to 1815 under Napoleon. And really the loss in WWII was not due to the fighting spirit of the soldiers or industrial capacity of the country. It was mostly due to poor strategy and tactics and an unwillingness by the politicians and the generals to face reality.
Are there reliable/meaningful ways to compare throughput on these machines?
Well, one basis for comparison, a fairly reasonable one, is the SPEC benchmarks. Since IBM went to their Power4 CPU's for the Z series boxes you could compare SPEC benchmarks. However, as far as I know IBM has not submitted SPEC benchmarks on the Z series boxes. Another valid comparison is TPC benchmarks. TPC-C uses a standardized OLTP system that probably would be a valid comparison.
I think the thing to understand is that mainframes are, these days, just another server when talking about CPU power, transactional capabilities and so forth. The one place where they really shine is reliability and availability. It really is true that you get what you pay for. There is a reason why mainframes are expensive. They are engineered for a degree of reliability not found in less expensive systems. However, for most shops the difference between 4 9's of uptime, which is quite achievable by a Sun or HP cluster, and 5 9's of uptime is only about 45 minutes, on an annual basis. Is it really worth the cost of a mainframe sysplex instead of a Sun cluster to achieve the extra 45 minutes? Probably not.
It's also annoying that a CICS application that served 10000 terminals with sub-second response times is denigrated by people whose web-based app takes 10 seconds or more to do a simple update and return output to the user.
Well, here you are really comparing apples to oranges. CICS applications served up across an SNA network to dumb terminals is not really comparable to web applications (you don't specify what platform, but let's assume Java) across a TCP/IP network to modern PC's. Simply comparing CPU power and network throughput won't do the trick. Admittedly a "simple" update and output return should perform as well as a CICS application to dumb terminals. But only IF the system was designed properly, from end to end for performance. For example, we recently implemented an image management system on a sun cluster. We have 500 users hitting the system, retrieving about 150 insurance claims images per minute. We are able to achieve a response time of about.75 seconds with it. We designed it for response time because we lose money when our claims examiners sit and wait for the image. The user accesses a java based web app, images are housed on Hitachi storage, and the application and DB2 database are housed on a cluster based on SunFire 6800's. Uptime requirements are 99.9%. So high performance and reasonable reliability can be done on midrange boxes. It's a matter of design.
The real question is, do you have the right system for the job?
Okay, re-read what I said. You are obviously even more of a mainframe zealot than I am. I didn't say a word about specifically for transactional throughput. I said horsepower. That is a very generic term and most people would interpret that as meaning more CPU power in a general way. Which is quite true. Unless you are suggesting that a single Z990, fully populated with 4 MCM's, somehow has more CPU power than a Sun E15K with 18 system boards? If so, how do they do it? Is there some miraculous CPU technology in the ESA architecture that allows each CPU to be equivalent to 2.5 or so RISC CPU's? If so IBM Z series should be wiping everything else off the face of the planet.
If you want to make a claim that a mainframe's transactional throughput is so much superior to a high end RISC/UNIX box, how about backing it up with some stats? This really isn't true either, but it sounds good to make wild claims based on a "I have worked with em all" statement. The reason that we, and other mainframe shops, are not migrating off mainframes is because they are absolutely stable and reliable. A well designed sysplex achieves 5 9's of uptime annually without breaking a sweat. The best of the Sun/HP/IBM/Compaq/SGI boxes need quite a bit of TLC to go from 4 9's to 5.
And then when you point out to them that the world outside of Microsoft land has been doing this for years they get very defensive. It's like there's a serious inferiority complex going on.
I'd be curious if you had kept a list of all the different reasons your Windows servers failed.
Yes, we do keep such statistics. The most common problems are, in no particular order:
System Administrator error
Viruses, worms, malicious software, etc.
Hardware failure
Operating System (or integrated MS application, like web browsers) failure
Comparatively, the single most common cause of UNIX system downtime for us is developer/DBA error. Hardware failure rarely takes a system down so it can't function, I think we have had one outage in the past 5 years on a UNIX box (we have about 50) due to sys admin error and we have not had a system outage due to Operating System problems.
When you start comparing, and note the issues with the OS and viruses/worms/etc. it is an eye opener. It certainly was to our operations team, who was pushing to move more applications to Microsoft environments.
But this is the standard that we have to adhere to because we provide claims payment, treatment authorization and such for insurance beneficiaries. Our SLA's with our customer only allow us 30 minutes of downtime for the entire system per week. That includes the mainframe sysplex, the point of sale system, the web access for doctors and pharmacies, the interactive voice systems and all of the claims entry points.
It's not about my data center kicking your data center's ass. This is the sort of hardware and software reliability that big data centers have to have. And this whole thread started from the idea that running COBOL within.NET was somehow innovative. The big iron shops (Sun, HP, IBM) have had COBOL migration or rehosting programs for years. I pointed out that the guy who thought this was innovative probably run a couple of windows PC's and a server. While that is necessary in the grand scheme of things, it isn't a really likely place to learn about big, mission critical IT. I used to work for a small business. We provided network services and integrations to other small and medium businesses. I thought I knew what reliability, scalability and uptime was all about until I went to work in a place where people literally might die if the system was down.
UNIX is so close to the mainframe in reliability terms these days that there is literally no way to differentiate. I can engineer a Solaris, AIX or HP-UX system to 5 9's reliability, and have as much, or more, processing power as a mainframe sysplex. But, the problem is all that COBOL code. It has to be moved. The original design of much of the world's core finance and insurance systems happened in the 1970's. The original designers are gone. The code is not well documented or commented because the people who wrote it, for the most part, didn't think it would still be running in COBOL, on mainframes, in 2003. Moving it in one big jump is scary, and high unlikely to happen.
We will move it, because you can't really innovate with COBOL anymore. Programmers are harder and harder to find, the SME's are retiring, and the best and brightest of the new generation are going to distributed platforms, especially Java. So, instead, we will move it one sub-system at a time to a new platform. Either a UNIX or Linux cluster, and the foundation will probably be Java. There is no confidence in the data center in Windows computing. We have had too many bad experiences with the few systems we have tried out. Bad by our standards. Granted, Windows can now achieve 3 9's, with good engineering and a LOT of tender loving care. 5 9's amounts to roughly 5 minutes of downtime per year. 3 9's amounts to roughly 500 minutes of downtime per year. 500 minutes of downtime means we might miss our SLA's for as many 15 weeks a year, depending on how the downtime worked out. That's a lot of lost revenue. And patients who can't get their treatment authorized on time or doctors not getting paid on time.
If it makes you happy. But, remember those 200 billion lines of cobol? Those run in data centers that have mainframes. They run primarily banking and insurance transactional systems. Too many people make comments on here whose "IT experience" is limited to an SMB with 5 PC's and one server. You know what our Unix and Windows systems do? All the peripheral stuff that isn't mission critical, that isn't about the core transactions. Our mainframes run our daily and weekly transaction cycles and have been doing so for more than 25 years. They do it efficiently and well. Our enterprise is about moving those transactions through the system, day in and day out without fail. Reliability has to be measured in 4 and 5 9's. Show me a Windows shop (yours included) with 5 9's reliability on their core systems? Our core transactional system has not missed a cycle in more than 15 years. With major system enhancements due to state and federal regulatory changes, with Y2K, with HIPAA.
Yeah, I know, but I stick around cause there are a few gems here and there. Besides, it's so much fun to read the idiocy. I didn't really mean to stereotype 'em, but if the shoe fits....
That's my take on things, but I'd be very interested to hear from anyone who sees mainframe COBOL code being used to do anything different.
You're pretty much dead on. Sun and HP systems have had more horsepower than mainframes for quite a while now. They are nearly as stable too. But there's a couple issues:
A lot of mainframe code dates back to the 70's. Trying to migrate it would be a nightmare. Modular rewrites, one little piece at a time is more likely to succeed.
CICS, TSO, MVS, VSAM, etc. is dead on reliable. Our mainframe sysplex outages can be measured in mere minutes per year.
There are simply too many migration scenarios where the system was eventually migrated off the mainframe, but the managers who initiated the migration were no longer managers when it was complete due to budget overruns, delays, and other problems. CIO's learn from this, and aren't willing to go there if they don't have to.
Dell servers running Windows are nowhere the reliability level of Sun/IBM/HP RISC servers running UNIX, let alone the mainframes. Mainframe shops are not willing to risk mission critical money makers on unproven, unreliable upstarts.
one would be better off leaving it on the mainframe until peices of it could be rewritten in a more modern language.
I work in the health insurance industry. We run millions of health care transactions per day through our mainframes. We use midrange and distributed systems (Sun primarily, along with a few Windows systems) to bring the transactions in the door and do the business intelligence work afterwards. Last year we start our planning to move off the mainframe. It is exactly what you described. Take pieces (the easy ones first) and rewrite and rehost. We probably won't finish the effort before 2008, or so. Of course, our current transactional system has been in place on mainframes since about 1978. We haven't missed a weekly payment cycle in more than 15 years. Our Windows boxes (even the supposedly high availability ones) miss cycles on about a monthly basis. We have no intention of even considering Windows for the rewrite effort. We're looking at Sun/Solaris, IBM/AIX and Linux clusters.
Oh please! Sun Microsystems has had rehosting solutions for COBOL on the mainframe to their platforms for years. Look at:
http://www.sun.com/migration/mainframe/sunps/
http://www.sun.com/migration/mainframe/
This isn't innovative at all. Unless, of course, the only part of IT you have ever been involved with is PC's running Windows and a couple of small servers and don't know what the data center is all about.
Actually I am sorry to tell you but it sounds like your network wasn't designed properlly.
I'm sorry to have to say that you are wrong. We have boundary security, internal firewalls, proxy servers, mail gateways, etc. We use appropriate patch management (NOT SMS or SUS, please, neither of those is an appropriate solution) based on Tivoli.
The issue is two-fold, leaving aside the crappy security design of Windows for the moment. First is that the systems development staff cannot be blithely impacted just for fun and patching them has to be planned in advance. One hour of downtime for 200 developers is costly. The second is that I must, for contractual reasons, connect my network to my customer's network and to my parent company's network. Yes, we have boundary security but in some cases we have to allow poorly designed MS protocols (NetBIOS, MS RPC, etc.) through the firewalls between us and these networks. So, my security is really only as good as theirs, and their security is crappy.
Good grief, not another if you just had the right tool answer. Our networks are Cisco, our firewalls are either Cisco or Checkpoint. Our IDS are all SNORT. We use Tivoli for management, monitoring, distribution and risk correlation. We use Sun's Identity Server for web single signon. We are using good systems, with good staff in place. Tools are NOT the solution. Good people and good processes are. And even with good staff and processes, sometimes the bad guys win. The thing about InfoSec is that I have to win every time, the bad guys only have to win once.
I am a home user, and I caught none of these new virii.
Well whooptedo! It takes just a few minutes to install a patch at home, and you don't have to worry about that patch breaking a system that is going to cost you thousands of dollars for every minute its down. You don't have to worry about a DMZ change making your ecommerce systems inaccessible. When the network slows down, you don't have to worry that your Solaris/Oracle servers performance suddenly is no longer meeting SLA's. You don't have 1500 users to patch, 100+ MS servers to patch, firewall and IDS logs to evaluate, and customers to keep happy. And, lest we forget, the real reason my company is in business is to process a couple million insurance transactions a day so that doctors and pharmacists get paid and beneficiaries keep on getting their insurance coverage and so forth. Every time we expend money and hours fighting MS viruses is a loss for us.
So, I invite all of you home users who can't understand why viruses and worms are such a big deal cause you kept your home network safe to come and do my job for a day. Coordinate the security staff, work with the operations and development staff to keep current and future platforms secure, convince the COO/CEO/CFO combination that the money for the new IDS is necessary, research the threats of tomorrow, and react to SQL Slammer all at the same time. I've been in the industry for more than a decade and it's getting steadily worse, not better. Hell, 10 years ago I had no interest in InfoSec because there was no glamour or respect or money for it, unless you worked in some area dealing with the military or intelligence. Today I am an InfoSec Director. I left behind system design and architecture to move into the field because it's a fast growing, demanding field. Why is that? Well, there are security threats out there, but there are also lots of problems, caused by system complexity and crappy design.
Microsoft has these virus problems because they are #1.
I just love this answer. Actually, this is way off the mark, and I'll explain in a minute. But, first, let's start with the assumption that the reason that Microsoft has about 60,000 or so known worms and viruses in the wild is that it is #1 and thus the biggest target. In that case, it is another case for breaking the Microsoft monopoly. You see, the reason that we have anti-trust cases and monopoly busting is because a monopoly is bad for the consumer, the market, or some other segment of the economy. So, if having a monopolistic OS provider brings us this level of worms and viruses with the billions of dollars of damage cost by them annually, that is a very strong argument for breaking up the Microsoft monopoly.
However, Microsoft being #1 is not the reason for the virus problem in the MS world. The problem is the extremely poor security model in the OS. Basic user permissions set up poorly during install, lack of separation between applications and OS, poor design choices allowing browsers and web servers to tightly integrate into the OS, and so forth. Virus writers go after MS because it is easy to do so. These guys are motivated by being able to do it, and MS makes it ridiculously easy to do it. You can't propagate worms and viruses in Linux the way you can in MS Windows. A web browser exploit won't allow you to root the box, install an smtp mail server and then start mass mailing the worm out to the user's entire mailing list.
If you don't understand how OS security works, stop repeating what the MS apologists are bandying about as propoganda. Instead, go read a book or two on it and figure out the basics, and then come back and discuss OS security intelligently.
1. Neither Dell nor HP has a high-end server operating system equivalent to Solaris.
Uhhhh, can I have some of the dope you're smoking? Or did HP dump HP-UX yesterday? Depending on which commercial *NIX you like best, you might say Solaris is better than HP-UX, or vice versa (I'm on the Solaris side personally), but HP certainly does have a high end server OS equivalent to Solaris. HP-UX on a 64-way Superdome is a heck of a high end system. They don't get much bigger.
Please show me this "properly designed network", that allows an unpatched Active Directory domain and blocks traffic on RPC ports.
I've been hearing this bit of FUD for a while now about how it's not Microsoft's fault. If only all of these incompetent network and system administrators would patch their systems and maintain their firewalls how there wouldn't be any problem.
Well, I'm here to tell you that I work for an organization with about 1500 employees. We process over a hundred million transactions annually in our systems. Our average system administrator or network engineer has about 7.5 years of experience in the IT industry, our security staff (I'm the security director) has an average of 9 years of IT industry experience. Except for the Windows administrators (our office automation network is Windows based), everyone comes from either a Unix or mainframe or both background. We know what we are doing, have a very good network and well maintained servers and appropriate security levels.
And every damn Windows virus/worm that comes along impacts us, even our mainframes and unix boxes. Why? Cause the stupid things propagate with attack vectors that are ridiculous. Root exploits in a web browser or via an email message and you don't even have to execute the damn thing? RPC worms with multiple attack vectors (browser, file shares, mail, RPC)? Local user exploits using html pages and scripts that can bypass web browser security settings and then execute arbitrary code!
It doesn't matter how well built your network is, if you are not running it like an NSA network, with no connectivity to the outside world, no email, no web browsing, no nothing, these damn Windows attacks are going to get in and cost money. I've lost more than a thousand work hours this year to dealing with SQL Slammer, MS Blaster and SoBig. Even if I got rid of all the Windows systems in my network, I'd still have a problem because the attacks would continue, and continue to affect me, although only at the boundaries, which would be better. Except for all the crap the mail servers have to deal with.
Is IBM doing one, the other, or both? It's impossible to tell from the post.
From reading the article it is clear they are doing IP Telephony. IBM has been doing VOIP for years, just like every other Fortune 1000 has. But replacing 900 PBX with VOIP really means IP Telephony, but the guy writing the article doesn't know the difference so he calls it VOIP.
A PBX that can only handle newfangled phones and no classic phones is not a realistic candidate for any company, except maybe for the smallest.
Now why on earth would I want to connect old technology to my new technology? My new technology can do everything the old stuff can, plus all of the new capabilities. Since we do need analog capabilities we put analog gateways in that convert the digital stream to analog and then you can connect traditional analog technology to that. Primarily we had some older analog equipment that wasn't fully depreciated. It was cheaper to buy the analog gateway for our IPTel system than to write off the depreciation and buy newer digital equipment.
But this idea that you have to be able to connect the "old equipment" is ridiculous. We have IP phones that do everything that the extended feature digital phones ever did. Multi-line, call waiting, caller ID, extended functions and features, and more. And, new technology is enabled, like an XML based display. Now we can push data to the phone using IP and XML. Do that with your "normal telephones".
To be a PBX replacement, you should be able to interface to telephones.
Well, you can buy IP capable phones from a variety of sources. I'm sure that at least some of them are capable of interfacing with any call manager using QSIG and SIP. In fact, I'm almost positive that the Cisco phones don't care what call manager they interface with as long as the signaling comes in correctly. Software phones are convenient for those who travel or work remotely (at home for example) but they are not particularly convenient at your primary location. If you were to install an open source IPTel solution in your home, and had inbound VPN capability, then you could make and receive your home phone calls anywhere you could get an internet connection provided you had a laptop with the right software with you. That's what we are doing for our road warriors at work now.
but it seems a technology company could do that migration in around two years, not four.
First off, the project itself ain't getting done in 2 years. It's expensive, requiring a lot of capital, there's a lot of work to be done to migrate each PBX. There is additional network work to be done. And there's the bureaucracy to deal with. I work for one of IBM's competitors (professional services side, not hardware/software). The most time consuming part of any project like this is all the internal issues that have to be dealt with. When you put it all together, 3 to 4 years (done by 2008 is what they said, so all of 04, 05, 06 and 07) is not unreasonable at all. And they can't just take all of their scarce network and telecom professionals off of other projects to throw at this project. They still have call centers, data centers and offices to run as well during the transition.
A quick google search turned up IPTel.org. They have GPL'ed IP Telephony packages, including a SIP router (for call routing) and software phones that run on Linux. I'm sure more investigation would yield more information. My company derives a large amount of income from running a call center. We get paid for active minutes on the phone. It was in our best interests, financially, to purchase a commercial IPTel system that would be guarunteed by the vendor and would have 24x7 onsite support. By the way, we selected Cisco's AVVID solution, for those who are curious.
We had a serious dilemma, we run our production heavy hitting servers on UNIX and sometimes Linux. We are starting to transition Linux for a lot of our core infrastructure. The two vendors we looked at closest for IPTel were Cisco and Avaya. Cisco is very open standards based in terms of Network Protocols and Cisco tends to drive the industry for new and emerging protocols. BUT their call managers and voice mail servers run on Windows (ugh) and Compaq servers (double ugh). Avaya, on the other hand, is pretty proprietary in terms of protocols and is in trouble financially and market share wise. BUT their call managers run on Linux. Finally we chose Cisco because we felt that the protocol side of this was more important than a couple of call manager servers that we can replace in the future if need be.
Slashdot Mirror
I'm surprised they use Evolution, I think Mozilla is better, and does Evolution have spam-filtering?
They use Evolution because it interoperates with Microsoft Exchange Server and has an Outlook look and feel to it.
I don't know if loosing to the Viet Minh is sorry
There is a big difference. France lost militarily to the Viet Minh at Dien Bien Phu. The U.S. did not lose militarily to the Viet Minh. In fact, by 1971 the Viet Minh (or Viet Cong if you prefer, it was the same thing, different name) were essentially destroyed as an effective force of any sort above the level of basic terrorism. The North Vietnamese Army, descended from the Viet Minh as well, had pretty well lost every stand up battle it fought with the U.S. Army up til then as well, except perhaps the Ia Drang, which was pretty much a draw.
The U.S. won the military side of the war and lost it politically. In fact it had been lost politically long before the military issue was decided one way or another.
None of this is to take away from the NVA or the Viet Minh, both extremely capable light infantry and had some excellent leaders including Ho Chi Minh and Giap, among others.
Well, except for France - they haven't successfully beaten off an invasion force in the last thousand years...
While I really don't like the French government, this just isn't true. French military history since WWI is pretty sorry, including the defeat by the Germans in 1940, defeat by Viet Minh guerilla forces in the 1950's and defeat in Algeria in the early 60's. But go back just a bit. From about 1650 to 1870, roughly, France was the pre-eminent land power in Europe, and by extension the world given that Europe completed dominated the rest of the world during those years. France managed to dominate the entire European continent essentially single handedly from 1800 to 1815 under Napoleon. And really the loss in WWII was not due to the fighting spirit of the soldiers or industrial capacity of the country. It was mostly due to poor strategy and tactics and an unwillingness by the politicians and the generals to face reality.
We have 500 users hitting the system, retrieving about 150 insurance claims images per minute.
Heh, that should have said about 150 insurance claims images per second. If we were that slow we'd still be working on claims from 1995 or so.
Are there reliable/meaningful ways to compare throughput on these machines?
Well, one basis for comparison, a fairly reasonable one, is the SPEC benchmarks. Since IBM went to their Power4 CPU's for the Z series boxes you could compare SPEC benchmarks. However, as far as I know IBM has not submitted SPEC benchmarks on the Z series boxes. Another valid comparison is TPC benchmarks. TPC-C uses a standardized OLTP system that probably would be a valid comparison.
I think the thing to understand is that mainframes are, these days, just another server when talking about CPU power, transactional capabilities and so forth. The one place where they really shine is reliability and availability. It really is true that you get what you pay for. There is a reason why mainframes are expensive. They are engineered for a degree of reliability not found in less expensive systems. However, for most shops the difference between 4 9's of uptime, which is quite achievable by a Sun or HP cluster, and 5 9's of uptime is only about 45 minutes, on an annual basis. Is it really worth the cost of a mainframe sysplex instead of a Sun cluster to achieve the extra 45 minutes? Probably not.
It's also annoying that a CICS application that served 10000 terminals with sub-second response times is denigrated by people whose web-based app takes 10 seconds or more to do a simple update and return output to the user.
Well, here you are really comparing apples to oranges. CICS applications served up across an SNA network to dumb terminals is not really comparable to web applications (you don't specify what platform, but let's assume Java) across a TCP/IP network to modern PC's. Simply comparing CPU power and network throughput won't do the trick. Admittedly a "simple" update and output return should perform as well as a CICS application to dumb terminals. But only IF the system was designed properly, from end to end for performance. For example, we recently implemented an image management system on a sun cluster. We have 500 users hitting the system, retrieving about 150 insurance claims images per minute. We are able to achieve a response time of about .75 seconds with it. We designed it for response time because we lose money when our claims examiners sit and wait for the image. The user accesses a java based web app, images are housed on Hitachi storage, and the application and DB2 database are housed on a cluster based on SunFire 6800's. Uptime requirements are 99.9%. So high performance and reasonable reliability can be done on midrange boxes. It's a matter of design.
The real question is, do you have the right system for the job?
Okay, re-read what I said. You are obviously even more of a mainframe zealot than I am. I didn't say a word about specifically for transactional throughput. I said horsepower. That is a very generic term and most people would interpret that as meaning more CPU power in a general way. Which is quite true. Unless you are suggesting that a single Z990, fully populated with 4 MCM's, somehow has more CPU power than a Sun E15K with 18 system boards? If so, how do they do it? Is there some miraculous CPU technology in the ESA architecture that allows each CPU to be equivalent to 2.5 or so RISC CPU's? If so IBM Z series should be wiping everything else off the face of the planet.
If you want to make a claim that a mainframe's transactional throughput is so much superior to a high end RISC/UNIX box, how about backing it up with some stats? This really isn't true either, but it sounds good to make wild claims based on a "I have worked with em all" statement. The reason that we, and other mainframe shops, are not migrating off mainframes is because they are absolutely stable and reliable. A well designed sysplex achieves 5 9's of uptime annually without breaking a sweat. The best of the Sun/HP/IBM/Compaq/SGI boxes need quite a bit of TLC to go from 4 9's to 5.
And then when you point out to them that the world outside of Microsoft land has been doing this for years they get very defensive. It's like there's a serious inferiority complex going on.
I'd be curious if you had kept a list of all the different reasons your Windows servers failed.
Yes, we do keep such statistics. The most common problems are, in no particular order:
- System Administrator error
- Viruses, worms, malicious software, etc.
- Hardware failure
- Operating System (or integrated MS application, like web browsers) failure
Comparatively, the single most common cause of UNIX system downtime for us is developer/DBA error. Hardware failure rarely takes a system down so it can't function, I think we have had one outage in the past 5 years on a UNIX box (we have about 50) due to sys admin error and we have not had a system outage due to Operating System problems.When you start comparing, and note the issues with the OS and viruses/worms/etc. it is an eye opener. It certainly was to our operations team, who was pushing to move more applications to Microsoft environments.
But this is the standard that we have to adhere to because we provide claims payment, treatment authorization and such for insurance beneficiaries. Our SLA's with our customer only allow us 30 minutes of downtime for the entire system per week. That includes the mainframe sysplex, the point of sale system, the web access for doctors and pharmacies, the interactive voice systems and all of the claims entry points.
It's not about my data center kicking your data center's ass. This is the sort of hardware and software reliability that big data centers have to have. And this whole thread started from the idea that running COBOL within .NET was somehow innovative. The big iron shops (Sun, HP, IBM) have had COBOL migration or rehosting programs for years. I pointed out that the guy who thought this was innovative probably run a couple of windows PC's and a server. While that is necessary in the grand scheme of things, it isn't a really likely place to learn about big, mission critical IT. I used to work for a small business. We provided network services and integrations to other small and medium businesses. I thought I knew what reliability, scalability and uptime was all about until I went to work in a place where people literally might die if the system was down.
UNIX is so close to the mainframe in reliability terms these days that there is literally no way to differentiate. I can engineer a Solaris, AIX or HP-UX system to 5 9's reliability, and have as much, or more, processing power as a mainframe sysplex. But, the problem is all that COBOL code. It has to be moved. The original design of much of the world's core finance and insurance systems happened in the 1970's. The original designers are gone. The code is not well documented or commented because the people who wrote it, for the most part, didn't think it would still be running in COBOL, on mainframes, in 2003. Moving it in one big jump is scary, and high unlikely to happen.
We will move it, because you can't really innovate with COBOL anymore. Programmers are harder and harder to find, the SME's are retiring, and the best and brightest of the new generation are going to distributed platforms, especially Java. So, instead, we will move it one sub-system at a time to a new platform. Either a UNIX or Linux cluster, and the foundation will probably be Java. There is no confidence in the data center in Windows computing. We have had too many bad experiences with the few systems we have tried out. Bad by our standards. Granted, Windows can now achieve 3 9's, with good engineering and a LOT of tender loving care. 5 9's amounts to roughly 5 minutes of downtime per year. 3 9's amounts to roughly 500 minutes of downtime per year. 500 minutes of downtime means we might miss our SLA's for as many 15 weeks a year, depending on how the downtime worked out. That's a lot of lost revenue. And patients who can't get their treatment authorized on time or doctors not getting paid on time.
If it makes you happy. But, remember those 200 billion lines of cobol? Those run in data centers that have mainframes. They run primarily banking and insurance transactional systems. Too many people make comments on here whose "IT experience" is limited to an SMB with 5 PC's and one server. You know what our Unix and Windows systems do? All the peripheral stuff that isn't mission critical, that isn't about the core transactions. Our mainframes run our daily and weekly transaction cycles and have been doing so for more than 25 years. They do it efficiently and well. Our enterprise is about moving those transactions through the system, day in and day out without fail. Reliability has to be measured in 4 and 5 9's. Show me a Windows shop (yours included) with 5 9's reliability on their core systems? Our core transactional system has not missed a cycle in more than 15 years. With major system enhancements due to state and federal regulatory changes, with Y2K, with HIPAA.
Yeah, I know, but I stick around cause there are a few gems here and there. Besides, it's so much fun to read the idiocy. I didn't really mean to stereotype 'em, but if the shoe fits ....
That's my take on things, but I'd be very interested to hear from anyone who sees mainframe COBOL code being used to do anything different.
You're pretty much dead on. Sun and HP systems have had more horsepower than mainframes for quite a while now. They are nearly as stable too. But there's a couple issues:
- A lot of mainframe code dates back to the 70's. Trying to migrate it would be a nightmare. Modular rewrites, one little piece at a time is more likely to succeed.
- CICS, TSO, MVS, VSAM, etc. is dead on reliable. Our mainframe sysplex outages can be measured in mere minutes per year.
- There are simply too many migration scenarios where the system was eventually migrated off the mainframe, but the managers who initiated the migration were no longer managers when it was complete due to budget overruns, delays, and other problems. CIO's learn from this, and aren't willing to go there if they don't have to.
Dell servers running Windows are nowhere the reliability level of Sun/IBM/HP RISC servers running UNIX, let alone the mainframes. Mainframe shops are not willing to risk mission critical money makers on unproven, unreliable upstarts.one would be better off leaving it on the mainframe until peices of it could be rewritten in a more modern language.
I work in the health insurance industry. We run millions of health care transactions per day through our mainframes. We use midrange and distributed systems (Sun primarily, along with a few Windows systems) to bring the transactions in the door and do the business intelligence work afterwards. Last year we start our planning to move off the mainframe. It is exactly what you described. Take pieces (the easy ones first) and rewrite and rehost. We probably won't finish the effort before 2008, or so. Of course, our current transactional system has been in place on mainframes since about 1978. We haven't missed a weekly payment cycle in more than 15 years. Our Windows boxes (even the supposedly high availability ones) miss cycles on about a monthly basis. We have no intention of even considering Windows for the rewrite effort. We're looking at Sun/Solaris, IBM/AIX and Linux clusters.
Oh please! Sun Microsystems has had rehosting solutions for COBOL on the mainframe to their platforms for years. Look at:
- http://www.sun.com/migration/mainframe/sunps/
- http://www.sun.com/migration/mainframe/
This isn't innovative at all. Unless, of course, the only part of IT you have ever been involved with is PC's running Windows and a couple of small servers and don't know what the data center is all about.Actually I am sorry to tell you but it sounds like your network wasn't designed properlly.
I'm sorry to have to say that you are wrong. We have boundary security, internal firewalls, proxy servers, mail gateways, etc. We use appropriate patch management (NOT SMS or SUS, please, neither of those is an appropriate solution) based on Tivoli.
The issue is two-fold, leaving aside the crappy security design of Windows for the moment. First is that the systems development staff cannot be blithely impacted just for fun and patching them has to be planned in advance. One hour of downtime for 200 developers is costly. The second is that I must, for contractual reasons, connect my network to my customer's network and to my parent company's network. Yes, we have boundary security but in some cases we have to allow poorly designed MS protocols (NetBIOS, MS RPC, etc.) through the firewalls between us and these networks. So, my security is really only as good as theirs, and their security is crappy.
There is a solution:
Good grief, not another if you just had the right tool answer. Our networks are Cisco, our firewalls are either Cisco or Checkpoint. Our IDS are all SNORT. We use Tivoli for management, monitoring, distribution and risk correlation. We use Sun's Identity Server for web single signon. We are using good systems, with good staff in place. Tools are NOT the solution. Good people and good processes are. And even with good staff and processes, sometimes the bad guys win. The thing about InfoSec is that I have to win every time, the bad guys only have to win once.
I am a home user, and I caught none of these new virii.
Well whooptedo! It takes just a few minutes to install a patch at home, and you don't have to worry about that patch breaking a system that is going to cost you thousands of dollars for every minute its down. You don't have to worry about a DMZ change making your ecommerce systems inaccessible. When the network slows down, you don't have to worry that your Solaris/Oracle servers performance suddenly is no longer meeting SLA's. You don't have 1500 users to patch, 100+ MS servers to patch, firewall and IDS logs to evaluate, and customers to keep happy. And, lest we forget, the real reason my company is in business is to process a couple million insurance transactions a day so that doctors and pharmacists get paid and beneficiaries keep on getting their insurance coverage and so forth. Every time we expend money and hours fighting MS viruses is a loss for us.
So, I invite all of you home users who can't understand why viruses and worms are such a big deal cause you kept your home network safe to come and do my job for a day. Coordinate the security staff, work with the operations and development staff to keep current and future platforms secure, convince the COO/CEO/CFO combination that the money for the new IDS is necessary, research the threats of tomorrow, and react to SQL Slammer all at the same time. I've been in the industry for more than a decade and it's getting steadily worse, not better. Hell, 10 years ago I had no interest in InfoSec because there was no glamour or respect or money for it, unless you worked in some area dealing with the military or intelligence. Today I am an InfoSec Director. I left behind system design and architecture to move into the field because it's a fast growing, demanding field. Why is that? Well, there are security threats out there, but there are also lots of problems, caused by system complexity and crappy design.
Microsoft has these virus problems because they are #1.
I just love this answer. Actually, this is way off the mark, and I'll explain in a minute. But, first, let's start with the assumption that the reason that Microsoft has about 60,000 or so known worms and viruses in the wild is that it is #1 and thus the biggest target. In that case, it is another case for breaking the Microsoft monopoly. You see, the reason that we have anti-trust cases and monopoly busting is because a monopoly is bad for the consumer, the market, or some other segment of the economy. So, if having a monopolistic OS provider brings us this level of worms and viruses with the billions of dollars of damage cost by them annually, that is a very strong argument for breaking up the Microsoft monopoly.
However, Microsoft being #1 is not the reason for the virus problem in the MS world. The problem is the extremely poor security model in the OS. Basic user permissions set up poorly during install, lack of separation between applications and OS, poor design choices allowing browsers and web servers to tightly integrate into the OS, and so forth. Virus writers go after MS because it is easy to do so. These guys are motivated by being able to do it, and MS makes it ridiculously easy to do it. You can't propagate worms and viruses in Linux the way you can in MS Windows. A web browser exploit won't allow you to root the box, install an smtp mail server and then start mass mailing the worm out to the user's entire mailing list.
If you don't understand how OS security works, stop repeating what the MS apologists are bandying about as propoganda. Instead, go read a book or two on it and figure out the basics, and then come back and discuss OS security intelligently.
1. Neither Dell nor HP has a high-end server operating system equivalent to Solaris.
Uhhhh, can I have some of the dope you're smoking? Or did HP dump HP-UX yesterday? Depending on which commercial *NIX you like best, you might say Solaris is better than HP-UX, or vice versa (I'm on the Solaris side personally), but HP certainly does have a high end server OS equivalent to Solaris. HP-UX on a 64-way Superdome is a heck of a high end system. They don't get much bigger.
Please show me this "properly designed network", that allows an unpatched Active Directory domain and blocks traffic on RPC ports.
I've been hearing this bit of FUD for a while now about how it's not Microsoft's fault. If only all of these incompetent network and system administrators would patch their systems and maintain their firewalls how there wouldn't be any problem.
Well, I'm here to tell you that I work for an organization with about 1500 employees. We process over a hundred million transactions annually in our systems. Our average system administrator or network engineer has about 7.5 years of experience in the IT industry, our security staff (I'm the security director) has an average of 9 years of IT industry experience. Except for the Windows administrators (our office automation network is Windows based), everyone comes from either a Unix or mainframe or both background. We know what we are doing, have a very good network and well maintained servers and appropriate security levels.
And every damn Windows virus/worm that comes along impacts us, even our mainframes and unix boxes. Why? Cause the stupid things propagate with attack vectors that are ridiculous. Root exploits in a web browser or via an email message and you don't even have to execute the damn thing? RPC worms with multiple attack vectors (browser, file shares, mail, RPC)? Local user exploits using html pages and scripts that can bypass web browser security settings and then execute arbitrary code!
It doesn't matter how well built your network is, if you are not running it like an NSA network, with no connectivity to the outside world, no email, no web browsing, no nothing, these damn Windows attacks are going to get in and cost money. I've lost more than a thousand work hours this year to dealing with SQL Slammer, MS Blaster and SoBig. Even if I got rid of all the Windows systems in my network, I'd still have a problem because the attacks would continue, and continue to affect me, although only at the boundaries, which would be better. Except for all the crap the mail servers have to deal with.
Is IBM doing one, the other, or both? It's impossible to tell from the post.
From reading the article it is clear they are doing IP Telephony. IBM has been doing VOIP for years, just like every other Fortune 1000 has. But replacing 900 PBX with VOIP really means IP Telephony, but the guy writing the article doesn't know the difference so he calls it VOIP.
A PBX that can only handle newfangled phones and no classic phones is not a realistic candidate for any company, except maybe for the smallest.
Now why on earth would I want to connect old technology to my new technology? My new technology can do everything the old stuff can, plus all of the new capabilities. Since we do need analog capabilities we put analog gateways in that convert the digital stream to analog and then you can connect traditional analog technology to that. Primarily we had some older analog equipment that wasn't fully depreciated. It was cheaper to buy the analog gateway for our IPTel system than to write off the depreciation and buy newer digital equipment.
But this idea that you have to be able to connect the "old equipment" is ridiculous. We have IP phones that do everything that the extended feature digital phones ever did. Multi-line, call waiting, caller ID, extended functions and features, and more. And, new technology is enabled, like an XML based display. Now we can push data to the phone using IP and XML. Do that with your "normal telephones".
To be a PBX replacement, you should be able to interface to telephones.
Well, you can buy IP capable phones from a variety of sources. I'm sure that at least some of them are capable of interfacing with any call manager using QSIG and SIP. In fact, I'm almost positive that the Cisco phones don't care what call manager they interface with as long as the signaling comes in correctly. Software phones are convenient for those who travel or work remotely (at home for example) but they are not particularly convenient at your primary location. If you were to install an open source IPTel solution in your home, and had inbound VPN capability, then you could make and receive your home phone calls anywhere you could get an internet connection provided you had a laptop with the right software with you. That's what we are doing for our road warriors at work now.
but it seems a technology company could do that migration in around two years, not four.
First off, the project itself ain't getting done in 2 years. It's expensive, requiring a lot of capital, there's a lot of work to be done to migrate each PBX. There is additional network work to be done. And there's the bureaucracy to deal with. I work for one of IBM's competitors (professional services side, not hardware/software). The most time consuming part of any project like this is all the internal issues that have to be dealt with. When you put it all together, 3 to 4 years (done by 2008 is what they said, so all of 04, 05, 06 and 07) is not unreasonable at all. And they can't just take all of their scarce network and telecom professionals off of other projects to throw at this project. They still have call centers, data centers and offices to run as well during the transition.
A quick google search turned up IPTel.org. They have GPL'ed IP Telephony packages, including a SIP router (for call routing) and software phones that run on Linux. I'm sure more investigation would yield more information. My company derives a large amount of income from running a call center. We get paid for active minutes on the phone. It was in our best interests, financially, to purchase a commercial IPTel system that would be guarunteed by the vendor and would have 24x7 onsite support. By the way, we selected Cisco's AVVID solution, for those who are curious.
We had a serious dilemma, we run our production heavy hitting servers on UNIX and sometimes Linux. We are starting to transition Linux for a lot of our core infrastructure. The two vendors we looked at closest for IPTel were Cisco and Avaya. Cisco is very open standards based in terms of Network Protocols and Cisco tends to drive the industry for new and emerging protocols. BUT their call managers and voice mail servers run on Windows (ugh) and Compaq servers (double ugh). Avaya, on the other hand, is pretty proprietary in terms of protocols and is in trouble financially and market share wise. BUT their call managers run on Linux. Finally we chose Cisco because we felt that the protocol side of this was more important than a couple of call manager servers that we can replace in the future if need be.