RMTCMD character conversion - IBM AS400

This is a discussion on RMTCMD character conversion - IBM AS400 ; Hi. We're using iSeriesAccess for Linux software. I have a problem with character conversion. Bassicly when I run my program from 5250 session it executes and 'do something' - insert some data into table. When I run the same CALL... ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: RMTCMD character conversion

  1. RMTCMD character conversion

    Hi.

    We're using iSeriesAccess for Linux software.
    I have a problem with character conversion.
    Bassicly when I run my program from 5250 session it executes and 'do
    something' - insert some data into table.

    When I run the same CALL... via RMTCMD program executes and do the same
    thing but in target table are for example instead of '^' things like
    this ''.

    Can anybody explain where is the problem ?
    Tables CCSID is 870.

    Tomasz

  2. Re: RMTCMD character conversion

    What character appears is often moot. It depends on the interface
    used to display the data. Review the code point [i.e. the hex value] of
    the character instead, using an interface that is /CCSID agnostic/; e.g.
    DSPPFM /* F10 then optionally F11 */.

    If the program that was called simply takes any string and deposits
    that string into a field [tagged] with CCSID(870), irrespective of the
    job CCSID, then the program would need to be corrected to translate the
    data from the job CCSID into CCSID(870) before insert; such is the case
    when the file is opened for example, as program described.

    An example with all of the language and code point details might be
    the best to provide comment, but perhaps just the above, plus the below
    reference material will assist.

    The remote command server apparently uses the /associated CCSID/ from
    the PC language settings rather than the user profile CCSID to establish
    the job CCSID setting for converting incoming strings. Review the CCSID
    setting for the QZRCSRVS job which services the request.

    APAR= SA54195 Some text follows:

    The optimized remote command/distributed program call server uses the PC
    CCSID to find the associated CCSID, then changes the job CCSID to the
    associated CCSID. However, the job CCSID may be compatible with the PC
    CCSID. In this case, the job CCSID should be used rather than the
    associated CCSID.

    The optimized remote command/distributed program call server will be
    updated to compare the character sets of the job CCSID and the
    associated CCSID. If the character sets are the same, the job CCSID is
    compatible, and the CCSID will not be changed. Otherwise, the job will
    be changed to use the associated CCSID.


    CCSID(870)
    http://www-03.ibm.com/servers/eserve...f/cp00870z.pdf
    Char Hex CharName Description
    ˙ B0 SD290000 Overdot accent
    ^ 5F SD150000 caret [or Circumflex Accent]
    ¬ *NA SM660000 logical not symbol
    *NA for hex signifies the character is not in this table

    CCSID(037)
    http://www-03.ibm.com/servers/eserve...f/cp00037z.pdf
    Char Hex CharName Description
    ^ B0 SD150000 caret [or Circumflex Accent]
    ¬ 5F SM660000 logical not symbol
    · B3 SD630000 Middle dot

    CCSID(850) /* PC */
    http://www-03.ibm.com/servers/eserve...f/cp00850z.pdf
    Char Hex CharName Description
    ¬ AA SM660000 logical not symbol
    ^ 5E SD150000 caret [or Circumflex Accent]
    · FA SD630000 Middle dot
    * I could not find the character inferred\noted as /Overdot accent/

    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

    tomasz wrote:
    > We're using iSeriesAccess for Linux software.
    > I have a problem with character conversion.
    > Basically when I run my program from 5250 session it executes and
    > 'do something' - insert some data into table.
    >
    > When I run the same CALL... via RMTCMD program executes and do the same
    > thing but in target table are for example instead of '^' things like
    > this '˙'.
    >
    > Can anybody explain where is the problem ?
    > Table CCSID is 870.


  3. Re: RMTCMD character conversion

    Thank you very much.
    I've checked and in fact data in file was inserted in ccsid 037.
    I've also checked that QZRCSRVS jobs are in ccsid 037 not 870.

    So i've modified a program I run via RMTCMD to change job ccsid to 870
    and now everything is fine.

    Regards,
    Tomasz



    CRPence pisze:
    > What character appears is often moot. It depends on the interface
    > used to display the data. Review the code point [i.e. the hex value] of
    > the character instead, using an interface that is /CCSID agnostic/; e.g.
    > DSPPFM /* F10 then optionally F11 */.
    >
    > If the program that was called simply takes any string and deposits
    > that string into a field [tagged] with CCSID(870), irrespective of the
    > job CCSID, then the program would need to be corrected to translate the
    > data from the job CCSID into CCSID(870) before insert; such is the case
    > when the file is opened for example, as program described.
    >
    > An example with all of the language and code point details might be
    > the best to provide comment, but perhaps just the above, plus the below
    > reference material will assist.
    >
    > The remote command server apparently uses the /associated CCSID/ from
    > the PC language settings rather than the user profile CCSID to establish
    > the job CCSID setting for converting incoming strings. Review the CCSID
    > setting for the QZRCSRVS job which services the request.
    >
    > APAR= SA54195 Some text follows:
    >
    > The optimized remote command/distributed program call server uses the PC
    > CCSID to find the associated CCSID, then changes the job CCSID to the
    > associated CCSID. However, the job CCSID may be compatible with the PC
    > CCSID. In this case, the job CCSID should be used rather than the
    > associated CCSID.
    >
    > The optimized remote command/distributed program call server will be
    > updated to compare the character sets of the job CCSID and the
    > associated CCSID. If the character sets are the same, the job CCSID is
    > compatible, and the CCSID will not be changed. Otherwise, the job will
    > be changed to use the associated CCSID.
    >
    >
    > CCSID(870)
    > http://www-03.ibm.com/servers/eserve...f/cp00870z.pdf
    >
    > Char Hex CharName Description
    > ˙ B0 SD290000 Overdot accent
    > ^ 5F SD150000 caret [or Circumflex Accent]
    > ¬ *NA SM660000 logical not symbol
    > *NA for hex signifies the character is not in this table
    >
    > CCSID(037)
    > http://www-03.ibm.com/servers/eserve...f/cp00037z.pdf
    >
    > Char Hex CharName Description
    > ^ B0 SD150000 caret [or Circumflex Accent]
    > ¬ 5F SM660000 logical not symbol
    > · B3 SD630000 Middle dot
    >
    > CCSID(850) /* PC */
    > http://www-03.ibm.com/servers/eserve...f/cp00850z.pdf
    >
    > Char Hex CharName Description
    > ¬ AA SM660000 logical not symbol
    > ^ 5E SD150000 caret [or Circumflex Accent]
    > · FA SD630000 Middle dot
    > * I could not find the character inferred\noted as /Overdot accent/
    >
    > Regards, Chuck


  4. Re: RMTCMD character conversion

    From what was described as the values seen [before the change], I
    would have expected that a typical insert would have yielded the
    expected results; i.e. such that no change should have been required.
    Does that mean the insert is being done purposely without conversion?

    By default, you should expect to be able to insert the CCSID(037)
    data into the CCSID(870) field; i.e. unless the insert is done without
    conversion. By default, the database will translate the data on input,
    from the job CCSID. Given the original ASCII code point was 0x5E, and
    that value was converted to 0xB0 in EBCDIC CCSID(037) due to either the
    target *JOB CCSID(037), and given the insert was standard from the *JOB
    CCSID(037) into a *FILE CCSID(870), then the final code point in the
    field data with CCSID(870) should have been 0x5F [as viewed by DSPPFM;
    again, ignoring what glyph, reviewing only the code point hex value]

    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

    tomasz wrote:
    > Thank you very much.
    > I've checked and in fact data in file was inserted in ccsid 037.
    > I've also checked that QZRCSRVS jobs are in ccsid 037 not 870.
    >
    > So i've modified a program I run via RMTCMD to change job ccsid to 870
    > and now everything is fine.
    >
    > Regards, Tomasz
    >
    > CRPence pisze:
    >> What character appears is often moot. It depends on the interface
    >> used to display the data. Review the code point [i.e. the hex value]
    >> of the character instead, using an interface that is /CCSID agnostic/;
    >> e.g. DSPPFM /* F10 then optionally F11 */.
    >>
    >> If the program that was called simply takes any string and deposits
    >> that string into a field [tagged] with CCSID(870), irrespective of the
    >> job CCSID, then the program would need to be corrected to translate
    >> the data from the job CCSID into CCSID(870) before insert; such is the
    >> case when the file is opened for example, as program described.
    >>
    >> An example with all of the language and code point details might be
    >> the best to provide comment, but perhaps just the above, plus the
    >> below reference material will assist.
    >>
    >> The remote command server apparently uses the /associated CCSID/
    >> from the PC language settings rather than the user profile CCSID to
    >> establish the job CCSID setting for converting incoming strings.
    >> Review the CCSID setting for the QZRCSRVS job which services the request.
    >>
    >> APAR= SA54195 Some text follows:
    >>
    >> The optimized remote command/distributed program call server uses the
    >> PC CCSID to find the associated CCSID, then changes the job CCSID to
    >> the associated CCSID. However, the job CCSID may be compatible with
    >> the PC CCSID. In this case, the job CCSID should be used rather than
    >> the associated CCSID.
    >>
    >> The optimized remote command/distributed program call server will be
    >> updated to compare the character sets of the job CCSID and the
    >> associated CCSID. If the character sets are the same, the job CCSID
    >> is compatible, and the CCSID will not be changed. Otherwise, the job
    >> will be changed to use the associated CCSID.
    >>
    >>
    >> CCSID(870)
    >> http://www-03.ibm.com/servers/eserve...f/cp00870z.pdf
    >>
    >> Char Hex CharName Description
    >> ˙ B0 SD290000 Overdot accent
    >> ^ 5F SD150000 caret [or Circumflex Accent]
    >> ¬ *NA SM660000 logical not symbol
    >> *NA for hex signifies the character is not in this table
    >>
    >> CCSID(037)
    >> http://www-03.ibm.com/servers/eserve...f/cp00037z.pdf
    >>
    >> Char Hex CharName Description
    >> ^ B0 SD150000 caret [or Circumflex Accent]
    >> ¬ 5F SM660000 logical not symbol
    >> · B3 SD630000 Middle dot
    >>
    >> CCSID(850) /* PC */
    >> http://www-03.ibm.com/servers/eserve...f/cp00850z.pdf
    >>
    >> Char Hex CharName Description
    >> ¬ AA SM660000 logical not symbol
    >> ^ 5E SD150000 caret [or Circumflex Accent]
    >> · FA SD630000 Middle dot
    >> * I could not find the character inferred\noted as /Overdot accent/
    >>


  5. Re: RMTCMD character conversion

    CRPence pisze:
    > From what was described as the values seen [before the change], I
    > would have expected that a typical insert would have yielded the
    > expected results; i.e. such that no change should have been required.
    > Does that mean the insert is being done purposely without conversion?
    >
    > By default, you should expect to be able to insert the CCSID(037) data
    > into the CCSID(870) field; i.e. unless the insert is done without
    > conversion. By default, the database will translate the data on input,
    > from the job CCSID. Given the original ASCII code point was 0x5E, and
    > that value was converted to 0xB0 in EBCDIC CCSID(037) due to either the
    > target *JOB CCSID(037), and given the insert was standard from the *JOB
    > CCSID(037) into a *FILE CCSID(870), then the final code point in the
    > field data with CCSID(870) should have been 0x5F [as viewed by DSPPFM;
    > again, ignoring what glyph, reviewing only the code point hex value]
    >
    > Regards, Chuck



    What I've seen was that job QZRCSRVS was running with CCSID 037.
    While my RMTCMD run a program which performed insert operation
    the chracters were inserted with ccsid 037 not 870.
    I didn't make any chars conversion, I only needed to change job QZRCSRVS
    ccsid to 870.

    Tomasz

  6. Re: RMTCMD character conversion

    I am concerned the action taken, changing the CCSID of the job, may
    only be a circumvention. Unless the insert activity is being performed
    with CCSID(*HEX), by effectively overriding the database to ignore the
    job CCSID(037), the CCSID(037) data should be converted automatically by
    the database upon insert into the CCSID(870) field.

    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

    tomasz wrote:
    > CRPence pisze:
    >> From what was described as the values seen [before the change], I
    >> would have expected that a typical insert would have yielded the
    >> expected results; i.e. such that no change should have been required.
    >> Does that mean the insert is being done purposely without conversion?
    >>
    >> By default, you should expect to be able to insert the CCSID(037)
    >> data into the CCSID(870) field; i.e. unless the insert is done without
    >> conversion. By default, the database will translate the data on
    >> input, from the job CCSID. Given the original ASCII code point was
    >> 0x5E, and that value was converted to 0xB0 in EBCDIC CCSID(037) due to
    >> either the target *JOB CCSID(037), and given the insert was standard
    >> from the *JOB CCSID(037) into a *FILE CCSID(870), then the final code
    >> point in the field data with CCSID(870) should have been 0x5F [as
    >> viewed by DSPPFM; again, ignoring what glyph, reviewing only the code
    >> point hex value]
    >>
    >> Regards, Chuck

    >
    >
    > What I've seen was that job QZRCSRVS was running with CCSID 037.
    > While my RMTCMD run a program which performed insert operation
    > the characters were inserted with ccsid 037 not 870.
    > I didn't make any chars conversion, I only needed to change job
    > QZRCSRVS ccsid to 870.
    >
    > Tomasz


  7. Re: RMTCMD character conversion

    Hi.

    Unfortunatelly it is not converted.
    When job is running with 037 and run my program which executes R400
    procedure which takes data from several of tables ( with ccsid 870) and
    then inserts data into other table (with 870) the data is corrupted.
    While I put into my program at the begining CHGJOB... everything works
    fine.
    I can't find out what is wrong but if it works now it's fine for me.
    Since I remember my colegues always had problems with characters
    conversions between their applications and iseries environment.

    Many thanks for lot of valuable informations.

    Tomasz


    CRPence pisze:
    > I am concerned the action taken, changing the CCSID of the job, may
    > only be a circumvention. Unless the insert activity is being performed
    > with CCSID(*HEX), by effectively overriding the database to ignore the
    > job CCSID(037), the CCSID(037) data should be converted automatically by
    > the database upon insert into the CCSID(870) field.
    >
    > Regards, Chuck




+ Reply to Thread