Replace degree symbol with blank

[Don Brown]

Does anyone have a TCL example to sub the degree symbol “

Topic

[Russ Ross]

Here is an example using the hcitcl interactive interpreter I did on the fly to illustrate what might work for you

hcitcl>set x “xb0F”

Russ Ross
RussRoss318@gmail.com

[Don Brown]

That worked Russ. Thanks for the examples.

I had an issue in 6.0 when runing it through the testing tool with encoding set to ASCII. It kept showing it didn’t sub the symbol with a blank. I selected a couple of the other encoding formats…greek being one of them, and it tested out ok.

[Russ Ross]

Our setup is running cloverleaf client IDE on Win7 and the cloverleaf 6.0 server on AIX.

The encodings I’ve also had varied degrees of success with are

binary

win-1252

UTF-8

I’m starting to think win-1252 will cause the upper 128 characters to display correctly in the Win7 IDE tester but is wrong if output to a file on our AIX cloverleaf server.

To get it correctly output to a file on our AIX server usually requires binary or UTF-8 encoding be used in the tester, but then doesn’t display correctly in the windows IDE testing tool.

Point being when it comes to the upper 128 characters what is displayed does not always match what goes out the wire.

Unfortuantely, this is also true for SMAT when the IDE client is on Win7 and the cloverleaf server is on AIX, which is our case.

I think the discrepancy occurs becuase for us, what is being displayed is on Win7, while what goes out the wire is on AIX, and encoding outcome not surprisingly seems to vary between the 2 operating environments.

It is knonwn there are cases that the testing tool isn’t 100% reliable to produce what the real integration will prodcue.

The most typical divergents between testing tool and actual interface from my observation seem to occur when dealing with non-keyboard characters, and especially the upper 128 charcaters.

When dealing with upper 128 characters, to know for sure what is going out the wire, I typically have a mock TCP/IP listener on localchost grab the outbound interface and raw route to a dump file, and hcihd the dump file.

Russ Ross
RussRoss318@gmail.com

[Keith McLeod]

I am working through an upgrade from 5.7 to 6.1.  Generally everything looks good, however,  I have 2 symbols that came across in 5.7 fine, but in 6.1 they are different.  My comparison is from newline extracts using the hcismat and hcismatdb tools.  See Below

5.7: OBX|1|FT|Report^Report||ORDER ID: CM-539892157

[Robert Milfajt]

When this happened to me I had to change the encoding on the inbound and outbound threads from ASCII to bypass.

Hope this helps,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Russ Ross]

We had to do something similar to what Robert described when upgrading from Cloverleaf 5.6 to cloverleaf 6.0.

For interfaces that were EBCIDIC we set the ib thread to binary and any thread it routes to is set to binary, anything after that could be ASCII.

For example we have inbound sites, distribution sites, and outbound sites so for one integration goes like this:

ib_site_1 (both these interfaces are set to binary encoding)

Russ Ross
RussRoss318@gmail.com

[Keith McLeod]

I double checked this with changes to encoding, however the results did not pan out to what is acceptable.  The odd part is that it appears fine through the testing tool.  I turned up the engine noise and captured the logs and still show the change occurring.

It is like HEX 39 30 B0 changes to HEX 39 30 EF BF BD, yet this is the result of a copy command in an xlate….  The engine noise set at Enable_all shows this change.  I also wrote out the files source and dest from SMATDB and show this change.

Puzzling in the respect that other destinations from this same source are OK.  I am going to try recreating the copy command to see if it makes a difference.

[Keith McLeod]

I did find this regarding this substitution.

[David Barr]

What’s the encoding set to on the inbound and outbound threads? If you’re printing the characters (for debugging purposes) before the data has gone through the outbound encoding step that could explain why your outbound data doesn’t match your debug statements.

[Author]

Replies