Re: Character differences between WDSC and SEU

[CRPence <CRPbottle@xxxxxxxxx>]

  It has been since V2R1M1 that CCSID support is available.  There 
is little excuse in year 2010 still to be running in an environment 
of CCSID(*HEX) [i.e. equivalent to CCSID(65535)] which indicates 
character translations should not occur.  Hoping that there is a way 
to make the ASCII client somehow just "understand" that the 
exclamation point character is a vertical line character would just 
continue the way things worked in the EBCDIC-only environment prior 
to database CCSID support.  That is not a good idea.  Better to 
finally just [/bite the bullet/ and] implement the necessary changes 
to effect a proper CCSID environment.

  I thought I was being clear, that the *glyph* noted as being 
visualized via SEU is moot.  It is the hex code point x'4F' that is 
the problem.  Just because what is visualized is inferred to be 
correct, does not make the value correct.  Because CCSID(65535) is 
being used instead of a proper EBCDIC CCSID, the database is being 
lied to about what data was entered into the CCSID(500) source 
member.  The 5250 is displaying what it thinks the user wants to see 
according to the keyboard type and language environment, due to the 
*JOB setting of *HEX the interface to the database from SEU is "do 
not convert any data" even though the database file is tagged with 
CCSID(500), and the perceived-as-correct character is placed into 
the database without any conversion; i.e. as the hex code point 
0x4F.  Then when WDSC is asked to retrieve the data from the 
CCSID(500) member, the client says "I am ASCII, so send me that 
EBCDIC data *after* converting to ASCII", so the database converts 
that 0x4F in EBCDIC CCSID(500) as an /exclamation point/, and 
converts that to the equivalent ASCII CCSID(1208) [or whatever the 
client expects] as ... you guessed it ... an *exclamation point*.

  As alluded in my first reply, there are a variety of perspectives 
to view the problem and the solution.  If you do not like the 
perspective I chose in that message, then perhaps if I offer 
another.  Albeit more dangerous for possibility to effect other 
undesirable results due to any other data which was entered with 
different /assumptions/ about the data, there is the option to tell 
the database that all past data entered into the members is assumed 
to have been in the same pseudo-ccsid=37 [at least not-ccsid=500] 
language environment.  That can be accomplished by issuing:

  CHGPF TheSrcPF CCSID(37)

  After such a change the 0x4F will be treated as the vertical line 
character, and thus when WDSC asks for the EBCDIC data to be 
converted into ASCII, the database will convert the EBCDIC vertical 
line character into a ASCII vertical line character.

  Alternatively, to correct just the specific incident of the wrong 
character....  Beyond just CHGJOB CCSID(37), actually /correcting/ 
the data in the file.mbr is required.  That is, rather than just 
displaying the data after changing the job CCSID, actually re-enter 
the data so the necessary character conversions are effected; save 
the changed data.  The negative effects of this are such that if 
other members are found to have the same issue, then it would have 
been better to perform the CHGPF noted earlier; that if some 
specific corrections are made, then a later CHGPF CCSID(37) is made, 
then all of the past /corrections/ need to be performed again.



Regards, Chuck

mgarrison@xxxxxxxxxx wrote:
> What is displaying in STRSEU is correct as Indent('|') but what 
> is being displayed in WDSC as Indent('!') is not correct. I am
> really looking for a solution in WDSC that will allow WDSC to
> display it correctly. When I do a CHGJOB CCSID(37) as you
> suggested then SEU is no longer correct. Our jobs are currently
> set as shown below.
>
> Language ID  . . . . . . . . . . LANGID         ENU 
> Country or region ID . . . . . . CNTRYID        US 
> Coded character set ID . . . . . CCSID          65535