Re: big iron mainframe vs. x86 servers
On Wed, 18 Nov 2009 07:32:24 -0800 (PST), StevePratt steve_pr...@isp.state.il.us wrote: As an aside, what is a good abbreviation for mainframe than m_f? And my response is that I call a mainframe a computer. Or sometimes I call a mainframe a real computer. As opposed to PCs; where PC stands for pretend computer. Or TC, toy computer. Or the British affection Toy Town. Of course, there are computers embedded in equipment that rival in power mainframes that I have worked in. But in a different direction - does it serve a useful purpose anymore to separate out the blue box in our computer room from the pink box? Sure, the pink box runs Solaris, and the blue box could run Linux. It can feel good to call my computer a mainframe, but it may be poor marketing to the decision makers who are planning our shop's future. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Fri, 30 Oct 2009 11:24:55 -0600, Joe Pfeiffer pfeif...@cs.nmsu.edu wrote: Unicode has a lot of inertia at this point, and 7-bit ASCII has more. I can reasonably expect both of them to last long after my death, and docs and conversion programs until civilization collapses to the point computers are gone. How about EBCDIC? What about it? If I needed to read it, it would be one-line awk script away. Sort of my point. Can you reasonably expect it to last long after your death? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On 31 Oct 2009 09:37:18 -0700, Patrick Scheible k...@zipcon.net wrote: All the characters from the several versions of EBCDIC are in Unicode. It should be simple enough to map them from EBCDIC order to Unicode order, and back, if necessary. Sort order would be different - will that matter? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Howard Brazee Sent: Monday, November 02, 2009 10:01 AM To: IBM-MAIN@bama.ua.edu Subject: Re: big iron mainframe vs. x86 servers On 31 Oct 2009 09:37:18 -0700, Patrick Scheible k...@zipcon.net wrote: All the characters from the several versions of EBCDIC are in Unicode. It should be simple enough to map them from EBCDIC order to Unicode order, and back, if necessary. Sort order would be different - will that matter? That was a BIG point that we made to the convert to Windows! people. The data in the reports would be in a different order unless they modified the SORT to rearrange the code points so that the ASCII would come out in EBCDIC order. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * 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(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Mon, 02 Nov 2009 09:45:34 -0700, Joe Pfeiffer pfeif...@cs.nmsu.edu wrote: Unicode has a lot of inertia at this point, and 7-bit ASCII has more. I can reasonably expect both of them to last long after my death, and docs and conversion programs until civilization collapses to the point computers are gone. How about EBCDIC? What about it? If I needed to read it, it would be one-line awk script away. Sort of my point. Can you reasonably expect it to last long after your death? I'm not quite sure whether you mean EBCDIC or the awk script; if EBCDIC yes, the awk script has never needed to be written, so unless I come across some reason to read some EBCDIC, no. You were talking about Unicode and 7-bit ASCII lasting long after your death. I just extended this to ask your opinion about a more on-topic coding system in ibm-main. I wouldn't be surprised if IBM wouldn't be quite satisfied switching away from MVS/EBCDIC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On 02 Nov 2009 09:08:18 -0800, Patrick Scheible k...@zipcon.net wrote: Sort order would be different - will that matter? Yes, there are probably some programs for which it does. Those that do will have to convert Unicode to EBCDIC and probably convert back again to do their final output. Or be rewritten completely. I have modified programs when our IBM mainframe shop moved from DOS to OS and the default sign in unsigned numbers changed, so that comparing old data still worked. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
In a6b9336cdb62bb46b9f8708e686a7ea005bde01...@nrhmms8p02.uicnrh.dom, on 10/27/2009 at 02:20 PM, McKown, John john.mck...@healthmarkets.com said: I don't like metric, personally. Too Earth-centric. I think we need to totally divorce all time and distance to more universal quantities. I nominate the 21 cm hydrogen spectral line for a distance and 7E-10 seconds for time (time for light to travel 21 cm). 1 gigatick would be .7 seconds. Then, we can join the galactic societies! grin Physicist have been using units in which c=1 for nearly a century. Slightly newer is also setting h (or is it h slash?) to 1. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
In ns4me5ddmf044tpv614bk9qs2p3crng...@4ax.com, on 10/30/2009 at 10:26 AM, Howard Brazee howard.bra...@cusys.edu said: How about EBCDIC? What is EBCDIC? Hasn't the count of possible answer gone into 3 digits? It's definitely gone into two digits? The good thing about Unicode is that the Unicode Consortium has promised to never reassign code points. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Fri, 30 Oct 2009 09:45:04 -0600, Joe Pfeiffer pfeif...@cs.nmsu.edu wrote: Unicode has a lot of inertia at this point, and 7-bit ASCII has more. I can reasonably expect both of them to last long after my death, and docs and conversion programs until civilization collapses to the point computers are gone. How about EBCDIC? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Tue, 27 Oct 2009 19:41:23 -, Dave Wade g8...@yahoo.com wrote: I meant, all files marked with time, should have been marked with UTC/Zulu/Grenwich. Whilst you might set the zone to GMT if you sync the clock to the Internet it will be set to UTC. And yes there is a difference It hasn't always been so, and I'm talking 20-20 hindsight about the way things would have been done. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On 27 Oct 2009 13:15:48 -0700, paulgboul...@aim.com (Paul Gilmartin) wrote: Administrative Assistant: He's out to lunch. When can he call you back? [What time zone is Benton Harbor? UP or LP? Do they observe DST? ... Too much uncertainty. Simplify!] gil: I'm about to go to lunch myself. Can he call me back two hours from now? [Long pause; imagine neural gears grinding at other end.] AA: Errr... What time zone are you in? [Obvious poor choice of algorithm.] My son-in-law showed up for a meeting with his boss an hour late in Seattle, after his Outlook translated the meeting to Rocky Mountain Time. That would have worked for a phone meeting, but confusion exists. Maybe the best hope to eliminate this confusion in the U.S. is the acceptance of ESPN time. When people schedule their time to watch a live sporting event, it starts to matter to them. Or follow China and have one time zone for the whole country. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Time Zones (was: big iron mainframe vs. x86 servers)
On Wed, 28 Oct 2009 09:22:13 -0600, Howard Brazee wrote: My son-in-law showed up for a meeting with his boss an hour late in Seattle, after his Outlook translated the meeting to Rocky Mountain Time. That would have worked for a phone meeting, but confusion exists. A few years ago, Outlook sent out an invitation to a conference the next week at 9:00 GMT-7. But the Spring DST change intervened: it should have said GMT-6. I made a trouble ticket to IT, which promptly replied that it's a known problem; Microsoft deems it WAD. But totally misleading for my colleagues in OZ. (Would Lotus do any better?) Maybe the best hope to eliminate this confusion in the U.S. is the acceptance of ESPN time. When people schedule their time to watch a live sporting event, it starts to matter to them. Or follow China and have one time zone for the whole country. Underreacher. Oh, you mean we should all operate on China time; majority rules. Might happen. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Tue, 27 Oct 2009 08:10:18 -0500, jmfbahciv jmfbah...@aol wrote: With 20-20 hindsight, all computers should have started off marking files that way. It's not easy changing, but it would really be worth it. How? Count your bits. Oh, and think about IBM cards. I meant, all files marked with time, should have been marked with UTC/Zulu/Grenwich. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Tue, 27 Oct 2009 10:26:38 -0700 (PDT), Eric Chomko pne.cho...@comcast.net wrote: For space applications, sure. A satellite that orbits in 101 minutes had better use UTC, but why humans on Earth in the same place? You think UTC tells you anything about where the Earth's terminator is? When the Earth is facing totally opposite the Sun on any given day. No, local time is a must for determining exactly when the sun will rise where you are! Heck well can live with two measuring systems, we can live with two times. My computer doesn't care where the sun is. If it needs to support people 24 hours per day, maybe anywhere in the world, what does the sun have to do with it? But if it is important to know when data are modified, having over 24 time zones has no advantage.Mark it with a common, universal time. The display routine can change it to local time just fine for users, even when the users are on the opposite sides of the Earth. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
Howard Brazee wrote: But if it is important to know when data are modified, having over 24 time zones has no advantage.Mark it with a common, universal time. The display routine can change it to local time just fine for users, even when the users are on the opposite sides of the Earth. We ran into that a couple of weeks ago - colleague in Australia ran a DSS dump, and when we restored it, got a warning message that the file had a bad date (restored anyway). Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
In China, your clock is set to Beijing time. Even if you're at the other edge of China, 16:00 in Beijing is 16:00 where you are. Really, I think every is so adapted to the idea of working from 8am to 5pm. Yet it's pretty meaningless in the grand scheme of things. The world would be a lot simpler if everyone just set their clocks the same. My iPhone's world clock feature is loaded with a half-dozen other clocks. But this would fall under the same debate as converting the US from the Imperial system to Metric, albeit on a global scale. Scott On Tue, Oct 27, 2009 at 11:32 AM, Howard Brazee howard.bra...@cusys.eduwrote: On Tue, 27 Oct 2009 10:26:38 -0700 (PDT), Eric Chomko pne.cho...@comcast.net wrote: For space applications, sure. A satellite that orbits in 101 minutes had better use UTC, but why humans on Earth in the same place? You think UTC tells you anything about where the Earth's terminator is? When the Earth is facing totally opposite the Sun on any given day. No, local time is a must for determining exactly when the sun will rise where you are! Heck well can live with two measuring systems, we can live with two times. My computer doesn't care where the sun is. If it needs to support people 24 hours per day, maybe anywhere in the world, what does the sun have to do with it? But if it is important to know when data are modified, having over 24 time zones has no advantage.Mark it with a common, universal time. The display routine can change it to local time just fine for users, even when the users are on the opposite sides of the Earth. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Sent: Tuesday, October 27, 2009 2:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: big iron mainframe vs. x86 servers In China, your clock is set to Beijing time. Even if you're at the other edge of China, 16:00 in Beijing is 16:00 where you are. Really, I think every is so adapted to the idea of working from 8am to 5pm. Yet it's pretty meaningless in the grand scheme of things. The world would be a lot simpler if everyone just set their clocks the same. My iPhone's world clock feature is loaded with a half-dozen other clocks. But this would fall under the same debate as converting the US from the Imperial system to Metric, albeit on a global scale. Scott I'd vote for it. And eliminated the stinking daylight saving time screw-up! Of course, at my first job, I had the print banner pages print the current date and time in GMT like: nn month yyy hh:mm:ss with a 24 hour clock. I like to have gotten lynched by everybody in that shop. They could not remember how to convert. Subtracting 6 (or 5) was too difficult. Oh, and then subtracting another 12 if the number was 12 was just obscene. I don't like metric, personally. Too Earth-centric. I think we need to totally divorce all time and distance to more universal quantities. I nominate the 21 cm hydrogen spectral line for a distance and 7E-10 seconds for time (time for light to travel 21 cm). 1 gigatick would be .7 seconds. Then, we can join the galactic societies! grin -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * 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(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Tue, 27 Oct 2009 12:32:06 -0600, Howard Brazee wrote: On Tue, 27 Oct 2009 10:26:38 -0700 (PDT), Eric Chomko wrote: For space applications, sure. A satellite that orbits in 101 minutes had better use UTC, but why humans on Earth in the same place? You think UTC tells you anything about where the Earth's terminator is? Actually, it does. With UTC and a globe, I can tell pretty well where the terminator is. If someone tells me his civil time, I need one more piece of information. When the Earth is facing totally opposite the Sun on any given day. No, local time is a must for determining exactly when the sun will rise where you are! True. Heck well can live with two measuring systems, we can live with two times. And Roman and Arabic numerals. But why should we. My computer doesn't care where the sun is. If it needs to support people 24 hours per day, maybe anywhere in the world, what does the sun have to do with it? Amen. But if it is important to know when data are modified, having over 24 time zones has no advantage.Mark it with a common, universal time. The display routine can change it to local time just fine for users, even when the users are on the opposite sides of the Earth. So, when will ISPF start marking members in UTC? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Tue, 27 Oct 2009 14:20:44 -0500, McKown, John wrote: I'd vote for it. And eliminated the stinking daylight saving time screw-up! But let's dispel the specious theological argument. There are opponents who contend that DST is contrary to God's will. Actually, the current convention of Standard Time is contrary to the best Scriptural reference I know: Matthew:20. Of course, at my first job, I had the print banner pages print the current date and time in GMT like: nn month yyy hh:mm:ss with a 24 hour clock. I like to have gotten lynched by everybody in that shop. They could not remember how to convert. Subtracting 6 (or 5) was too difficult. Oh, and then subtracting another 12 if the number was 12 was just obscene. I once tried to place a phone call from Colorado to Benton Harbor, MI. Administrative Assistant: He's out to lunch. When can he call you back? [What time zone is Benton Harbor? UP or LP? Do they observe DST? ... Too much uncertainty. Simplify!] gil: I'm about to go to lunch myself. Can he call me back two hours from now? [Long pause; imagine neural gears grinding at other end.] AA: Errr... What time zone are you in? [Obvious poor choice of algorithm.] I don't like metric, personally. Too Earth-centric. I think we need to totally divorce all time and distance to more universal quantities. I nominate the 21 cm hydrogen spectral line for a distance and 7E-10 seconds for time (time for light to travel 21 cm). 1 gigatick would be .7 seconds. Then, we can join the galactic societies! grin How about the Planck time and the Planck length, suitably scaled. But aren't powers of 10 enormously anthropocentric? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Tue, Oct 27, 2009 at 3:20 PM, McKown, John john.mck...@healthmarkets.com wrote: I don't like metric, personally. Too Earth-centric. I think we need to totally divorce all time and distance to more universal quantities. I nominate the 21 cm hydrogen spectral line for a distance and 7E-10 seconds for time (time for light to travel 21 cm). 1 gigatick would be .7 seconds. Then, we can join the galactic societies! grin OK, now you're scaring me, because I find this appealing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
SWATCH Internet time? What is a Swatch .beat? We have divided up the day into 1000 .beats. So, one Swatch .Beat is equivalent to 1 Minute 26.4 Seconds. Why use Internet Time? Internet Time exists so that we do not have to think about timezones. For example, if a New York web-supporter makes a date for a chat with a cyber friend in Rome, they can simply agree to meet at an @ time - because internet time is the same all over the world. Where is the Internet Time meridian? Biel Meantime (BMT) is the universal reference for internet time. A day in internet time begins at midnight BMT (@000 Swatch .Beats) (Central European Wintertime). The Meridian is marked for all to see on the facade of the Swatch International headquarters on Jakob-Staempfli Street, Biel, Switzerland. When did Internet Time start? The BMT Meridian was inaugurated on October 23rd, 1998, in the presence of Nicholas Negroponte, founder and director of the media laboratory at the Massachusetts Institute of Technology. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of P S Sent: Tuesday, October 27, 2009 4:37 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] big iron mainframe vs. x86 servers On Tue, Oct 27, 2009 at 3:20 PM, McKown, John john.mck...@healthmarkets.com wrote: I don't like metric, personally. Too Earth-centric. I think we need to totally divorce all time and distance to more universal quantities. I nominate the 21 cm hydrogen spectral line for a distance and 7E-10 seconds for time (time for light to travel 21 cm). 1 gigatick would be .7 seconds. Then, we can join the galactic societies! grin OK, now you're scaring me, because I find this appealing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On 26 Oct 09 08:41:40 -0800, Charlie Gibbs cgi...@kltpzyxm.invalid wrote: No, on the contrary. The internals keep representing the same point in time, as utc, but you have it presented as a time in the format of your choosing. Exactly. UTC has been the standard in aviation for decades for this very reason. With 20-20 hindsight, all computers should have started off marking files that way. It's not easy changing, but it would really be worth it. Especially for those sites that gradually change the time to make sure transactions get stored in order as the clock bumps back because of daylight savings time - but also for any multi-time zone database. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Mon, 26 Oct 2009 10:24:05 -0600, Howard Brazee wrote: On 26 Oct 09 08:41:40 -0800, Charlie Gibbs wrote: No, on the contrary. The internals keep representing the same point in time, as utc, but you have it presented as a time in the format of your choosing. Exactly. UTC has been the standard in aviation for decades for this very reason. Did a few plies of this thread get lost in the newsgroup void? With 20-20 hindsight, all computers should have started off marking files that way. It's not easy changing, but it would really be worth it. Regrettably, it rarely works right. MVS and UNIX early realized the benefit of UTC (but MVS only partly -- how are ISPF PDS members marked? What about tape labels?) But new systems must reinvent. MS DOS and Macintosh OS both well after started running the primary clock on civil time. Mac is better now; Windows is still ailing. I suspect the mechanism is that engineers eager to get to power-on test start their test beds with the clock on civil time. They procrastinate implementing the conversion routine. Then the shipment deadline looms, and the transition is deferred to a future release, then the conversion effort is unacceptable. (When will ISPF start using UTC?) And z/OS and Unix System Services still don't do it right for US timestamps prior to 2007. What fraction of z/OS installations (away from the UK meridian) still run the [E]TOD on civil time? Especially for those sites that gradually change the time to make sure transactions get stored in order as the clock bumps back because of daylight savings time - but also for any multi-time zone database. Gulp! And the ETR will only slew a couple seconds a day. It wouldn't finish before time to change back. I understand that during leap seconds, z/OS dispatches no jobs. The designers likely considered but eschewed making even the leap second correction gradually, over a few hours. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John P. Baker Sent: Wednesday, October 21, 2009 9:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: big iron mainframe vs. x86 servers The big advantages of the IBM mainframe architecture have always been application upward compatibility, I/O throughput, and RAS (reliability, availability, and serviceability). SNIPPAGE Give that staggering number of financial transactions processed on a daily basis, over 90% of which is done on large-scale IBM mainframes, is it not strange that you have never heard of a mainframe virus? IBM RAS and IBM Security (whether implemented via IBM RACF, CA ACF/2, CA-Top Secret Security, or some other External Security manager (ESM)) is what keep these systems running. SNIPPAGE Actually, there are a few of them. I had made the same statement circa 1990, and I was pointed to an experiment that had been done to prove that an MVS based virus could be accomplished. One of the reasons for Production Control types to only accept source and do their own compiles and linkages is to prevent what could be malicious code from being copied and then infecting a business' production load libraries. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
jbaker...@comporium.net (John P. Baker) writes: Give that staggering number of financial transactions processed on a daily basis, over 90% of which is done on large-scale IBM mainframes, is it not strange that you have never heard of a mainframe virus? IBM RAS and IBM Security (whether implemented via IBM RACF, CA ACF/2, CA-Top Secret Security, or some other External Security manager (ESM)) is what keep these systems running. the original mainframe tcp/ip implementation was done in pascal and never experienced any buffer length related problems ... some past posts modifying mainframe tcp/ip so that instead of taking 3090 processor to get 44kbytes/sec ... a small part of 4341 processor got channel speed thruput http://www.garlic.com/~lynn/subnetwork.html#1044 Majority of of internet-related exploits and vulnerability during the 90s were buffer-length related ... associated with C language programming enviornment misc. past posts http://www.garlic.com/~lynn/subintegrity.html#buffer that started to shift in this decade to transfer of network files that were executed containing malicious code (either automatic execution or social engineering prompting execution). I've done some word occurance analysis of internet theat vulnerability reports ... and advocated that the centers asked for categorization ... since the reports have been free-form making it more difficult to categorize. there were some of this kind of viruses in the 70s 80s on mainframes, both the internal network ... some internal network past posts http://www.garlic.com/~lynn/subnetwork.html#internalnet and bitnet/earn http://www.garlic.com/~lynn/subnetwork.html#bitnet lots of the financial stuff grew up in mainframe batch ... some past references/discussions (this from linkedin greater ibm) http://www.garlic.com/~lynn/2009o.html#51 8 ways the American information worker remains a Luddite and slightly older from year ago http://www.garlic.com/~lynn/2008p.html#27 Father of Financial Dataprocessing some amount of the transactions starting moving online during the 70s 80s ... but would only be partially be performed ... with the completion of process still being performed in mainframe batch (in overnight batch window). In the 90s, there were several large financial institutions that worked on leverage massive numbers of parallel killer micros to implement straight through processing for these online transactions (actually going to comletion). The issue was growing business and growing global business was putting extreme pressure on the overnight batch windows (more work decreasing size). However, the parallelization technology they were using added two orders of magnitude overhead (compared to the mainframe batch) ... completely swamping any anticipated thruput increase (several projects were billions into the efforts before doing any serious look at the speedsfeeds and then declared success and abandoned the efforts). On the other hand there was a lot of mainframe clustering, continuous availability and disaster survivability done in the 70s and early 80s ... that never made it out as product. For instance at the hillgang user group meeting yesterday ... they had presentation about new single-system-image cluster support for z/VM. We had done that in the mid-to-late 70s for the HONE system (world-wide online marketing and sales support) ... and in the early 80s, for US HONE datacenter in california, it was replicated in Dallas and then Boulder (three site, load-balancing, and fall-over). misc. past posts mentioning HONE http://www.garlic.com/~lynn/subtopic.html#hone Long ago and far away, my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture. She was responsible for peer-coupled architecture ... but because of very little response at the time (except for IMS hot-standby), she didn't stay long. http://www.garlic.com/~lynn/subnetwork.html#sharedata Later we started HA/CMP product with rs/6000s for both availability and cluster scaleup: http://www.garlic.com/~lynn/subtopic.html#hacmp reference to Jan92 meeting on cluster scaleup http://www.garlic.com/95.html#13 and some old email http://www.garlic.com/~lynn/lhwemail.html#medusa however, within a month of the Jan92 meeting, the cluster scaleup was transferred, we were told we couldn't work on anything with more than four processors ... and then there was announcement for (JUST) the numerical intensive marketplace: http://www.garlic.com/~lynn/2001n.html#6000clusters1 http://www.garlic.com/~lynn/2001n.html#6000clusters2 along with numerous others in these old posts: http://www.garlic.com/~lynn/2001n.html#70 http://www.garlic.com/~lynn/2001n.html#83 While we were out marketing ha/cmp, I coined the terms geographic survivability and disaster survivability (to differentiate from disaster recovery)I was also asked to write a section for the corporate continuous availability strategy document ... but it got pulled after both Rochester and POK
Re: big iron mainframe vs. x86 servers
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. l...@garlic.com (Anne Lynn Wheeler) writes: lots of the financial stuff grew up in mainframe batch ... some past references/discussions (this from linkedin greater ibm) http://www.garlic.com/~lynn/2009o.html#51 8 ways the American information worker remains a Luddite and slightly older from year ago http://www.garlic.com/~lynn/2008p.html#27 Father of Financial Dataprocessing re: http://www.garlic.com/~lynn/2009o.html#81 big iron mainframe vs. x86 servers ... at tandem, after leaving ibm, Jim did this study: Why Do Computers Stop and What Can Be Done About It? http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf from above: An analysis of the failure statistics of a commercially available fault-tolerant system shows that administration and software are the major contributors to failure. ... snip ... also ... Fault Tolerance in Tandem Computer Systems http://www.hpl.hp.com/techreports/tandem/TR-86.2.pdf from above: When the sources of faults are examined in detail, a surprising picture emerges: Faults come from hardware, software, operations, maintenance and environment in about equal measure. Hardware may go for two months without giving problems and software may be equally reliable. The result is a one month MTBF. When one adds in operator errors, errors during maintenance, and power failures the MTBF sinks below two-weeks. ... snip ... in the later part of the 90s, we spent some time with large financial transaction operation ... that had 100% availability so far in the decade. they attributed the 100% availability to: 1) IMS hot-standby 2) automated operator recent post about high i/o error (disk development) environment where MVS had MTBF of 15 minutes ... and I undertook to rewrite i/o supervisor to never fail ... also brought down the wrath of the MVS group for just referring to the MVS failure rate internally http://www.garlic.com/~lynn/2009o.html#17 Broken hardware was Re: Broken Brancher http://www.garlic.com/~lynn/2009o.html#31 Justice Department probing allegations of abuse by IBM in mainframe computer market other posts mentioning bldgs 14 (disk engineering) 15 (disk product test) http://www.garlic.com/~lynn/subtopic.html#disk -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
---snip-- Depending on the application and the OS, an Intel quad core high end might well match a z10 quad core for all but decimal arithmetic. How many z10s would it take to run the equivalent of 1500 blades linked in a cluster running google? unsnip- I've said it before and I'll say it again: Each platform has strengths and weaknesses. While the Intel x86 has a certain amount of strength over the z platform in raw compute power, the z platform does decimal arighmetic at speeds that the x86 platform can only dream about. Ditto for large amounts of I/O. Intel and AMD haven't even begun to match the speed of the z platform's channel architecture. What platform fits YOUR business needs best? Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman ---snip-- Depending on the application and the OS, an Intel quad core high end might well match a z10 quad core for all but decimal arithmetic. How many z10s would it take to run the equivalent of 1500 blades linked in a cluster running google? unsnip - I've said it before and I'll say it again: Each platform has strengths and weaknesses. While the Intel x86 has a certain amount of strength over the z platform in raw compute power, the z platform does decimal arighmetic at speeds that the x86 platform can only dream about. Ditto for large amounts of I/O. Intel and AMD haven't even begun to match the speed of the z platform's channel architecture. What platform fits YOUR business needs best? Viewing IT in toto as a business tool, I'd place the emphasis a word later: What platform fits your BUSINESS needs best? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
The big advantages of the IBM mainframe architecture have always been application upward compatibility, I/O throughput, and RAS (reliability, availability, and serviceability). Application upgrade compatibility requires both hardware instruction set upward compatibility and software system interface upward compatibility. Intel has made some significant strides in recent years in terms of hardware instruction set upward compatibility, but Microsoft's software system interface upward compatibility is a joke. Windows release boundaries have been invariably disastrous, and service packs have been little better. I/O throughput on z System z processor complex is second to zone. No PC I/O architecture can come close to the throughput exhibited by a small System z processor complex. A large System z processor complex is in a universe all its own. IBM RAS (reliability, availability, and serviceability), developed and evolved over 45 years, is second to none, and RAS is what keeps businesses in business. For sheer number crunching, I might pick an IBM Power[n] box. If I want to go on the cheap, I might pick an Intel box. For transactional processing involving vast databases, anything other than a System z processor complex is irresponsible. Give that staggering number of financial transactions processed on a daily basis, over 90% of which is done on large-scale IBM mainframes, is it not strange that you have never heard of a mainframe virus? IBM RAS and IBM Security (whether implemented via IBM RACF, CA ACF/2, CA-Top Secret Security, or some other External Security manager (ESM)) is what keep these systems running. John P. Baker -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John Sent: Wednesday, October 21, 2009 9:14 PM To: IBM-MAIN@bama.ua.edu Subject: Re: big iron mainframe vs. x86 servers Viewing IT in toto as a business tool, I'd place the emphasis a word later: What platform fits your BUSINESS needs best? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
How many Mainframe engines = 1500 x86 boxes? IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 10/19/2009 12:51:38 PM: Fairly nice article. Rather nicely balanced about the pluses of either environment. It's a slide show. http://www.eweek.com/c/a/IT-Infrastructure/Big-Iron-Mainframes-Versus-x86-Servers-What-You-Need-to-Know-332020/?kc=EWKNLEDP08202009A John McKown - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
That's a lot of hood ornaments. On Tue, Oct 20, 2009 at 11:13 AM, David Andrews d...@lists.duda.com wrote: How many Mainframe engines = 1500 x86 boxes? How many moving vans = 1500 motorcycles? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Talman How many Mainframe engines = 1500 x86 boxes? It depends. Could be as few as one. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
Interesting. I'd think the number could be less than one. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John Sent: Tuesday, October 20, 2009 1:16 PM To: IBM-MAIN@bama.ua.edu Subject: Re: big iron mainframe vs. x86 servers -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Talman How many Mainframe engines = 1500 x86 boxes? It depends. Could be as few as one. -jc- NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
How many Mainframe engines = 1500 x86 boxes? How many moving vans = 1500 motorcycles? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On Tue, Oct 20, 2009 at 11:39 AM, Kirk Talman rkueb...@tsys.com wrote: How many Mainframe engines = 1500 x86 boxes? How many Kenworth rigs = 1500 motorcycles? Depends on what you're trying to do. Hint: if it's February in Minneapolis, the number is a lot smaller than if it's August. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hal Merritt Sent: Tuesday, October 20, 2009 1:44 PM To: IBM-MAIN@bama.ua.edu Subject: Re: big iron mainframe vs. x86 servers Interesting. I'd think the number could be less than one. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John Sent: Tuesday, October 20, 2009 1:16 PM To: IBM-MAIN@bama.ua.edu Subject: Re: big iron mainframe vs. x86 servers -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Talman How many Mainframe engines = 1500 x86 boxes? It depends. Could be as few as one. -jc- In this case, I would bet it depends on what those x86 servers are doing. If they are a Beowulf supercomputer cluster, then the z10 is NOT going to beat it. But if they are Web servers? Or even application servers? Speaking of such. The z10 is said, by IBM, to be the fastest (clock time) CISC processor. So, does that mean that a single IFL processor could outperform any single x86 (Xeon?) single threaded processor around for something which is CPU intensive, such as numeric computation? To be fair, let us assume that this computation is being done in Java by using the identical .class file. I know that isn't fair since the JVMs are not identical. But it is about as fair as I can think of. Or perhaps the same C code compiled and run on Linux using the same version of GCC. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * 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(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
I asked because the pretty slide show linked to by the original post I replied to used that number (1500) on the 13th and last slide with no indication of scale factor or context. After 48 yrs in IT I have an appreciation for the issues raised by the replies, both explicit and implicit. I was wondering from the practical point of view. Where is the cross-over point where one considers z10 vs squatty box? on power? on space? on software licences? admin bodies? is the issue to complicated without doing a full tca/tco? This was on my mind because I have the misfortune to have inherited support of a mainframe application connected to a squatty box using custom code and a token ring conenction to the mainframe. every time it burps i get indigestion. replacing it means using smtp to replace telephony -- swapping one poisonous snake for another breed. As an aside, what is a good abbreviation for mainframe than m_f? I would like to reserve that for M$, Office and InfoPath at the moment. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 10/20/2009 02:54:30 PM: -Original Message- [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hal Merritt Interesting. I'd think the number could be less than one. [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Talman How many Mainframe engines = 1500 x86 boxes? It depends. Could be as few as one. In this case, I would bet it depends on what those x86 servers are doing. If they are a Beowulf supercomputer cluster, then the z10 is NOT going to beat it. But if they are Web servers? Or even application servers? Speaking of such. The z10 is said, by IBM, to be the fastest (clock time) CISC processor. So, does that mean that a single IFL processor could outperform any single x86 (Xeon?) single threaded processor around for something which is CPU intensive, such as numeric computation? To be fair, let us assume that this computation is being done in Java by using the identical .class file. I know that isn't fair since the JVMs are not identical. But it is about as fair as I can think of. Or perhaps the same C code compiled and run on Linux using the same version of GCC. John McKown - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On 20 Oct 2009 12:55:20 -0700, in bit.listserv.ibm-main you wrote: I asked because the pretty slide show linked to by the original post I replied to used that number (1500) on the 13th and last slide with no indication of scale factor or context. After 48 yrs in IT I have an appreciation for the issues raised by the replies, both explicit and implicit. I was wondering from the practical point of view. Where is the cross-over point where one considers z10 vs squatty box? on power? on space? on software licences? admin bodies? is the issue to complicated without doing a full tca/tco? Depending on the application and the OS, an Intel quad core high end might well match a z10 quad core for all but decimal arithmetic. How many z10s would it take to run the equivalent of 1500 blades linked in a cluster running google? This was on my mind because I have the misfortune to have inherited support of a mainframe application connected to a squatty box using custom code and a token ring conenction to the mainframe. every time it burps i get indigestion. replacing it means using smtp to replace telephony -- swapping one poisonous snake for another breed. As an aside, what is a good abbreviation for mainframe than m_f? I would like to reserve that for M$, Office and InfoPath at the moment. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 10/20/2009 02:54:30 PM: -Original Message- [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hal Merritt Interesting. I'd think the number could be less than one. [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Talman How many Mainframe engines = 1500 x86 boxes? It depends. Could be as few as one. In this case, I would bet it depends on what those x86 servers are doing. If they are a Beowulf supercomputer cluster, then the z10 is NOT going to beat it. But if they are Web servers? Or even application servers? Speaking of such. The z10 is said, by IBM, to be the fastest (clock time) CISC processor. So, does that mean that a single IFL processor could outperform any single x86 (Xeon?) single threaded processor around for something which is CPU intensive, such as numeric computation? To be fair, let us assume that this computation is being done in Java by using the identical .class file. I know that isn't fair since the JVMs are not identical. But it is about as fair as I can think of. Or perhaps the same C code compiled and run on Linux using the same version of GCC. John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
Um, the 13-slide show left me waiting for the information to start. I found it gossamer-thin, so lite that I believe it would struggle even to get into an airline magazine. take care all, Graeme At 02:51 AM 20/10/2009, you wrote: Fairly nice article. Rather nicely balanced about the pluses of either environment. It's a slide show. http://www.eweek.com/c/a/IT-Infrastructure/Big-Iron-Mainframes-Versus-x86-Servers-What-You-Need-to-Know-332020/?kc=EWKNLEDP08202009A John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * 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(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
big iron mainframe vs. x86 servers
Fairly nice article. Rather nicely balanced about the pluses of either environment. It's a slide show. http://www.eweek.com/c/a/IT-Infrastructure/Big-Iron-Mainframes-Versus-x86-Servers-What-You-Need-to-Know-332020/?kc=EWKNLEDP08202009A John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * 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(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: big iron mainframe vs. x86 servers
On 19 Oct 2009 09:52:48 -0700, john.mck...@healthmarkets.com (McKown, John) wrote: Fairly nice article. Rather nicely balanced about the pluses of either environment. It's a slide show. http://www.eweek.com/c/a/IT-Infrastructure/Big-Iron-Mainframes-Versus-x86-Servers-What-You-Need-to-Know-332020/?kc=EWKNLEDP08202009A Fair - but incomplete. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
