× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 22 Jan 2013 08:32, Michael Schutte wrote:
<<SNIP>> Notice the ô

In the database file it's a value of 3C. But it appears when the data
is written to the ifs.

Not clear on what "it appears" means. No matter really. Whatever glyph is presented is not typically of interest, merely the code point; i.e. what is the hex code for the byte position, irrespective of whatever glyph might appear in its place.

<<SNIP>>

When I upload the file to http://en.webhex.net/ from the IFS it still
has a hex value of 14. but displays a period instead. That could
just be their choice of how to display the character.

Makes sense. x'14' in ASCII is a control character, much like x'3C' is in EBCDIC; i.e. there is no specific glyph in the character set to represent the character because its intent for existence is not to be displayed but to cause a /control/ action.

<<SNIP>> The current process <<SNIP>> builds a database table.
Then the user must issue the command EMAILFILE.

Email File command basically creates a file in QTEMP, then issues
CPYTOSTMF command with STMFCODPAG equal to *STDASCII <<SNIP>>

Given a database file with the EBCDIC code point x'3C' as part of the data, the correct effect when translating the data to ASCII is that the corresponding character will be represented by the code point x'14'.

http://www.ibm.com/software/globalization/cdra/appendix_g.html#EBCDIC to ISO-8
_i EBCDIC to ISO-8 i_
"Figure 101. Control Character Mapping - SBCS EBCDIC to ISO-8

_EBCDIC_ | _ISO-8_
_Hex Abbr. Character Name_ | _Hex Abbr. Character Name_
... |
3C DC4 Device Control 4 | 14 DC4 Device Control 4
...
"


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.