The short answer is:  When a parent process is aborted, it issues an 
abort against it's child process(es) as part of the parent's termination 
handling and waits for them to complete prior to the parent completing 
it's termination. This assumes there isn't other factors, such as 
hardware or OS failures as well involved.

The medium-length explanation is:

Its been more than a decade since I studied these steps, So Craig/Scott 
may offer some corrections....
The abort/terminate logic sets the terminate flag in the process table 
for the child.  It then notifies the OS to run the process dispatcher.  
When awoken thru the dispatch process, the processing checks this flag 
and if set, calls terminate.  The exception to this is when interrupts 
are off and the process is running in critical mode.  At this point the 
process is allowed to continue running until the 'critical' condition is 
reset, at which point it branches into terminate processing.  Running in 
critical mode is a function of specialized code.  While this may occur 
from time to time when IMAGE code is executing, it does not run in this 
mode during an entire transaction as it would have a significant impact 
on the overall system performance.  Keep in mind that IMAGE should 
complete what is necessary for physical integrity of the structure, but 
not necessary logical integrity of the data. The majority of the time 
physical corruption is a result of overall system or hardware failure, 
or even more frequency, poor backup/restore procedures.  It is not 
likely to be caused by user-initiated process aborts unless there is a
coding error in IMAGE....which for something like this to still exist 
after all these years is not likely.

So having the ability to unwind the last incomplete IMAGE transaction 
thru roll-back recovery can be
important from a data integrity perspective.


