[Nancy McDaniel]

We just recently upgraded our test environment to RedHat 9 and also to CIS 2022.09.03 cloverleaf version.  We have 8 test sites with a separate master site.

We are in the initial stages of testing and have not set a date when we want to upgrade our prod cloverleaf server to RedHat 9 and CIS 2022.09.03.

[Nancy McDaniel]

Jim,

We have several connections with them – we have one that we send data to them and that is successful.

this thread is elg_271_in which is the one that we are listening for messages from Experian.  They did some initial testing and it worked.

But when we went live with them today, we found out that there are doing load balancing and sending data from multiple servers.  They said they are seeing a lot of connection refused messages.

that is why we decided to try the multi-server configuration.

We have 2 multi-server input threads – Epic interconnect to our cloverleaf server with high volume.  Epic provide guidance – they recommended do not set the max client setting – so we have it at zero and it works great.  We did have to switch to the tcp protocol instead of the pdl-tcpip protcol but we were able to use the default MLLP protocol setting.

Your suggestion of bumping up the max client did not work.

We are getting the data but it goes to the error database with error 418 unable to write message as connection no longer available — retries disabled.

I can put in a support ticket and see if they can help me with this error.

 

[Nancy McDaniel]

Jim – yes we tried the multi-server with PDL tcp/ip thread.

Note this is the input (response) thread from Experian.

When I changed it from server mode to multi-server and went into multi-server config – only change was to click on option to save IP and port.

We then got the following error – message in error state.

Unable to write message as connection no longer available — retries disabled.

 

Attachments:

You must be logged in to view attached files.

[Nancy McDaniel]

Needing assistance.  We were able to use the x12_tcp.pdl when testing.

The issue is when we went to production, we discovered Experian is using multiple servers and only one was able to send data, the other was getting connection refused.

So then we tried switching over to multi-server option.  We had used it a couple of times for Epic interconnect interfaces with high volume.  The issue is that the info we had gotten on setting up multi-server  was using the tcp protocol instead of the pdl-tcpip protocol and then using default of mllp in encapsulation configuration.

We would like to use the multi-server option for the listening thread but have a question on what the setup should be since Experian uses different start and end block.

The PDL has STX for start and ETX for end.  I tried using that in the encapsulation wrapper but it did not recognize the wrapper.  Debug definitely shows Experian sending 02 for begin block and 03 for end block.  I then tried setting the start to 02 and end to 03.  But it is still not recognizing the data.  02 hex = STC ascii and 03 hex = ETX ascii.

Any suggestions on getting the multi-server option working for Experian X12 using tcp protocol instead of the pdl-tcpip is greatly appreciated.

 

[Nancy McDaniel]

James – I recompiled the X12_tcp.pdl and set the thread sending data to Experian to use the X12_tcp.pdl.  That seemed to work as we got the TA1 from them.  We send that back to the query interface on Epic.  We are asking them to send us eligibility data now that it looks like we resolved the protocol transmit begin/end blocks for them.

So far, it looks like it is working and I appreciate the help on this.

• This reply was modified 8 months, 2 weeks ago by Nancy McDaniel.

[Nancy McDaniel]

David – one more question, did you have to check the box on the outbound stub that say treat messages routed to this connection as inbound.

or was the tcl proc on the outbound tps for the stub enough?

[Nancy McDaniel]

David,

This might be something for us to look at.  I have done some updating destination in metadata.  But it looks like you are talking about changing the SOURCECONN to a different thread so that the message will process the routing from another inbound thread.  Definitely something to pursue.  We are on CL 19.1 in prod and testing with CL 20.1.1 on our test cloverleaf server.  When I say we had the main ADT process crash in test, it occurred of times after I had tried to switch to the direct routing.  I had just rolled it back rather than troubleshooting the exact issue.

Question – on the original ADT inbound thread are you routing to a stub i.e. file thread that has the OB tcl proc that will re-route it over to a different IB thread on a different process?

run {
# ‘run’ mode always has a MSGID; fetch and process it
keylget args MSGID mh
msgmetaset $mh SOURCECONN $HciConnName
lappend dispList “OVER $mh”
}

 

thanks,

Nancy

[Nancy McDaniel]

Rob,

Looks like the CIS 20.1.1 patch is not listed yet under downloads.

We have the CIS 20.1 that we upgraded to on our non-prod sites.  I was researching an issue with reload objects and saw that with this new patch, it will be disabled by default.  which would be nice since it is too easy to run and I have seen issues like unloadable xlt errors following reload objects.

[Nancy McDaniel]

This is an old warning – not new to 19.1.  You need to make sure that in your HL7 segments that same segment is not shown at the same level.  If you build your formats so that you group the related segments together, then they will be on different levels.  Both ROL are at the same level.  If you group ROL with your visit information -> starting at PV1, then PV2.  Then it will be at the next level.  Remember if you do this this changes the path for your xlates.

