×
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.
On 22 Oct 2012 15:31, Tom Hightower wrote:
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.
If I were confident of my use of SEP, then I would not spend much
more time. Lacking confidence however, I would trace two requests
within a session where the user is allowed to use RCMD; one request for
which the exit-program is known *not* to get invoked and another request
for which the exit-program is known to get called. I do not recall what
effect the DEBUG 100 has, with regard to the "trace" produced by FTP, so
I would probably [first or just instead] use a job trace:
noop previously logged in to this FTP server job
quote rcmd ovrprtf *prtf splfown(*curusrprf) ovrscope(*JOB)
usrdta(nocall)
quote rcmd trcjob *on
get qrecovery/notexists.whatever
quote rcmd trcjob *off
noop resetting connection here though should be optional
close
open <systemname>
noop log in here same as earlier
quote rcmd ovrprtf *prtf splfown(*curusrprf) ovrscope(*JOB)
usrdta(called)
quote rcmd trcjob *on
get qsys2/qsqptabl
quote rcmd trcjob *off
A review of the first Trace Job output should show that the exit
program was never called; just search for the exit program name. Note:
the TRCJOB invocations shown are very old syntax for tracing a job, so
adjustments may be required for each of start, stop, and spooling for
the trace activity. Review of the second Trace Job output would show
the exit program being called along with from what OS TCP\IP FTP server
program. And that same initial "flow" in both traces can be reviewed
and contrasted for how the exception processing effected a code path
that can be inferred to have bypassed calling the exit-program in the
first but not in the second.
Note: STRSRVJOB and the trace requested against the QTFTP* job(s)
from another [interactive] job is acceptable instead. I just default to
do the work within the specific FTP server job... just as I might effect
trace within my interactive job rather than starting another job to do so.
midrange.com
