Fred, Esther, Harvard, Another GSS tape has gone bad. This is the sixth one in 19 months. For the record, in case this happens again at a time when I am away, here is how to make the repairs. This message is stored in sy$seedis:[seedis.gss.programs]howto.rof. The problem is discovered in one of three ways: 1. user complaint 2. automatic mail sent to merrill 3. repeated jobs READGSSTAPE in CSA cluster. To find out which tape number xxxxx is bad, look at csa::sy$cache:[cache]readdgsstape.log.* To find out its backup tape number yyyyy, look in sy$cache:[cache.perm.dbname.ftype.level]series/cod and/or sy$cache:[cache.perm.dbname.ftype.level.series.st]*.cod Get backup tape yyyyy from user tape library, and get a blank tape. In computer center I/O area, mount backup tape yyyyy and new blank on two 6250 tape drives. Log into CSA as SEEDIS, set default to [seedis.gss.programs.mace.tape.new]. Edit tapecopy.com with logical names (eg utape3,utape4) of drives where tapes are actually hung. Make sure of which is input and which is output (one of the mount statements is mount/write) Type "set verify" and "@tapecopy". Job will take 30-60 minutes. You may abort the job if you wish, when copying is complete and scanning of both tapes (for comparison) has begun. Get old bad tape xxxxx from computer center high use rack, and move its paper labels to new tape xxxxx just made. Put a note to this effect: GSS tape xxxxxx, copied mm/dd/yy from backup yyyyy. Internal label yyyyy. Log on to CSA or LBLH as SEEDIS. Set default to [seedis.gss.programs]. Make a new version of batchgsstape.com. There are two places that need editing that will be obvious from old corrections. This is to tell SEEDIS that GSS tape xxxxx has an internal label ("actualtape") of yyyyy. Put a copy WITH THE SAME VERSION NUMBER in both CSA and LBLG/LBLH. Put new tape xxxxx in computer center high use area. Return backup yyyyy to user tape library. Put explanatory label on old xxxxx, and leave on Deane Merrill's desk. Thanks. Deane.