Make sure you are sending or receiving ROL at both levels, if you are only sending or receiving at one level, then get rid of the one that you will not see in the message. For example, if you only get ROL segment after the PV# segments and never at PID level, then remove the ROL in the PID level.  That will take care of the error.

[Nancy McDaniel]

thanks – that was the issue.  Some time ago, we were looking at global monitor and did not realize it was still up.  I have changed the setting to not auto start the monitord daemons.  The interval setting was the amount of time I had seen it restart

[Nancy McDaniel]

also switching to the user mode on tcpip – encapsulated – definitely understanding putting the start and end blocks but if we are getting 2 bytes invalid data before the valid start block on the ack – won’t we get a PDL error still in the log file?

[Nancy McDaniel]

I turned on eo for this thread and looks like vendor is sending 00 2f (null and forward slash) before 0b starting the ack message.

see below – any ideas in the pdl I  sent earlier that would prevent triggering the PDL error?

below is the info from this mornings log file:

pdl :read:DBUG/2:    storz_out:10/30/2018 12:19:44] Events: E 0, R 8, W 0

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] read 49 bytes

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] input buffer accepted 49 bytes, now 49

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44]  00 2f 0b 4d  53 48 7c 5e  |./.MSH|^|

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44]  7e 5c 26 7c  7c 7c 7c 7c  |~&||||||

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44]  7c 7c 41 43  4b 7c 32 34  |||ACK|24|

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44]  37 38 34 7c  50 7c 32 2e  |784|P|2.|

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44]  33 0d 4d 53  41 7c 41 41  |3.MSA|AA|

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44]  7c 32 34 37  38 34 0d 1c  ||24784..|

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44]  0d                        |.|

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] IDLE and 49 bytes but no error: starting READ

[pdl :PDL :DBUG/2:    storz_out:10/30/2018 12:19:44] PDL changed states: old 0, new 1

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] Calling Tcl procedure: hci_pd.read

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] with args: {}

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] Tcl procedure hci_pd.read returns ‘RECEIVE’

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] trying to match phrase: basic-msg

[pdl :PDL :WARN/0:    storz_out:10/30/2018 12:19:44] match phrase basic-msg rejected

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] multi: phrase #0 rejected; trying next

[pdl :PDL :ERR /0:    storz_out:10/30/2018 12:19:44] no-match: no more phrases to try

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] Calling Tcl procedure: read.error

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] with args: {{status error} {type no-match}}

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] pdiIgnoreInput: chop to 1, bolen 0

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] pdiIgnoreInput: after memmove: 0 + 48

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] pdiIgnoreInput: chop to 1, bolen 0

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] pdiIgnoreInput: after memmove: 0 + 47

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] Tcl procedure read.error returns ’47’

[pdl :PDL :DBUG/2:    storz_out:10/30/2018 12:19:44] PDL changed states: old 1, new 0

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] READ operation completed (47 bytes buffered still, 49 before)

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] IDLE and 47 bytes but no error: starting READ

[pdl :PDL :DBUG/2:    storz_out:10/30/2018 12:19:44] PDL changed states: old 0, new 1

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] Calling Tcl procedure: hci_pd.read

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] with args: {}

[pdl :PDL :DBUG/0:    storz_out:10/30/2018 12:19:44] Tcl procedure hci_pd.read returns ‘RECEIVE’

[Nancy McDaniel]

I took the suggestions and also looked at old post by Greg Day regarding flushing out the extra bytes.  

The vendor (who will not make changes to the current version and this is an old interface that has been here for some time – I just want to do some cleanup) is sending two bytes (null, sometimes 2f (forward slash) [00 2f].

The 2 extra bytes are (00) followed by another character.  

there is no issue recognizing the ack message.

I am wanting to suppress the PDL warn/error messages that get written to the log file.  It fills up the log files and adds clutter to the log files when reviewing for “real” errors.

Help is greatly appreciated.

[pdl :PDL :WARN/0:    storz_out:10/27/2018 10:53:44] match phrase basic-msg rejected

[pdl :PDL :ERR /0:    storz_out:10/27/2018 10:53:44] no-match: no more phrases to try

I have attached my latest copy of the pdl

Sometimes I see it as 2 bytes read  [00 2f]

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] input buffer accepted 2 bytes, now 2

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44]  00 2f                     |./|

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] IDLE and 2 bytes but no error: starting READ

[pdl :PDL :DBUG/2:    storz_out:10/27/2018 10:53:44] PDL changed states: old 0, new 1

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] Calling Tcl procedure: hci_pd.read

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] with args: {}

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] Tcl procedure hci_pd.read returns ‘RECEIVE’

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] trying to match phrase: basic-msg

