Mainframe Linux Mythbusting 3809

since I've rarely heard of similar problems under tcp-ip implemenations on other platforms, it is possibly bugs in the vendor's tcp-ip implementation ... check with your tcp-ip vendor about possible bugs in their tcp-ip implementation.

at more basic implementation and protocol level ... sna tends to require an enormous amount more code and much longer pathlength (as well as significantly more buffer copies) ... as per earlier post:

from a protocol aspect, sna has tended to be much more half-duplex oriented vis-a-vis tcp-ip ... which should simplify the management of possible states.

for some topic drift ... from a post earlier this year

the following email extract about implementing SNA on a unix platform ....

re: sna; interesting note in this month's sigops. Somebody at CMU implemented LU6.2 under UNIX4.2 ...

Rosenberg reported on an implementation of an SNA node consisting of LU 6.2 and PU T2.1 protocols. (These protocols cover approximately OSI layers 2 through 6.) The implementation was made on UNIX 4.2. About 85% of the code was generated automatically from the FAPL meta-description of SNA. The following problems were reported:

...

1. The protocol code is large, and thus cannot run in the kernal space. Consequently, communication between user program and the node (processor executing the SNA code) is more complex and slower than if the node were part of the kernel. In addition, error recovery proved tricky.

2. The SNA node must simulate the UNIX sockets, which are full duplex and place no restriction on the states of the two conversants. The SNA node uses a half-duplex, flip-flop protocol, where the states of the two conversants must remain synchronized. To match the two required an extension to SNA.

The implementation is now complete and is actually used to drive a 3820 printer, which is a SNA device