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
