Applied corrections from Daniele

doc/CHEP2016/CHEP_2016_paper_CTA.tex

@@ -156,7 +156,7 @@ The following steps describe how a file is archived to tape:
   \item On the close of the file, the EOS workflow engine queues a request to
   archive the file with the CTA front-end.
   \item The CTA front-end stores the archive request in the CTA metadata system.
-  \item The file becomes eligible for archival.  Either the file has be been
+  \item The file becomes eligible for archival.  Either the file has been
   queued for the maximum permissible amount of time or there is enough data to
   be transferred to warrant the cost of mounting a tape.
   \item A tape server connected to a free tape drive queries the CTA metadata
@@ -185,7 +185,7 @@ The following steps describe how a file is retrieved from tape.
   the CTA front-end.
   \item The CTA front-end stores the retrieve request in the CTA metadata
   system.
-  \item The file becomes eligible for recall.  Either the file has be been
+  \item The file becomes eligible for recall.  Either the file has been
   queued for the maximum permissible amount of time or there is enough data to
   be transferred to warrant the cost of mounting a tape.
   \item A tape server connected to a free tape drive queries the CTA metadata
@@ -384,7 +384,7 @@ disk storage, data transfer protocols and meta-data operations.  CTA will focus
 on providing efficient tape backend storage.
 
 CTA will introduce pre-emptive drive scheduling which will automatically
-schedule the background tasks of tape media repacking and data verification
+schedule the background tasks of tape media repacking and data verification.
 This automatic scheduling will use the tape drives at full speed all of the time
 and therefore enable CTA to cope with the 150 petabytes per year data rate of
 LHC physics run 3.