George After that frantic activity as recorded on the CICS-L list, I'm trying to get back to your original problem.
You actually reported it was solved by installing the change according to the procedure described by the Attachmate article which is, in effect, implementing the "timemark" - sometimes called "are you there?" and at other times confusingly called "keep-alive" - traffic at the level of TCP in Windows equivalent to the what the TIMEMARK parameter in the TN3270E server program does with the z/OS Communications Server (CS) IP component. Would you please explain how it was you decided that the original "timeout" problem - as originally reported in posts with subject "Timeout Problem after Switching a DAC unit with OSA in the z10" on Wed 12 Jan - was thought to have been solved? My problem is that I cannot see how that enabling the TCP "timemark" traffic in Windows TCP can have any beneficial effect at all. With the default 2 hours delay, what it will do for you is the following: 1. If any of the TN3270 client end users leaves the TN3270 client "window" active for up to 2 hours, the TCP connection initiated by the window will be terminated - that is unless the TN3270E server has not already terminated the TCP connection so it can be effective on the side of the TN3270 client only when the network has broken down. 2. In the very unlikely event that the firewall tolerates idle TCP connections for more that 2 hours, the "timemark" traffic will persuade the firewall that the TCP connection is still wanted by its users and not cause a termination. Since the "timeout" problems you reported were of the order of a few minutes rather than 2 hours, I'm at a loss over how this "timemark" traffic can have any bearing on your original problem. - Also not to be overlooked is that fact that, rather than go to the time and trouble of making this change in all of the Attachmate configuration files, if the benefit were to be "timemark" traffic to keep a firewall "happy", you need actually do nothing whatsoever at all since you have arranged for "timemark" traffic every 30 minutes with the value of 1800 for the TIMEMARK statement in your TN3270E PROFILE data set. - Regarding what might cause a TN3270 connection to be dropped after 2 minutes, I imagined a rather complicated firewall rule which specified that, if all that happened on a TN3270 connection was the usual TELNET/TN3270 negotiation traffic followed by "application" traffic but only in the direction server to client, it, as it were, says to itself, the client has gone away, so drop the TCP connection. Yes, it's complex, but I can imagine firewall implementations compete vigorously to provide as much complexity as they can and I can imagine naive firewall implementers being duped by such a cornucopia! - I - and probably others trying to follow this series of threads - have been concentrating on the word "timeout" in the subject. However, on reviewing the posts, I note the "timed out" in the reports - not really explained from where they came but somehow related to CICS - in your post of "12 Jan 2011 12:26:52 -0500" which you claimed would explain everything, an example being "12:42:42 TELNE51A timed out" from CICPTM, "the CICS where the application is". You provided other messages from CICSTOR, "the CICS that owns the terminals", and the part of the messages you chose to present was either "Signon" or "Signoff" together with the LU name. I am not intimately familiar with CICS messages so it was only much, much later when you showed us the sets of messages appearing at the same time as the VTAM messages to which you took such exception as described in the thread "Help with ADJSSCP" on IBM-MAIN and "CICS Session Failure and Model APPL Statements for SLUs" on CICS-L that I appreciated the "timed out" could have been extracted from a CICS message and where the presentation of the full message might have assisted enormously in dealing with the original problem. Actually I did try using "timed out" as a search phrase in the CICS Messages and Codes manual but got 58 hits which is far too many hits to use to try to guess what message it may have been. As a result of the discussion of what might be a similar problem in the IBMTCP- L list - which is where this query should really have been posed - it seems that it is likely that the end users are simply exiting from their Attachmate window with the "X" option, that this causes a normal termination of the TCP connection and that this is causing the sequences of CICS messages of which the most characteristic is DFHZC3424. It may be that, while this is a message which appears in the "terminal" CICS, the message with "timed out" is a corresponding message in the "application" CICS. It may be that what is a normal termination of the TN3270 TCP connection transmits itself to the SNA session and the "terminal" CICS as an abnormal termination which then transmits itself to whatever the application is as some sort of abnormal termination of a transaction which has an eye on the clock and shows its impatience by "timing out". Nowhere in this series of threads has there been any mention of what the end users, the users of the Attachmate TN3270 client emulator program, say is going on. Unlike the TSO users which John McKown reported has been discomforted by the removal of the session manager, we don't know whether the users of the "School District of Palm Beach County" system are suffering any discomfort at all. What is somewhat interesting is why there is a change of behaviour from when the previous TN3270 server was used to the current use of the z/OS Communications Server (CS) TN3270E program. Is it possible that the previous TN3270 server terminated the SNA session in such a way that it appeared "normal" in comparison with the CS TN3270E program which terminates the SNA session in such a way that it appeared "abnormal" thus causing a different reaction in CICS? What I'd be doing to sort this out in a period when both TN3270 servers were available of course, would be to check the SNA traffic using NetView Session Monitor trace function - and I maybe wouldn't even need the CPIU option! - So, in order to make any progress on this topic we would need to know precisely what the CICS error message was which contains the "timed out" and what the Attachmate end user experience is. Ideally you would be able to report a trace of the end of the SNA session for the case of the previous TN3270 server and the CS TN3270E program for comparison. Just to be sure, you should check with your firewall specialists was checks they have implemented which might affect your TN3270 TCP connections. It would also be helpful to have some idea whether or not the firewall was involved if you could indicate whether it is only your "external" users which have the problem or does it also affect your "internal" users. Chris Mason On Tue, 15 Feb 2011 10:19:16 -0500, George Rodriguez <george.rodrig...@palmbeachschools.org> wrote: >Hi Chris, > >I'm still reading your reply to the Attachmate tech-note link that I gave >you, but I thought that it's important to let you know that the only change >we made is what's documented below: > >Enabling Keep-alive Support in EXTRA! > >To enable client-initiated keep-alive support, you must configure EXTRA! to >use the Microsoft TCP/IP KeepAlive parameter. Follow these steps: > > 1. Close any open EXTRA! host sessions. > 2. In a plain text editor, such as Notepad, open the EXTRA! session > configuration or EDP file you are using for the TN3270 session. (To enable > the KeepAlive parameter in all newly created TN3270 sessions, modify the > 3270.EDP file.) > >By default, this file is located at C:\Program >Files\Attachmate\EXTRA!\Sessions\ENU\Template\3270.EDP. > > 1. In your EDP file, scroll down to the [Connection] heading. > 2. Add the following line to the [Connections] section. > >KeepAlive=YES > >Or, to disable this feature (the default), delete the line or change the >value to NO. >KeepAlive=NO > > 1. Save the file. > 2. Restart EXTRA!. > >We did NOT make the registry change, so I'm assuming that the default of 2 >hours is in effect. From the little I've read from your response, this is >NOT a good thing. > >Is it possible for you to provide any information on the firewall settings >and what to look for or what's not specified that could be causing this 2 >minute disconnection problem? > >Again, I truly appreciate all the help you've provided. >* >* >*George Rodriguez* >*Specialist II - IT Solutions* >*Application Support / Quality Assurance* >*PX - 47652* >*(561) 357-7652 (office)* >*(561) 707-3496 (mobile)* >*School District of Palm Beach County* >*3348 Forest Hill Blvd.* >*Room B-332* >*West Palm Beach, FL. 33406-5869* >*Florida's Only A-Rated Urban District For Six Consecutive Years* > > > >On Mon, Feb 14, 2011 at 11:55 PM, Chris Mason <chrisma...@belgacom.net>wrote: > >> George >> >> I'm pleased to see that you report having solved your problem and I'm sorry >> for the delay in responding to your numerous posts of a fortnight ago. You >> may have noticed some of the aggression with which I have had to deal in >> the >> last few days - and it continues - but you deserve the responses I've been >> getting ready. >> >> In order to understand what I am about to cover, you will need to read over >> my response to your post where you asked me to analyse the Attachmate >> article which, in essence involves introducing TCP-level "keepalive" >> processing >> in the TCP support in the Microsoft Windows workstations supporting the >> Attachmate TN3270 client. >> >> Since you report you have solved your problem by introducing TCP >> "keepalive" >> processing in the TN3270 client, I have the following 4 points to make: >> >> 1. TCP "keepalive" - or its application-level equivalent - can only solve >> the >> sort of "timeout" problem you reported initially by, as it were, keeping a >> firewall happy so that it does not decide to terminate TCP connections. The >> other role of "keepalive" is to detect the death, real or apparent, of a >> partner >> in a TCP connection so that the local end of the TCP connection can be laid >> to rest! You haven't expressed a need for this capability of "keepalive". >> >> 2. Presumably you have decided on a value other than 2 hours for the >> KeepAliveTime Windows registry parameter so it would be useful to know what >> value, time interval, you have chosen. >> >> 3. Assuming the value is, say, 10 minutes (600000), as a means of >> satisfying >> the firewall rules, you could have specified a value of 600 (10 minutes) >> for the >> TIMEMARK statement and, say, 300 (5 minutes) for the SCANINTERVAL >> statement in the TN3270E server PROFILE data set. I imagine that would be >> easier than deploying the Windows registry change and adjustment to the >> Attachmate EDP file out to all your external clients. >> >> 4. There is an alternative or a complement to 3 which is to check what the >> firewall rules are which apply to your TN3270 service IP addresses and >> server >> port number, 23. You should, of course, ensure that the TIMEMARK frequency >> is less than the "lack of activity" timer in the firewall rules. >> >> - >> >> So, if your problem had been to "clean up" lost TCP connections in the >> workstations supporting your Attachmate clients, you have done the right >> thing by deploying the customisation described in the Attachmate article. >> >> However, since your problem was to avoid disconnections of the TN3270 >> traffic, it is very probable there were two much easier ways to solve the >> problem - but it's your choice. >> >> Chris Mason >> >> On Fri, 28 Jan 2011 07:48:58 -0500, George Rodriguez >> <george.rodrig...@palmbeachschools.org> wrote: >> >> >Chris / Patrick, >> > >> >The tech-note in Attachmate's database did solve the timeout problem. >> Thanks >> >again for the help... >> > >> >*George Rodriguez* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
