Index: tools/build/v2/doc/src/architecture.xml
===================================================================
--- tools/build/v2/doc/src/architecture.xml	(revision 86431)
+++ tools/build/v2/doc/src/architecture.xml	(working copy)
@@ -83,8 +83,8 @@
 
         <listitem><para>
           The targets are returned to the top level code. They are converted
-        into bjam targets (via <code>virtual-target.actualize</code>) and passed
-        to bjam for building.
+          into Boost Build targets (via <code>virtual-target.actualize</code>) 
+          and passed to Boost Build for building.
         </para></listitem>
       </orderedlist>
     </para>
@@ -166,8 +166,8 @@
         Virtual targets correspond to atomic updatable entities. Each virtual
       target can be assigned an updating action -- instance of the
       <code>action</code> class. The action class, in turn, contains a list of
-      source targets, properties, and a name of an bjam action which should be
-      executed.
+      source targets, properties, and a name of an Boost Build action which 
+      should be executed.
       </para>
 
       <para>
@@ -183,7 +183,7 @@
       that the real file names are computed, and the commands that should be run
       are generated. This is done by the <code>virtual-target.actualize</code>
       and <code>action.actualize</code> methods. The first is conceptually
-      simple, while the second needs additional explanation. Commands in bjam
+      simple, while the second needs additional explanation. Commands in Boost Build
       are generated in a two-stage process. First, a rule with an appropriate
       name (for example "gcc.compile") is called and is given a list of target
       names. The rule sets some variables, like "OPTIONS". After that, the
@@ -308,15 +308,15 @@
       <para>
         As stated above, it is possible to compile a C++ file multiple times,
       using different include paths. Therefore, include dependencies for those
-      compilations can be different. The problem is that bjam does not allow
+      compilations can be different. The problem is that Boost Build does not allow
       multiple scans of the same target.
       </para>
 
       <para>
         The solution in Boost.Build is straightforward. When a virtual target is
-      converted to a bjam target (via the
+      converted to a Boost Build target (via the
       <literal>virtual-target.actualize</literal> method), we specify the
-      scanner object to be used. The actualize method will create different bjam
+      scanner object to be used. The actualize method will create different Boost Build
       targets for different scanners.
       </para>
 
@@ -355,7 +355,7 @@
         <listitem><simpara>
           If when compiling "a.cpp" there is an include of "a.h", the "dir"
         directory is on the include path, and a target called "a.h" will be
-        generated in "dir", then bjam should discover the include, and create
+        generated in "dir", then Boost Build should discover the include, and create
         "a.h" before compiling "a.cpp".
         </simpara></listitem>
 
Index: tools/build/v2/doc/src/extending.xml
===================================================================
--- tools/build/v2/doc/src/extending.xml	(revision 86431)
+++ tools/build/v2/doc/src/extending.xml	(working copy)
@@ -613,7 +613,7 @@
         and the target type. When invoked, the generator will create a target
         of type <literal>CPP</literal> with a source target of
         type <literal>VERBATIM</literal> as the only source. But what command
-        will be used to actually generate the file? In bjam, actions are
+        will be used to actually generate the file? In Boost Build, actions are
         specified using named "actions" blocks and the name of the action
         block should be specified when creating targets. By convention,
         generators use the same name of the action block as their own id. So,
@@ -970,7 +970,7 @@
 
 
           <para> Note the <code>bind DEF_FILE</code> part. It tells
-          bjam to translate the internal target name in
+          Boost Build to translate the internal target name in
           <varname>DEF_FILE</varname> to a corresponding filename in
           the <code>link</code> action.  Without it the expansion of
           <code>$(DEF_FILE)</code> would be a strange symbol that is
@@ -992,7 +992,7 @@
 </programlisting>
 <!-- You *must* explain the part in [...] above. It's completely opaque to the casual reader -->
 
-            This is needed to accomodate some bug in bjam, which hopefully
+            This is needed to accomodate some bug in Boost Build, which hopefully
             will be fixed one day.
             <!-- This is *NOT* a bug!!  Anyway, BBv2 shouild handle this automatically. Why doesn't it? -->
 </para></listitem>
Index: tools/build/v2/doc/src/install.xml
===================================================================
--- tools/build/v2/doc/src/install.xml	(revision 86431)
+++ tools/build/v2/doc/src/install.xml	(working copy)
@@ -103,7 +103,7 @@
               </para>
 
               <para>Placing Boost.Build into <filename>/usr/share/boost-build</filename>
-              will make sure that <command>bjam</command> will find Boost.Build
+              will make sure that <command>b2</command> will find Boost.Build
               without any additional setup.</para>
             </listitem>
 
@@ -120,7 +120,7 @@
         </para>
 
         <para>If those guidelines are met, users will be able to invoke
-        <command>bjam</command> without any explicit configuration.
+        <command>b2/command> without any explicit configuration.
         </para>
 
     
Index: tools/build/v2/doc/src/overview.xml
===================================================================
--- tools/build/v2/doc/src/overview.xml	(revision 86431)
+++ tools/build/v2/doc/src/overview.xml	(working copy)
@@ -580,6 +580,12 @@
 
     <section id="bbv2.overview.invocation">
       <title>Invocation</title>
+      
+      <note>
+        <para>
+            As of Boost 1.47.0, the official name of Boost.Build executable is <command>b2</command>. The bootstrap scripts create a copy with the old name <command>bjam</command> to prevent third-party build scripts from failing. Authors are encouraged to update their scripts to refer to the new name.
+        </para>
+      </note>
 
       <para>To invoke Boost.Build, type <command>b2</command> on the command line. Three kinds
       of command-line tokens are accepted, in any order:</para>
Index: tools/build/v2/doc/src/reference.xml
===================================================================
--- tools/build/v2/doc/src/reference.xml	(revision 86431)
+++ tools/build/v2/doc/src/reference.xml	(working copy)
@@ -17,7 +17,8 @@
     <section id="bbv2.reference.init">
       <title>Initialization</title>
 
-      <para>bjam's first job upon startup is to load the Jam code that
+      <para>First job of the Boost Build's command <command>b2</command> 
+        upon startup is to load the Jam code that
         implements the build system. To do this, it searches for a file
         called <filename>boost-build.jam</filename>, first in the invocation directory, then
         in its parent and so forth up to the filesystem root, and finally
Index: tools/build/v2/doc/src/tasks.xml
===================================================================
--- tools/build/v2/doc/src/tasks.xml	(revision 86431)
+++ tools/build/v2/doc/src/tasks.xml	(working copy)
@@ -447,8 +447,8 @@
       <varname>args</varname> and <varname>input-files</varname> as command-line
       arguments. The <varname>args</varname> parameter is passed verbatim and
       the values of the <varname>input-files</varname> parameter are treated as
-      paths relative to containing Jamfile, and are adjusted if <command>bjam
-      </command> is invoked from a different directory. The
+      paths relative to containing Jamfile, and are adjusted if <command>b2</command> 
+      is invoked from a different directory. The
       <code>run-fail</code> rule is identical to the <code>run</code> rule,
       except that it expects that the run fails.
     </para>