Re: Character differences between WDSC and SEU

I suspect the data was entered into the source physical file at the server using a job CCSID of *HEX, but with an effective language environment that reflects the CCSID 37; or some other non-500 CCSID, where the symbol named SM130000 as the "Vertical Line/Logical OR" is located at code point x'4F'. Given the 0x4F in the data is tagged with CCSID(500), that is *properly* the SP020000 as the "Exclamation point"; i.e. 0x4F in EBCDIC CCSID 500 is properly translated into the equivalent ASCII representation of the exclamation point character; i.e. as seen in the client viewer. I suspect then, that what is wrong [one perspective; may be other perspectives to view both the /problem/ and /solutions/] in this scenario is that...

Whatever enters the /vertical line/ character needs to effect the hex code point x'BB' in the data tagged as EBCDIC CCSID(500). Using STRSEU, this may be as simple as CHGJOB CCSID(37) prior to editing; assuming the US English CCSID correctly represents the language environment, such that the keyboard type [KBDTYPE] of the device and language identifier [LANGID] of the job also reflect US English. To avoid having to set the CCSID, I recommend that once the preferences are established for a person, that their user profile object is updated with the values to reflect their preferences; e.g. CHGPRF CNTRYID(US) LANGID(ENG) CCSID(37) /* optionally also SRTSEQ(*HEX) CHRIDCTL(*JOBCCSID) */.

For reference to the character\symbol names, their glyphs as images in the .pdf, and their proper locations for a given CCSID:

ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00037.pdf
ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00037.txt
ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00500.pdf
ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00500.txt

Regards, Chuck

mgarrison@xxxxxxxxxx wrote:

Thanks for the reply Chuck.

The DSPPFM of the source member is as shown below:

*...+....1....+....2....+....3....+....4
00020110030505436H Indent('|') FFFFFFFFFFFFFFFFFC4C9889A474754444444444
0002011003050543680954553DDFDD0000000000

and the CCSID of the source file is:
Coded character set identifier . . : CCSID 500
Any thoughts?


CRPence wrote:

The issue may be on the server versus the client. Is so, ...

Which glyph [i.e. the visible "character"] is presented by
STRSEU is not of very much interest. What is the hex code point
of the character, and what is the CCSID of the file [or CCSID
of the SRCDTA field]? The DSPPFM allows viewing the actual hex
code point; use the F10=Hex, then F11=Over\Under, and then read
& record the hex digits top-down, directly under the character
which presumably is, like with STRSEU, displayed as '|'.


mgarrison@xxxxxxxxxx wrote:

When I am using SEU a source member has the keyword
INDENT('|') on the H spec and when I bring up the same source
member in WDSC it shows the H spec keyword as INDENT('!').
What preference can I set in WDSC to show the keyword
correctly?