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.
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.
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>>