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