From what I recall from some time ago (my personal memory is like FLASH - the more I write, the more it is "worn out" and the faster it fails), back when PSI(?) had a z emulator on Itanium, IBM sued them. Some of the reasons given were: (1) that z/OS had a reputation in the field for extreme reliability; (2) much of z/OS's reliability was based on the z hardware's reliability and automatic recovery from errors; (3) allowing z/OS to run on non-z hardware would decrease z/OS's reliability due to decreased hardware reliability; (4) such reduction in reliability would adversely impact z/OS's reputation in the market place; (5) this would negatively impact sales and increase support costs (6) therefore, allowing z/OS to run on non-z hardware (at least in a non-development environment) was not in IBM's best interest.
I know you pointed out that (as we say around here), the user can "risk assess" and accept the decreased reliability in return for decreased cost. IMO, that's one of the reasons for running MS-Windows servers. But I also know, at least from what I've experienced, that despite this "risk acceptance", that end users will complain loudly if they don't get what they're used to. I'm going to catch hell today for just this reason. I was _forced_ to make an ACS change to our STORCLAS SMS routine. We had allocated a special storage group for a specific set of data set names, which started with a given HLQ . We did this, with the provision that they would not be recovered at Disaster Recovery. This was accepted. Back then. However, in our latest D.R. test, we "caught hell" because those "production" data sets were not available. We said, "We know. That was agreed to when we separated them into their own pool." They said, "Well that's not acceptable anymore." Us: "You agreed to back up what you needed yourself." Them: "Well, we changed our mind!!" So I had to make an emergency change. Our ACS routines are "fragile" and I missed a change. This, after a few hours, caused disk space errors. And I got charged with all the problems associated with it because I am the one who made the change. I now don't believe much of anybody when they say that they will accept any responsibility for anything. Given time, they will renege on any agreement that they possibly can get away with reneging on. I am getting very cynical and sick of people in my old age. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 • N. Richland Hills • TX 76010 (817) 255-3225 phone • [email protected] • www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of R.S. > Sent: Thursday, August 23, 2012 4:11 AM > To: [email protected] > Subject: Re: X86 server > > W dniu 2012-08-23 04:23, McKown, John pisze: > > X64 hardware, as much as it has improved, is still not as reliable or > > have the I/O capacity of the z hardware. E.g.: We had a TCM fail > > once. A spare picked up the work, automatically restarting the > > instruction stream, with no outage of any sort and no software > > involvement. X86, from what I'm told, would at least require the OS > > to do the equivalent of a checkpoint restart. Also had an OSA fail. > > The other OSA did an ARP takeover and no IP sessions were lost. TCPIP > > was informed, but all it did was put out a message and not start any > > new sessions on the failing OSA. Our "open" people called me a liar > > when I told them that. > > So ? > We know: > - mainframe HW is more reliable and more "redundant" than pc HW. > - even mainframe HW sometimes do fail. > > Now we have the followig choices: > - use one OSA card or more and pay for that > - use single BOOK configuration, or pay for more BOOKs > - use single CPC or multiple sysplexedd CPCs > - etc. etc > > So, we have some choice: you may want more reliable equipment and pay > more or less reliable one and pay less. > X64 would be another option to pay less for less reliablity. But it's > not due to decision of IBM. And it has very little to do with > technology, it has a lot of to do with business nd politics. > > > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > -- > Treść tej wiadomości może zawierać informacje prawnie chronione Banku > przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być > jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie > jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do > jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, > kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze > jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę > wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając > odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej > kopie wydrukowane lub zapisane na dysku. > > This e-mail may contain legally privileged information of the Bank and > is intended solely for business use of the addressee. This e-mail may > only be received by the addressee and may not be disclosed to any third > parties. If you are not the intended addressee of this e-mail or the > employee authorised to forward it to the addressee, be advised that any > dissemination, copying, distribution or any other similar activity is > legally prohibited and may be punishable. If you received this e-mail > by mistake please advise the sender immediately by using the reply > facility in your e-mail software and delete permanently this e-mail > including any copies of it either printed or saved to hard drive. > > BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 > 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: [email protected] > Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego > Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: > 526-021-50-88. > Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w > całości wpłacony) wynosi 168.410.984 złotych. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
