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