RE: FTP question -- MIDRANGE-L

To add some confusion, perhaps, I think the iSeries is the client in this case. So the inactivity time-out will have no effect, it's controlled by the server on the Linux box. If it were an iSeries server, it'd be possible to change 2 time-outs, both the inactivity one and a so-called transfer time-out. (I just learned of this recently.) Unfortunately, the help for it says that it is not an FTP standard and implemented only on iSeries.

But the good new is, there is a client subcommand, DEBUG, that might be helpful, and it's been around since V3R2. DEBUG 100 turns on an FTP client trace, which results in a spooled file - just executing a DIR got me 44 pages. Probably directly meaningful only to IBM support.

DEBUG non-zero is explained below.

The interesting thing is, you can set the inactivity and transfer time-outs for the client with this subcommand. Default inactivity is 600 seconds, transfer is 420. See below for more information (it's the help for this subcommand). DEBUG T1, e.g., tells you the value of the inactivity time-out.

DEBUG (Enable Display of Commands Send to Remote System)

To display the commands at the remote system, use the DEBUG
subcommand as follows:

DEBug [debug value]

DEBug   You can abbreviate subcommands to the most unique
  series of characters.

Debug value - Toggles the debugging mode.  If an optional
  debug-value is specified, it is used to set the debugging
  level. When debugging is on, each subcommand sent to the
  remote system is displayed, preceded by the string (>>>).
  If the debug value is 0, debugging is off.  If the debug
  value is a positive integer, debugging is on. If no value
  is specified, the debug value is toggled.

  When the debug value '100' is specified, an FTP client
  trace is initiated.  The client continues running the
  trace until DEBUG is turned off or until the FTP client is
  ended.  (When the trace is ended, there may be a
  significant delay while the trace data is formatted.)


DEBUG (To change the client time-out limit values)

This special debug option is provided to enable users to
change the client time-out limits when the default time- out
values are not long enough for a data transfer to complete
successfully. Changing these values should be necessary only
in situations where network traffic or other conditions
cause transfer times to become very large.

FTP client time-out values may be changed using the Debug
subcommand as follows:

DEBug    T1 | T2    [ value ]

T1 - When the first parameter is set to T1, it specifies
     that the FTP client time-out limit for reading server
     replies should be changed or displayed.

     If the FTP client does not return an expected server
     reply within this time limit, the client will close the
     control connection to the server.

T2 - When the first parameter is set to T2, it specifies
     that the FTP client time-out limit used while
     transferring data should be changed or displayed.

     If the FTP client does not receive an expected data
     connection response within this time limit, the client
     will close the data connection to the server.

value - The time-out limit in seconds. This value must be a
        positive number greater than zero.  When this
        parameter is omitted, the current value of the time-
        out limit is displayed.

For example,

       DEBUG  T1 900

sets the client time-out value for server replies to 900
seconds.


hth
Vern

At 07:14 AM 11/4/2004, you wrote:

If there is nothing of note in the FTP server job log, I would probably
CHGFTPA INACTIMO(*LARGERTHANCURRENTVALUE).
John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787  F: +1-312-601-1782
john.jones@xxxxxxxxxx
-----Original Message-----
From: Trevor Perry [mailto:tperry@xxxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, November 03, 2004 4:00 PM
To: Midrange Systems Technical Discussion
Subject: FTP question
I am FTPing to a Linux server from an iSeries batch session.
It randomly fails - we do know it sends only a part of the file.
When we turn on traces on either end, there is never a failure.
The FTP never fails from any other system to the Linux server.
We are on V5R2 and have all the latest PTFs.
Questions:
1) Any ideas of why or how to fix?
2) Anywhere I should start looking?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
This email is for the use of the intended recipient(s) only. If you have received this email in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this email without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. The information contained in this communication may be confidential and may be subject to the attorney-client privilege. If you are the intended recipient and you do not wish to receive similar electronic messages from us in future then please respond to the sender to this effect.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.