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:
Götz Neumann <[log in to unmask]>
Reply To:
[log in to unmask][log in to unmask], 30 Apr 1999 19:26:00 EDT457_us-ascii The 7908 is a 10Mb disc drive.
My first HP3000, a Series 30, had one drive, a 10 Mb 7908,
configured as a split drive. One 5Mb logical drive was
LDEV 1 and held the operating system software,
which was delivered on three 8" floppy discs.
Eventually MPE got too big for the 5 Mb drive and our
CE reconfigured the drive as a single 10 Mb drive.
Then we got a 7920 50 Mb drive and had scads of room
for our 16 users. [...]37_30Apr199919:26:[log in to unmask]
Date:
Fri, 30 Apr 1999 00:11:58 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
"Newman, Kevin:" wrote:
>
> In general, I would agree with this; however, in this particular case, I
> know what was happening with this session.  I know what it was
> accessing, what it was trying to do and the conditions of it becoming
> hung.

That sounds like you may have all the data necessary to duplicate
this, and the HPRC, WTEC and labs could then work out what the
root cause is and fix it.

> I feel that I have enough knowledge about the 3000 that I would
> feel save doing a kill on this process.  I know that others on this list
> would also be able to determine if they would want to risk performing a
> kill like this. I don't think that the general user should have access
> to do a kill like this, and I definitely would not let a 'unix only'
> person get anywhere near this command on any 3000 that I had anything to
> do with.  I still think that it is needed, and maybe the kill should
> describe what you are about to do, what resources are being held, and
> possible side affects; then ask if you really want to risk destabilizing
> your system.  If you say yes, kill it.  Set some flag to show that a
> process was forced dead, and if a DUMP is done and sent to the RC, they
> could easily see that the system is dirty due to someone killing off
> processes.  At that point, they could turn it back to the customer, and
> not waste anymore of their time on it.

The crux here is that noone, not even MPE 'knows' what resources a process
may hold, unless some other process really waits on it (*. Even looking
at a
stack trace may not show you which internal OS structure was locked by a
process just a few (hundred..thousand) instructions before. By brute force
killing you may leave an MPE control structure in a status that the next
user of a pooled ldev, or next opener of a file (just some examples) may
not expect to be half-(un)-initialized, so the danger of a crash of the
box is really high.

Concepts like semaphores , critical flags and whatever are nothing but
coding conventions aquired and released in 'pairs'. I keep thinking of
them as traffic lights on a crossing. And a kill tool is like giving
my process the remote control to get green whenever I wish.
I agree there maybe cases when you can 'see' the whole traffic picture
and forcing a 'green' appears safe, but beware of that 40 ton trucks,
which think it is 'their green' ...

Goetz (German namecousin of Kevin) Neumann,
HP, WTEC MPE/iX.

*) with the exception of some CM resources like SIRs.

ATOM RSS1 RSS2