Re: z/OS 1.8 reliability question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples Sent: Wednesday, April 25, 2007 5:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.8 reliability question If you're up to z/OS 1.5 or better then you could always set up an LPAR for z/OS 1.8 any time you wish (assuming you've got any necessary maintenance on the 1.5 LPAR). There's no single version charge clock to worry about, so no harm no foul. If you're on 1.7 then you can sign up for the early 1.9 program and have a very fun LPAR going. - - - - - Timothy Sipples I thought the clock started when I first ordered 1.8. I.e. order 1.8 on ??? and you'd better be off of 1.6 by ???+nnn days (or whatever). I will admit that I've never had to work with marketting much, so I don't know the rules about this sort of thing. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: z/OS 1.8 reliability question
On Wed, 25 Apr 2007 07:30:52 -0500, McKown, John [EMAIL PROTECTED] wrote: I thought the clock started when I first ordered 1.8. I.e. order 1.8 on ??? and you'd better be off of 1.6 by ???+nnn days (or whatever). I will admit that I've never had to work with marketting much, so I don't know the rules about this sort of thing. The clock matters for new versions, not new releases. Both are z/OS V1. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ 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: z/OS 1.8 reliability question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Wednesday, April 25, 2007 8:07 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.8 reliability question On Wed, 25 Apr 2007 07:30:52 -0500, McKown, John [EMAIL PROTECTED] wrote: I thought the clock started when I first ordered 1.8. I.e. order 1.8 on ??? and you'd better be off of 1.6 by ???+nnn days (or whatever). I will admit that I've never had to work with marketting much, so I don't know the rules about this sort of thing. The clock matters for new versions, not new releases. Both are z/OS V1. Mark Thanks. I must have been remembering the clock from our CICS/TS 1.3 to 2.3 conversion. We don't do all that well with clocks around here, at times. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: z/OS 1.8 reliability question
One of the good intangibles about z/OS (and, MVS/ESA, and MVS/XA, and.. ) reliability is that when you call support with a problem, they usually work on the problem. With those other guys and even with some vendors on z/OS who code on other platforms and then port to z/oS, you often spend the first day or two convincing them that there *is* a problem and that the problem *is* in their code.IBM's mainframe support, on the other hand, usually assumes that you are *not* a clueless person and that when you call, a problem *does* exist.While it's hard to measure, I do believe that this contributes to a faster problem resolution cycle and therefore improved reliability. Thanks, IBM support crew - wherever you are now. Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 -- 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: z/OS 1.8 reliability question
Tim Hare wrote: One of the good intangibles about z/OS (and, MVS/ESA, and MVS/XA, and.. ) reliability is that when you call support with a problem, they usually work on the problem. With those other guys and even with some vendors on z/OS who code on other platforms and then port to z/oS, you often spend the first day or two convincing them that there *is* a problem and that the problem *is* in their code.IBM's mainframe support, on the other hand, usually assumes that you are *not* a clueless person and that when you call, a problem *does* exist.While it's hard to measure, I do believe that this contributes to a faster problem resolution cycle and therefore improved reliability. It goes _much_ further than that... *We* have a culture that focuses on post-mortem analysis -- probably because we grew up with batch processing. Our processes involves making the system and infrastructure code capable of capturing as much useful information as possible at the time of a failure. An SVC dump contains storage, state information, system trace, etc. IPCS provides formatters for system data and a programmable infrastructure for creating/inserting our own. *They* have a culture of attempting to reproduce errors on a development machine with a debugger present -- a system that simply cannot find subtle, timing- or location-dependent, or environmental errors ... plain and simple. I have seen dumps being taken on other platforms (e.g., Windows). But, I have yet to find a programmer that knows how read one. :-( -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.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: z/OS 1.8 reliability question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Wednesday, April 25, 2007 2:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.8 reliability question snip *They* have a culture of attempting to reproduce errors on a development machine with a debugger present -- a system that simply cannot find subtle, timing- or location-dependent, or environmental errors ... plain and simple. I have seen dumps being taken on other platforms (e.g., Windows). But, I have yet to find a programmer that knows how read one. :-( -- Edward E Jaffe Very true. When the let's go to Windows! crowd was here, we in Tech Services were allowed to ask questions of the vendors who were going to do the conversion and post-conversion support. One of our questions was along the lines of: It is 2 am and a report job just terminated with errors. What do we do? The answer was along the lines of: Recompile the application with debugging information. Now have the programmer do a single step until the error reoccurs. Our subsequent question was something like: The process had run for 3 hours at full speed before the error occurred. Do you have an estimate of how long the process would need to run with the programmer single-stepping through it to reach the same point in its processing? Dead silence. The entire mind set of the convert-now team was that batch was not needed anymore. If a report was needed, the user would simply do an ad hoc request to get it. Nothing said about the fact that this doesn't work for printing insurance policies. When we do this, we can print thousands at a time. Again, being in insurance, there are BIG PENALITIES for not getting things done in a timely manner. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
z/OS 1.8 reliability question
OK, another chance to prove me an idiot. I'm used to it. I remember from messages posted here that z/OS 1.8, at least when originally released, was (let us say) not up to our usual expectations of RAS. Assuming that I order z/OS 1.8 soon and so get current maintenance on it, it is now up to snuff? I ask because the System z here has gotten some good reviews lately for reliability (compared by some management to other systems which shall remain nameless). As we all know, 1000 attaboys are wiped out by a single aw-$h1t. (apologies if that word offends anybody, but that's the saying even obstificated ). So this is a concern of mine. One plus that the System z has over all other systems here is that it is the Energizer Bunny. It just keeps going and going and ... . Even when it was running 100% CPU for 23.99 hours/day with a CPU queue depth in the 20s, it didn't fail (unlike the aforementioned unnamed system). Soothing emails gratefully received. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
