This is a discussion on Re: RMS record much longer that format attribute proclaims. - VMS ; Hein RMS van den Heuvel wrote on 04/30/2008 02:43:47 PM: > On Apr 30, 8:35 am, norm.raph...@metso.com wrote: > > This shows and output file with > > > > Record format: Stream_LF, maximum 255 bytes, longest 255 bytes > ...
Hein RMS van den Heuvel
wrote on 04/30/2008
> On Apr 30, 8:35 am, norm.raph...@metso.com wrote:
> > 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?
> 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?
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.
> It the record a 'good one' as far as the application is concerned, or
> is it broken ?
> I'm sure you know how to 'fix' it, but since you did not indicate
> $ SET FILE/ATTR=(MRS=0,LRL=7627) TEST.LOG
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.
> Hein. (taking a quick peek online whilest on family vacation)