home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 21734 < prev    next >
Encoding:
Text File  |  1993-01-22  |  4.0 KB  |  90 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!psinntp!vitro.com!v7.vitro.com!vaxs09
  3. From: vaxs09@v7.vitro.com
  4. Subject: Re: VMS file structure?
  5. Message-ID: <1993Jan22.091333.1@v7.vitro.com>
  6. Lines: 78
  7. Sender: news@vitro.com (USENET News System)
  8. Organization: Vitro Corporation
  9. References: <C16JI3.4Ln@nmrdc1.nmrdc.nnmc.navy.mil>
  10. Date: Fri, 22 Jan 1993 14:13:33 GMT
  11.  
  12. In article <C16JI3.4Ln@nmrdc1.nmrdc.nnmc.navy.mil>, dsc3pzp@nmrdc1.nmrdc.nnmc.navy.mil (Philip Perucci) writes:
  13. > But what about VMS?  Is VMS like IBM (go ahead - FLAME ME) in that
  14. > files have a block-size and record-length?  If so, how does one do
  15. > a binary "ftp"?  Must you set the block/record size manually?
  16. > BTW, I use Wollongong for TCP/IP.
  17.  
  18. I see that Robert Gezelter has already posted a reply summarizing the
  19. various record structures available for RMS files.  I'll try to answer
  20. your specific questions.
  21.  
  22. Under VMS you don't normally have to specify block or record sizes.  You
  23. never have to specify block size for disk files.  On disk, the block size
  24. is always 512 bytes.  It is not usually neccessary to specify the record
  25. size either.  Most VMS file types have variable length records and the
  26. only record size you'd need to worry about is a maximum length (which
  27. almost always defaults adequately).
  28.  
  29. For files with fixed length records, the initial creator must specify the
  30. record size.  Subsequent accessors must either specify an identical record
  31. size or just let it default (the record size is stored in the file header).
  32.  
  33. For FTP, you don't have to specify record size.  It all defaults for you.
  34. There are three cases:
  35.  
  36. 1.  Ordinary FTP in TEXT (ASCII) mode.
  37.  
  38.     When receiving a file, the VMS file will be created with variable length
  39.     records.  The file will be tagged for "carriage return carriage control"
  40.     which means that standard utilities that display the file (such as TYPE
  41.     or PRINT) will insert a carriage return/line feed combination between
  42.     each record on output.
  43.  
  44.     When transmitting a file to a UNIX system you'll end up with each
  45.     record delimited by a line feed.
  46.  
  47.     If you are dealing with readable text, use TEXT mode.
  48.     If you are dealing with binary data, don't use TEXT mode.  It'll
  49.     mess with your record separators.
  50.  
  51. 2.  Ordinary FTP in BINARY (IMAGE) mode.
  52.  
  53.     When receiving a file, the VMS file will be created with fixed length
  54.     512 byte records.  Any record separators (carriage returns, line feeds
  55.     or whatever) in the original file are inserted verbatim in the VMS file.
  56.     You end up with an sequence of bytes identical to those on the target
  57.     system.  VMS maintains a "bytes used" count for the last block in the
  58.     file.  That count indicates exactly where the end-of-file occurs within
  59.     the last record.
  60.  
  61.     If you're receiving a .tar or .Z file from the Internet, don't worry
  62.     about it.  TAR and LZDCMP deal with container files with this format
  63.     just fine.  VAX executables (if you're brave enough to load them
  64.     from the Internet) work just fine as well.
  65.  
  66.     When sending a file, I'm not sure exactly how it's handled.  In the
  67.     case of a 512 byte, fixed length record file though, you certainly get
  68.     the desired effect -- an identical array of bytes is created at the
  69.     remote system.
  70.  
  71.     If you're dealing with binary data, use BINARY mode.
  72.     If you're dealing with text, BINARY mode will make it look real
  73.     funny.  You don't get a carriage return with the line feed and
  74.     the records don't break at line boundaries).
  75.  
  76. 3.  FTP from one VMS system to another.
  77.  
  78.     The real TCP/IP packages running on VMS systems (Wollongong's WIN/TCP,
  79.     TGV's Multinet and others, but not DEC's UCX) have a private operating
  80.     mode.  They recognize each other and automatically switch into a
  81.     "RMS transfer mode".
  82.  
  83.     When you're going from one VMS system to another, don't worry about it.
  84.     The file will be copied bit-for-bit identical and the file organization
  85.     (fixed length, variable length, stream, etc) will be preserved.
  86.  
  87.     I wouldn't try it with indexed files though.
  88.                      
  89.     John Briggs            vaxs09@v7.vitro.com
  90.