Remove CR/LF from ZOR.18 field

Gina,

The BEST way is to get the sending system to build a correct message. This is really the sending system’s issue – not yours.

Failing that, my guess is you will need a pre Xlate Tcl proc to remove the offending characters.

We have a miserable app that doesn’t know about standards, and the exact

same problem with it, but luckily it isn’t a TCP connection.  I have a reaper

script that goes out and gets the message files; it makes decisions about

what messages should go (since the app also sends QC results as messages)

and as a side effect it cleans up the extraneous CR characters and logs the

fact so I can yell at the tech who hit enter.

If I had the problem on a TCP thread, I’d be very tempted to make the

thread a fileset, point the connection to a pipe, and clean it up as I wrote the

file.

Jim,

That won’t work, will it?  You’ve got to get to the message before it gets to

the parser in the engine.

–kevin (where did I put that engine/upoc diagram?) kinnell

Kevin,

For Communication protocols that are not sensitive to CR/LF (such as raw TCP/IP or MLP/PDL) that won’t make any difference until the message is parsed.

Typically that parsing is in the Xlate or when using GRM functions.

So at either the IB Tps or pre-xlate Tps (given no grm functions), you get the entire message within the encapsulation (mlp or length encoded for example).

For file protocols, I think you need to have a different style specified so that the entire message is read since the I/O handlers are typically sensitive to CR/LF.

Jim Kosloskey

I have an issue where a user is keying in a user_comment_field in the ZOR segment and hitting the ENTER key after the comment.  This CR/LF is making the engine think it is the end of the segment, and of course doesn’t recognize the next segment, because is actually isn’t a new segment.

I’m looking for ideas on the best ways to deal with this.  

For a quick way to deal with this, make the comment field repeating and replace all of the character pairs with ~ in a TCL proc.  This is how most multiple line results/comments are handled normally.  This assumes your receiving system is OK with the repeating field representing multiple lines.

If not, you need to replace all the fields with something in a TCL on ib_sms and change them back on the ob_sms.

Hope this helps,