James writes:

> Looks like Wirt was on target with this same idea way back in August!
>  I think that he would not want to say "I, told you so!", so, if I may,
>  "He told us so!"
>  ----------------------------------------------------------------------
>
>  Nope, one important point is with this fix the INETD Server is running
>  in the linear queue B152, BUT with this patch we are NOT starting the
>  client process's in this same queue...  We are starting the clients at
>  PRI=CS.
>
>  The !RUN INETD;PRI=BS solution is not supported nor recommended by HP.

It's very important to understand that James' modification is undoubtedly the
right and proper (and optimal) thing to do, and I very much appreciate he and
HP correcting the problem as quickly as they have.

However, it's also important to understand that in the absence of an
HP-provided solution, raising JINETD to the B queue was the only solution
that was available to users. While James rightly says that solution is "not
supported" by HP, I tend to focus more on the last half of his sentence,
where he says that it's "not recommended" :-). That's a much milder statement
-- and given the severity of the problem, if you had it, it's probably more
appropriate.

If you were running your CPU at 100% (which is what every process should
ultimately strive for), telnet logons are simply not possible at the moment.
The difference in raising JINETD to the B queue was the difference between
night and day. Most importantly, it was the difference between being
functional and broken, at least from the users' viewpoint.

Given that circumstance, I never really considered there to be any choice.
Raising JINETD to the B queue still launched telnet sessions in the C queue,
just as James' patch does now. Nor was I ever able to find any other adverse
effects of moving it there in my limited testing. All of the results that I
encountered created so much upside benefit with no measurable downside costs
(minus a few theoretical ones) that there seemed to be no alternative to our
recommending to our users that they raise JINETD's priority.

Indeed, the only reason that most people never saw this problem is that their
HP3000s are actively engaged in high disc I/O processes, due either to the
lack of main memory or the design of their application programs. Because of
the comcommitant suspension of CPU activity during those periods, low queue
priority jobs such as JINETD were provided with sufficient time for new users
to get a socket/session created.

But if you were unlucky enough to be among those users with sufficient memory
or applications designed well enough to keep your discs quiet, your users
would be completely shut out for sizeably long periods of time.

Nonetheless, all of this is just a long way of saying again: Thanks. Thanks
much, actually.

Wirt Atmar