DC088003 Line TCPIP Pterm TCPPTJSV listener

Document ID : KB000096834
Last Modified Date : 21/05/2018
Show Technical Document Details
Question:
What causes DC088003 Line TCPIP Pterm TCPPTJSV listener: connection rejected?
There are times when all the PTERMS defined in the QA database are unavailable and we get messages like 
DC088003 V33 T14 Line TCPIP Pterm TCPPTJSV listener: connection rejected (0000000088) 

The QA database is not THAT highly used but this has been happening more frequently lately. 

We are unable to determine who is causing this problem because there are only 1 or 2 user IDs that everyone uses to access the system, essentially blinding the database to an actual individual user. 

There are no active run units showing when this situation happens. 

It seems like there are SQL transactions coming in using ODBC or JDBC that are ending but holding on to the TCPIP PTERM/LTERM pair until something eventually times out. 

1) What is causing the SQL transaction to NOT release the LTERM? 

2) What can be done to get them to release the LTERM? 

3) What setting on IDMS controls how long the LTERM remains active with no activity? 

4) How can I release these LTERMS manually once they have all been taken and are rejecting new connections? In other words, what command is available to clear one or all of the TCPIP LTERMS to reset the connection so it is available again? I usually end up re-cycling the CV, which is unacceptable. 

 
Answer:
1) What is causing the SQL transaction to NOT release the LTERM? 

When we 'pseudo-converse' our client/server sessions the IDMS Task is terminated and the Task's storage is hung off of the LTE (just like how we do it in ADS/Online). The LTE persists as long as the Connection persists, until the front-end client application issues a Disconnect or a timeout occurs. 

2) What can be done to get them to release the LTERM? 
Either a Disconnect is issued or a timeout occurs. Since we don't always get a Disconnect we need to better configure the timeouts. 

3) What setting on IDMS controls how long the LTERM remains active with no activity? 
How is the task IDMSJSRV defined? specifically the following parameters: 
RESOURCE INTVL 
EXTERNAL WAIT 
QUIESCE WAIT 
INACTIVE/STALL INTVL 
This can be found with the command: 
DCMT D TASK IDMSJSRV 

You want to check the RESOURCE INTERVAL and the INACTIVE/STALL interval for the IDMSJSRV task. 
The RESOURCE INTERVAL timer for the IDMSJSRV task will fire whenever a connection lies in wait when no task is actively running. This kind of condition occurs when a front-end ODBC/JDBC client fails to properly terminate the connection (which can happen for any number of reasons). 
Is connection pooling involved in these connections? If so, then we have to consider the 'Idle Time' specification for the connection pool, as our RESOURCE INTERVAL for the IDMSJSRV task must always be greater than this parameter. We always want the connection pool manager to terminate our pooled connections. 
If connection pooling is not involved, then typically a value of 60 is appropriate for the RESOURCE INTERVAL. 
We might also suggest that the EXTERNAL WAIT time be reduced (for the IDMSJSRV Task of course) depending on its value. The EXTERNAL WAIT timer kicks off whenever an active task lies in wait for the specified period. 
Depending on the SUSPEND STRATEGY definition for the connection, the IDMSJSRV Task can persist after a query is finished. The task will then sit idle until a Disconnect is issued from the application (or pool manager) or the EXTERNAL WAIT timer pops. In most cases, the EXTERNAL WAIT timer can also be set to around 60 seconds. 
Note that these are general recommendations... We'd need to know the make-up of the applications using this task before we can make more specific suggestions. 

4) How can I release these LTERMS manually once they have all been taken and are rejecting new connections? In other words, what command is available to clear one or all of the TCPIP LTERMS to reset the connection so it is available again? I usually end up re-cycling the CV, which is unacceptable. 

You can vary the TCPIP line offline and online to free up the terminals. 

Please let me know what you find and if you have any questions. 
There is also a knowledge document KB 000011293 that discusses timeout parameters in more detail.