> Can you elaborate why we should check this check boxes?
The old 'IBM MQ Series' protocol was not originally written with delayed responses in mind, so the feature has limitations that require manual consideration. Sending delayed responses requires 'Shared Sessions' to be enabled, but we can't just enable that by default. Notably, the way 'Shared Sessions' works is not compatible with temporary response queues or a replyTo queue that otherwise changes from request to request.
The only way to fix these limitations was to rework it from scratch, which we did in DevTest 8.0 with the 'IBM MQ Native' protocol.
> Also when we enabled check box then we are not able to see complete details in Console in Inspection view.
Delaying the response isn't really compatible with the way the inspection view currently gathers its data. If a response is delayed then it's sent at some point in the future, in the background while the VS execution moves on to other steps. The events from actually sending that response are emitted during another step's execution, or possibly during no step's execution. This is a problem for the inspection view, which is based around grouping events under their respective steps.
Again, the new 'IBM MQ Native' protocol is able to handle it a little better. But it can't remove the fundamental problem that we don't know some things about the response message until actually going through a send operation that can happen at some arbitrary point in the future.