Re: SNADS over TCP/IP

Gentlemen,

 Having used both and written code to leverage both I must say there is
definitaly room for FTP and SNADS.  Certainly for connectivity to NON IBM
servers FTP is generally simpler and more likely to be available.  For moving
one or two files it's way faster.  For reliability and ease of monitoring go
SNADS.

 Tim is really on target. If FTP can't get to the other machine you gotta read
the unformatted log output, parse it best you can, guess in some cases, wait,
then try again.  With SNADS, you Send it and forget it. On the recieve side with
SNADS you just wait for the message CPxnnnn telling you what file and from and
to whom and deal with it. No guesswork, always in sequence.

 FTP has it's place and I use it a lot, but you CANNOT replace SNADS with FTP
unless you really like writing code.
 
 - Larry

Tim McCarthy wrote:
> >
> >
>         >My point is FTP doesn't care if it can't attach to another
> machine either.
>         >Finding if the transmission was successful is as simple as
> reading the FTP
>         >log text, manually or via a program that knows what to look
> for.
> 

>         Huh??? What do you mean FTP doesn't care if it can't attach to
> another machine? FTP is a connection oriented protocol, it has to be
> connected to the destination server to perform the file transfer. If the
> connection is broken then too bad, start again. SNADS is connectionless.
> If the connection to the remote host is not active then the request is
> queued; if the connection is broken it can recover on another route - no
> user intervention required. As far as checking the FTP output log to
> determine if the transmission was successful: this is not only difficult
> but it's highly unreliable and the output varies from server to server.
> 
>         >> To set up this same
>         >> processing via FTP would require jumping through many more
> hoops.
>         >>
> 
>         >I disagree.  Maybe a couple hoops, but at least you'd be using
> something
>         >that is platform independant.  That outweighs the one or two
> hoops you need
>         >to jump through to see if the transmission was successful.
> 
>         I understand the omnipresence of FTP but I agree with Rob here
> on the hoops issue. With SNADS I can monitor for files intended for me
> or my application as a user. I do not have to depend on the remote user
> using a certain file name or putting to a particular directory. Plus if
> I get multiple files they're all queued nicely in order for me and they
> can be prioritized. Think of the processes you have to build at both
> ends just to control the situation where a remote sends another copy of
> the same file before I've processed the data in the first copy. Does he
> append or replace? What if I've got the file locked?
> 
>         In addition don't forget to consider the issues associated with
> running an FTP server on the host side...giving out user id's,
> controlling the remote users access etc. I'm not trying to be negative
> on FTP here - the company I work for writes and sells FTP clients and
> servers - but FTP is not always a good replacement for SNADS.
> 
>         Tim

-- 
Larry Bolhuis         |
Arbor Solutions, Inc  | Two rules to success in life:
(616) 451-2500        | 1. Never tell people everything you know.
lbolhui@ibm.net       |

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---