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)