- This topic has 1 reply, 1 voice, and was last updated 8 years, 11 months ago by
.
-
Topic
-
I’m using Cloverleaf 6.1 on Windows Server 2008 R2. In my Xlate I’m checking the OBX-3.1 against a Table and if the value is not found in the table then the default output is “0”. The goal is to suppress the OBX segment if the value is not in the table. To do this I have my pathcopy and all of my copy statements for the OBX in an IF statement that evaluates if the output of the table is “0”.
THE ABOVE CODE WORKS. So that’s not the issue.
The issue is that when I use my if statement in my Xlate to evaluate if the output of the table the process panics. Below outlines the very odd behavior of this Xlate.
The If statement is: @vitalsInd ne =0
1) If I change the above if statement to say @vitalsInd eq =0 it does not panic! (of course it gives me the exact opposite of what I want)
2) If I change the above if statement to say @vitalsInd ne =”0″ it does not panic. (but then it also doesn’t suppress any of the OBX segments.
3) When I put debug statements in the Xlate I can see the Xlate is completing fine. It’s just bombing out when it tries to write the outbound message.
Below is the panic message that I’m getting and attached is my Xlate screenshot.
Code:[prod:prod:INFO/0: proc5_cmd:10/12/2015 12:21:58] Thread fr_site1_vitals_adt_p5 not auto-started.
[prod:prod:INFO/0: proc5_cmd:10/12/2015 12:21:58] Thread fr_site1_bar_p5 not auto-started.
[prod:prod:INFO/0: proc5_cmd:10/12/2015 12:21:58] Thread to_dbM_bar_p5 not auto-started.
[prod:prod:INFO/0: proc5_cmd:10/12/2015 12:21:58] Thread to_dbM_vitals_adt_p5 not auto-started.
[prod:prod:INFO/0: proc5_cmd:10/12/2015 12:21:58] Thread to_dbM_dev_bar_p5 not auto-started.
[prod:prod:INFO/0: proc5_cmd:10/12/2015 12:21:58] Thread to_dbM_dev_vitals_adt_p5 not auto-started.
[tcl :out :INFO/0: proc5_xlate:10/12/2015 12:21:59] XLT is loaded from local site, read e:cloverleafcis6.1integrator__Flagler_Master/formats/hl7/2.5.1/Allscripts_SCM_Vitals/fields from master
[tcl :out :INFO/0: proc5_xlate:10/12/2015 12:21:59] XLT is loaded from local site, loading e:cloverleafcis6.1integrator__Flagler_Master/Tables/Normalized_GenderCode_v2.tbl from master site
[pti :sign:WARN/0: proc5_xlate:10/12/2015 12:21:59] Thread 1 ( proc5_xlate ) received signal EXCEPTION_ACCESS_VIOLATION:
[pti :sign:WARN/0: proc5_xlate:–/–/—- –:–:–] The thread attempted to read from or write to a virtual address for which it does not have the appropriate access.
[pti :sign:WARN/0: proc5_xlate:10/12/2015 12:21:59] PC = 0xffffffff
PANIC: “0”
PANIC: Calling “pti” for thread proc5_cmd
—– Scheduler State —–
Thread Events State Priority Runnable PT Msgs
0 0 SCHED_IDLE 0 0 0,0,0
1 0 SCHED_RUNNING 0 0 1,0,0————– Thread 0 (proc5_cmd)————–
ti: 0x00DFAB90
tid : 0
HostPthreadId : 0x00000000
EventList : 0x00DDF648
PolledEvents : 0x00DDF660
PthreadEvent : 0x00DFBDB0
ReadyEvents : 0x00DFD238
CtrlMsgs : 0x00DFD250
UserCtrlMsgs : 0x00DFD268
UserDataMsgs : 0x00DFD280
StartArgs : 0x00000000
SchedState : SCHED_IDLE
SchedPriority : 0
Killed : 0
—– Registered Events —–
el: 0x00DDF648
elCount : 2
elHead: 0x00DFD2B0
elTail: 0x02CBB750
ele: 0x00DFD2B0
event: 0x00DFBDB0
prev : 0x0
next : 0x2cbb750
ev: 0xdfbdb0
evType : PTHREADS
evStrDesc :
evSocket : 0
evHandle : 0
evMsgQue : 0
evTid : 0
evState : 0
evPtMsg : 0x0
evUserData : 0x0
evCallBack : 0x0
evCbShutdown : 0x0
evRecurFreq :
ele: 0x02CBB750
event: 0x02C02E08
prev : 0xdfd2b0
next : 0x0
ev: 0x2c02e08
evType : SOCKET
evStrDesc : Command port listen
evSocket : 1156
evHandle : 0
evMsgQue : 0
evTid : 0
evState : 0
evPtMsg : 0x0
evUserData : 0x2cb4910
evCallBack : 0x40cb10
evCbShutdown : 0x40d290
evRecurFreq :
—– Polled Events —–
el: 0x00DDF660
elCount : 0
elHead: 0x00000000
elTail: 0x00000000
—– Ready Events —–
el: 0x00DFD238
elCount : 0
elHead: 0x00000000
elTail: 0x00000000
—– Outstanding Pthread Ctrl Msgs —–
pmq: 0x00DFD250
Count : 0
Head : 0x00000000
Tail : 0x00000000
—– Outstanding Pthread User Ctrl Msgs —–
pmq: 0x00DFD268
Count : 0
Head : 0x00000000
Tail : 0x00000000
—– Outstanding Pthread User Data Msgs —–
pmq: 0x00DFD280
Count : 0
Head : 0x00000000
Tail : 0x00000000————– Thread 1 (proc5_xlate)————–
ti: 0x02F9BA18
tid : 1
HostPthreadId : 0x000004A4
EventList : 0x0304B7A0
PolledEvents : 0x0304B5A8
PthreadEvent : 0x02DAC1D0
ReadyEvents : 0x0304B1B8
CtrlMsgs : 0x0304B5D8
UserCtrlMsgs : 0x0304B290
UserDataMsgs : 0x0304B2A8
StartArgs : 0x030660F8
SchedState : SCHED_RUNNING
SchedPriority : 0
Killed : 1
—– Registered Events —–
el: 0x0304B7A0
elCount : 5
elHead: 0x0304B500
elTail: 0x034364B0
ele: 0x0304B500
event: 0x02DAC1D0
prev : 0x0
next : 0x304b2d8
ev: 0x2dac1d0
evType : PTHREADS
evStrDesc :
evSocket : 0
evHandle : 0
evMsgQue : 0
evTid : 1
evState : 0
evPtMsg : 0x0
evUserData : 0x3066438
evCallBack : 0x50d040
evCbShutdown : 0x50d1e0
evRecurFreq :
ele: 0x0304B2D8
event: 0x02DAC270
prev : 0x304b500
next : 0x304b518
ev: 0x2dac270
evType : SOCKET
evStrDesc : ICL Server Listen
evSocket : 1432
evHandle : 0
evMsgQue : 0
evTid : 1
evState : 0
evPtMsg : 0x0
evUserData : 0x3064878
evCallBack : 0x50cf20
evCbShutdown : 0x50d1e0
evRecurFreq :
ele: 0x0304B518
event: 0x02DAC3B0
prev : 0x304b2d8
next : 0x3436480
ev: 0x2dac3b0
evType : POLLED
evStrDesc :
evSocket : 0
evHandle : 0
evMsgQue : 0
evTid : 1
evState : 2
evPtMsg : 0x0
evUserData : 0x2fd1210
evCallBack : 0x521f40
evCbShutdown : 0x0
evRecurFreq :
ele: 0x03436480
event: 0x030E9408
prev : 0x304b518
next : 0x34364b0
ev: 0x30e9408
evType : NT_EVENT
evStrDesc : New Thread
evSocket : 0
evHandle : 1444
evMsgQue : 0
evTid : 1
evState : 0
evPtMsg : 0x0
evUserData : 0x3442000
evCallBack : 0x5259a0
evCbShutdown : 0x0
evRecurFreq :
ele: 0x034364B0
event: 0x030E8558
prev : 0x3436480
next : 0x0
ev: 0x30e8558
evType : NT_EVENT
evStrDesc : Xlate thread Eng Event
evSocket : 0
evHandle : 1504
evMsgQue : 0
evTid : 1
evState : 0
evPtMsg : 0x0
evUserData : 0x2fd1210
evCallBack : 0x5212c0
evCbShutdown : 0x0
evRecurFreq :
—– Polled Events —–
el: 0x0304B5A8
elCount : 1
elHead: 0x0304B260
elTail: 0x0304B260
ele: 0x0304B260 — POLLED event: 0x02DAC3B0
—– Ready Events —–
el: 0x0304B1B8
elCount : 0
elHead: 0x00000000
elTail: 0x00000000
—– Outstanding Pthread Ctrl Msgs —–
pmq: 0x0304B5D8
Count : 1
Head : 0x03470018
Tail : 0x03470018
PthreadMsg: 0x03470018
ptmType : 1
ptmSender : 1
ptmCtrl : 3358
ptmNext : 0x00000000
ptmDataPtr: 0x00000000
ptmDataInt: 0
—– Outstanding Pthread User Ctrl Msgs —–
pmq: 0x0304B290
Count : 0
Head : 0x00000000
Tail : 0x00000000
—– Outstanding Pthread User Data Msgs —–
pmq: 0x0304B2A8
Count : 0
Head : 0x00000000
Tail : 0x00000000PANIC: Calling “dbi shutdown” for thread proc5_cmd
PANIC: Calling “dbi shutdown” for thread proc5_xlate
PANIC: Process panic—engine going down
PANIC: assertion ‘0’ failed at PthreadInterface.cpp/766
-
Replies
-
-
I’ve figured out the problem but have no idea why it’s a problem. Seems like a bug to me but I have found a workaround.
The problem is with my variant. I’m trying to use one variant for all message types so I do not have to write and maintain multiple Xlates. The problem is that with an A01, A08, and A04 the OBX segments are before the DG1 and for A03’s the OBX segments are after the DG1. To avoid having to create multiple Xlates I built my variants as follows:
Code:
MSH
[{SFT}]]
EVN
PID
[
PV1
[PV2]
[{OBX}]
]
[
[{DG1}]
[{OBX}]
]I’m also not copying the DG1 segments to my outbound variant.
So, I’m not sure why the IF @vitalsInd ne =0 causes a problem when trying to copy the OBX segments to the second group but when I changed my code to write them to the first group it fixed the problem.
I do understand why the variant would get confused but what I don’t understand is what is the difference between a “ne” and “eq”. Why would a “ne” cause problems but an “eq” did not?
Anyways, this works now so I’m ok.
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
