×
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.
Barbara,
I'm still puzzled. Even more than before :-)
- The manual says: 'When CCSID(*CHAR : *JOBRUN) is not specified,
character data will be assumed to be in the mixed-byte CCSID related to
the job CCSID.'
- In my test program I did not specify CCSID(*CHAR:*JOBRUN); that would
imply that the character data was assumed to be in the mixed-byte CCSID
related to the job CCSID.
- When I ran my test program in a job with CCSID 37, the Unicode
characters were converted to the equivalent characters in CCSID 37. In a
job with CCSID 500 they were converted to 500.
Intuitively I expected conversion to job CCSID, and that is what I
found, but it is not what the manual says. According to the manual I
should have used CCSID(*CHAR:*JOBRUN) to get the results I got, but I
did not specify it.
And I still don't know what the mixed-byte CCSID's are that are related
to 37 and 500.
Joep Beckeringh
Barbara Morris schreef:
Joep, if you code CCSID(*CHAR:*JOBRUN) in your H spec, then RPG will
assume that character data is in the job CCSID. RPG will only assume a
mixed-byte CCSID if the job CCSID is already a mixed-byte CCSID.
As an Amazon Associate we earn from qualifying purchases.
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.