On 15-May-2017 09:08 -0600, Versfelt, Charles wrote:
I'm having an issue doing FTP, we're using a method we've used in
the past.
Source file contains the script and the log goes to a second source
file. I changed some of the names but left the rest the same.
Some suggestions were made [about what to change] to progress, but I
noticed few clarifications were given about how the IBM i FTP client
functions in the given scenario, to understand better, the reason for
the failures.
FTP command in CL program:
FTP RMTSYS('SYSNAME.HOSTEDFTP.COM')
The above request implicitly issues the "OPEN" FTP subcommand, i.e.
OPEN SYSNAME.HOSTEDFTP.COM, upon initialization of the FTP client
session. Having named a Remote System/Server on the Start TCP/IP FTP
(FTP) command, the next input required by the server for that OPEN
request, would be the user-id and password.
Script:
OPEN SYSNAME.HOSTEDFTP.COM
USER prof_name passwd10
CD /Myron catalog
PUT eprodcat_1746207GR.csv
QUIT
The log I'm getting
Connecting to host ftp.HOSTEDFTP.COM at address xxx.xxx.xxx.xxx …
220 Service ready for new user.
The above FTP220 feedback is in response to the implicit open; i.e.
the connect was opened successfully to "ftp.HOSTEDFTP.COM" [aka
SYSNAME.HOSTEDFTP.COM from the script]. The next step in processing is
authentication, so the first line of input should be the user-id and
password; the next prompt indicates that:
Enter login ID (prof_name):
The OPEN having already been issued implicitly, effected per the
RMTSYS specification on the STRTCPFTP command, the first token in the
input-script would be accepted by the FTP server as the user-id, and the
second string/token on that line would be accepted as the password.
That is just as Tommy initially responded
[
https://archive.midrange.com/midrange-l/201705/msg00403.html],
suggesting that "OPEN" was interpreted as the user-id.
331 User name okay, need password for OPEN.
530 Authentication failed.
The above therefore explains why FTP331 feedback indicates that the
"User name" provided was "OPEN". Though not conspicuous, the value
accepted as a password was the text "SYSNAME.HOSTEDFTP.COM" [that, for
obvious reasons, is not presented in any feedback]. For lack of a
user-id named OPEN *with* a password of SYSNAME.HOSTEDFTP.COM being
available on the server, the expected effect is the above authentication
failure, the FTP530 feedback.
Enter an FTP subcommand.
USER prof_name **********
At this point in the script, the FTP service should probably remain
"open", though still not authenticated; i.e. the "USER" FTP subcommand
should probably have been accepted by the server without error.?
Probably moot, after correction to the prior issue, whereby the
authentication would be expected to function properly on the first try.
No response from remote host; all connections closed.
I am unsure why there would not be any more feedback messages from the
FTP server other than the above "No response", since the USER FTP
subcommand was processed; i.e. unsure why there is no feedback for any
of the attempts to CD, PUT, and QUIT, that follow the USER subcommand.?
I have the AS/400 profile and password the same as the remote profile
and password. The only thing I can think of is that the remote
profile is lower case and the iSeries it's upper case.
I don't know if that matters.
No matter about matching names/passwords; the server should be
agnostic in that regard, because the authentication is effected via the
input. The input in this scenario, is from [source] data records of the
member of a database [source] file.
I'm running this signed on under that user profile.
When I do FTP from the command line and enter the user profile and
password I successfully get in.
The interactive/prompted request will exhibit the effect,
conspicuously per prompting, that the first input, indeed should be, the
user-id and password; i.e. elucidating, that the first two FTP
subcommands, the OPEN and USER, are extraneous, and those records should
be removed from the script [if the same RMTSYS is specified as the one
on the OPEN subcommand]. Please note that the OPEN can remain scripted
exactly as shown, but the FTP request would need to specify a bogus
Remote System; e.g. the CL request could be coded, instead of what was
shown, as:
FTP RMTSYS(*NONE) /* init FTP scripting without open connection */
Note: An asterisk prefix is discouraged/unsupported generally, in
that context of a parameter value that is not a
special-value/single-value, despite the lack of any warning in the help
text. Yet, such usage should never become an issue in this scenario;
i.e. this could be "safely coded" in production, with almost zero chance
of ill effect.
The next issue that would be seen, if either a) only removing the
OPEN, or b) only changing to use RMTSYS(*NONE) but leaving the OPEN,
would be with the next line of text as input. A requirement remains to
remove the "USER" on the second line of the input-script; the input
expected by the server is *only* data, just the user-id and password on
the one line, whereas the "USER" FTP subcommand is a directive. That
correction was noted by Rich in
[
https://archive.midrange.com/midrange-l/201705/msg00412.html]
Note: The USER subcommand is available to be used in an already-open
connection, for example, either after a failed authentication, or after
a prior "REIN" FTP subcommand that had just re-initialized the session.
If the USER subcommand is coded on a line by itself, then the user-id
and password both would be coded on the following line, just as they
would be coded after an [implicit or explicit] OPEN subcommand.
midrange.com
