(I am hoping that other folks will jump in with help as well, especially in areas where I am not doing a great job in helping you...)
It still really depends on several things, such as which version of the shell you are using, Bourne(bash), Korn(ksh), or C(csh). Since I'm doing mostly bash stuff, I'll use that in my examples, and if you're in a different world, you'll have to translate, OK?
Another thing it depends on is whether you have root access to these servers. Without it, you may not get as far.
Finally, an important thing to know is whether these servers have a trusted host relationship, but once again, that is not necessarily an obstacle, it just makes the process take more steps if they don't.
You want to copy files over from Server A to Server D (database server), citing ftp as the example. That's fine as long as Server D is running an ftp daemon that allows you to post files to the directory path you need, and a certain amount of ftp access can be scripted so you don't have to babysit it. Another option to consider, though is scp, which is a secure (SSL) version of the "regular" cp command for copying stuff. An example might look like this:
[root@plato /]# scp /tmp/myfilename.sql root@dbserver:/opt/informix/dbpath
In this case I am assuming that target directory is the DBPATH on the Informix host. If there is a trusted host setup (administratively risky, but for closed networks, it can be ok) the scp command above won't even require a password. If you don't have root access on dbserver, then substitute your ID on dbserver for root as the target of the scp command, but keep in mind that it will only allow you to put the file(s) in a directory path that you have permissions to... this can be done with a series of files or a filename mask just like a cp, so you don't necessarily have to issue a separate copy command for each file to port to the other box.
That takes care of step 1.
Steps 2 through 4 all occur over on dbserver. While I do not know what ID you plan to log on there with, it likely falls into one of the following:
(a) root
(b) informix
(c) some other defined user that has some database access granted to it
(d) something else that just won't work
Assuming it's not (d), let's move forward. Depending on the trusted hosts/security model on your network, you could theoretically script the whole thing, log onto dbserver with an ssh command, execute your script and leave, but that would likely require you to be root as well.
Once you are logged onto the dbserver, either manually or via script, you can easily execute dbaccess with your SQL. Once again, it kind of depends whether the database server is hosting more than one database at a time, which I cannot tell.
A simple form, if your're logged on dbserver, it only hosts one database, you have rights to the database, and the file is located in $DBPATH, looks like this:
cd $DBPATH;dbaccess - filename.sql
A slightly fancier version that could be run as root, runs dbaccess, and the SQL, as informix(rights to everything):
su -c 'cd ${DBPATH};${INFORMIXDIR}/bin/dbaccess - filename.sql' informix
This should be done with care, and it depends on what kind of table updates you are doing.
Let me know if this helps- I am by no means a Linux or Informix guru, but I've been doing a lot of both for almost two years now, so I like to think I'm getting better at it.
Regards,
Joe