Re: Looking for best option

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Charles Wilt wrote:
> Shouldn't the CCSID be 65535 since it's binary data?
> 

Yes, it probably should.

Unfortunately, waaaaay too many programs try to translate data *even if* 
65535 is specified. (By popular demand!) Plus, there's a ton of software 
(such as *anything* that runs in PASE, anything uploaded via FTP, etc) 
that doesn't set files to 65535.

So, in short, even though 65535 means *HEX, don't translate, it's not 
the way CCSIDs are typically used with IFS files.  I don't know why? 
Marking it with 65535 wouldn't be a bad idea, though.


> Since it wasn't, could that cause a translation issue that seemed to
> by solved by the change from 819 to 37?

My suspicion is that Bruce is mistaken, and that it was something else 
(not the change from 819 to 37) that made the difference.  He was 
previously doing things like %TRIM, and calculating the length with 
%LEN, and using VARYING strings not set to max length as output from 
base64_decode, and even calling http_xlate() on his binary data... all 
of which are much more likely to have caused this type of problem.


> I'm thinking perhaps the OS was trying to translate the data as if it
> _was_ text.  When he set the CCISD to 37 the OS decided no translation
> was needed, so everything worked.

I understand why you say that.  But, in my experience, software for the 
IFS doesn't work that way.  IFS software specifies the O_TEXTDATA flag 
on the open() API or the "b" (for binary) flag on the fopen() API to 
tell it whether the data is to be treated as binary or text.  A program 
that's written to work with binary data would open the file in binary 
mode and it wouldn't make any difference what the CCSID is.

A program intended to work with a stream file as text would corrupt an 
image, even without ASCII/EBCDIC conversion, since it'd be looking for 
CRLF characters in the data.

In this case, the file is supposed to be served by Apache.  Apache would 
determine whether to treat the file as binary or text based on it's 
extension.  .tif *should* be considered binary, not text!   Remember, 
Apache needs to send a MIME type to the browser.  It has to tell the 
browser "content-type: image/tiff"  it can't know that purely based on 
the CCSID -- it has to have another way.  It looks at the extension of 
.tif.  If that part isn't working, you can specify it via the AddType 
config keyword in Apache.

Anyway, if Apache knows the file is binary, it won't attempt translation 
regardless of the CCSID marked on the file.

None of the images on my system are marked as 65535, yet they work 
correctly via Apache.

Likewise, FTP determines whether to do translations based on whether you 
are in binary mode.  It opens the file in text mode if you don't specify 
"binary".

SCP and SFTP always opens files in binary mode, and never in text mode.

NetServer (Windows Networking) has a configuration option that lets you 
configure each share as one that will translate CCSIDs or not.  By 
default it's set to never translate.

Samba always uses binary mode.

I don't know about ops nav, though?

Short of FTPing the file in ASCII mode or using Netserver and enabling 
CCSID translation (both of which I'd consider "user error"), I fail to 
see why the CCSID on the file would matter.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------