@jimrawls17
Forum Replies Created
-
AuthorReplies
-
Rodney,
It sounds like a Windows firewall issue I had when I went to Windows 10. You might need to allow hciaccess to communicate through Windows firewall.
Hope this helps.
Hi Yamil,
We had to update our Windows Firewall to allow
hciaccess to communicate through the firewall. Once this was done everything was running like it had on Windows 7.Hope this helps.
Jim
Having had to recover from data losses multiple times, I’d be interested to hear more about your experience with this setting, especially as nothing else has worked for us (including HA). Have you experienced data loss with this flag set? Have you had a chance to compare throughput with and without the setting? We have on the order of 6 million inbound messages a day.
Thanks.
February 8, 2016 at 9:21 pm in reply to: Moving from Cloverleaf 6.0.2 to 6.1.1 – Delimiters changed #83664Thanks guys. Looks like Infor fixed what we’ve been coding around all of these years…
February 5, 2016 at 1:51 pm in reply to: Moving from Cloverleaf 6.0.2 to 6.1.1 – Delimiters changed #83660This is an HL7 2.5.1 ORU^R01^ORU_R01 lab result message (both inbound and outbound). This input matches the 6.1.1 output, as do the delimiters, so it appears that 6.0.2 (and 5.7.2, where this was developed) had been making a substitution of ^ for & in this case.
The copy is straight across for the whole field.
There is a post-xlt Tcl proc that renumbers the OBX and NTE segments. It splits segments at the field level, updates OBX-1 or NTE-1 and reassembles the segments.
Both inbound and outbound variants are version 2.3. We did not modify the type from DATE on the inbound, just the length.
When I changed the inbound variant to TIMESTAMP (and left the length as 14) then I do get the correct output using COPY. Thank you.
I found this interesting because, during another attempted work-around, we copied from PV2-8 to a variable and did NOT experience truncation, but when copying from the variable to PV1-44, again we see truncation. So apparently the variable also inherits the DATE attribute
January 28, 2015 at 1:23 pm in reply to: Received Email from LicenseKey.Care-Lawson@infor.com #81943We received this too.
Follow-up:
We needed the 32-bit ncurses library installed. Not sure why the lock manager is using this, but anyway, this fixed the issue. 🙂
Mary,
I’ve seen timeouts when we were trying to connect using a DNS name and DNS was acting up. Try
nslookup connection
where connection is the DNS name you’re trying to connect to. If it takes awhile to respond, you might consider going to the IP address instead of the DNS name.
February 5, 2013 at 4:05 pm in reply to: Time out when issuing hciprocstatus or hciconnstatus #77937Jon,
Is the process hung? We saw this sometimes in the early 5.x releases when we were running on AIX.
Hi Gary, Did you declare env as global? That’s the only time I’ve seen that error.
Hi Jim,
Neither, as we didn’t have to cross processes. The X12 270 transaction from the Cerner thread was sent to the outbound HTTP thread; those 2 threads only were in the first process. The X12 271 transaction inbound to Cloverleaf – the multi-server thread – was in the second process with the outbound Cerner thread (pdl tcpip config). This seemed to give the inbound multi-server connection dedicated resources; in our original configuration, all four threads were in the same process, and when batch 270s went out and all of the 271 responses flooded back in, the process was overwhelmed.
I wanted to post a follow-up in case anyone runs into this in the future. We ultimately resolved this by putting Cerner inbound to HTTP outbound into a process by themselves, and the multi-server thread and thread back to Cerner in another process by themselves. Thanks to Lawson for their diligence and patience in helping us figure this out.
Hi Peter,
Rather than reinvent the wheel, you may want to look at a powerful utility called HL7Spy (http://www.hl7spy.com/). It’s fairly inexpensive per license and easy to use. 🙂
Regards,
Jim
We were able to run tcpdump between the 2 nodes last week. Our network admin gave us a clean bill of health. Turns out they sit on the same switch, which also showed no errors.
In a very few cases, the messages were actually lost and never showed up on the Cloverleaf logs. In the mean time we have been able to work around the problem by throttling the other system to the point that we no longer receive errors or lose messages.
This brings me back to my original question regarding limits for multi-server connections… are there any? I guess my next step will be to talk to support.
-
AuthorReplies
