Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!SRI-KL.ARPA!STEINBERGER
From: STEINBERGER@SRI-KL.ARPA.UUCP
Newsgroups: mod.computers.vax
Subject: Processes in a RWAST state
Message-ID: <12286367612.15.STEINBERGER@SRI-KL.ARPA>
Date: Sat, 14-Mar-87 13:33:01 EST
Article-I.D.: SRI-KL.12286367612.15.STEINBERGER
Posted: Sat Mar 14 13:33:01 1987
Date-Received: Sun, 15-Mar-87 04:34:16 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 33
Approved: info-vax@sri-kl.arpa

Sometimes a process gets into an RWAST state.  If you do a SHOW SYSTEM you
can see this.  For example if you have a TK-50 tape drive and you give
it a command (e.g. mount) before the green light comes on, it will often
get in a RWAST state and NEVER get out of it.  I've had to reboot the
system.  I'm more careful now - I always wait for the green light!

However when I'm debugging some new hardware and software, sometimes a
process will get into an RWAST state and DCL cannot kill it.  I spoke
to the DEC folks in Colorado and they confirmed that reboot is the only
option here (I had been using STOP/ID=nnn, which gives no error message,
but doesn't do anything either).

Can anyone give me a more favorable second opinion?  Is rebooting the only
option to getting rid of a process in the RWAST state?  If so, why does DEC
allow VMS to create processes that it can't delete?

Thanks to all who reply.


Rebooting in Menlo Park, CA,

	Ric Steinberger
	steinberger@kl.sri.com

	(415) 859 - 5985


PS - Implicit in all of this is the fact that the AST will not be delivered
due to some kind of hardware or hardware/software interaction problem.
The process is in a "Waiting for Godot" state.


-------