Re: Interactive Feature Upgrade Theory

From: Andy Nolen-Parkhouse <aparkhouse@attbi.com>
> I went back to my documentation to try and figure out why I would have
> made such an assertion

Thanks Andy for the clarification. Part of the resolution of this
"problem" may lie in different hardware. I only have an old, feeble
machine and should keep that in mind when making sweeping
generalizations. My assertion (in retrospect, maybe a bit too strong)
was based on the following experiment:

1) make a batch program B that does:
     Again: go to Again;
2) make an interactive program A that does:
    Again: count to 1 billion (or some such number);
               show a screen (any screen);
               go to Again;
3) submit B to batch (e.g. to QSYSNOMAX) and set its priority to 20
(same as interactive). Use WRKSYSACT or WRKACTJOB
to verify that B gets almost 100% of the CPU time.
4) start A in an interactive session.
Use WRJSYSACT or WRKACTJOB to verify that now B gets 50%
and A gets 50%.
5) wait (on my system about a minute) until CFINT kicks in. On my
system I can run 40% interactive, so one would expect that when
CFINT kicks in (if the new algorithm worked), the system would limit
program A to 40% and give 60% to program B. This is not what
happens. Instead, CFINT takes 60% and the two programs B and
A share the remaining 40% evenly with 20% each.
It would be interesting to see what the result would be on one of
the models that claim the "new algorithm".
BTW: sometimes CFINT does not kick in until I start yet another
interactive session. For the best test start two batch jobs with B
and two interactive jobs with A. Then the above holds, if one
counts the two Bs as one, and the two As as one.