The volhist TYPE=REMOTE entries are created when a library client requests a scratch tape and the library manager changes it to status=private and creates this REMOTE entry with LOCATION of the owning instance name. It doesn't have anything to do with MOVE DRM. There is a TYPE=REMOTE for every volume in a library clients inventory in the library manager volhist. Whether checked in to the library or not. This is what prevents you from bringing back a tape and checking it in as scratch.
I have found another way to create a REMOTE entry. If you make sure there is no REMOTE entry, check out the tape from the library manager libv and then from the library client run an AUDIT LIBR CHECKL=B. This will create a REMOTE entry on the library manager. Then you can check that tape back in. You don't mention what you mean by "stuck" volumes. The only way to checkout a tape from a library client is via MOVE DRMEDIA or MOVE MEDIA commands. They communicate with the library manager to eject the tape. Not create or modify this REMOTE entry in the volhist. The full syntax of the del command is del volhist type=remote volume=xxxxx tod=+0 force=yes These are undocumented options to the command. Bill Boyer -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Josh Davis Sent: Thursday, August 16, 2007 6:30 PM To: ADSM-L@VM.MARIST.EDU Subject: Library manager still shows REMOTE I've seen a few hits where the only fix was to DELETE VOLHIST TYPE=REMOTE FORCE=YES but where it was never identified HOW the volumes got stuck. I found one way at my customer site. MOVE DRM notifies the library manager that the volume is TYPE=REMOTE. The LOCATION is filled with the servername. If you SET SERVERNAME on a library client AFTER it's already moved DRM volumes offsite, there is no way to refresh the LOCATION on the library manager. AUDIT LIBR doesn't work because it's not in the library. UPD VOLHIST won't update location on a REMOTE volume, though it will say the command completed. Preemptively deleting the volume history can be a problem too, so manual handling is the only way out. I've got a PMR open to see if UPD VOLHIST can be enhanced with FORCE=YES also, or otherwise to allow REMOTE volumes to have location updated. -Josh-Daniel S. Davis Certified TSM Implementor CATE AIX/pLPAR