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.

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

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.

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.

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

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 / \
--------------------------------------------------------------------