Hein RMS van den Heuvel wrote on 05/04/2008
02:15:04 AM:

> 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 :-) :-)


Of course I'm not listening (no disrespect intended (or felt)).

>
> 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?
>


I didn't mean to reopen this as I shall never see it again.

When testing, our app will write the file max 255, longest 88
(if the longest record is 88) unless the last record written
is empty, then we seem to see max 255, longest 255.

When things are working and the input produces the really
long output record, then we see max 0, longest 32767. So the
app in testing is not always the same. That doesn't explain
how a log file with a long record got the shorter attributes.
I've never seen this in production, so it's not worth persuing
by me.

EVE (edt emulation) did balk at opening it at 255,255.

> Cheers,
> Hein.