home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 263,232 of 264,096   
   Johnny Billquist to Waldek Hebisch   
   Re: Binutils   
   05 Sep 25 23:06:38   
   
   From: bqt@softjar.se   
      
   On 2025-09-05 17:43, Waldek Hebisch wrote:   
   > Arne Vajhøj  wrote:   
   >> On 9/4/2025 11:02 PM, Waldek Hebisch wrote:   
   >>> Arne Vajhøj  wrote:   
   >>>>   
   >>>> I think he got the transfer working both ways with a little   
   >>>> ingenuity.   
   >>>   
   >>> Yes, thanks to your tip I can correct attributes on files   
   >>> transmitted from Linux.  To transfer from VMS I can either   
   >>> change attributes to fixed blocks and deal with padding   
   >>> in Linux or use zip -V.  I have tried   
   >>>   
   >>> SET FILE/ATTR=(RFM:FIX,MRS:1)   
   >>>   
   >>> but that does not give me expected result.   
   >>   
   >> I would try with an even number for MRS. An odd number will   
   >> cause some bytes to be considered pad bytes.   
   >   
   > Let me explain what I expected: RFM:FIX alone keeps maximal   
   > record size unchanged, effectivly adding padding in last   
   > record (unless length of the file happens to be be an integral   
   > multiple of maximal record size).  My expectation was that   
   > MRS:1 will eliminate need for padding, keping file end in   
   > the same place as it was before changing attributes.   
   >   
   > Unfortunately, it seems that attempts to set record size are   
   > ignored.  It seems that record size is separate from mazimal   
   > record size and despite claim in "VSI OpenVMS Record Management   
   > Services Reference Manual":   
   >   
   > : The maximum record size (MRS) field defines the size of all records   
   > : in a file with fixed-length records, the maximum size of variable-length   
   > : records, the maximum size of the data area for variable with fixed-   
   > : length control records, and the cell size (minus overhead) for relative   
   > : files.   
   >   
   > setting maximal record size does not change record size: DUMP/HEADER   
   > shows me:   
   >   
   >          Record type:                      Fixed   
   >          File organization:                Sequential   
   >          Record attributes:                   
   >          Record size:                      4056   
   >          Highest block:                    54   
   >          End of file block:                52   
   >          End of file block:                52   
   >          End of file byte:                 220   
   >          Bucket size:                      0   
   >          Fixed control area size:          0   
   >          Maximum record size:              26332   
   >   
   > in contradiction to the claim from reference manual.   
      
   I think you're expecting magic (if I understood you right). Changing the   
   attributes of an existing file does not change the content of the file,   
   merely how some things are interpreted at read, as well as possibly   
   affecting further writes.   
      
   If you set a file to fixed, with a maximum record size of whatever does   
   not change any existing records in the file. It can cause truncation   
   when you write additional records, but if you by some trickery caused   
   larger records to exist in the file, they will not be changed.   
      
   Furthermore, you cannot dodge padding if you have records in the file.   
   If you specify a maximum records size of 1, you'll get padding on every   
   record if I remember right. The one way to not have padding is to have a   
   stream record format.   
      
   But really, just modifying file attributes does not in any way go in and   
   actually change the content in the file.   
      
      Johnny   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca