But this has not to be the case.

Unless all the records in a given file (or, at least in each given portion of a file; though that does complicate things considerably), then the idea doesn't work. But if they are, then it converts an O(n log n) process to O(n), which will have a far more profound effect upon your processing performance than specific sort implementations ever will.

The fundamental requirement for this to work is a simple arithmetic calculation to convert the address of a record to its position in the file. I envisioned this being something like:

my $filePos = ( $recAddr - $firstRecAddr ) * ( $recLen + 1 ) + $lenOfH
+eader;
[download]

This would then allow you to seek directly to the appropriate file (or ramfile) position, and write the record in its final position directly. A similar calculation can be used to address the appropriate bit in the tracking bit-vector.

You mean that I have a bit-string in memory. And I initialise it with 0 and if I find a record then I put a 1 at this position. At the end I have to check if all positions in the bit-string are set to 1. Is this correct?

You have the general idea, but I inverted the state of the bits. Ie.

I envisaged initialising the all the bits to 1: my $tracker = chr(255) x ( $noOfRecords / 8 );

Then unsetting the bits as the records are written: vec( $tracking, 1, $recNo ) = 0;

Then testing for completion by search the tracking vector for non-zero bytes: if( $tracking =~ m[[^\0]] ) {...

But doing it the other way, initialising to 0, setting bits and then searching for non-0xff bytes is the same.