none
APPC Session Timeout RRS feed

  • Question

  • I am running HIS 2004 server on a Windows 2003 server, which is connecting successfully with an IBM host using APPC over an SDLC connection. I can see the sessions in the Local and Remote APPPC LUs.

    The problem is that the sessions dont seem to be timing out quickly enough and when the Mode Limit is reached the server refuses to accept any more connections. Client connections also dont always seem to be reused, making the problem worse.

    Friday, February 11, 2011 1:46 PM

Answers

  • Stephen
     
    I've been doing a little bit of research into how "contention loser" sessions can get used as well as "contention winner" sessions. It's a simple matter of a parameter associated with the initiation of a conversation. As described by LU type 6.2 "mapped conversation verbs" it's a MC_ALLOCATE with RETURN_CONTROL = WHEN_SESSION_ALLOCATED or WHEN_SESSION_FREE. Both of these options, as opposed to, for example, WHEN_CONWINNER_ALLOCATED or IMMEDIATE, allow an LU to "bid" for use of a "contention loser" session in order to support a conversation. I *think* - since the only manual that has the details is a bit too detailed! - there could be an extra exchange in the case of a "bid" for a "contention loser" session but the overhead is not that much.
     
    Strangely enough, if you ever get down to this level in, say, analysing traces, for the "bid" process, don't go looking for the BID request unit. It's not used for LU type 6.2.
     
    I see that your SESTIMEOUT specifically deactivates only contention winner sessions but doesn't bother with insisting that the "limited resource session" bit has been recorded as being set in the BIND response. So now I know why Peter was entitled to expect that his APPC sessions "timed out". It's a Microsoft HIS speciality!
     
    I note that, because of the usual mode of operation of HIS-based transactions with respect to, say, CICS, you expect always to be the side initiating conversations. Thus you would normally want your CNOS numbers to be a certain number of sessions, N, where there were N contention winner sessions and 0 contention loser sessions.
     
    However, should it be sensible for CICS to have contention winner sessions, you could prompt CICS to end its contention winner sessions by setting the "limited resource session" bit in the BIND response sent back to CICS. I checked the relevant CICS manual and it appears that CICS will immediately end a "limited resource session" as soon as the conversation finishes rather than having a configurable delay which is - well - a bit limited!
     
    VTAM's support for LU type 6.2 - which CICS does *not* use - is a little more flexible in having the APPL statement LIMQSINT operand value as the delay. It may be sometimes your customer's partner is a program based on VTAM support for LU type 6.2 - the APPL statement will specify APPC=YES - and so, in those cases, LIMQSINT should be considered.
     
    Chris Mason
    Saturday, March 5, 2011 11:59 AM

