Re: Embedded SQL in a Service Program versus in a Program

At first I did not understand anything you said in your reply. I think it's because I wasn't clear about what I'm comparing or contrasting. I finally think I see what you're saying - and I apologize - I did not mean to contrast shared vs unique - I meant to contrast shared vs default.

And I mean to limit this to CCSID 37, for the purpose of this discussion.

So your reply doesn't really fit my question.

Both LANGIDSHR and LANGIDUNQ put numbers before letters in the resulting output that I remember. So that the displayed results of something sorted according to LANGIDSHR when LANGID is ENU looks more like the order of ASCII than of EBCDIC - something with a number at the beginning of the text will appear BEFORE something with a letter at the start - this is opposite from EBCDIC.

I looked up the tables used for LANGIDSHR and LANGIDUNQ - here is the 2nd screen of the shared one for CCSID 37

Table: QLA10025S Library: QSYS CCSID value: 37

Sequence Char Sequence Char Sequence Char Sequence Char
0590 ¾ 0690 ä 0690 A 0730 É
0590 0 0690 à 0700 b 0730 Ê
0600 ¹ 0690 á 0700 B 0730 Ë
0600 1 0690 ã 0710 ç 0730 È
0610 ² 0690 å 0710 Ç 0730 e
0610 2 0690 Â 0710 c 0730 E
0620 3 0690 Ä 0710 C 0740 f
0620 ³ 0690 À 0720 d 0740 F
0630 4 0690 Á 0720 ð 0750 g
0640 5 0690 Ã 0720 Ð 0750 G
0650 6 0690 Å 0720 D 0760 h
0660 7 0690 a 0730 é 0760 H
0670 8 0690 ª 0730 ê 0770 í
0680 9 0690 æ 0730 ë 0770 î
0690 â 0690 Æ 0730 è 0770 ï

All variations of the letter A for example have the same weight - 690

And all numeric variations appear before all letters. And all punctuation is on the first page, ahead of alphanumerics, if you choose to look. Use WRKTBL to see this stuff.

MY POINT - heh - if someone uses LANGIDSHR or LANGIDUNQ, the resulting display will NOT be the same as if using simple default EBCDIC - it will be more like ASCII, although even it is not completely lined up with that - this is about appearance when dealing with numbers and letters.

Actually, as I recall now, text with initial punctuation DID appear first in the list - it was weird for users to see that.

Hope this is better stated. I think it is, or at least it is wordier!!

Vern

On 7/23/2014 4:17 PM, CRPence wrote:

On 23-Jul-2014 10:13 -0500, Vernon Hamberg wrote:

<<SNIP>> One thing about shared weight - hope I'm right on this -
the order looks as if it is ASCII, not EBCDIC - Chuck, can you
confirm? IIRC, that's what I saw - for example, numbers came first,
which is like ASCII, not last, as in EBCDIC.

The effect seemingly implied [collation of numbers vs alpha] is unrelated to shared-weight versus unique-weight. The /hex/ collation, by code-point, for which the /weight/ of a single 8-bit character is implicitly unique [i.e. 0x00 to 0xFF], has the digits ordered *before* alphabetic letters in ASCII, but digits ordered *after* alphabetic letters in EBCDIC.

The effect is due to the Sort Sequence being specific to the chosen /language/, aka a cultural [or effective locale] preference [as defined irrespective of the ASCII or EBCDIC character encoding, per conspicuously, the character encoding playing no role in the domains of cultural\language\locale]; the associated /language/ for the Sort Sequence (SRTSEQ) is identified by the Language Identifier (LANGID) specification, for each of Language Identifier Shared-Weight (*LANGIDSHR) and Language Identifier Unqiue-weight (*LANGIDUNQ).

I am not aware if any language preference for collation, *LANGIDSHR or *LANGIDUNQ, might mimic the default\hex EBCDIC of digits before alpha. Entirely plausible that there might be, and then for an ASCII 7-bit or 8-bit, the hex collation would be undesirable\incorrect in that language, such that a language-specific collation\sort-sequence would need to be used to obtain the proper order.