For the application Walter originally had in mind, I think daddy won't be
doing anything but handshaking and monitoring junior's progress -- pretty safe
stuff which shouldn't have much chance of an abort.

In or own apps, we do lots of process-handling, but mostly daddy suspends
until junior reactivates him.  Again, zero chance of daddy having a problem
that would mess up junior.

For the one or two apps where daddy continues doing things while junior is
also busy, I code VERY cautiously.  If my normal response to some specify
error would be to display lots of status info and abort, I would code
something non-aborty for daddy, or somehow make SURE he could never have that
error anyhow.  For that matter, I would code junior very cautiously because
daddy might not know what to do if junior went missing.

-------------------

Whoops, just saw Brian's other post where it looks like deadlock issues make
my original idea unworkable.  Oh, well.

Looks like Walter's best approach is to hunt down the apps that lock around
terminal I/O, like others suggested before.  Bound to be less trouble than
what I am about to suggest...

... if for any perverse reason Walter still likes the idea of having a timed
lock using separate task do an unconditional lock and update, try moving it
from a child process to a separate job.  Then the death of either parent or
child won't automatically mess up the other -- daddy can, for example, just
give up and log off.  Daddy & junior still communicate by message files, with
the added step that when daddy gives up after 15-odd seconds, he sends a
give-up message to junior.  Junior checks for that message after it gets the
lock but before it starts any updates, so if the lock takes too long to come
thru no harm is done.  Junior needs to run in a jobq with a generous job
limit, so he can always log on promptly -- I would probably create a new jobq
just for this.  (I'm thinking of junior as a quickie job streamed each time by
daddy, although an all-day background sleeper job might work too).  I might be
inclined to wait more than 15 seconds, to allow for extra overhead like a new
job logging on.


----- Original Message ----- 
From: "Brian Donaldson" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, June 05, 2008 07:20
Subject: Re: [HP3000-L] TurboIMAGE: Timed lock request


Since my previous posting I already tried this out and yes, the child gets
whacked if the  parent stops (for any reason.)

Probably not a good thing for data integrity if the child is in the middle
of updating a chain of records, so I (hopefully) solved the problem by
putting a DBXBEGIN around the DBLOCK and updates...........

Time will tell if it works or not.....

Brian.

On Wed, 4 Jun 2008 07:21:58 -0500, Jerry Fochtman <[log in to unmask]>
wrote:

>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 *

* 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 *