Hi, There are other valid reasons for multiple images within a single CEC in addition to dealing with VSCR challenges. One is to provide higher availability. The exploitation of parallel Sysplex even within a single CEC can isolate you from single image planned and unplanned downtime. Nothing In Life Is Free but even without a second physical footprint with data sharing, IRD, and other tools all available today you can make your system look very nearly 100% available and handle varied workloads in each partition.
These are interesting. Mainframe Continuous Availability TD Bank Financial Group Best Practices (25 pages) http://www-03.ibm.com/systems/services/downloads/tdbfg_ca_bestpractice.p df Hot Topics #15 pages 4 - 6 Always there when you need z Top ten best practices for near continuous availability http://publibz.boulder.ibm.com/epubs/pdf/e0z2n170.pdf FWIW we mix it all in development and test LPARs even production query. We only don't have routine heavy TSO use in our highest performance/available production on-line LPARs. We do run lots of scheduled production batch there though we try to schedule the resource intensive batch off peaks hours to avoid contention with on-line and optimize the WLC peak charges. I would agree with others that WLM does a good job of managing the varied workloads in these environments. As we have grown I am very glad I cannot get down to the level of minutia provided by COMPAT mode. In those mixed workload environments my quest is always to find someone to kick around and a good target is medium and large sized test batch jobs. I run almost everything except quick turn light weight test batch jobs as discretionary. If you have a CEC where there is enough demand you cannot get a WLC discount then soaking up all the capacity with discretionary test batch is a good use of those cycles. There is no rebate for unspent cycles when you nail a full capacity period several times a week sometimes every day. MTTW which you get with discretionary works very well you just have to find something you can run this way and still meet user expectations. For TSO I think 2 periods is enough. Set a response time percentile goal for the first and make it big enough to do everything reasonable then treat them like batch with a low to moderate velocity goal IMP 4. Management of those development LPARs is in most ways more challenging than production on-line as it is harder to justify capacity increases they always run with less resources CPU/MEMORY than would be ideal. Best Regards, Sam Knutson, GEICO Performance and Availability mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Monday, September 25, 2006 11:45 AM To: [email protected] Subject: Re: Job Mix (was: Speaking of SDSF) >If it is a given that I have a single CEC and my CPU demand is consistantly 100%, then I totally fail to see the plus of multiple LPARs. I made an assumption, regarding multiple footprints, that was invalid. I have not run in a single CPU shop since 1984. The only reason for multiple images within a single CEC is really if you still have Virtual Storage Constraint that can be alleviated with more images. But, you have to be very careful with TSO competing with Production (Online & Batch). If you drop it too low, then it's aproductivity hit. ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. ---------------------------------------------------------------------- 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
