Connect:Direct for z/OS: Restricted Concurrent Sessions

Body

IBM Sterling Connect:Direct for z/OS can be licensed two ways for concurrent sessions. The more popular license if for unrestricted concurrent sessions. You can also get a “restricted concurrent sessions license that restricts the number of concurrent sessions provides a cost break for the customer.

It is important to understand that concurrent sessions refers to the number of processes running concurrently, not the number of remote nodes that you can be in session with concurrently. All of your "concurrent sessions" can be with one remote node, but generally they will be across multiple remote nodes. Inbound and outbound sessions are counted in your concurrent sessions limit. It is possible depending on how you code your MAXPRIMARY and MAXSECONDARY initialization parameter when running with a concurrent session limit that all of the concurrent sessions could be taken up with outbound or inbound concurrent sessions.

If you are running a legacy release of the software, pre V5.1, your concurrent session limit will be set in the license key. Beginning with V5.1 and later there is no longer a license and it is the customer's responsibility to code a MAXPROCESS initialization parameter to ensure that they do not exceed the maximum number of concurrent sessions licensed for. If the customer exceeds what they are licensed for on V5.1 and later they could be charged extra for the overage.

Regardless of whether the customer is still on legacy software (pre V5.1) or bluewash software (V5.1 and later) they should consider coding the MAXPROCESS parameter in the initialization parameters to be in the habit of coding it. Set MAXPROCESS to the concurrent session limit that the customer has contracted for. Then depending on the limit coded set MAXPRIMARY and MAXSECONDARY to a value less than the contracted limit. For example you are licensed for 10 concurrent sessions unless there is a good reason to code MAXPRIMARY and MAXSECONDARY to the maximum value it is recommended that you set each to 8. That way you will not have inbound take up all of the concurrent sessions limit which will not allow any outbound session to be set up until one of the inbound sessions end. By setting the MAXPRIMARY and MAXSECONDARY to 8 you will always have 2 sessions available for the other direction. But if you need these to be set at the concurrent session limit just be aware that your SLAs could be greatly impacted.

If you are running IBM Sterling Connect:Direct for z/OS V5.1 or later it is very important that you code the MAXPROCESS initialization parameter. If you have been in the habit in the past of coding only the MAXPRIMARY and MAXSECONDARY initialization parameters (when MAXPROCESS is not coded it will default to the sum of MAXPRIMARY and MAXSECONDARY) this could cause you to have periods where your workload exceeds the restricted number of concurrent sessions you have contracted for.