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 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 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
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
