I've done several fail-tests; the exit program is not being invoked for any
of them and thus no logging is being performed for those fails. Any deeper
testing (beyond doing the SEP and running the FTP commands and watching what
gets called and executed, and when) - well, I'm clueless on how to make that
happen, but certainly open to learning how to do it.
The supervisor/programmer who initiated this can-of-worms was hoping to
avoid contacting the client without more info, but oh well.
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, October 22, 2012 3:03 PM
Subject: Re: FTP logging issue
On 22 Oct 2012 14:23, Tom Hightower wrote:
So, my situation is normal as far as the iSeries FTP server is
concerned? And that's because the FTP server has already decided it
cannot fulfill the GET request (because of the non-existent file) and
thus is not calling the FTP exit program (which would only be logging
the request, in this case)?
That was my experience *as I recall* for both the FTP server and the FTP
client, though I have *no ability* [no system on which] to verify that
effect on any [modern or old] release. So, AFaIK... Yes.
Situation Normal; though whether also AFU, I have no opinion ;-)
I expect that attempts to prove that your exit-program is not being
called for requests [that are either gibberish instead of valid FTP
subcommands or] for which the valid FTP subcommand refers to a non-existent
[or unauthorized] object, will be fruitful; despite the likely
preference\desire being the opposite :-Q I suspect that both a trace and
debug by SEP breakpoint will show that the exit-program was not called for
such requests. I expect that additional testing [beyond just the one
specific GET request] would confirm that the exit-program will not be called
at the request validation exit point whenever the FTP server\client has
already decided that the request should be rejected; i.e. not just because
the object name specified on the valid FTP subcommand request did not exist,
but because a request is gibberish, that the user is not authorized, and
possibly even if the data can not be allocated.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l