Well DRAT! Here is my problem. We have no control over the various FTPS clients out there and what they THINK they should send in explicit SSL mode. Two Windows clients I am testing always insist on sending PBSZ 0 and PROT P at the start of EVERY command sent to the server, even though the channel was already secured with PROT P at the start of the session. The redundant PROT P's get RC 503 BAD COMMAND SEQUENCE and terminate on that error (and these particular clients can't be configured to ignore errors, they stop on ANY error). I expect others users will also run into this problem. It would be REALLY handy if the FTP server config file could have a user setting to tell it how to handle redundant PROT P's: Extra_PROT_P = IGNORE /*Ignore redundant PROT P if the data channel is already secured, exit on 0*/ Extra_PROT_P = REJECT /*If PROT P fails because data channel is already secured, Exit on 503 as usual*/ Back to the drawing board for me I guess.............. :( Thanks for the quick response Miguel - much appreciated. -Mike
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Miguel Delapaz Sent: Wednesday, November 19, 2008 1:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTPEXIT Question Mike, The return string is used to send a message back to the client when the exit rejects a command (and only if you set the return code to 4 or 12). It will reject the command with a "502 <return string>". There is no mechanism for modifying the command that gets sent to the server. Regards, Miguel Delapaz z/VM TCP/IP Development The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> wrote on 11/19/2008 10:24:42 AM: <snip> > I know this code is executing because I see my FTPEXIT: RetMsg on the > console, but the FTP Server is ignoring my RETSTRING (NOOP) and still > attempting to execute PROT P. > > What am I doing wrong here? Should I be using a RETURN_CODE other than > 0 to indicate that FTP should evaluate my RETSTRING? > > I'm confused.............. :( > > -Mike
