× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 1/19/2012 9:09 AM, Jeff Young wrote:
I have a customer that needs to transmit files using SFTP to their vendor
on a periodic basis. Each transmission will have the same file name but
different member names.

I've never had good luck with sending database members with sftp. Please remember that sftp is a Unix tool. It knows nothing of features that only exist on IBM i (such as members).

Since this is an automated task anyway, have the program that's generating the file write it into a stream file object (*STMF).


Given that I know next to nothing about setting up or using SFTP, what to I
need to do to configure the IBM i to communicate with the server and can I
use this same name format in the SFTP command to send the data?

You need TCP/IP configured and working. You need port 22 open in the firewall. You need PASE, QShell, and 5733-SC1 base and option 1 installed.

sftp is a Unix tool, it does not have any IBM i native features like FTP does. All naming MUST be in IFS format (though, it looks like you were using that with FTP anyway.)

Unlike FTP, files cannot be converted... they will be sent as-is. So if your data is in fixed-length record-based EBCDIC, and you want it to be in stream-oriented ASCII or Unicode, then you need to convert it prior to calling sftp.


If I create a flat file on the i and then use either the CPYTOIMPF or
CPYTOSTMF commands to place the file on the IFS, are there any special
parms that I need?

Sftp/scp doesn't know or care what the format of your file is. As far as sftp/scp is concerned, it's a big string of bytes. It will copy those bytes to another computer, as-is.

CPYTOSTMF/CPYTOIMPF are tools for converting the format of your data. Therefore, no parameter you specify will matter to scp/sftp. It doesn't matter to sftp, because sftp doesn't care what the format of your data is.

However, the folks who are receiving your file will care. You need to find out what format THEY want the file in, and then use an appropriate tool (or write one) to get it in that format.


I know that I can use the Unix API's to create the file directly, but I
need to code this so that someone who is not familiar with using API's can
maintain it.
The data is plain text with a | character separating fields.

I have no problem with using the CPYTOIMPF tool for this, that's a good method... but I disagree with your philosophy!

For what you're doing, CPYTOIMPF will convert a database file into a pipe-delimited file with one command call. If the format of data that it produces is what you want, then why /wouldn't/ you use it? Reinventing the wheel is pointless, unless you're going build a better wheel!

But the philosophy that "I think the IFS APIs will work better, but I won't use them because someone else might have to learn a skill" is absolutely idiotic. Sorry for being so blunt, but that's how I feel. I'm mean seriously... another programmer is going to see you calling APIs named "open", "write" and "close" and they're going to be completely stumped? How are you call the completely obscure write() API?? Nobody will ever figure out what that does??? Really?

My suggestion is to have an RPG program that outputs a normal, externally defined PF that contains the fields you want, and the records are in the sequence you want. Then use CPYTOIMPF to convert it to a pipe-delimited file.

Custom-building the pipe-delimited format in your file, then writing it to a flat file, and converting it to a stream file with CPYTOSTMF is moronic, and shouldn't be done. If you're going to do the custom formatting in your program, then it should also write it to the stream file.

Adding extra work and extra complexity so that someone else doesn't have to learn some trivial new technique is stupid.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.