Last year while working with an SLM policy to shape concurrent transactions to 1, I realised the threshold has to be specified as 0 (I couldn't find relevant documentation though, with little bit of research I established it as n-1 for getting n concurrent transactions), this was in the version XB220.127.116.11.7, the policy has been in production all going good. Now we are looking at upgrading to XB18.104.22.168.4, to get started, got the dev box upgraded to this version and the regression test failed!. I repeated the same exercise and realised now the threshold should n not n-1 any more. I went through the fix list from 22.214.171.124 to 126.96.36.199, there was nothing obvious pointing to this behavior though there were some SLM related fixes.
Has anyone experienced this behavior or can someone from IBM provide some details on this change
Thanks in Advance.
Pinned topic Change to SLM Policy Behavior for Concurrent Connections
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-02-05T18:49:50Z at 2013-02-05T18:49:50Z by HermannSW
HermannSW 2700006U546737 Posts
Re: Change to SLM Policy Behavior for Concurrent Connections2013-02-05T18:49:50ZThis is the accepted answer. This is the accepted answer.> ... with little bit of research I established it as n-1 for getting n concurrent transactions ...
It seems that this was fixed in APAR IC84858:
"... on rare occasion, terminate SLM processing for a given statement one message earlier than defined by its threshold."