[Jo Ellen Laansma]

I am really struggling getting the 15 for the NAK.  I’ve tried the format command to hex and it writes it as the string 15 (31 35) two characters; not the number.   🙄

[Jo Ellen Laansma]

Bob, that is what I have been thinking.  I was considering implementing a master site (for tclprocs, variants and tables) but am not seeing an upside.  A symbolic link was already established for our tclprocs.  And creating a master site that only allows (i.e.) tables and variants to be edited in those sites, seems counter productive.  I’ve been searching these boards to see if there is a downside to simply using symbolic links for the paths I truly want to share.  

Russ, you seem to discourage the use of symbolic links.  Is that from previous experience?  Was there something that happened?

[Jo Ellen Laansma]

forget the above question.

[Jo Ellen Laansma]

forget the above question.

[Jo Ellen Laansma]

I’m having this same problem with HL7 v2.6 FT1-29 which is defined as CWE length 250.  The value is 58160081146.  I tried changing to ST length 250 and it yields the same error.  I tried PATHCOPY and still the same error.  It seems most people have had success increasing the size.  Has anyone not been successful by increasing the size?

[Jo Ellen Laansma]

I’m also seeing that message in the tester.  HL7v2.6 FT1-29 is defined as 250 CWE.  When the input string is more than 4 bytes, it yields the error.  I tried changing from CWE to ST, but to no avail.

[Jo Ellen Laansma]

Lastly…  I found that when you “resend” messages it had the unicode character ufffd and when they came from a thread in the traditional way it used xd7.

In case anyone wasnted to know there is a difference between resending and thread throughput.

[Jo Ellen Laansma]

So I thought maybe now that it’s going through the engine, it interprets the characters differently.

…

Yes, it’s back to the original d7.

[Jo Ellen Laansma]

And then, after successfully testing, I try to implement it and it will not work.    Such frustration.

I thought maybe it was the “state” it was in when I resent it, so I made sure the inbound thread received it as it normally would by creating extra threads and sending the message down a pipeline.

Another post said that the tester needed \ or {} to indicate it was a control character and the implemenation did not.  I’ve tried both ways and neither work.  I gave up passing as a variable, afraid that was impacting the esacape sequences and it still does not work.

[Jo Ellen Laansma]

By gum, using a Unicode translation fixed it!

I regsub’d ufffd instead of x.

[Jo Ellen Laansma]

I’m a little confused by your statement.  The largest value in one signed byte is FF.  And a hex editor shows D7.

But I did what you suggested and the mystery character came up with 65533 which is FFFD .  

I guess that proves the theory that what it’s reading in is not what I thought and I agree with your statement that the tcl must be somehow interfering with the read.  But it still leaves me unable to change the value within the tcl preproc.  (I’ve tried xffxfd and xfffd).

I think I’m relegated to capturing the bad messages in a file and use a unix command to replace the original d7 problem (which does work), although cumbersome.

Thank you for your comments.  If you figure out (based on the message I uploaded) how to change the character, I would still be very interested in the result.

[Jo Ellen Laansma]

I have invented my own code, tried supplied code, and cannot get what you are suggesting to work.

In my message, there is an embedded xd7 in OBX-5.

I’ve tried:

[Jo Ellen Laansma]

Thank you for the clarification, Steve!  That is the part that had me baffled.

[Jo Ellen Laansma]

I did see that post, but that gives a trailing space if the last field is not valued and I do not want trailing spaces.

[Jo Ellen Laansma]

I put this all in the post proc so that I could utilize the output of the concatenation as my input.  But apparently, it would not change the value of the output after my post proc.

I ended up having to do this in two steps:

1) use the post proc to have the concat feature work and assign to a temporary variable.

2) added a new step of the temporary variable that trimmed the trailing space.

[Author]

Replies