Hi listers,

Yesterday we ran into a problem at a customer site that could have
potentially been disastrous, but fortunately was just a major scare, and a
minor inconvenience. By telling this "tale of woe" I hope to prevent
anyone else from ending up in the same predicament.

The system administrator was going to duplicate a backup tape using
TAPECOPY (many thanks to Lars Appel and Kevin Miller for this fine
utility.) TAPECOPY was installed into a group that was on the HPPATH and
the user did a HELP TAPECOPY to make sure there wasn't a conflict with
corresponding UDC. The user was running MPEX at the time and MPEX reported
that HELP TAPECOPY was the program file TAPECOPY.GROUP.ACCOUNT. Everything
looked good, the tape was mounted and the command TAPECOPY TD was entered,
which is supposed to read the tape and create a single disk file
containing all of it's contents.

This is where things got a little weird. The resulting output to $STDLIST
of the TAPECOPY command was a LISTF TD,2. Shortly thereafter some users
noted that their programs were aborting. Investigating the problem we
found an MPEX command file named TAPECOPY.CMD22.VESOFT that was executed
rather than the TAPECOPY program that the user wanted. The command file
does not copy a tape; it performs a FULL RESTORE OF EVERY FILE ON THE
TAPE! And redirects the output to a flat file so the user doesn't even
know it is happening.

Fortunately in this instance the backup tape was several years old, and
due to application changes no production data files were overlaid; just a
number batch jobs, programs, and source files. With a moderate amount of
effort we were able to remove all of the files that were unnecessarily
restored, and put back the files that had been overlaid. Had the tape been
a more current backup the results could have been catastrophic. And if not
for the quick thinking of the system manager to realize that the problems
started after using the TAPECOPY command it may have been quite some
before anyone know what had transpired.

Several lessons were learned during this episode:
- Could have used %WHEREIS TAPECOPY instead of %HELP TAPECOPY
- Could have fully qualified the command.
    %RUN TAPECOPY.GROUP.ACCOUNT;INFO="TD"  instead of %TAPECOPY TD
- Could have run it outside of MPEX.
- Could have ....

It does concern me that VESOFT includes a command that IMHO appears to be
inappropriately named, does not provide any help, and silently restores an
entire backup tape without any notification to or confirmation from the
user. The customer is going to contact VESOFT and suggest they either make
this command a bit more visible or require confirmation.

Perhaps the whole situation could have been avoided, but I can honestly
say that had it been me I wouldn't necessarily have done anything
differently. As I said in the beginning, hopefully this will help someone
avoid a similar mistake.

Doug.

Doug Werth                             Beechglen Development Inc.
[log in to unmask]                               Cincinnati, Ohio

PS. Here are the contents of the file for anyone who is interested.

%print tapecopy.cmd22.vesoft
PARM INDFILE=VEINDIR, [log in to unmask]@.@, LIM=9999
COMMENT
COMMENT This command will restore a fileset from tape (using ;CREATE)
COMMENT and build an indirect file called !INDFILENAME that you can
COMMENT then pass to STORE to make copies of the tape.
COMMENT
comment Save and reset file eq (SYSLIST might be there)
many %filter listeq,'FILE';start=3>veeq  %reset @
many %:PURGE !INDFILE>$NULL %BUILD !INDFILE;REC=-26,,,ASCII;DISC=!LIM
many %SETLVAR VESOFTDEFAULTPRINT ""  %SETLVAR VESOFTDEFAULTALTFILE ""
%filter "RESTORE;!FILESET;CREATE;SHOW",R MATCHES "@#@" AND R[8:1]=".";&
       FORMAT=STRCHANGE(R[0:26]," ","");OUT=(!INDFILE,OLD)
veeq
many %ALTFILE !INDFILE;SQUEEZE  %LISTF !INDFILE,2