RMTCMD character conversion
tomasz
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
CRPence
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/eserver/iseries/software/globalization/pdf/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/eserver/iseries/software/globalization/pdf/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/eserver/iseries/software/globalization/pdf/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.
tomasz
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:
CRPence
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
> 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
CRPence
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.
tomasz
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: