Re: CA downloads

What really gets confusing when you create a file with query is that you may
find some fields have a CCSID of 65535 and some don't.  Check the created
file with DSPFFD and check the individual fields.  The entire file does
not necessarily have to be all one CCSID.  DSPFD will tell you if you need
to use DSPFFD to check for fields that have different CCSID's.


On Fri, 17 Oct 1997, Guy Murphy wrote:

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