Yes ... FTPFD17A did introduce this as a result of an SR which objected to
just the behavior you, and I suspect many of us, took for granted.
Unfortunately, this undocumented "fix" broke a lot of our production jobs,
and we repaired them by ensuring that EXITONERROR is toggled off prior to
an operation which might produce an acceptable error or exception
condition, such as a DELETE on a non-existent remote file, then we toggle
it on, again, immediately afterward.

I haven't investigated FTPFT57A, but I suspect that this 'fix' will not be
reversed -- we'll have to live with it.  If I'm wrong, hopefully someone at
HP will ring in, here.

Lee Gunter          [log in to unmask]




From: Ron Tilby <[log in to unmask]> on 09/21/98 02:27 PM

Please respond to Ron Tilby <[log in to unmask]>


To:   [log in to unmask]
cc:    (bcc: Lee Gunter/BCBSO/TBG)
Subject:  FTP DELETE and EXITONERROR




I updated from MPE/iX 5.5 PowerPatch 4 to 5.5 PowerPatch 5 over the
weekend.
5.5 PowerPatch 5 includes patch:
FTPFD17A  GENERAL FIXES FOR FTP FOR 5.5 PUSH (H Patch).

Many of my current FTP jobs expect that DELETEing a non-existent remote
file is ok, and
not an error.

Now, In FTP if I:
...
EXITONERROR
DELETE <remotefile>

And the <remotefile> doesn't exist, then FTP calls it an error and exits.
What's the "correct" behavior?
Is this change in the behavior of FTP a bug fix, or a new bug?

Does the latest FTP GR patch (FTPFD57A) change this behavior again?

Thanks,
Ron Tilby
Raytheon Aircraft Montek Co.