letter P at the end of the name.  There are now two macros to help generate
log messages with the contextual information of file, line and function:

CASTOR_DLF_WRITEC
CASTOR_DLF_WRITECP

The first macro logs a message without parameters accept for the three
contextual ones of file, line and function.  The second macro logs a message
with parameters to which the three contextual ones are prepended.

The meaning of the letter C at the end of the CASTOR_DLF_WRITEC is 'C'onextual
log.  The meaning iof the letter P at the end of CASTOR_DLF_WRITECP is with
'P'arameters.

This macro should be used when it is desirable to include the file, line and
function context information in a log.  It is advised to include such
information when logging an error for the developers, but not to use it for
monitoring logs where operators are informed of what is happening and they do
not need or want to know the details of the source code.

The CASTOR_DLF_WRITEPC macro macro generates the file, line and function
context information automatically and passes it on down the DLF logging chain.
This means developers do not need to use the __FILE__, __LINE__,
__PRETTY_FUNCTION__ macros in their application code when logging.  Here is an
example of using this macro:

  try {
    ...
  } catch(castor::exception::Exception &ex) {
    castor::dlf::Param params[] = {
      castor::dlf::Param("volReqId", vdqmJobRequest.tapeRequestId),
      castor::dlf::Param("Message" , ex.getMessage().str()       ),
      castor::dlf::Param("Code"    , ex.code()                   )};
    CASTOR_DLF_WRITEPC(cuuid, DLF_LVL_ERROR, AGGREGATOR_MAIN_SELECT_FAILED,
      params);
  }

loop.

request messages.  Support is now given for file and tape request messages
with and without error appendices.

the copy and paste demon.

readable log messages.

it from RtcpAcknowledgeMsgBody to RtcpAcknowledgeMsg.

test out some theories.  We have now managed to get the disk and tape I/O
threads of rtcpd to connect back to us and ask for more work.  The 'crazy' code
will need to be re-written into something structured.

the reception of an RTCP message into two separate function calls; the
reception of the header and then the reception of the body.

This modification was needed in order to deal with the next step of
the RTCOPY protocol where the main select loop has to deal with different
types of incoming RTCOPY messages comming from different RTCPD threads.i
Immediately after a call to select which indicates an incoming message, the
tape aggregator needs to use the Transceiever to just read in the RTCP message
header so it can then dispatch the receptionm of the body of the incomming
message to the appropriate Transceiver body reception function.

bits in the file descriptpor set is taken into account.

Kerberos V.

the tape and disk I/O threads of RTCPD:

castor::tape::aggregator::VdqmRequestHandlerThread::processTapeDiskIoConnections

function in order to allow developers to call the function without the need to
specify the size of the params array:

    template<int n>
      void dlf_writep (Cuuid_t uuid,
                       int severity,
                       int message_no,
                       castor::dlf::Param (&params)[n],
                       struct Cns_fileid *ns_invariant = 0) throw() {
      dlf_writep(uuid, severity, message_no, n, params, 0);
    }

The template causes the size of the array to be determied at compile time.  A
pointer to castor::dlf::Param will of course not work.  The original
castor::dlf::dlf_writep function can be used as usual in this case.

The following code snippet shows an example of using the new template:

  castor::dlf::Param params[] = {
    castor::dlf::Param("volReqId", vdqmJobRequest.tapeRequestId),
    castor::dlf::Param("vid"     , request.vid                 ),
    castor::dlf::Param("vsn"     , request.vsn                 ),
    castor::dlf::Param("label"   , request.label               ),
    castor::dlf::Param("devtype" , request.devtype             ),
    castor::dlf::Param("density" , request.density             )};
        castor::dlf::dlf_writep(cuuid, DLF_LVL_SYSTEM,
          AGGREGATOR_GAVE_VOLUME_INFO, params);

the initial connection from RTCPD.  The main select loop is now in place so
that we can see many messages and connections at the same time.  However we
still have not seen the incoming connections we expect for the tape and disk
I/O threads.

will deal with the following:

     * The incoming callback connection request from the tape I/O thread.
     * The incoming callback connection requests from the disk I/O threads.
     * Any incoming messages sent from RTCPD over any of the connected
       sockets, including the initial RTCPD connection.

will facilitate implementing the RTPCD prototcol in a multi-threaded server.
We need to be able to create an RTCPD  callback listener socket within the run
function of a thread and then accept the initial connection made by RTCPD (as
opposed to the 4 or more connections we will later receive from the TAPE IO and
DISK IO threads).  This accept must have a timeout otherwise we could easily
have a server that simply locks up if RTCPD never connects back.

own function:

  castor::tape:aggregator::VdqmRequestHandlerThread::processJobSubmissionRequest

Started to refactorise out the giving of file lists to RTCPD.

Fix checksum comparison so that is does give false positives due to string comparison of a hex number with a 0 on the left.

check set of messages which occure after the sending of the initial
request list and before the creation of the abort/ping thread of
RTPCD.

extended gettapestocheck with the cleanup. changed the way that filerecallfailed is called by updateRecRetryPolicy.

 added the procedures for the tapegateway, forwardport of the fix for besttapecopyforstream and resetstreams

Fixed: 'assignment discards qualifiers from pointer target type' compilation warning. Also lower-cased the secOn flag to conform to name server variable naming conventions