Re: Character differences between WDSC and SEU

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