× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks Chuck.

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.

Tom


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, October 22, 2012 3:03 PM
To: midrange-l@xxxxxxxxxxxx
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.

Regards, Chuck
--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.