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



Thanks for the reply.

Comments below...
On 1 Aug 2010 at 12:39, Simon (Simon Coulter <midrange-l@xxxxxxxxxxxx>) commented
about Re: Client Access file transfer error:


On 01/08/2010, at 11:09 AM, Gary Kuznitz wrote:

I'm using a viewer on the PC (part of salamander) looking at the
file on the 400. It
shows that it's EBCDIC on the top heading line.

If I use Ultra Edit the file looks like garbage.

Sounds like salamander viewer is guessing (based on data content) that
the file is EBCDIC and converts to ASCII so it displays legibly on the
PC.

That sounds correct.

Sounds like UltrEdit is treating the file as ASCII thus looks like
garbage. If the file has lots of @ signs then it's likely really
EBCDIC data. Blank in EBCDIC is X'40' which shows in an ASCII viewer
as @.

That's my guess also.

Using Wrklnk, display attributes on the file it shows the Code page
is 37.

Then the data is likely EBCDIC. See if option 2 or 5 in WRKLNK renders
it correctly or whether it sends a "guessed encoding" message.

I tried option 2 even though that option isn't listed and it deleted the file. Option 5 is
Next Level. I'm guessing these options are different on a later version of the OS.


Even though the code page is correct I think it's still in EBCDIC.

Unclear again. I presume you mean that the code page/CCSID on the host
is 37 therefore correct for EBCDIC data but that the data is received
at the client unconverted when you expect it to be in ASCII.

That's correct. I'd like it to be ASCII so DAZzle can read it.


I'm surprised that Client Access doen't convert it to ASCII
automatically.


It does unless CCSID 65535 is in play. However, you're not using
Client Access. In your original append you wrote:

I found hundreds of messages relating to QZLSFILE which handles the
Client Access file transfers.


That's an incorrect statement. I'm fairly sure QZLSFILE doesn't handle
CA file transfers. It handles NetServer file transfers. So are you
accessing the host XML data via:

o CA file transfer
or
o Mapped network drives
or
o NetServer shares

I think you are correct. I don't know why I was thinking it was CA file transfer.

So the problem is how to get NetServer to translate into ASCII.

Thank you very much for pointing that out.

Gary

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

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
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.