|
quick re-cap before Al Mac BS http://two.digital.cnet.com/cgi-bin2/flo?y=eByE0BXoDZ0U0dFt0Av This is an artcle about Microsoft MSN Messenger Service Outage & what the implications are for other Microsoft promises. We have seen this kind of scenario in the past & doubtless again in the future. http://www.ignite400.org/html/real/it_exists56.htm The "It Exists" video shows how the Microsoft server approach is like Keystone Cops when compared to IBM's different kind of computing world View this with Real Player or with anything that can play a .mpg file I took a look at the URL cited here. This is yet another crisis in consumer confidence for Microsoft. Microsoft is able to get away with this because they are an illegal monopoly that the US government is unable to resolve. Consider what the impact might be on ordinary businesses using the computing products supplied by Microsoft. A related story is that Microsoft USED to run their business off of IBM eServers, but ran into marketing difficulties. They were SAYING that Microsoft servers could do anything that an IBM eServer could do, but using IBM eServers to do their own internal work. This led to a conversion effort. 23 IBM eServers were replaced with over 500 Microsoft eServers needed to do the same work. How long does it take to reboot all these servers? Does the server farm have a master server - take an option to reboot 100%? They ran into a problem with the enforcement of business rules crossing servers. This is one area that IBM operating systems have a lot of experience with, but although Microsoft can manage terabytes of information, their software is not really competitive with IBM when it comes to enforcing business rules across fragmented data bases. They were unable to get this to work on the Microsoft servers replacing the IBM eserver business computers. So the work was transferred to an ASP. The work is back on IBM eServers at the ASP. This way it works right & Microsoft can say with a straight face that THEY are not using any IBM eServers to run their business. This story has been heavily covered in the IBM eServer press. One of the problems with this whole topic is that the technical details are extremely difficult to explain to non-technical users, and some companies do not even try to give an explanation. Last nite when I was running backup on our IBM eServer, and studying some software development work on automating some cost updates to our ERP, I happened to notice that the Console for our NT Network had the Blue Screen of You Know What, so I phoned our PC Administrator at home to give him these tidings. "Again?" he said with a note of dismay, so he started to tell me what he wanted me to do about it. The last time I am aware of was earlier that same day. We had a power outage 4.30 am Monday July 9 which lasted 3 seconds, according to the IBM eServer UPS log, but within those 3 seconds, the NT Server lost a communication line & could not get it back up again. One of the steps for NT recovery was to power down everything connected to it, including the IBM eServer. This is a case of the weakest link managing a company's networks. Now IBM eServers CAN run Microsoft Servers, using system software modified by IBM to not have the Microsoft fragility ... IBM is able to do this because NT heavily uses OS/2 code, which was jointly developed by Microsoft & IBM. But I have been unable to persuade my employer to use the IBM version of Microsoft OS. There must have been something earlier because over the weekend I was not able to send e-mail to co-workers. It was my turn to express a note of dismay when it came to transcribing the story since print screen is not an option here ... the screen was filled with massive amounts of memory address problems. This led to my suggestion that this is a case for using our DIGITAL CAMERA ... we need to get a snapshot of this screen, then when we are back in business, download the picture into a folder with some name like NT-BLUES labeled based on date & time of the infamous blue screen of Microsoft death. MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac) Marty is correct. That's what Microsoft tells its customers to do. It often takes us more than 7 days to recover from a Microsoft crash. Why should Microsoft be any different? Perhaps from this we can get a standard. How long is it supposed to take to recover? If it takes Microsoft X days to fix their own system, when supplied by Bill Gates infinitely deep financial pocket, then the staff of customers can say to their bosses to not expect us to do same kind of work in less than how many days on what budget? I suspect part of Microsoft problem is that they are probably not allowed to use non-Microsoft products that have been developed to patch known Microsoft problems that are not Politically Correct for Microsoft Tech Support to acknowlege exist. Subj: RE: The future of computing From: (Urbanek, Marty) Give them a chance. It has only been down 7 days. Rebooting is only the first step in Microslug recovery strategy. Next, I think standard procedure is to reinstall the operating system and application software and see if that fixes the problem. ;-) From: (Jim Franz) if you haven't seen the "It Exists" video, it explains why pretty clearly. The world does not know there is a better solution. If you grew up re-booting your desktop, you've been indoctrinated. http://www.ignite400.org/html/real/it_exists56.htm
- Subject: The future of computing
- From: "Chris Rehm" <javadisciple@xxxxxxxxxxxxx>
- Date: Mon, 9 Jul 2001 15:54:28 -0700
http://two.digital.cnet.com/cgi-bin2/flo?y=eByE0BXoDZ0U0dFt0Av I pretty much think this is the future of our mission critical systems. It really shocks me that they'd get to a point where they'd have to reboot a network in commercial service. It impresses me that this didn't work. Chris Rehm javadisciple@earthlink.net If you believe that the best technology wins the marketplace, you haven't been paying attention. +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.