HELP! - why does this process die?

[dave at murphy.UUCP]

Help! I'm having a problem with a shell that keeps dying off at
inconvenient times.  Here's the situation: A user whose login shell is
csh runs a Bourne shell script; call this shell A.  Shell A is a menu
script which prompts for a function number and then executes shell B (as
a command, not "exec"), which runs shell C.  Both are Bourne shells. 
Shell C then runs shell D in background and exits to shell B, which also
exits, leaving the user back in shell A, which prompts for another
function.  Meanwhile, shell D does three things: it executes a bunch of
trap statements to ignore interrupt, hangup, and terminate; it runs a
program called "raster" which generates a plot on an electrostatic
plotter, and, when that finishes, it removes a lock file and then exits. 

Now here's the problem: when the user is back in shell A, he gets impatient
and hits ^Z to suspend it so he can do other stuff while the plot is
running.  Trouble is, when ^Z is typed, shell D, which is waiting for the
raster process to complete, gets killed by something!  The raster process
is left still running without a parent (it gets inherited by init), but
since the shell D is dead, the lock file doesn't get deleted, and then
someone has to go remove it manually before anyone else can do a plot.
I can't seem to trap the signal that is causing shell D to terminate, and
I've tried everything I could think of: using "nohup" in shell C to execute
shell D; using trap statements to trap every signal that I could think of
that might cause shell D to terminate, even rewriting shell D in csh and
using "onintr -" to ignore all signals.  Nothing works.  By the way, if
the user just exits shell A after it comes back, this also causes shell
D to die.

Question is: what signal is shell D getting that it can't trap, and where is
it coming from?  The only signal that I can think of that could kill shell
D is SIGKILL, but where is it coming from?  Is csh in the habit of killing
off children that it can't account for?  (Doesn't seem too likely, as it
could make life uncomfortable for processes that fork.)  And, if it kills
off shell D, why doesn't it also kill off the raster process? (The raster
program does not change any signal actions.)

Machine is a Gould PN9080, OS is UTX-32 (a BSD4.2-derived system), rev 1.2U02.
Is this a significant problem or am I just overlooking something?

Thanks in advance for your help.  If the problem is non-trivial, I will
summarize responses and post to the net.
---
It's been said by many a wise philosopher that when you die and your soul
goes to its final resting place, it has to make a connection in Atlanta.

Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
UUCP:  ...{sun,pur-ee,brl-bmd}!gould!dcornutt
 or ...!ucf-cs!novavax!houligan!dcornutt
ARPA: wait a minute, I've almost got it...

"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."