From: johnrreagan@earthlink.net   
      
   On 9/3/2025 6:38 PM, Johnny Billquist wrote:   
   > On 2025-09-03 06:20, Lawrence D’Oliveiro wrote:   
   >> On Tue, 2 Sep 2025 20:35:54 -0400, Arne Vajhøj wrote:   
   >>   
   >>> If you create a RFM VAR file on VMS with:   
   >>>   
   >>> A   
   >>> BB   
   >>> CCC   
   >>>   
   >>> then it is stored as:   
   >>>   
   >>> 01 00 41 00   
   >>> 02 00 42 42   
   >>> 03 00 43 43 43 00   
   >>>   
   >>> When you do a binary FTP to Linux you end up with just 6 bytes:   
   >>>   
   >>> 41 42 42 43 43 43   
   >>   
   >> That’s stupid. I would describe that as a bug in the VMS FTP program.   
   >   
   > Really? The length bytes are not actually any data in the file. Same   
   > with padding. I would say it would be a very bad bug to actually include   
   > them.   
   >   
   >>> With a binary FTP from VMS of a VAR file you get just the data bytes   
   >>> with no structure defining bytes at all.   
   >>   
   >> And here I thought “binary” meant “transfer all the bytes in the file   
   as   
   >> is” ...   
   >   
   > And it does. All the bytes of the file. Not all the metadata that exists   
   > outside of the data content.   
   >   
   >    Johnny   
   >   
   Don't consider the length/padding to be part of the file.  It is simply   
   part of the container that is holding the bytes.  VARCR, STMLF, etc.   
   each are different containers but would hold the same bytes.  You   
   wouldn't want the RMS header would you?  Of course not.   
      
   Consider an OBJ file that contains code and data.  The container in   
   which it lives (EOBJ, ELF32, ELF64, etc.) is not relevant to the code or   
   data.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)