Miguel, Disabling contention resolution on the client might be a temporary workaround, but I wouldn't recommend that as a permanent workaround. Contention resolution is a very good thing to have enabled -- it can dramatically speed up things like macros -- and you can just about guarantee you'll have an endless number of phone calls from clients otherwise if you don't fix it before too long.
I thought way before z/OS 1.8 the contention resolution problems were fixed and everything runs smoothly. Let me go dig up my old notes.... OK, here's the history. Contention resolution debuted in z/OS 1.2. It takes two to tango, though (server and client), and for 1.2, 1.3, and 1.4 there were discrepancies in how z/OS implemented contention resolution and (later) how the first clients did. Before z/OS 1.5's GA everything settled down, and there were PTFs released for prior z/OSes. The contention resolution specification is defined in IETF RFC2355, but sometimes it's tough to implement the specs exactly the same way. (As to why IBM released a client that didn't work with its own server contemporaneously... can't explain that one.) There's an informational APAR called "Common Telnet Problems Under z/OS" which you should check to see if there are PTFs that apply to your particular z/OS release. The APAR is II13135. To save you the reading, Miguel, at this instant that APAR advises these fixes for z/OS 1.8: UK15163, UK15227, UK16016, UK19642, UK16746, UK19164, UK19835, UK21579, UK25194, UK26064, UK32220, UK25807 and further advises searching on R170 TSASO if you're running TELNET in its own ASID. In addition, these non-TELNET fixes may be relevant because they might impact TELNET: OA11652, OA11841, OA15828, OA16468, and OA17750. (Some/all of those may not be relevant to 1.8.) My hunch is that Mark Zelden correctly remembers when contention resolution indeed was a problem, but I thought IBM had permanently buried those specific problems as of z/OS 1.5. Maybe they've come back, or maybe it's something else. Applying the fixes in II13135 should squash anything IBM knows about on the z/OS side. Do note there's a Personal Communications 5.9.2 now, so I would also try that to see if the behavior changes. (There's also a 5.8.3.) Don't automatically assume the mainframe is at fault, which reminds me.... I remember arguing with the PComm team a few years ago that they had a ridiculously short timeout value as the default. I think the timeout affected TN3270E SSL handshaking across slow network connections, including modem dial-up, the average corporate VPN, and other high latency/high congestion situations, making it impossible to connect. They argued that lengthening the default might break something else, so they didn't want to change it. I argued that the certainty of having something broken (SSL handshakes) ought to trump the remote possibility that a longer timeout might break one user's macro (or something -- I don't think anybody could think of a plausible breakage scenario there). My argument won, and the default timeout is now longer. All of which is very interesting but may have nothing to do with your problem. :-) Hope all that helps. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- 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
