>I obviously can't comment on traces I haven't seen. I can say that TCP >provides guaranteed delivery ... if you (and your software) are willing to >cope with some very ugly timings.
We have no guaranteed delivery! Period! And, the only change was SNA to TCP/IP. >>If TCP/IP is so robust, why has it NEVER happened in 7 years under SNA (how >>long we've had the TN3270 client we use), and it always happens under TCP/IP. >I don't understand that statement. If you've been using Tn3270 for 7 years >you've been using TCP/IP. >By definition, Tn3270 is 3270 over TCP/IP. Not being a network person, I may be tripping over terminology. It's been the same desktop client for 7 years. >First, in my VERY unhumble opinion, anybody using screen scraping gets what he >or she deserves. (BOOM!) That was as true under pure SNA as under TCP/IP. All well and good! It doesn't fly with the business or my mangement. If I could get away with that, we would be TCP/IP on the mainframe, tomorrow. And, we would have a whole lot of scrap 3745's and 3174's. > (If you went for 7 years without screen reformatting you lived in a very > static world, indeed. Never said that we did. We have people who re-do the MACROS when the screens change. (Just did it for Germany) >That sounds like a problem with the Tn3270 client, or some kind of >incompatability between the Tn3270 client and server, or some such. I can reproduce the problem manually (with 5 minutes of effort). It has to do with the lack of think time. Just pound a PFKey until the host barfs. It happens with: RUMBA ATTACHMATE Hummingbird, and at least three different web-clients: 2 in JAVA and on in ACTIVEx. >If this is not an intermittant problem it is absurd to blame it on dropped IP >packets. Dropped packets are not a repeatable issue ... unless you are >violating the protocol or have something misconfigured. The packet drops (not always the same one), but with no think time the desktop is sending the data too fast. >(Sending packets too large for a level-2 switch will be dropped every time. >And trying to set up an SNA connection between mismatched ends will fail, too. Remember NRZI vs non-NRZI?) I don't know what you just said. And, no, I don't remember. The packets are one PFKey. >I happen to be an SNA bigot and have no love for TCP/IP, but don't like seeing >bogus arguments against TCP/IP. It's not bogus. I explained the issue to a z/OS TCP/IP consultant, at CMG Canada in April. Even with my poor grasp of terminology, she knew what the issue was. Something about NAGLE (spelling?) and host settle-time. >Crying "wolf" helps nobody. I am not crying wolf. Also, I was not asking for help here. I was just pointing out that TCP/IP sucks, is a weak protocol and is going to take over the market. >Find more specifics about your failure; there is something more specific than >just "TCP/IP" here. If I knew what questions to ask, I would. Standard Problem Determination question: "What changed"? Answer: "I changed to protocol on the desktop to communicate through TCP/IP, rather than SNA". Next question: "What was the result"? Answer: "No matter what client I used, if I typed 'too fast', my session got forcibly disconnected". Secondary Answer: "When I used scripts, it happened immediately"! IPSO FACTO! Q.E.D. . -teD Marching to the beat of a different flute ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
