On 04 Oct 2013 18:00, Neil Palmer wrote:
In CHGFTPA it is INACTTIMO(300)
Hmmm... That makes the origin of the apparent 75 minutes, as the
timeout being experienced, all the more confusing.
But then... the RMVLNK is said to take ~75 minutes; i.e. "I'd need
about 75 minutes for the RMVLNK to complete." That, along with my
further review of the described processing and described failure, and
with some testing of effectively equivalent [in time] processing, I am
confident the issue encountered will be resolved by including in the
processing, the following two FTP requests at the beginning of the
script [before or after the QUOTE TIME 7200]. Note: the second request
is the implementation of a circumvention to a defect [APAR SE27332; link
in my prior reply] that may or may no longer exist, but causes no harm
if included:
DEBUG T1 7200
PWD
The remaining comments are for the archives to further understand my
presumptive conclusion, and to provide specific responses to additional
remaining comments in the quoted\replied-to message.
I thought that's what the TIME would change on the Server
It is. The "QUOTE TIME <inactivity> <transfer>" invocation should
override the inactivity-timeout and the transfer-timeout, in seconds, at
the server.
(didn't think it would matter on Client side),
Correct. The QUOTE TIME is only relevant to the server.
but maybe I also need a TIME in addition to the QUOTE TIME ?
There is no client TIME subcommand :-( Achieving the same effect on
the client, is effected via the less obvious "DEBUG T1 <inactivity>"
request; i.e. sets the inactivity-timeout, in seconds, at the client.
Along those lines, I wondered /aloud/ in my prior reply, if perhaps
adding the FTP subcommand request to DEBUG T1 7200 would provide relief;
albeit, possibly requiring the circumvention from the APAR, which is to
follow the DEBUG T1 request with the PWD request. I will explain below,
why I think this client-side inactivity-timer may be the source of the
problem, and thus *enabling resolution* to the issue being encountered.
Sorry for confusion - I had edited down the FTP log
Yet I should have recognized, having seen the text "Enter an FTP
subcommand." at each step, that the FTP was being performed
interactively. Of course *now* it is obvious to me :-)
FWiW:
Normally there is a "220" prefixed feedback message TCP12AF from the
IBM i as FTP server, presented in the client session _upon_ connection,
that identifies the inactivity-timeout per "Connection will close if
idle more than ?? minutes." Do these connections say "5 minutes.",
reflecting the INACTTIMO(300)?
Additionally, the request to QUOTE HELP should divulge the inactivity
timer setting that the server has established. The feedback comes in
one of many messages TCP12AF with "214-" prefix that reveals the
inactivity-timeout in seconds: "If this connection is not used more than
???? seconds, the session will end."
Finally, the DEBUG T1 without any argument passed for the
inactivity-timer, will feedback TCP3CA8 "Client T1 time value set to ???
seconds."
- the actual end <ed: of the interactive FTP session> 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.
The "250" prefixed TCP12AF messages are an indication that the server
had received and supposedly had activated the requested override, in
this case, to both the transfer-timeout and the inactivity-timeout. As
noted above, the QUOTE HELP should reflect that change in its feedback.
However, noting the oddity of the referenced APAR\defect [from my
prior reply], and its circumvention, I wondered /aloud/ also, if perhaps
issuing the FTP subcommand PWD, after the QUOTE TIME 7200 7200, and
before passing the next QUOTE text to the server... might be required to
circumvent a similar issue whereby the feedback from the server was an
effective lie; i.e. perhaps the override does not go into effect unless
the first request after the QUOTE TIME invocation is *not* another QUOTE
subcommand. I have since decided that was just a misguided inference,
based on my concentrating too much on the ~75 minutes as an /apparent/
timeout at the /remote server/ instead of understanding what is really
happening; i.e. the timeout was distinct from the ~75 minutes for the
QUOTE RCMD RMVLNK to complete. Again... explained later\below in my reply.
While testing on a v5r3 system, with a variety of chosen server
inactivity-timeout values, I would follow the QUOTE TIME with some QUOTE
RCMD DLYJOB seconds_value requests [rather than using RMVLNK] to verify
that the inactivity setting was being honored. To minimize time
requirements for any individual test-case, of course my choices for the
seconds_value were /smallish/ rather than something like 100+ minutes.
But I had noticed some longish tests with QUOTE RCMD DLYJOB 600 that
would experience an occasional failure: TCP3C6B "No response from remote
host; all connections closed." In each failing scenario however, the
server request actually completed, irrespective my inference of the
meaning for that message; i.e. my interpretation was that the /remote
host/ had closed the connection. The message says however, that the
problem was due to no response being "received from the remote host
within the timeout period." Thinking on this...
I recalled never having experienced overrides to the server's
inactivity-timer being non-functional [through v6r1]; i.e. never having
received an unexpected timeout, after issuing the QUOTE TIME to avoid a
timeout. I often had performed long and complex processing in FTP
scripts having issued an earlier QUOTE TIME request, usually somewhat
long-running CALL PGM() requests via FTP subcommand QUOTE RCMD requests
in my scripts, after which the parsed\reviewed standard output revealed
no errors were encountered. But after additionally reviewing some
documents from some web searches, in conjunction with results of my
recent testing, I have concluded that I must have always included the
client-side timer update [i.e. "DEBUG T1 inactivity" requests] when
using homogeneous FTP. I apparently had forgotten about using that
client-side request, probably because I typically just copied from a
base-source and since for several years, my only FTP work to an IBM i
server has been from non-i clients... apparently those clients have a
sufficiently long client inactivity timeout setting, that I had not
noticed an issue.
Enter an FTP subcommand.
≥ quote rcmd rmvlnk '/asp02/virtualtape/VOL001'
No response from remote host; all connections closed.
I am fairly confident that what happens, as I infer... Rather than
the long-running request at the server having been diagnosed as
exceeding its inactivity timer and thus the connection being closed,
only after control returns to the client from the QUOTE RCMD request,
the client detects that its own inactivity-timer has been exceeded.
Then the client closes the connection, but diagnoses the effect the same
as if the /remote host/ had terminated the connection; a somewhat
confusing effect, for a timeout at the server versus for a timeout at
the client... being indistinguishable.
It would be nice, for example, if there were two messages used
instead of just the one TCP3C6B. Perhaps one would suggest that the
issue was per "No _response_ was received _from_ the remote host within
the *client inactivity* timeout period." Perhaps another would suggest
that the issue was per "No _request_ was received _at_ the remote host
within the *server inactivity* timeout period." Or perhaps the text of
that message could be expanded to be explicitly clear that there are
*two* inactivity timers that may have effected the closed connection,
and in the recovery, to show the syntax for setting both timers.
From what I can infer from my testing, the RMVLNK will have completed
irrespective of where there is an inactivity timeout; client or server.
It seems that a long-running request is not terminated by the
inactivity-timer at the IBM i FTP server. Instead it seems, only a
delay _between requests_ reaching the server will effect close of the
connection; i.e. a delay that exceeds the inactivity-timer setting for
the server. I was actually under the false impression that the timer
would terminate the active request at the server... and the joblog would
show the request being interrupted. And unlike some other FTP clients,
the IBM i client seems not to terminate the connection until the control
returns from a QUOTE subcommand; i.e. even with a very small client
inactivity timeout, the IBM i FTP client will allow the server to
continue processing whatever active request that was sent via the QUOTE
subcommand.
Enter an FTP subcommand.
≥ quit
I'll add the QUOTE RCMD DSPJOBLOG and see what that reveals.
Regardless of what may have seem implied by my prior reply... That
request can not assist; it will not function in _this_ scenario :-(
Apologies for having shown that particular request in my prior reply,
instead of PWD or something else. It was just meant to be any request
that would appear before an EOF was encountered, and something before a
QUIT, just in case that did not appear in the stdout... but that is all
moot, because this was not a scripted request [my misunderstanding,
whereas instead, it was an interactive FTP session].
The /connections closed/ implies that there is no ability to send any
more requests via that session; i.e. QUIT is possible to terminate the
FTP client session command-line, and the OPEN could be issued to start a
new session at the server, but no further request that communicates
to\with the server will be possible within that client session. Either
the documented CHGJOBD request would need to be done to force logging to
occur, or perhaps early in the session, having issued the request to
QUOTE RCMD CHGJOB LOG(4 0 *SECLVL) would be similarly effective.? The
latter seemed not to assist in my testing... and I do not have the
required authority to activate the logging via the job description on
the system where I test.
midrange.com
