RE: [U2] Inter-Process Control...
We are using Unix semaphores under Universe 10.0, with GCI C code that was ported from Pr1me by a third party. If you are interested in having a look at this I'll check with the powers-that-be. David Norman Senior Software Engineer - SA Ambulance Service ICT Services SA Health Government of South Australia Box 3, GPO Adelaide, South Australia 5001 *+61 8 8274 0384 * fax +61 8 8271 4844 * norman.da...@saambulance.com.au This e-mail may contain confidential information, which also may be legally privileged. Only the intended recipient(s) may access, use, distribute or copy this e-mail. If this e-mail is received in error, please inform the sender by return e-mail and delete the original. If there are doubts about the validity of this message, please contact the sender by telephone. It is the recipient's responsibility to check the e-mail and any attached files for viruses. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
hmmm. Are you running on a unix system? Maybe you could do this with a named pipe. have the waiting program open a named pipe for reading and wait and have the sending program open the named pipe for writing and send the message. George > -Original Message- > From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2- > us...@listserver.u2ug.org] On Behalf Of Larry Hiscock > Sent: Thursday, February 26, 2009 4:47 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Inter-Process Control... > > Yep ... sure miss sem$wait & sem$notify. You could accomplish the same > thing with a simple socket-based protocol. The main process could > listen on > a socket and wait for any of the sub-processes to connect and send a > message > via the socket. > > Larry Hiscock > Western Computer Services > > > -Original Message- > From: owner-u2-us...@listserver.u2ug.org > [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tom Whitmore > Sent: Thursday, February 26, 2009 12:25 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Inter-Process Control... > > I agree. I wrote two little programs. > > LOCK.TEST1 > 0001 LOCK 60 ELSE CRT '60 LOCKED' > 0002 CRT 'UNLOCKED' > > > LOCK.TEST2 > 0001 UNLOCK 60 > 0002 CRT '60 WAS UNLOCKED' > > LOCK.TEST1 locked 60 displayed "unlocked". > LOCK.TEST2 generated the error ' Program "LOCK.TEST2": Line 1, Lock 60 > not > owned by calling process' and then displayed "60 WAS UNLOCKED". > > As I was playing with the test programs as I type this. it looks like > the > first process needs to perform the first lock. The second process will > then > lock, and wait on the lock until the first process unlocks. I need to > be > able to support many-to-one processes. The "one" process waits on the > lock > and any of the "many" processes need to release the lock... which the > old > semaphore process supported... I confess, I'm spoiled. :) > > Thanks > Tom > -Original Message- > From: owner-u2-us...@listserver.u2ug.org > [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Kevin King > Sent: Thursday, February 26, 2009 2:01 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] Inter-Process Control... > > Tom, can you elaborate when you say "the only process that can modify > the > lock is the one that set it". Isn't that exactly how a semaphore is > supposed to work? Both processes should be able to set the lock but > only > one can have it at any moment in time. Or am I missing the point? > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Inter-Process Control...
Does Universe support the WAKE / PAUSE commands? We are a Unidata shop and use these commands to do something very similar to the problem you are trying tackle. Syntax WAKE pid Description The UniBasic WAKE command activates a UniData process (pid) that has been paused with either the ECL PAUSE command or the UniBasic PAUSE command. If the specified process has not already been paused, UniData disregards the next PAUSE issued for the process indicated by pid. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control... {Unclassified}
I do understand the concern, and the concept of "optimistic locking". Our application will have session timeout logic, so we can clean-up any locks. We will be developing tools to keep the control records cleaned up. Our problem is that we cannot use optimistic locking for the application. Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of HENDERSON MIKE, MR Sent: Thursday, February 26, 2009 6:06 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... {Unclassified} Tom, I don't think that 'maintaining a lock manager' is necessarily a good solution to non-persistent connections. A more conventional approach is for each connection to maintain the state of the record(s) it was going to modify - i.e. a 'before image'. Then, when it's time to apply the transaction, you lock the records (READU), and check that the records now on disk are in the same state as their before images. If they are, you can safely overwrite them. If they are not all the same as before, you unlock them and tell the user that someone else has changed the data and bad luck, please start again. This is known as the "optimistic locking" design philosophy. You also need a Phantom process to go through and clean out all the old 'before image' data that users never came back to. Of course, if you get too many oops-somebody-else-changed-it collisions, you may need to use persistent connections or a re-architecting of the data and/or application to reduce the frequency of collisions. Hope this helps Mike -Original Message- From: owner-u2-us...@listserver.u2ug.org On Behalf Of Tom Whitmore Sent: Friday, 27 February 2009 11:21 a.m. To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... One example of what I'm trying to do is develop a record lock manager (for the lack of a better description) for non-persistent connections. I need the lock manager to wakeup when there is a request for a readu/write/delete. The all the "responders" would need to send requests to the "lock manager". We have other processes that could use this functionality as well. I hope that helps, Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of iggch...@comcast.net Sent: Thursday, February 26, 2009 4:09 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Hey Tom, Are you trying to do something like... Program A B B B B DONE = 0 B B B B LOOP B B B B B B B B B B GOSUB ;* PROCESS STUFF B B B B B UNTIL DONE DO B B B B B B B B B B B IF SOME.EVENT THEN B B B B B B B B B B B B B B B B LOCK 10;* WAKE UP PROGRAM B B B B B B B B B B B B B END B B B B B B B B B B B LOCK 11 THEN B B B B B B B B B B B B B B B B B B B B UNLOCK 11 B B B B B B B B B B B B END ELSE B B B B B B B B B B B B B B B B B B UNLOCK 10;* PROGRAM B FINISHED B B B B B B B B B B B END B B B B B B B B B B B B SLEEP 30 B B B B B B REPEAT B B B B B B B STOP PROGRAM B B B B B B B B DONE = 0 B B B B B B LOOP B B B B B B B B B B B B B LOCK 10 THEN B B B B B B B B B B B B B B B B B B B B UNLOCK 10 B B B B B B B B B B B B B B ENDB ELSE B B B B B B B B B B B B B B B B B B B B LOCK 11 B B B B B B B B B B B B B B B B B B B B GOSUB ;* PROCESS STUFF B B B B B B B B B B B B B B B B B B B B B UNLOCK 11 B B B B B B B B B B B B B B END B B B B B B B UNTIL DONE DO B B B B B B B B B B B B B B SLEEP 30 B B B B B B B REPEAT B B B B B B B B STOP - Original Message - From: "Tom Whitmore" To: u2-users@listserver.u2ug.org Sent: Thursday, February 26, 2009 12:05:19 PM GMT -06:00 US/Canada Central Subject: RE: [U2] Inter-Process Control... Thank you for all the responses. I should have stated that we are a UniVerse shop. I did play with the lock/unlock but the only process that can modify the lock is the one that set it. B Also, I could not get the process to wait on the lock. B From the playing I did, lock/unlock seems very limited compared to what was available 15 years ago. Thanks Tom --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in
RE: [U2] Inter-Process Control... {Unclassified}
Tom, I don't think that 'maintaining a lock manager' is necessarily a good solution to non-persistent connections. A more conventional approach is for each connection to maintain the state of the record(s) it was going to modify - i.e. a 'before image'. Then, when it's time to apply the transaction, you lock the records (READU), and check that the records now on disk are in the same state as their before images. If they are, you can safely overwrite them. If they are not all the same as before, you unlock them and tell the user that someone else has changed the data and bad luck, please start again. This is known as the "optimistic locking" design philosophy. You also need a Phantom process to go through and clean out all the old 'before image' data that users never came back to. Of course, if you get too many oops-somebody-else-changed-it collisions, you may need to use persistent connections or a re-architecting of the data and/or application to reduce the frequency of collisions. Hope this helps Mike -Original Message- From: owner-u2-us...@listserver.u2ug.org On Behalf Of Tom Whitmore Sent: Friday, 27 February 2009 11:21 a.m. To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... One example of what I'm trying to do is develop a record lock manager (for the lack of a better description) for non-persistent connections. I need the lock manager to wakeup when there is a request for a readu/write/delete. The all the "responders" would need to send requests to the "lock manager". We have other processes that could use this functionality as well. I hope that helps, Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of iggch...@comcast.net Sent: Thursday, February 26, 2009 4:09 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Hey Tom, Are you trying to do something like... Program A B B B B DONE = 0 B B B B LOOP B B B B B B B B B B GOSUB ;* PROCESS STUFF B B B B B UNTIL DONE DO B B B B B B B B B B B IF SOME.EVENT THEN B B B B B B B B B B B B B B B B LOCK 10;* WAKE UP PROGRAM B B B B B B B B B B B B B END B B B B B B B B B B B LOCK 11 THEN B B B B B B B B B B B B B B B B B B B B UNLOCK 11 B B B B B B B B B B B B END ELSE B B B B B B B B B B B B B B B B B B UNLOCK 10;* PROGRAM B FINISHED B B B B B B B B B B B END B B B B B B B B B B B B SLEEP 30 B B B B B B REPEAT B B B B B B B STOP PROGRAM B B B B B B B B DONE = 0 B B B B B B LOOP B B B B B B B B B B B B B LOCK 10 THEN B B B B B B B B B B B B B B B B B B B B UNLOCK 10 B B B B B B B B B B B B B B ENDB ELSE B B B B B B B B B B B B B B B B B B B B LOCK 11 B B B B B B B B B B B B B B B B B B B B GOSUB ;* PROCESS STUFF B B B B B B B B B B B B B B B B B B B B B UNLOCK 11 B B B B B B B B B B B B B B END B B B B B B B UNTIL DONE DO B B B B B B B B B B B B B B SLEEP 30 B B B B B B B REPEAT B B B B B B B B STOP - Original Message - From: "Tom Whitmore" To: u2-users@listserver.u2ug.org Sent: Thursday, February 26, 2009 12:05:19 PM GMT -06:00 US/Canada Central Subject: RE: [U2] Inter-Process Control... Thank you for all the responses. I should have stated that we are a UniVerse shop. I did play with the lock/unlock but the only process that can modify the lock is the one that set it. B Also, I could not get the process to wait on the lock. B From the playing I did, lock/unlock seems very limited compared to what was available 15 years ago. Thanks Tom --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
A point to remember if using sockets (on UniVerse) is that your phantom will become an iphantom, and thus consume a license. Regards Bernard Lubin -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Larry Hiscock Sent: Friday, 27 February 2009 8:47 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... Yep ... sure miss sem$wait & sem$notify. You could accomplish the same thing with a simple socket-based protocol. The main process could listen on a socket and wait for any of the sub-processes to connect and send a message via the socket. Larry Hiscock Western Computer Services -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: Thursday, February 26, 2009 12:25 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... I agree. I wrote two little programs. LOCK.TEST1 0001 LOCK 60 ELSE CRT '60 LOCKED' 0002 CRT 'UNLOCKED' LOCK.TEST2 0001 UNLOCK 60 0002 CRT '60 WAS UNLOCKED' LOCK.TEST1 locked 60 displayed "unlocked". LOCK.TEST2 generated the error ' Program "LOCK.TEST2": Line 1, Lock 60 not owned by calling process' and then displayed "60 WAS UNLOCKED". As I was playing with the test programs as I type this. it looks like the first process needs to perform the first lock. The second process will then lock, and wait on the lock until the first process unlocks. I need to be able to support many-to-one processes. The "one" process waits on the lock and any of the "many" processes need to release the lock... which the old semaphore process supported... I confess, I'm spoiled. :) Thanks Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, February 26, 2009 2:01 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Tom, can you elaborate when you say "the only process that can modify the lock is the one that set it". Isn't that exactly how a semaphore is supposed to work? Both processes should be able to set the lock but only one can have it at any moment in time. Or am I missing the point? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
One example of what I'm trying to do is develop a record lock manager (for the lack of a better description) for non-persistent connections. I need the lock manager to wakeup when there is a request for a readu/write/delete. The all the "responders" would need to send requests to the "lock manager". We have other processes that could use this functionality as well. I hope that helps, Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of iggch...@comcast.net Sent: Thursday, February 26, 2009 4:09 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Hey Tom, Are you trying to do something like... Program A B B B B DONE = 0 B B B B LOOP B B B B B B B B B B GOSUB ;* PROCESS STUFF B B B B B UNTIL DONE DO B B B B B B B B B B B IF SOME.EVENT THEN B B B B B B B B B B B B B B B B LOCK 10;* WAKE UP PROGRAM B B B B B B B B B B B B B END B B B B B B B B B B B LOCK 11 THEN B B B B B B B B B B B B B B B B B B B B UNLOCK 11 B B B B B B B B B B B B END ELSE B B B B B B B B B B B B B B B B B B UNLOCK 10;* PROGRAM B FINISHED B B B B B B B B B B B END B B B B B B B B B B B B SLEEP 30 B B B B B B REPEAT B B B B B B B STOP PROGRAM B B B B B B B B DONE = 0 B B B B B B LOOP B B B B B B B B B B B B B LOCK 10 THEN B B B B B B B B B B B B B B B B B B B B UNLOCK 10 B B B B B B B B B B B B B B ENDB ELSE B B B B B B B B B B B B B B B B B B B B LOCK 11 B B B B B B B B B B B B B B B B B B B B GOSUB ;* PROCESS STUFF B B B B B B B B B B B B B B B B B B B B B UNLOCK 11 B B B B B B B B B B B B B B END B B B B B B B UNTIL DONE DO B B B B B B B B B B B B B B SLEEP 30 B B B B B B B REPEAT B B B B B B B B STOP - Original Message - From: "Tom Whitmore" To: u2-users@listserver.u2ug.org Sent: Thursday, February 26, 2009 12:05:19 PM GMT -06:00 US/Canada Central Subject: RE: [U2] Inter-Process Control... Thank you for all the responses. I should have stated that we are a UniVerse shop. I did play with the lock/unlock but the only process that can modify the lock is the one that set it. B Also, I could not get the process to wait on the lock. B From the playing I did, lock/unlock seems very limited compared to what was available 15 years ago. Thanks Tom --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
Yep ... sure miss sem$wait & sem$notify. You could accomplish the same thing with a simple socket-based protocol. The main process could listen on a socket and wait for any of the sub-processes to connect and send a message via the socket. Larry Hiscock Western Computer Services -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: Thursday, February 26, 2009 12:25 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... I agree. I wrote two little programs. LOCK.TEST1 0001 LOCK 60 ELSE CRT '60 LOCKED' 0002 CRT 'UNLOCKED' LOCK.TEST2 0001 UNLOCK 60 0002 CRT '60 WAS UNLOCKED' LOCK.TEST1 locked 60 displayed "unlocked". LOCK.TEST2 generated the error ' Program "LOCK.TEST2": Line 1, Lock 60 not owned by calling process' and then displayed "60 WAS UNLOCKED". As I was playing with the test programs as I type this. it looks like the first process needs to perform the first lock. The second process will then lock, and wait on the lock until the first process unlocks. I need to be able to support many-to-one processes. The "one" process waits on the lock and any of the "many" processes need to release the lock... which the old semaphore process supported... I confess, I'm spoiled. :) Thanks Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, February 26, 2009 2:01 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Tom, can you elaborate when you say "the only process that can modify the lock is the one that set it". Isn't that exactly how a semaphore is supposed to work? Both processes should be able to set the lock but only one can have it at any moment in time. Or am I missing the point? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Inter-Process Control...
Hey Tom, Are you trying to do something like... Program A B B B B DONE = 0 B B B B LOOP B B B B B B B B B B GOSUB ;* PROCESS STUFF B B B B B UNTIL DONE DO B B B B B B B B B B B IF SOME.EVENT THEN B B B B B B B B B B B B B B B B LOCK 10;* WAKE UP PROGRAM B B B B B B B B B B B B B END B B B B B B B B B B B LOCK 11 THEN B B B B B B B B B B B B B B B B B B B B UNLOCK 11 B B B B B B B B B B B B END ELSE B B B B B B B B B B B B B B B B B B UNLOCK 10;* PROGRAM B FINISHED B B B B B B B B B B B END B B B B B B B B B B B B SLEEP 30 B B B B B B REPEAT B B B B B B B STOP PROGRAM B B B B B B B B DONE = 0 B B B B B B LOOP B B B B B B B B B B B B B LOCK 10 THEN B B B B B B B B B B B B B B B B B B B B UNLOCK 10 B B B B B B B B B B B B B B ENDB ELSE B B B B B B B B B B B B B B B B B B B B LOCK 11 B B B B B B B B B B B B B B B B B B B B GOSUB ;* PROCESS STUFF B B B B B B B B B B B B B B B B B B B B B UNLOCK 11 B B B B B B B B B B B B B B END B B B B B B B UNTIL DONE DO B B B B B B B B B B B B B B SLEEP 30 B B B B B B B REPEAT B B B B B B B B STOP - Original Message - From: "Tom Whitmore" To: u2-users@listserver.u2ug.org Sent: Thursday, February 26, 2009 12:05:19 PM GMT -06:00 US/Canada Central Subject: RE: [U2] Inter-Process Control... Thank you for all the responses. I should have stated that we are a UniVerse shop. I did play with the lock/unlock but the only process that can modify the lock is the one that set it. B Also, I could not get the process to wait on the lock. B From the playing I did, lock/unlock seems very limited compared to what was available 15 years ago. Thanks Tom --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
I agree. I wrote two little programs. LOCK.TEST1 0001 LOCK 60 ELSE CRT '60 LOCKED' 0002 CRT 'UNLOCKED' LOCK.TEST2 0001 UNLOCK 60 0002 CRT '60 WAS UNLOCKED' LOCK.TEST1 locked 60 displayed "unlocked". LOCK.TEST2 generated the error ' Program "LOCK.TEST2": Line 1, Lock 60 not owned by calling process' and then displayed "60 WAS UNLOCKED". As I was playing with the test programs as I type this. it looks like the first process needs to perform the first lock. The second process will then lock, and wait on the lock until the first process unlocks. I need to be able to support many-to-one processes. The "one" process waits on the lock and any of the "many" processes need to release the lock... which the old semaphore process supported... I confess, I'm spoiled. :) Thanks Tom -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, February 26, 2009 2:01 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Inter-Process Control... Tom, can you elaborate when you say "the only process that can modify the lock is the one that set it". Isn't that exactly how a semaphore is supposed to work? Both processes should be able to set the lock but only one can have it at any moment in time. Or am I missing the point? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Inter-Process Control...
Tom, can you elaborate when you say "the only process that can modify the lock is the one that set it". Isn't that exactly how a semaphore is supposed to work? Both processes should be able to set the lock but only one can have it at any moment in time. Or am I missing the point? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
Thank you for all the responses. I should have stated that we are a UniVerse shop. I did play with the lock/unlock but the only process that can modify the lock is the one that set it. Also, I could not get the process to wait on the lock. From the playing I did, lock/unlock seems very limited compared to what was available 15 years ago. Thanks Tom --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
If this is the approach you go for, I would recommend that you use a resource lock, rather than a record lock (no need to open file etc etc)... Resource locks are set system wide, so are not limited to a single account / file / record, and are accessed with the LOCK/UNLOCK UniBasic commands... You have 64 locks to use as you see fit.. In my mind the solution depends on how quickly you need the second process to "wake up".. if a 30sec+ delay is ok, then using a resource lock could be an option with a SLEEP 30 on the locked condition.. Otherwise I would be looking at launching the "child" job as required, rather than having it wait for work.. Regards Raymond de Bourbon From: owner-u2-us...@listserver.u2ug.org [owner-u2-us...@listserver.u2ug.org] On Behalf Of kishor [kis...@parmars.com] Sent: 26 February 2009 07:52 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Inter-Process Control... Couldn't you get the second phantom to lock an empty record & release it when it is done? The first phantom can wait on the readu lock. Regards, Kishor Parmar -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: 26 February 2009 12:57 To: u2-users@listserver.u2ug.org Subject: [U2] Inter-Process Control... We have two phantom processes. The first phantom needs to wait for an event to occur with the second phantom. I realize that I could have the first phantom loop, check, then sleep. However, I'd like to avoid wasting resources. Back on the Prime, I could use semaphores, to control this flow and this was clean, and simple. Has anyone come across a means of having a phantom wait on "something", so it only wakes up when it needs to perform its function? To try to explain better: Phantom1: Loop Wait on semaphore Perform a shared process (batch updates would be an example) Repeat Phantom2 (3, 4, ...): Loop Process records Notify semaphore Repeat Thanks, Tom Whitmore RATEX Business Solutions --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Inter-Process Control...
> We have two phantom processes. The first phantom needs to wait for an event > to occur with the second phantom. I realize that I could have the first > phantom loop, check, then sleep. However, I'd like to avoid wasting > resources. Back on the Prime, I could use semaphores, to control this flow > and this was clean, and simple. Has anyone come across a means of having a > phantom wait on "something", so it only wakes up when it needs to perform its > function? If you use the LOCK command (e.g.: LOCK 17) you're using semaphores. Does that suit your needs? If you're on UniData, you may want to take a look at PAUSE and WAKE. It gives you a way for a process to go to sleep, allowing another process to wake it up. Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Inter-Process Control...
Hi Tom, You could use the LOCK/UNLOCK Basic statements. These are designed for interprocess control, but I dont know if they will achieve your goal of not wasting resources. So in each program you would have something like this: LOOP UNTIL LOCK n DO RQM REPEAT process stuff here UNLOCK n where n is a number between 0 and 63. The problem with this is that the process has to check on the lock, sleep, wake up, check on the lock etc. It doesn't just stay blocked until the lock is available. The alternative would be to us a READU on a file that is already opened by the program. I don't know which method would be the least resource intensive - it would be interesting to experiment and find out. cheers, asvin owner-u2-us...@listserver.u2ug.org wrote on 26/02/2009 12:57:14: > Tom Whitmore > Sent by: owner-u2-us...@listserver.u2ug.org > > Feb 26 2009 13:23 > > Mail Size: 4681 > > Please respond to > u2-users@listserver.u2ug.org > > To > > "u2-users@listserver.u2ug.org" > > cc > > Subject > > [U2] Inter-Process Control... > > Entity > > > > We have two phantom processes. The first phantom needs to wait for an event > to occur with the second phantom. I realize that I could have the first > phantom loop, check, then sleep. However, I'd like to avoid wasting > resources. Back on the Prime, I could use semaphores, to control this flow > and this was clean, and simple. Has anyone come across a means of having a > phantom wait on "something", so it only wakes up when it needs to perform its > function? > > To try to explain better: > > Phantom1: > Loop > Wait on semaphore > Perform a shared process (batch updates would be an example) > Repeat > > > Phantom2 (3, 4, ...): > Loop > Process records > Notify semaphore > Repeat > > Thanks, > Tom Whitmore > RATEX Business Solutions > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest. HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England - Number 14259 Authorised and regulated by the Financial Services Authority. - SAVE PAPER - THINK BEFORE YOU PRINT! This transmission has been issued by a member of the HSBC Group "HSBC" for the information of the addressee only and should not be reproduced and/or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Inter-Process Control...
Tom, Sounds like a classic application for sockets. Inter process communications. Phantom 1 opens a server socket on a known port/IP and waits on a blocked read for something (like a process name to run for example). Process 2 opens a socket on the known port/ip and writes the name of the process it would like to have run and perhaps provides some parameters as either a command line or second write. Process 1 fires off the requested process and writes and response. Tom Whitmore wrote: > We have two phantom processes. The first phantom needs to wait for an event > to occur with the second phantom. I realize that I could have the first > phantom loop, check, then sleep. However, I'd like to avoid wasting > resources. Back on the Prime, I could use semaphores, to control this flow > and this was clean, and simple. Has anyone come across a means of having a > phantom wait on "something", so it only wakes up when it needs to perform its > function? > > To try to explain better: > > Phantom1: > Loop > Wait on semaphore > Perform a shared process (batch updates would be an example) > Repeat > > > Phantom2 (3, 4, ...): > Loop > Process records > Notify semaphore > Repeat > > Thanks, > Tom Whitmore > RATEX Business Solutions > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > > -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com /"Come To The Dark Side, We Have Cookies."/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Inter-Process Control...
Couldn't you get the second phantom to lock an empty record & release it when it is done? The first phantom can wait on the readu lock. Regards, Kishor Parmar -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: 26 February 2009 12:57 To: u2-users@listserver.u2ug.org Subject: [U2] Inter-Process Control... We have two phantom processes. The first phantom needs to wait for an event to occur with the second phantom. I realize that I could have the first phantom loop, check, then sleep. However, I'd like to avoid wasting resources. Back on the Prime, I could use semaphores, to control this flow and this was clean, and simple. Has anyone come across a means of having a phantom wait on "something", so it only wakes up when it needs to perform its function? To try to explain better: Phantom1: Loop Wait on semaphore Perform a shared process (batch updates would be an example) Repeat Phantom2 (3, 4, ...): Loop Process records Notify semaphore Repeat Thanks, Tom Whitmore RATEX Business Solutions --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Inter-Process Control...
We have two phantom processes. The first phantom needs to wait for an event to occur with the second phantom. I realize that I could have the first phantom loop, check, then sleep. However, I'd like to avoid wasting resources. Back on the Prime, I could use semaphores, to control this flow and this was clean, and simple. Has anyone come across a means of having a phantom wait on "something", so it only wakes up when it needs to perform its function? To try to explain better: Phantom1: Loop Wait on semaphore Perform a shared process (batch updates would be an example) Repeat Phantom2 (3, 4, ...): Loop Process records Notify semaphore Repeat Thanks, Tom Whitmore RATEX Business Solutions --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/