At 01:43 PM 12/15/2000 -0500, Griffin, Patrick J. wrote:

>I hadn't thought of looking there, but checking it now I see that it is
>flooded with activity from the users who weren't blocked. There were no
>records shown with that Lock Block number.

Right. The history tends to take a short view (is there a config
parameter?) and probably expanding it would waste space without
adding information.

>I took a look in the Event Log portion and saw entries like:
>
>(Occurred 5 times) DEL_OWNER: owner = 901460, lock = 901460, request =
>0
>
>(Occurred once) DEL_OWNER: owner = 901460, lock = 1587712, request
>= 0
>(Occurred once) DEL_OWNER: owner = 901460, lock = 939412, request =
>0
>
>[owner 901460 pointed to the task I killed to free up the system, but I
>assume these entries may represent tasks that occupied that slot earlier and
>are not related to this challenge.]

That's likely as the various block types are kept around and reused. Those
look like transaction end messages, particularly the first one.

>You also asked "Are your various owners in different groups?"
>
>All of our users have been grouped by department, so there would be
>many users trying to read this table and all of them may have different Unix
>Group ID's. Additionally, all users are members of the PRODUCTION group,
>and it's membership in this group that grants them access to the local
>Production Database files. None of these users actually appear in isc4.gdb.

The normal mode of lock table failure is a signal that can't be
delivered. The symptoms are not what you are seeing (one request
will have the lock - in your printout, no one does) but I can't
resist trying to make a known solution fit an unknown problem.
The other argument against this hypothesis is that the system
generally runs.

There was a problem last year with a database on solaris that kept
hanging up - turned out to be a known bug in solaris signal handling.


Regards,

Ann
www.ibphoenix.com
We have answers.