Fix for bug #86639: Timeout should be extended when retrying to gather queues at the start of diskmanagerd. Actually, a fixed timeout of 300s is used, and no retry.

Fixed bug #86557: in case of failure, the dispatcher module of the transfermanager creates inconsistencies. It actually called serverqueue.remove with wrong arguments

Done.

Added need lock on new XMI (although it should be now patchable).

Separated the xmi of tape gateway protocol from the one of the rest of castor.
Adapted the wrapper to handle the case where there is no DB schema gemeration from the XMI.
Removed old structure (RepackFileQry) which was not in XMI anymore (and not referenced).

Implemented -q option of listtransfers, allowing to list pending transfers from the transfer manager point of view, without contacting the diskservers

Done

Ignore filesystem and diskservers that are marked DISABLED in the DB. This will in particular avoid that listtransfers spends time trying to contact them

Fixed bug #86421: disk to disk copy and concurrent stager_rm lead to inconsistencies. Note that there were 2 bugs. One in the case of a running d2d copy and another one in the case of a pending d2d copy

We will skip the 0xB6 command (SEND VOLUME TAG) for Spectra like library as soon as it is not supported.
This makes smc_find_cartridge function work much faster.
A variable "SMC LIBRARY_TYPE SPECTRA" in castor.conf will switch the logic.

The Virtual tape library also does not support 0xB6 so this fix is good for it too.

Done.

Fixed.

Small fixes for CDB commands to work correctly with Spectra library and  mhvtl.
As soon as a Spectra library and Virtual Tape Library are close loop libraries it was added special vriable to castor.conf to switch to this logic.
Right now it is just a fix for human presentation of loaded drives.

Also was fixed incorect error handling for 0xB6 CDB command.

Improved syntax do that it works with Python 2.4.3 which is the version installed on the CASTOR development boxes.

I incorrectly assumed the "no more work" file entry in the list of files to be
migrated had the same tape-file sequence-number as the last file written to
tape, in other words the file just before the "no more work" file entry.

be different in two different places.  I have now replaced the K and R
declaration with a compatible Ansi C version.

rfio/lun2fn.c:33: error: ‘char* lun2fn’ redeclared as different kind of symbol
rfio_api.h:239: error: previous declaration of ‘char* lun2fn(int)’

Arranged files to be compiled into alphabetical order as the list is getting too long to easily to find individual files by eye.

Added missing positionCommandCode member to BaseFileInfoStruct.

Added new bulk messages to RH.xmi and auto-generated the associated classes.  Please note that there is no graphical information in RH.xmi concerning the new messages because gencastor went mad and changed the order of the members of existing classes.  We now add new content manually for readablility, sanity and maintainability.

Fixed.

Fixed bug #85869: incomplete listtransfers -p output with 'Caught exception : need more than 3 values to unpack'

The cancelRecallForTape procedure has been extended to also change the status of the tape involved in the
DB. This will prevent rtcpclientd from looping on the vmgr.

The procedure cancelRecall has been made safer in the process as in some (unusual, but possible) cases, it would have killed migrations too, if any.

Improved comments within the example castor.conf file.

Added assertions to tapebridged that check the tape-file sequence-number of
the flush messages from rtcpd.

Added missing setObjType(castor::OBJ_TapeAccessSpecification) to the method
named castor::db::ora::OraVdqmSvc::selectTapeAccessSpecifications().