Brian Donaldson wrote:
> Been giving this quite a bit of thought, and yes, it can be done (with a bit
> of work.)
>
> Question about the CREATEPROCESS thingy and the scenario in question I
> have is this --
>
> Scenario: -- 
>
> Parent creates the child process.
>
> Question -- If parent program dies (for whatever reason, abort, stop run, 
> goback etc.) does the child process continue to its logical end (goback)
> or does it also die too? 
>
> If the child also dies this could result in corrupted data as the child is
> doing the updates. That was why I had suggested including the DBX procedures in 
> the child program to ensure the integrity of the data being updated).
>
> TIA,
> Brian.
>
>
> On Wed, 28 May 2008 21:26:26 -0700, Walter J. Murray <[log in to unmask]>
> wrote:
>
>   
>> Beautiful!
>>
>> Too bad junior can't give the lock to daddy.  ("I yield the lock to my
>> father.")  Since it's junior who gets the lock, it has to be junior who
>> does the updates.  But I think this could be made to work.  Thank you
>> Dave.
>>
>> Walter
>>
>>
>> -----Original Message-----
>> From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
>> Behalf Of Dave Powell, MMfab
>> Sent: Wednesday, May 28, 2008 12:26 PM
>> To: [log in to unmask]
>> Subject: Re: [HP3000-L] TurboIMAGE: Timed lock request
>>
>> I think he can do it with a whole lot of rewriting...
>> 1: Separate off the (unconditional) lock & updates into a second little
>> program.
>> 2: Have the main program create & activate the new child program as
>> needed.
>> 3: Have the child program notify daddy when the lock comes thru, by
>> writing to
>> a message file, or some such, BEFORE it starts any updates.
>> 4: If daddy doesn't get the good news within 15 seconds, it kills off
>> junior
>> and tells the user to try again later.  (Maybe daddy did a 15-second
>> timed
>> read on the message file -- this way the wait and the mechanism to get
>> the
>> news are combined into one step).
>> 5: To make it completely bulletproof even if the timing comes out worst
>> case,
>> daddy may need to send some acknowlegement back to junior when it gets
>> the
>> good news about the lock, and junior needs to wait for that before
>> starting
>> the updates.
>>
>> I have no particular opinion on whether its worth all the re-writes, but
>> it
>> ought to be possible.
>>
>>
>> ----- Original Message -----
>> From: "Denys Beauchemin" <[log in to unmask]>
>> To: <[log in to unmask]>
>> Sent: Tuesday, May 27, 2008 20:53
>> Subject: Re: [HP3000-L] TurboIMAGE: Timed lock request
>>
>>
>>     
>>> I just do not see a way in which this could be accomplished; in order
>>>       
>> to
>>     
>>> retain control, you have to use conditional locks and that never gets
>>>       
>> you in
>>     
>>> the queue.  If you use unconditional locking, you're toast.
>>>
>>> I would hunt down the offending programs and fix them.
>>>
>>> Denys...
>>>
>>> -----Original Message-----
>>> From: Walter J. Murray [mailto:[log in to unmask]]
>>> Sent: Tuesday, May 27, 2008 10:43 PM
>>> To: 'Denys Beauchemin'; [log in to unmask]
>>> Subject: RE: [HP3000-L] TurboIMAGE: Timed lock request
>>>
>>> The problem is that some of the programs don't "play by the rules," as
>>> Denys puts it.  They lock around terminal reads.  If I do a regular
>>> unconditional lock, which I would like to do, I run the risk of
>>>       
>> hanging
>>     
>>> until the other user gets back from lunch.
>>>
>>> Yes, this is a real-world problem for me.  I would like to issue an
>>> unconditional lock request (get queued up waiting for the request to
>>>       
>> be
>>     
>>> satisfied), but be able to bail out if it's not satisfied within 15
>>> seconds, and tell the user to try again later.
>>>
>>> No, I am definitely not looking for HP to implement this as an
>>> enhancement--just wondering if it has ever come up.
>>>
>>> Yes, I meant to say I could issue a CONDITIONAL lock every second for
>>>       
>> 15
>>     
>>> seconds, but that wouldn't meet my needs.
>>>
>>> Walter
>>>
>>> -----Original Message-----
>>> From: Denys Beauchemin [mailto:[log in to unmask]]
>>> Sent: Monday, May 26, 2008 6:28 PM
>>> To: 'Walter J. Murray'; [log in to unmask]
>>> Subject: RE: [HP3000-L] TurboIMAGE: Timed lock request
>>>
>>> It looks like you're asking for something like a second conditional in
>>> English.  I'm not sure if it would be easy to implement in the first
>>> place
>>> and I can see where it may cause more harm than good.  A long time
>>>       
>> ago,
>>     
>>> I
>>> wrote an order entry application that started using conditional locks.
>>> I
>>> quickly changed that to unconditional locks because users complained
>>> about
>>> having to issue a "yes" to retry the locks on many orders.  Granted,
>>>       
>> it
>>     
>>> was
>>> a silly idea but this was about 30 years ago.  I find that as long as
>>> your
>>> programs play by the rules (no MR or strictly controlled MR and no
>>>       
>> locks
>>     
>>> around terminal reads,) the application flows much faster using pure
>>> unconditional locks.
>>>
>>> Did you have a specific application in mind for this?  Perhaps there
>>>       
>> may
>>     
>>> be
>>> another way to implement such a mechanism; I seriously doubt HP will
>>> enhance
>>> IMAGE to add this request.
>>>
>>> Also, I think you mean your process would issue a conditional lock one
>>>       
>> a
>>     
>>> second for 15 seconds and no, that will not do the trick, that was the
>>> problem I had 30 years ago.  (Has it really been 30 years? I guess so.
>>> Sigh.)
>>>
>>> Denys...
>>> -----Original Message-----
>>> From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
>>> Behalf
>>> Of Walter J. Murray
>>> Sent: Monday, May 26, 2008 8:04 PM
>>> To: [log in to unmask]
>>> Subject: [HP3000-L] TurboIMAGE: Timed lock request
>>>
>>> Greetings,
>>>
>>> Time for another TurboIMAGE question.
>>>
>>> I'm pretty sure there is no way to do this directly in TurboIMAGE.  I
>>>       
>> am
>>     
>>> curious whether it has ever been an enhancement request, or whether
>>> someone has a suggestion of how to accomplish something equivalent.
>>>
>>> I want something that's like a cross between an unconditional and a
>>> conditional lock request.  I'd like to issue a lock request using this
>>> new mode, and specifying a time interval, e.g., 15 seconds.
>>>
>>> If the lock can be granted immediately, fine.
>>>
>>> If not, the request is queued and my process is blocked, just as for
>>>       
>> an
>>     
>>> unconditional lock request.
>>>
>>> If the lock can be granted within the specified interval, control
>>> returns to my process, just as when an unconditional lock request is
>>> granted.
>>>
>>> If the lock is still pending when the specified time has elapsed, my
>>> request is deleted from the queue, and I get a status return
>>>       
>> indicating
>>     
>>> that my request was unsuccessful because of a timeout.
>>>
>>> It would be like a timed read against a terminal or a message file.
>>>       
>> It
>>     
>>> seems like something that would be very useful, but I don't remember
>>> ever having heard it suggested.
>>>
>>> Without this feature, the best I know of to do is to issue an
>>> unconditional lock request every second for 15 seconds, and then give
>>> up.  This is not a very good substitute for what I want, because my
>>> request never gets queued up.
>>>
>>> Walter
>>>
>>> Walter J. Murray
>>>
>>> * To join/leave the list, search archives, change list settings, *
>>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>>
>>> * To join/leave the list, search archives, change list settings, *
>>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>>
>>>       
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>     
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>   

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *