• Subject: Re: CA downloads
  • From: "Guy Murphy"<gmurphy@xxxxxxxxxxxx>
  • Date: Fri, 17 Oct 97 08:12:32 -0600


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


This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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 here. If you have questions about this, please contact [javascript protected email address].