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