×
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 mailing list archive is Copyright 1997-2025 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.