The tricky part is that, AFAIK, EXITONERROR is an MPEism (if this is
otherwise, please let me know). If it is an MPEism, then there is no
analogy, no convention to appeal to for what is "correct". Why this even
matters is that if you can DELEte a file, you can also overwrite it even
on non-MPE hosts, AFAIK. So what is the difference between deleting and
not, should something fail? If the job fails completely, then you still
have yesterday's file. If you do not explicitly delete, and the send /
put fails, you still have yesterday's file. Only in the case that you
explicitly delete, AND the send fails, do you have a different result of
no file. So, what does the DELEte actually achieve? Only if someone (a
person, not a process) might pick up yesterday's file is this a problem.


I had the pleasure of discussing this for a production issue; our job to
monitor a remotely initiated ftp checks the date (so we use the
TODAY.XEQ command file that Tim Ericson provides on his site to get
yesterday's date) to see if we got the file by an anticipated cutoff, as
a separate mechanism from processing this file. Another party insists on
deleting all sent files before sending the first one, so I had to code
around the third possibility that the file may not exist. In our
context, someone manually picking up yesterday's file is extremely
unlikely; unfortunately, it is not impossible.

I like the idea of turning on EXITONERROR after the delete. OTOH, we
send a single file per job for recoverability. We have several ftp
jobs... It also seems that our ftps are saturating our connection, so
that there is no benefit to concurrently sending files, and are
concerned that doing so would only increase the possibility of failure.