[Daniel Lee]

Thanks Jim.  I bet it’s as simple as a suppress that I have at the top of my Xlate. (I have like 5 of them in my Xlate)  I’ll take a look at it tonight and post a reply.  There is not a SEND in my Xlate, I was only using the SEND as a debug tool.  But now that you’ve explained what happens in the Xlate when a Suppress is called it makes perfect sense that the SEND would generate the message.

[Daniel Lee]

I’m not going to be able to look at this until tonight but I’m thinking I may have a suppress way at the top of my script.  However, I thought that if the Cloverleaf Xlate code hit a suppress then it stopped processing the Xlate.

I also was able to test this in a route on the test system and saw that it’s working the same way as it is in the test tool so the test tool is working fine.  It’s in my Xlate somewhere.

[Daniel Lee]

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.

[Daniel Lee]

Jim, he’s using an old version of Mirth on his side that doesn’t give him the option for a persistant connection.  He had his inactivity timeout set for every 65 seconds which was the issue.  I’m asking him if he can set it to every 8 hours so it will kind of act like a persistant connection.  My main reason I posted this in the first place is because I misunderstood the Cloverleaf logs and thought he was sending some junk hex characters across the connection to us.  Not sure why Cloverleaf logs an “Unrecoverable read error” and a “mlti_phrase_2” error when the remote side shuts down but I guess it is what it is.

[Daniel Lee]

UPDATE:  I think I’m reading too much into those .log files.  I tried connecting to the hcitcptest tool instead of connecting to the gMed interface.  Then I went into the hcitcptest tool and simply stopped and started the interface and I’m getting the exact same Cloverleaf log events.  So, I no longer think the gMed interface is sending us junk charactes and instead think they are just cycling their interfaces after about a min. of inactivity.  Look at the below Cloveleaf log events from when I just tested stopping and starting the remote interfaces.

Code:

[pti :even:DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Processing SOCKET (PDL server) event 0x03543D20
[pti :even:DBUG/1:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Calling cb 0x438460
[pdl :read:DBUG/2:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Events: E 32, R 8, W 0
[pdl :PDL :ERR /0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] read failed: Unknown error
[pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] input buffer accepted 0 bytes, now 0
[pdl :PDL :ERR /0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] read returned error 0 (No error)
[pdl :PDL :INFO/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Unrecoverable read error: 60691968, 0603ents: E 32, R 8, W 0
[pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] IDLE and 0 bytes and an error: starting READ
[pdl :PDL :DBUG/2:to_gMed_oru_ris_p2:07/23/2015 13:09:13] PDL changed states: old 0, new 1
[pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Calling Tcl procedure: hci_pd.read
[pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] with args: {}
[pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Tcl procedure hci_pd.read returns ‘RECEIVE’
[pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] trying to match phrase: basic-msg
[pdl :PDL :INFO/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] input-error in dfa ‘basic-msg’
[pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] multi_phrase_2: status = error
[pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] Calling Tcl procedure: read.error
[pdl :PDL :DBUG/0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] with args: {{status error} {type input-error}}
[pdl :PDL :ERR /0:to_gMed_oru_ris_p2:07/23/2015 13:09:13] PDL signaled exception: code 1, msg device error (remote side probably shut down)

[Daniel Lee]

Terry, how do I turn tcp and tcp trace on in 6.1?  I do not see that option anywhere.  The thing I want to make sure everyone understands is this is an “outbound” thread.  It’s set up to send data and I’m not sending anything.  All I do is make a TCP/IP connection.

Ed, I tried the hcitcptest and I do not see any traffic at all.  Why when I connect via the hcitcptest tool wouldn’t I see any data attempt to cross but when I connect via Cloverleaf I see the following line every 65 seconds:

Code:

[pdl :PDL :INFO/0:to_gMed_oru_ris_p2:07/21/2015 13:21:30] Unrecoverable read error: 59090032, 6E02ents: E 32, R 8, W 0

[Daniel Lee]

Charlie, thanks for your reply.  The logs attached to this post is with the EO logging turned all the way up.  All I see is those two characters being sent in.  The odd part is this is an outbound thread.

[Daniel Lee]

This may be too crazy of a solution but from what I can see of the data you provided I think you could create an HRL that works.  I think this will only work if “I9” is always in the first componant of the repeated field.  If so, then you could set up the fields leading up to your ICD9 data as one VRL, set the repeating ICD9 data up as a second VRL (using a carrot as the field seperator), and any trailing fields could be set up as a third VRL.  Then in your HRL, set up the ICD9 data as a “Repeat While” and in the “Field:” box put the name of the field (something like I9VRL.I9Field or whatever you named the VRL and Field in your VRL) and in the “Value:” box put I9.

If your lucky enough to have that “I9” text consistantly in the first componant I think what’s I’ve said above is possible.  Without some sort of tag on the repeating data I’ve never been able to figure out how to do what you’re asking in a VRL.

[Daniel Lee]

Quote:

One possibility that could cause this is creating an alert for another interface by copying the alert for this interface and over looking to change the wording of the copied alert.

Wow, wouldn’t have thought of that.  I did double check though and this was not the case for the alert.

[Daniel Lee]

That doesn’t seem to add up to me.  Can you send the basis for your itterate and a screenshot of the settings on the test tool when you run it?

[Daniel Lee]

Show me your variant and what’s inside your itterate.

[Daniel Lee]

PS.  I know that my screenshot has my PID and PV1 inside my itterate but that’s only because those segments repeat in an A17.  They do not repeat in your message so they shouldn’t be in your itterate.

[Daniel Lee]

I can’t tell exactly what is going on with what I’m seeing on the screen.

[Daniel Lee]

Hi Christopher, hope things are going well for you at Orlando Health.  My suspension would be either your .log/.err files in your process directories or your .msg/.idx smat files.  I’m thinking that alert to measure the delta of disk usage would fire if your % disk full was reduced by 20% as well as if it increased by 20%.  Depending on how your log files are set up, if you cycle a process the .old .log and .err files are either deleted or moved to your LogHistory directory.  When you cycle your threads the .msg and .idx files are either deleted are moved to your SmatHistory directory.

If you are set up to delete your old files that that would explain the reduction.  However, I’m not an AIX expert but I’m thinking that if your History directories are on different volume groups than /quovadx then that may cause this fluctuation as well.

Do the alerts correspond to when processes or threads are being cycled?  How many days worth of SMAT files to you retain.  Do the alerts corresponding to the time when the oldest SMAT files fall out of your rotation?  

Just some thoughts.

[Daniel Lee]

I take back my last post as I just looked at your outbound variant.  Instead try the following:

Basis:  5(0).0

Path Copy:  5(0).0(%g1) -> 6(%g1)

If the above doesn’t work you may have to try path copying each segment:

Path Copy 5(0).0(%g1).IN1 -> 6(%g1).IN1

Path Copy 5(0).0(%g1).IN2 -> 6(%g1).IN2

etc.

[Author]

Replies