Apparently I'm a glutton for punishment tonight

"#" starts a comment in a shell script -- everything from the hash to the end of the line is a comment.

Code:
#!/bin/ksh
#
# Scripts should start with something like the first line -- it tells
# UNIX what shell to run the script with.
#
# It is, of course, also always good to comment your code and put in a
# header comment that tells people what the script is supposedly doing
#
# In particular it is a very good idea to document any parameters that
# might be passed in to your script.  Shell script parameters are numbered
# like so:
#
# $0 = the script name
# $1 = the first parameter
# $2 = the second parameter
# $n = the Nth parameter
# $* = all parameters

DLC=/eis/dlc/91e          # A variable named DLC is being assigned a value.
export DLC                  # Exporting the variable makes it available to
                                # sub shells  -- it does not make it available to the
                                # parent shell.  Note that you export variables
                                # WITHOUT using a "$"; you are exporting the
                                # variable, not its value.

DB=test; export DB       # The ";" ends one command and starts another.
                                 # this allows you to put two commands on one
                                 # line.  It's a very common thing to do with export.

DBSET=testeb2; export DBSET
DBS=/dbs/$DB/prod; export DBS    # The DBS variable is being set based, in
                                               # part, on the value of the DB variable.

# It is generally better to get into the habit of writing this sort of thing as:
#
#   DBS=/dbs/${DB}/prod; export DBS
#
# The braces help to delimit the variable from the surrounding text
# preventing unfortunate naming accidents that might occur if it were
# more like this:
#
#   DBS=/$DBxyz/prod l export DBS
#
# If there happens to be a variable named DBxyz you may not get the
# result that you expect...


BKUP=/backup/prodeb2; export BKUP
SCRIPT=/eis/scripts/backup/$DB; export SCRIPT

# The variables above are probably commonly used in many scripts.  If you
# ever need to change them (like if you upgrade someday) you'll need to
# track them down in a lot of places.  A good way to avoid this is to create
# a standard environment script and to "dot" that script in each your work
# scripts like so:
#
#    . /eis/scripts/progress.sh
#
# Note that there is a space between the "." and the environment script
# name.  This causes the environment script to be executed in the current
# context rather than a sub-shell which allows the variables to be set
# properly and made available to your working script and makes it so that
# you only need to modify them in a single place if something changes.

#EMAIL Stuff
read -r SRCBOX </prod1/dbhname.txt; export SRCBOX

# The "read" command prompts for the value of SRCBOX
# "<" means that the input is being taken from /prod1/dbhname.txt
# If there had been no "<" then the terminal would be the source of input.
# IOW you would need to type a response.

MSG="The Production DBs have been restored to $DBSET on $SRCBOX "; 

# Again the variables inside the string would be better written with ${VAR}
# syntax.

export MSG
EMAIL=' i took this since it has company email addresses'; export EMAIL
# End Email Stuff
echo "stopping database set...."

# The "echo" command writes to the output destination (probably the
# user's screen).

/eis/scripts/startup/stop $DBSET
echo "backing up hard code entries for database set...."
$DLC/bin/pro -b $DBS'1'/$DB'webeb2' -U batch -P bat2run -p $SCRIPT/restprogs/'predel'$DB'.p' >$SCRIPT/predel.out
echo "restoring production to $DBSET database set...."

# Input is being taken from "yesin" which, I'm guessing, is a file containing
# lines of "y".  A better way to do this might be to leverage the "yes"
# command and a pipe like so:
#
#   yes | $DLC/bin/prorest $DBS'3'/'adm'$DB $BKUP/admprod-bak
#
# Also if the backups consist of multiple volumes the "yesin"
# file should contain:
#
#  y
#  volume2-bak
#  volume3-bak
#
# and so forth (with full path names used).
#
# I have a suspicion that this file has all possible extent names for all
# databases and that it is abusing prorests willingness to keep trying
# extents until it finds the right one.

$DLC/bin/prorest $DBS'3'/'adm'$DB $BKUP/admprod-bak </prod1/yesin
$DLC/bin/prorest $DBS'3'/hlp$DB $BKUP/hlpprod-bak </prod1/yesin
$DLC/bin/prorest $DBS'2'/$DB'cateb2' $BKUP/cateb2-bak </prod1/yesin
$DLC/bin/prorest $DBS'1'/$DB'eb2' $BKUP/prodeb2-bak </prod1/yesin
$DLC/bin/prorest $DBS'1'/$DB'webeb2' /backup/webeb2/webeb2-bak </prod1/yesin
echo "Cleaning production data out of $DBSET database set...."

# Running another script -- this script might depend on values that were
# exported above

$SCRIPT/$DB'clean.ksh'
echo "done with $DBSET restore from production"

# This is sending you a message letting you know that (in theory) the
# restore finished but the whole process is missing any serious error
# checking and any positive validation that the work really got done.

mailx -s "$MSG" $EMAIL </prod1/yesin