× 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.



Steve,

Not sure if it exactly fits the bill, but you may want to examine Scott
Klement's FTPAPI. http://klement.dstorm.net/ftpapi/

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863



> -----Original Message-----
> From: Steve Landess [mailto:steve_landess@hotmail.com]
> Sent: Monday, September 16, 2002 5:34 PM
> To: midrange-l@midrange.com
> Subject: 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....
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.