If the /framework/ is using the SQL CLI like BRMS does [for WRKMEDBRM as noted in the support document], then perhaps that /framework/ is not reclaiming a connection handle as described in the support document BRMS was doing before that code was corrected. The QSQCLI will appear in a trace before the CLP, if the SQL CLI is being used. Regardless, since the problem is apparently specific to the use of that framework, perhaps the best bet is to report the issue to the providers of that software. If they see no reason why their code should cause the problem with the use of the SQL CLI by import\export [because for instance, they verify they clean up their connection handle properly], then they could pursue the issue with IBM.

Regards, Chuck

Saptharishi Narasimhan wrote:
Also thanks for the information about the BRMS function solution.
But i couldn't figure out the correct direction out of that.

CRPence wrote:
The following is an example of a conflict that was resolved by
the BRMS function changing to no longer cause a conflict:
Something similar could be by origin of the /framework/ being used,
if that is also coded to the SQL CLI. <<SNIP>>

Return to Archive home page | Return to MIDRANGE.COM home page