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