First, I just want to mention that I hope the data you sent is for a fictitious patient as the name and ssn are in the listing. I have deleted that section from my response and would encourage David or Nancy to remove that section from the server.
As for your locking problem, it looks like LRORD is never being set as it is not in the list of values so the code if freezing while trying to lock +^LRO(69,LRYR,2). This line of code is trying to find the next available order number. Data dictionary for this field is:
69,.5 CURRENT ORDER NUMBER 2;1 NUMBER
INPUT TRANSFORM: K:+X'=X!(X>9999999)!(X<0)!(X?.E1"."1N.N) X
LAST EDITED: MAY 3,1984
HELP-PROMPT: TYPE A WHOLE NUMBER BETWEEN 0 AND 9999999
DESCRIPTION:
The count of the order number for the current year.
DELETE TEST: 1,0)= I '$D(^XUSEC("LRLIASON",DUZ))
You may need to check your LOCK_SPACE using LKE. As there is no timeout set on the lock, LOCK continues slow poll till space becomes available. Or perhaps there is a hung lock on LRO(69,LRYR,2). Unlocking that may be the key. I’m not sure how you are getting a proper order number in file 69 for those orders that you are manually unlocking…
I don’t seem to have this routine name in our VistA environment, our routine is called LROW2, and the unlock you are doing manually is done in the code following the hung lock command:
S ^LRO(69,LRYR,2)=LRORD L -^LRO(69,LRYR,2)
From: hard...@googlegroups.com <hard...@googlegroups.com>
On Behalf Of Jai Singh VistA
Sent: Thursday, February 23, 2023 11:35 PM
To: Hardhats <hard...@googlegroups.com>
Subject: [External] [Hardhats] GT.M is Acquiring Locks while Creating Lab Order !!
CAUTION: External email. Do not click links or open attachments unless you verify. Send all suspicious email as an attachment to Report Spam.
Hi Everyone,
From last two days, we are getting some issue in Integration of Laboratory.
The GT.M is acquiring lock on File Number 69 while Creating Laboratory Order.
Whenever the team is clearing the lock then the order is successfully processed. Same is again happening with New Laboratory Order HL7 Message.
Below is the ZJOB Status of the Process ID.
Seeking your kind help.
JOB #: 100776 Process Name:
Device: 0
Process State: hib
JOB Type: -direct CPU Time: 00:00:55 Login time: 06:43:20
Routine line: <NEXT^MXLROW2>
NEXT L +^LRO(69,LRYR,2) S LRORD=1+^LRO(69,LRYR,2) F Q:'$D(^LRO(69,"C",LRORD)) S LRORD=LRORD+1
Job Exam Action: L//??
Enter '^' to choose another JOB
Enter 'L' to display status information about other Job
Enter 'S' to display current System Status
Enter 'V' to display local variables of other job
Enter '*' to load other job's symbol table into current job and Q
Enter 'K' to send a Kill Job command to other job
Job Exam Action: L//V
Send intrp to job. Any error means you don't have the privilege to intrpt.
INTRPT issued to process 100776
JOB #: 100776 Process Name:
Device: 0
Process State: hib
JOB Type: -direct CPU Time: 00:00:55 Login time: 06:43:27
Routine line: <NEXT^MXLROW2>
NEXT L +^LRO(69,LRYR,2) S LRORD=1+^LRO(69,LRYR,2) F Q:'$D(^LRO(69,"C",LRORD)) S LRORD=LRORD+1
Section Locks
MLG:828614,MLT:16
LOCK ^HLMA(1581448544) LEVEL=1
LOCK ^HLMA("AC","I",235) LEVEL=1
LOCK ^LRO(69,3230224,1) LEVEL=4
Section Devices
0 OPEN RMS STREAM NOWRAP
0-out OPEN RMS STREAM NOWRAP
SCK$13173 CLOSED
SCK$14364 CLOSED
SCK$14663 CLOSED
SCK$14893 CLOSED
SCK$17574 CLOSED
SCK$23222 CLOSED
SCK$24411 CLOSED
SCK$27624 CLOSED
SCK$31998 CLOSED
SCK$34548 CLOSED
Section Intrinsic Variables
$DEVICE=""
$ECODE=""
$ESTACK=8
$ETRAP="D ERROR^HLTP3"
$HOROLOG="66529,35244"
$IO=0
$JOB=100776
$KEY=""
$PRINCIPAL=0
$QUIT=1
$REFERENCE="^XUTL(""XUSYS"",100776,""JE"",""I"",10)"
--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to
Hardhats+u...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
hardhats+u...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/hardhats/96f19524-c9df-42db-9c20-188e56f1b58bn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/MN2PR09MB46816AF7C57848A238F8B8ACBEA89%40MN2PR09MB4681.namprd09.prod.outlook.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/60142481-89ba-4b25-ba69-a16248d86879n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/MN2PR09MB468140C39E0F1ADB0CEFF4EBBEA99%40MN2PR09MB4681.namprd09.prod.outlook.com.
Are you talking about Pharmacy picklist? That should have nothing to do with file 69. But it could be using quite a bit of lock space in the region that your lab code also runs in. This still points to a lock space issue to me. I don’t see in your below comments the complete output of the LKE SHOW command where it shows the available percentage of free lock space. You could have a problem with locks that have been abandoned over time which would require a cleanup. But like you said, maybe someone else with more targeted experience than me can better help you!
To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/e289f07b-63db-4ca6-948c-d760761a2060n%40googlegroups.com.
2. This error is happening when the system is trying to write to the sign-on log, file 3.081. It is trying to use an empty IP address which causes the null subscripts error. You can get more data if you use ^XTER to look at the stack and variables at the time including who the user is.
3. I don’t know your system at all, but from the text it looks like the NOPRINCIO is related to HL7 message processing. From the manual:
The most common causes for the principal device to cease to exist involve terminal sessions or socket connections (including those from processes started by inetd/xinetd). When the remote client terminates the connection, the underlying PRINCIPAL device becomes inaccessible making any subsequent attempt to READ from, or WRITE to, it hopeless. In the case of terminals, a user closing the window of a session without cleanly exiting from the process sets up the case that can drive this error.
To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/a2370223-f9f8-4981-9a98-a3c4b1856643n%40googlegroups.com.
On Mar 2, 2023, at 7:03 PM, Kevin Toppenberg <kdt...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/01cb4d66-49dc-43aa-9b63-6840b0dea3b6n%40googlegroups.com.