Re: [U2] Record locks (Unidata 7.2)
The lock isn't released since another user set it. On 10/02/2013 22:35, Peter Cheney wrote: In the example below what happens to the lock? Does it release if the write is not executed? If not shouldn't you have a RELEASE statement at the end after the last END? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Saturday, 9 February 2013 3:57 To: U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) I should add that (in our test account) I switched to the READU statement along with a LOCKED clause - READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END I locked one of the records in the list I was processing. When the program was working on that record, the CRT statement was executed, and the program moved right along processing the rest of the list; and record I had locked was not updated. Looking through the 'UniBasic Commands Reference' PDF, I found 'RECORDLOCKED (file.var, rec.id.expr)'. Perhaps this could be used within a LOOP to control things, allowing terminal input where the user can choose what to do about the record lock? I've decided to write the data to a new file, so this is no longer a big issue for me. If I had created the program using our vendor's tool kit, the generated code would have added all the appropriate gunk the system uses for record locks. The responses have been interesting as I've been looking for a chance to better understand how Unidata shops handle locks. Thank you, Jon Wells From: Tony Gravagno3xk547...@sneakemail.com To: u2-users@listserver.u2ug.org Sent: Friday, February 8, 2013 2:30 AM Subject: Re: [U2] Record locks (Unidata 7.2) I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. That said, when we used to have a lot of people in an office and a dumb terminal beeping was a recognized message to everyone, it was OK (generally) to just do the READU. These days with more alternative UIs, thick-client, thin-client, web services, mobile, etc, there's no one to hear that beep. So for modern development I would agree that you really don't want an unconditional lock hanging around, you want a Locked clause with logic to rollback the transaction and exit gracefully, perhaps with a message sent to the site admin. The penalty for Not having a Locked clause with a new UI is that the port will hang, the UI will receive a timeout (which many clients aren't prepared to process), and the DBMS port could be sitting there indefinitely with no one aware of the condition. This can cascade to multiple ports until suddenly everything grinds to a halt and GUI users around the world are unable to access the app. I believe some heads will be nodding here because I hear about this happening occasionally. T From: Wjhonson Then you're misunderstanding what I'm saying. From: Kevin King +1. Well stated. Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. From: Wjhonson I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users --- Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect
Re: [U2] Record locks (Unidata 7.2)
The sample has a LOCKED which the lock is not obtained so that's okay. It also has a THEN clause with a WRITE statement so the lock is released. The only condition not covered is if there is no record currently in the file. The lock is obtained and unless there is a WRITE or RELEASE below the last END, then the lock is held by the program until the program terminates. You are correct and there should be an ELSE clause added with a RELEASE to cover all conditions. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Peter Cheney Sent: Sunday, February 10, 2013 2:36 PM To: Jon Wells; U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) In the example below what happens to the lock? Does it release if the write is not executed? If not shouldn't you have a RELEASE statement at the end after the last END? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Saturday, 9 February 2013 3:57 To: U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) I should add that (in our test account) I switched to the READU statement along with a LOCKED clause - READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END I locked one of the records in the list I was processing. When the program was working on that record, the CRT statement was executed, and the program moved right along processing the rest of the list; and record I had locked was not updated. Looking through the 'UniBasic Commands Reference' PDF, I found 'RECORDLOCKED (file.var, rec.id.expr)'. Perhaps this could be used within a LOOP to control things, allowing terminal input where the user can choose what to do about the record lock? I've decided to write the data to a new file, so this is no longer a big issue for me. If I had created the program using our vendor's tool kit, the generated code would have added all the appropriate gunk the system uses for record locks. The responses have been interesting as I've been looking for a chance to better understand how Unidata shops handle locks. Thank you, Jon Wells From: Tony Gravagno 3xk547...@sneakemail.com To: u2-users@listserver.u2ug.org Sent: Friday, February 8, 2013 2:30 AM Subject: Re: [U2] Record locks (Unidata 7.2) I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. That said, when we used to have a lot of people in an office and a dumb terminal beeping was a recognized message to everyone, it was OK (generally) to just do the READU. These days with more alternative UIs, thick-client, thin-client, web services, mobile, etc, there's no one to hear that beep. So for modern development I would agree that you really don't want an unconditional lock hanging around, you want a Locked clause with logic to rollback the transaction and exit gracefully, perhaps with a message sent to the site admin. The penalty for Not having a Locked clause with a new UI is that the port will hang, the UI will receive a timeout (which many clients aren't prepared to process), and the DBMS port could be sitting there indefinitely with no one aware of the condition. This can cascade to multiple ports until suddenly everything grinds to a halt and GUI users around the world are unable to access the app. I believe some heads will be nodding here because I hear about this happening occasionally. T From: Wjhonson Then you're misunderstanding what I'm saying. From: Kevin King +1. Well stated. Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. From: Wjhonson I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
In the example below what happens to the lock? Does it release if the write is not executed? If not shouldn't you have a RELEASE statement at the end after the last END? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Saturday, 9 February 2013 3:57 To: U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) I should add that (in our test account) I switched to the READU statement along with a LOCKED clause - READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END I locked one of the records in the list I was processing. When the program was working on that record, the CRT statement was executed, and the program moved right along processing the rest of the list; and record I had locked was not updated. Looking through the 'UniBasic Commands Reference' PDF, I found 'RECORDLOCKED (file.var, rec.id.expr)'. Perhaps this could be used within a LOOP to control things, allowing terminal input where the user can choose what to do about the record lock? I've decided to write the data to a new file, so this is no longer a big issue for me. If I had created the program using our vendor's tool kit, the generated code would have added all the appropriate gunk the system uses for record locks. The responses have been interesting as I've been looking for a chance to better understand how Unidata shops handle locks. Thank you, Jon Wells From: Tony Gravagno 3xk547...@sneakemail.com To: u2-users@listserver.u2ug.org Sent: Friday, February 8, 2013 2:30 AM Subject: Re: [U2] Record locks (Unidata 7.2) I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. That said, when we used to have a lot of people in an office and a dumb terminal beeping was a recognized message to everyone, it was OK (generally) to just do the READU. These days with more alternative UIs, thick-client, thin-client, web services, mobile, etc, there's no one to hear that beep. So for modern development I would agree that you really don't want an unconditional lock hanging around, you want a Locked clause with logic to rollback the transaction and exit gracefully, perhaps with a message sent to the site admin. The penalty for Not having a Locked clause with a new UI is that the port will hang, the UI will receive a timeout (which many clients aren't prepared to process), and the DBMS port could be sitting there indefinitely with no one aware of the condition. This can cascade to multiple ports until suddenly everything grinds to a halt and GUI users around the world are unable to access the app. I believe some heads will be nodding here because I hear about this happening occasionally. T From: Wjhonson Then you're misunderstanding what I'm saying. From: Kevin King +1. Well stated. Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. From: Wjhonson I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users --- Note: This email (inc all attachments) is for the use of the intended recipient(s) only. Privileged or confidential information may be contained in this communication. If you have received this email in error, please notify the sender immediately and then delete all copies of this message from your computer network. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future, then please respond to the sender to this effect. We have taken precautions to minimise the risk of transmitting software viruses
Re: [U2] Record locks (Unidata 7.2)
On 08/02/13 07:30, Tony Gravagno wrote: I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. And even in an office, if you code properly, an unprotected READU can make sense. The proper way to program data entry (if you can) is to read everything, get the info from the user, and then RERUN THE TRANSACTION using locks to stash it safely away. That way, you should never get a program hanging on a lock for more than a second or so (I know I know ...) Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
We don't really have the luxury to rewrite the entire system. But we can fix one program a day -Original Message- From: Wols Lists antli...@youngman.org.uk To: u2-users u2-users@listserver.u2ug.org Sent: Fri, Feb 8, 2013 1:22 am Subject: Re: [U2] Record locks (Unidata 7.2) On 08/02/13 07:30, Tony Gravagno wrote: I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. And even in an office, if you code properly, an unprotected READU can make sense. The proper way to program data entry (if you can) is to read everything, get the info from the user, and then RERUN THE TRANSACTION using locks to stash it safely away. That way, you should never get a program hanging on a lock for more than a second or so (I know I know ...) Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
I should add that (in our test account) I switched to the READU statement along with a LOCKED clause - READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END I locked one of the records in the list I was processing. When the program was working on that record, the CRT statement was executed, and the program moved right along processing the rest of the list; and record I had locked was not updated. Looking through the 'UniBasic Commands Reference' PDF, I found 'RECORDLOCKED (file.var, rec.id.expr)'. Perhaps this could be used within a LOOP to control things, allowing terminal input where the user can choose what to do about the record lock? I've decided to write the data to a new file, so this is no longer a big issue for me. If I had created the program using our vendor's tool kit, the generated code would have added all the appropriate gunk the system uses for record locks. The responses have been interesting as I've been looking for a chance to better understand how Unidata shops handle locks. Thank you, Jon Wells From: Tony Gravagno 3xk547...@sneakemail.com To: u2-users@listserver.u2ug.org Sent: Friday, February 8, 2013 2:30 AM Subject: Re: [U2] Record locks (Unidata 7.2) I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. That said, when we used to have a lot of people in an office and a dumb terminal beeping was a recognized message to everyone, it was OK (generally) to just do the READU. These days with more alternative UIs, thick-client, thin-client, web services, mobile, etc, there's no one to hear that beep. So for modern development I would agree that you really don't want an unconditional lock hanging around, you want a Locked clause with logic to rollback the transaction and exit gracefully, perhaps with a message sent to the site admin. The penalty for Not having a Locked clause with a new UI is that the port will hang, the UI will receive a timeout (which many clients aren't prepared to process), and the DBMS port could be sitting there indefinitely with no one aware of the condition. This can cascade to multiple ports until suddenly everything grinds to a halt and GUI users around the world are unable to access the app. I believe some heads will be nodding here because I hear about this happening occasionally. T From: Wjhonson Then you're misunderstanding what I'm saying. From: Kevin King +1. Well stated. Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. From: Wjhonson I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
Jon the LOCKED clause acts like a Then...else You can only take one branch. So for the locked record, it took the LOCKED branch and ignored the END THEN branch Because the Locked clause is another case you see? Like Readu CASE Locked: do this CASE NotLockedANd Exists: do that CASE NotLockedANDDoesNotExist: do a third thing You understand? This is why you MUST have a LOOPing structure around the Locking. Which is what I sent you the other day. -Original Message- From: Jon Wells jwaytwe...@yahoo.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Fri, Feb 8, 2013 9:57 am Subject: Re: [U2] Record locks (Unidata 7.2) I should add that (in our test account) I switched to the READU statement along with a LOCKED clause - READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END I locked one of the records in the list I was processing. When the program was working on that record, the CRT statement was executed, and the program moved right along processing the rest of the list; and record I had locked was not updated. Looking through the 'UniBasic Commands Reference' PDF, I found 'RECORDLOCKED (file.var, rec.id.expr)'. Perhaps this could be used within a LOOP to control things, allowing terminal input where the user can choose what to do about the record lock? I've decided to write the data to a new file, so this is no longer a big issue for me. If I had created the program using our vendor's tool kit, the generated code would have added all the appropriate gunk the system uses for record locks. The responses have been interesting as I've been looking for a chance to better understand how Unidata shops handle locks. Thank you, Jon Wells From: Tony Gravagno 3xk547...@sneakemail.com To: u2-users@listserver.u2ug.org Sent: Friday, February 8, 2013 2:30 AM Subject: Re: [U2] Record locks (Unidata 7.2) I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. That said, when we used to have a lot of people in an office and a dumb terminal beeping was a recognized message to everyone, it was OK (generally) to just do the READU. These days with more alternative UIs, thick-client, thin-client, web services, mobile, etc, there's no one to hear that beep. So for modern development I would agree that you really don't want an unconditional lock hanging around, you want a Locked clause with logic to rollback the transaction and exit gracefully, perhaps with a message sent to the site admin. The penalty for Not having a Locked clause with a new UI is that the port will hang, the UI will receive a timeout (which many clients aren't prepared to process), and the DBMS port could be sitting there indefinitely with no one aware of the condition. This can cascade to multiple ports until suddenly everything grinds to a halt and GUI users around the world are unable to access the app. I believe some heads will be nodding here because I hear about this happening occasionally. T From: Wjhonson Then you're misunderstanding what I'm saying. From: Kevin King +1. Well stated. Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. From: Wjhonson I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
One technique that I have used, in the past, has been to save a list of locked ID's and at the end of the program re-try them when all else has finished. Then if they are still locked the program will send a message to me or the operator to alert that there is a locked record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Friday, February 08, 2013 9:57 AM To: U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) I should add that (in our test account) I switched to the READU statement along with a LOCKED clause - READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END I locked one of the records in the list I was processing. When the program was working on that record, the CRT statement was executed, and the program moved right along processing the rest of the list; and record I had locked was not updated. Looking through the 'UniBasic Commands Reference' PDF, I found 'RECORDLOCKED (file.var, rec.id.expr)'. Perhaps this could be used within a LOOP to control things, allowing terminal input where the user can choose what to do about the record lock? I've decided to write the data to a new file, so this is no longer a big issue for me. If I had created the program using our vendor's tool kit, the generated code would have added all the appropriate gunk the system uses for record locks. The responses have been interesting as I've been looking for a chance to better understand how Unidata shops handle locks. Thank you, Jon Wells From: Tony Gravagno 3xk547...@sneakemail.com To: u2-users@listserver.u2ug.org Sent: Friday, February 8, 2013 2:30 AM Subject: Re: [U2] Record locks (Unidata 7.2) I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. That said, when we used to have a lot of people in an office and a dumb terminal beeping was a recognized message to everyone, it was OK (generally) to just do the READU. These days with more alternative UIs, thick-client, thin-client, web services, mobile, etc, there's no one to hear that beep. So for modern development I would agree that you really don't want an unconditional lock hanging around, you want a Locked clause with logic to rollback the transaction and exit gracefully, perhaps with a message sent to the site admin. The penalty for Not having a Locked clause with a new UI is that the port will hang, the UI will receive a timeout (which many clients aren't prepared to process), and the DBMS port could be sitting there indefinitely with no one aware of the condition. This can cascade to multiple ports until suddenly everything grinds to a halt and GUI users around the world are unable to access the app. I believe some heads will be nodding here because I hear about this happening occasionally. T From: Wjhonson Then you're misunderstanding what I'm saying. From: Kevin King +1. Well stated. Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. From: Wjhonson I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
You should have written it something like this: TRY.AGAIN: READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED SLEEP 2 GOTO TRY.AGAIN END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END You have to add the label TRY.AGAIN: so you have a jump point then add the SLEEP command for 2 seconds and lastly the GOTO command so after the SLEEP expires, execution remains at the READU command. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Friday, February 08, 2013 9:57 AM To: U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) I should add that (in our test account) I switched to the READU statement along with a LOCKED clause - READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END I locked one of the records in the list I was processing. When the program was working on that record, the CRT statement was executed, and the program moved right along processing the rest of the list; and record I had locked was not updated. Looking through the 'UniBasic Commands Reference' PDF, I found 'RECORDLOCKED (file.var, rec.id.expr)'. Perhaps this could be used within a LOOP to control things, allowing terminal input where the user can choose what to do about the record lock? I've decided to write the data to a new file, so this is no longer a big issue for me. If I had created the program using our vendor's tool kit, the generated code would have added all the appropriate gunk the system uses for record locks. The responses have been interesting as I've been looking for a chance to better understand how Unidata shops handle locks. Thank you, Jon Wells From: Tony Gravagno 3xk547...@sneakemail.com To: u2-users@listserver.u2ug.org Sent: Friday, February 8, 2013 2:30 AM Subject: Re: [U2] Record locks (Unidata 7.2) I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. That said, when we used to have a lot of people in an office and a dumb terminal beeping was a recognized message to everyone, it was OK (generally) to just do the READU. These days with more alternative UIs, thick-client, thin-client, web services, mobile, etc, there's no one to hear that beep. So for modern development I would agree that you really don't want an unconditional lock hanging around, you want a Locked clause with logic to rollback the transaction and exit gracefully, perhaps with a message sent to the site admin. The penalty for Not having a Locked clause with a new UI is that the port will hang, the UI will receive a timeout (which many clients aren't prepared to process), and the DBMS port could be sitting there indefinitely with no one aware of the condition. This can cascade to multiple ports until suddenly everything grinds to a halt and GUI users around the world are unable to access the app. I believe some heads will be nodding here because I hear about this happening occasionally. T From: Wjhonson Then you're misunderstanding what I'm saying. From: Kevin King +1. Well stated. Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. From: Wjhonson I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
I would also add some type of bailout logic in case the record NEVER frees up (user went home for the weekend). Obviously, you need to make the call on this on a case by case situation, but you would not want a critical process (like month end) to fail because Joe Blow left a record locked. Should you finish the other 99.% of month end or have it fail completely? Again, you need to make this call on a case by case basis for your application. MAX.TRIES = 1000 TRIES = 0 TRY.AGAIN: READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED SLEEP 2 TRIES += 1 IF (TRIES = MAX.TRIES) THEN * track this condition somehow and move on GOTO SKIP END GOTO TRY.AGAIN END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END SKIP: John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Woodward, Bob Sent: Friday, February 08, 2013 1:10 PM To: Jon Wells; U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) You should have written it something like this: TRY.AGAIN: READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED SLEEP 2 GOTO TRY.AGAIN END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END You have to add the label TRY.AGAIN: so you have a jump point then add the SLEEP command for 2 seconds and lastly the GOTO command so after the SLEEP expires, execution remains at the READU command. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Friday, February 08, 2013 9:57 AM To: U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) I should add that (in our test account) I switched to the READU statement along with a LOCKED clause - READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END I locked one of the records in the list I was processing. When the program was working on that record, the CRT statement was executed, and the program moved right along processing the rest of the list; and record I had locked was not updated. Looking through the 'UniBasic Commands Reference' PDF, I found 'RECORDLOCKED (file.var, rec.id.expr)'. Perhaps this could be used within a LOOP to control things, allowing terminal input where the user can choose what to do about the record lock? I've decided to write the data to a new file, so this is no longer a big issue for me. If I had created the program using our vendor's tool kit, the generated code would have added all the appropriate gunk the system uses for record locks. The responses have been interesting as I've been looking for a chance to better understand how Unidata shops handle locks. Thank you, Jon Wells From: Tony Gravagno 3xk547...@sneakemail.com To: u2-users@listserver.u2ug.org Sent: Friday, February 8, 2013 2:30 AM Subject: Re: [U2] Record locks (Unidata 7.2) I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. That said, when we used to have a lot of people in an office and a dumb terminal beeping was a recognized message to everyone, it was OK (generally) to just do the READU. These days with more alternative UIs, thick-client, thin-client, web services, mobile, etc, there's no one to hear that beep. So for modern development I would agree that you really don't want an unconditional lock hanging around, you want a Locked clause with logic to rollback the transaction and exit gracefully, perhaps with a message sent to the site admin. The penalty for Not having a Locked clause with a new UI is that the port will hang, the UI will receive a timeout (which many clients aren't prepared to process), and the DBMS port could be sitting there indefinitely with no one aware of the condition. This can cascade to multiple ports until suddenly everything grinds to a halt and GUI users around the world are unable to access the app. I believe some heads will be nodding here because I hear about this happening occasionally. T From: Wjhonson Then you're misunderstanding what I'm saying. From: Kevin King +1. Well stated. Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using
Re: [U2] Record locks (Unidata 7.2)
Oh no, you don't have to add a label and you don't have to use GOTO. TRY_AGAIN = 1 LOOP WHILE TRY_AGAIN READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED SLEEP 2 END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID TRY_AGAIN = 0 END REPEAT On 08/02/2013 18:10, Woodward, Bob wrote: You should have written it something like this: TRY.AGAIN: READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED SLEEP 2 GOTO TRY.AGAIN END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END You have to add the label TRY.AGAIN: so you have a jump point then add the SLEEP command for 2 seconds and lastly the GOTO command so after the SLEEP expires, execution remains at the READU command. BobW ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
On second thought this won't do either since it hasn't got an ELSE clause. ERR = '' LOOP TRY_AGAIN = 0 READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED - (Q)uit or Enter INPUT REPLY: IF REPLY # 'Q' THEN TRY_AGAIN = 1 ELSE ABORT END ELSE STU.REC = '' UNTIL NOT(TRY_AGAIN) REPEAT STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID On 08/02/2013 20:12, Mecki Foerthmann wrote: Oh no, you don't have to add a label and you don't have to use GOTO. TRY_AGAIN = 1 LOOP WHILE TRY_AGAIN READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED SLEEP 2 END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID TRY_AGAIN = 0 END REPEAT On 08/02/2013 18:10, Woodward, Bob wrote: You should have written it something like this: TRY.AGAIN: READU STU.REC FROM STU.FILE, STU.ID LOCKED CRT STU.ID: RECORD IS LOCKED SLEEP 2 GOTO TRY.AGAIN END THEN STU.REC48 = INST.CRED STU.REC49 = INET.CRED WRITE STU.REC ON STU.FILE, STU.ID END You have to add the label TRY.AGAIN: so you have a jump point then add the SLEEP command for 2 seconds and lastly the GOTO command so after the SLEEP expires, execution remains at the READU command. BobW ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
I agree, though I find the LOCKED clause is needed more often than not in our particular environment. I've always used the following logic to determine which course of action to take. In this example: READU REC FROM FILE, ID THEN [do something] END ELSE [do something else] END [operate on REC] WRITE REC ON FILE, ID if there is an INPUT statement or a READU attempt on another record anywhere between the first READU and the WRITE in this program or any other that will lock the same record, then there needs to be a LOCKED clause and a loop. In my experience, leaving a user session unresponsive due to a missing LOCKED clause leads to closing the terminal emulator window or power cycling a dumb terminal. Sometimes this simply orphans the session, and the user hits the lock a 2nd time when they log back in. Not fun for the user or the support desk employee. We have a standard subroutine call for all LOCKED clauses that tells the user who has the lock so they can contact the culprit directly and leave I.T. out of the loop. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Woodward, Bob Sent: Thursday, February 07, 2013 3:56 PM To: U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Thursday, February 07, 2013 3:41 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause -Original Message- From: Woodward, Bob bob_woodw...@k2sports.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Feb 7, 2013 2:43 pm Subject: Re: [U2] Record locks (Unidata 7.2) You're exactly right. The only time you REALLY need the LOCKED clause if there is some need to change that approach. That was what I attempted to show in my first response. I guess I was a bit terse in that one, though. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Anthonys Lists Sent: Thursday, February 07, 2013 2:21 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) On 07/02/2013 20:46, Jon Wells wrote: What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Somebody will correct me if I'm wrong, but I thought that was exactly what READU did! If you don't provide a LOCKED clause, READU will hang and wait until the lock clears, then read and lock the record. As I say, check the docu and make sure I'm right ... I've never had to bother much with locks ... Cheers, Wol Thank you, Jon Wells ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
The READU statement has a LOCKED clause that is true if a record is locked. You can put all your locking ha logic in there. READU record FROM filevariable,itemID THEN code if record exists and isn't locked (optional) LOCKED code to handle locked record condition (optional) END ELSE code if record doesn't exist (required) END Now if you put that into a loop you can display a message and give the user the option to try again or abort. And if you put the code into a subroutine you can use that in all your programs with a single line like this. CALL SR.READU(record,filevariable,ItemID,Option,Err) On 06/02/2013 21:52, Jon Wells wrote: Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
Perhaps we should apply a little Systems Analysis 101 here - ask some questions. I'm not convinced that the original request completely described the need. What is the logical scenario (batch update, transaction entry, file maintenance, etc.)? Once a lock is removed, do you want your copy of the record to be written regardless of why it was locked in the first place, possibly overwriting someone else's changes? Why do you want to do it this way? I'm sure there are other questions, but these will do for a start. If, as Will suggested, this is a job application test, the OP should answer that more information is needed. Technically, what was described is completely doable, but is it the correct thing to do? Regards, Charlie Noah Tiny Bear's Wild Bird Store Home of Safety Net Shipping http://www.TinyBearWildBirdStore.com Toll Free: 1-855-TinyBear (855-846-9232) On 02-07-2013 2:26 AM, Mecki Foerthmann wrote: The READU statement has a LOCKED clause that is true if a record is locked. You can put all your locking ha logic in there. READU record FROM filevariable,itemID THEN code if record exists and isn't locked (optional) LOCKED code to handle locked record condition (optional) END ELSE code if record doesn't exist (required) END Now if you put that into a loop you can display a message and give the user the option to try again or abort. And if you put the code into a subroutine you can use that in all your programs with a single line like this. CALL SR.READU(record,filevariable,ItemID,Option,Err) On 06/02/2013 21:52, Jon Wells wrote: Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
Sorry Mecki but I think you have the LOCKED in the wrong place. At least in my version of Unidata. It comes before the THEN segment so the full, proper syntax would be: READU xxx FROM xxx, xxx ON ERROR Xxx what to do if a hard error like file not open END LOCKED Xxx what to do if locked END THEN Xxx what to do if lock is obtained and record is read END ELSE Xxx what to do if lock is obtained but record does not exist. END There is a second format for the READU command but it's a lot easier if the OP just reads about, himself, in the HELP information. HELP UNIBASIC READU from ECL in Unidata will get him that. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Thursday, February 07, 2013 12:27 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) The READU statement has a LOCKED clause that is true if a record is locked. You can put all your locking ha logic in there. READU record FROM filevariable,itemID THEN code if record exists and isn't locked (optional) LOCKED code to handle locked record condition (optional) END ELSE code if record doesn't exist (required) END Now if you put that into a loop you can display a message and give the user the option to try again or abort. And if you put the code into a subroutine you can use that in all your programs with a single line like this. CALL SR.READU(record,filevariable,ItemID,Option,Err) On 06/02/2013 21:52, Jon Wells wrote: Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Thank you, Jon Wells From: Woodward, Bob bob_woodw...@k2sports.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thursday, February 7, 2013 12:35 PM Subject: Re: [U2] Record locks (Unidata 7.2) Sorry Mecki but I think you have the LOCKED in the wrong place. At least in my version of Unidata. It comes before the THEN segment so the full, proper syntax would be: READU xxx FROM xxx, xxx ON ERROR Xxx what to do if a hard error like file not open END LOCKED Xxx what to do if locked END THEN Xxx what to do if lock is obtained and record is read END ELSE Xxx what to do if lock is obtained but record does not exist. END There is a second format for the READU command but it's a lot easier if the OP just reads about, himself, in the HELP information. HELP UNIBASIC READU from ECL in Unidata will get him that. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Thursday, February 07, 2013 12:27 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) The READU statement has a LOCKED clause that is true if a record is locked. You can put all your locking ha logic in there. READU record FROM filevariable,itemID THEN code if record exists and isn't locked (optional) LOCKED code to handle locked record condition (optional) END ELSE code if record doesn't exist (required) END Now if you put that into a loop you can display a message and give the user the option to try again or abort. And if you put the code into a subroutine you can use that in all your programs with a single line like this. CALL SR.READU(record,filevariable,ItemID,Option,Err) On 06/02/2013 21:52, Jon Wells wrote: Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
A WRITE automatically clears the lock, a WRITEU will keep it. If you are inside a transaction boundary however, then the lock is kept until the transaction is committed or abandoned. Regards JayJay On 7 Feb 2013, at 20:46, Jon Wells jwaytwe...@yahoo.com wrote: What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Thank you, Jon Wells From: Woodward, Bob bob_woodw...@k2sports.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thursday, February 7, 2013 12:35 PM Subject: Re: [U2] Record locks (Unidata 7.2) Sorry Mecki but I think you have the LOCKED in the wrong place. At least in my version of Unidata. It comes before the THEN segment so the full, proper syntax would be: READU xxx FROM xxx, xxx ON ERROR Xxx what to do if a hard error like file not open END LOCKED Xxx what to do if locked END THEN Xxx what to do if lock is obtained and record is read END ELSE Xxx what to do if lock is obtained but record does not exist. END There is a second format for the READU command but it's a lot easier if the OP just reads about, himself, in the HELP information. HELP UNIBASIC READU from ECL in Unidata will get him that. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Thursday, February 07, 2013 12:27 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) The READU statement has a LOCKED clause that is true if a record is locked. You can put all your locking ha logic in there. READU record FROM filevariable,itemID THEN code if record exists and isn't locked (optional) LOCKED code to handle locked record condition (optional) END ELSE code if record doesn't exist (required) END Now if you put that into a loop you can display a message and give the user the option to try again or abort. And if you put the code into a subroutine you can use that in all your programs with a single line like this. CALL SR.READU(record,filevariable,ItemID,Option,Err) On 06/02/2013 21:52, Jon Wells wrote: Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
With the LOCKED clause included, the READU does not pause. You can put anything you want in that section but just realize that the statement fully executes and proceeds to the next command. If you want to simulate wait until I obtain the lock then you just have to create this into a small loop. Something like this: LOCKWAIT: READU xxx FROM yyy, zzz LOCKED Xxx commands, if you want to do anything other than just loop GOTO LOCKWAIT END THEN Xxx got the lock and have read the record so do whatever Xxx14 = I was here END ELSE Xxx got the lock but it's a new record. Xxx = Xxx14 = I was here END Do some more stuff. WRITE xxx ON yyy, zzz You don't HAVE to do anything in the locked section other than just goto your label. You could add a small delay, if you wanted, just so your process isn't in a super tight loop chewing up all your computers horsepower. Also, remember, you need to do something with the lock, even if it's a new record. Either a WRITE or RELEASE statement on the zzz key value. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Thursday, February 07, 2013 12:47 PM To: U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Thank you, Jon Wells From: Woodward, Bob bob_woodw...@k2sports.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thursday, February 7, 2013 12:35 PM Subject: Re: [U2] Record locks (Unidata 7.2) Sorry Mecki but I think you have the LOCKED in the wrong place. At least in my version of Unidata. It comes before the THEN segment so the full, proper syntax would be: READU xxx FROM xxx, xxx ON ERROR Xxx what to do if a hard error like file not open END LOCKED Xxx what to do if locked END THEN Xxx what to do if lock is obtained and record is read END ELSE Xxx what to do if lock is obtained but record does not exist. END There is a second format for the READU command but it's a lot easier if the OP just reads about, himself, in the HELP information. HELP UNIBASIC READU from ECL in Unidata will get him that. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Thursday, February 07, 2013 12:27 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) The READU statement has a LOCKED clause that is true if a record is locked. You can put all your locking ha logic in there. READU record FROM filevariable,itemID THEN code if record exists and isn't locked (optional) LOCKED code to handle locked record condition (optional) END ELSE code if record doesn't exist (required) END Now if you put that into a loop you can display a message and give the user the option to try again or abort. And if you put the code into a subroutine you can use that in all your programs with a single line like this. CALL SR.READU(record,filevariable,ItemID,Option,Err) On 06/02/2013 21:52, Jon Wells wrote: Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
I think it would also be useful to add some form of exit routine inside the LOCKWAIT loop. Something like a counter to only allow say 10 attempts at trying to obtain the lock. That way you don't keep looping for ever if some other process which has the lock does not release it for whatever reason. Cheers Peter -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Woodward, Bob Sent: Friday, 8 February 2013 7:02 To: Jon Wells; U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) With the LOCKED clause included, the READU does not pause. You can put anything you want in that section but just realize that the statement fully executes and proceeds to the next command. If you want to simulate wait until I obtain the lock then you just have to create this into a small loop. Something like this: LOCKWAIT: READU xxx FROM yyy, zzz LOCKED Xxx commands, if you want to do anything other than just loop GOTO LOCKWAIT END THEN Xxx got the lock and have read the record so do whatever Xxx14 = I was here END ELSE Xxx got the lock but it's a new record. Xxx = Xxx14 = I was here END Do some more stuff. WRITE xxx ON yyy, zzz You don't HAVE to do anything in the locked section other than just goto your label. You could add a small delay, if you wanted, just so your process isn't in a super tight loop chewing up all your computers horsepower. Also, remember, you need to do something with the lock, even if it's a new record. Either a WRITE or RELEASE statement on the zzz key value. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Thursday, February 07, 2013 12:47 PM To: U2 Users List Subject: Re: [U2] Record locks (Unidata 7.2) What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Thank you, Jon Wells From: Woodward, Bob bob_woodw...@k2sports.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thursday, February 7, 2013 12:35 PM Subject: Re: [U2] Record locks (Unidata 7.2) Sorry Mecki but I think you have the LOCKED in the wrong place. At least in my version of Unidata. It comes before the THEN segment so the full, proper syntax would be: READU xxx FROM xxx, xxx ON ERROR Xxx what to do if a hard error like file not open END LOCKED Xxx what to do if locked END THEN Xxx what to do if lock is obtained and record is read END ELSE Xxx what to do if lock is obtained but record does not exist. END There is a second format for the READU command but it's a lot easier if the OP just reads about, himself, in the HELP information. HELP UNIBASIC READU from ECL in Unidata will get him that. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Thursday, February 07, 2013 12:27 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) The READU statement has a LOCKED clause that is true if a record is locked. You can put all your locking ha logic in there. READU record FROM filevariable,itemID THEN code if record exists and isn't locked (optional) LOCKED code to handle locked record condition (optional) END ELSE code if record doesn't exist (required) END Now if you put that into a loop you can display a message and give the user the option to try again or abort. And if you put the code into a subroutine you can use that in all your programs with a single line like this. CALL SR.READU(record,filevariable,ItemID,Option,Err) On 06/02/2013 21:52, Jon Wells wrote: Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
On 07/02/2013 20:46, Jon Wells wrote: What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Somebody will correct me if I'm wrong, but I thought that was exactly what READU did! If you don't provide a LOCKED clause, READU will hang and wait until the lock clears, then read and lock the record. As I say, check the docu and make sure I'm right ... I've never had to bother much with locks ... Cheers, Wol Thank you, Jon Wells ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
You're exactly right. The only time you REALLY need the LOCKED clause if there is some need to change that approach. That was what I attempted to show in my first response. I guess I was a bit terse in that one, though. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Anthonys Lists Sent: Thursday, February 07, 2013 2:21 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) On 07/02/2013 20:46, Jon Wells wrote: What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Somebody will correct me if I'm wrong, but I thought that was exactly what READU did! If you don't provide a LOCKED clause, READU will hang and wait until the lock clears, then read and lock the record. As I say, check the docu and make sure I'm right ... I've never had to bother much with locks ... Cheers, Wol Thank you, Jon Wells ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause -Original Message- From: Woodward, Bob bob_woodw...@k2sports.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Feb 7, 2013 2:43 pm Subject: Re: [U2] Record locks (Unidata 7.2) You're exactly right. The only time you REALLY need the LOCKED clause if there is some need to change that approach. That was what I attempted to show in my first response. I guess I was a bit terse in that one, though. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Anthonys Lists Sent: Thursday, February 07, 2013 2:21 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) On 07/02/2013 20:46, Jon Wells wrote: What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Somebody will correct me if I'm wrong, but I thought that was exactly what READU did! If you don't provide a LOCKED clause, READU will hang and wait until the lock clears, then read and lock the record. As I say, check the docu and make sure I'm right ... I've never had to bother much with locks ... Cheers, Wol Thank you, Jon Wells ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Thursday, February 07, 2013 3:41 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause -Original Message- From: Woodward, Bob bob_woodw...@k2sports.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Feb 7, 2013 2:43 pm Subject: Re: [U2] Record locks (Unidata 7.2) You're exactly right. The only time you REALLY need the LOCKED clause if there is some need to change that approach. That was what I attempted to show in my first response. I guess I was a bit terse in that one, though. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Anthonys Lists Sent: Thursday, February 07, 2013 2:21 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Record locks (Unidata 7.2) On 07/02/2013 20:46, Jon Wells wrote: What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Somebody will correct me if I'm wrong, but I thought that was exactly what READU did! If you don't provide a LOCKED clause, READU will hang and wait until the lock clears, then read and lock the record. As I say, check the docu and make sure I'm right ... I've never had to bother much with locks ... Cheers, Wol Thank you, Jon Wells ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
+1. Well stated. On Thursday, February 7, 2013, Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. -Original Message- From: u2-users-boun...@listserver.u2ug.org javascript:; [mailto:u2-users-boun...@listserver.u2ug.org javascript:;] On Behalf Of Wjhonson Sent: Thursday, February 07, 2013 3:41 PM To: u2-users@listserver.u2ug.org javascript:; Subject: Re: [U2] Record locks (Unidata 7.2) I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause -Original Message- From: Woodward, Bob bob_woodw...@k2sports.com javascript:; To: U2 Users List u2-users@listserver.u2ug.org javascript:; Sent: Thu, Feb 7, 2013 2:43 pm Subject: Re: [U2] Record locks (Unidata 7.2) You're exactly right. The only time you REALLY need the LOCKED clause if there is some need to change that approach. That was what I attempted to show in my first response. I guess I was a bit terse in that one, though. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org javascript:; [mailto:u2-users-boun...@listserver.u2ug.org javascript:;] On Behalf Of Anthonys Lists Sent: Thursday, February 07, 2013 2:21 PM To: u2-users@listserver.u2ug.org javascript:; Subject: Re: [U2] Record locks (Unidata 7.2) On 07/02/2013 20:46, Jon Wells wrote: What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Somebody will correct me if I'm wrong, but I thought that was exactly what READU did! If you don't provide a LOCKED clause, READU will hang and wait until the lock clears, then read and lock the record. As I say, check the docu and make sure I'm right ... I've never had to bother much with locks ... Cheers, Wol Thank you, Jon Wells ___ U2-Users mailing list U2-Users@listserver.u2ug.org javascript:; http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org javascript:; http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org javascript:; http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org javascript:; http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
Then you're misunderstanding what I'm saying. -Original Message- From: Kevin King ke...@precisonline.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Feb 7, 2013 6:48 pm Subject: Re: [U2] Record locks (Unidata 7.2) +1. Well stated. On Thursday, February 7, 2013, Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. -Original Message- From: u2-users-boun...@listserver.u2ug.org javascript:; [mailto:u2-users-boun...@listserver.u2ug.org javascript:;] On Behalf Of Wjhonson Sent: Thursday, February 07, 2013 3:41 PM To: u2-users@listserver.u2ug.org javascript:; Subject: Re: [U2] Record locks (Unidata 7.2) I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause -Original Message- From: Woodward, Bob bob_woodw...@k2sports.com javascript:; To: U2 Users List u2-users@listserver.u2ug.org javascript:; Sent: Thu, Feb 7, 2013 2:43 pm Subject: Re: [U2] Record locks (Unidata 7.2) You're exactly right. The only time you REALLY need the LOCKED clause if there is some need to change that approach. That was what I attempted to show in my first response. I guess I was a bit terse in that one, though. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org javascript:; [mailto:u2-users-boun...@listserver.u2ug.org javascript:;] On Behalf Of Anthonys Lists Sent: Thursday, February 07, 2013 2:21 PM To: u2-users@listserver.u2ug.org javascript:; Subject: Re: [U2] Record locks (Unidata 7.2) On 07/02/2013 20:46, Jon Wells wrote: What I'm wondering is; what can I put into the 'Xxx what to do if locked' section whereby it waits until the record lock clears, once it clears, set my own lock, read the record, alter the record, and then write the record (which would release my lock)? Somebody will correct me if I'm wrong, but I thought that was exactly what READU did! If you don't provide a LOCKED clause, READU will hang and wait until the lock clears, then read and lock the record. As I say, check the docu and make sure I'm right ... I've never had to bother much with locks ... Cheers, Wol Thank you, Jon Wells ___ U2-Users mailing list U2-Users@listserver.u2ug.org javascript:; http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org javascript:; http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org javascript:; http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org javascript:; http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
I think people understand exactly what you're saying, but disagree. Most applications don't use the more rigorous coding for having a Locked clause that provides additional information to the user, retries, etc. That's not wrong, it's just not necessary ... depending on the site. That said, when we used to have a lot of people in an office and a dumb terminal beeping was a recognized message to everyone, it was OK (generally) to just do the READU. These days with more alternative UIs, thick-client, thin-client, web services, mobile, etc, there's no one to hear that beep. So for modern development I would agree that you really don't want an unconditional lock hanging around, you want a Locked clause with logic to rollback the transaction and exit gracefully, perhaps with a message sent to the site admin. The penalty for Not having a Locked clause with a new UI is that the port will hang, the UI will receive a timeout (which many clients aren't prepared to process), and the DBMS port could be sitting there indefinitely with no one aware of the condition. This can cascade to multiple ports until suddenly everything grinds to a halt and GUI users around the world are unable to access the app. I believe some heads will be nodding here because I hear about this happening occasionally. T From: Wjhonson Then you're misunderstanding what I'm saying. From: Kevin King +1. Well stated. Woodward, Bob wrote: In an active user session where users are obtaining a lock for a length of time, you're right. There are lots of times, though, that lock intervention is not a benefit. It all depends on the need of the application and many situations where I would highly recommend using the default locking system of READU. From: Wjhonson I wouldn't however *recommend* this approach to locking as the user can never tell if their terminal is waiting on a lock, or just hung in some other odd manner, or perhaps processing a batch of something. So it's rather a nasty trick to play on the user, to just use READU without a LOCKED clause ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Record locks (Unidata 7.2)
Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
You mean you want to loop on the checking *until* the lock is released and then write? So this is for a job interview? DOLOOP = 0 LOOP READU ITSLOCKEDJIM FROM Y,Z LOCKED DOLOOP = 1 END UNTIL NOT(DOLOOP) DO SLEEP 10; *Let the system catch its breath REPEAT WRITE X ON Y,Z ELSE CRT 'HELP ME! HELP ME!' -Original Message- From: Jon Wells jwaytwe...@yahoo.com To: U2-Users U2-Users@listserver.u2ug.org Sent: Wed, Feb 6, 2013 1:53 pm Subject: [U2] Record locks (Unidata 7.2) Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
Recte! I created me an infinite looop thingie. The DOLOOP = 0 should be INSIDE the Loop structure... obviously Bonk bonk on the head ! -Original Message- From: Wjhonson wjhon...@aol.com To: jwaytwells jwaytwe...@yahoo.com; u2-users u2-users@listserver.u2ug.org Sent: Wed, Feb 6, 2013 1:57 pm Subject: Re: [U2] Record locks (Unidata 7.2) You mean you want to loop on the checking *until* the lock is released and then write? So this is for a job interview? DOLOOP = 0 LOOP READU ITSLOCKEDJIM FROM Y,Z LOCKED DOLOOP = 1 END UNTIL NOT(DOLOOP) DO SLEEP 10; *Let the system catch its breath REPEAT WRITE X ON Y,Z ELSE CRT 'HELP ME! HELP ME!' -Original Message- From: Jon Wells jwaytwe...@yahoo.com To: U2-Users U2-Users@listserver.u2ug.org Sent: Wed, Feb 6, 2013 1:53 pm Subject: [U2] Record locks (Unidata 7.2) Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
READU blah blah blah THEN/ELSE WRITE blah blah blah END Can't get much more straight forward than that. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Wednesday, February 06, 2013 1:53 PM To: U2-Users@listserver.u2ug.org Subject: [U2] Record locks (Unidata 7.2) Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Record locks (Unidata 7.2)
Jon, Everything is strait forward except the wait until logic. That can get very complex if you want to. RECORDLOCKED(file.var, rec.id.expr) - Returns record lock status, 0 if not locked. MATREADU or READU or RECORDLOCKU - Will lock a record.* MATWRITE or WRITE or RELEASE - Will unlock a record. *Note you can use GETUSERNAME(STATUS()) to see who has it locked. David A. Green (480) 813-1725 DAG Consulting -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Jon Wells Sent: Wednesday, February 06, 2013 2:53 PM To: U2-Users@listserver.u2ug.org Subject: [U2] Record locks (Unidata 7.2) Hi all, I have not looked at the world of record locks since my R83 Pick days. I'm hoping to add the ability for the program I'm working on to: * Check if a record is locked * Wait until the lock is removed * Once the lock is removed, or if the record is not locked: * Lock the record * Perform the WRITE statement I'm hoping someone can share an example of how to accomplish this in UniBasic. Thank you, Jon Wells Campbell University ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
