George Some percentage of your confusion may be removed when you appreciate that my responses do not emerge fully outfitted from the head of Zeus but take a while to compose - while I find the appropriate references, for example.
Thus my second post was a continuation of my first post in reply to your original post and, in case this is the source of your confusion, nothing to do with your first response. However, I believe I am now the one with a right to be confused. Which product is it that is producing the messages with the "TELNE" prefix? You appear to associate them with CICS so it would imply that whatever product is creating the messages has something to do with CICS. It was implicit in my previous two responses that the "TN3270E" to which you referred in your original post was the z/OS Communications Server (CS) TN3270E server. Indeed you then post a subset of the TN3270E parameters. I am aware that there are CICS "signon" and "signoff" transactions, CESN and CESF, IIRC. I suppose that some product could be logging these transactions. But then the mystery deepened as I noticed that the "signon" and "signoff" messages had a numeric part which looked as if it might be some sort of 3- digit channel address ... I actually had a few more points to raise following your second post giving the TELNETGLOBALS block but I think I need some clarification over what your current configuration is - and what your previous configuration was. Also, if you really are using the z/OS CS TN3270E server, I think the whole of the TN3270E PROFILE should be included - with two limitations: 1. Be sure that the TN3270E PROFILE file contains *only* the TN3270E statements. I believe, given that you would have recently set it up, this will be the case. 2. If you have masses of "mapping" statements, supply only a set relevant to one of the TN3270E clients with which you are having a problem. In case it is not clear, the reason I find your third post no help whatsoever is that it seems to imply CICS is in some sort of way supporting the TN3270E server function. This is not what I expected at all. All CICS should be able to "see" is a session, when it starts, when it stops and why it stops and, of course, any transactions the end user runs. I was going to say that CICS is quite unaware that the SNA session supported by CICS is concatenated to a TN3270E TCP connection. If it is presented with a "control vector" X'64' (CV64) in the exit used to initiate the SNA session, it will "know" that way beyond the TN3270E server is a logical continuation of the session associated with an IP address and a port number and, if the TN3270E server has been induced to use the "resolver" in order to translate the IP address into a name to go with the IP address. In any case, whatever the configuration, you will need to identify exactly which event is causing the ending of the association between CICS and whatever is supporting the TN3270E function in such a way that the USS 10 message appears. Those CICS messages are no help I'm afraid. You should be looking at logs for all the components involved and, if nothing shows up, taking traces for the relevant components in whatever order seems most likely to be productive. You are fortunate that you appear to have a reproducible problem. Chris Mason On Wed, 12 Jan 2011 12:26:52 -0500, George Rodriguez <[email protected]> wrote: >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
