Anticipated Number of Concurrent Sessions - Call-Level Interface Version 2

Teradata Call-Level Interface Version 2 Reference for Mainframe-Attached Systems

Product
Call-Level Interface Version 2
Release Number
15.10
Language
English (United States)
Last Update
2018-10-07
dita:id
B035-2417
lifecycle
previous
Product Category
Teradata Tools and Utilities

Anticipated Number of Concurrent Sessions is a four-byte field that refers to the maximum number of sessions expected to be concurrently established.

 

Language

Variable

COBOL

DBCAREA‑MAX‑NUM‑SESS

PL/I

MAX_NUM_SESS

C

max_num_sess

IBM Assembler

DBCISMAX

 

Routine

Action

DBCHINI

writes

DBCHCL

reads (CON; RSUP; IRQ; IWPF; CMD)

DBCHWAT

 

 

Maximum Number of Sessions is used by...

To...

applications

write

The value of zero for Anticipated Number of Concurrent Sessions indicates that the default value from the HSHSPB is used for the Anticipated Number of Concurrent Sessions. The application may change the value of Anticipated Number of Concurrent Sessions by supplying the preferred value in the DBCAREA. The minimum value is 1, and the maximum value is 999.

Anticipated Number of Concurrent Sessions is used for two purposes. When CLIv2 must wait for one or more sessions to complete, it must build a list of system-dependent control blocks on which it will wait. If CLIv2 obtains a list of a particular size and then on a subsequent call needs a larger list, it must free the existing list and obtain a larger one. You can avoid this overhead by obtaining an appropriately sized list the first time. CLIv2 rounds the specified value up to the next multiple of 16 and obtains a list of this size.

When a request or response is processed, CLIv2 must lookup the CLIv2 internal information for that session. The larger the number of simultaneous sessions, the less efficient such session lookup can be. CLIv2 uses the value set for the Anticipated Number of Concurrent Sessions when the first session is connected to optimize the internal lookup algorithm. So setting an accurate value initially can reduce the CPU used by CLIv2 on all subsequent calls.