"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
