In a recent note, McKown, John said:
> Date: Thu, 12 May 2005 14:59:10 -0500
>
> Basically, ftp does not normally have any indication for "end of record"
> in a binary transfer. It views the data as a stream of bytes (Like PL/I
> STREAM files). However, if you specify STRU R, then ftp will do a
> special "encoding" so that the end of a record can be detected. IIRC, an
> "end of record" is encoded as 0xFF01. If the data contains a 0xFF, it is
> expanded to a 0xFFFF. There may be some other things.
>
> Read all about it at:
>
> http://www.ietf.org/rfc/rfc0959.txt?number=959
>
RFC 959, eh? YLSED!
Therein, I see nothing about 0xFF01. Perhaps an IBM idiosyncrasy.
But:
File-structure is the default to be assumed if the STRUcture
command has not been used but both file and record structures
must be accepted for "text" files (i.e., files with TYPE ASCII
or EBCDIC) by all FTP implementations.
However:
quote syst
>>> syst
215 UNIX Type: L8 Version: SUNOS
Command:
quote stru r
>>> stru r
504 Unimplemented STRU type.
Oops!
However, as you suggested earlier, from the SUNOS client to the
z/OS server, one can do:
BINARY
QUOTE STRU R
and fool SUNOS. But is there any way of accomplishing the equivalent
with z/OS client and SUNOS server? I fear not. And, when z/OS
receives the 504 error from SUNOS, does it suppress the local effect
of STRU R? I fear so. I'd like to test this with the LOCSTAT
command, but much of the output scrolls away. Is there any way
to redirect the output of LOCSTAT to a file for browsing later?
Thanks,
gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
