Private Protocol (PP) distributed processing was deprecated in DB2 for z/OS V9 and it is not supported in DB2 10.The initial announcement was that any package marked as bound with PP will not execute in 10, but because this was an issue for installations where the BIND default was DBPROTOCOL(PRIVATE) this constraint was relaxed.
According to how DB2 10 is documented today, these packages will be executed but they will fail when trying to run PP. Anyway, for many other reasons, you should be moving away from Private Protocol and using DRDA.
DRDA stands for Distributed Relational Database Architecture, an open industry standard embraced by the DB2 products and other databases. The DRDA technical documentation can be found in the Open Group website in http://www.opengroup.org. There is no technical reason today to keep using PP instead of DRDA, and you are missing some or many of the recent and not so recent developments only available when using DRDA.
Do you know that PP has not been improved for more than 10 years?
If you are busy migrating from PP to DRDA you may have noticed that you may need to create aliases in remote locations in order to correctly migrate some applications.
The fact is that PP performs always a process called Alias Resolution if an application is using three part-name aliases in the originating location. The first part of a three-part name alias indicates a local or remote server and its use allows an application to implicitly connect to a remote location.
Consider the following figure. This is a representation of a package running in a DB2 for z/OS, LOC1, accessing data in a remote DB2 for z/OS, LOC2. In this case the remote access is done using PP.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… Happy migration!