[Info-vax] MAX record size in a sequential file

[Hein RMS van den Heuvel]

On Tuesday, May 15, 2012 1:21:07 PM UTC-6, JF Mezei wrote:
> StGallen wrote:
> >
> > QUESTION:
> > How does RMS come up with a value of 32767 for the Longest Record?

RMS doesn't. The C-RTL does as controlled by the logical name DECC$DEFAULT_LRL
http://h71000.www7.hp.com/doc/732final/5763/5763pro_004.html
That same C-RTL will also default the file attributes to a prior version of the file if that exists, to futher muddle the waters.

> It is a default value because RMS doesn't keep track of the longest

It does.

> record length in the file as this is basically a raw data file which is
> interpreted by RMS at run time to emulate records.

It is not.


> The real limit on record size will be defined by your bufquo (buffer
> quota) which limits the size of any individual IO. 

It does not. 

'bufquo' which is probably referring to the SYSGEN param MAXBUF only influenced BUFFERED IO. Notably QIO to the TERMINAL.

RMS _was_ limited to an IO buffer size of 127 blocks, 'recently' bumped tp 255 blocks.
The record size is limited by the maximum signed 16 bit value (32767)
 
 
> If you have a record in the file that is longer than your bugquo, the read will fail.

No it will not. RMS will read it just fine.
Trying to write the read record to a buffered IO device will fail ($ TYPE ...)


StGallen> I feel it would be inelegant to set the MAP to 32767? 
Why? Nothing wrong with that other than a 'wasted' VM.
It will nicely avoid future failures.

Alternatively you can 
- create the file with RMS proper,
- Use that logical
- 'fix' the file with $ ANALYZE/RMS/UPDATE
- 'fix' the file with $ SET RMS/FILE=ATTRIB=LRL=xxx

Good luck!
Hein