× 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.



To correct that problem generally, for the user profile, instead of either for all user profiles using CCSID(*SYSVAL) or only for the current job: While signed on interactively, issue the request CHGPRF CCSID(37) to modify your user to designate a CCSID for all of its jobs; using the CCSID value appropriate to the chosen LANGID or whatever environment considerations, rather than assuming 37 is appropriate. FWiW I have always considered the noted result of the SELECT to be a defect, for the failure of the SQL request to honor the "default job CCSID", a feature which was supposed to resolve just such issues. Note: When the job CCSID is *HEX [or 65535], the value for the "Default coded character set identifier" as displayed by WRKJOB OPTION(*DFNA) will reflect the default CCSID for the "Language identifier" shown above the CCSID.

Although most in the USA will be unaffected by a change to the system value, and already there are replies boasting about there being no harm for those who did make global changes, do not be fooled into believing nothing negative can come from changing the value for the job, user, or system. What negative can happen is generally both very subtle and not simple to correct; i.e. object changes, data changes, and perhaps only for activity since the change... such that for the data, some records may have to be changed but not others, and it may not even be obvious which is which when either of two code points may be valid in the string. That said, it is probably better to make the change from 65536 than to not change, since even if there are negative outcomes, what was happening before the change was probably incorrect and what would be perceived as negative after the change is probably correct; just that the correct behavior is no longer consistent and thus requires actions to fix any programming & procedural errors.

Regards, Chuck

Mike wrote:
I'll try this. I fear changing system values without knowing
the repercussions. But the system id is 65535.

Jack Kingsley wrote:

will changing your job ccsid fix it. chgjob ccsid(37)

Mike wrote:

I am creating some file dumps from our iSeries for download
to the PC.
Currently, to save time (and out of laziness) I am just
having STRSQL create the file for me. The problem I am having
is that some of the fields where I am adding my own string
value (SELECT myfield, 'myaddedstring' FROM mytable), it
puts the CCSID to 65535 instead of 37. This seems to be
causing the PC to download the hex values in the fields
vs. the actual text.
Is there a way to force these values to CCSID 37?

I discovered this after generating a SQL version of the file
in iSeries Navigator.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.