tcl join command on 19.1

[Tom Rioux]

We are testing for our migration from 6.1.2 to 19.1.    In our testing we have found an issue with the tcl join command.     Here is the situation:

We have a list that consists of unit, room, and bed.

Unit:   ECC     Room: {}   Bed:  {}   Each is in it’s own variable.   We are then joining those together with the ^.    There are instances where our room and bed are blank.   On 6.1.2, our script that joins them is populating the outcome of the join command as “ECC”.  It does not contain the extra carets.    When I run the same message through the same script on 19.1, our script that joins them is populating the outcome WITH the extra carets:  “ECC^^”.

This isn’t really that big of a deal right now but may have issues in other cases.  Does anyone know why it is performing this way?

A little more background.   The 6.1.2 is running on UNIX.  The 19.1 is running on LINUX.

Thanks…

Tom Rioux

Thomas.Rioux@christushealth.org

Topic

[David Barr]

That’s weird. May I see the code?

[Tom Rioux]

Here is the code snippet that sets utilizes the join command:

catch { set PV1_3list [ lreplace $PV1_3list 0 0 $newloc ] }        ;# Update Location
catch { set PV1_3list [ lreplace $PV1_3list 1 1 $newroom ] }    ;#   Room and Bed
catch { set PV1_3list [ join [ lreplace $PV1_3list 2 2 $newbed ] “^” ] }

This code has been in place since before I started working here and has been working like a champ.

Thanks…

Tom Rioux

[Jim Kosloskey]

Are you making the Unit Room Bed variables into a list then joining that list with the ^ separator?

Edit – Never mind your code came through while I was posting the above.

• This reply was modified 5 years, 2 months ago by Jim Kosloskey.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jim Kosloskey]

The only thing I can think of is I believe 19.1 uses a different release of Tcl than 6.1.

Perhaps the behavior has been tightened.

What does the PV1_3list look like prior to the join? Are there indeed null elements {ECC {} {}}?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Tom Rioux]

Jim,

What you have listed is correct.  There is indeed null elements.   The funny thing is, that I can go to hcitcl on each platform and the outcome is exactly the same:  ECC^^    It is only when it is run through the engine that the difference shows up.

 

[David Barr]

Maybe the code is throwing additional errors that you aren’t seeing because of the catch statements. What happens if you get rid of the catch?

[Jim Kosloskey]

Hmmm so it appears the Tcl level may not be an issue.

Is this code used in an Xlate or is it in a UPoC?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Tom Rioux]

It is in the route as a pre-xlate.

[Jim Kosloskey]

OK so do the carets appear in the message after the proc executes and prior to the Xlate?

If so, do they then disappear in the 6.1 Xlate and not in the 19.1 Xlate? If so, and you save that message to a file (prior to the Xlate) then run it through the HL/7 tester are things different between the releases?

So in other words, stepping through the processes following the Tcl pro, where does the 2 releases diverge?

 

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Charlie Bursell]

I assume PV1_3list already exists?  Other wise you would get an error you would never see because of the catch.

Regardless of whether the join command has changed or not this code, even though old, is not good code.

Why the catch?  It would just hide any legitimate error.

At the end of the code PV1_3list is now a scalar so the name is misleading.

Try something like

set location [string trimright [join

^] ^]

I don’t have 6.2.1 installed so I cannot test it there but in 19.1 if room and bed are empty you will get the extra ^ at the end.  Just trim it off.

My guess, assuming it did work the way you said in an earlier version, they noticed it and fixed it. The way it works now, IMHO, is the way it should work.

[Tom Rioux]

Thanks everyone.   To answer Jim’s question…since this is happening during a pre-xlate in the route, the only time we notice it downstream is when the route is a raw route.   When it hits a translation, it is fine.    To answer Charlie, yes this code is very old and pre-dates my time here.   It isn’t how I would have coded it either.  We will trim it off if needed on those raw routes.

I was just curious about the why the command is acting differently between the two platforms.

Thanks…

[David Barr]

Cloverleaf 6.1.2 uses TCL 8.5.10. Cloverleaf 19.1 uses TCL 8.6.8. I don’t see anything in the TCL 8.6 documentation indicating a change that would affect the section of code that you posted. I would try putting some echo statements right before this block of code of all the referenced variables (PV1_3list, newloc, newroom, newbed) in a case where it isn’t working. I’m trying to imagine how this code could output something without a caret. One possibility is the “newbed” variable is not defined, so the third line throws an error rather than changing the value of PV1_3list, and you don’t see the error because of the catch statement.

[Jim Kosloskey]

So 6.1:

Xlate or Raw Route no carets?

19.1:

Xlate no Carets, Raw Route carets?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Author]

Replies