DB2 - L

 View Only

Distributed applications (Data Studio) and controlling application compatibility – best practice?

  • 1.  Distributed applications (Data Studio) and controlling application compatibility – best practice?

    Posted Nov 21, 2022 11:54 AM

     

    AS our Db2Z upgrades to V12 and different function levels, IBM suggests we use new NULLID collections with packages bound at the new application level.  The new collection can be logically named something NULLID_V12R1M501

    The base NULLID collection stays at the base or original compat level.

    The benefit is then the distributed application can control when they move to the new function level by choosing a collection of pacages bound at the higher application.

    • Fine… it seems complicated… paranoia about risk of changing the NULLID collection packages must run deep so this granular control must be important.  Anyways, I will use this granular control of distributed application connectivity.

     

    This was all described by Chris Crone in 2018 in this IDUG blog

    https://www.idug.org/blogs/chris-crone1/2020/11/04/db2-12-and-the-ibm-data-server-drivers-with-fl-501-and-above

     

     

    IBM data studio is an example of a distributed application.

    By default IBM Data Studio connects with the NULLID collection

     

    How do Data Studio users use the new NULLID collections with higher application compat?

     

    Option (1) is that I can go around and tell all my Data Studio end-users to manually update their individual Db2Z connection to use the JDBC connection optional parms of

    clientApplcompat = V12R1M501

    currentPackageSet = NULLID_V12R1M501

     

    But the problem with that is telling everyone and getting them to pay attention.  And some end-users are not technical enough to change their JDBC connection optional parms.

     

     

    Option (2) is to use SYSTEM profile tables. To set Client Applcompat and currentPackageSet.

    This allows me, the DBA, to control when end-users use the new packages and the new application compat.
    This usage of system profile tables has been described in other blogs




    IBM data studio is a bit annoying because there is no simple indication to Db2Z that a connection is from Data Studio or some other JDBC application.

    Db2Z basically only sees the application connection is "db2jcc_application" (or "OQTv4.1")

    If I use "db2jcc_application" as the system profile filter to set the client to use the upper function level packages then I accidently set other applications (not Data Studio) to this higher function level.

    And this is not really desired.  I only want to set my all Data Studio users to use the higher function level.

     

    I suppose I can set my profile table filter based upon userid… but then that is many rows in the system profile table.  And it is manual to maintain and add new users.

     

    I am wonder about how others control function level for distributed connections.  Especially in the case of Data Studio.  Does anyone have comments?

     

    Regards,

    Brian Laube

     



    ------------------------------
    Brian Laube Manulife Financial

    Db2 Z DBA (mostly)
    ------------------------------