Article 125737 of comp.os.vms:
Path: nntpd.lkg.dec.com!crl.dec.com!crl.dec.com!caen!reeve.research.aa.wl.com!decwrl!nntp.crl.com!pacbell.com!ihnp4.ucsd.edu!mvb.saic.com!info-vax
From: Jim Kirkpatrick <JIMKIRK@UWYO.EDU>
Newsgroups: comp.os.vms
Subject: Re: Why is MAIL.MAI a placed file ?
Message-ID: <01HTBZ6LPSO2001I44@PLAINS.UWYO.EDU>
Date: Wed, 26 Jul 1995 16:28:39 -0600 (MDT)
Organization: Info-Vax<==>Comp.Os.Vms Gateway
X-Gateway-Source-Info: Mailing List
Lines: 23

In article <3v3arc$no6@rs18.hrz.th-darmstadt.de>, mueller@axp612.gsi.de
 (W.F.J.Mueller) writes:
> My question: Why on earth is MAIL.MAI a placed file ?? What could possibly
>              break if it's moved ?? If I backup and restore it with BACKUP
>              this file attribute gets lost and everything works fine !
>              Is this a bug in VMSmail ?

I corresponded with Digital on this topic, and my recollection is that
this was a bad methodology in RMS (though Terry's assertion of a bug
in CONVERT may also be true).  Apparently, at some point in RMS, when
it's decided to extend the file, RMS calls a routine to do so.  The
routine signals success by setting the placed bit in the header, which
the "upper" layer reads and then goes on with its task, whatever that was.
Nowhere does this placed bit get cleared.  Sloppy.

I also griped that DFO (or should I call it PFO, Polycenter File
Optimizer? :-) makes no comment whatever when it skips a placed file.

This was a few years ago.  You can guess how much progress Digital has
made on these issues.  (hint: zero)

Jim