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:Thomas.Denier AT MAIL.TJU DOT EDU]
Sent: Tuesday, October 14, 2003 9:49 AM
To: ADSM-L AT VM.MARIST DOT EDU
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.