Hi Chris, Now I'm 100% confused... It's probably the way I'm describing the problem. Let me show you examples of messages that CICS provides when things happen:
This is for user TARANTI: CICPTOR is the CICS that owns the terminals. 06:28:42 TELNE870 Signon this is the initial startup 06:35:53 TELNE875 Signon 7 minutes later the user is signing in again 06:35:59 TELNE875 Signon a few seconds later signing on again 06:36:16 TELNE875 Signon 07:08:38 TELNE875 Signoff 07:32:50 TELNE870 Signoff 07:59:58 TELNE1B0 Signon 08:00:02 TELNE1B0 Signon 09:21:44 TELNE1B0 Signoff 09:51:38 TELNE933 Signon 11:57:24 TELNE51A Signon 11:57:27 TELNE51A Signon 12:01:04 TELNE933 Signoff CICPTM is the CICS where the application is. 07:06:20 TELNE875 timed out if the initial start up is at 6:28 and inactivity happens 30 min. later, this is ok 07:30:09 TELNE870 timed out 09:18:27 TELNE1B0 timed out 11:57:51 TELNE933 timed out 12:42:42 TELNE51A timed out I appreciate your help... * * *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 Wed, Jan 12, 2011 at 11:19 AM, Chris Mason <[email protected]>wrote: > 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 > Home of Florida's first LEED Gold Certified School Under Florida law, e-mail addresses are public records. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing. ---------------------------------------------------------------------- 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
