|
The following is from the READMESP.TXT file that comes with Client Access service packs. What you're describing happened to us until I followed these instructions. Guy Murphy University of Illinois - UDIS 217-333-8670 murphyfa@uiuc.edu 2.6.1 TRANSFERRING DATA WHEN THE FILE CCSID IS 65535 ----------------------------------------------------- The Data Transfer function will not translate data between ASCII and EBCDIC, if the CCSID of the file on the AS/400 is 65535. Uploads to the AS/400 file will generate message "CWBTF0005 - Data in this field is incorrect or does not match PC data type." Downloads to the PC will complete successfully, but the data will not be converted, appearing as hexidecimal data instead of the correct character data. Data Transfer will now allow conversion from CCSID 65535 to the PC CCSID on transfers to the PC. The AS/400 job CCSID will be used for the conversion. Data Transfer will also convert from the PC CCSID to the AS/400 job CCSID for transfers to the AS/400 when fields are tagged with the 65535 CCSID. This conversion is controlled by creating an INI file named CWBTFR.INI in your Windows install directory (which is usually C:\WINDOWS). For your convenience, we have shipped a sample CWBTFR.INI file in the Client Access install directory (which by default is C:\Program Files\IBM\Client Access). We also included a CWBTFR.TXT file, which explains the different fields. To use CWBTFR.INI, copy it to your Windows install directory and change it to reflect the options you wish to use. The CWBTFR.INI file must contain ONE of following lines: ForceTranslation=0; for no translation of 65535 data OR ForceTranslation=1; for translation of 65535 data If the CWBTFR.INI file is not found, or the correct section and value names are not present in the CWBTFR.INI file, Data Transfer will default to not translate 65535 data. WARNING: Enable this fix only if you are confident the data contained within columns tagged with the 65535 CCSID are in a defined CCSID that matches the user profile CCSID of the jobs that will access it. Accessing 65535 CCSID data from a job CCSID that does not match the data may corrupt data within the database file. If you don't enable this fix by providing a CWBTFR.INI file, transfers will continue to behave as they did before. Columns tagged with the 65535 CCSID are designed to not be converted when transferring to/from the PC. Using this fix, which forces a conversion to take place, is to be done only when it is not possible to change the column or file CCSID from 65535. Every attempt should be made to appropriately tag the data with the correct CCSID. For more information on the 65535 CSID, see topic 2.2.3.2 in the AS/400 National Language Support book, SC41-1301-00. Conversions from CCSID 65535 fields are prone to errors under multi-language situations where AS/400 user job CCSIDs do not match. ______________________________ Reply Separator _________________________________ Subject: CA downloads Author: <MIDRANGE-L@midrange.com > at INTERNET Date: 10/17/97 6:55 AM Hi All, I have recently upgraded my emulation software to Client Access (windows 95), from the NetSoft Elite/400 product. I am trying to download a file from the AS/400 that I created using query. In this file I have a character result field that was created by concatenating 2 numeric fields using the "digits" function of query. This field is indeed a "CHAR" field on the AS/400 file that query creates. When downloading, however, Client Access views this field as type "HEX", and brings down each byte in it's hex notation (i.e., "1" comes down as "F1"). NetSoft Elite/400 on the other hand views this field as the "CHAR" field that it is, downloading it properly. Has anyone come across this situation? Is there a workaround or PTF available? TIA Regards, Tom McCollem +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "MIDRANGE-L@midrange.com". | To unsubscribe from this list send email to MAJORDOMO@midrange.com | and specify 'unsubscribe MIDRANGE-L' in the body of your message. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.