× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



For reference, the given scenario is the "Example" from LEFT() scalar at the given URL. Aside from the other [IMO poorly worded and lacking] documentation commentary, _that_ example is missing the /code point/ detail to properly explain the scenario. I doubt it is valid anyhow, even if that information had been provided. The value 'Jürgen' is the hex string x'4AC3BC7267656E' in UTF-8; more completely, the first two characters are J as 0x4A and ü as 0xC3BC where the latter is a two-byte character.

Refer also to the similar example in SUBSTRING scalar doc, which at least gives the code points defining the /characters/, but that example gives yet a different glyph, which is AFaIK also incorrect. The other characters noted: in the documentation for LEFT() Ê as 0xC38A and for SUBSTRING() ô as 0xC3B4 Just about any way you look at it, the 0xC3 is a 'C' from an EBCDIC perspective, and as to UTF-8, as I understand it the 0xC3 is an effective /escape/ character defining that the next byte is significant to defining this two-byte character, so I am not sure how one half of a character converts into anything.

So.... Some scalar functions may act on bytes versus on characters. A multi-byte character returned as only one of its bytes would not necessarily be represented by a glyph which is the /expected/ visual result. That assumes of course, that the single byte is valid when mapped to EBCDIC, to even enable showing a character.

LEFT(NAME, 2) and SUBSTRING(NAME, 1, 2) should be the same, and according to warning 54 in the V5R3 doc for the SUBSTR() scalar, it returns /bytes/ not characters; take care in reading, because SUBSTRING and SUBSTR are explained together in the v5r3 doc.

I have not tried a variation of the following from an ASCII client interface yet, but the green screen does not seem to work as I would expect... but I believe the report writer has some limitations for the given scenario because IIRC it believe it builds Graphic type with shift characters:

chgjob ccsid(37) /* to emulated session defined w/ that CCSID */
strsql
create table qtemp.c
(c037 varchar(15) ccsid 37, c273 char(15) ccsid 273
,u1208 varchar(15) ccsid 1208)
insert into qtemp.c (c037) values('Jürgen')
update qtemp.c set c273=c037, u1208=c037
select
left(u1208, 2) as l
, substring(u1208, 1, 2) as S
, substr(u1208, 1, 2) as s
, c.*, hex(c037) as xc037
, hex(c273) as xc273, hex(u1208) as xu1208
from qtemp.c c

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.