It is the same process which holds the lock on
^TIU(8925,18) when I lock the node using the LOCK command.
And the process status shows
hui 3538
11.5 1.9 10816 4904 pts/0 R+ 14:58
12:29 /usr/local/gtm_5c/mumps -direct
How can we find which routine this
process is runn
On Jun 22, 2006, at 8:57 PM, Usha wrote:GTM>L +^TIU(8925,18):0 I $T W "LOCKED" LOCKED <> GTM>L -^TIU(8925,18) <> GTM>L -^TIU(8925,18) <> GTM>S DA=18,DIK="^TIU(8925," GTM>D ^DIK It hangs... And LKE's status at this point is
*** VistA Community Call -- Friday at NOON EDT ***
TOPIC: What are the requirements for a VistA support organization?
DATE: Friday, June 23
TIME: 12:00 Noon EDT
DURATION: 1 hour.
CONFERENCE CALL DIAL IN NUMBERS
USA 866-483-4159 (toll free)
Outside USA 706-634-0093
Conferen
By grabbing the lock I was trying to make sure it was not already locked. By
releasing the lock multiple times I was trying to make sure that the
following was not happening since I was not using the LKE utility before.
[EMAIL PROTECTED]:~> gtm
GTM>L +^TIU(8925,18):0 I $T W "LOCKED"
LOCKED
GT.M V5.1-000 is available
(http://www.sanchez-gtm.com/news/news_062206.htm). This adds
significant functionality - multi-site replication. Whereas previously,
a primary instance replicated to a secondary instance, with V5.1-000, a
root primary instance can replicate to as many as 16 secondar
Let's hope we can all talk the same "language."
>From iHealthBeat -
-
Alliance To Set Health IT Standards in Europe
-
A not-for-profit group of 22 technology and health care companies launched
Contin
Usha --
I don't know Fileman, but I am puzzled by what you are trying to do.
Why are you grabbing the lock and then releasing it multiple times?
Once will do. Is there something going on with the lock that we don't
know about? Look at the LKE utility if you want to see which process
has what
Hmm Does seem strange. I guess you could use my debugger and step
through DIK and see where it hangs. But debugging through Fileman
code is usually unproductive for me.
Kevin
On 6/22/06, Usha <[EMAIL PROTECTED]> wrote:
> On looking at the RPC routines used to delete the note, it seems DIK
