Re: BATCH FTP question

On 19-Feb-2015 07:45 -0600, Denis Robitaille wrote:

On 18 février 2015 11:15 Thomas Burrows wrote:

<<SNIP>> my file of FTP commands SAW_FTP_F:

REIN
USER userid password
NAMEFMT 1
ASCII
<<SNIP>>
QUIT

<<SNIP>> SAW_FTP_F is not a TEXT file. But a straight PF that has
one field name that is an alpha 80.

Could this be a problem?

I have written a batch ftp utility several years ago that is still
being used daily here.

The input file is a regular PF with one alpha field in it of length
256

And the 80-byte file described by the OP should work just as well given no requests exceed that line\record-length. I do not recall the maximum input length for any one FTP request.

The first line of the input file is like this:
<userid> <password>

There is no USER FTP subcommand coded, just the user id followed by
the password.

The IBM i as FTP client can accept the USER subcommand with the usrid and pwd coded exactly like shown in the OP; but only because there is a prior line of INPUT.

However AFaIK the first line of INPUT, on which the OP had coded [what appears a request to invoke] the REIN subcommand, would be understood implicitly by the IBM i FTP client to be a first attempt via the INPUT to provide the user-name and password. And while that effect is almost surely unintended and undesirable, the overall effect on the request is effectively naught; presumably a login\credentials failure occurs at the target, because the FTP client possibly asks the FTP server to login the user named REIN without any password.?

So *if* the INPUT was modified to omit the first line as currently coded, only *then* would the USER subcommand [need to] be dropped [to avoid msg TCP3C66 "Number of arguments for a prompted login to the server not correct.". What the effect of the superfluous REIN [a subcommand that is not even allowed until after the FTP connection has been established] is presumably just as described in the second-level text of that TCP3C66 message, that "the automatic connect-login sequence to the server is ended. Therefore, one should log in to the connected server using the USER subcommand.", because the OUTPUT does not show any effect for the first line of the INPUT from the OP.

In the CL, this is how the override is :
OVRDBF FILE(INPUT) TOFILE(QTEMP/&WRKFILE) +
MBR(*FIRST) OVRSCOPE(*JOB)

Whenever use of a job-scoped override is mentioned, best always to remind that the termination-phase of the program\processing [be that a normal or an abnormal end], should in many [if not most] scenarios effect the explicit corresponding Delete Override request to avoid latent effects of an override accidentally left in effect; specifically for the above OVRDBF:
DLTOVR INPUT LVL(*JOB)

<<SNIP>>