George Well, I've been having another look at your problem mainly because the description of the INACTIVE parameter says that the TN3270E TCP connection is "dropped", by which we may assume the author means, disconnected.
I'm wondering if maybe there has been a failure properly to describe the result of reaching an INACTIVE time limit in the light of the introduction of functions appearing after this descriptive text was written. - Should the authors reflect the later functions in the description of the INACTIVE statement? Yes. - Do they ever? There are safer bets! There is a section in the z/OS Communications Server Configuration Guide which describes the behaviour of a TN3270E concatenation - SNA session to TN3270E TCP connection - when the session ends. This is "Figure 64. Session ending scenarios" in section "2.2.1.8.1 Session initiation management (LOGAPPL, QINIT, FIRSTONLY, and DEFONLY)". http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/f1a1b371/2.2.1.8.1 According to this logic diagram, the following would be required in order that your TN3270E clients would leave the CICS application and be presented with an USS 10 message: - The expiry of the value of the INACTIVE statement would need to be regarded as a "Logoff" rather than a "Break" - You would need to have specified LUSESSIONPEND rather than the default NOLUSESSIONPEND. - You would need to have specified one of the following: -- DEFAULTAPPL <cics> LOGAPPL -- DEFAULTAPPL <cics> FIRSTONLY LOGAPPL -- DEFAULTAPPL <cics> FIRSTONLY QINIT The expiry of the value of the INACTIVE statement being regarded as a "Logoff" rather than a "Break" makes sense if one appreciates that there was nothing wrong with the SNA session. It's just that one of the session partner LUs, the TN3270E server, decided to "call it a day"! The alternative to being presented with the USS 10 message is for the session with your CICS to be re-established at, I assume, whatever point is normal when you first establish the session with CICS. Note that the default for the DEFAULTAPPL statement LOGAPPL and FIRSTONLY parameters (QINIT does not appear really to be relevant) is for the action when the parameters are not specified to apply - naturally enough - and this would cause that alternative to happen. This implies that you have specified the LOGAPPL parameter. Please report back on whichever of these circumstances fits your situation even if, in checking it out, you solve your problem. Chris Mason On Wed, 12 Jan 2011 09:19:46 -0600, Chris Mason <[email protected]> wrote: >George > >If I understand this correctly, you are having a problem between the primary >LU application, CICS, and the secondary LU application, the TN3270E server, >or involving either CICS, the primary LU application, or the TN3270E server, >the secondary LU application. Since you report that the TN3270E client >passes from being in communication with CICS - implied - to being presented >with the Unformatted System Services (USS) 10 message - assumed to be >what you mean by "USSTAB", there would appear to be no problem with the >TCP connection supporting the TN3270E connection between the TN3270E >client and the TN3270E server. > >But - perhaps being after the "break" - I realised only slowly what is going on >here - and it is, of course, not a *problem* but a *feature*! > >The clue to your "problem" is changing from an environment where presumably >this "feature" is not included to one where it is. I know nothing about the "DAC >unit" but I guess it is some sort of "outboard" TN3270E server. > >Among the admittedly massive number of TN3270E server parameters - to say >nothing of the parameters associated with the z/OS Communications Server >(CS) IP component - which incidentally necessarily has the same level as the >underlying z/OS - is the INACTIVE statement of the "Telnet parameter >statements in the Telnet profile": > ><quote> > >2.10.2.17 INACTIVE > >Use the INACTIVE parameter statement to define the terminal SNA session >inactivity timeout. A connection that has no client-VTAM session activity for >the specified time is dropped. > >Telnet is initialized with a INACTIVE value of 0. > >The INACTIVE statement can be coded in TELNETGLOBALS, TELNETPARMS, or >PARMSGROUP statement blocks. See "General rules for parameter statements" >in topic 2.10.2.1 for more information about the hierarchy of parameter values. > >Restriction: The INACTIVE statement applies to a KEEPOPEN connection only >when an SNA session, with the VTAM application, is active. > >Telnet uses one timer for the INACTIVE, PRTINACTIVE, and KEEPINACTIVE >statements. See z/OS Communications Server: IP Configuration Guide for >details. > >Syntax > >>>__ _______________ ___>< > |_INACTIVE 0____| > |_INACTIVE__sec_| > >Parameters > >0 >An INACTIVE timeout value of 0 disables the inactivity timeout. > >sec >Sets the inactivity timeout to the specified number of seconds. When a >connection has had no session activity for the specified number of seconds, it >is closed. This number must be an integer in the range 0 - 99 999 999. > ></quote> > >http://publibz.boulder.ibm.com/cgi- >bin/bookmgr_OS390/BOOKS/f1a1b471/2.10.2.17 > >The odd thing is that, by default, this parameter is 0, meaning that >the "feature" is not operational. You must have set it to something like 120 >perhaps without realising its significance. > >It may be relevant that you mention the value of the TCPCONFIG statement >INTERVAL parameter which has a default value of 120 - so you didn't need >actually to specify 120 - although I personally am in favour of specifying >relevant default values as an aid to solving problems when they arise. > >The mechanism controlled by the INTERVAL parameter of the TCPCONFIG >statement[1] is to assure the TCP connection when there is no traffic which >otherwise provides that assurance. However your users evidently maintain >their TN3270E TCP connection when the "timeout" you report happens. > >In order better to understand the issues surrounding - <rant> I here really do >mean "issues" and ***not*** "problems as the word is so widely and >flagrantly misused these days </rant> - timing with the TN3270E server, I >commend section "Timers" in the chapter on the "TN3270E Telnet server" in >the z/OS CS Configuration Guide: > >http://publibz.boulder.ibm.com/cgi- >bin/bookmgr_OS390/BOOKS/F1A1B371/2.2.1.11 > >Incidentally, since you took the trouble to mention your level of z/OS, I have >kept my quotes and references to V1R9. However I notice there has been >some rearrangement of this "Timers" section in later editions of the manual >where it has been relabelled "Connection persistence". It is possible - I'd >need >to check to be sure - that the issues are better expressed in later manuals >rather than necessarily including descriptions of new function. > >Checking your original post in review, I expect that neither CICS parameters >nor the TN3270E client are involved since it was the TN3270E server which >changed in your configuration. > >Chris Mason > >[1] How quaint to refer to a "card". I haven't seen an actual card used for >customisation in ever such a long time - sometime in the mid '70s I guess. A >good friend and colleague who used to visit a lot invariably used cards >for "aide memoires". He must have intercepted the rubbish disposal at the time >the stock of cards where he worked was being thrown out - and there must >have been a lot since the stock saw him though to retirement a quarter of a >century later! > >On Wed, 12 Jan 2011 07:48:07 -0500, George Rodriguez ><[email protected]> wrote: > >>Before the Christmas break, we moved the TN3270 configuration that was in >a >>DAC unit to z/OS and started using TN3270E as a STC on z/OS using a VIPA >>address. The environment is as follows: >> >>CICS/TS v3.10 with a TOR and an AOR >>TCP/IP v1.9 >>z/OS v1.9 >>Attachmate EXTRA! Enterprise 2000 >> >>The problem is that a user is timed out after a 2-3 minutes and it takes the >>user all the way back to the USSTAB. In CICS I have coded USRDELAY=30 >and in >>the TCP/IP profile parm we coded interval 120 on the TCPCONFIG card. >> >>Any and all help is greatly appreciated. >> >>*George Rodriguez* ---------------------------------------------------------------------- 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
