Preserving double quote pairs (Active Nulls)

This topic has 10 replies, 5 voices, and was last updated 13 years, 8 months ago by John Mercogliano.

Creator

Topic
February 1, 2007 at 4:00 pm #49047
Greg Eriksen
Participant
A coworker is having an issue with cloverleaf not copying an Active Null (pair of double quotes) from an input message field to the output message field. We’ve searched the forum and found many posts about removing quotes, but none for keeping them.

Cloverleaf apparently sees the quotes in the input field, defines them as a xlateInType of ‘null’, and the quote characters themselves aren’t available in the xlateInVals value.

Is there any way to get around this behavior of cloverleaf so that the double quotes can be copied to output? It seems ridiculous that we would have to code a proc for every single field where an active null could possibly occur, to test for the type of ‘null’ and then hard-code the double quote characters (backslash escaped?) to the xlateOutVals list.
Creator

Topic

Viewing 9 reply threads

Author

Replies
- February 1, 2007 at 4:22 pm #60549
  Keith McLeod
  Participant
  Typically no special action is required. What is your copy statement? All my Active Nulls |””| pass without issue from source to destination. I generally use pathcopy statements for the whole segment, then adjust whatever is neccessary for the desired segments.
- February 1, 2007 at 4:33 pm #60550
  Greg Eriksen
  Participant
  We must all be “control-freaks” here, because none of us is using bulk or path copies. She is copying at the field level, and when we use a (pre) tcl fragment, the xlateInType is ‘null’ and the xlateInVals is empty, even though the input message has a pair of double-quotes in that field.
- February 1, 2007 at 5:21 pm #60551
  Keith McLeod
  Participant
  Have you done a copy without a pretcl proc? It should still copy the Active Null.
- February 1, 2007 at 6:03 pm #60552
  Jim Kosloskey
  Participant
  Greg,
  
  Perhaps you have already taken this into account, but if your proc is checking the field value it could be getting misled (as you noted the value is null).
  
  If you have an ‘Active or HL/7’ null (“”), your proc needs to check the Type (as you have noted it is ‘null’) and act accordingly.
  
  If you need an example, email me directly and I will send you an xltp type proc which checks for ‘Active or HL/7) nulls.
  
  Thanks,
  
  Jim Kosloskey
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- February 1, 2007 at 6:07 pm #60553
  Jim Kosloskey
  Participant
  Greg,
  
  By the way, I also rarely use BULKCOPY or PATHCOPY.
  
  I am more inclined to accept PATHCOPY although it appears there are still some problems with it.
  
  I do not find it terribly inconvenient to bypass their use.
  
  I just thought you might like to know you are not alone.
  
  Jim Kosloskey
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- February 1, 2007 at 7:02 pm #60554
  Greg Eriksen
  Participant
  Keith,
  
  We started back from scratch again, just copying input field to output with no tcl proc, and lo and behold the quotes got copied. Then we added a pre-tcl fragment that simply parsed the first xlateInVal into a variable and then created a list with that variable as the xlateOutVal, and the quotes were still copied, so just having a tcl fragment isn’t the problem.
  
  Where we apparently are having problems is when we try to do anything else with that field. For reasons I wont try to explain here, we want to append a component delimiter (^) after the active null, and as soon as we do that the quotes disappear from the output. If we change the xlateOutTypes to ‘ch’ or ‘st’, we still don’t get the desired output. The only way we could get ‘quote_quote_carat’ in output was to just hard-code backslash_quote_backslash_quote_backslash_carat as the xlateOutVal. But that means we have test each field for an active null and only do the hard-coded value conditionally, otherwise copy the actual value.
  
  But thanks for your reply because it helped us narrow down what was happening. The other thing that was really throwing us off was that whenever we tried to echo out the value of xlateInVals, it was displayed as empty if the input was double-quotes, and we never found a way of quoting the variable containing the quotes to make them show up.
- February 1, 2007 at 7:14 pm #60555
  Greg Eriksen
  Participant
  Jim,
  
  She is going back to work on the problem some more, but you are right that it probably hinges on understanding how to work with a field of type ‘null’. I may email you for your proc, because believe it or not this is the third issue involving nulls (how to output an active null, how to test for active null, how to deal with acutal nulls – hex 00 – in input messages) that has come up this week, so anything to understand them better would be helpful at this point. Much ado about nuthin’!
  
  Thanks for the moral support on our not using bulk/pathcopy. It’s just the way we always coded on our other engines. We want to send receiving systems only the data they require and nothing more, and it just seems easier to selectively copy rather than have to clear things out of the output. I have been afraid though that we would get a certain number of translations running and find out cloverleaf was bogged down because all those individual field copies were somehow horribly inefficient. But I’m hoping that it just makes the xlate code more lengthy and complicated, without adding extra load to the engine.
- February 1, 2007 at 7:58 pm #60556
  Keith McLeod
  Participant
  Line 1: Copy your field to a variable such as @null_flag with a preproc that tests for xlateInType of null. Set @null_flag to 1 if true. 0 if false.
  
  Line 2: Create an IF statement testing for @null_flag == 1. If this is true copy =””^ to your output field.
  
  I am sure there is more to this. Hope this or Jim’s procs help.
- April 5, 2011 at 6:01 pm #60557
  Osmand Christian
  Participant
  In case someone else also runs into this issue, here is how I handled it. See attached screenshot.
  
  O.C.
- April 6, 2011 at 4:31 pm #60558
  John Mercogliano
  Participant
  Gregg what you appear to be doing is attempting to add an additional subfield delimitor with no data following it. In a translate that is very hard to do without sending out an entire string with a subfield delimiter at the end as you are finding out. The translation always drops the last empty subfield during normal processing but you can trick it if you use the ^ as part of a string.
  
  Now you should be able to write a generic xlt proc to do this that takes the field you need to check and returns what you require using code similiar to this.
  
  if { [string equal [lindex $xlateInTypes 0] null] } {
  
  set xlateOutVals
  John Mercogliano
  Sentara Healthcare
  Hampton Roads, VA
Author

Replies

Viewing 9 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.