Re: Character differences between WDSC and SEU

[CRPence <CRPbottle@xxxxxxxxx>]

  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?