Configuring Sessions in the Netmap for Connect:Direct for UNIX

Body

Before you can configure the session values in Connect:Direct for UNIX, you need to determine the total number of sessions you are entitled to use. This is determined by your contract license agreement that you signed when you acquired the Connect:Direct software.
If you have a "Premium" license, then you can use up to 999 sessions  for all incoming and outgoing connections to remote nodes.
If you have a "Standard" license, then the license will specify the total number of sessions you are entitled to use.
It is your responsibility to know what type of license you have and the number of sessions you are entitled to use. You may need to contact your IBM Sales Representative to verify this information.
Session counts are subject to IBM audits.

Once you have determined the total number of sessions you are allowed, you are ready to configure the session parameters in the Netmap for Connect:Direct for UNIX.

Running the Connect:Direct for UNIX  server under maximum session loads can affect the overall performance of the system. The more concurrent sessions in use, the more system resources are needed such as CPU and memory capacity. Please consult your IBM Sales Representative concerning capacity planning, workload analysis, and sizing questions.

In the Netmap:

Local Node Connection Record:
There are three parameters for controlling the total concurrent sessions with which the Connect:Direct server can establish with all remote nodes.
1. sess.total - This is the total of all incoming and outgoing sessions the Connect:Direct server can establish with all remote nodes.
The sum of 'api.max.connects' and 'sess.total' cannot exceed the number of file descriptors available. A CDU server session takes up two file descriptors. The file descriptors value is system dependent. CDPMGR inherits the file descriptor limits from the environment of the user ID that starts the CDU CDPMGR service. You must define enough file descriptors to handle the total number of concurrent sessions configured.
2. sess.pnode.max - This is the total number of concurrent sessions the Connect:Direct server can establish as the Primary node with all remote nodes.
3. sess.snode.max - This is the total number of concurrent sessions  the Connect:Direct server can establish as the Secondary node with all remote nodes.

This is an example of a default Local Node Connection Record. The values given are installation defaults. The session maximum values are '999' each. Bear in mind the system resource considerations noted above.
If the 'sess.pnode.max' or 'sess.snode.max' values are set larger than the 'sess.total' value, the system will silently round the values down to the 'sess.total' value.
local.node:\
 :api.max.connects=16:\
 :sess.total=255:\
 :sess.pnode.max=255:\
 :sess.snode.max=255:\

If you have a 'Premium' license:
Set the the three session control parameters to the maximum values for the sessions you expect your Connect:Direct server to handle.
As a "Best Practice", the 'sess.total' value should be set to the sum of the 'sess.pnode.max' and 'sess.snode.max' values.
Bear in mind the system resource considerations noted above.

If you have a 'Standard' license:
Set the 'sess.total' parameter value to the number of allowed sessions specified in your license.
Now you will need to do some planning.
The 'sess.pnode.max' and 'sess.snode.max' parameter values will need to be divided out from the total sessions allowed (in your license) according to your expectations for the workload on your Connect:Direct server.
As a "Best Practice", the sum of the 'sess.pnode.max' and 'sess.snode.max' parameter values should not be greater than the value specified for the 'sess.total' parameter.
If you expect your Connect:Direct server to receive more files concurrently then send, allocate a greater number of sessions to the 'sess.snode.max' parameter.
If you expect your Connect:Direct server to send more files concurrently than receive, allocate more sessions to the 'sess.pnode.max' parameter.
Set the 'sess.pnode.max' and 'sess.snode.max' parameter values accordingly; do not exceed the session total specified in your contract license.

For any changes made to the 'local.node' record in the Netmap, you will need to restart the CDU server to pick up the changes.

Remote Node Connection Record:
Each remote node with which your Connect:Direct Server can communicate will have a record in the Netmap.
For each remote node record in the Netmap, there are three parameters for controlling the sessions with that specific remote node.
1. sess.total - This is the total of all incoming and outgoing sessions the Connect:Direct server can establish with this specific remote node.
2. sess.pnode.max - This is the total number of concurrent sessions the Connect:Direct server can establish as the Primary node with this specific remote node.
3. sess.snode.max - This is the total number of concurrent sessions  the Connect:Direct server can establish as the Secondary node with this specific remote node.

The 'sess.pnode.max' and 'sess.snode.max' parameter values can be set to '0' if desired.
As a "Best Practice", the sum total of the 'sess.pnode.max' parameter values for all of the remote node records in the Netmap should not exceed the value set for the 'sess.pnode.max' parameter in the 'local.node' record. This is not a requirement.
As a "Best Practice", the sum total of the 'sess.snode.max' parameter values for all of the remote node records in the Netmap should not exceed the value set for the 'sess.snode.max' parameter in the 'local.node' record. This is not a requirement.
As a "Best Practice", the sum total of the 'sess.total' parameter values for all of the remote node records in the Netmap should not exceed the value set for the 'sess.total' parameter in the 'local.node' record. This is not a requirement.

You may have more remote nodes then allowed sessions available. In this case you will need to assign the values as best as you can and the remote nodes will have to compete for access to the Connect:Direct server.

For all of the remote node records in the Netmap, carefully plan how to allocate the available sessions. Think about the expected workload (sending and receiving) between your Connect:Direct server and the remote nodes. Divide up the available sessions accordingly.

The Connect:Direct server will have its own record in the Netmap. This is due to the Connect:Direct server being able to specify itself as a remote node in a process. This is useful when running the Loopback test to check for normal operation of the Connect:Direct server.
For the Connect:Direct server's own Netmap record, set the 'sess.pnode.max' and 'sess.snode.max' parameter values to '1' each. Set the 'sess.total' parameter value to '2'. This is sufficient under normal circumstances. If you regularly submit processes that run on your own Connect:Direct server, then you will need to adjust these parameters to higher values.

Contact the Connect:Direct administrators for the remote nodes. They will be doing this same planning for allocating sessions on their Connect:Direct servers. Ask them how many sessions they are setting for the 'sess.pnode.max' and 'sess.snode.max' parameter values in the Netmap record for your Connect:Direct server on their node.
Negotiate and set these values on both nodes.
Set the 'sess.pnode.max' parameter value for their remote node record in your Netmap to match the 'sess.snode.max' parameter value in the Netmap record for your Connect:Direct server on their node.
Set the 'sess.snode.max' parameter value for their remote node record in your Netmap to match the 'sess.pnode.max' parameter value in the Netmap record for your Connect:Direct server on their node.
This will prevent either node from getting "session limit exceeded" errors. For both nodes, if there are more processes then sessions available, the processes will simply be queued up in the TCQ and released for processing when a session becomes available but there won't be any errors generated about session limits.

The 'tcp.ip.default' record in the Netmap:

The 'tcp.ip.default' record defines default information to use when the remote node is specified by IP address in a Pnode's process script with the 'snode=(ip_addr;port)' parameter instead of a Netmap record.
If you anticipate the use of the 'tcp.ip.defaul' record, you will need to configure the three session parameters in this record as you would for any other remote node record.

Connect:Direct for UNIX servers running behind a 'load balancer':

To a remote Snode, CDU servers running as Pnodes behind a load balancer look like a single node. You need to ensure that the 'sess.pnode.max' parameter value for the remote Snode in the Netmaps on the Pnodes behind the load balancer are divided equally to match the 'sess.snode.max' parameter value on the Snode's Netmap for your Pnodes.