From: vaxs09@v7.vitro.com
Subject: Re: VMS file structure?
Organization: Vitro Corporation
Date: Fri, 22 Jan 1993 14:13:33 GMT

In article <C16JI3.4Ln@nmrdc1.nmrdc.nnmc.navy.mil>, dsc3pzp@nmrdc1.nmrdc.nnmc.navy.mil (Philip Perucci) writes:
> But what about VMS?  Is VMS like IBM (go ahead - FLAME ME) in that
> files have a block-size and record-length?  If so, how does one do
> a binary "ftp"?  Must you set the block/record size manually?
> BTW, I use Wollongong for TCP/IP.

I see that Robert Gezelter has already posted a reply summarizing the
various record structures available for RMS files.  I'll try to answer
your specific questions.

Under VMS you don't normally have to specify block or record sizes.  You
never have to specify block size for disk files.  On disk, the block size
is always 512 bytes.  It is not usually neccessary to specify the record
size either.  Most VMS file types have variable length records and the
only record size you'd need to worry about is a maximum length (which
almost always defaults adequately).

For files with fixed length records, the initial creator must specify the
record size.  Subsequent accessors must either specify an identical record
size or just let it default (the record size is stored in the file header).

For FTP, you don't have to specify record size.  It all defaults for you.
There are three cases:

1.  Ordinary FTP in TEXT (ASCII) mode.

    When receiving a file, the VMS file will be created with variable length
    records.  The file will be tagged for "carriage return carriage control"
    which means that standard utilities that display the file (such as TYPE
    or PRINT) will insert a carriage return/line feed combination between
    each record on output.

    When transmitting a file to a UNIX system you'll end up with each
    record delimited by a line feed.

    If you are dealing with readable text, use TEXT mode.
    If you are dealing with binary data, don't use TEXT mode.  It'll
    mess with your record separators.

2.  Ordinary FTP in BINARY (IMAGE) mode.

    When receiving a file, the VMS file will be created with fixed length
    512 byte records.  Any record separators (carriage returns, line feeds
    or whatever) in the original file are inserted verbatim in the VMS file.
    You end up with an sequence of bytes identical to those on the target
    system.  VMS maintains a "bytes used" count for the last block in the
    file.  That count indicates exactly where the end-of-file occurs within
    the last record.

    If you're receiving a .tar or .Z file from the Internet, don't worry
    about it.  TAR and LZDCMP deal with container files with this format
    just fine.  VAX executables (if you're brave enough to load them
    from the Internet) work just fine as well.

    When sending a file, I'm not sure exactly how it's handled.  In the
    case of a 512 byte, fixed length record file though, you certainly get
    the desired effect -- an identical array of bytes is created at the
    remote system.

    If you're dealing with binary data, use BINARY mode.
    If you're dealing with text, BINARY mode will make it look real
    funny.  You don't get a carriage return with the line feed and
    the records don't break at line boundaries).

3.  FTP from one VMS system to another.

    The real TCP/IP packages running on VMS systems (Wollongong's WIN/TCP,
    TGV's Multinet and others, but not DEC's UCX) have a private operating
    mode.  They recognize each other and automatically switch into a
    "RMS transfer mode".

    When you're going from one VMS system to another, don't worry about it.
    The file will be copied bit-for-bit identical and the file organization
    (fixed length, variable length, stream, etc) will be preserved.

    I wouldn't try it with indexed files though.
                     
	John Briggs			vaxs09@v7.vitro.com
Newsgroups: comp.os.vms,biz.dec.workstations,vmsnet.alpha