Re: SAVSYS to IMGCLG then to DVD on PC

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.