Home > IT Answers > AS/400 > Alternative to FTP for file transfer to iSeri...
Help

Question

  Asked: Apr 17 2008   6:49 PM GMT
  Asked by: Pmc

Alternative to FTP for file transfer to iSeries (AS/400)


AS/400, FTP, File transfers, AS/400 FTP

I've been tasked with attempting to find a better alternative to FTP for transfering files from an FTP server to the iSeries. The files being transferred are based on a server that is being replaced and the manager of infrasturucture does not wish to put FTP on the new box.

The current process uses FTP dir command to list the files present to an output logfile which is then processed to create a script "on the fly" to FTP the file up to the iSeries.

I had thought about setting up a NETSHARE drive on the iSeries then transferring from there but the office which will be creating and storing the files is a remote site on a WAN which also passes hundreds of 5250 type sessions (plus GUI and other misc data/applications) through the connection and I don't wish to impact the interactive "stuff".

Any suggestions?

Subscribe to Alerts! Get questions and answers delivered to your Inbox.


E-mail me updates on this question



   SUBSCRIBE

hidden modal window
Help

Answer Wiki (Improve, edit or add to this answer)

IMPROVE THIS ANSWER
View History
 RATE THIS ANSWER
0
Click to Vote:
  •   0
  •  0
Last Answered: Apr 17 2008  8:48 PM GMT  by Bvining




There are many ways to transfer files from one system to another. As it sounds like both are iSeries the list could include DDM (with a simple CPYF for instance), SNDNETF, QFileSvr file system of IFS, etc plus the FTP solution you are already familiar with. All will have the drawback of potentially impacting interactive users that are sharing the same communication channel (though there are some knobs such as TCP Quality of service (QOS) available to you). And depending on the data you may also be able to reduce impact on the communication line by way of data compression (assuming you have spare cycles on the systems themselves in order to compress/decompress).

One alternative that comes to mind would be to stop sending files. Rather than sending entire files (batches of data), you might be able to send the individual records as they become available on the source system. If we're talking database records perhaps a simple trigger program could send the records over in real time (with scenarios such as writing directly to a socket, writing to a DDM *DTAQ, writing to a DDM database, etc) or, along similiar lines, perhaps you could journal the file and receive the journal images in real time for transmission to the target system (or use remote journaling for that matter). A real time capture of the data should minimize the potential impact to interactive users (the data is spread out over a wider time period) and you could, of course, also build in your own throttles/controls (where most -- though not all -- file transfer utilities don't have much in the way of throttles (or checkpoing/restart for that matter)). Obviously the feasibility of this approach depends on the data source, and your question doesn't give much information on that.

I might be able to help more if you can provide additional information on where the data is (database, IFS, etc) on the source system and how the data is getting there (fed by local applications, sent as a file from yet a 3rd system, etc).

Bruce Vining
http://www.brucevining.com/
Providing integrated solutions for the System i user community
  • AddThis Social Bookmark Button

Browse more Questions and Answers on AS/400 and Networking.

Looking for relevant AS/400 Whitepapers? Visit the Search400.com Research Library.


RSS - Discussions Help

Discuss This Answer


You must be logged-in to discuss a question. Log-in/Register

Pmc  |   Apr 18 2008  1:32PM GMT

To elaborate on the original description of what is ahppening… Local users get a faxed document into their PC’s. This is converted into a PDF document and loaded onto a LAN server (which was also the original FTP server). The iSeries has a scheduled job which sweeps the FTP server (utilizing the FTP dir command to an output log) and the files present ar FTP’d to a database “flat file” which is then processed to extract the data present.

The whole process goes from received fax to PDF, from PC to Lan Server, before the iSeries even knows about the existance of the document. The PC’s and the LAN server are in a remote location to the physical iSeries and the communications pipeline supports several hundred interactive sessions as well as other miscellaenous functions.

Personally, so far at least I think that the batch FTP process is the least intrusive, but our infrastructure team does not want to support FTP on the new replacement server.

Thanks for the input though, and if you have any (and I do mean any) other thoughts on this I’d love to hear them.

Paul Carpenter
Protective Life, Asset Protection Division

 

Bvining  |   Apr 18 2008  1:59PM GMT

What is the new LAN server at the remote location? That is, what type of operating system will it be running.

 

Pmc  |   Apr 21 2008  2:30PM GMT

OK, I got that information… Windows 2003 Server. BTW… I thought Windows server side OS included at least the ability to accomodate an FTP Get and an FTP Dir without extra requirements.

Thanks again

Paul Carpenter

 

Mcl  |   Apr 21 2008  6:41PM GMT

Can you change the process to go from the PC to the iSeries IFS instead of to the LAN server?

If you can do that you can use QSHELL commands to get a directory listing to a file
(ls -l ifsdirname > qsys.lib/mylib.lib/dirlist.file/dirlist.mbr),
extract the filenames from that file and then use a CPYFRMSTMF command to copy from ifsdirname/ifsfilename to qsys.lib/mylib.lib/myfile.fil/myfile.mbr.

If you can write a program to handle the FTP, setting up something to use QSHELL should be easy…

As far as remote location and traffic - I don’t know what differance it makes if you are transferring from PC to LAN Server and then an FTP to get the files to the iSeries verses going from PC to the iSeries directly..

Regards
Mike Loiodice

 

Pmc  |   Apr 22 2008  1:45PM GMT

Thanks Mike,

The IFS Shared idea was one that I had already been considering. The objection to that which was raised is the currently the users save to document to a local LAN drive - a pretty quick operation. Saving to an IFS drive would involve channeling through the communications bottleneck along with all the other jobs/data/etc connecting the data center and our remote site. Our users are used to that local speed and if we degrade their response times, well it would not be a good thing.

 

Djac  |   Apr 24 2008  9:55AM GMT

I’ve been following this thread and every time I get to the bit that says:

“our infrastructure team does not want to support FTP on the new replacement server”

I think ‘why the heck not!?!?!?!’

Is it issues with space/performance/security? These can all be addressed if they can be bothered.

Or do they just not want their nice shiny server having anything to do with that nasty old dinosaur of an AS400?

Have you escalated this through management? Perhaps if someone explained to the infrastructure folks that these systems belong to the company, not to them?

Anyhoo, rant over….

From your concerns about performance if the users save directly to and NFS share, it would appear that local saving with periodic collection by the AS400 is still your only realistic option.

How about setting up a medium-spec PC locally to the users to act as an FTP server, or possibly even a NAS drive? Most NAS drives have an FTP server built-in.