After an application inactivity timer expires, the user cannot get back to the application and there are TCP/IP errors.
search cancel

After an application inactivity timer expires, the user cannot get back to the application and there are TCP/IP errors.

book

Article ID: 54403

calendar_today

Updated On:

Products

Teleview TELEVIEW- PACKAGE TPX - Session Management Vman Session Management for z/OS

Issue/Introduction

Description:

  • We have the Teleview session manager and an IBM TCP/IP stack.

  • The TCP/IP stack users are static defined - one IP address to one LU name.

  • When the user goes to a defined DEFAULTAPPL port, it gives them the Teleview banner.

  • The user logs onto Teleview and selects an application that has a timer for inactivity. When the application inactivity timer goes off the users appears to be out of the application but not out of Teleview.

  • The user tries to come back in but the TCP/IP stack says: (which is true because the user is static defined, one IP address to one LU) 
    STC07501 EZZ6035I TELNET DEBUG DETAIL CLIENT 159IP..PORT: XXX.XX.XXX.XX..XXXXCONN: 000859D8 LU: MOD: EZBTPGLURCODE: 3003-00 LUs are all in use.PARM1: 00000000 PARM2: 00000000 PARM3: T12262L1

====

We have a new wrinkle in this problem: a Firewall.

There is a firewall that issues a kill or disconnect after one hour of inactivity but TCP/IP does not get the notification and still holds the session until it's TCP/IP timers kick in--the default TIMEMARK value of 10,800 seconds (3 hrs)--and finally kills the session.

This explains the behavior:

  • The user logs on to a DEFAULTAPPL port and gets the session with that applid.

  • User selects an application that has a timer in it of 20 minutes.

  • The user is away from his session for more than 20 minutes and the application timer kicks in and kills his session.

  • Now the user is back to the session manager's main page which is correct at this point.

  • The user stays away and now one hour has past so the Firewall timer kicks in and kills the session; however, TCP/IP does not know about it and is still holding the session.

  • If the user comes back after one hour but before the TCP/IP timer of three hours, he can not get a session because TCP/IP will put out this message because the user does not come from a pool but rather a static definition 
    STC07501 EZZ6035I TELNET DEBUG DETAIL CLIENT 275IP..PORT: XXX.XX.XXX.XX..XXXXCONN: 000A30B9 PARM3: T1EC49L1LU: MOD: EZBTPGLURCODE: 3003-00 LUs are all in use.PARM1: 00000000 PARM2: 00000000

Solution:

TCP/IP timeout settings need to be less than the firewall timeout.

You need to ensure that TCP/IP kills the session before the Firewall timer removes the session from its STATE list. Otherwise, TCP/IP does not know that the session has been terminated by the firewall and you will see errors similar to what is described here.

Check with your TCP/IP vendor's recommendations for configuring timeout when there is a firewall in place.

Environment

Release:
Component: TLVIEW

Resolution

TCP/IP timeout settings need to be less than the firewall timeout.

You need to ensure that TCP/IP kills the session before the Firewall timer removes the session from its STATE list. Otherwise, TCP/IP does not know that the session has been terminated by the firewall and you will see errors similar to what is described here.

Check with your TCP/IP vendor's recommendations for configuring timeout when there is a firewall in place.

Powered by Wolken Software