From: antispam@fricas.org   
      
   Johnny Billquist wrote:   
   > 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).   
      
   I simply expected documantaion to say the truth.   
      
   > 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.   
      
   Well, I would prefer to avoid discussions about what is content,   
   what is data and what is metadata. People here have strong views   
   about this and nobody is going to change his/her view.   
      
   I would say that VMS file have header and rest. I think that   
   documentation actually says about disc blocks, but main point is   
   that changing attributes only changes header keeping rest of   
   file unchanged. "VSI OpenVMS Record Management Services Reference   
   Manual" mentions several fields in the header and I wanted to   
   do specific change to header fields. More precisely, I wanted   
   to set file "File organization" to Sequential and record size to 1   
   preserving information about end of file.   
      
   Given that basic parameters are controled by FAB, I looked at   
   parameters to SET FILE/ATTR setting various fields of FAB and   
   I found MRS with from description looked like right way to   
   set record length field in the header. But it did not work.   
   As I wrote in replay to Arne using LRL parameter that he   
   found did the job.   
      
   > 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.   
      
   As I wrote in replay to Arne I did:   
      
   SET FILE/ATTR=LRL:1 FFS.OBP   
   SET FILE/ATTR=RFM:FIX FFS.OBP   
      
   which set file to fixed length records. In such file there is no   
   padding: either there is byte and we have full record or there is   
   no byte and we have no record. Of course, without the second step   
   file above would have variable length records and reading it would   
   produce nonsense.   
      
   --   
    Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|