>>> Resource groups don't work, since everyone in the resource group gets >>> capped by the one person hogging up the cpu. Using service class >>> periods and bumping down to discretionary doesn't work, since even at >>> discretionary you can chew up a lot of cpu (we have lots of cpu in the >>> morning, but then we cap in the afternoon). We are trying to stop an >>> individual from making our cap happen earlier in the day then we want. > </snip>
>> Add another service class period with very low (or non-performing >>goals) >> to >> the affected service class. When the user(s) reach the Service Unit >> Limit and drop into the "last" period. Very little or no service will be >> consumed. >No, this is the same situation as the OP describes for discretionary. If >his cpu is empty, this group of jobs will still be allowed to consume >lots of CPU. Maybe I just don't get it, but one job can't simply "chew up all the CPU". When the service class is interrupted, then the work will rotate between all the competing tasks, so that enforcement of a cap doesn't unduly punish anyone. In addition, if the intent is to reduce the high water mark for CPU, then why does it matter where the usage originates? 10 low usage jobs vs 1 high usage job ... makes no sense. If you cap a service level then you will achieve your objective. Any badly behaving unit of work needs to be manually transferred to a different service class for special handling (or it can be done through automation), but you can't be generic about it. Adam ---------------------------------------------------------------------- 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
