I was chatting with Josh the other day and he asked me if I knew that IBM now does not recommend uses the default value of 10 for a channel’s SHARECNV (shared conversation) value. He said that the MQ Knowledge Center recommends for distributed queue managers a value of 1 for a channel’s SHARECNV.
Of course, I said WTF and where did you read that. He emailed me the link and sure enough, that is what it says.
The default settings for client and server connection channels changed in Version 7.0 to use shared conversations. Performance enhancements for distributed severs were then introduced in Version 8.0. To benefit from the new features that were introduced alongside shared conversations, without the performance impact on the distributed server, set SHARECNV to 1 on your Version 8.0 or later server connection channels.
And further down it says:
However, for distributed servers, processing messages on channels that use the default configuration of 10 shared conversations is on average 15% slower than on channels that do not use shared conversations.
A 15% performance hit for using the default value for SHARCNV on distributed queue managers!!! OMG!
From a guy who writes MQ exits, I have always hated the SHARECNV parameter when it has a value greater than 1 because in my opinion, IBM did a horrible job in their implementation of it as it relates to a channel security exit.
When SHARECNV parameter is set to 1, a channel security exit is invoked with the following ExitReason values:
When SHARECNV parameter is set to a value greater than 1, i.e. 10, a channel security exit is invoked with the following ExitReason values:
Everything looks EXACTLY the same for the 1st session but for session #2 to session #10, the calling sequence is totally different.
Secondly, did you happen to notice that when all but the last session ends, the channel security exit is NOT made aware of this fact!!! The channel security exit is only invoked with MQXR_TERM when the last session, whichever number that is, terminates (never for the other sessions ending). I have no idea who dreamt this up, but man it is a bad design.
I am so happy that Josh told me about this little tidbit. Now I get to tell my customers that IBM’s best practices for a channel’s SHARECNV parameter on distributed platforms, is to set it to 1 rather than use the default value of 10.
It would be interesting to know the performance for z/OS queue managers whose channel’s SHARECNV is set to 10 vs 1.
Regards,
Roger Lacroix
Capitalware Inc.
