Body

Connect:Direct for Windows Default Class

Have you ever wondered what the Default Class set in the Initparms, default Class in the netmap, and the Class in a Connect:Direct process means; or what impact changing these settings might have?

For the purposes of this article I will be using these assumptions:

1.) The initparm settings are:

   A.) sess.pnode.max=10

         sess.snode.max=10

         sess.total=10

         sess.default=1

2.) The netmap settings for the remote node are:

  A.) SessPnodeMax=10

        SessSnodeMax=10

        DefaultClass=1

3.) The Connect:Direct process used:

   /*BEGIN_REQUESTER_COMMENTS

    $PNODE$="MyNODE.CD470" $PNODE_OS$="Windows"

    $SNODE$="PARTNER.CD460" $SNODE_OS$="Windows"

    $OPTIONS$="WDOS"

  END_REQUESTER_COMMENTS*/

 SAMPLE PROCESS

               SNODE=PARTNER.CD460

 STEP1 COPY

               FROM (

                              FILE="C:\Program Files (x86)\Sterling Commerce\Connect   Direct v4.7.0\Server\Process\Sample.cdp"

               )

               TO (

                              FILE="C:\Program Files (x86)\Sterling Commerce\Connect Direct v4.7.0\Server\Download\Verify.cdp"

                              DISP=RPL

               )

PEND

The initparms indicate the node is licensed for 10 total sessions and up to 10 can be used for either inbound (sess.snode.max) or outbound (sess.pnode.max) or a combination not to exceed a total of 10.  The sess.default is set to 1, this is the default setting for the class.

In this case the netmap reflects the same settings as the initparms.  This, however, is not a requirement.  The settings between the initpam and netmap can differ and there might be scenarios where it is a more efficient use of sessions if they do not.  If the settings in the netmap differ from the initparms, the netmap settings will take precedence.

In looking at the example process you will notice that there is no class keyword.  The process will therefore use the netmap's default class setting.

What exactly does "class" mean to Connect:Direct?  Using the assumptions above, the node has a total of 10 sessions that are available for use. 

If you assign a number to these sessions, 1 to 10, the class of a session would equate to its number.  So that class 1 would the first session, class 2 would be the second session, etc.  Out of the box the default class in any netmap entry is 1.  When your process is submitted it is going to execute as class 1.  It will execute as class 1 because there is no class keyword defined in the process and the netmap default class is set 1.  At execution this means that the process can execute on its class or any higher class.  In other words it has all 10 sessions to select from to execute.

Now, what happens if you go in and assign a class to the process?

 /*BEGIN_REQUESTER_COMMENTS

    $PNODE$="MyNODE.CD470" $PNODE_OS$="Windows"

    $SNODE$="PARTNER.CD460" $SNODE_OS$="Windows"

    $OPTIONS$="WDOS"

  END_REQUESTER_COMMENTS*/

 SAMPLE PROCESS

               SNODE=PARTNER.CD460

               CLASS=3

 STEP1 COPY

               FROM (

                              FILE="C:\Program Files (x86)\Sterling Commerce\Connect   Direct v4.7.0\Server\Process\Sample.cdp"

               )

               TO (

                              FILE="C:\Program Files (x86)\Sterling Commerce\Connect Direct v4.7.0\Server\Download\Verify.cdp"

                              DISP=RPL

               )

PEND

In the example above you will see the class has been set to 3.  In this case when the process executes it will have access to its stated class, 3, and higher.  In other words it has access to sessions 3 through 10, only 8 of the 10 total sessions.

Right now you might asking yourself, as I did initially, that's all very interesting but why would I want to pay for sessions I can't use?  After thinking about it for a while I thought...service level criteria.  Consider the following scenario.

You have a trading partner, call them Parnter1.  You have allocated 10 of your total licensed sessions for use with Partner1.  You have a pretty high volume of business going on with Partner1 and therefore a pretty heavy volume of routine transfers, in fact it is very common to exhaust the sessions to Partner1 so a significant number of the transfers will go into a wait state waiting for sessions to become available.  Now assume you have several transfers that have to happen but are they extremely time sensitive and you cannot afford for them to go into a wait state waiting their turn to transmit their data.  Depending on how many of these time sensitive processes you have you could go into your netmap entry for Partner1 and set DefaultClass=2 or 3 depending on need.  Now you routine processes will run at the default class, class 2(or 3) or higher.  For you time sensitive processes you code the CLASS parameter, CLASS=1, in the process.  When you execute your time sensitive process it will execute using any session including class 1 that the routine processes do not have access to.  Your time sensitive process will not have to wait for a session like many of the routine processes do.

Now assume the netmap for Partner1 has the settings of:

        SessPnodeMax=4

        SessSnodeMax=4

        DefaultClass=1

You have to run some processes periodically (say weekly or monthly) that are transmitting very large files and run for a very long time.  You have been running these long running processes at the same time and when you run them they are tying up sessions and drastically impacting normal production.  You can't increase the number of sessions, what can be done?

If you will code CLASS=4 for these long running processes they will run sequentially using only 1 of the 4 sessions leaving the other 3 sessions available for normal production.  While there still might be some impact on normal production, but the impact will be reduced.

As you can see, with an understanding of the sess.default, or class, value you do some fine tuning of your Connect:Direct traffic by giving priority to some processes if it is required.