IBM Support

Configuring Sessions in Initparms and Netmap for Connect:Direct for Windows

Technical Blog Post


Abstract

Configuring Sessions in Initparms and Netmap for Connect:Direct for Windows

Body

Connect:Direct for Windows - Configuring Sessions in Initparms and Netmap

This information applies to all versions of Connect:Direct for Windows.

Before you can configure the session values in Connect:Direct, 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 255 sessions each for 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 for Connect:Direct for Windows.
Session parameters are defined in two locations - in the Initparms and in the Netmap records.

In the Initparms:
Prior to Connect:Direct for Windows v4.6.0.3 iFix 020, in the Initparms, there are two  session parameters - 'sess.pnode.max' and 'sess.snode.max'.
Starting with Connect:Direct for Windows v4.6.0.3 iFix020 and continuing through to the current version, the 'sess.total' parameter was introduced.
Following are explanations of how to configure these parameters.

1. sess.pnode.max - This is the total number of concurrent sessions the Connect:Direct server can establish for sending files to remote nodes. The value can be set to a maximum of 255.
2. sess.snode.max - This is the total number of concurrent sessions the Connect:Direct server can establish for receiving files from remote nodes. The value can be set to a maximum of 255.
3. sess.total - This is the total number of sessions specified by your contract license agreement. Setting this parameter will prevent you from exceeding your license session limits if you happen to incorrectly specify the values for the 'sess.pnode.max' and 'sess.snode.max' parameters.

If you have a 'Premium' license:
Set 'sess.pnode.max=255' and 'sess.snode.max=255'.
Set 'sess.total=510' (if your Connect:Direct for Windows version has this parameter).

If you have a 'Standard' license:
Set the 'sess.total' parameter value to the number of allowed sessions specified in your license (if your Connect:Direct for Windows version has this parameter).
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.
The sum of the 'sess.pnode.max' and 'sess.snode.max' parameter values can not be greater than the number of sessions specified in your contract license agreement.
If you expect your Connect:Direct server to receive more files concurrently then send, allocate a greater number of sessions to '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 the license.

In the Netmap:
Each remote node with which your Connect:Direct Server can communicate will have a record in the Netmap.
Each Netmap record has two parameters for controlling concurrent sessions with the remote node.
1. Max Pnode Sess - This is the total number of concurrent sessions the Connect:Direct server can establish with this specific remote node for sending files.
2. Max Snode Sess - This is the total number of concurrent sessions the Connect:Direct server can establish with this specific remote node for receiving files.

The sum total of the 'Max Pnode Sess' 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 Initparms.
The sum total of the 'Max Snode Sess' 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 Initparms.

The 'Max Pnode Sess' and 'Max Snode Sess' parameter values can not be set to '0', the minimum is '1' for each.
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.
For the Connect:Direct server's own Netmap record, set the 'Max Pnode Sess' and 'Max Snode Sess' parameter values to '1' each. This is usually sufficient under normal circumstances.

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

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 'Max Pnode Sess' and 'Max Snode Sess' parameter values in the Netmap record for your Connect:Direct server on their node.
Negotiate and set these values on both nodes.
Set the 'Max Pnode Sess' parameter value for their remote node record in your Netmap to match the 'Max Snode Sess' parameter value in the Netmap record for your Connect:Direct server on their node.
Set the 'Max Snode Sess' parameter value for their remote node record in your Netmap to match the 'Max Pnode Sess' parameter value in the Netmap record for your Connect:Driect 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.

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SS4PJT","label":"IBM Sterling Connect:Direct"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]

UID

ibm11123641