Article 147903 of comp.os.vms:

In article <009A29C8.01B3CE40.14@ccastat.demon.co.uk>, chris@ccagroup.co.uk writes...
 : 
>Carl wrote:
 :
>>number of blocks.  Then, at the end of the actual data in the first file, you'd 
>>set the next word, and the first word in each of any remaining empty blocks in
>>the cluster, to %XFFFF.  Then modifying the file retrieval pointers would give
 :
>Very good - that never would have occurred to me. This is presumably the way
>RMS handles 'nospanblocks' ?

Yes.

> I take it it doesn't care that the file actually isn't nospanblocks ?

Correct. This is in fact how RMS Run Unit journalling manages to delete
records from a shared sequential file where a transaction is rolled back.
Ofcourse it is in the convenient position to ba able to force new records
to start at a block boundary no matter what the file said.
Yes, you too can delete records from an rms sequential file using the -1
technique, but you'll have to align with further records somehow!
(best you can do for non-block-aligned is to fake a record willed with nulls.

>Is modifying the file pointers easy/safe/supported ? I don't see a safe way to

It is hard, unsafe, unsupported :-).

> but presumably indexed files have a similar problem in extending
>their 'areas' - or do they just add to the end of the file ?

They just grow their areas at the end of the file in <extend> sized
chunks and then parcel out buckets from the extend later.

> Could this be a
>clean solution for prepending to a very large file of variable length records ?

The clean solution is to simply copy the data from the large file.
Alternative solutions are likely to be a bigger job then the problem itself.
If this is truly a make or break performance/space solution then you want
to investigate alternatives at the application level. For example i might
imagine the the application could read from a mailbox (pipe! some day) which
is fed by the prefix first, real data next as fed by an independend task.
Or that the application is hacked up to read a file of files first,
then read datya from the files passed.


Hope this helps,		+--------------------------------------+
Hein van den Heuvel, Digital.	| All opinions expressed are mine, and |
  "Makers of VMS and other	| may not reflect those of my employer |
   fine Operating Systems."	+--------------------------------------+