> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
> Behalf Of Stan Sieler
> Mike writes:
[debug fragment deleted...]
> Stan writes:
> This should work safeley *provided* that you also decrease the
> job limit by the same amount.
This certainly would make it "safer", but I am not easy to convice
that it is "safe"...
> MPE sizes the JMAT by the *sum* of the session limit and job limit.
This used to be true when the JMAT was a CM table. Now the JMAT is an
NM table the constant "max_num_jmat_entries" is actually 3500. The JMAT
is not the problem.
The table I was more worried about was the JOBSIR table, which is
constructed at boot time using an old-style calculation (in CMINIT)
similar to the one you describe.
I "think" you would be OK as long as you keep the sum the same, but
I am not willing to bet on it.
There are unusual cases that would put this to the test, eg: if old
limit was 100,100, and you change the limit to 150,50, then you logon 150
sessions, stream 50 jobs, then launch some scheduled jobs, and try logging
on more jobs ;HIPRI. My guess is that if this still works, it is only
because "range checking" is turned off on the CM modules accessing the
JOBSIR table and the address calculations happen to stay within the bounds
of the DST -- in other words LUCK! It is also possible that we maxed
out the JOBSIR table earlier when increasing system limits (I can't
remember). In that case I guess it is not luck but "skill"! ;-)
>(That's why a STREAM ; HIPRI job can startup even if you are at the
> max configured number of jobs.)
This wouldn't work well if you were at max jobs and max sessions.
However, STREAM ;HIPRI will still work (assuming not out of
'system resources') because actual JMAT size is 3500.
> If you don't keep the sum the same, you
> run the risk of unexpected things happening (I haven't tried it, and don't
> plan to try it).
I also haven't tried it, but I must admit, I am tempted...that's just my
nature :-)
> Still, as Scott M said, it isn't supported.
Exactly...
|
