Scott writes:
> Bottom line, :ABORTPROCESS will not abort any process that is critical.
> Period.

Ergo, :ABORTPROCESS will not abort any process which :ABORTJOB could not
abort.  It's just a more fine-grained :ABORTJOB, not a magical "process-
be-gone" command.

In my opinion this is a step backwards in that it destabilizes the 3000
platform by allowing operations staff to take potshots at arbitrary
processes in a carefully designed and constructed process tree.  The
developers of the system probably never tested what happens if arbitrary
processes get killed at arbitrary points in their execution, thus
increasing the chances of data corruption and other problems resulting
from use of this new command.

Further, the only mechanism available to a developer to protect herself
from :ABORTPROC is to set the process "critical" for its entire execution.
This means of course that the process will not be abortable *at all* now,
and any error in the program will result in the entire system crashing
with a SA1458 (Process Aborting While Critical).  Hardly an improvement.

Users are asking for a product that "Kills bugs dead permanently right
now", but, as has been pointed out, this is not practical.

The problem is not the inability to 'kill' certain processes.  In fact
there are two problems:

1) Processes get stuck in states where they cannot be aborted.

   This is not a deficiency in the :ABORT[JOB|PROC|whatever] commands.
   It is a result of a complex system which is either buggy or not
   designed to avoid these situations.  If you don't want non-abortable
   stuck processes, ask HP and the other software developers to ensure
   that this doesn't happen.  Of course if you want more money spent on
   this, you'll have to expect something else to suffer.

2) Users can't tell *why* something is stuck and why they can't abort it.

   There seems to be a standard human response of "if you can't understand
   it, try to make it go away".  Several people today have asked for more
   information as to why processes are stuck.  I suggest (actually I
   suggested to HP several days ago) that if there was a TELESUP type
   utility that people could run which would explain to them why a
   process was not currently abortable, that this would practically
   eliminate the need for a "super" :ABORTPROC command.  Either users
   would accept the stuck nature of the process once they understand
   exactly why it is stuck, or they would complain to HP (or whomever)
   about the stuck process and ask for the associated "bug" to be fixed.
   The utility would give enough information for the user to feel
   confident that they understand exactly what the process is doing and
   why it is stuck (this means a textual explanation, not just a bunch
   of stack traces) and also the technical information that a developer
   would need to investigate and fix why the condition occurred in the
   first place.

G.