 |
 |
Archives of the TeradataForum
Message Posted: Thu, 06 Dec 2001 @ 14:11:37 GMT
| Subj: | | Re: ����'s |
| |
| From: | | Geoffrey Rommel |
| | A colleague provides a reference table with a description field that may contain the � sign (eg 'Between �100 and �500'). | |
Is this an MVS data set or an ASCII file (Windows or Unix)? In either case, it would be helpful to know what the binary value of this
character is. I suspect that if it's EBCDIC, the value is x'5B', which in the U.S. is a dollar sign ($).
| | The values are inserted manually via NCR Queryman but show up on a TSO retrieve as a double quote ("). | |
Since Queryman is a Windows client, it uses ASCII. Ordinary 7-bit ASCII does not define a � sign, but it does appear at x'00A3' in
Unicode. My guess is that Queryman does not recognize this character, so it is substituting DEL (x'7F'). I assume that by "TSO retrieve",
you mean you are running BTEQ from MVS; anyhow, what is being retrieved is x'7F', which in EBCDIC is a double quote (").
| | It is when this value is exported the output file illustrates a =C1 sign where we originally started with the � ! | |
Hmm... Can't explain that.
| | However , if the value/record is inserted in the same way via TSO there is no issue (start with a �, finish with a �). | |
By "via TSO", do you mean using BTEQ from MVS? FastLoad? Anyhow, that's not surprising: the insert from MVS and the retrieve to MVS use
mirror-image translation tables, so everything gets converted correctly.
| | Alternatively, if the record is still inserted via Queryman but the � sign iis substituted with a $ sign , the table holds the
value as a � (retrieve the record on TSO) and therefore the output file holds a � sign ! | |
As mentioned above, I believe IBM designates x'5B' to be the local currency symbol. The ASCII '$' then gets inserted into Teradata
without translation, but converted to x'5B' ('�') when retrieved. Clear as a bell, eh?
| | Solution is in hand but is this a common problem with Queryman and are there any settings that can be played with to prevent
such a workaround. | |
Sorry, I don't know the answer to this one.
--wgr
| |
