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




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  / \
--------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.