Been there done that. Buy new barcodes, with a different series of VOLSERS for your *X TSM server. Petty cash.
When the tapes go scratch eject them and replace the bar codes. Put them back in and tell the *X TSM server to rewrite the internal label to match the new bar codes with LABEL LIBV command. I know you said you don't want to do that, because of the labor. BUT, you can do a few at the time. And you'll be happier (and safer) in the long run. Small pain now, big benefits later. You won't ever have to worry about tape confusion. You don't have to change your CA-1 exit. You don't have to worry about updating the TMC, or even about getting the entries out of OAM. BUT, if you want do do those things, you can do so easily: -Set up a batch job that runs TMS DEL on ALL tapes in the range every night. It will kill off any that go scratch, but none that still have valid data. -Change your library settings in ISMF. There is an option (EJECT=PURGE) that tells OAM to automatically delete the OAM data base entry when the tape is ejected. Hope that helps, even if it isn't exactly what you wanted.... -----Original Message----- From: Thomas Denier [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 9:49 AM To: [EMAIL PROTECTED] Subject: Migrating 3590 tapes from OS/390 to Linux or Unix We are currently running a 5.1.7.2 server under OS/390 and are looking into the possibility of migrating to a mainframe Linux server. The Linux server would share our existing 3494 tape library with the surviving OS/390 workload. As TSM workload shifted from OS/390 to Linux we would need to shift 3590 scratch tapes from OS/390 to Linux. We have so far of two possible approaches, each with some ugly features. We are wondering how other sites have handled this type of migration. We use the CA-1 Tape Management System. Both approaches mentioned above depend on modifying our cartridge entry exit to prevent it from laying claim to volumes marked as deleted in the CA-1 database. Both approaches call for updating the CA-1 database to mark departing scratch tapes as deleted. The two approaches diverge when it comes to getting the departing scratch tapes out of the OAM database. One approach would simply eject the tapes. When the tapes were reinserted OS/390 would not claim them, and subsequent 'checkin libvol' commands on Linux would claim them. This approach involves a lot of labor, some risk of damage to tapes (especially the 3590 K tapes), and some risk of confusion between tapes intended to go to our offsite vault and tapes intended to go back into the 3494. The second approach would use IDCAMS 'DELETE VOLUMEENTRY' commands to remove the OAM database entries. Subsequent 'checkin libvol' commands would claim the tapes for the Linux server. This approach involves an end run around the normal mechanisms for managing a database. We generally get very nervous about that sort of thing.
