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
