From: antispam@fricas.org
Arne Vajhøj wrote:
> On 9/5/2025 11:43 AM, 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 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. I would expect that having records
of length 3 and then setting length to 2 would also truncate
data in the records.
I did:
copy FFS.OBJ;1 FFS.OBP;1
SET FILE/ATTR=LRL:1 FFS.OBP;1
SET FILE/ATTR=RFM:FIX FFS.OBP
and after that scp to Linux worked fine. Since in variable length
file records always take even number of bytes (odd length recors are
padded), I think that ET FILE/ATTR=LRL:2 would work equally well.
But for me LRL:1 looks more correct, as this does not depend on
detail above.
--
Waldek Hebisch
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
