--- On Wed, 7/29/09, Ted MacNEIL <[email protected]> wrote:

From: Ted MacNEIL <[email protected]>
Subject: Re: Enforcing CPU Time
To: [email protected]
Date: Wednesday, July 29, 2009, 2:13 PM

>When you've set a cap that you constantly hit, then you need to control that 
>which
is causing you to hit the cap, especially when it is a case of a test system 
causing problems with a production system.

A cap is better than cancelling.
I'd rather have a test job hang than blow it away and come back and use more 
resources later.
That's what 'Discretionary' is for.


Ted:
I am mixed on your answer. The problem as I see it if you cap it it ties up the 
initiator for a potentially long time. It also could mean that you do not meet 
service levels and your management gets dinged (and the politics that follows). 
Yet if you"cancel" the job (322 or 222 or whatever)  you can free up the 
initiator for other test jobs to execute. Now days the operator does NOT sit 
around and  monitor jobs so there is no easy way for him/her to  know that the 
job is essentially sitting there. In a busy shop I could see a job capped and 
no thruput occurs and then the screams start I CAN't get my job done etc etc 
usually its late in the day before anyone gets upset and the programmers get 
hammered as they are doing "nothing". On the overall  scheme of things people 
can live with 322 or 122 or whatever a lot easier than no job thruput. 
A case in point we had a shared spool and 3 test job classes were set up so 
test could run with IDMS (no idea what type of jobs other than they needed 
IDMS). If those test jobclass got delayed the phones started to ring off the 
hook demanding to know "WHY"!!! . The answer is NOT to fire off another 
initiator as we had it finely tuned and (IIRC) only one job could be running 
against IDMS at the time. Hey I didn't design it we just implemented what the 
IDMS person wanted. There were also other issues of resource availability (tape 
drives and the like). This was a real world situation. We even went to the 
programmers management and explained the situation and the agreed that a 322 or 
522 or what ever was acceptable rather than delaying other people.
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

Reply via email to