ackowledge of a request for a VID from RTCPD.  Still a long, long way to go,
but it's a start.

- Moved in checkFileForRepack from oracleStager.sql
- Other minor optimizations

- minor change in startRepackMigration to make a query more clear.
- checkFileForRepack moved to oracleTape.sql.

Fixed default values for logfiles, logkevel, user certificate and user key. Previously, all of the default where empty

the data type of the err field locally.  Thr original data type rtcpErrMsg_t
is defined in file CASTOR2/h/rtcp.h but this file includes function definitions
which are simply not needed.

aggregator.  The reason the tape aggregator will use this local version as
opposed to the original in CASTOR2/h/rtcp.h is the fact that the orginal
contains the following two fields (dgn and server) which are not used in
marshalling and unmarshalling, but are used to store the internal state of RTCP
clients and servers:

vi CASTOR2/h/rtcp.h

    176 typedef struct rtcpTapeRequest {
    ...
    180     char dgn[CA_MAXDGNLEN+1];
    ...
    183     char server[CA_MAXHOSTNAMELEN+1];   /* For client use only */
    ...
    208 } rtcpTapeRequest_t;

I personally like to keep my message structures and their contents
separate from variables used only to store application state.

However, the code has to be reviewed in order to reuse the AbstractTCPSocket class.

Cleanup functions: added check for existence of data after FETCHs before trying to access them, simplified some WHERE clauses

fixed rtcpclientdCleanUp to reset the tape in the streams to NULL and not 0, in order to not break a potential constraint on the tape id

Detect the new error ENSNOSEG in replacetapecopy and 'ignore' it, since there is nothing to migrate anymore

New message in case of a repack migration failing because the original segment has been dropped in the mean time

Incresed the number of RTCPD handler threads as it looks like (I maybe wrong) that RTCPD wants to connect once per DISK IO thread in order to get the next file to be migrated/recalled

This class now needs to be fleshed out.

connections from the VDQM and one for listening to connections from RTCPD.

Two ports are required because of the major differences between the VDQM and
RTCOPY prototcols.  In the case of the VDQM protocol, the tape aggregator
should listen, accept and then read in an incomming VDQM message, in other
words the magic number, request type, message body length and finally the
message body.  In the case of the RTCOPY protocol, the tape aggregator should
listen, accept and the send as opposed to read in a message.

added in getFilePath the logic to skip the files which were deleted in the nameserver during a repack process.