Re: IFS Dir file listing

On 06-Aug-2014 10:24 -0500, Voris, John wrote:

On 05-Aug-2014 18:04 -0500, CRPence wrote:

On 05-Aug-2014 17:50 -0500, Buddy McClean wrote:

On 05-Aug-2014 17:29 -0500, Voris, John wrote:

On 05-Aug-2014 15:51 -0500, Buddy McClean wrote:

<<SNIP>>
FTP is putting files in a directory and I want to know the
name so I can read via xml-into.

Actually, FTP has its own flat file listing capability too

typically, the steps are . . . .

CHGCURLIB mylib

FTP 127.0.0.1

ls <directory> (DISK

I was thinking about the possibility, Thanks.

The LS [and DIR which has its own (DISK option and output to
*CURLIB/DIROUTPUT.DIROUTPUT] is a client feature; listing the
contents of the remote path\directory. So if the /putting files/
refers to the the IBM i as server vs client, then those FTP
subcommands are not directly helpful [AFaIK].

My reply re-inserted, above, in its entirety.

Buddy McClean wrote:

The LS [and DIR which <<SNIPped; see above>>

The mis-attributed text, above, was snipped.

Using a connection of 127.0.0.1 points the server back to itself.
which is why I included it = the LS command in FTP *is* acting as a
client (127.0.0.1 is the home server).

Yes, but a contrived example; one that is unlikely to be representative of what the OP was\will be doing with their FTP scenario.

This FTP LS command is the same as the UNIX or QSH qshell command.

If in the future, it is a diligent junior programmer maintaining the
script, they would pull the manual for FTP, then need to grab the
manual for UNIX-QSH just for the "LS command" to verify their
understanding of your process.

What process? Processing of the DIR vs the LS? And if LS is the same irrespective whence invoked, why is anyone looking elsewhere for docs about the difference(s).? Neither the LS shell utility nor the FTP LS subcommand was my recommendation; I was merely warning that [AFaIK] the LS (DISK FTP subcommand [and the DIR (DISK as well] was limited to the FTP client.

I tend to avoid such outputs, because using them is often little better than the use of /screen-scraping/; the undescribed data being directed to a file as the output stream device instead of to a video screen as the output stream device, is sometimes problematic for coded dependencies on the layout of the data, due to nuances with what might be output.

In my opinion, using a single FTP process instead of two processes is
better - one tool versus two tools in the process.

I agree that could be nice. But the remainder of my comment was directed to whether the initial process being utilized by the OP might not even be running as an IBM i FTP client. If not running as an IBM i FTP client, then the syntax "(DISK" is non-standard, and whatever was the output from the LS request at the client would _also_ have to be /PUT/ to the IBM i as FTP server; without the special case of FTP to *loopback, there was no implication of that requirement, and the OP did suggest the effect of FTP was /PUTting/ files into a directory, not /GETting/ files into a directory. Or if they must initiate a second FTP request as a client session running locally on what was the FTP server, is there really that much value in starting a second FTP session to *loopback, over just starting\using a different shell; the former requiring credentials, the latter probably not.?