Harmik,

>As Jeff Kell, Bruce Collins, and Mike Hornsby suggested, I believe the
>problem may well have something to do with the setting of the TUNE
>command, which is currently as follows. This was set by the company that
>installed the computer, and has been unchanged for several years, so why
>is it giving a problem now?

I don't think the TUNE settings are "guilty". At least the BASE and LIMIT
priority ranges look like the default ones. And that's exactly what causes
a "bad" process in the CS queue to "starve" DS queue members CPU wise. In
the default configuration, the priority of the CQ is favored over the DQ,
as the former are typically interactive users while the latter are batch.

If a process in the CQ runs away with all CPU it can get, the system won't
give any CPU to DQ processes with your TUNE setting. If you can alter the
CPU hog in the CQ to a lower priority or bump the jobs to be aborted to a
higher priority, the ABORTJOB should get honored.

You might want to have a close look at the CPU hog in the CQ to find out
what conditions caused it to loop and how to prevent these in the future.

Lars.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *