Re: RMS record much longer that format attribute proclaims.

Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> wrote on 04/30/2008
02:43:47 PM:
[color=blue]
> On Apr 30, 8:35 am, norm.raph...@metso.com wrote:[color=green]
> > This shows and output file with
> >
> > Record format: Stream_LF, maximum 255 bytes, longest 255 bytes
> >
> > but the DUMP/RECORD below shows
> >
> > Record number 120 (00000078), 7626 (1DCA) bytes, RFA(0008,0000,01FB)
> >
> > a record much longer than that.
> >
> > Comments?[/color]
>
> Only the obvious... the actual records do not match the file
> attributes. So ?
>
> And that 255 is sort of a nice-number: max value for an unsigned byte.
>
> RMS itself would not do that, short of a system crash stopping the
> atributes from being flushed out.
> Who / What wrote the file? The C-RTL easily could, as it does block
> IO, not (RMS) record IO of simple unshared sequential files.
> It could have picked up attributes from an earlier version of the
> file, if C rtl was used to create it.
> And check out the logical name "decc$default_lrl".
> That would not happen to be set to 255 would it now?
>[/color]

I now suspect a tyro opened an earlier version of the file in TPU and
rewrote it on EXIT (when a QUIT was intended) and TPU did the changes.
I have yet to test this hypothesis. The next time the app was run, I
believe the File-Open took it's attributes from the existing version
to create the version in question.
[color=blue]
> It the record a 'good one' as far as the application is concerned, or
> is it broken ?
>[/color]
It's fine.
[color=blue]
> I'm sure you know how to 'fix' it, but since you did not indicate
> so...:
> $ SET FILE/ATTR=(MRS=0,LRL=7627) TEST.LOG[/color]

Thanks for the vote of confidence. Yes I fixed it with
SET FILE/ATTR=(MRS=0,LRL=32767) TEST.LOG

once I determined the contents was correct.

-Norm
[color=blue]
>
> Cheers,
> Hein. (taking a quick peek online whilest on family vacation)[/color]