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



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.