HP3000-L Archives

April 1999, Week 5

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:
"Newman, Kevin:" <[log in to unmask]>
Reply To:
Newman, Kevin:
Date:
Thu, 29 Apr 1999 15:29:25 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
I could stand to have something like this!

Kevin Newman

> -----Original Message-----
> From: Gavin Scott [SMTP:[log in to unmask]]
> Sent: Thursday, April 29, 1999 12:09 PM
> To:   [log in to unmask]
> Subject:      Re: How do I kill a hung session ?
>
> Scott writes:
> > The exact questions "why is a process hung" is very difficult to
> answer
> > currently.
>
> I assume that a "why is this process stuck" utility program would
> simply
> look for certain scenarios that have previously been identified by HP
> through analysis of memory dumps and obvious things like being impeded
> on a file or database lock.  If the process being examined does not
> fall
> into one of these categories, then basic process state (critical
> yes/no,
> block reason, which port, etc.) would be dumped, along with a stack
> trace,
> so the user could report this new scenario to HP (or whomever) both
> for
> a possible bug fix and for integration into the next version of the
> "why
> is it stuck" utility.  Over time the program would be taught to
> explain
> perhaps 99% of all stuck process situations with a high level
> description
> for the user.
>
> > Leading question: would there be a lot of support for some new CI
> functions
> > (eg: pinfo, etc) and enhancments to the :SHOWPROC command to show
> the
> > required information?
>
> I think a more detailed :SHOWPROC command would be a great help, but
> this
> doesn't have to be too fancy.  Just some more detailed dumping of the
> system tables related to the process, without an attempt to interpret
> the
> data at a very high level.  This would be fairly simple to implement.
>
> The "why can't I abort this process" utility should be a standalone
> TELESUP
> program, since it would probably be updated on a regular basis as new
> scenarios are discovered and added to the program.  One hopes that
> stuck
> processes are not a common enough occurrence that this utility has to
> become embedded into the OS at the CI command level :-)
>
> G.

ATOM RSS1 RSS2