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