[Info-vax] RMS internals?

[Allen, Daniel P.]

-----Original Message-----
From: info-vax-bounces at rbnsn.com [mailto:info-vax-bounces at rbnsn.com] On Behalf Of Richard B. Gilbert
Sent: Monday, August 10, 2009 9:58 AM
To: info-vax at rbnsn.com
Subject: Re: [Info-vax] RMS internals?

Bob Koehler wrote:
> In article <h5lckr$8h3$1 at naig.caltech.edu>, glen herrmannsfeldt <gah at ugcs.caltech.edu> writes:
>> In comp.os.vms Howard S Shubs <howard at shubs.net> wrote:
>> (big snip)
>>
>>> I suppose we could have done it with two $GETs, yes.  Unfortunately,
>>> without knowing for sure how the file was being written by FTP, we
>>> didn't know that.  FTP is saving it as two records, one of 32767 bytes,
>>> and one of 330 bytes.  I only found that out once I looked at the blocks
>>> while debugging my routines.  And I can't be sure it'll always work this
>>> way.  We're using MULTINET.  What if we switch to UCX (unlikely) and it
>>> does things differently?  I like the idea of having a library around
>>> which will read any record length, anyway.
>> TCP is a stream protocol, with no record marks.  The resulting
>> file should be independent of anything in the TCP/IP chain.
>
>    FTP imposes a standard CRLF pair at the end of each line of text,
>    when transfering as a text file.  Of course, TCP doesn't need to
>    know about this.
>

That's not quite true!  FTP appends the LOCAL LINE TERMINATOR in text
mode.  Unix destinations get <LF>.  DOS/Windows get <CR><LF>.  I think
there's something that uses <CR> by itself but I can't recall what it
is; maybe Apple/Mac.  VMS gets "counted strings".

It's handled on the receiving end.

--
draco vulgaris
_______________________________________________
Info-vax mailing list
Info-vax at rbnsn.com
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com


Directly from RFC 959:

        3.1.1.1.  ASCII TYPE

            This is the default type and must be accepted by all FTP
            implementations.  It is intended primarily for the transfer
            of text files, except when both hosts would find the EBCDIC
            type more convenient.

            The sender converts the data from an internal character
            representation to the standard 8-bit NVT-ASCII
            representation (see the Telnet specification).  The receiver
            will convert the data from the standard form to his own
            internal form.

            In accordance with the NVT standard, the <CRLF> sequence
            should be used where necessary to denote the end of a line
            of text.  (See the discussion of file structure at the end
            of the Section on Data Representation and Storage.)

            Using the standard NVT-ASCII representation means that data
            must be interpreted as 8-bit bytes.

            The Format parameter for ASCII and EBCDIC types is discussed
            below.

Dan