× 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 Saturday, February 14, 2004, at 03:54 AM, M. Lazarus wrote:


I don't think that we have to go as esoteric as PASE. Doesn't Client Access File Transfer default to 66535? What if I was to use the create file option and forget to change the CCSID on the xfer and the default system ID was 437? Would there be mass confusion when native pgms tried to use that file?

Client Access does not default to 65535. It uses QCCSID (eventually) but since almost no-one sets QCCSID properly the file transfer ends up using 65535 which results in EBCDIC data at the PC. You can always tell this because EBCDIC data displayed on a PC using an ASCII editor will show a lot of commercial-at signs (@). These generally have ASCII code-point x'40' which in EBCDIC is the space. Therefore EBCDIC spaces show as ASCII @ signs.


The Convert CCSID 65535 flag in Client Access is a kludge to compensate for customer systems not being set correctly (and also because few customers understand the complexities of character encoding and can't fathom why the data downloaded to the PC looks like crap so they blame the transfer and not their wrong environment).

I said it was not possible to have a job using an ASCII CCSID (except in PASE or possibly by using 65535 but processing data as if it were ASCII). You cannot set QCCSID or a job CCSID to 437 (or any non-EBCDIC value). Therefore the only way to get data incorrectly interpreted is by doing something wrong. You can send ASCII data to the host and have ASCII data interpreted as EBCDIC if the host uses 65535 and you neglect to use the Client Access kludge. There are other ways too.

In this case the file would have ASCII data that was interpreted as EBCDIC. It is certainly possible to have files using any valid CCSID. If files are being transferred between systems that use different encoding methods and that encoded data is stored in a file which says the data is something else such as 37 when it's is 437 or 65535 when it is not raw data then YES you will have a learning experience (except most won't of course--they'll just blame the system and not their own ignorance).

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

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.