iconv() fails? - IBM AS400

This is a discussion on iconv() fails? - IBM AS400 ; I'm getting wrong output by iconnv() doing ebcdic to ascii translation (no dbcs neither unicode involved). When on the input buffer I have x'0D25' translating to ccsid 819 I get x'0d85' instead of x'0d0a'. Translating from ccsid 819 x'0d0a' into ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: iconv() fails?

  1. iconv() fails?

    I'm getting wrong output by iconnv() doing ebcdic to ascii translation
    (no dbcs neither unicode involved).
    When on the input buffer I have x'0D25' translating to ccsid 819 I get
    x'0d85' instead of x'0d0a'.
    Translating from ccsid 819 x'0d0a' into an ebcdic ccsid, I get x'0D25'
    correctly.
    Why?

    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  2. Re: iconv() fails?

    I get the from CCSID 37 -> CCSID 819
    hex -> IN: 0D25
    hex -> OUT: 0D0A

    For 280 & 1144:
    280 -> 819
    hex -> IN: 0D25
    hex -> OUT: 0D0A
    1144 -> 819
    hex -> IN: 0D25
    hex -> OUT: 0D0A

    For an alternate input of x'0D15':
    280 -> 819
    hex -> IN: 0D15
    hex -> OUT: 0D85

    Is it possible the input was actually x/0D15, perhaps if only by some
    error changed from the expected input value x/0D25; i.e. prior to actual
    evaluation by inconv()? Otherwise I would suspect there is some
    corruption in the table which evaluates the transition from one
    character to the other; such a problem would, I expect most likely, to
    be specific to a CCSID; either source or target. Do all of the above
    EBCDIC CCSID source 0x0D25 conversions give consistent 0x0D85 results?

    Regards, Chuck
    --
    All comments provided "as is" with no warranties of any kind
    whatsoever and may not represent positions, strategies, nor views of my
    employer

    Dr.UgoGagliardelli wrote:
    > I'm getting wrong output by iconnv() doing ebcdic to ascii translation
    > (no dbcs neither unicode involved).
    > When on the input buffer I have x'0D25' translating to ccsid 819 I get
    > x'0d85' instead of x'0d0a'.
    > Translating from ccsid 819 x'0d0a' into an ebcdic ccsid, I get x'0D25'
    > correctly.
    > Why?
    >


  3. Re: iconv() fails?

    il 15/11/2007 23.25, Scrive CRPence 40750408:
    > I get the from CCSID 37 -> CCSID 819
    > hex -> IN: 0D25
    > hex -> OUT: 0D0A
    >
    > For 280 & 1144:
    > 280 -> 819
    > hex -> IN: 0D25
    > hex -> OUT: 0D0A
    > 1144 -> 819
    > hex -> IN: 0D25
    > hex -> OUT: 0D0A
    >
    > For an alternate input of x'0D15':
    > 280 -> 819
    > hex -> IN: 0D15
    > hex -> OUT: 0D85
    >
    > Is it possible the input was actually x/0D15, perhaps if only by some
    > error changed from the expected input value x/0D25; i.e. prior to actual
    > evaluation by inconv()?

    I'm pretty sure that the input was 0d25, it was obtained with \r\n C
    literals, then I carefully watched it in debug mode. But 0d15 too has
    no sense it's translated into 0d85, isn't it?
    > Otherwise I would suspect there is some
    > corruption in the table which evaluates the transition from one
    > character to the other; such a problem would, I expect most likely, to
    > be specific to a CCSID; either source or target. Do all of the above
    > EBCDIC CCSID source 0x0D25 conversions give consistent 0x0D85 results?

    Yes, just before posting here I tried 37, 280, 1144 with the same
    results, I compiled the same very simple C program on a 520 iSeries with
    V5R4, on a 270 with V5R2 ad on an old 170 with V4R4, on both 520 and 270
    I had wrong results, while I had correct results on the 170. All the
    systems have 2932 as primary language.
    I saw that the iconv_t object returned by iconv_open() is always
    referring to the correct ccsid I specified.
    I tried QTQCVRT api too with the same results, btw I think that QTQCVRT
    and iconv uses the same structures.
    I have the same error on two different systems with different os levels,
    for that I don't think that the same thing became corrupted the same
    very particular way. Then I don't know what could be damaged. I
    displayed QASCII *TBL on v4r4 and v5r4 and for input x25 the output is
    x0a on both, but I do not really know what iconv() is actually using.

    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  4. Re: iconv() fails?

    Dr.UgoGagliardelli wrote:
    >> Is it possible the input was actually x/0D15, perhaps if only by some
    >> error changed from the expected input value x/0D25; i.e. prior to actual
    >> evaluation by inconv()?

    >I'm pretty sure that the input was 0d25, it was obtained with \r\n C
    >literals


    Was the program compiled with SYSIFCOPT(*IFSIO) ? If *NOIFSIO (the default)
    is used I believe \n is 0x15 but with *IFSIO \n will be 0x25.

    See the "Text Streams" section of the ILE C/C++ Programmer's Guide
    (SC09-2712):
    http://publib.boulder.ibm.com/infoce...s/sc092712.pdf


    --
    -----
    Walt Madden -- IBM System i software development




  5. Re: iconv() fails?

    il 16/11/2007 17.55, Scrive Walt Madden 40750408:
    > Dr.UgoGagliardelli wrote:
    >>> Is it possible the input was actually x/0D15, perhaps if only by some
    >>> error changed from the expected input value x/0D25; i.e. prior to actual
    >>> evaluation by inconv()?

    >> I'm pretty sure that the input was 0d25, it was obtained with \r\n C
    >> literals

    >
    > Was the program compiled with SYSIFCOPT(*IFSIO) ? If *NOIFSIO (the default)
    > is used I believe \n is 0x15 but with *IFSIO \n will be 0x25.

    ox15 or 0x25 it's ok, doesn't matter, but the translation into ascii
    ox85 instead of 0x0a is wrong anyway.



    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  6. Re: iconv() fails?

    A quick search on the tokens CP00819 & EBCDIC yielded a table which
    actually shows the EBCDIC 0x15 as being round trip with the ASCII 0x85.
    That was the first table presented [at the following links], but it is
    a /Tuxedo/ code page conversion with a "Note: The TUXEDO default ASCII
    and EBCDIC code pages differ slightly from CP-00819 and CP-00037."
    However, all of the other EBCDIC Latin-1 tables that are presented, seem
    to suggest 0x15 -> 0x0A which is consistent with the stated expectation.
    http://edocs.bea.com/elink/mainfram/...xug/codepg.htm
    http://edocs.bea.com/tuxedo/tcp/v91/pdf/tuxug.pdf
    http://e-generation.beasys.com/tuxed...1/pdf/user.pdf

    Then looking at my v5r4 system, I see the following prompted tables
    show 0x15 -> 0x85 which is the stated outcome [which my inconv() test
    showed as well], but that result is obviously in conflict with the
    stated expectation:
    CRTTBL TBL(QTEMP/X) SRCFILE(*PROMPT) BASETBL(QUSRSYS/QA6o697819)
    That table defines the "CHRID(*N 1130) to CHRID(697 819) translate
    table". Similarly, with the QA6q697819 table that defines the "CHRID(*N
    1132) to CHRID(697 819) translate table".

    I have asked of someone with a much deeper understanding of the
    subject matter, why the 0x85 instead of 0x0A, in the noted iconv().

    Regards, Chuck
    --
    All comments provided "as is" with no warranties of any kind
    whatsoever and may not represent positions, strategies, nor views of my
    employer

    Dr.UgoGagliardelli wrote:
    >>>> Is it possible the input was actually x/0D15, perhaps if only by some
    >>>> error changed from the expected input value x/0D25; i.e. prior to
    >>>> actual evaluation by iconv()?
    >>>
    >>> I'm pretty sure that the input was 0d25, it was obtained with \r\n C
    >>> literals

    >>
    >> Was the program compiled with SYSIFCOPT(*IFSIO) ? If *NOIFSIO (the
    >> default) is used I believe \n is 0x15 but with *IFSIO \n will be 0x25.

    >
    > ox15 or 0x25 it's ok, doesn't matter, but the translation into ascii
    > ox85 instead of 0x0a is wrong anyway.


  7. Re: iconv() fails?

    The answer is that the conversion is _both_ /working as expected/ and
    /working unexpectedly/. Depending in which /camp/ one resides, their
    way is correct and the other camp is incorrect. Apparently history has
    this conundrum originating with the C language [with ASCII origins]
    failing to have explicitly defined what the \n was in ASCII; e.g. did
    that \n intend to represent a new line, a next line, or a line feed.?
    Thus when the C language was developed for EBCDIC, the \n was open to
    interpretation, versus having been explicitly documented. The choice
    was /new line/ for EBCDIC [it is after all, an 'n'], for which the
    best-fit was deemed to be the /next line/ character in ASCII -- again,
    \n was not defined to be either of ASCII /next line/ or /line feed/.
    Apparently many ASCII C compilers hard coded x'0A', and it was many
    years later before anyone questioned the choice of /next line/ versus
    /line feed/, long after there was already a large base of /next line/ code.

    Some resources that describe some code points:

    The code pages [ccsid] resources are aimed at the glyphs rather than
    control characters, so the control characters [which would be duplicate
    in all of the EBCDIC tables] are not included at the first link below,
    but at the second and third links below:
    http://www.ibm.com/servers/eserver/i...codepages.html
    http://www.ibm.com/servers/eserver/i...trolcodes.html
    http://www.ibm.com/software/globaliz...appendix_g.jsp


    ** Following must be viewed in fixed-font; tables in two links above

    Control Character Mapping - SBCS EBCDIC to ISO-8
    _EBCDIC_ _ISO-8_
    Hex Abbrev Character Name Hex Abbrev Character Name
    15 NL New Line 85 NEL Next line
    0C FF Form Feed 0C FF Form Feed
    0D CR Carrier Return 0D CR Carriage Return
    25 LF Line Feed 0A LF Line Feed

    Control Character Mapping - SBCS ISO-8 to EBCDIC
    _ISO-8_ _EBCDIC_
    Hex Abbrev Character Name Hex Abbrev Character Name
    0A LF Line Feed 25 LF Line Feed
    0C FF Form Feed 0C FF Form Feed
    0D CR Carrier Return 0D CR Carriage Return
    85 NEL Next Line 15 NL New Line


    The following was the response to my inquiry:

    > The problem you are talking about has been around for as long as

    people have been moving data between EBCDIC and ASCII systems. The
    problem is that there are some control characters with similar
    characteristics - (line feed, new line, next line) - and depending on
    various software applications, they have been used interchangeably.

    > Here is a response to a note that we received about the very same

    thing way back in 1997:

    >> This is a frequent point of confusion and one that does not have any

    good resolution.

    >> The NLTC _official position_ is that line feed maps to line feed;

    i.e. 0A -> 25. Our default conversion tables all do that. However, the
    problem is in the EBCDIC to ISO-8 conversion. For ISO-8 code pages
    (like 819) we map EBCDIC 15 (new line) to ISO 85 (next line) which makes
    sense, except that some software does not know what to do with the C1
    controls (80-9F) and, of course, IBM PC code pages do not contain them
    at all. In the ASCII world the expectation is often that new line be
    indicated by 0A; strictly, the "line feed."

    >> The net of it is that we have some alternate tables, or people just

    make their own alternates swapping the 0A-25/85-15 maps. You still need
    some way to determine which one to use!


    With that, see also the following links for some more discussion of
    the C1 controls from ISO/IEC 6429 for which Next Line as source of the
    original confusion, is defined.

    http://en.wikipedia.org/wiki/C0_and_...trol_character
    http://en.wikipedia.org/wiki/ISO_8859-1
    http://unicode.org/reports/tr16/ "3.3" and "6.5"
    http://ra.dkuug.dk/CEN/TC304/guide/GTOP.HTM "control functions" and...
    http://ra.dkuug.dk/CEN/TC304/guide/GIS6429.HTM
    http://ra.dkuug.dk/CEN/TC304/guide/GCONCEPT.HTM#cnsets

    Regards, Chuck
    --
    All comments provided "as is" with no warranties of any kind
    whatsoever and may not represent positions, strategies, nor views of my
    employer

    CRPence wrote:
    > A quick search on the tokens CP00819 & EBCDIC yielded a table which
    > actually shows the EBCDIC 0x15 as being round trip with the ASCII 0x85.
    > That was the first table presented [at the following links], but it is
    > a /Tuxedo/ code page conversion with a "Note: The TUXEDO default ASCII
    > and EBCDIC code pages differ slightly from CP-00819 and CP-00037."
    > However, all of the other EBCDIC Latin-1 tables that are presented, seem
    > to suggest 0x15 -> 0x0A which is consistent with the stated expectation.
    > http://edocs.bea.com/elink/mainfram/...xug/codepg.htm
    > http://edocs.bea.com/tuxedo/tcp/v91/pdf/tuxug.pdf
    > http://e-generation.beasys.com/tuxed...1/pdf/user.pdf
    >
    > Then looking at my v5r4 system, I see the following prompted tables
    > show 0x15 -> 0x85 which is the stated outcome [which my inconv() test
    > showed as well], but that result is obviously in conflict with the
    > stated expectation:
    > CRTTBL TBL(QTEMP/X) SRCFILE(*PROMPT) BASETBL(QUSRSYS/QA6o697819)
    > That table defines the "CHRID(*N 1130) to CHRID(697 819) translate
    > table". Similarly, with the QA6q697819 table that defines the "CHRID(*N
    > 1132) to CHRID(697 819) translate table".
    >
    > I have asked of someone with a much deeper understanding of the
    > subject matter, why the 0x85 instead of 0x0A, in the noted iconv().
    >
    > Regards, Chuck


  8. Re: iconv() fails?

    il 17/11/2007 2.52, Scrive CRPence 40358128:
    > The answer is that the conversion is _both_ /working as expected/ and
    > /working unexpectedly/. Depending in which /camp/ one resides, their
    > way is correct and the other camp is incorrect. Apparently history has
    > this conundrum originating with the C language [with ASCII origins]
    > failing to have explicitly defined what the \n was in ASCII; e.g. did
    > that \n intend to represent a new line, a next line, or a line feed.?
    > Thus when the C language was developed for EBCDIC, the \n was open to
    > interpretation, versus having been explicitly documented. The choice
    > was /new line/ for EBCDIC [it is after all, an 'n'], for which the
    > best-fit was deemed to be the /next line/ character in ASCII -- again,
    > \n was not defined to be either of ASCII /next line/ or /line feed/.
    > Apparently many ASCII C compilers hard coded x'0A', and it was many
    > years later before anyone questioned the choice of /next line/ versus
    > /line feed/, long after there was already a large base of /next line/ code.
    >
    > Some resources that describe some code points:
    >
    > The code pages [ccsid] resources are aimed at the glyphs rather than
    > control characters, so the control characters [which would be duplicate
    > in all of the EBCDIC tables] are not included at the first link below,
    > but at the second and third links below:
    > http://www.ibm.com/servers/eserver/i...codepages.html
    >
    > http://www.ibm.com/servers/eserver/i...trolcodes.html
    >
    > http://www.ibm.com/software/globaliz...appendix_g.jsp
    >
    >
    > ** Following must be viewed in fixed-font; tables in two links above
    >
    > Control Character Mapping - SBCS EBCDIC to ISO-8
    > _EBCDIC_ _ISO-8_
    > Hex Abbrev Character Name Hex Abbrev Character Name
    > 15 NL New Line 85 NEL Next line
    > 0C FF Form Feed 0C FF Form Feed
    > 0D CR Carrier Return 0D CR Carriage Return
    > 25 LF Line Feed 0A LF Line Feed
    >
    > Control Character Mapping - SBCS ISO-8 to EBCDIC
    > _ISO-8_ _EBCDIC_
    > Hex Abbrev Character Name Hex Abbrev Character Name
    > 0A LF Line Feed 25 LF Line Feed
    > 0C FF Form Feed 0C FF Form Feed
    > 0D CR Carrier Return 0D CR Carriage Return
    > 85 NEL Next Line 15 NL New Line
    >

    >
    > The following was the response to my inquiry:
    >
    > > The problem you are talking about has been around for as long as

    > people have been moving data between EBCDIC and ASCII systems. The
    > problem is that there are some control characters with similar
    > characteristics - (line feed, new line, next line) - and depending on
    > various software applications, they have been used interchangeably.
    >
    > > Here is a response to a note that we received about the very same

    > thing way back in 1997:
    >
    > >> This is a frequent point of confusion and one that does not have any

    > good resolution.
    >
    > >> The NLTC _official position_ is that line feed maps to line feed;

    > i.e. 0A -> 25. Our default conversion tables all do that. However, the
    > problem is in the EBCDIC to ISO-8 conversion. For ISO-8 code pages
    > (like 819) we map EBCDIC 15 (new line) to ISO 85 (next line) which makes
    > sense, except that some software does not know what to do with the C1
    > controls (80-9F) and, of course, IBM PC code pages do not contain them
    > at all. In the ASCII world the expectation is often that new line be
    > indicated by 0A; strictly, the "line feed."
    >
    > >> The net of it is that we have some alternate tables, or people just

    > make their own alternates swapping the 0A-25/85-15 maps. You still need
    > some way to determine which one to use!
    >
    >
    > With that, see also the following links for some more discussion of
    > the C1 controls from ISO/IEC 6429 for which Next Line as source of the
    > original confusion, is defined.
    >
    > http://en.wikipedia.org/wiki/C0_and_...trol_character
    > http://en.wikipedia.org/wiki/ISO_8859-1
    > http://unicode.org/reports/tr16/ "3.3" and "6.5"
    > http://ra.dkuug.dk/CEN/TC304/guide/GTOP.HTM "control functions" and...
    > http://ra.dkuug.dk/CEN/TC304/guide/GIS6429.HTM
    > http://ra.dkuug.dk/CEN/TC304/guide/GCONCEPT.HTM#cnsets
    >
    > Regards, Chuck

    I understand that all this stuff is coming from the past, but this
    figure conflicts with the correct behavior I found in V4R4.
    Is V4R4 the wrong one? :-))
    Further more with iconv() you cannot specify a translation table, should
    I use a wrapped QDCXLATE with my own customized transtlation tables? It
    doesn't make sense, isn't it looking crazy?
    For now I just wrapped i conv adding the statement:
    if ((found = strstr(input, "\r\n")) != NULL)
    while (found = strstr(output, "\x0d\x85")) found[0] = '\x0a';

    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  9. Re: iconv() fails?

    il 17/11/2007 13.41, Scrive Dr.UgoGagliardelli 40445104:
    [...]
    > I use a wrapped QDCXLATE with my own customized transtlation tables? It
    > doesn't make sense, isn't it looking crazy?
    > For now I just wrapped i conv adding the statement:
    > if ((found = strstr(input, "\r\n")) != NULL)
    > while (found = strstr(output, "\x0d\x85")) found[0] = '\x0a';
    >

    Ops... should be
    if ((found = strstr(input, "\r\n")) != NULL)
    while (found = strstr(output, "\x0d\x85")) found[1] = '\x0a';


    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  10. Re: iconv() fails?

    il 17/11/2007 2.52, Scrive CRPence 40445104:
    [...]

    > The following was the response to my inquiry:
    >
    > > The problem you are talking about has been around for as long as

    > people have been moving data between EBCDIC and ASCII systems. The
    > problem is that there are some control characters with similar
    > characteristics - (line feed, new line, next line) - and depending on
    > various software applications, they have been used interchangeably.
    >
    > > Here is a response to a note that we received about the very same

    > thing way back in 1997:
    >
    > >> This is a frequent point of confusion and one that does not have any

    > good resolution.
    >
    > >> The NLTC _official position_ is that line feed maps to line feed;

    > i.e. 0A -> 25. Our default conversion tables all do that. However, the
    > problem is in the EBCDIC to ISO-8 conversion. For ISO-8 code pages
    > (like 819) we map EBCDIC 15 (new line) to ISO 85 (next line) which makes
    > sense, except that some software does not know what to do with the C1
    > controls (80-9F) and, of course, IBM PC code pages do not contain them
    > at all. In the ASCII world the expectation is often that new line be
    > indicated by 0A; strictly, the "line feed."

    OK, but I stated that iconv() fails to translate 0x25 (not 0x15) that
    should be mapped to 0x0a accordingly to both
    http://www-306.ibm.com/software/glob...appendix_g.jsp
    and
    http://www-03.ibm.com/servers/eserve...trolcodes.html

    BTW I've just looked at them, for that my wondering has been that
    iconv() and QTQCVRT are failing from at least V5R2 on, previous version
    V4R4 I tested, succesfully translates 0x25 into 0x0a as expected and
    accordingly to IBM nls statements.

    >
    > >> The net of it is that we have some alternate tables, or people just

    > make their own alternates swapping the 0A-25/85-15 maps. You still need
    > some way to determine which one to use!

    Both iconv() and QTQCVRT do let you specify the CCSIDs from and to the
    translation should take place, how can I determine the right translation?

    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  11. Re: iconv() fails?

    I agree with the expected outcome given an EBCDIC CCSID and code
    point 0x25 as input; i.e. that the 0x0A ASCII code point would be the
    expected conversion. That is because....

    AFaIK the EBCDIC Line Feed is always the code point 0x25, and thus
    should always convert/translate to the ASCII 0x0A Line Feed. As I had
    originally stated [and thus I was responding with] the assumption that
    the 0x85 being seen, was a side effect of the code point 0x15 being
    passed to iconv() *instead* of the noted 0x25; regardless of how that
    might have happened. Whereas I suggested that the 0x15 versus 0x25 was
    perhaps by some error having the data "changed from the expected input",
    Walt proposed the more likely origin for the code point 0x15 versus the
    0x25, being the C generated literal for \n -- a value established
    according to a compile option *NOIFSIO. My tests of just iconv() [i.e.
    no use of the \n as C generated literal] on v5r4 shows passing x'25'
    converts consistently to x'0A' using [every test I tried of a Latin-1]
    EBCDIC CCSID to CCSID(819).

    Thus if there is an unexpected case of an EBCDIC CCSID from which the
    code point 0x25 translates to the ASCII code point 0x85, I would suggest
    opening a problem with your service provider. If I had not so easily
    [and apparently incorrectly] concluded that the \n as valid 0x15 being
    the origin of the problem, that would have been my first suggestion.

    Regards, Chuck
    --
    All comments provided "as is" with no warranties of any kind
    whatsoever and may not represent positions, strategies, nor views of my
    employer

    Dr.UgoGagliardelli wrote:
    > il 17/11/2007 2.52, Scrive CRPence 40445104:
    > <>
    > OK, but I stated that iconv() fails to translate 0x25 (not 0x15)
    > that should be mapped to 0x0a accordingly to both
    > http://www-306.ibm.com/software/glob...appendix_g.jsp
    > and
    > http://www-03.ibm.com/servers/eserve...trolcodes.html
    >
    >
    > BTW I've just looked at them, for that my wondering has been that
    > iconv() and QTQCVRT are failing from at least V5R2 on, previous version
    > V4R4 I tested, successfully translates 0x25 into 0x0a as expected and
    > accordingly to IBM nls statements.
    >
    >>
    >> >> The net of it is that we have some alternate tables, or people

    >> just make their own alternates swapping the 0A-25/85-15 maps. You
    >> still need some way to determine which one to use!

    >
    > Both iconv() and QTQCVRT do let you specify the CCSIDs from and to the
    > translation should take place, how can I determine the right translation?


  12. Re: iconv() fails?

    il 19/11/2007 15.47, Scrive CRPence 40390056:
    > I agree with the expected outcome given an EBCDIC CCSID and code point
    > 0x25 as input; i.e. that the 0x0A ASCII code point would be the expected
    > conversion. That is because....
    >
    > AFaIK the EBCDIC Line Feed is always the code point 0x25, and thus
    > should always convert/translate to the ASCII 0x0A Line Feed. As I had
    > originally stated [and thus I was responding with] the assumption that
    > the 0x85 being seen, was a side effect of the code point 0x15 being
    > passed to iconv() *instead* of the noted 0x25; regardless of how that
    > might have happened. Whereas I suggested that the 0x15 versus 0x25 was
    > perhaps by some error having the data "changed from the expected input",
    > Walt proposed the more likely origin for the code point 0x15 versus the
    > 0x25, being the C generated literal for \n -- a value established
    > according to a compile option *NOIFSIO. My tests of just iconv() [i.e.
    > no use of the \n as C generated literal] on v5r4 shows passing x'25'
    > converts consistently to x'0A' using [every test I tried of a Latin-1]
    > EBCDIC CCSID to CCSID(819).
    >
    > Thus if there is an unexpected case of an EBCDIC CCSID from which the
    > code point 0x25 translates to the ASCII code point 0x85, I would suggest
    > opening a problem with your service provider. If I had not so easily
    > [and apparently incorrectly] concluded that the \n as valid 0x15 being
    > the origin of the problem, that would have been my first suggestion.
    >
    > Regards, Chuck

    So the short answer is: yes, it fails!
    :-))
    I'll open a service call, thank you very mucch.


    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

+ Reply to Thread