On 04 Oct 2013 13:27, Neil Palmer wrote:
Increasing the timeout value did not prevent the FTP connection
timing out while the RMVLNK command was running (approx. 75 minutes):
Enter an FTP subcommand.
≥ quote rcmd LODIMGCLG IMGCLG(VIRTUALTAP) OPTION(*UNLOAD) DEV(TAPVRT01)
250 Command LODIMGCLG IMGCLG(VIRTUALTAP) OPTION(*UNLOAD) DEV(TAPVRT01)
successful.
Enter an FTP subcommand.
≥ quote time 7200 7000
250-File transfer time-out value set to 7000 seconds.
250 Inactivity time-out set to 7200 seconds.
Enter an FTP subcommand.
≥ quote rcmd rmvlnk '/asp02/virtualtape/VOL001'
No response from remote host; all connections closed.
What is the Inactivity timeout (INACTTIMO) for the FTP server?
Perhaps it is 4500? IIRC, the current value\setting should appear in
the following command-line invocation:
CHGFTPA ??INACTTIMO()
My first thought... That seems to be a probable FTP server problem.
I would probably follow the /Troubleshooting File Transfer Protocol/
instructions both to get a spooled joblog of the FTP server job and
probably a server trace [e.g. by having included sending the FTP
subcommand DBUG to the server, or possibly TRCTCPAPP]:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzaiq/rzaiqlogserr.htm
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzaiq/rzaiqtraceserver.htm
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzaiq/rzaiqjoblog.htm
Most interesting IMO would be if a joblog reveals that the Remove
Link request was actually interrupted [early; at 75 minutes vs 120] or
that the RmvLnk request completed within the 75 minutes but the client
script never continued with its next request; e.g. such that the EOF is
the implicit QUIT subcommand. Per earlier information, apparently there
was no next request, just EOF... so the script could be changed to add a
request after the RMVLNK to emphasize there was no apparent hang at End
Of File; e.g. adding these two requests:
QUOTE RCMD DSPJOBLOG
QUIT
However, interestingly... There is [or was] apparently a known
defect with the respective _client_ timeout settings [both /inactivity/
and /transfer/ time-outs] not being established for the next request if
that next request is [passed to the server directly with] the QUOTE
subcommand. That raises two interesting possibilities. One... the
_apparent_ server timeout [i.e. "No response from remote host"] could
have been manifest as a result of a client timeout.? That seems
unlikely, because the apparent default is 600, not 4500. Two... a
similar issue could exist for the establishment of the TIMEout setting
at the server... and perhaps adding the PWD subcommand after sending the
TIME request would similarly ensure the timeout update goes into
effect.? That defect:
APAR SE27332 /* no explicitly noted fixed-in release */
Abstract: TCPIP FTP INACTIVITY TIMER NOT WORKING PROPERLY
http://www-912.ibm.com/n_dir/nas4apar.NSF/c79815e083182fec862564c00079d117/c8c95a18d7f55fc88625721f00421ad0?OpenDocument
"...
_Problem Summary_
iSeries FTP client inactivity timeout is set via DEBUG T1 subcommand.
When running the command, followed by a QUOTE RCMD, the client timer
does not take effect. However, if running a command prior to the QUOTE
RCMD, the client timer will work.
_Problem Conclusion_
The new timeout is not being updated until after the next read to the
server is completed. ...
...
Status: CLOSED UR1 <ed: UR1=fixed in an unstated *future* release>
..."
If that T1 inactivity setting is updated in a revision to the script
[e.g. in an attempt to prevent the current timeout issue, perhaps per
the first of the above two /possibilities/ alluded above], then likely
best also to implement the circumvention in that APAR; i.e. to issue a
PWD subcommand, after a request to "DEBUG T1 value", because there is no
documented release in which that defect was\if-ever corrected.
midrange.com
