From: antispam@fricas.org   
      
   Arne Vajhøj  wrote:   
   > On 9/5/2025 1:40 PM, Waldek Hebisch wrote:   
   >> Arne Vajhøj  wrote:   
   >>> I was not talking about file padding but about record   
   >>> padding.   
   >>>   
   >>> I think this illustrate the issue:   
   >>>   
   >>> $ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")   
   >>> FIX2   
   >>> $ typ z.txt   
   >>> AB   
   >>> CD   
   >>> EF   
   >>> $ set file/attr=(mrs:1) z.txt   
   >>> $ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")   
   >>> FIX2   
   >>> $ set file/attr=(lrl:1) z.txt   
   >>> $ write sys$output f$file("z.txt","rfm"),f$file("z.txt","mrs")   
   >>> FIX1   
   >>> $ typ z.txt   
   >>> A   
   >>> C   
   >>> E   
   >>>   
   >>> B, D and F are "lost".   
   >>>   
   >>> And it looks like one need to set LRL instead of MRS to change the file.   
   >>   
   >> I am not sure what this is supposed to ilustrate.  I mean, I would   
   >> expect that changing record length below previous record length   
   >> and doing no other changes to attributes will lead to trouble   
   >> and while I do not undertand all details of your example, it seem   
   >> to confirm my expectation.   
   >   
   > It illustrates that:   
   >   
   > $ set file/attr=(rfm:fix,lrl:oddnumber) ...   
   >   
   > is very dangerous, because some data bytes may end up being lost due   
   > to being considered padding.   
      
   I did   
      
   set file/attr=lrl:1   
   set file/attr=rfm:fix   
      
   which in sane system should be equivalent to   
      
   set file/attr=(rfm:fix,lrl:1)   
      
   As I wrote my change gave result that I expected, that is I got   
   both count and record content (including padding byte when record   
   had odd length).  From my point of view I got all data with no   
   loss and no extra bytes at the end.   
      
   You use DCL features which make it somewhat unclear what your command   
   did (and you did not specify what parameters were used to create   
   initial file).  Also, your command looks like using the same   
   file as input and output (or do versions insure that they are   
   different?).   
      
   >>                         I would expect that having records   
   >> of length 3 and then setting length to 2 would also truncate   
   >> data in the records.   
   >   
   > $ set file/attr does not change the content of the file only the   
   > file header meta data.   
   >   
   > AAA   
   > BBB   
   > CCC   
   >   
   > 41 41 41 00   
   > 42 42 42 00   
   > 43 43 43 00   
   >   
   > does not become:   
   >   
   > AA   
   > BB   
   > CC   
   >   
   > 41 41   
   > 42 42   
   > 43 43   
   >   
   > but:   
   >   
   > AA   
   > A*   
   > BB   
   > B*   
   > CC   
   > C*   
   >   
   > 41 41   
   > 41 00   
   > 42 42   
   > 42 00   
   > 43 43   
   > 43 00   
      
   I am not sure how you are getting result above.  I created a   
   simple variable length file and I get:   
      
   $ set FILE/ATTR=LRL:2 VTST.TXT   
   $ type VTST.TXT   
   a   
   bcd   
   $ set FILE/ATTR=LRL:1 VTST.TXT   
   $ type VTST.TXT   
   a   
   bcd   
      
   That is 'type' is getting right records regardless of my LRL setting.   
   Naive program could truncate records.  Slightly better one   
   could get records in pieces of size corresponding to   
   LRL (possibly creating more record on output than is present in   
   the input).  But truncating with odd LRL setting and reading   
   record padding bytes with even LRL setting look like a bug   
   (which may remain unfixed forever due to requirement for   
   bug compatibility).   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)