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.


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 

-----Original Message-----
From: Mecki Foerthmann<>
To: u2-users<>
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 Hammerle<>
  To: u2-users<>
  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
  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
  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
  elete this e-mail including all attachments from your system. Thank you
  2-Users mailing list

  U2-Users mailing list
2-Users mailing list

U2-Users mailing list
U2-Users mailing list

Reply via email to