Actually, why not continue using the same method already in place?  There's
nothing inherently different between the two platforms that would require a
change -- only your operations preferences (and control) for managing the
inventory.  There is (currently) no feature to "protect" one storage pool
(or
TSM server) from tapes with undesired characteristics -- like a vol-ser
filter.  See page 47 of the TSM 4.2 Admin Guide for Windows.

Instead of multiple devclasses, you could use multiple library
definitions -- one for long tapes, one for standard length;  then, you'll
checkin long tapes to the "long tape" library, etc.  This would be *one*
solution... which uses scratch tapes.  Using this solution, the operators
are trained to be watchful of which tapes are checked into which library;
the downside being you'll need to coordinate sharing the drives between
the two libraries -- else, undesired waits for a (common) mount point could
occur.

A third solution, not yet available, would be to exploit a feature which
restricts
certain vol-ser patterns to a specific pool (or server  or application);
there is
a known problem with shared-3494 where an operator inserts tapes into
the i/o area, then, before the operator can coordinate with the intended
server, another
server "notices" the collection of tapes with "insert category -- FF00" and
allows *any*
application to check them into the library... then it's up to the
application to accept a
given tape or not, and TSM currently accepts *any* tape assigned the insert
category.

Regards,
Don