Junior could give the lock to daddy if you use a logical lock. You'd
need to create a new item in the set (or a new set with items that are
used for logical locks), and then junior would put his/her unique stamp
into the logical lock field (could be as simple as a program name), and
daddy checks for that value.
*******************************************
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 *
|
