Re: SAVSYS to IMGCLG then to DVD on PC

Chuck,

In CHGFTPA it is INACTTIMO(300)
I thought that's what the TIME would change on the Server (didn't think it would matter on Client side, but maybe I also need 
a TIME in addition to the QUOTE TIME   ?
 
Sorry for confusion - I had edited down the FTP log - the actual end was:
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.    
Enter an FTP subcommand.                                 

quit                                                   

I'll add the QUOTE RCMD DSPJOBLOG and see what that reveals.


Neil Palmer, Waterloo, Ontario, Canada


(This account not monitored for personal mail,
remove the last two letters before @ for that)


________________________________
From: CRPence <CRPbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Friday, October 4, 2013 8:13:52 PM
Subject: 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.