Path: news.mitre.org!blanket.mitre.org!agate!howland.erols.net!news-peer.sprintlink.net!news-pull.sprintlink.net!news-in-east.sprintlink.net!news.sprintlink.net!Sprint!208.131.160.208!news.infi.net!news.infi.net!newsfeeder.servtech.com!post.servtech.com!cyber3.servtech.com!not-for-mail
From: lvt-cfc@cyber3.servtech.com (christopher f. chiesa)
Newsgroups: comp.os.vms
Subject: Brag
Date: 31 Oct 1997 15:39:35 -0500
Organization: ServiceTech, Inc.
Lines: 75
Message-ID: <63dfm7$pj8@cyber3.servtech.com>
NNTP-Posting-Host: cyber3.servtech.com

Apropos of nothing, I just impressed the heck out of myself and had to 
tell somebody who would be capable of APPRECIATING it.  I apologize for
the waste of bandwidth, but... jeez! :-)

For most of the day today, I've been running an interactive DCL procedure
that steps through a directory tree in a recursive manner, and lets me 
examine and manipulate files.  Sort of a "housecleaning" process for
my diskspace.

One of the operations this procedure provides, is "DCL command," which
I've implemented roughly thus (error checking not shown):

    $ OPEN/READ CHAN TT:
    $ READ CHAN CMD
    $ CLOSE CHAN
    $ 'CMD'    ! Yeah, I know, it's not safe.  But I'm its ONLY user.

A little over an hour ago, I used this 'escape hatch' to issue an EDIT
(/EDT) command.  Then, while editing, I ^Y'd out of the EDT session, and
at the DCL process SPAWNed a subprocess.

Then I logged out of the subprocess.  I _should_ have been returned to the
DCL prompt at which I had previously issued the SPAWN command -- but I
wasn't.  My terminal "froze," for all intents and purposes.  "That's odd,"
I thought.  "I wonder if I can diagnose and FIX it?"

SHOW PROCESS/CONTINUOUS showed the process in HIB state in the midst of
EDT, with no apparent CPU or I/O activity.  SDA showed no outstanding
ASTs, and an examination of the call stack showed that, indeed, the last
identifiable procedure call had been to SYS$HIBER.  Hmm.

I recalled that when SPAWNing (from the DCL command prompt, anyway), a
mailbox is involved in notifying the parent process that the subprocess
has terminated.  I conjectured that perhaps something had somehow
interfered with this, so that in whatever sense DCL understood these
things, the parent process "never got the message."  

I experimented with a parent and child process at another terminal (well,
in a different DECterm window, anyway) and verified that, indeed, I was
able to cause an identical "parent-process non-reawakening" problem by
by randomly inserting messages into, and consuming messages written to,
the termination mailbox.  Best of all, I was then able to RECOVER from the
situation by (as it turned out) a fortuitous combination of happening to
send ACCEPTABLE messages into the mailbox!

But when I tried reading-and-writing messages of ARBITRARY length at the
mailbox associated with the REAL problem process, it DIDN'T WORK.  The
doggoned thing stayed in HIB state.

The cool part is this: I was able to go back into SDA, find the code in
DCL where it established a write-attention AST on the termination mail-
box, and thereby find the address of the AST code itself (it took me
"forever" to hit upon THIS PARTICULAR METHOD of locating the AST code,
however; I had no luck trying to trace the AST queue of either the process
OR the mailbox device).  It was then a simple matter of examining the code
and discovering that the AST wanted to successfully read 16 (decimal)
bytes, then either read or write (I didn't actually verify the I/O
function code) 4 bytes.

I popped back out to DCL, composed a couple of string symbols of 16 and 4
bytes' length respectively, OPEN'ed a channel to the mailbox, and used the
WRITE command to spit the strings into it in the "right" order.  I then
CLOSEd the channel.  And, although I forget whether it happened after the
WRITEs, or waited until after the CLOSE, but-- at that point my original
"problem process" WOKE UP and all has been NORMAL EVER SINCE.  

I'm really pleased with myself that I was able to use SDA so effectively,
to solve what in earlier times would have been an inexplicable and
insurmountable problem.  <Pat self on back.>

Have to run.  Thanks for listening!

Chris 
  lvt-cfc@servtech.com