Path problems, I mean, the dlls may have some hardcoded path values of expected perl?

If that were the case, it would be very bad practice. And one I've never encountered with any Perl/CPAN created dlls. There's no guarantees that IBM/Rational haven't done something like that, but it would be ... um ... untypical if they have.

For the AS perl approach, I would probably try:

1. Install the AS Perl (to match the CQPerl version) in a separate directory structure;
2. Then copy the entire CQPerl <CQPerl>\lib & <CQPerl>\site\lib directories over the top of the equivalents installed by the AS perl--and then test thoroughly!

If that checks out okay, you can then disable the CQPerl installation--remove it from your path, and enable the AS Perl install and you should then have everything that came with the CQPerl and then ability to use PPM to maintain the installation. For everything except the CQ stuff.

When a new release of CQPerl comes along, you'd have to install it (without letting it become a part of your path), and then repeat the copyover process from the new subtrees to your AS perl installation. It would require you document the process (in case you get hit by a bus), but it shouldn't be too onerous to do. A simple batch file using xcopy ought to do it.