Re: XML files in the IFS and incorrect code page.

On 26-May-2016 13:15 -0500, Booth Martin wrote:

<<SNIP>> WRKLNK suggests that the data is EBCDIC but the properties
of the file say it is 0819. btw, it is WRKLNK that suggested the
00500 code page. <<SNIP>>

Where the use of Work With Object Links (WRKLNK) is noted, presumably what was meant instead, perhaps, was Edit File (EDTF) or Display File (DSPF); i.e. presumably from WRKLNK, having performed 2=Edit or 5=Display, then a message might "say" the CCSID is 819 and that possibly the expectation was "the 00500 code page".? Otherwise, perhaps option 8=Display-Attributes was used? That shows the CCSID assigned to the file, but I am unaware of any suggestions that panel presents about what might be the proper CCSID given a suspected mismatch between the actual-data and the ccsid-attribute. No matter, the crux is, the WRKLNK itself reveals nothing but the list of files, so some additional action had to have been taken to reveal the CCSID; i.e. WRKLNK did not /suggest/ CCSID(500), though the effect from some option taken against some file from WRKLNK may have /suggested/ something.

FWiW: Use F10=Display-Hex from option 5=Display against the file from WRKLNK [or more directly, just use DSPF] to see the actual code points from which the visible glyphs were derived. Because EDTF and DSPF show only EBCDIC characters\glyphs to the inherently EBCDIC 5250 display, non-EBCDIC\ASCII data is implicitly converted to EBCDIC, with the intention that what is presented on the screen will be capable of being read\understood as visible glyphs; that is why the hexadecimal values must be viewed instead, to know what the actual data is, irrespective the glyphs seen. Or use the Dump (DMP) command to dump the STMF and DATA-, then review the spooled dump of the contents of the file [which includes the hexadecimal code points]; the dump does not attempt to make the /eye-catcher-data/ [seen on the far right side, between asterisks] is not falsified\displayed as the presumed-equivalent glyph [corresponding to the EBCDIC character after translation from ASCII], so when the data is actual ASCII, most text data will appear there, as gibberish.