Typically such problems result from resource locks. A resource might
be a file lock or an item lock in a database or a system resource. There
are others. Access to these resources is protected/coordinated through
the use of lock records called semaphores.

There are differnt types of semaphores and the type determines the
effect on the process holding the semaphore when another process tries
to lock it. There are plain semaphores where there is no affect on the
priority of the semephore holder. There are 'decay' semaphores, where
the holder gets boosted to the top of the queue (CQ, typically) where
he runs and, as he uses CPU time, his priroty drops to the limit of the
queue, where he stays until he releases the semaphore. There are also
'oscillation' semaphores which are like 'decay' semaphores except
that when the process reaches the limit of the queue, he bounces back
to the top of the queue. And there are 'priority' semaphores, where the
process holding the semaphore gets boosted to the base of the queue
queue (CQ, typically) and runs there until he releases the semaphore.

There are 2 ways to troubleshoot the problem: using DEBUG when the
problem happens or through a memory dump.

Using DEBUG is usually the best method but does require a certain
amount of preparation. In order to use DEBUG and not get stuck along
with everyone else, you should use the "ALTACCT" and "ALTUSER" commands
to set ";MAXPRI=BS" on the user "MANAGER.SYS". This must be done in
advance; i.e. now. Then when the problem happens, you or the third
party or HP can logon using ";PRI=BS" and you will have priority over
process hanging things up and be able to troubleshoot it.

Otherwise, the other choice is to CTL-B, "TC" the system, get a memory
dump, and see if the problem can be identified that way.

Believe me, DEBUG is the way to go. Having logged on ";PRI=BS" you
can also use GLANCE and DBUTIL plus any other tools at your disposal.


-Pete Crosby  ([log in to unmask]  a.k.a. [log in to unmask])
 HP Response Center


>
>Has anyone encountered a situation where a process consumes all the CPU
>and consequently, locks up the system?
>
>We have two HP3000s, a 939KS and a 996/300 that users access via TCP
>connections.  The 939 is running version 5.0 of MPE (PP 6) and the 996
>version 5.5 (PP 4).  We typically have 60 sessions on the 939 and 100
>sessions on the 996.  The problem seems to happen (mostly) on the 996.
>
>We THINK the trouble is related to a client server product which runs on
>both CPUs.  We have the "listener job" running in the DQ, but at times
>it consumes (as other processes do) as much CPU as it can get.  I
>understand that.  What I don't understand is why, at various times, it
>locks up the system.  It hold onto all the CPU it can get.  The software
>vendor is working with us to resolve this issue.
>
>Perhaps my queues are not set properly.  This is how they are set (both
>boxes):
>
>   QUEUE    BASE    LIMIT    MIN    MAX    ACTUAL   BOOST   TIMESLICE
>   -----    ----    -----    ---    ---    ------   -----   ---------
>    CQ      152     200      1      2000   5        DECAY     200
>    DQ      195     238      2000   2000   2000     DECAY     200
>    EQ      240     253      2000   2000   2000     DECAY     200
>
>We do not use the EQ much.  Would dropping the base/limit of the EQ
>help?  Should the C and D queues overlap as I have them set, or not?
>
>Any suggestions would be GREATLY appreciated.
>
>TIA,
>
>Bob Sorenson - System Manager
>Infotrust
>