I know of a number of organizations that "clean" tapes prior to placing them back into a scratch tape pool. This way the tapes are free of any pre existing data.  The cleaning process can be done in low volume using a mainframe job or if you have a large number of tapes there are companies that will "clean" the tapes for you in bulk.

As a general rule, you should have all tapes "cleaned" before placing them in the scratch pool. Adding a cleaning step to the tape operators duties would be rather easy. The tape operator boxes up tapes that need to be cleaned and shipped them to a vendor once a month and fills the scratch pool with tapes that have been previously cleaned.

Additionally there are tapes that will be returned to the scratch pool when space reclamation job is run.  This reclamation job moves data from tapes where only 20% (defined by system operator) of the tape is filled with active data to new tapes.  The process frees up valuable slot space in the robotic tape systems, but generates tapes that need to be cleaned.

Another problem with mainframe tapes has to do with Virtual Tape.  These "cool" technology creates a file on hard disk that represents a tape. After a certain period of time these tape files are written out to a large tape.  These tapes now have the images of potentially hundreds of virtual tapes written on them. The idea behind this tool is to improve processing speed by caching heavily used or recently created tape on hard disk and then moving them off hard disk to real tape once the probability of retrieval has dropped below a certain threshold.

Another problem area is optical disk and mainframe.  Mainframes often treat optical disk as another form of tape.  Since optical cannot be reclaimed then you run into many of the same expiration issues.

This problem applies not just to mainframe tapes but to all tapes used on different platforms.  There are tools like IBM's Tivoli Storage Manager which started out life as a mainframe product and has since been rewritten to run on UNIX and Windows.  You will run into similar scratch pool issues on these other operating systems.





Tom Utiger

Data Empowerment Group
[log in to unmask]
D +1 (702) 505-9978
O +1 (702) 289-4230
F  +1 (702) 446-0302

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]