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 XB22.214.171.124.7, the policy has been in production all going good. Now we are looking at upgrading to XB126.96.36.199.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 188.8.131.52 to 184.108.40.206, 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.
This topic has been locked.
1 reply Latest Post - 2013-02-05T18:49:50Z by HermannSW
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 2700006U544357 PostsACCEPTED ANSWER
Re: Change to SLM Policy Behavior for Concurrent Connections2013-02-05T18:49:50Z in response to SystemAdmin> ... 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."