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

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.