DB2 Clients

So there are a few topics I wanted to cover relating to DB2 clients and how Commerce uses them.

Type 2 vs. Type 4 drivers

So strictly speaking, this is referring to the JDBC driver being used. Type 2 JDBC drivers are the traditional kind that require having a DB2 client installed, and the databases properly cataloged within that DB2 client. Type 4 JDBC drivers allow an application to connect without the use of a DB2 client – simply using a JDBC url. Commerce 6 used type 2 drivers by default, and Commerce 7 uses type 4 by default. However, that is only for normal application traffic. Utilities like stagingcopy or stagingprop or dbclean or others may or may not be able to use the type 4 drivers – some of them may require that you have the client available so they can use type 2 drivers. Interestingly enough, Commerce also requires the type 2 drivers during Commerce Instance Creation, so you’ll have to have them there in each environment during build anyway.

Because of this, you’ll still need to install a db2 client on at least one application server, and frequently at least one application server in each environment (prod, stage, qa, dev, test, authoring – whatever you call them)

Runtime vs. Admin client

Just to keep us on our toes, IBM changes terminology from time to time. Between db2 version 8 and 9, they changed the client terminology. On DB2 version 8, we installed the “Administration Client”. On DB2 9, the same thing is called “IBM Data Server Client”.

Commerce needs the full IBM Data Server Client. There’s something called the Runtime client or IBM Data Server Runtime client – this does not work for Commerce. You must have the full one installed, not the runtime one. The runtime is a smaller footprint that is designed for vendors to include in their own code, essentially.

Fix Packs

As well as changing the terminology, they also change how you spell Fix Pack. Is it FixPak or FixPack or Fix Pack now? I don’t honestly know. Whatever you call it, you can use the same “Universal” Fix Pack to patch both the clients and the servers. That’s my preference, to have the Universal Fix Pack code on my build server, NFS mount it to my clients and servers, and patch them all from that source. I have heard you can also use the individual client code to apply a Fix Pack, but in all honesty, have never tried it myself.

I always patch my Clients when I do my Servers – this is not strictly required. The old rule was “Two down, one up” – meaning that for full version changes, you could connect to the previous two full version changes and to the next one full version up at a minimum. That changed a bit with DB2 version 8, so you may have to look closely, but I have never seen nor heard of an issue caused by a client on a different Fix Pack of the same version of the Servers it connects to. If I don’t patch them all at the same time, then I might forget the client – since it make so little difference, and it’s so infrequent that I have to do anything at all with a client.

Ember is always curious and thrives on change. Working in IT provides a lot of that change, but after 17 years developing a top-level expertise on Db2 for mid-range servers and more than 7 years blogging about it, Ember is hungry for new challenges and looks to expand her skill set to the Data Engineering role for Data Science. With in-depth SQL and RDBMS knowledge, Ember shares both posts about her core skill set and her journey into Data Science.
Ember lives in Denver and work from home for XTIVIA, leading a team of Db2 DBAs.