The Lock Timeout History screen can be used to identify the
    object that causes a timeout event.

    The Stall Messages screen provides stall information, but when
    a process times out while waiting for a lock, the stall is
    terminated and the information is no longer available on the
    Stall Messages screen.

    For each active process on the current VMScluster node, the Lock
    Timeout History screen shows the process ID, the time that the
    process most recently timed out while waiting for a lock, the
    reason for the most recent timeout experienced by the process,
    and the number of timeouts experienced by the process since
    attaching to the database.

    The information shown in the screen includes:

    o  process ID

       The process ID of each active process.

    o  occurred

       The time that the process most recently timed out while
       waiting for a lock. This field is blank if the process has
       not experienced any timeouts.

    o  lock timeout reason

       The event that caused the most recent timeout experienced
       by the process. This field is blank if the process has not
       experienced any timeouts. Note that the lock timeout reason
       does not identify the cause of the timeout. The conflicting
       process could be on a different VMScluster node. Rather, the
       lock timeout reason provides historical information that can
       help the DBA track down the timeout by other means, such as
       using the RMU Show Locks utility or examining the application
       transaction data flow analysis. The lock timeout reason
       remains displayed for a process until the process is involved
       in another timeout or detaches from the database. For more
       information on interpreting the lock timeout reasons, see the
       descriptions for the stall reasons in the help text for the
       Stall Messages screen.

    o  timeout

       The number of timeouts the process has experienced since
       being attached to the database. This field is blank if the
       process has not experienced any timeouts. This information
       may be as useful as the lock timeout reason in determining
       the importance of the timeout. For instance, if the database
       has been active for a week and the number of timeouts is low,
       the system may be operating efficiently. Timeouts are fairly
       common in a database system, and not all timeouts are bad.