Concurrent installations

Edit online

While the concurrent installation of new and old CCA RPM levels is neither supported nor advisable, here are some background considerations if you do have a CCA 8.0 RPM for a CEX8C installed alongside with earlier CCA RPMs.

  1. The libcsulcca.so library for CCA 8.0, CCA 7.*, and earlier releases have many symbols with the same names. An application cannot deterministically link with both libraries. The first library in the link statement is used for all symbols that can be resolved there, after that the second library will be examined. At this point, either the linker will not allow the link to continue by throwing an error on the duplicate symbols, or will produce a hybrid-linked application. Either case gives the user the wrong answer.

    A new or updated library cannot itself resolve this kind of conflict because:

    • There is no way to have a default set of symbols or card support in an updated host library. The link operation is a fundamental step in building the customer application and outside the control of the library or library installation process.
    • One way to resolve name collisions is to change all of the function names in the new library. However, this would break symbol-level compatibility between library versions, requiring application re-mapping.

    If you truly want to have both the new CCA and old versions of CCA, you can try copying the old installation files into a set of new locations and then setting the proper environment variables before re-building. For example, if you have CCA 7.3 installed and want to keep that while also installing CCA 8.0 on a RedHat distribution, then perform the following steps:

    1. Host Library: cp /usr/lib64/libcsulcca* /root/73_lib/
    2. Install Location: cp -r /opt/IBM/CCA/ /opt/4769/
    3. Then set the environment variables from file /etc/profile.d/csulcca.sh to point to these new locations for the 7.3 installation. Do not modify the /etc/profile.d/csulcca.sh file itself since it is used by your default installation (soon to be 8.0) to set the default values. If you want to use this script, make a copy and modify the copy.
    4. Perform the following commands: 
      export CSUINSTDIR=/opt/4769/
export LIB_FOLDER=/root/73_lib/
export CSUDESLD="$CSUINSTDIR/keys/deslist
export CSUDESDS="$CSUINSTDIR/keys/des.key
export CSUAESLD="$CSUINSTDIR/keys/aeslist
export CSUAESDS="$CSUINSTDIR/keys/aes.key
export CSUPKALD="$CSUINSTDIR/keys/pkalist
export CSUPKADS=“$CSUINSTDIR/keys/pka.key
export CNM_CLASSPATH="$CSUINSTDIR/cnm/CNM.jar
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:} $LIB_FOLDER
export CSUSRDI=$CSUINSTDIR/srdidata

    With these updates in place (and only in an environment where these changes are in place) you should be able to build and run against the old CCA 7.3 release. This set up will have a separate key storage location than the default.

    Then you can install CCA 8.0 which will upgrade the default install locations and set the default CCA to 8.0 (unless you specify otherwise by setting the environment variables previously discussed).

    Once CCA 8.0 is installed/upgraded you can build and run against CCA 8.0.

  2. The key storage environment variables in the default user profile (/etc/profile.d/csulcca.sh and /etc/profile.d/csulcca.csh) are changed at installation time to point to the /opt/IBM/CCA/keys/ path. Softlinks are added to older default installation paths to assist migration, but double-check that all of your key storage is accessible.

    As previously discussed, you can set up different key stores in different locations, although this might not be what you want, and will leave certain keys stranded in one location and thus inaccessible from another.

  3. Again note that for a hybrid environment like this, TKE administration becomes challenging. Since only one catcher can be run at a time. The catcher from the most recent RPM is recommended to be used.