×
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.
On 03 May 2012 10:13, Scott Klement wrote:
On 5/3/2012 12:00 PM, Cyndi Bradberry wrote:
The system CCSID is set to 65535, LangID=ENU. I have tried to
change the PF to CCSID = 037. I have recompiled the file, using a
new source file that has a CCSID = 037.
I don't understand this part. Why does it matter what the CCSID of
the SRCFILE is? Surely, your goal should be to set the CCSID of the
char/varchar columns... right?
For data retrieval, indeed that CCSID is moot. However, FWiW:
The CCSID of the source establishes the CCSID of the "text" fields
that define the record format; i.e. kwds COLHDG, TEXT, EDTWRD, COMP, et al.
Note: The CHGPF CCSID(nbr) [which was designed only to effect setting
the CCSID for database files from pre-v2r1m1 which were set incorrectly
by automatic conversions] will blindly set the CCSID of all the /text/
fields in the file [member, file, record format] to the specified nbr;
i.e. irrespective of the actual data. So just as with changing the
column CCSIDs without regard to the data [potentially bad], there is a
similar potential problem with the data that is the text; i.e. the
actual data may not match the new CCSID that is assigned.
Regards, Chuck
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.