Signing in to Informatica Network

Yes.

And SELECT on msRepl_Transactions and msRepl_Commands.

If you are using ENABLELWM, then it also needs DELETE, not just SELECT.

Yes

1) Actually, I don't know the answer to this.  I would expect so, but I can't state that definitively.

EDIT: I checked with a colleague on this, and the Articles should be removed from DistDB when you inactivate the capture registration.

2.a) If you are running under different accounts/logins, no.

The underlying problem here is that PWX and PC have a shared set of modules, but don't use the same code branches of those shared modules.  PWX needs the PWX versions of those modules first in %PATH%, while PC needs the PC versions of those modules first in %PATH%.

pwxsettask.* rearranges the environment variables to work for PWX.

If you have different logins, each has its own set of environment variables.

2.b) Sure, as long as you are only running 1 PWX Listener that way.

3) No.  PWXCCL doesn't have a service handler interface, so a Windows service can't control it.

(It could start it, but then the service would be disjoint from the process - it could not tell if PWXCCL was running, and could not sent commands to it, nor stop it.)

You really need to solve multiple problems:

1. starting PWXCCL in background

2. Windows shouldn't terminate PWXCCL when you sign off

3. You shouldn't have to login to start PWXCCL

4. You need some way to send commands to PWXCCL

That KB actually resolves 1. and 2.

1. because it runs in the background

2. because it runs as a headless process, so Windows doesn't kill it when you disconnect

You can resolve 3. by using Windows scheduler to start the script.

You can resolve 4. by using PWXCMD to send commands to PWXCCL

EDIT: I have edited that KB to make those more clear.  It may take a day or so for the revised version to be visible in KB.

Unfortunately, to really make PWX Listeners distinct, they each need to have their own DBMOVER.CFG, so that they can have separate directories (CAPT_PATH, CAPT_XTRA, LOGPATH, etc.), and distinct CAPI_CONNECTION statements.

All Windows Listener Services that you create with DTLLSTSI will share the same DBMOVER.CFG.

DTLLSTSI is legacy code from when customers ran only one PWX Listener per server, only SQL Server customers ran on Windows, and almost no SQL Server customers used PWXCCL.

The "modern" approach would be to use PowerCenter Admin Console Services for PWX Listener and PWXCCL, which do support distinct configuration files per service.

When you use DTLLSTSI to create a listener service, you don't get to tell DTLLSTI what DBMOVER.CFG the PWX Listener should use.

All PWX Listener Services created by DTLLSTSI will use the default DBMOVER.CFG (the one named "dbmover.cfg" in the first PWX install directory found in Windows %PATH%).

If you want each PWX Listener to use a different DBMOVER.CFG, then you should either use the PowerCenter Admin Console Service for PWX Listener to create each, or use a combination of wscript, .bat, and Windows Scheduler, as in the KB below.

HOW TO: Run multiple PowerExchange Listeners in the background on Windows using wscript

https://kb.informatica.com/howto/3/Pages/119919.aspx

All LOGGER_DELETES_EXPIRED_CDCT_RECORDS does is to tell PWXCCL whether or not to actually delete the CND files when it goes through cleanup.

All COND_CDCT_RET_P does is define the retention period.  When CDCT entries are older than that, they are marked expired.

If LOGGER_DELETES_EXPIRED_CDCT_RECORDS is defaulted or set to Y, then PWX also removes those records, and the related CND files.