Jon wrote:
>At 08:55 PM 1/18/96 GMT, Larry Byler wrote:
>>  But what do you do if the target queue is already
>>at limit?  Does the move fail?  Do you ignore the target queue limit (except
>>to hold off newly introduced jobs from executing until enough jobs log off)?
>>Does the job whose queue you are changing suspend until it is within queue
>>limit?  Does an existing job in the target queue suspend instead?  Which
one?
 
>Well, let's look at current system behaviour.  It *is* possible now to have
>more jobs EXECuting than the LIMIT specifies.  This can happen if a job is
>HIPRI, or the limit is temporarily raised and then lowered.  In this
>situation, all jobs continue to execute until the enough jobs finish to let
>the next one on.  So, from the options you listed I vote for:
 
>>...ignore the target queue limit (except
>>to hold off newly introduced jobs from executing
>>until enough jobs log off)
 
I agree with Jon's analysis.  ALTERing a job into a 'full' queue is exactly
the same as streaming a new job with ;HIPRI;QUEUE=thatqueue on it's !JOB
card, so there is nothing strange about :ALTJOBing a job into a queue
that already has at least 'limit' jobs executing in it.  This will
probably require OP/SM or JOBSECURITY LOW anyway.
 
G.