When running CTSSYNC EJECT for SMS Managed Virtual tape, CTSSYNC ends with RC=0 even if the the LWORM tape is NOT EJECTED.
Why doesn't it get a different RC?
ca1
When you do an “EJECT” on a virtual-volume in an IBM VTS (using the CTSSYNC utility). First, it depends on the status of the virtual-volume. If the virtual volume is in SCRATCH status (also called Fast Ready category) – the virtual-volume is deleted from the Library Manager. It may or may not be deleted from the TCDB/Volcat (depends on their option settings). If the virtual-volume is in PRIVATE/ACTIVE status, the virtual-volume is NOT ejected from the library.
In both cases, CTSSYNC will end with a RC=00/RSN=00. This is because when CTSSYNC calls the IBM OAM service; the service simply is coming back and saying the volser is valid and has been queued to be ejected. The actual process is done later by OAM. If you attempt to eject a private/active virtual-volume with CTSSYNC it ends with RC=00. A few seconds later, there will be two console messages issued;
CBR3650I - EJECT OF VOLUME VVVVVV FROM LIBRARY XXXXXXXX FAILED.
CBR3726I FUNCTION INCOMPATIBLE ERROR CODE 06 FROM LIBRARY XXXXXXXX FOR VOLUME VVVVVV.
Again, these are console messages issued from the OAM address space and are not part of the CTSSYNC job. CTSSYNC simply put the request into the queue for OAM to process; and that worked just fine.
NOTE: If the eject command is issued for a volume that is NOT defined within OAM (not defined within the VTS library itself), the CTSSYNC will end with a non-zero return (RC=04) indicating that the volume is not defined to OAM.
If the client wants a non-zero return code for non-scratch virtual-volumes that were ejected; they need to contact IBM and ask the CBRXLCS services be changed to return a non-zero return-code/reason-code under these conditions.