All replies

  • Lankylad
     
    First I should say I am not at all a HIS specialist - no doubt one of those eminent people will contribute eventually - so it may be that something obvious known to all HIS users is at the heart of your query. However, I do know a thing or two about SNA and related topics such as APPC - which is why my nose appears in this "forum" - and so I feel able to make a few tentative comments.
     
    > The problem is that the sessions don't seem to be timing out quickly enough ...
     
    What's wrong with this statement is that the *session* in SNA has no sense of time[1]. In SNA, the detection of lack of activity for the purposes of determining that a node adjacent over a link appears no longer to be functioning - either because it truly is no longer functioning or because the media supporting the link is no longer functioning - is delegated to the logic supporting the link.
     
    The concept of "timing out" belongs solely to the "data link control" (DLC) logic in SNA whether this is SDLC or IP-DLC, aka Enterprise Extender, or any other type of DLC.
     
    > ... and when the Mode Limit is reached the server refuses to accept any more connections.
     
    In SNA, I am familiar with the "detection of failure" use of "timing out" but not with what might be understood as your concept of "freeing resources". This latter I have encountered only in configurations involving TELNET, specifically TN3270 where the detection of lack of traffic on an idle SNA session concatenated to a TELNET TCP connection can lead to the TELNET server at the point of concatenation ending both the session and the TCP connection for the purposes of freeing the resources associated with the session in the 3270 SNA application and the TELNET server itself.
     
    > ... and when the Mode Limit is reached the server refuses to accept any more connections.
     
    In any case this is a confused statement. The APPC "mode limit" has nothing whatsoever to do with "connections". You may have meant "conversations".
     
    Let us assume you do mean conversations. The fact that no more conversations are accepted when the current number of simultaneous conversations, each taking place over a session so that there is an equal number of sessions in place, is what the "mode limit" is all about. It is a limit. When one of those conversations ends, the associated session is free to accept and support a new conversation. The "mode limit" is there in order to ensure that the number of parallel sessions established in order to support conversations cannot increase ad infinitum.
     
    If you actually want more simultaneous conversations, you must arrange that the two APPC partners establish more parallel sessions by increasing the limit to the number of sessions associated with the mode name specified for those parallel sessions. This is APPC "business-as-usual" as you will have learned about it in your APPC class.
     
    > Client connections also don't always seem to be reused, making the problem worse.
     
    I don't understand what you might mean by the first part of this statement. Perhaps this concerns some part of the HIS communication outside SNA since "client connection" makes no sense in an SNA context. In SNA APPC, "sessions are reused by conversations" is as close as I can get to your use of the word "reused".
     
    Chris Mason
     
    [1] That sounds like what husbands used to say about wives in the days before such sentiments were deemed politically incorrect!
    Friday, February 11, 2011 3:16 PM
  • Thanks Chris.

    I do indeed mean conversation so apologies for my sloppy description.

    Historically, HIS has created 4 default sessions which have always been adequate for the number of conversations in use (which by their natuire are very small and fast). But something has changed. Sessions no longer seem to be being reused in the same way and the number steadily increases to 8 at which point no more can be accepted. I can see sessions disappearing from time to time, which made me assume that they were timing out. I have several servers running HIS client connections and these seem to create multiple APPC sessions.

    I have no control or understanding over the mainframe end of this link. Is it possible that something may have been changed there that would create this behaviour?

    Peter

    Wednesday, February 16, 2011 6:39 PM
  • Peter
     
    Thanks for the clarification/confirmation.
     
    It's a while since I dealt with "Change Number of Session" (CNOS) operations in any sort of configuration. I vaguely recall that, so many sessions are created when the first session, the SNASVCMG session is established, so many for conversations initiated by side A and so many for conversations initiated by side B. Should either side A or side B need more because all current sessions are in use, more sessions can be initiated up to a limit.
     
    Well, I remembered I had some presentation material from when I used to teach various SNA topics and so I dug it out. It may be that it has part of the answer to what you are seeing.
     
    This is the text from the presentation visual and notes. It's a bit of work since I have to remove all the formatting tags. Here goes!
     
    <presentation material>
     
    How many sessions to support conversations ?
     
    - contention winner sessions
     
    - total number of sessions
     
    > Change Number of Sessions (CNOS) function
     
    > supported by session with mode name: SNASVCMG
     
    When are sessions activated ?
     
    - on activation of connection or conversation request
     
    What to do with idle sessions ?
     
    - may terminate when no conversations (after delay)
     
    Notes:
     
    How many sessions to support conversations ?
     
    An installation may want to ensure that node resources are not consumed indefinitely by conversation allocation requests causing sessions to be started. Thus a maximum on the number of sessions can be specified in each of the partner nodes. Note that the number is for each mode name that may be requested.
     
    Also within the mode name, sometimes called the mode set, is a maximum number of sessions on which conversations can be allocated without "asking permission" from the partner node for use of the session. This is the maximum number of contention winner sessions. The difference between the two numbers is the number of contention loser sessions.
     
    The first session that is established with the partner is the session which supports the Change Number of Sessions (CNOS) function. This session is identified by the mode name SNASVCMG and it resolves downwards any differences there may be between these numbers as defined in the two partner nodes. In case the node operators subsequently change these numbers, the session with mode name SNASVCMG is used to communicate these changes to the partner LU.
     
    When are sessions activated ?
     
    Contention winner sessions can be started as the LU is activated - of course, the partner LU must be available - or as a result of conversation allocation requests.
     
    What to do with idle sessions ?
     
    Sessions normally stay active once initiated, even following the termination of the conversation that may have been the reason the session was activated.
     
    Sessions not carrying conversations for a period of time may be deactivated if the BIND used to initiate them returns a response which indicates that at least one of the connections used by the session is a limited resource. After a period of time determined by the implementation, the idle session is deactivated. This provides the opportunity to disconnect the connection identified as the limited resource when no more sessions are using the connection.
     
    </presentation material>
     
    I'm afraid I forgot about the "limited resource" aspect last time. In a sense you are correct in there being a "time-out" which is this "limited resource" mechanism.
     
    In VTAM, this is a very messy area. There are two timing parameters involved. The one which affects the termination of APPC sessions is the value of the LIMQSINT operand of the APPL statement with APPC=YES - or if the VTAM application is CICS, which developed APPC support long before the VTAM native APPC support, some parameter within CICS.
     
    Here is the description:
     
    <quote>
     
    LIMQSINT=timeout_value
     
    dependencies: APPC=YES
     
    range: 0–65535 seconds
     
    Specifies how often VTAM searches the queue for unused LU 6.2 contention winners.
     
    If LIMQSINT=0, contention-winner LU 6.2 limited resource sessions are terminated immediately after their conversations end.
     
    As a starting point, timeout_value should be at least one second less than half of the shortest time cost interval. For example, if the time cost interval for a line is 120 seconds, you should specify 59 seconds. Because applications can work differently, you might need to adjust the time cost interval as necessary.
     
    Sessions that are active for longer than the timeout_value seconds are deactivated on the expiration of the timer and the next queue search.
     
    </quote>
     
    You'll note how this is oriented to running connections over media which cost money to run.
     
    There is no default value for this operand - unless you logically assume it is infinity.
     
    It's possible that there is a parameter in HIS equivalent to LIMQSINT. It is strictly necessary in order fully to implement the mechanism associated with the "limited resource" bit in APPC. However I fear HIS has before shown itself deficient in providing comprehensive support for SNA.
     
    There is another timing parameter which is the potential delay after all sessions have been "seen" to disappear or no traffic if the monitoring node does not have awareness of sessions as can happen with intermediate nodes using APPN/HPR. This parameter is a time value specified by the DISCNT operand of the PU statement which provides the parameters for the VTAM end of the connection.
     
    It is another parameter of the DISCNT operand, YES or DELAY (not NO, the default) which causes a bit to be set in the BIND request or BIND response when the APPC session is established. If either of the end-points in the APPC session "sees" this bit set, it implements the "time-out" mechanism which in VTAM APPC support is defined by the LIMQSINT operand value.
     
    Just one more final complication on the VTAM side. What I have described is a logical and consistent story as far as VTAM is concerned which is rather poorly described in the manuals. However, the water can be rendered a bit muddy by quite independently of the PU statement DISCNT operand, the PU statement can specify LIMRES=YES which simply causes the "limited resource" bit to be set.
     
    Thus, if your configuration is defined - or has perhaps recently been redefined - presumably on the VTAM side rather than the HIS side which you appear to control so that either the LIMRES=YES specification has been added or the DISCNT=(YES,...) or DISCNT=(DELAY,...) specification has been added - and - the LIMQSINT operand of the APPL statement is set - or - the CICS equivalent - or - an HIS equivalent, this can cause sessions to be terminated following conversations having ended. However, in the case of the use of the DISCNT operand, the connection itself will be broken when the last session ends after the count of conversations drops to zero for a sufficiently long period.
     
    You need to understand all the HIS parameters which could affect your APPC configuration - perhaps the usual specialists will eventually respond.
     
    You need also to discuss the APPC parameters used by your VTAM and CICS (if appropriate) specialists in order to develop a complete picture of the APPC mechanisms in play.
     
    Chris Mason
    Thursday, February 17, 2011 2:38 AM
  • Peter,

    You didn't mention which APPC Mode is being used by your application, but many of the default APPC Modes that are defined in the HIS configuration are setup for a Parallel session limit of 8 (to match IBM defaults for the same mode, e.g. #BATCH).

    This means that when CNOS is done, the parallel session limit is negotiated. If both sides are set to 8 (using this example), then you will be able to have up to 8 concurrent APPC sessions across the Local APPC LU/Remote APPC/Mode triplet. It sound like there are now enough clients making requests that you have reached 8 sessions. I have to assume (without any data to verify it) that you see 8 all the time because there are enough transaction requests coming in that as soon as one APPC conversation is complete, another one is processed. This would keep the session count at 8.

    HIS does not close out an APPC session until 20 seconds after a conversation ends. This is a performance feature because the assumption is that another request for the same APPC triplet may come in. By keeping the session up, we save some APPC conversation startup overhead.

    If users are seeing delays in processing, it is likely because requests are being queued up due to the session limit.

    If this is the case, then you could increase the parallel session limit in the HIS mode definition and on the matching mode definition on the mainframe so that you can get more than 8 concuurent sessions.

    As Chris explained, there are other parameters int he APPC mode definition such a the contention winner limts that he mentions. The contention winner indicates which end of the session request can activate the session without "approval" from the other end.

    Thanks...

     


    Stephen Jackson - MSFT
    Friday, February 18, 2011 3:39 PM
  • Thanks Chris, I'll take your suggestions up with the mainframe end of the link
    Tuesday, February 22, 2011 2:05 PM
  • Thanks Stephen and Chris,

    I'm using a bespoke mode which in HIS has a Parallel Session Limit of 16, a Contention Winner Limit of 4, a Partner Contention Winner Limit of 2 and an Automatic Activation Limit of 2.

    The sessions build up from 4 to 8 and then new sessions are refused. Occasionally a session will disappear, but this is certainly not in 20 seconds (more like 5 minutes).

    The sessions themselves should typically last for just a few seconds, and the volume of them is quite low.

    The problem seems to have started when we changed the way that our application accesses the SNA Service.

    Historically, the HIS client sessions were initiated by anonymous users of an ASP website using methods in a legacy COM DLL. The DLL was configured in MTS using a different user to the web which had permissions to utilise the HIS Client/Server service.

    The problem seems to have started when we upgraded the ASP website to ASP.NET running under impersonation. The new website now accesses the same legacy COM DLL via a proxy (using tlbimp). The DLL is operating under MTS as before.

    Peter

    Tuesday, February 22, 2011 2:45 PM
  • The parallel session limit shouldn't be impacted at all by the access method (anonymous vs. impersonation). If you cannot go beyond 8 sessions and the HIS mode defintion has 16, then I suspect that the mode definition on the mainfrmae side is set to 8 parallel sessions. CNOS negotiates to the lower value if there is a conflict.

    The only way for me to see what is happening with the sessions is to have a look at some HIS traces captured using the snatrace.exe utility. In this case, the necessary traces would be:

    SnaServer: LU 6.2 Messages and Data Link Control under the Message trace tab.

    Ideally, the traces should be enabled with the SNa Server service stopped so that they will capture the CNOS process when the service is started.

    Thanks...


    Stephen Jackson - MSFT
    Tuesday, February 22, 2011 2:52 PM
  • Stephen
     
    Sorry about this being a bit late. It got prepared but not sent.
     
    > ... then you will be able to have up to 8 concurrent APPC sessions across the Local APPC LU/Remote APPC/Mode triplet.
     
    I'll admit that it's a slightly gray area for me but, if all session imitation is from one side the maximum number possible will tend to be limited to the "contention winner" count which, for any one of the partners, is 4.
     
    I believe it is a feature of APPC that one partner can request to use the "contention winner" session of the other partner but I've never - with very limited experience - found that happening.
     
    > HIS does not close out an APPC session until 20 seconds after a conversation ends.
     
    Does this happen independently of the "limited resource session"[1] bit being set?
     
    Does HIS routinely mark *all* sessions as "limited resource session"?
     
    Does HIS restrict this behaviour to only its "contention winner" sessions?
     
    > This would keep the session count at 8.
     
    If HIS is assuming and setting "limited resource session" for all sessions, it should only be deactivating the sessions for which the HIS side is "contention winner".
     
    > By keeping the session up, we save some APPC conversation startup overhead.
     
    In VTAM (and CICS AFAIK), sessions are maintained by default. It is only when the "limited resource session" bit is set that VTAM will entertain the idea of ending the session. However, if HIS always sets the "limited resource session" bit, VTAM will oblige for its "contention winner" sessions - under the control of the value of the LIMQSINT operand.
     
    Chris Mason
     
    [1] Note that it is important to distinguish "limited resource session" and "limited resource link". The latter can also be known as, in effect, a "deactivate when idle" link. If any link, strictly adjacent link station is marked as a "limited resource link", any passing BIND request or BIND response sent out over the link is marked by setting the "limited resource session" bit on, byte 25 (0 origin) bit 1 (0 origin). It is possible to decide to set the "limited resource bit" on independently. This is the LIMRES=YES specification in VTAM.
    Friday, March 4, 2011 9:57 AM

  • Stephen
     
    > If you cannot go beyond 8 sessions and the HIS mode definition has 16, then I suspect that the mode definition on the mainframe side is set to 8 parallel sessions. CNOS negotiates to the lower value if there is a conflict.
     
    This is that - for me and maybe you - murky area again. One side of an APPC set of parallel sessions can start conversations unconditionally *only* over the "contention winner" sessions. I believe there are APPC protocols which allow the "contention loser" sessions to be used - obviously with some sort of permission from the APPC partner for whom the sessions are "contention winner" sessions - but it may be that the program doesn't indulge in the use of these additional protocols and so contents itself with the "contention winner" sessions - to the consternation of the observer!
     
    Peter
     
    It might be interesting if you could show some display of the CNOS numbers on initiation and then when the limit is reached.
     
    Just to be sure everyone is in perfect agreement - even if it's not the agreement you want! - you should ask for the following from the VTAM side:
     
    DISPLAY NET,CNOS,ID=appl_name,LUNAME=lu_name,LOGMODE=logon_mode_name
     
    Note that there is a MODIFY NET,CNOS command which can be used to change numbers dynamically and I guess there may be HIS commands which can do the same. Both should provoke changes in the CNOS numbers.
     
    Chris Mason
    Friday, March 4, 2011 10:03 AM
  • Chris,

    I have seen many LU 6.2 traces for customer APPC applications where they end up getting a "contention loser" session. It usually occurs because there isn't enough planning around how many concurrent APPC transactions they will have so that the APPC mode definitions are not correctly defined to insure that they allocate enough "contention winner" sessions for the HIS side.

    In most cases, our customers are using applciations that initiate the transaction requests so they should all be contention winner session to save that extra bit of overhead.

    I'm not aware of our "delay" in deallocating a session being related to the "limited resource" setting. I never encountered the "limited resource" parameter until it came up for the IP-DLC issues where we ended up making a change to all that to be configurable.

    If another request does not come across that particular APPC triplet (Local APPC LU/Remote APPC LU/Mode) within 20 seconds of the previous conversion ending, the SNA Server service simply unbinds the session. This is configurable as described in the following KB:

    831976 Description of the SESTIMEOUT parameter that is used by the SNA Server service
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;831976

    Thanks...


    Stephen Jackson - MSFT
    Friday, March 4, 2011 9:42 PM
  • Stephen
     
    I've been doing a little bit of research into how "contention loser" sessions can get used as well as "contention winner" sessions. It's a simple matter of a parameter associated with the initiation of a conversation. As described by LU type 6.2 "mapped conversation verbs" it's a MC_ALLOCATE with RETURN_CONTROL = WHEN_SESSION_ALLOCATED or WHEN_SESSION_FREE. Both of these options, as opposed to, for example, WHEN_CONWINNER_ALLOCATED or IMMEDIATE, allow an LU to "bid" for use of a "contention loser" session in order to support a conversation. I *think* - since the only manual that has the details is a bit too detailed! - there could be an extra exchange in the case of a "bid" for a "contention loser" session but the overhead is not that much.
     
    Strangely enough, if you ever get down to this level in, say, analysing traces, for the "bid" process, don't go looking for the BID request unit. It's not used for LU type 6.2.
     
    I see that your SESTIMEOUT specifically deactivates only contention winner sessions but doesn't bother with insisting that the "limited resource session" bit has been recorded as being set in the BIND response. So now I know why Peter was entitled to expect that his APPC sessions "timed out". It's a Microsoft HIS speciality!
     
    I note that, because of the usual mode of operation of HIS-based transactions with respect to, say, CICS, you expect always to be the side initiating conversations. Thus you would normally want your CNOS numbers to be a certain number of sessions, N, where there were N contention winner sessions and 0 contention loser sessions.
     
    However, should it be sensible for CICS to have contention winner sessions, you could prompt CICS to end its contention winner sessions by setting the "limited resource session" bit in the BIND response sent back to CICS. I checked the relevant CICS manual and it appears that CICS will immediately end a "limited resource session" as soon as the conversation finishes rather than having a configurable delay which is - well - a bit limited!
     
    VTAM's support for LU type 6.2 - which CICS does *not* use - is a little more flexible in having the APPL statement LIMQSINT operand value as the delay. It may be sometimes your customer's partner is a program based on VTAM support for LU type 6.2 - the APPL statement will specify APPC=YES - and so, in those cases, LIMQSINT should be considered.
     
    Chris Mason
    Saturday, March 5, 2011 11:59 AM
  • Thanks Chris.

    I do indeed mean conversation so apologies for my sloppy description.

    Historically, HIS has created 4 default sessions which have always been adequate for the number of conversations in use (which by their natuire are very small and fast). But something has changed. Sessions no longer seem to be being reused in the same way and the number steadily increases to 8 at which point no more can be accepted. I can see sessions disappearing from time to time, which made me assume that they were timing out. I have several servers running HIS client connections and these seem to create multiple APPC sessions.

    I have no control or understanding over the mainframe end of this link. Is it possible that something may have been changed there that would create this behaviour?

    --

    Mr. dich thuat

    Tuesday, June 7, 2011 4:08 AM
  • It would be fairly easy to see what is happening with some HIS traces from the SNA Server service that captures the initial APPC session activstion (so we can see the CNOS and BIND exchanges) to see which is starting the sessions and who is the contention winner/loser. As APPC conversations are started and ended, we would be able to see why additiona sessions are being activated and why they are not being closed down.

    Trace analysis goes a bit beyond what I can normally do via a forum exchange as this type of analysis is usually handled via a support case.

     

    The traces would be captured using snatrace.exe and the trace options would be as follows:

    SnaServer

         LU 6.2 Messages
         Data Link Control

    Thanks...


    Stephen Jackson - MSFT
    Friday, June 10, 2011 1:02 AM