It's fairly well documented that MOVE DRMEDIA will execute CHECKOUT LIBVOLUME under the covers to make "safe" any copypool volumes and DB backup volumes that are allegedly on their way off-site.
Is it documented anywhere if MOVE DRM will execute CHECKIN LIBVOL commands? At the root of my question is a discussion several of us are having at work. We're painfully aware that in some TSM 5.5 and TSM 6.1 levels, there's a deadlock related to DELETE VOLHISTORY fighting with LABEL LIBVOL. As we run with our virtual tape libraries set for RELABELSCRATCH=YES, we sometimes see an nearly spontaneous LABEL LIBVOL as volumes are released from storage pools or are no longer needed as DB backups. What's less agreed upon is whether we have to check in the returning volumes before executing a MOVE DRM FROMST=VAULTR TOST=ONSITER to trigger the bug or not. One colleague is adamant that MOVE DRM will find -- and relabel -- a volume that's sitting in the VTL even if it doesn't show up in a QUERY LIBVOL before we do the MOVE DRM. My own expectation is that if we do the MOVE DRM command before the volumes are checked back in the library, the automatic volume relabeling won't go on its own. Because the price of failure is a TSM server hang, we're a bit leary about playing with different permutations until we map out the various scenarios and outcomes. But, if we can convince ourselves that in some cases, MOVE DRM doesn't trigger an implicit LABEL LIBVOL if a library is set for RELABELSCRATCH=YES, we could return to checking in our "off-site" volumes and then, say, running manual LABEL LIBVOL OVERWRITE=YES to have the same effect. So, does anyone know about safe or unsafe sequences of MOVE DRM with or without CHECKIN LIBVOL when a library is set for RELABELSCRATCH=YES? Thanks, Nick