[U2] Lock Status
Is there anything in Unidata that would report the line of code that set a particular record lock? -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Once you know the pid of the program with the lock, you can use PORT.STATUS to determine this. You just need to use the CALL.STACK option. IIRC (It's been a few months) it would be like: PORT.STATUS PID the progs pid here CALL.STACK Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 9:06 AM To: U2 Users List Subject: [U2] Lock Status Is there anything in Unidata that would report the line of code that set a particular record lock? -Kevin http://www.PrecisOnline.com ___ 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] Lock Status
I don't see anything in the LIST.QUEUE output, but I can see how that would be useful. If you have control of the source code for all of the file i/o operations you could write your own wrapper routines for the commands that set record locks, get the information from SYSTEM(49) (the program stack), and write it to a file somewhere, keyed by file name and record key. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 11:06 AM To: U2 Users List Subject: [U2] Lock Status Is there anything in Unidata that would report the line of code that set a particular record lock? -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users html body Dave Davis Team Lead, Ramp;D P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif] 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. /body /html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
That's useful for determining where that port is, but we have a process leaving rogue locks lying around. Anything that tells what updated the lock table? On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath dmcgr...@rocketsoftware.comwrote: Once you know the pid of the program with the lock, you can use PORT.STATUS to determine this. You just need to use the CALL.STACK option. IIRC (It's been a few months) it would be like: PORT.STATUS PID the progs pid here CALL.STACK Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 9:06 AM To: U2 Users List Subject: [U2] Lock Status Is there anything in Unidata that would report the line of code that set a particular record lock? -Kevin http://www.PrecisOnline.com ___ 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 -- -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Dave: Two Words: Vendor App. Good idea, but not possible in this case. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
This is probably no help... In Universe there is a LIST.READU EVERY. That will show every lock in the system. Maybe if Unidata has an equivalent, you can get some useful info there... On Thu, Sep 8, 2011 at 11:15 AM, Kevin King precisonl...@gmail.com wrote: That's useful for determining where that port is, but we have a process leaving rogue locks lying around. Anything that tells what updated the lock table? On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath dmcgr...@rocketsoftware.comwrote: Once you know the pid of the program with the lock, you can use PORT.STATUS to determine this. You just need to use the CALL.STACK option. IIRC (It's been a few months) it would be like: PORT.STATUS PID the progs pid here CALL.STACK Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 9:06 AM To: U2 Users List Subject: [U2] Lock Status Is there anything in Unidata that would report the line of code that set a particular record lock? -Kevin http://www.PrecisOnline.com ___ 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 -- -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- John Thompson ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Unfortunately, no love there either John. I even went to the GETREADU( .. ) function in BASIC.. nothing there. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
LIST.READU will tell you what program owns the lock (as long as the program is still running). The UNO column is the UniData Number, which will relate to a user/process in the PORT.STATUS (no options) command's list. Aside from that, I don't know if you can catch the actual line number unless you catch the program in the act when it does it with PORT.STATUS CALL.STACK. You know roughly what file/record it will effect, you could try locking the record yourself (with say, ED) and waiting until the rogue program hits it. Using PORT.STATUS CALL.STACK then should tell you the line number issuing the lock. Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 9:15 AM To: U2 Users List Subject: Re: [U2] Lock Status That's useful for determining where that port is, but we have a process leaving rogue locks lying around. Anything that tells what updated the lock table? On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath dmcgr...@rocketsoftware.comwrote: Once you know the pid of the program with the lock, you can use PORT.STATUS to determine this. You just need to use the CALL.STACK option. IIRC (It's been a few months) it would be like: PORT.STATUS PID the progs pid here CALL.STACK Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 9:06 AM To: U2 Users List Subject: [U2] Lock Status Is there anything in Unidata that would report the line of code that set a particular record lock? -Kevin http://www.PrecisOnline.com ___ 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 -- -Kevin http://www.PrecisOnline.com ___ 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] Lock Status
It's a shame there isn't a file trigger operation on locking reads, just updates and deletes. That way you could just add it to the file in question. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 11:16 AM To: U2 Users List Subject: Re: [U2] Lock Status Dave: Two Words: Vendor App. Good idea, but not possible in this case. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users html body Dave Davis Team Lead, Ramp;D P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif] 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. /body /html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
On Thu, Sep 8, 2011 at 11:23 AM, Daniel McGrath dmcgr...@rocketsoftware.com wrote: LIST.READU will tell you what program owns the lock (as long as the program is still running). The UNO column is the UniData Number, which will relate to a user/process in the PORT.STATUS (no options) command's list. Aren't the locks released when the program stops? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Kudos for the novel ideas Dan! However, in this case we're trying to track down a program that left a lock. And being an SB+ application, a lot of stuff runs under the same PID. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
On Thu, Sep 8, 2011 at 11:26 AM, Dave Davis dda...@harriscomputer.com wrote: It's a shame there isn't a file trigger operation on locking reads, just updates and deletes. That way you could just add it to the file in question. The update trigger might be useful. Most ppl would lock the record before updating it. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Yes, Steve, but being an SB+ application... the program never stops completely until the person logs off. Meanwhile, they end up dragging mines.. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Yes, they should be. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Thursday, September 08, 2011 9:27 AM To: U2 Users List Subject: Re: [U2] Lock Status On Thu, Sep 8, 2011 at 11:23 AM, Daniel McGrath dmcgr...@rocketsoftware.com wrote: LIST.READU will tell you what program owns the lock (as long as the program is still running). The UNO column is the UniData Number, which will relate to a user/process in the PORT.STATUS (no options) command's list. Aren't the locks released when the program stops? ___ 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] Lock Status
It would be useful, except that the problem is the locker causing the problem probably hasn't updated the record yet, which most likely would release the lock (this being an SB+ application) and end the problem. Retaining the lock after an update is something that would likely be coded in unibasic. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Thursday, September 08, 2011 11:28 AM To: U2 Users List Subject: Re: [U2] Lock Status On Thu, Sep 8, 2011 at 11:26 AM, Dave Davis dda...@harriscomputer.com wrote: It's a shame there isn't a file trigger operation on locking reads, just updates and deletes. That way you could just add it to the file in question. The update trigger might be useful. Most ppl would lock the record before updating it. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users html body Dave Davis Team Lead, Ramp;D P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif] 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. /body /html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
We do suspect it is from a custom BASIC subroutine, recently installed. So knowing the file we're looking back through any code that was compiled within the past 2 weeks and manually searching for READU's that don't WRITE, DELETE, or RELEASE. Sure would be nice if the lock table would report the line of code that set the lock. Just sayin'. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Kevin, I think that the closest you are going to be able to get is the program in question using LIST.READU to determine the PID and PORT.STATUS to then find the program. I don't know of any way to dynamically get to the program line number from there. You could, of course, just look through the program source and the READUs then make an educated guess from there. Kevin King wrote: Unfortunately, no love there either John. I even went to the GETREADU( .. ) function in BASIC.. nothing there. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
On Thu, Sep 8, 2011 at 11:34 AM, Kevin King precisonl...@gmail.com wrote: We do suspect it is from a custom BASIC subroutine, recently installed. So knowing the file we're looking back through any code that was compiled within the past 2 weeks and manually searching for READU's that don't WRITE, DELETE, or RELEASE. Sure would be nice if the lock table would report the line of code that set the lock. Just sayin'. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users That does seem like it would be a trivial and cool addition. Maybe just on an option switch. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Yeah PORT.STATUS on Universe will tell you the last command run by the floating user number of the user... So if you were able to get the UserNo from LIST.READU EVERY output, and then cross reference that with the PORT.STATUS output, perhaps you could at least narrow it down. Of course that would require you knowing the program name that you were looking for... So if you knew the program name you were looking for, maybe you could in a BASIC program: 1) Execute and Capture LIST.READU EVERY output. 2) Execute and Capture PORT.STATUS output. 3) Then look through PORT.STATUS and find the program you were looking for or the UserNo you were looking for and display just that line... -Or if you new a series of Unix user names that might be setting you could look at only those... Just thinking out loud... On Thu, Sep 8, 2011 at 11:34 AM, Jeff Schasny jscha...@gmail.com wrote: Kevin, I think that the closest you are going to be able to get is the program in question using LIST.READU to determine the PID and PORT.STATUS to then find the program. I don't know of any way to dynamically get to the program line number from there. You could, of course, just look through the program source and the READUs then make an educated guess from there. Kevin King wrote: Unfortunately, no love there either John. I even went to the GETREADU( .. ) function in BASIC.. nothing there. __**_ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/**mailman/listinfo/u2-usershttp://listserver.u2ug.org/mailman/listinfo/u2-users -- --**--** Jeff Schasny - Denver, Co, USA jschasny at gmail dot com --**--** __**_ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/**mailman/listinfo/u2-usershttp://listserver.u2ug.org/mailman/listinfo/u2-users -- John Thompson ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
If only the lock table was an actual hashed file that you could place an update trigger on. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 11:15 AM To: U2 Users List Subject: Re: [U2] Lock Status That's useful for determining where that port is, but we have a process leaving rogue locks lying around. Anything that tells what updated the lock table? On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath dmcgr...@rocketsoftware.comwrote: Once you know the pid of the program with the lock, you can use PORT.STATUS to determine this. You just need to use the CALL.STACK option. IIRC (It's been a few months) it would be like: PORT.STATUS PID the progs pid here CALL.STACK Regards, Dan -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 9:06 AM To: U2 Users List Subject: [U2] Lock Status Is there anything in Unidata that would report the line of code that set a particular record lock? -Kevin http://www.PrecisOnline.com ___ 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 -- -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users html body Dave Davis Team Lead, Ramp;D P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif] 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. /body /html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Just don't do what one of my old bosses did (he was having trouble with SB+ holding locks) - he found one of our main processes and put in RELEASE. Our system relied heavily on pessimistic locking so this caused quite a bit of data loss. Of course, I was the one that had to clean it all up (he didn't like the names I called him after that one). Of course, this was the same genius that taught an entire site to use ctrlq to stop their PC's from beeping... but didn't bother to explain that you shouldn't reboot and try the same thing again. Good luck Colin -Original Message- From: Kevin King We do suspect it is from a custom BASIC subroutine, recently installed. So knowing the file we're looking back through any code that was compiled within the past 2 weeks and manually searching for READU's that don't WRITE, DELETE, or RELEASE. Sure would be nice if the lock table would report the line of code that set the lock. Just sayin'. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Kevin sorry but no. There is no function that will tell you the line of code or even the program which set a lock. You could however, as others have suggested determine the PID which set it, AND (not OR) write a routine which wakes up every five minutes and copies the current lock table into a history item, compare and contrast so you can get a running map of exactly WHEN and by WHOM the nasty lock is being set. Then after you run that for a week, send the results to the Vendor and say, OK now fix it bozo! Optionally you can leave off bozo. -Original Message- From: Kevin King precisonl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 8:20 am Subject: Re: [U2] Lock Status Unfortunately, no love there either John. I even went to the GETREADU( .. ) unction in BASIC.. nothing there. __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://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] Lock Status
I think I worked for him once! ;^) Charlie Noah On 09-08-2011 11:11 AM, Colin Alfke wrote: Just don't do what one of my old bosses did (he was having trouble with SB+ holding locks) - he found one of our main processes and put in RELEASE. Our system relied heavily on pessimistic locking so this caused quite a bit of data loss. Of course, I was the one that had to clean it all up (he didn't like the names I called him after that one). Of course, this was the same genius that taught an entire site to usectrlq to stop their PC's from beeping... but didn't bother to explain that you shouldn't reboot and try the same thing again. Good luck Colin -Original Message- From: Kevin King We do suspect it is from a custom BASIC subroutine, recently installed. So knowing the file we're looking back through any code that was compiled within the past 2 weeks and manually searching for READU's that don't WRITE, DELETE, or RELEASE. Sure would be nice if the lock table would report the line of code that set the lock. Just sayin'. ___ 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] Lock Status
This won't work unless the program is halted-waiting. Most likely it's moved on to do a hundred other things since the lock in question, but left it hanging because the pid is still living. If the pid dies it would release the lock, but for example, even on non-SB systems, phantoms which run constantly can leave locks hanging forever. -Original Message- From: Jeff Schasny jscha...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 8:34 am Subject: Re: [U2] Lock Status Kevin, I think that the closest you are going to be able to get is the program n question using LIST.READU to determine the PID and PORT.STATUS to hen find the program. I don't know of any way to dynamically get to the rogram line number from there. You could, of course, just look through he program source and the READUs then make an educated guess from there. Kevin King wrote: Unfortunately, no love there either John. I even went to the GETREADU( .. ) function in BASIC.. nothing there. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- --- eff Schasny - Denver, Co, USA schasny at gmail dot com --- __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://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] Lock Status
I believe that if the program ended the lock would be released, so by finding the PID via LIST.READU and then determining the program name associated with the PID via PORT.STATUS you are identifying the program which currently holds the lock unless the program ends between the LIST.READU and PORT.STATUS. At least in my Unix/Universe world. Wjhonson wrote: This won't work unless the program is halted-waiting. Most likely it's moved on to do a hundred other things since the lock in question, but left it hanging because the pid is still living. If the pid dies it would release the lock, but for example, even on non-SB systems, phantoms which run constantly can leave locks hanging forever. -Original Message- From: Jeff Schasny jscha...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 8:34 am Subject: Re: [U2] Lock Status Kevin, I think that the closest you are going to be able to get is the program n question using LIST.READU to determine the PID and PORT.STATUS to hen find the program. I don't know of any way to dynamically get to the rogram line number from there. You could, of course, just look through he program source and the READUs then make an educated guess from there. Kevin King wrote: Unfortunately, no love there either John. I even went to the GETREADU( .. ) function in BASIC.. nothing there. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
That's not the case. PORT.STATUS shows you what that PID is currently doing when you run it. Not what it was doing an hour ago for example. Not what it was doing when it set the lock. Just what it's doing now. In Unix/Universe world. If you are so lucky to know about the lock *right when* it's being set, then you are right. But in my experience that is a very rare occurence. And in this particular example, he already stated that it was a lock left set some time earlier. You can only know the program being run by that PID if that program is in some sort of waiting condition and had been waiting since it set the lock. -Original Message- From: Jeff Schasny jscha...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 10:30 am Subject: Re: [U2] Lock Status I believe that if the program ended the lock would be released, so by inding the PID via LIST.READU and then determining the program name ssociated with the PID via PORT.STATUS you are identifying the program hich currently holds the lock unless the program ends between the IST.READU and PORT.STATUS. At least in my Unix/Universe world. Wjhonson wrote: This won't work unless the program is halted-waiting. Most likely it's moved on to do a hundred other things since the lock in uestion, but left it hanging because the pid is still living. If the pid dies it would release the lock, but for example, even on non-SB ystems, phantoms which run constantly can leave locks hanging forever. -Original Message- From: Jeff Schasny jscha...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 8:34 am Subject: Re: [U2] Lock Status Kevin, I think that the closest you are going to be able to get is the program n question using LIST.READU to determine the PID and PORT.STATUS to hen find the program. I don't know of any way to dynamically get to the rogram line number from there. You could, of course, just look through he program source and the READUs then make an educated guess from there. Kevin King wrote: Unfortunately, no love there either John. I even went to the GETREADU( .. ) function in BASIC.. nothing there. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- --- eff Schasny - Denver, Co, USA schasny at gmail dot com --- __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://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] Lock Status
Not exactly trivial. Would require a new structure to be added to the table and changes to all associated routines that access and maintain this shared memory table. Also - UniData record locks are tied to a file variable. So even if the 'program ends', if the file variable is in COMMON and therefore not closed (local variables closed when program ends), the lock would persist. Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Thursday, September 08, 2011 9:39 AM To: U2 Users List Subject: Re: [U2] Lock Status On Thu, Sep 8, 2011 at 11:34 AM, Kevin King precisonl...@gmail.com wrote: We do suspect it is from a custom BASIC subroutine, recently installed. So knowing the file we're looking back through any code that was compiled within the past 2 weeks and manually searching for READU's that don't WRITE, DELETE, or RELEASE. Sure would be nice if the lock table would report the line of code that set the lock. Just sayin'. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users That does seem like it would be a trivial and cool addition. Maybe just on an option switch. ___ 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] Lock Status
I disagree. If I run LIST.READU and note the PID of a process holding a lock on an item then run PORT.STATUS on that PID the only way that the program shown by PORT.STATUS as currently running is not the process holding the lock would be if the program ended (thus dropping the lock) before I ran the PORT.STATUS. Wjhonson wrote: That's not the case. PORT.STATUS shows you what that PID is currently doing when you run it. Not what it was doing an hour ago for example. Not what it was doing when it set the lock. Just what it's doing now. In Unix/Universe world. If you are so lucky to know about the lock *right when* it's being set, then you are right. But in my experience that is a very rare occurence. And in this particular example, he already stated that it was a lock left set some time earlier. You can only know the program being run by that PID if that program is in some sort of waiting condition and had been waiting since it set the lock. -Original Message- From: Jeff Schasny jscha...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 10:30 am Subject: Re: [U2] Lock Status I believe that if the program ended the lock would be released, so by inding the PID via LIST.READU and then determining the program name ssociated with the PID via PORT.STATUS you are identifying the program hich currently holds the lock unless the program ends between the IST.READU and PORT.STATUS. At least in my Unix/Universe world. Wjhonson wrote: This won't work unless the program is halted-waiting. Most likely it's moved on to do a hundred other things since the lock in uestion, but left it hanging because the pid is still living. If the pid dies it would release the lock, but for example, even on non-SB ystems, phantoms which run constantly can leave locks hanging forever. -Original Message- From: Jeff Schasny jscha...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 8:34 am Subject: Re: [U2] Lock Status Kevin, I think that the closest you are going to be able to get is the program n question using LIST.READU to determine the PID and PORT.STATUS to hen find the program. I don't know of any way to dynamically get to the rogram line number from there. You could, of course, just look through he program source and the READUs then make an educated guess from there. Kevin King wrote: Unfortunately, no love there either John. I even went to the GETREADU( .. ) function in BASIC.. nothing there. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Port.status shows what is currently running on that PID Not what was running when the lock was set. The process is not the program. You are using the words interchangebly when they are not. A process can run a long stack up and down adding and pruning. The call stack only shows the current stack of the stack, not what the state was when the lock was set. If a member of the old call stack had set a lock, that lock persists until the entire call stack is completely depleted. Which could be 20 routines later. -Original Message- From: Jeff Schasny jscha...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 11:30 am Subject: Re: [U2] Lock Status I disagree. If I run LIST.READU and note the PID of a process holding a lock on an tem then run PORT.STATUS on that PID the only way that the program hown by PORT.STATUS as currently running is not the process holding the ock would be if the program ended (thus dropping the lock) before I ran he PORT.STATUS. Wjhonson wrote: That's not the case. PORT.STATUS shows you what that PID is currently doing when you run it. Not what it was doing an hour ago for example. Not what it was doing when it set the lock. Just what it's doing now. In Unix/Universe world. If you are so lucky to know about the lock *right when* it's being set, then ou are right. But in my experience that is a very rare occurence. And in this particular example, he already stated that it was a lock left set ome time earlier. You can only know the program being run by that PID if that program is in some ort of waiting condition and had been waiting since it set the lock. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
Even if the program ended that locked the item, the lock could still be maintained if the file variable was passed. I know this is after the fact but, one option going forward would be to write a wrapper program for READU's and call it LOCK.RECORD. I use this approach extensively. CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE ) 1. If it is a phantom, perform a READU 2. If it is a real user, use the LOCKED clause 2a. If it is locked, display whom has it locked followed by an INPUT ( if it is SB+, use a DISP ). 2b. If it is not locked, lock it. * This allows them to see who has them locked and contact the guilty party 3. NEW OPTION : Once locked, you could get the call stack and record to a file which program locked it ( excluding this sub - LOCK.RECORD ). Or you could add an additional parameter to this sub and pass in the program name. We already do 1 and 2, but 3 would be an interesting option. We also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to escape if the record is locked and it also displays who has them locked. We only use this option when it is safe to escape and it sends back ESCAPED 1 or 0 so we can handle the escape properly. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or company to whom they are addressed. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail including all attachments from your system. Thank you ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
This still would not be accurate for the reasons already stated. The call stack only shows you what routine is on the stack. If the lock had been set for hours, who knows what routine was there previously? As you yourself stated, locks can persist, after the routine which created them has gone away. The only viable solution is to record the lock at the time it is set. -Original Message- From: George Hammerle zhamme...@hubert.com To: u2-users u2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 12:36 pm Subject: Re: [U2] Lock Status ven if the program ended that locked the item, the lock could still be aintained if the file variable was passed. I know this is after the fact but, one option going forward would be to write a rapper program for READU's and call it LOCK.RECORD. I use this approach xtensively. CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE ) 1. If it is a phantom, perform a READU . If it is a real user, use the LOCKED clause a. If it is locked, display whom has it locked followed by an INPUT ( if it is B+, use a DISP ). b. If it is not locked, lock it. This allows them to see who has them locked and contact the guilty party . NEW OPTION : Once locked, you could get the call stack and record to a file hich program locked it ( excluding this sub - LOCK.RECORD ). Or you could add n additional parameter to this sub and pass in the program name. e already do 1 and 2, but 3 would be an interesting option. e also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to scape if the record is locked and it also displays who has them locked. We only se this option when it is safe to escape and it sends back ESCAPED 1 or 0 so e can handle the escape properly. This e-mail and any files transmitted with it are confidential and intended olely for the use of the individual or company to whom they are addressed. If ou have received this e-mail in error, please notify the sender immediately and elete this e-mail including all attachments from your system. Thank you __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://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] Lock Status
Thank you goes out to everyone for the input. We were able to identify (and as of this moment it would appear correct) a couple of suspects by looking at the code that had been compiled within the last 2 weeks and evaluating each routine separately. I still think it'd be cool to be able to see which program set which locks retrospectively, though I completely understand Wally's perspective about the effort involved to make that happen. -K ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Lock Status
I dare to disagree. If you ALWAYS use a subroutine that records the pid, the file, item Id and program on a logfile when you want to read and lock a record and ALWAYS use a subroutine that removes the info from the logfile to write or release this could work. Otherwise it won't. On 08/09/2011 20:39, Wjhonson wrote: This still would not be accurate for the reasons already stated. The call stack only shows you what routine is on the stack. If the lock had been set for hours, who knows what routine was there previously? As you yourself stated, locks can persist, after the routine which created them has gone away. The only viable solution is to record the lock at the time it is set. -Original Message- From: George Hammerlezhamme...@hubert.com To: u2-usersu2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 12:36 pm Subject: Re: [U2] Lock Status ven if the program ended that locked the item, the lock could still be aintained if the file variable was passed. I know this is after the fact but, one option going forward would be to write a rapper program for READU's and call it LOCK.RECORD. I use this approach xtensively. CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE ) 1. If it is a phantom, perform a READU . If it is a real user, use the LOCKED clause a. If it is locked, display whom has it locked followed by an INPUT ( if it is B+, use a DISP ). b. If it is not locked, lock it. This allows them to see who has them locked and contact the guilty party . NEW OPTION : Once locked, you could get the call stack and record to a file hich program locked it ( excluding this sub - LOCK.RECORD ). Or you could add n additional parameter to this sub and pass in the program name. e already do 1 and 2, but 3 would be an interesting option. e also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to scape if the record is locked and it also displays who has them locked. We only se this option when it is safe to escape and it sends back ESCAPED 1 or 0 so e can handle the escape properly. This e-mail and any files transmitted with it are confidential and intended olely for the use of the individual or company to whom they are addressed. If ou have received this e-mail in error, please notify the sender immediately and elete this e-mail including all attachments from your system. Thank you __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://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] Lock Status
You might be able to implement this capability from within the programs themselves without a huge amount of effort. We have a small program tracking subroutine and a companion utility that automatically installs a call to it from every program. The original purpose was to determine which code was still in use for our initial conversion from Ultimate to UV 15 years ago, but it's come in handy for isolating anomolies over the years. The call statement is simply: CALL TRACKER('THIS.PROGRAM') The utility goes through all programs on a weekly basis during nightly batch processing, adds that line at the top if it doesn't exist (following the SUBROUTINE line), and recompiles the program. The tracker program writes a log record where the ID is the user and the data is a sequential list of programs as well as a record where the ID is the program and the data is a sequential list of users. For your lock issue, you could take this a step further and: 1) Check to see if this session is still hanging onto locks from the previously called subroutine 2) Figure out what subroutine was previously called from the log record and log the locks still being held You will also have to come up with a method of insuring you only log the initial instance, but I think that should be do-able. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 1:01 PM To: U2 Users List Subject: Re: [U2] Lock Status Thank you goes out to everyone for the input. We were able to identify (and as of this moment it would appear correct) a couple of suspects by looking at the code that had been compiled within the last 2 weeks and evaluating each routine separately. I still think it'd be cool to be able to see which program set which locks retrospectively, though I completely understand Wally's perspective about the effort involved to make that happen. -K ___ 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] Lock Status
If you rewrote your system to whip eggs, then it would whip eggs. But this doesn't fix the underlying issue that there are many systems already out there, which cannot whip eggs. And which you do not have the luxury to rewrite, but have to live with them the way they are. There IS a way to get around this problem, but not retroactively, only proactively. -Original Message- From: Mecki Foerthmann mec...@gmx.net To: u2-users u2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 1:28 pm Subject: Re: [U2] Lock Status I dare to disagree. f you ALWAYS use a subroutine that records the pid, the file, item Id nd program on a logfile when you want to read and lock a record and LWAYS use a subroutine that removes the info from the logfile to write r release this could work. therwise it won't. On 08/09/2011 20:39, Wjhonson wrote: This still would not be accurate for the reasons already stated. The call stack only shows you what routine is on the stack. If the lock had een set for hours, who knows what routine was there previously? As you yourself stated, locks can persist, after the routine which created hem has gone away. The only viable solution is to record the lock at the time it is set. -Original Message- From: George Hammerlezhamme...@hubert.com To: u2-usersu2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 12:36 pm Subject: Re: [U2] Lock Status ven if the program ended that locked the item, the lock could still be aintained if the file variable was passed. I know this is after the fact but, one option going forward would be to write rapper program for READU's and call it LOCK.RECORD. I use this approach xtensively. CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE ) 1. If it is a phantom, perform a READU . If it is a real user, use the LOCKED clause a. If it is locked, display whom has it locked followed by an INPUT ( if it is B+, use a DISP ). b. If it is not locked, lock it. This allows them to see who has them locked and contact the guilty party . NEW OPTION : Once locked, you could get the call stack and record to a file hich program locked it ( excluding this sub - LOCK.RECORD ). Or you could add n additional parameter to this sub and pass in the program name. e already do 1 and 2, but 3 would be an interesting option. e also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to scape if the record is locked and it also displays who has them locked. We nly se this option when it is safe to escape and it sends back ESCAPED 1 or 0 so e can handle the escape properly. This e-mail and any files transmitted with it are confidential and intended olely for the use of the individual or company to whom they are addressed. If ou have received this e-mail in error, please notify the sender immediately nd elete this e-mail including all attachments from your system. Thank you __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://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] Lock Status
I just realized there also needs to be a 3rd step in the process below that removes any logging of locks that have since been released. In the following sequence of events: Program A locks record R Program A calls subroutine B Program A calls subroutine C Program A releases record R Subroutines B and C will falsely accuse program A of leaving an unresolved lock. The next subroutine that runs following the release in program A needs to check for this and remove the lock log for record R. That way when the user eventually logs off you're only left with logs of the locks that never went away. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester Sent: Thursday, September 08, 2011 1:36 PM To: U2 Users List Subject: Re: [U2] Lock Status You might be able to implement this capability from within the programs themselves without a huge amount of effort. We have a small program tracking subroutine and a companion utility that automatically installs a call to it from every program. The original purpose was to determine which code was still in use for our initial conversion from Ultimate to UV 15 years ago, but it's come in handy for isolating anomolies over the years. The call statement is simply: CALL TRACKER('THIS.PROGRAM') The utility goes through all programs on a weekly basis during nightly batch processing, adds that line at the top if it doesn't exist (following the SUBROUTINE line), and recompiles the program. The tracker program writes a log record where the ID is the user and the data is a sequential list of programs as well as a record where the ID is the program and the data is a sequential list of users. For your lock issue, you could take this a step further and: 1) Check to see if this session is still hanging onto locks from the previously called subroutine 2) Figure out what subroutine was previously called from the log record and log the locks still being held You will also have to come up with a method of insuring you only log the initial instance, but I think that should be do-able. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Thursday, September 08, 2011 1:01 PM To: U2 Users List Subject: Re: [U2] Lock Status Thank you goes out to everyone for the input. We were able to identify (and as of this moment it would appear correct) a couple of suspects by looking at the code that had been compiled within the last 2 weeks and evaluating each routine separately. I still think it'd be cool to be able to see which program set which locks retrospectively, though I completely understand Wally's perspective about the effort involved to make that happen. -K ___ 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] Lock Status
Now that's a program I'd like to see. I've been trying to write one that makes cups of coffee, but so far no luck.:-D I always tell my clients when they ask me for things that can't be done without rewriting the whole system, that I will do the impossible straight away, but miracles may take a bit longer. Mecki On 08/09/2011 21:48, Wjhonson wrote: If you rewrote your system to whip eggs, then it would whip eggs. But this doesn't fix the underlying issue that there are many systems already out there, which cannot whip eggs. And which you do not have the luxury to rewrite, but have to live with them the way they are. There IS a way to get around this problem, but not retroactively, only proactively. -Original Message- From: Mecki Foerthmannmec...@gmx.net To: u2-usersu2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 1:28 pm Subject: Re: [U2] Lock Status I dare to disagree. f you ALWAYS use a subroutine that records the pid, the file, item Id nd program on a logfile when you want to read and lock a record and LWAYS use a subroutine that removes the info from the logfile to write r release this could work. therwise it won't. On 08/09/2011 20:39, Wjhonson wrote: This still would not be accurate for the reasons already stated. The call stack only shows you what routine is on the stack. If the lock had een set for hours, who knows what routine was there previously? As you yourself stated, locks can persist, after the routine which created hem has gone away. The only viable solution is to record the lock at the time it is set. -Original Message- From: George Hammerlezhamme...@hubert.com To: u2-usersu2-users@listserver.u2ug.org Sent: Thu, Sep 8, 2011 12:36 pm Subject: Re: [U2] Lock Status ven if the program ended that locked the item, the lock could still be aintained if the file variable was passed. I know this is after the fact but, one option going forward would be to write rapper program for READU's and call it LOCK.RECORD. I use this approach xtensively. CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE ) 1. If it is a phantom, perform a READU . If it is a real user, use the LOCKED clause a. If it is locked, display whom has it locked followed by an INPUT ( if it is B+, use a DISP ). b. If it is not locked, lock it. This allows them to see who has them locked and contact the guilty party . NEW OPTION : Once locked, you could get the call stack and record to a file hich program locked it ( excluding this sub - LOCK.RECORD ). Or you could add n additional parameter to this sub and pass in the program name. e already do 1 and 2, but 3 would be an interesting option. e also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to scape if the record is locked and it also displays who has them locked. We nly se this option when it is safe to escape and it sends back ESCAPED 1 or 0 so e can handle the escape properly. This e-mail and any files transmitted with it are confidential and intended olely for the use of the individual or company to whom they are addressed. If ou have received this e-mail in error, please notify the sender immediately nd elete this e-mail including all attachments from your system. Thank you __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://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