Re: RMS record much longer that format attribute proclaims. - VMS

This is a discussion on Re: RMS record much longer that format attribute proclaims. - VMS ; David J Dachtera wrote on 05/02/2008 10:34:10 PM: > norm.raphael@metso.com wrote: > > > > This shows and output file with > > > > Record format: Stream_LF, maximum 255 bytes, longest 255 bytes > > > > but the ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: RMS record much longer that format attribute proclaims.

  1. Re: RMS record much longer that format attribute proclaims.

    David J Dachtera wrote on 05/02/2008 10:34:10
    PM:

    > norm.raphael@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?

    >
    > As I understand it (probably inaccurate/incomplete), these values are
    > really just advisory in nature. They provode some clue as to what is
    > reasonably expectable, even if that expectation does not reflect the
    > reality of the data.
    >
    > I read once that some programs use the LRL value at file ((SYS)$)OPEN
    > time to initially allocate buffer space.


    In this case, EVE refused to open the file until the attribute was
    adjusted.
    EDT opened it but of course truncated the long record on the way in.

    So at least one attribute mattered to at least on application.

    I'm still unable to generate 255, 255 from a simple edit, modify, save....

    >
    > D.J.D.



  2. Re: RMS record much longer that format attribute proclaims.

    On May 3, 10:42*pm, norm.raph...@metso.com wrote:

    DJD> > I read once that some programs use the LRL value at file ((SYS)
    $)OPEN
    DJD> > time to initially allocate buffer space.
    >
    > In this case, EVE refused to open the file until the attribute was
    > adjusted.


    I think the TPU default USZ (RMS User Buffer siZe) currently is
    min(2048,LRL)
    Could be 2000

    > I'm still unable to generate 255, 255 from a simple edit, modify, save....


    Of course not.
    You are not listening!
    (Only minor disrespect intented :-) :-)

    Normal RMS (such as used by simple edit) does not do this.
    It takes a DECCRTL or similar 'smart' tool, to mess this up.

    You have an account on eisner (or an other system with perl) right?
    Try this:

    $ delete x.x.*
    $ x := x.x
    $ perl -le "print qq($_ ) x $_ ** 3 for (1..10)" > 'x
    $ write sys$output f$file(x,"MRS"), " ", f$file(x,"LRL")
    $ def decc$default_lrl 255
    $ perl -le "print qq($_ ) x $_ ** 3 for (1..10)" > 'x
    $ write sys$output f$file(x,"MRS"), " ", f$file(x,"LRL")
    $ set file/attribute=mrs=255 'x
    $ perl -le "print qq($_ ) x $_ ** 3 for (1..10)" > 'x
    $ write sys$output f$file(x,"MRS"), " ", f$file(x,"LRL")

    So let me ask again... Who / What wrote the file?

    Cheers,
    Hein.

+ Reply to Thread