Re: connecting 2 as400s

[michaelr_41@xxxxxxxxxxxxxx]

Of course, one of the nice things about SNA *is* the error reporting.
Rather than packets just being discarded and then needing to be resent
(though you may only know by poor performance), SNA tells you what's
going on. 

On Wed, 25 Aug 2004 22:21:02 +1000, "Simon Coulter"
<shc@xxxxxxxxxxxxxxxxx> said:
> 
> On 24/08/2004, at 5:18 AM, rob@xxxxxxxxx wrote:
> 
> > No thanks, I've had enough of the SDLC errors and obscure error codes 
> > for
> > SNA that I used to get with STRPASTHR.  Codes that IBM seemed to hold 
> > near
> > and dear to their hearts and hide from the rest of us.  Codes that 
> > meant
> > doing odd things like varying off and deleting device descriptions and
> > letting them recreate again when a connection attempt was made.  And if
> > the planets were in just the right alignment - maybe everything would 
> > work
> > that time.  I'll take TCP/IP instead.
> 
> At least most of the SNA sense codes told you exactly what was wrong 
> and didn't leave you guessing where the problem might be like the 
> ubiquitous "no route to host" that TCP spits out. Is that caused by a 
> local configuration problem, a problem at the target system, or a 
> problem with some anonymous router somewhere in between. Never mind the 
> problems caused by mismatched MTUs.
> 
> Hardly hidden. The sense codes are all described in the SNA Functions 
> and Formats manual which is easily obtained.
> 
> True, configuration of devices was more complex than the TCP assign IP 
> address and forget. But IP is only simple in a trivial network where 
> all devices are in the same subnet. As soon as you have multiple 
> networks and different subnets TCP quickly becomes as complex as SNA 
> (but without the accurate feedback that SNA provides).
> 
> > Oh, sure, SNA did have the 'fire and forget' mentality that you could 
> > send
> > something off, and if the remote system was down, it would wait, and 
> > retry
> > when that system reconnected.  That was nice.   But finding out why
> > something stayed stuck in WRKDSTQ and the like could be a shuddering
> > experience.
> 
> Funny, I never had much trouble with distribution queues and I used 
> them between multiple 400s and mainframe systems.
> 
> Although you are confusing SNADS (SNA Distribution Services) with APPC 
> and APPN communications. The store and forward aspect you refer to was 
> part of SNADS which was built on top of SNA.
> 
> Regards,
> Simon Coulter.
> --------------------------------------------------------------------
>     FlyByNight Software         AS/400 Technical Specialists
> 
>     http://www.flybynight.com.au/
>     Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
>     Fax:   +61 3 9419 0175                                   \ /
>                                                               X
>                   ASCII Ribbon campaign against HTML E-Mail  / \
> --------------------------------------------------------------------
> 
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
-- 
  
  michaelr_41@xxxxxxxxxxxxxx