This is a multipart message in MIME format.
--=_alternative 000F190B8525743F_=
Content-Type: text/plain; charset="US-ASCII"

David J Dachtera <djesys.no@spam.comcast.net> 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.

--=_alternative 000F190B8525743F_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif"><br>
</font>
<br>
<br><font size=2><tt>David J Dachtera &lt;djesys.no@spam.comcast.net&gt;
wrote on 05/02/2008 10:34:10 PM:<br>
<br>
&gt; norm.raphael@metso.com wrote:<br>
&gt; &gt; <br>
&gt; &gt; This shows and output file with<br>
&gt; &gt; <br>
&gt; &gt; Record format: &nbsp; &nbsp; &nbsp;Stream_LF, maximum 255 bytes,
longest 255 bytes<br>
&gt; &gt; <br>
&gt; &gt; but the DUMP/RECORD below shows<br>
&gt; &gt; <br>
&gt; &gt; Record number 120 (00000078), 7626 (1DCA) bytes, RFA(0008,0000,01FB)<br>
&gt; &gt; <br>
&gt; &gt; a record much longer than that.<br>
&gt; &gt; <br>
&gt; &gt; Comments?<br>
&gt; <br>
&gt; As I understand it (probably inaccurate/incomplete), these values
are<br>
&gt; really just advisory in nature. They provode some clue as to what
is<br>
&gt; reasonably expectable, even if that expectation does not reflect the<br>
&gt; reality of the data.<br>
&gt; <br>
&gt; I read once that some programs use the LRL value at file ((SYS)$)OPEN<br>
&gt; time to initially allocate buffer space.</tt></font>
<br>
<br><font size=2><tt>In this case, EVE refused to open the file until the
attribute was adjusted.</tt></font>
<br><font size=2><tt>EDT opened it but of course truncated the long record
on the way in.</tt></font>
<br>
<br><font size=2><tt>So at least one attribute mattered to at least on
application.</tt></font>
<br>
<br><font size=2><tt>I'm still unable to generate 255, 255 from a simple
edit, modify, save....</tt></font>
<br><font size=2><tt><br>
&gt; <br>
&gt; D.J.D.<br>
</tt></font>
--=_alternative 000F190B8525743F_=--

On May 3, 10:42=A0pm, 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 :=3D 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=3Dmrs=3D255 '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.