Article 155856 of comp.os.vms:

In article <Pine.LNX.3.93.960924102630.553B-100000@irys.stanpol.zabrze.pl>, Gotfryd Smolik <gotfryd@stanpol.zabrze.pl> writes...
>On Sat, 21 Sep 1996, Donald P. Welker wrote:
>+st2f304@hsvax1.HS.UNI-HAMBURG.DE (Phillip Helbig) wrote:

>+Definately yes! We lost several production payroll files (including the
>+database dictionary) a few years back. This was DEC's diagnosis.
:
> This *can* be true: some database may work with the way "read a file
>description via filesystem at start, but do the data IO direct to
>disk on the LBN level".

Nah, Nonsense. There are NO commercial databases out there performing  LBN IO.
And even if there were, just didling with directory entries does NOT change
allocated blocks, so they'd remain just as valid, untill an actual delete
of the file was done.

>this may be done b.ex. for speed - but also can create a problem

The `speed' advantage of LBN IO versus normal VBN IO consists of
avoiding of a few instructions in the QIO path to perform the 
window mapping and occasionally a few more instruction if a window
turn needs to take place. Just pre-allocate (contiguos) a file and
perhaps `place' it carefully (FDL AREA options!) will get the 
application roughly to the same place without the maintenance headache.

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."	+--------------------------------------+