[Lonnie Wright]

Thanks to all of you for your help.  

It turns out that the code that changed the facility field was on the sending system.  The resend that they did the first time I tested with the hcitcptest was not sent through the normal path, so it was not changed.  After running several tests that some of you recommended, I set up another hcitcptest and this time asked them to create a new transaction.  This one came across with the facility changed.  I then showed that to a programmer on their side and he was able to find the code and make the needed modification.

I’m sorry to have run you down a wild goose change, but I truly do appreciate your help.

[Lonnie Wright]

John, sorry, you did say network trace in your message, I just missed it the first time.

[Lonnie Wright]

Russ,

Good suggestion.  I checked the site pdls directory when I first discovered the problem, but I had not thought of modifying the mlp_tcp.pdl to add an echo.  I’ll change the name to be sure it gets the correct one.

John,

Are you talking about a network trace?  It seems that since the hcitcptest received the unmodified message, that the correct message is making it to the server, but I’m willing to try anything.  I’m going to try the pdl change first and if that doesn’t help, I’ll try your suggestion.

[Lonnie Wright]

Russ,

This is happening in both the PROD and TEST which are run on 2 different AIX servers.  The change is intentional because the routing script is set to use the modified facility.  

There are no other interfaces on the system using the same port, I used netstat to verify this as well as a search of all of the NetConfigs on the server.

The hcitcptest tool receives the message in the unaltered form which indicates that the modification is taking place somewhere in Cloverleaf, but the SMAT file and an echo from a SMS/IN_DATA proc shows the altered transaction.  The only place I can think of that could be changing it before this point is the PDL, but that is the standard mlp_tcp.pdl.

I have coded the routing UPOC to get around this by using the facility as sent by the vendor, but I really would like to know where this is being changed.

I was hoping someone on this forum could tell me where to look, if not the next step will be to contact support.

[Lonnie Wright]

As you can see below, the change has been made before it reaches the SMS/IN_DATA proc.

This is what was sent:

MSH|^~&|MEDILINKS|ECLH|EMORY|ECLH|20120508070154||DFT^P03|837db85768f04f52901e5fdb0f132798|T|2.4

EVN|P03|20120508070154|20120508070154

PID|||6546546||SUAVE^RICO||19710303|M|||||(   )   -|||||TEST123456

FT1|||050812|20120508100000|20120508070154|C1|17194640||SUAVE, RICO|1||0|CHG_MED_THERA|||||IN|||VRT6ZJP

And this is what is displayed by the in_data proc:

MSH|^~&|MEDILINKS|C>RESP|EMORY|ECLH|20120508070154||DFT^P03|837db85768f04f52901e5fdb0f132798|T|2.4^MEVN|P03|20120508070154|20120508070154^MPID|||6546546||SUAVE^RICO||19710303|M|||||(   )  -||||TEST123456^MFT1|||050812|20120508100000|20120508070154|C1|17194640||SUAVE, RICO|1||0|CHG_MED_THERA|||||IN|||VRT6ZJP

[Lonnie Wright]

By TPS proc do you mean the SMS/in_data proc?

The protocol is pdl-tcpip.

Because of decisions made by our management, we are still running Cloverleaf 5.1.

[Author]

Replies