File transfers between central AS/400 and multiple branch AS/400's

All:

Around 12 years ago I wrote a system for a client that uses the AS/400 File
Transfer Subroutine (FTS) to allow send/receive of files dynamically between
systems WITHOUT having to set up SNADS and use SNDNETF, RCVNETF, etc.

For those of you who are not familiar with FTS, it is a carry-over from the
System/36, and it can be used to transfer source members and/or data files
between AS/400 and System/36 systems, as well as AS/400 <-> AS/400 systems.
In the beginning ALL of the remote systems were S/36, but over time they
were replaced with AS/400's.  Now there are 30 remote AS/400's, with 1
central AS/400.

This system was designed to be robust and fairly bullet-proof over the
existing SNA network.  There is a master file on the central AS/400 that
designates which files need to be either sent or received daily to/from the
remote system, and it works either over a leased line environment OR it will
create the necessary Dial-up SDLC configuration objects, use them, and
delete them when finished.

They now want to perform this functionality via the internet over a VPN
connection.

My first thought was that we could possibly adapt this system to use an SNA
over TCP/IP configuration (MPTN) as the underlying communications framework
along with the existing programs, but I'm not exactly sure how viable or
stable that it would be, or if this technology will even work over a VPN.  I
haven't heard a lot (either good or bad) about using MPTN.

They have used batch FTP scripts from the central AS/400 on an ad-hoc basis
to perform some file transfers, but I don't feel extremely comfortable with
the error-handling using this approach.

How hard would it be to write Sockets code to replicate what FTS does?  Has
anyone already done something similar to this?

The optimal solution needs to be:

1)  Dependable.  If it determines that a file did NOT get sent/received
properly, it should retry X times before it reports a failure.  The
environment is basically operatorless.

2)  Easy.  The current system is intuitive and easy to use, manage, and
maintain.

3)  Include all source code.  Since the current system was custom-written, I
would guess that they want all source code.  The client will most probably
want to make some modifications to the software to add additional
functionality.


If you are a software vendor with a solution, please send me a private
message..steve_landess@nospam.hotmail.com (take out the nospam.)


Thanks in advance for your help....