All the FTP scripts I've seen need to be written out and redirect back into the FTP command.

But has anyone ever successfully pushed the script into the command from memory, as a data string??

not sure what you are trying to achieve but it seems like scp with public-key-encryption seems worth checking out ?

I'm almost sure you wish to achieve something interesting, but I cannot fathom out what it is.

Perhaps you want to implement FTP-client functionality in your program? Try components like curl or libftp.

These are existing programs in a body of code we are porting in October. It has to work now, be vetted and stable before we port the DB and ERP to Linux. Curl won't work as these are dedicated ftp servers, there's no html or even web access. All internal. We do not have libftp.

What I am trying to do is consolidate about 120 program so the port will go smoothly and not crash anywhere. ftp is the latest in a series of command line functions I write consolidation code. We has say 50 calls to ftp throughout our system. I am write a one-call-for-all subroutine. so if we have issues, we only need to fix the subroutine, not all 50 calls. But I am also working on performance improvement. That's why I posted about a non-script, straight feed into ftp. It would about a 100k reads and write, read and deletes actions a day.

Are you using some programming language or script language or any programming environment? (I could use clairvoyance/legilimency if it weren't illegal in my country.)

The problem is the disk access for the gets and puts by FTP and not FTP being invoked itself?

Why not establish a RAM disk for the locations where you perform the get and put commands and then resolve that RAM disk at a fixed time?

And if accessing the FTP binary seems to be a problem, then copy the FTP binary also to the RAM disk and likewise run it from that location.

We with with something you have never heard of. Universe Basic as part the Rocket Software's US package. It's support it's Multi-Value DB. Something else I'm sure you haven't heard of.

That's an interest idea. A ram disk would do the trick. I'm just not sure we even have the capabilities or if our DB coding system could handle one.

I'll ask the admin.

@OP: Cool. Then how do you expect anyone to give you advice? Nonetheless, my memories come back: you're the guy migrating from AIX to RedHat Linux.

Anyways, if you call (fork+exec) /usr/bin/ftp to transfer a file, it will be slow. Not because the commands to the program come from a file, but because fork and exec are slow. Also network traffic is slow. Reading a few lines (the commands) from a text-file isn't slow.

1 members found this post helpful.

Just asking the question......

My impression is that the DB would require a path or a similar structure. When you create a RAM disk, it becomes a path, and you can make a link to it if you require a certain structure or to need it to appear as if it were within the hierarchy of an existing physical disk tree.

I guess you'll have to evaluate that with your team.

If we could link to a ram drive that might a be a much more efficient way to do this.

If you have unused RAM, give it to the kernel so that it could use it as disk-cache. Now that does improve performance.

The Kernel has enough... with his fried chicken!