Re: Another BIG Mainframe Bites the Dust
On 12 Oct 2006 05:30:38 -0700, in bit.listserv.ibm-main you wrote: In [EMAIL PROTECTED], on 10/10/2006 at 10:26 PM, Ted MacNEIL [EMAIL PROTECTED] said: I moved from my Bell BlackBerry account to a YAHOO using POP3, in June, because RIM re-engineered their support making a REPLYTO mandatory for all BlackBerry ids. And you can't figure out how to include Reply-To: IBM Mainframe Discussion List [EMAIL PROTECTED] when you post to IBM-MAIN? Given that the majority of the messages that I reply to do not have the reply to set that way but rather are like Ted's, I suspect that it would be easier to have the listserv set it if it can. I read the newsgroup using Agent 4.0 and may well have an equally bad reply-to. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Saturday, 10/14/2006 at 07:01 ZW3, Clark F Morris [EMAIL PROTECTED] wrote: Given that the majority of the messages that I reply to do not have the reply to set that way but rather are like Ted's, I suspect that it would be easier to have the listserv set it if it can. I read the newsgroup using Agent 4.0 and may well have an equally bad reply-to. Your reply-to is fine. It points to the listserver. Alan Altmark z/VM Development IBM Endicott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REPLYTO problems (was RE: Another BIG Mainframe Bites the Dust)
In [EMAIL PROTECTED], on 10/11/2006 at 07:56 AM, Chase, John [EMAIL PROTECTED] said: It's possible, but I would vote against it. There are times when somebody might want to receive replies to a post off-list, and setting REPLYTO is the easiest way to accomplish that. That depends on the mail client. Some display both the From and the Reply-to address and let you select which to use. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
What a terrible thing to say about one's wife ! Talk about a CPU hog! Luckily, she doesn't read this list gr -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
In [EMAIL PROTECTED], on 10/10/2006 at 05:20 PM, Ward, Mike S [EMAIL PROTECTED] said: The thing that gets me is the MIPS. You can go from a machine that has a single processor at 100 mips. To a processor that has 4 cpus at 100 mips each and they call it 400 mips. Depending on you workload type that may not buy you anything and you are still chugging along with just more mips. What I would rather see is the actual cycle rate of the processor go up. Give me the mips 400 but with two processors at 200 mips each, or even 1 400 mip processor. That might be nice for some workloads, although it would be very bad for others. Either way, would you buy the 1 CPU 400 MIPS box if it cost 3 times as much as the 4 CPU 400 MIPS box? IBM has to balance the cost of making the processor faster against the cost of adding more processors. This mips rate is underrated unless you know the true meaning of mips. The true meaning of MIPS is that there is no true meaning of MIPS. It stands for millions of instructions per second, and you get drastically different numbers depending on what instruction mix you use. Worse, when you compare two different processor designs[1] you can't even say which is faster, never mind how much faster. [1] Say 3158 against 4341. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Tuesday, 10/10/2006 at 05:20 EST, Ward, Mike S [EMAIL PROTECTED] wrote: The thing that gets me is the MIPS. You can go from a machine that has a single processor at 100 mips. To a processor that has 4 cpus at 100 mips each and they call it 400 mips. Depending on you workload type that may not buy you anything and you are still chugging along with just more mips. What I would rather see is the actual cycle rate of the processor go up. Give me the mips 400 but with two processors at 200 mips each, or even 1 400 mip processor. This mips rate is underrated unless you know the true meaning of mips. You are hitting on exactly why we don't publish MIPS any more. It simply leads you down the proverbial garden path. You notice, too, we don't make a big deal about the cycle rate (GHz), either. Both are pretty much irrelevant in estimating the affect on your workload. And each generation of processors changes the mix of silicon, microcode, and millicode so you can't really depend on knowing how many cycles an instruction takes. Add pipelining into the mix and it gets worse. The best measurement of performance is the one you use to determine how much value you are getting from the box. You bought it for a reason. Are you getting the number of transactions per second from YOUR applications that you need to make the box worth the investment? Are you getting the qualities of service you require? Is it helping you meet your IT spending goals? Alan Altmark z/VM Development IBM Endicott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
forgive the history, but early in our marriage, my computer operator wife (how we met is another story) got a job with a small insurance co with a s/360-22 running some flavor of DOS (I think). She worked overnight, and she loaded the card read, submitted the jobs, and took out her novel. She was only there so that the printer or card reader jammed, she could fix it. Talk about a CPU hog! -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
I still like MIPS. I know, I'm getting old! I believe everything you say about MIPS being meaningless or whatever, but I still think that if you are looking at 3 or 4 models of CPUs, the MIPS rating gives you a good feel for how fast they are, especially if they are all in the same processor group. z/800 z/900 being one group, z890 z990 being a 2nd group etc. I would think that if you compared a 100 MIPs machine with a 400 MIPS machine in the same group, you should be able to get approximately 4 times the work out of the 400 MIPS machine. When I hear a box has so many MSUs, I still don't know what that means until I look up the MIPS. I know every time I go to an IBM presentation that contains new hardware, they still either have MIPS charts in their presentation, or they mention verbally how many MIPS the boxes are. I always thought that was kind of strange with their emphasis on MSUs, but then I think they realize that the term MIPS has been around much longer than MSUs, and most mainframe people have been around a long time. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee Wisconsin 414-475-7434 - Original Message - From: Alan Altmark [EMAIL PROTECTED] You are hitting on exactly why we don't publish MIPS any more. It simply leads you down the proverbial garden path. You notice, too, we don't make a big deal about the cycle rate (GHz), either. Both are pretty much irrelevant in estimating the affect on your workload. And each generation of processors changes the mix of silicon, microcode, and millicode so you can't really depend on knowing how many cycles an instruction takes. Add pipelining into the mix and it gets worse . Alan Altmark z/VM Development IBM Endicott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Thu, 2006-10-12 at 10:47 -0400, Alan Altmark wrote: The best measurement of performance is the one you use to determine how much value you are getting from the box. You bought it for a reason. Are you getting the number of transactions per second from YOUR applications that you need to make the box worth the investment? Are you getting the qualities of service you require? Is it helping you meet your IT spending goals? *bought* - that's past tense. Bit bloody late then. I always liked the idea of (customer) benchmarking. Run the customers workload on some new kit, and let them decide if it *really* is 1.8 times as good (or whatever is claimed) at delivering throughput. I'm talking real workload on real (o.k., these days semi-real) iron, not some simulated equivalent on a synthetic workload based on some ethereal typical job mix. Yeah I know it's expensive - but you can't argue with RMF. Also got me the odd trip to Cafilornia, but that's not strictly relevant ... ;-) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
What a terrible thing to say about one's wife ! -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Thursday, October 12, 2006 2:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust forgive the history, but early in our marriage, my computer operator wife (how we met is another story) got a job with a small insurance co with a s/360-22 running some flavor of DOS (I think). She worked overnight, and she loaded the card read, submitted the jobs, and took out her novel. She was only there so that the printer or card reader jammed, she could fix it. Talk about a CPU hog! -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com --- --- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
REPLYTO problems (was RE: Another BIG Mainframe Bites the Dust)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL As for the REPLYTO, there was a thread on it a while ago. I moved from my Bell BlackBerry account to a YAHOO using POP3, in June, because RIM re-engineered their support making a REPLYTO mandatory for all BlackBerry ids. 3 weeks ago, they did the same thing for all BlackBerry connected ids. I asked/begged/pleaded. They didn't care. I only have this problem with IBM-Main. All the other list serves I belong to do not honour the REPLYTO. They insert their own. Darren, is it possible to reconfigure IBM-Main to do that? It's possible, but I would vote against it. There are times when somebody might want to receive replies to a post off-list, and setting REPLYTO is the easiest way to accomplish that. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REPLYTO problems (was RE: Another BIG Mainframe Bites the Dust)
In a recent note, Chase, John said: Date: Wed, 11 Oct 2006 07:56:29 -0500 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL I only have this problem with IBM-Main. All the other list serves I belong to do not honour the REPLYTO. They insert their own. Darren, is it possible to reconfigure IBM-Main to do that? It's possible, but I would vote against it. There are times when somebody might want to receive replies to a post off-list, and setting REPLYTO is the easiest way to accomplish that. I much agree. In days of yore, the Usenet etiquette was to reply to the poster who courteously summarized replies. As you say this remains useful here; I've occasionally supplied a Reply-to on this list for that purpose. Don't break LISTSERV merely because some subscribers patronize broken mail services. Why have Reply-to at all if it's always set equal to From? (I know; there's the possibility of Reply-to mailbombing. I'm little moved by that argument.) I subscribe to one other list which never sets Reply-to; I know on that list to override the To: when I followup, even as I know to do so to Ted's posts on this list. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
I think that's the rub. How much can you afford in discretionary, if any. I played with disc. early on and found that since I different requirements for production batch workloads based on time zone and importance, and there was very little if any cycles left for test, I had to end up putting the test batch into a low importance service class where it would at least get some service over time. And like Ted I've worked for insurance companies who are mostly reluctant to get upgrades until absolutely necessary. I think you mention this. How many cycles are left after system support and program product tasks, production online and priority production batch are accounted for? If it becomes problematic to run disc., based on wait for CPU, you're left with a low importance service class for your test workloads. Mark Zelden [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 10/10/2006 05:47 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Another BIG Mainframe Bites the Dust Perhaps there was not enough discretionary work defined. Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsuti -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REPLYTO problems (was RE: Another BIG Mainframe Bites the Dust)
---snip-- Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL As for the REPLYTO, there was a thread on it a while ago. I moved from my Bell BlackBerry account to a YAHOO using POP3, in June, because RIM re-engineered their support making a REPLYTO mandatory for all BlackBerry ids. 3 weeks ago, they did the same thing for all BlackBerry connected ids. I asked/begged/pleaded. They didn't care. I only have this problem with IBM-Main. All the other list serves I belong to do not honour the REPLYTO. They insert their own. Darren, is it possible to reconfigure IBM-Main to do that? It's possible, but I would vote against it. There are times when somebody might want to receive replies to a post off-list, and setting REPLYTO is the easiest way to accomplish that. ---unsnip-- Or you can do what I usually do: make sure my address shows and simply request that replies be sent offlist. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REPLYTO problems (was RE: Another BIG Mainframe Bites the Dust)
In a message dated 10/11/2006 10:21:09 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Or you can do what I usually do: make sure my address shows and simply request that replies be sent offlist. And SPAM! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REPLYTO problems (was RE: Another BIG Mainframe Bites the Dust)
On Wed, 11 Oct 2006, Chase, John wrote: From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL Darren, is it possible to reconfigure IBM-Main to do that? It's possible, but I would vote against it. There are times when somebody might want to receive replies to a post off-list, and setting REPLYTO is the easiest way to accomplish that. -jc- And this is why I have it set this way. If someone wants to set a specific Reply-To: address, I want Listserv to leave it alone. Example: I send a post to the list asking how many people have had to reboot their Windows machine this week..please reply to me and not the list. I set a Reply-To: tag to point to my email address. I don't want the list flooded with me too! postings. To confuse matters, I have to make sure my mail client puts the correct Reply-To: tag in my outgoing email and the recipient's email client has to properly recognize my Reply-To: tag and handle it properly. Darren P.S. - If you all want, I can set Listserv to ignore any Reply-To tags for a week or so and see how things go. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Wed, 11 Oct 2006 10:08:23 -0400, [EMAIL PROTECTED] wrote: I think that's the rub. How much can you afford in discretionary, if any. I played with disc. early on and found that since I different requirements for production batch workloads based on time zone and importance, and there was very little if any cycles left for test, I had to end up putting the test batch into a low importance service class where it would at least get some service over time. I see this often but still just don't understand it. Say you have all this low important work with IMP=5 and some low velocity or percentile goal and you move it all to discretionary. The overall load on the system is the same and this workload should get serviced. This didn't work as well in the past as it does now, but changes over the years to how WLM manages discretionary work should allow it. Also, discretionary has the added benefit of MTTW. So I still try to put as much work as I can in discretionary. The biggest problem I had with discretionary work were the changes made to the WLM controlled initiator algorithms in z/OS 1.4 (obviously not a consideration if using JES2 inits). Since then there have been some PTFs to help this. What I did at the time (and still do) was to take that batch service class and add a 1st period with IMP=5 and a medium duration to help get the INITs started (WLM only looks at 1st period for starting INITs). This had a side benefit of getting the quick jobs out of the system if they could end while in 1st period. I used to do this in COMPAT mode for a couple of batch service classes but stopped this practice with WLM because of the (good) recommendations to try and keep around 25-30 or less in use periods on an LPAR. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REPLYTO problems (was RE: Another BIG Mainframe Bites the Dust)
On Wed, 11 Oct 2006, Rick Fochtman wrote: Or you can do what I usually do: make sure my address shows and simply request that replies be sent offlist. Unfortunately, Rick, that doesn't work. 99% hit reply, type their response and send. I know, from the amount of rejections I get from my excessive quote analyzer. We could always do a test and see! :-) Darren -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REPLYTO problems (was RE: Another BIG Mainframe Bites the Dust)
-snip--- Ed Finnel wrote: In a message dated 10/11/2006 10:21:09 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Or you can do what I usually do: make sure my address shows and simply request that replies be sent offlist. And SPAM! unsnip- Considering that I get hundreds of SPAMS per day anyhow, I've learned to use filters to filter out the important stuff. :-( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REPLYTO problems (was RE: Another BIG Mainframe Bites the Dust)
--snip--- Darren Evans-Young wrote: Much further snippage...And d this is why I have it set this way. If someone wants to set a specific Reply-To: address, I want Listserv to leave it alone. Example: I send a post to the list asking how many people have had to reboot their Windows machine this week..please reply to me and not the list. I set a Reply-To: tag to point to my email address. I don't want the list flooded with me too! postings. To confuse matters, I have to make sure my mail client puts the correct Reply-To: tag in my outgoing email and the recipient's email client has to properly recognize my Reply-To: tag and handle it properly. Darren P.S. - If you all want, I can set Listserv to ignore any Reply-To tags for a week or so and see how things go. ---unsnip PLEASE, Darren, don't change a thing! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: REPLYTO problems (was RE: Another BIG Mainframe Bites the Dust)
On 11 Oct 2006 08:34:33 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] wrote: In a message dated 10/11/2006 10:21:09 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Or you can do what I usually do: make sure my address shows and simply request that replies be sent offlist. And SPAM! Note my sig. AFAICT, the spam comes from the USENET mirror, rather than those subscribed. Putting one's address in human-readable form takes care of that problem. If the mirroring keeps the REPLY-TO, that will *increase* the probability of spam, not decrease it. Absence or presence of REPLY-TO affects differently those of us who read the list via USENET. If there's no REPLY-TO, TO is the munged e-mail address of the sender. Occasionally, someone posts with a REPLY-TO of the list, and that makes things easier. However, when someone has a REPLY-TO of their own address, I tend to think it was just a mistake in the munging (as occasionally happens) and change it to the list, anyway. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
2nd attempt - Ted's REPLYTO problem grabbed the 1st Ted For those reading this who do not have English as a mother tongue and are thus unfamiliar with English culture, I'll take this opportunity to explain Hobson's choice. It helps that (a) I used to teach to an audience of European students so I have a sensitivity to idiom and the like - and - (b) I used to sing on the site where Hobson kept his horses and lived on the site of the hostelry next door. In the early seventeenth century, Thomas Hobson rented out horses from some stables near to King's College in Cambridge next door to the institution known then as Katharine Hall and the George[1] Inn. The clientele for his horses, generally university folk, used to select some horses more than others and so Hobson's stock wasn't being used to the best advantage. To ensure that his horses were not overused or underused, Hobson arranged that the freshest horse was always nearest the stable door and insisted that this horse was chosen. Hence we have the expression Hobson's choice. Today I expect Hobson would be described as a work load manager. Apparently the Katharine Hall, renamed St Catharine's, college chapel was constructed on the site of Hobson's stables as part of the mid to late seventeen century rebuilding of the institution. Chris Mason [1] Somehow the building on this site became known as The Bull. One reference mentions that Hobson also ran a coach service from Cambridge to London and that his London terminus inn was called The Bull. Bull was the name of the terrible building housing the students' rooms in my time, now happily replaced by a modern building - although, being listed, the facade has been preserved. - Original Message - From: Ted MacNEIL [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, 10 October, 2006 11:58 PM Subject: Re: Another BIG Mainframe Bites the Dust ... Hobson's choice. ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
One of the most interesting points that he brought up was the CPU 100 percent busy. We all know that is not necessarily bad. I am not a perf cap person but am reasonably comfortable with running my system(s) at that . Now 20 year ago that was not the case but in all reasonably current MVS systems that is a reasonable thing to do. Well, some are proud to be able to use all resources they paid for, others are proud to only use 60% of what they paid for and are happy they're wasting 40% ;-) Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Hunkeler Peter (KIUK 3) wrote: One of the most interesting points that he brought up was the CPU 100 percent busy. We all know that is not necessarily bad. I am not a perf cap person but am reasonably comfortable with running my system(s) at that . Now 20 year ago that was not the case but in all reasonably current MVS systems that is a reasonable thing to do. Well, some are proud to be able to use all resources they paid for, others are proud to only use 60% of what they paid for and are happy they're wasting 40% ;-) And again - we hope, the Samsung mainframe was horribly oversized. Or they will need much more HP machines. Or they will have strong performance security problems. I simply don't believe that 7000MIPS datacenter grew up without real need (workload). -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
One of the most interesting points that he brought up was the CPU 100 percent busy. We all know that is not necessarily bad. I am not a perf cap person but am reasonably comfortable with running my system(s) at that . Now 20 year ago that was not the case but in all reasonably current MVS systems that is a reasonable thing to do. Not really. In order to get that famous 99.999% availability with a rock-solid SLA you need to run a data-sharing parallel sysplex -and- you need to leave some whitespace on each image so there is room to accommodate workload shifts for planned and unplanned system/application outages. If you don't do that and you lose an image (for whatever reason) you have a user perceived outage/loss of service and your 99.999 number goes poof or your SLA does. And if you're not in a parallel sysplex with data sharing you're never going to get close to those sort of numbers no matter what you do, even if you can make your SLA most of the time. Well, some are proud to be able to use all resources they paid for, others are proud to only use 60% of what they paid for and are happy they're wasting 40% ;-) I guess I'd be one of the happy ones wasting 40% Well, maybe not that much, but certainly a healthy chunk. A casual estimate for an n-way plex would be a bit less than 1/n spared per image, assuming you wanted the work of the failing/spared system to be picked up uniformly by the others. And again - we hope, the Samsung mainframe was horribly oversized. Or they will need much more HP machines. Or they will have strong performance security problems. I simply don't believe that 7000MIPS datacenter grew up without real need (workload). Did you read the Samsung guy's note? Samsung is a genuinely large business with real workloads. They made their decision to get off their mainframe for business reasons and it is a done deal. Their machines (plural) are sold, so it is safe to assume that whatever they're doing, they're really doing it on another platform (UNIX) just like they said they were. And apparently they're happier with the result. Their world did not come crashing down. We don't and can't know whether their mainframe systems were properly sized and effectively organized and run, but those questions are moot. That ought to be a cold shot of reality. Despite the mainframe's capabilities, there are significant downsides and not everyone is happy to accommodate those. As uncomfortable as it may be, the z ain't the king of the hill any more. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
As for the remarks from the gentleman from Samsung, very well written and explained without apologies. He said it worked for them. Now how many CEO's have seen that are contemplating the same thing? Could part of the fear of big iron be the age of the caretakers along with the burgeoning cost of the software needed to run them? If a company has a historical growth rate of 4% per annum and has to look at a major technology refresh in the processing area every 5-7 years (being generous there), then how long before they hit that plateau where the cost to sustain the system by personnel and software is truly onerous? I'd like to think there will be a mainframe somewhere to keep me fed until December 31, 2018, but is that realistic? Maybe not so much as in the 80's. Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 [EMAIL PROTECTED] If you aim at nothing you will hit it every time. - Zig Ziglar -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Not really. In order to get that famous 99.999% availability with a rock-solid SLA you need to run a data-sharing parallel sysplex -and- you need to leave some whitespace on each image so there is room to accommodate workload shifts for planned and unplanned system/application outages. You are wrong here. z/OS workloads usually include discretionary work that uses any idle CPU, but can be delayed when the CPU is needed for more productive work. Just because a system is 100% busy doesn't mean that it cannot take on additional work. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
You are wrong here. z/OS workloads usually include discretionary work that uses any idle CPU, but can be delayed when the CPU is needed for more productive work. Just because a system is 100% busy doesn't mean that it cannot take on additional work. Perhaps, but I count discretionary AS whitespace. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
But it's PRODUCTIVE whitespace (greyspace?) not idle as on other platforms where you can't run above 60% without jeopardizing the system. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Tuesday, October 10, 2006 8:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust You are wrong here. z/OS workloads usually include discretionary work that uses any idle CPU, but can be delayed when the CPU is needed for more productive work. Just because a system is 100% busy doesn't mean that it cannot take on additional work. Perhaps, but I count discretionary AS whitespace. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Veilleux, Jon L [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] com... Not really. In order to get that famous 99.999% availability with a rock-solid SLA you need to run a data-sharing parallel sysplex -and- you need to leave some whitespace on each image so there is room to accommodate workload shifts for planned and unplanned system/application outages. You are wrong here. z/OS workloads usually include discretionary work that uses any idle CPU, but can be delayed when the CPU is needed for more productive work. Just because a system is 100% busy doesn't mean that it cannot take on additional work. YOU are wrong there: workloads indeed *usually* include discretionary work that can be delayed, but do not need to: we don't have discretionary work. All work has goals and that is for several reasons. First: there is hardly any work that is submitted to the system and the user returns the next day to see how far it has come. Nearly all work is waited on, if some jobs take one or a few hours to complete, so be it, but the user useally expects it to finish within a reliable timeframe. Some work can be delayed more than other, but not for an indefinitely long period. Second: we have had quite a number of occasions where work that was denied access to the CPU for a long time (as discretionary or low IMP work does), caused all kinds of problems because of resources held by this work that were required by other, more important work. Examples vary from simple dataset enq's to USS processes not responding which generate kill-requests that are not responded to which cause limits to be exceeded, and Catalog access where CAS had a reserve outstanding on a catalog for a unit of work that did not progress because it seemed to be serviced by the priority of a low IMP job. All work has a minimal performance requirement and if batch is delayed an entire morning due to more important work, we have problems. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Mr Yoon: thank you for taking the time to give us this insight. IMHO, here is a key point. This was a well thought out business project. The extensive benchmarking tells me that their due diligence included all of the relevant issues. This was an expensive project to be sure. It so happens that the application suite, skill sets, and business mission were better served by the target platform rather than the z suite. Indeed, most argue that selection of a solution starts with the business need, then selection of a software suite but best fits that need. The platform is often dictated by the selected software suite. My $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock Sent: Monday, October 09, 2006 12:46 PM To: IBM-MAIN@BAMA.UA.EDU Subject: FW: Another BIG Mainframe Bites the Dust ..snip.. First of all, we did not embark on this project purely from a cost perspective. Of the three main criteria for our success - reliability, performance, and cost - the financial aspect was the least important. If, through our 18 months of benchmark testing of the various solutions available for rehosting, we felt that the reliability and performance was not viable, this project would have died a quiet death. ..snip.. 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
One of the most interesting points that he brought up was the CPU 100 percent busy. We all know that is not necessarily bad. I am not a perf cap person but am reasonably comfortable with running my system(s) at that . Now 20 year ago that was not the case but in all reasonably current MVS systems that is a reasonable thing to do. It's always been reasonable, at least in my case, since 1981. 100% busy, by itself, has never been an issue. The SRM/WLM combo has been designed to run your processor at that level. It's when service degrades, is the issue. My point, is why is he happy at 60%? *IX and windows don't like 'high' utilisation numbers. And, sometimes 'high' is 20%. When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
z/OS workloads usually include discretionary work that uses any idle CPU, but can be delayed when the CPU is needed for more productive work NOT in anyplace I worked at. If it's discretionary, it probably won't run. When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Tue, 2006-10-10 at 20:41 +, Ted MacNEIL wrote: NOT in anyplace I worked at. If it's discretionary, it probably won't run. FWIW *most* batch runs discretionary here. I've got some response-time goals on a couple dozen quick-turnaround jobs, but in general I just throw jobs at WLM and let it handle it. I get no complaints. (Yes, we have cycles to spare.) -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Tue, 10 Oct 2006 20:41:50 +, Ted MacNEIL [EMAIL PROTECTED] wrote: is needed for more productive work NOT in anyplace I worked at. If it's discretionary, it probably won't run. Since you say not in anyplace I worked at, did you set it up that way? Perhaps there was not enough discretionary work defined. I have been at shops were some LPARs are virtually 100% production CICS/DB2, so when you were at or near 100% - response time just got worse - period. No room for anything else to run (other than system support tasks). Is this a good way to run things in a modern well configured parallel sysplex environment? Of course not, but I think Chris talked about this in a recent thread. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Tue, 2006-10-10 at 07:44 +, Ted MacNEIL wrote: 100% busy, by itself, has never been an issue. The SRM/WLM combo has been designed to run your processor at that level. It's when service degrades, is the issue. My point, is why is he happy at 60%? *IX and windows don't like 'high' utilisation numbers. And, sometimes 'high' is 20%. Probably isn't the correct form, but is (tangentially) relevant here. A lot of this thinking seems to have evolved because there is no good way to control what is actually eating the machine. At least in Linux - one would have to think HP-UX on that sort of kit would have something. There are moves (and patchsets) coming onstream to provide workload management/isolation in the Linux environment. It sure ain't WLM but is the start of something. As is its wont in the Linux environment, these things come from several directions at once (resource groups versus clustering versus virtual server versus ...) but seems to be progressing. How much/what gets merged into the mainline kernel is being hammered out at present. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Since you say not in anyplace I worked at, did you set it up that way? Perhaps there was not enough discretionary work defined. Hobson's choice. Since 1981, I have worked for financial companies, a government ministry, IGS Canada, and a wholesaler with tight margins. We set it up that way because nobody wanted to spend the money on the upgrades. Anything set to discretionary did/does not run. We squeeze/squeezed every little IPS out and then wait(ed) for months for required upgrades to come in. Because of that, I have learned a lot of obscure tricks to make the SRM/WLM combo perform unnatural acts. I guess I've always gotten my job because people in the GTA know who I am, and what I can do. (Not that I'm bragging) GTA -- Greater Toronto Area When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Oct 10, 2006, at 2:44 AM, Ted MacNEIL wrote: One of the most interesting points that he brought up was the CPU 100 percent busy. We all know that is not necessarily bad. I am not a perf cap person but am reasonably comfortable with running my system(s) at that . Now 20 year ago that was not the case but in all reasonably current MVS systems that is a reasonable thing to do. It's always been reasonable, at least in my case, since 1981. 100% busy, by itself, has never been an issue. The SRM/WLM combo has been designed to run your processor at that level. It's when service degrades, is the issue. Ted, Back in the early 80s MVS 3.7, I believe (but cannot prove) the IPS and the dispatcher were not all together good at dispatching certain tasks. IIRC allocation was not getting dispatched properly and then got delayed causing allocation to back up, so work could not get through properly. I distinctly remember shooting several allocation (as well as our IBM PSR) issues. It was believed at the time that allocation was getting bumped to the bottom of the q for dispatching which lead to many interlocks. Its been 20 plus years so I don't remember the issues. Part of the issue was RTM not being able to cleanup properly and leaving the Q4 messed up. Yes we had many problems (sometimes as many as 10 stand alone dumps a day actually 20 one day). IBM was totally convinced that we needed a faster and bigger system (168MP) with (IIRC) 32 meg. Small by todays systems but back then respectable size. At the time there was no faster system and we had max memory. Ed PS: Please fix the replyto with your ISP. My point, is why is he happy at 60%? *IX and windows don't like 'high' utilisation numbers. And, sometimes 'high' is 20%. When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
The thing that gets me is the MIPS. You can go from a machine that has a single processor at 100 mips. To a processor that has 4 cpus at 100 mips each and they call it 400 mips. Depending on you workload type that may not buy you anything and you are still chugging along with just more mips. What I would rather see is the actual cycle rate of the processor go up. Give me the mips 400 but with two processors at 200 mips each, or even 1 400 mip processor. This mips rate is underrated unless you know the true meaning of mips. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Monday, October 09, 2006 10:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust On Oct 9, 2006, at 12:46 PM, Jon Brock wrote: As a follow-up to the recent Another BIG Mainframe Bites the Dust thread -- and apropos to a couple of other ongoing threads -- I received kind permission from Mr. Sangho Yoon to post on this listserv the following email he sent to me the other day. There is a lot to be ruminated upon in his note. Jon ---SNIP One of the most interesting points that he brought up was the CPU 100 percent busy. We all know that is not necessarily bad. I am not a perf cap person but am reasonably comfortable with running my system(s) at that . Now 20 year ago that was not the case but in all reasonably current MVS systems that is a reasonable thing to do. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Back in the early 80s MVS 3.7, I believe (but cannot prove) the IPS and the dispatcher were not all together good at dispatching certain tasks. I started in 1981 with SP1.0 (called SP1, then). The SRM had just been re-written. I remember the hub-bub over SRB service units and long running started tasks finally getting SMF4, SMF5, and SMF30 records. As for the REPLYTO, there was a thread on it a while ago. I moved from my Bell BlackBerry account to a YAHOO using POP3, in June, because RIM re-engineered their support making a REPLYTO mandatory for all BlackBerry ids. 3 weeks ago, they did the same thing for all BlackBerry connected ids. I asked/begged/pleaded. They didn't care. I only have this problem with IBM-Main. All the other list serves I belong to do not honour the REPLYTO. They insert their own. Darren, is it possible to reconfigure IBM-Main to do that? When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
To a processor that has 4 cpus at 100 mips each and they call it 400 mips. No, they don't. 4 CPU's at x MIPS do not give you 4X MIPS. The best you'll get is around 3.5X MIPS. If you trust what MIPS (don't) mean. When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Gentlemen, I have been reading this thread, as z-worker I am, too interested and worried about my job/future. Obviously I have been thinking: What the hell 7,000 mips the good man was talking about ? How were configurated his fabric ? It was one datacentre ? Have they 2 for DR purposes ? How many enviroments did they have ? How many Plexes ? There were any over sized ones ? Which DB/DC were been used ? You can say that a Corporation like that would have checked all those wasting aspects long ago before thinking any alternatives and starting finance analysis, but I would like to know some macro aspects a little deeper than 7000 mips were at 100% and were costing more 10 million bucks on 5-year period. All right, add x million contracts simulations by month (someone have said before). Anyhow, it is still somewhat 'vague', like my car was good enough, it did not fit to my usage. So I have bought a new one, a new brand X. I wish I have made myself clear, and I simply would like some data to understand what did happen. OK... their corporationthey do what they want, but, please, we are techs, we like data, graphs, vectors, trends, machine model/type, and, :) ...dumps. (sorry, couldn't resist) [Sorry to interrupt you guys] Best regards, Joao Carlos Rio de Janeiro - Brazil. PS: Soon I will be posting from my Blackberry too. Of course, by the seashore, in the sunset, over a cold beer. Then I will be able to understand these corporation subjects ITIS. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Thank you. * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Oct 9, 2006, at 12:46 PM, Jon Brock wrote: As a follow-up to the recent Another BIG Mainframe Bites the Dust thread -- and apropos to a couple of other ongoing threads -- I received kind permission from Mr. Sangho Yoon to post on this listserv the following email he sent to me the other day. There is a lot to be ruminated upon in his note. Jon ---SNIP One of the most interesting points that he brought up was the CPU 100 percent busy. We all know that is not necessarily bad. I am not a perf cap person but am reasonably comfortable with running my system(s) at that . Now 20 year ago that was not the case but in all reasonably current MVS systems that is a reasonable thing to do. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
In [EMAIL PROTECTED], on 09/11/2006 at 03:59 PM, Clark F Morris [EMAIL PROTECTED] said: I remember the 301, 3301 and 501. What was the 601? 24-bit instructions in 48-bit (plus parity and tags) word. Multilevel indexing and indirect addressing. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
In [EMAIL PROTECTED], on 09/10/2006 at 09:09 AM, Clark F Morris [EMAIL PROTECTED] said: What models and was it other than just data and instruction? Burroughs: B6500, B6700, B7500, B7800, etc. The tag bits constrained how a word was interpreted for both data and instructions. RCA: CDP, 601. The tag bits were under programmer control and had no effect on the interpretation of words, other than triggering an interrupt and being testable. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On 11 Sep 2006 09:01:16 -0700, in bit.listserv.ibm-main you wrote: In [EMAIL PROTECTED], on 09/10/2006 at 09:09 AM, Clark F Morris [EMAIL PROTECTED] said: What models and was it other than just data and instruction? Burroughs: B6500, B6700, B7500, B7800, etc. The tag bits constrained how a word was interpreted for both data and instructions. RCA: CDP, 601. The tag bits were under programmer control and had no effect on the interpretation of words, other than triggering an interrupt and being testable. I remember the 301, 3301 and 501. What was the 601? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Uh Oh! The dreaded ancient computer history thread has evolved again. And to think that I started it too. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee Wisconsin 414-475-7434 - Original Message - From: Clark F Morris [EMAIL PROTECTED] Burroughs: B6500, B6700, B7500, B7800, etc. The tag bits constrained how a word was interpreted for both data and instructions. RCA: CDP, 601. The tag bits were under programmer control and had no effect on the interpretation of words, other than triggering an interrupt and being testable. I remember the 301, 3301 and 501. What was the 601? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Telefunken TR4 and TR440, which had two tag bits for each 48 bit word of storage. The bits where represented in the registers, too. The meaning was 0 - binary floating point 1 - binary fixed point 2 - instructions 3 - other, like decimal or char Some instructions, like Load (in German: B = Bringe) worked different for fixed point and floating point, for example. If you tried to do a binary fixed arithmetic instruction on a word with tag (Typenkennung) = 2 or 3, a special kind of ABEND occured (Typenkennungs-Alarm). So it was good practice to initialize all dynamic storage with Typenkennung = 2 or 3. But you could modify machine instructions as in every other architecture, but only with the correct instructions. Modification was normally not done in storage, but when fetching the instruction, a modificator value from the previous instructions was (optionally) added. And there was even an instruction like EX on 360 to execute instructions at arbitrary places in storage, and these instruction also were allowed to have Typenkennung 0 or 1. Instructions normally were placed in read-only storage. Kind regards Bernd Am Sonntag, 10. September 2006 14:09 schrieben Sie: On 9 Sep 2006 22:02:52 -0700, in bit.listserv.ibm-main you wrote: In [EMAIL PROTECTED], on 09/08/2006 at 06:11 PM, Bernd Oppolzer [EMAIL PROTECTED] said: BTW, on older machines (not IBM) there were concepts like storage tags, which allowed to detect the use of uninitialized variables even for binary values. I don't understand why these concepts never reached the market. They did: Burroughs, now part of Unisys. RCA. Probably others as well. What models and was it other than just data and instruction? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On 9 Sep 2006 22:02:52 -0700, in bit.listserv.ibm-main you wrote: In [EMAIL PROTECTED], on 09/08/2006 at 06:11 PM, Bernd Oppolzer [EMAIL PROTECTED] said: BTW, on older machines (not IBM) there were concepts like storage tags, which allowed to detect the use of uninitialized variables even for binary values. I don't understand why these concepts never reached the market. They did: Burroughs, now part of Unisys. RCA. Probably others as well. What models and was it other than just data and instruction? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
In [EMAIL PROTECTED], on 09/08/2006 at 06:11 PM, Bernd Oppolzer [EMAIL PROTECTED] said: BTW, on older machines (not IBM) there were concepts like storage tags, which allowed to detect the use of uninitialized variables even for binary values. I don't understand why these concepts never reached the market. They did: Burroughs, now part of Unisys. RCA. Probably others as well. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Veilleux, Jon L Sent: Friday, September 08, 2006 7:17 AM To: IBM-MAIN@BAMA.UA.EDU Subject: FW: Another BIG Mainframe Bites the Dust REXX is the gold standard for decimal arithemtic but since it is interpreted it is slower than COBOL. snip Of the Iron Pyrite family? ;-) Later, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Im my opinion, there is one true fact about mainframe stability and decimal arithmetic. I'm not talking about hardware and so on, maybe the MFs are more stable than the other platforms. But software: the use of packed decimal arithmetic leads to more stable software, because not every bit representation in storage is a valid decimal number. In fact, for a decimal number of length, say, six bytes, it is very unlikely to find a valid representation if you look at some arbitrary six bytes in storage (less than 0.001). So most uses of uninitialized packed decimal fields will be detected in the test stage of the application, which is not true for applications using only binary numbers. This is, in my opinion, one of the top reasons why mainframe (application) software appears to be stable and reliable (use of uninitialized storage flagged by 0C7 with high probability). You get much more security, this way, but you have to pay a performance price for it (not much). BTW, on older machines (not IBM) there were concepts like storage tags, which allowed to detect the use of uninitialized variables even for binary values. I don't understand why these concepts never reached the market. This would make software development and testing easier and maybe cheaper. Kind regards Bernd Am Freitag, 8. September 2006 01:16 schrieben Sie: Ooops, I had too many brief statements. What I was trying to say was: 1. Even a mainframe can be insecure and unreliable if the facilities aren't used properly. The application has to use the security facilities in order to be secure. Thus the application (or the system installation process or the security administration) may be the least reliable component. 2. I am saying that COBOL is required to deliver the same results on decimal arithmetic regardless of platform and presence or absence of decimal arithmetic on that platform. Thus the HP Superdomes in this case should still get the same results in any given computation if compatible compiler options are chosen to match what was done on the z series. 3. Packed decimal arithmetic is much slower than binary on the z series. True decimal arithmetic becomes even more painful compute time wise on those platforms that don't have a decimal arithmetic instruction set. The greater speed of the other processors offsets this to at least some extent. Or something else? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
McKown, John wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thompson, Steve (SCI TW) Sent: Wednesday, September 06, 2006 4:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust snip I just wonder if they will experience the quarter closing where it takes 3-10 times longer than predicted. And then that first year end closing... Another thing I wonder about is, well, will they have rounding issues because of floating point? Or will they have issues with fixed point binary and rounding? [...] And we will never, ever know. No company will admit to a mistake of this magnitude, if indeed it turns out to be so. Too much liability in a sue-happy world. Perhaps S. Korea is not as sue-happy as the US. I hope not. Maybe we won't know the details, the horror stories from administration room. However we will see if the company survive. There are companies which got rid of mainframe and survived. It is possible. Sometimes it can be profitable (less costly). Of course we can still suspect (or rather hope): what about security, do they need more staff, maybe they were oversized very much (are YOU oversized???), maybe their application was horribly inefective, maybe they will have problems with EOQ/EOY, maybe they have problem with response times, etc. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
I find it strange that IBM has been trumpeting z/Linux, and something like this happens - on HP/UX. The homepage trumpets that they were showing Openframe (on Fujitsu kit) at LinuxWorld. Somebody juggling the balls at IBM seems to have dropped one. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
This bit stood out the most for me: According to Sangho Yoon, director of the information strategy team at Samsung, the decision to move off Big Iron was strictly financial. Moving their data warehousing and reporting systems to a superdome would make some sense, but I would think reliability and security would be the top priority for their operational systems. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Thursday, September 07, 2006 10:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust Maybe we won't know the details, the horror stories from administration room. However we will see if the company survive. There are companies which got rid of mainframe and survived. It is possible. Sometimes it can be profitable (less costly). Of course we can still suspect (or rather hope): what about security, do they need more staff, maybe they were oversized very much (are YOU oversized???), maybe their application was horribly inefective, maybe they will have problems with EOQ/EOY, maybe they have problem with response times, etc. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Here are some more of our friends: http://www.mainframemigration.org/ JC This bit stood out the most for me: According to Sangho Yoon, director of the information strategy team at Samsung, the decision to move off Big Iron was strictly financial. Moving their data warehousing and reporting systems to a superdome would make some sense, but I would think reliability and security would be the top priority for their operational systems. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Thursday, September 07, 2006 10:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust Maybe we won't know the details, the horror stories from administration room. However we will see if the company survive. There are companies which got rid of mainframe and survived. It is possible. Sometimes it can be profitable (less costly). Of course we can still suspect (or rather hope): what about security, do they need more staff, maybe they were oversized very much (are YOU oversized???), maybe their application was horribly inefective, maybe they will have problems with EOQ/EOY, maybe they have problem with response times, etc. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html John Cassidy (Dipl.-Ingr.) Berninastrasse 9 8057 Zuerich Europe Telephone: +41 (0) 43 300 4602 Mobile:+41 (0) 79 207 3268 E-Mail: [EMAIL PROTECTED] http://www.JDCassidy.net http://www.europeunited.org http://en.wikipedia.org/wiki/Europe_United -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Lindy Mayfield wrote: This bit stood out the most for me: According to Sangho Yoon, director of the information strategy team at Samsung, the decision to move off Big Iron was strictly financial. Moving their data warehousing and reporting systems to a superdome would make some sense, but I would think reliability and security would be the top priority for their operational systems. Maybe they claim RAS (reliablility, availability, security) is unaffecetd. I'm sure they claim so. Maybe they also believe it. Maybe RAS is really unaffected, or affected at very little degree. *Acceptable* degree. You don't need the best, you need good enough. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Thu, 7 Sep 2006 10:20:21 -0300, Clark F Morris [EMAIL PROTECTED] wrote: Reliability is based on the least reliable component. COBOL is required to generate code that correctly (if slowly) handles decimal what??? Are you saying that COBOL code is unreliable? that only cobol can generate decimal arithmetic? that packed decimal arithmetic is slow? Or something else? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
I don't hope they have problems, but I do expect that things will require a long time to settle down. I would also be willing to bet that the xpected cost savings will not materialize, at least to the degree envisioned. It may have been the right business decision, or it may not. Even if the business survives, as I imagine it will, it will take a while to tell whether it gives the payback they are counting on. I would love to be privy to that information, just for the sake of my own curiosity. It's an interesting situation. To paraphrase someone else from the list, IBM mainframe hardware is gone from that installation, and chances are that it ain't coming back. It is never good to be complacent regarding the presumed superiority of a computer platform. Jon snip Maybe we won't know the details, the horror stories from administration room. However we will see if the company survive. There are companies which got rid of mainframe and survived. It is possible. Sometimes it can be profitable (less costly). /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Hear, hear buy that man a beer! [EMAIL PROTECTED] 9/7/2006 11:03 AM I don't hope they have problems, but I do expect that things will require a long time to settle down. I would also be willing to bet that the xpected cost savings will not materialize, at least to the degree envisioned. It may have been the right business decision, or it may not. Even if the business survives, as I imagine it will, it will take a while to tell whether it gives the payback they are counting on. I would love to be privy to that information, just for the sake of my own curiosity. It's an interesting situation. To paraphrase someone else from the list, IBM mainframe hardware is gone from that installation, and chances are that it ain't coming back. It is never good to be complacent regarding the presumed superiority of a computer platform. Jon snip Maybe we won't know the details, the horror stories from administration room. However we will see if the company survive. There are companies which got rid of mainframe and survived. It is possible. Sometimes it can be profitable (less costly). /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
You are showing your MF bias. Many believe that occasional outages and reduced security levels are not only acceptable, but are to be expected. Most of us know that the cost of availability rises exponentially as you approach 100% on any platform. The selection of a availability percentage (and therefore how much to spend) is a business decision. There are many business cases where even prime time outages are very acceptable. For example, only two of our 12 LPARS has any availability SLA. My $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lindy Mayfield Sent: Thursday, September 07, 2006 4:50 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust This bit stood out the most for me: According to Sangho Yoon, director of the information strategy team at Samsung, the decision to move off Big Iron was strictly financial. Moving their data warehousing and reporting systems to a superdome would make some sense, but I would think reliability and security would be the top priority for their operational systems. 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Veilleux, Jon L Sent: Thursday, September 07, 2006 11:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: FW: Another BIG Mainframe Bites the Dust I suppose that next you will be telling us that outages are not only expected, but are desirable! Jon L. Veilleux Well, of course outages are desirable! Imagine having to put in a full day of work with no breaks for an outage. Why, the amount of RSI claims will sky rocket! The BSOD is just Microsoft's way of making sure that your health is protected from excessive, consecutive hours of work. Besides, the computer is broke again is a favored excuse that is acceptable to both management and clients! And excuses the worker from any responsibility. Loverly! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
I think a lot of it boils back down to what is needed. I'm not a huge fan of server technology (20,000 chickens pulling a plow) but since we don't run PROFS any longer, Locust notes is how I do e-mail. It might be that vendor pricing is in the mix big time (I haven't read the article) or that the mainframe is still seen as old technology with nowhere to grow. Did IBM-Korea do due diligence in trying to avoid this? Maybe the company wanted a now and happening appearance and this fit the bill. Quien sabe! Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
No, but he is making the very valid point that achiving 100% uptime may not be fiscally sound. If it costs me $10 million to go from 99.9% to 99.999% availability but it only buys me $1 million dollars worth of business, why would I pay that money? There is a problem when it comes to determining how much a given amount of downtime costs, but if you can get that figured out, you should be able to make a reasonable business decision as to which direction to go. Of course, there is always the matter of whether either solution achieves the goals set for it, but we don't have enough information to be able to speak to that with certainty. Jon snip I suppose that next you will be telling us that outages are not only expected, but are desirable! /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Well, of course outages are desirable! Imagine having to put in a full day of work with no breaks for an outage. Why, the amount of RSI claims will sky rocket! The BSOD is just Microsoft's way of making sure that your health is protected from excessive, consecutive hours of work. Besides, the computer is broke again is a favored excuse that is acceptable to both management and clients! And excuses the worker from any responsibility. Loverly! So CICS takes a few minutes bog time to process an abended transaction and the phones light up. My former POE once took a week to fully rebuild and restore an email server, and that was acceptable. If you drive a Mercedes, then, it shouldn't stop unexpectedly while your Chevy Aveo can stop once a day and have to be restarted? Cow muffins as Col. Potter would say. Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Daniel A. McLaughlin Sent: Thursday, September 07, 2006 12:02 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust snip So CICS takes a few minutes bog time to process an abended transaction and the phones light up. My former POE once took a week to fully rebuild and restore an email server, and that was acceptable. If you drive a Mercedes, then, it shouldn't stop unexpectedly while your Chevy Aveo can stop once a day and have to be restarted? Cow muffins as Col. Potter would say. Daniel McLaughlin Did I forget the sarcasm tags yet again? GRIN -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
In a message dated 9/7/2006 12:02:12 P.M. Central Standard Time, [EMAIL PROTECTED] writes: If you drive a Mercedes, then, it shouldn't stop unexpectedly while your Chevy Aveo can stop once a day and have to be restarted? Cow muffins as Col. Potter would say. So much for homilies: _http://www.cnn.com/2006/AUTOS/06/14/pricey_lemon/index.html_ (http://www.cnn.com/2006/AUTOS/06/14/pricey_lemon/index.html) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] writes: I think a lot of it boils back down to what is needed. I'm not a huge fan of server technology (20,000 chickens pulling a plow) but since we don't run PROFS any longer, Locust notes is how I do e-mail. recent posts about some early 2-tier (mainframe) operations ... justifying server plus distributed operation http://www.garlic.com/~lynn/2006p.html#40 25th Anniversary of the Personal Computer some of the other posts in the thread on early evoluation of 2-tier 3-tier computing http://www.garlic.com/~lynn/2006p.html#31 25th Anniversary of the Personal Computer http://www.garlic.com/~lynn/2006p.html#34 25th Anniversary of the Personal Computer http://www.garlic.com/~lynn/2006p.html#36 25th Anniversary of the Personal Computer http://www.garlic.com/~lynn/2006p.html#39 25th Anniversary of the Personal Computer lots of collected past postings on 3-tier computing http://www.garlic.com/~lynn/subnetwork.html#3tier espeically during the hey day of SAA when we were out doing customer executive presentations on 3-tier ... and lots of SAA was much more oriented towards the preservation of the terminal emulation paradigm http://www.garlic.com/~lynn/subnetwork.html#emulation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On 7 Sep 2006 06:43:00 -0700, in bit.listserv.ibm-main you wrote: On Thu, 7 Sep 2006 10:20:21 -0300, Clark F Morris [EMAIL PROTECTED] wrote: Reliability is based on the least reliable component. COBOL is required to generate code that correctly (if slowly) handles decimal what??? Are you saying that COBOL code is unreliable? that only cobol can generate decimal arithmetic? that packed decimal arithmetic is slow? Ooops, I had too many brief statements. What I was trying to say was: 1. Even a mainframe can be insecure and unreliable if the facilities aren't used properly. The application has to use the security facilities in order to be secure. Thus the application (or the system installation process or the security administration) may be the least reliable component. 2. I am saying that COBOL is required to deliver the same results on decimal arithmetic regardless of platform and presence or absence of decimal arithmetic on that platform. Thus the HP Superdomes in this case should still get the same results in any given computation if compatible compiler options are chosen to match what was done on the z series. 3. Packed decimal arithmetic is much slower than binary on the z series. True decimal arithmetic becomes even more painful compute time wise on those platforms that don't have a decimal arithmetic instruction set. The greater speed of the other processors offsets this to at least some extent. Or something else? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
On Thu, 7 Sep 2006 20:16:09 -0300, Clark F Morris [EMAIL PROTECTED] wrote: 2. I am saying that COBOL is required to deliver the same results on decimal arithmetic regardless of platform and presence or absence of decimal arithmetic on that platform. Thus the HP Superdomes in this case should still get the same results in any given computation if compatible compiler options are chosen to match what was done on the z series. Maybe so. I don't know, but I'm skeptical. Is there no other language that can be run on z/OS and the HP that will perform proper decimal arithmetic? 3. Packed decimal arithmetic is much slower than binary on the z series. True decimal arithmetic becomes even more painful compute time wise on those platforms that don't have a decimal arithmetic instruction set. The greater speed of the other processors offsets this to at least some extent. Is it? Again, I don't know how the speed of packed decimal arithmetic compares to binary on a z/Architecture box. However, when you look at all the other instructions in a typical DP application, the amount of time spent doing arithmetic as a very small percentage. Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
running nix servers w/o admins. that's an interesting thought. probably too much face involved for someone to do before/after TCO. IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/06/2006 03:27:07 PM: A 7,000 MIPS mainframe in Korea was recently replaced by Unix Boxes. See: http://searchdatacenter.techtarget.com/originalContent/0,289142, sid80_gci1214459,00.html?track=NL-576ad=563693asrc=EM_NLT_514124uid=1718791 Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee Wisconsin 414-475-7434 - 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. The information may also constitute a legally privileged confidential communication. 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Yeah, I saw that comment too, about running HP-UX without admins. I support both a superdome and the mainframe (z9BC) here - and the 'dome is physically twice the size of the z9, as well as taking more of my time to support than z/OS. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Talman Sent: Wednesday, September 06, 2006 3:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust running nix servers w/o admins. that's an interesting thought. probably too much face involved for someone to do before/after TCO. IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/06/2006 03:27:07 PM: A 7,000 MIPS mainframe in Korea was recently replaced by Unix Boxes. See: http://searchdatacenter.techtarget.com/originalContent/0,289142, sid80_gci1214459,00.html?track=NL-576ad=563693asrc=EM_NLT_514124uid=1 718791 Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee Wisconsin 414-475-7434 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R. Sent: Wednesday, September 06, 2006 3:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust Yeah, I saw that comment too, about running HP-UX without admins. I support both a superdome and the mainframe (z9BC) here - and the 'dome is physically twice the size of the z9, as well as taking more of my time to support than z/OS. Rex I did not read it that way. I read it as the cost of the z/OS people is part of the savings. I read mainframe operators, admins or system programmers as prefixing all those jobs with the word mainframe. Not that there were no HP-UX sysadmins. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
Isn't that what makes the open systems stuff so good, no people...;-) Thanks, Fletch Yeah, I saw that comment too, about running HP-UX without admins. I support both a superdome and the mainframe (z9BC) here - and the 'dome is physically twice the size of the z9, as well as taking more of my time to support than z/OS. Rex I did not read it that way. I read it as the cost of the z/OS people is part of the savings. I read mainframe operators, admins or system programmers as prefixing all those jobs with the word mainframe. Not that there were no HP-UX sysadmins. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Talman Sent: Wednesday, September 06, 2006 3:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust running nix servers w/o admins. that's an interesting thought. probably too much face involved for someone to do before/after TCO. snip Yeah, another Emperor has new clothes and you better be able to see 'em story. [Remember, the beatings will stop when the morale improves.] I just wonder if they will experience the quarter closing where it takes 3-10 times longer than predicted. And then that first year end closing... Another thing I wonder about is, well, will they have rounding issues because of floating point? Or will they have issues with fixed point binary and rounding? I guess we can watch and wonder if the same thing will happen with them that happened with HP when they announced getting rid of mainframes I understand they have consolidated back to a mainframe type system. Later, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
We will likely never know. If they do decide they made a mistake, there will be no percentage in publicizing the fact. Jon snip I just wonder if they will experience the quarter closing where it takes 3-10 times longer than predicted. And then that first year end closing... Another thing I wonder about is, well, will they have rounding issues because of floating point? Or will they have issues with fixed point binary and rounding? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thompson, Steve (SCI TW) Sent: Wednesday, September 06, 2006 4:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust snip I just wonder if they will experience the quarter closing where it takes 3-10 times longer than predicted. And then that first year end closing... Another thing I wonder about is, well, will they have rounding issues because of floating point? Or will they have issues with fixed point binary and rounding? snip Later, Steve Thompson And we will never, ever know. No company will admit to a mistake of this magnitude, if indeed it turns out to be so. Too much liability in a sue-happy world. Perhaps S. Korea is not as sue-happy as the US. I hope not. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another BIG Mainframe Bites the Dust
I would question some of the claims being made on the Tmaxsoft website http://www.tmaxsoft.com/news/news/2006_08_02.shtml 1 second improvement in online response time, 'improved' security? That said - it is another customer gone and like the 'dodo' will probably never come back! James F. Smith -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: 07 September 2006 04:19 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R. Sent: Wednesday, September 06, 2006 3:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another BIG Mainframe Bites the Dust Yeah, I saw that comment too, about running HP-UX without admins. I support both a superdome and the mainframe (z9BC) here - and the 'dome is physically twice the size of the z9, as well as taking more of my time to support than z/OS. Rex I did not read it that way. I read it as the cost of the z/OS people is part of the savings. I read mainframe operators, admins or system programmers as prefixing all those jobs with the word mainframe. Not that there were no HP-UX sysadmins. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
