Detecting DB2 installations without running DB2 specific commands

Detecting installations of a particular software on Windows is a simple job , but things get worst in case of Linux and UNIX , especially if the software was not installed using native binaries like rpm or deb packages. Windows has the registry (start -> run -> regedit.exe) to list all the required details like install path , product version , locale or product type. But on Linux or UNIX it may not be that easy. Faced a similar problem about detecting DB2 installations on Non-Windows OS.

DB2 documentation mentions that you can detect DB2 installation details using the "db2ls" utility located as "/usr/local/bin/db2ls". But the problem here is it will list all products of the DB2 family like : DB2 Server , DB2 Client , DB2 Connect etc. Running db2ls command provides details like : Installation path ,  Level , Fix pack , Special Install Number , Installation date , Installer UID. But what if I need to detect these details without running any command , just like we do in windows by reading the existing registry keys.
After searching the DB2 info-center I realized that its not possible to detect DB2 installations without running a command like db2ls ...

It sounds impossible but thats the truth ... however the fact is even db2ls command will internally refer to some global file which may contain all the details ... so which is this file ??? "global.reg" is the answer. However this file is encoded and cannot be read directly. In order to decode this file one needs to run the db2greg tool ... We are back to the same problem where we need to run a command to find DB2 installation details ... So I tried to read the file using cat command , obviously it wasn't readable as clear text since it had come Unicode characters ... Below is the screenshot of the file content :

NOTE : location of global.reg is fixed as /var/db2/global.reg always



Interesting problem to solve ... Let try to read it as a Unicode encoded file using special editors like notepad++ or edit+  or ultra-edit...


At first sight it looks worst than the previous screenshot. But if you observe carefully , there is pattern hidden in the second screenshot.  Path to the root install directory for DB2 Server has a pattern of %OO%OO%12<ROOT_INSTALL_PATH>%OO%OO , in our case the value is /opt/IBM/DB2/V9.7 , on Linux operating systems like RHEL and SUSE the pattern is %OO%12%OO<ROOT_INSTALL_PATH>%OO%OO

Path to the database has a pattern of %OO%OO%16<PATH_TO_DATABASE>%OO%OO%O4 which in our case is "/home/db2inst1/sqllib" or "/home/db2inst2/sqllib" , on Linux operating systems like RHEL and SUSE the pattern is %OO%16%OO<PATH_TO_DATABASE>%OO%OO%O4

Once we get the root install directory location , its easy to find the type of product installed by looking for the file <ROOT_INSTALL_PATH>/cfg/.*.lvl file where the name of .lvl file will contain ese (enterprise server edition), client , admcl (administration client) , adcl (application development client) , rtcl (run-time client) etc.

Note :  <ROOT_INSTALL_PATH>/cfg will always have only one .lvl file.

The scenario here is "writing a relevance for a fixlet to install DB2 server" using BigFix. Lets get our hands dirty with all the above information and use the below relevance:
if name of operating system as lowercase starts with "aix" then (exists true whose ( exists files whose ((it contains "client" and it ends with ".lvl") of (name of it as lowercase)) of (( folders ("/" & it as string & "/cfg") ) of ( preceding texts of firsts "%OO%OO" of ( following texts of firsts "/" of ( lines of file "/var/db2/global.reg") whose (it contains "DB2SYSTEM" ) ) )))) else if name of operating system as lowercase starts with "linux" then (exists true whose ( exists files whose ((it contains "client" and it ends with ".lvl") of (name of it as lowercase)) of (( folders ("/" & it as string & "/cfg") ) of ( preceding texts of firsts "%OO%OO" of ( following texts of firsts "/" of ( lines of file "/var/db2/global.reg") whose (it contains "DB2SYSTEM" ) ) ))) ) else false
Note : String patterns shown above contain numeric zero "0" and not alphabetic "O"
+