The package PKG1 makes reference to an alias, NL.EMP, that resolves to a remote DB2 object at LOC2. For clarity I have included in this figure the SQL code involved in the alias creation, but of course the Alias is created once and before the program execution.
The alias resolution processing consist in the substitution of objects names, following the alias definition, in a SQL statement before the SQL is sent to a remote server. As represented there is no object named NL.EMP in LOC2 but the query will work. This is the way in which PP works, always.
When you migrate from PP to DRDA you will need to BIND packages at each remote location, typically you will use the BIND COPY DBPROTOCOL(DRDA) SQLERROR(CONTINUE) bind options for this. Additionally, if the application uses three-part name aliases, and because DB2 V8 and V9 do not have the capability to perform alias resolution processing for DRDA requests, you need to create aliases in the remote location.
Consider how the picture will look like after migrating this application from PP to DRDA. In this case, LOC2 will contain a copy of package PKG1 as required by DRDA and this package contains the same reference to NL.EMP as the original package. In order to run this package successfully you need to create an alias in LOC2 to resolve NL.EMP into PRD.EMP.
This situation has changed recently by the introduction of the zParm DRDA_RESOLVE_ALIAS. This subsystem parameter, available in V8 and V9, allows you to activate alias resolution processing for DRDA so you do not need to create an alias at the remote location anymore. This is the way in which DB2 10 works and you will not have an option for deactivating this behavior.
Our scenario may look like the following figure after activation of DRDA_RESOLVE_ALIAS:
Now the scenario looks a lot simpler and this new zParm has the potential to make the migration from PP to DRDA a lot simpler.
DRDA_RESOLVE_ALIAS is set to NO by default and you need to set it to YES in order to activate this functionality. So please have a look into your current maintenance, maybe you have this zParm available but not activated.
PK64045: PREPARATION FOR ELIMINATION OF PRIVATE PROTOCOL IN DB2 10 FOR Z/OS (http://www-01.ibm.com/support/docview.wss?uid=swg1PK64045 ) documents this and many other features and tools that are made available to you in order to support the migration from PP to DRDA; this APAR should be your starting point in the migration process.
You should be considering to eliminate PP now even if your plans for DB2 10 are for a distant future. By using PP today you are missing many advantages for your distributed processing that are available only to DRDA; to describe some of them is reason enough for a new post...