[pdl :PDL :WARN/0:    storz_out:10/27/2018 10:53:44] match phrase basic-msg rejected

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] multi: phrase #0 rejected; trying next

[pdl :PDL :ERR /0:    storz_out:10/27/2018 10:53:44] no-match: no more phrases to try

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] Calling Tcl procedure: read.error

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] with args: {{status error} {type no-match}}

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] pdiIgnoreInput: chop to 1, bolen 0

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] pdiIgnoreInput: after memmove: 0 + 1

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] pdiIgnoreInput: chop to 18446744073709551615, bolen 0

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] pdiIgnoreInput: after clear: 0 + 0

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] Tcl procedure read.error returns ‘0’

[pdl :PDL :DBUG/2:    storz_out:10/27/2018 10:53:44] PDL changed states: old 1, new 0

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:53:44] READ operation completed (0 bytes buffered still, 2 before)

Sometimes I see it as right  before the message (example 49 bytes read, 1st two are the junk chars):

[pdl :read:DBUG/2:    storz_out:10/27/2018 10:48:11] Events: E 0, R 8, W 0

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] read 49 bytes

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] input buffer accepted 49 bytes, now 49

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11]  00 2f 0b 4d  53 48 7c 5e  |./.MSH|^|

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11]  7e 5c 26 7c  7c 7c 7c 7c  |~&||||||

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11]  7c 7c 41 43  4b 7c 32 34  |||ACK|24|

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11]  31 30 38 7c  50 7c 32 2e  |108|P|2.|

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11]  33 0d 4d 53  41 7c 41 41  |3.MSA|AA|

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11]  7c 32 34 31  30 38 0d 1c  ||24108..|

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11]  0d                        |.|

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] IDLE and 49 bytes but no error: starting READ

[pdl :PDL :DBUG/2:    storz_out:10/27/2018 10:48:11] PDL changed states: old 0, new 1

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] Calling Tcl procedure: hci_pd.read

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] with args: {}

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] Tcl procedure hci_pd.read returns ‘RECEIVE’

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] trying to match phrase: basic-msg

[pdl :PDL :WARN/0:    storz_out:10/27/2018 10:48:11] match phrase basic-msg rejected

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] multi: phrase #0 rejected; trying next

[pdl :PDL :ERR /0:    storz_out:10/27/2018 10:48:11] no-match: no more phrases to try

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] Calling Tcl procedure: read.error

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] with args: {{status error} {type no-match}}

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] pdiIgnoreInput: chop to 1, bolen 0

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] pdiIgnoreInput: after memmove: 0 + 48

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] pdiIgnoreInput: chop to 1, bolen 0

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] pdiIgnoreInput: after memmove: 0 + 47

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] Tcl procedure read.error returns ’47’

[pdl :PDL :DBUG/2:    storz_out:10/27/2018 10:48:11] PDL changed states: old 1, new 0

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] READ operation completed (47 bytes buffered still, 49 before)

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] IDLE and 47 bytes but no error: starting READ

[pdl :PDL :DBUG/2:    storz_out:10/27/2018 10:48:11] PDL changed states: old 0, new 1

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] Calling Tcl procedure: hci_pd.read

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] with args: {}

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] Tcl procedure hci_pd.read returns ‘RECEIVE’

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] trying to match phrase: basic-msg

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] multi_phrase_2: status = ok

[pdl :PDL :DBUG/0:    storz_out:10/27/2018 10:48:11] Calling Tcl procedure: read.done

[Nancy McDaniel]

I have been trying to locate good documentation on PDL drivers for pdl-tcpip (mlp_tcp.pdl).

the mlp_tcp.pdl we are using – just has the info below.  I am not sure on the format to modify as it looks like we get the 2 bytes before we ever the ack back.   If I had some good documentation on how these pdl drivers should be setup for mlp tcp protcol, than I can have a better understand of how to correctly format it.  I was unsuccessful in getting to format correctly so appreciate any guidance.

define driver tcpip-mlp;

   version: “2.0”;

end driver;

/* This driver manages the transmission of messages using the HL7 defined

* MLP protocol.  Each message is bounded by a start character

* and a stop string .

*

* The phrase basic-msg recognizes this message format.  Once recognized,

* the message data will be available from the ‘data’ field.

*/

define phrase basic-msg;

   ;

   field data = variable-array( not( ) );

   ; ;

end phrase;

[Nancy McDaniel]

Jim – the client is not wanting to address it.  they say they have an upgrade in the works and would prefer to look at it again when we go to their upgrade.  

I can follow up with them again on it.  I was hoping to try and suppress these warnings.  we are getting their acks and they are getting our adt data.

[Author]

Replies