HP3000-L Archives

January 2001, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Clogg <[log in to unmask]>
Reply To:
John Clogg <[log in to unmask]>
Date:
Wed, 24 Jan 2001 11:45:20 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (48 lines)
A file or database lock would be an example of a control block wait, so it
is consistent with your theory.  Unfortunately, I know of no way to identify
the control block or the resource it represents.  I have called the response
center during similar situations, and have not usually had any luck getting
them to identify the resource under contention.

One trick that sometimes works is to look for a priority boost.  For
example, if a job running in the DS subqueue has locked a resource, and
other processes at, say, 152 priority are waiting for it, the dispatcher
will boost the priority of the locking process to the same level as the
waiting process in order to hurry it along.  If you see a process in the
problem account that is getting plenty of CPU while everyone else is
impeded, and its priority appears to have been boosted above its normal
range, then it is the likely culprit.  Determining what it has locked could
still be difficult, though.  Of course, this approach only works if the
offending process is running at a lower priority than other, competing
processes.

-----Original Message-----
From: Cecile Chi [mailto:[log in to unmask]]
Sent: Wednesday, January 24, 2001 11:32 AM
To: [log in to unmask]
Subject: CONTROL BLOCK WAIT


Yesterday we had a lot of jobs and sessions hang on a 969/220 running
MPE/iX 5.5.  This went on for several hours, and then suddenly everything
was OK again.  We are trying to determine the cause.

Everything that was hung was in one production account.  The majority of
the sessions and jobs were in other accounts, many of them running the
same programs from a common account, and they were not affected.
DBUTIL did not show any database locks in the account.
One theory is that something was holding a lock on a flat file which is used
by almost everything that runs in the affected account.  If  true, it would
explain why everything suddenly started to run again, when the lock was
finally released.

The System Manager used Lund's SOS to look for problems:

"SOS in addition to impedance also indicated that the current wait state
was a CONTROL BLOCK WAIT.) I'm trying to determine exactly what the CONTROL
BLOCK WAIT is indicating "

Can anyone tell me what CONTROL BLOCK WAIT means?

Cecile Chi

ATOM RSS1 RSS2