Robert's Blog

Wednesday, July 2, 2008

For Mainframers Interested in DB2 for Linux/UNIX/Windows...

Like many a veteran IT person, I knew a lot about DB2 for z/OS before I ever touched DB2 for Linux, UNIX, and Windows (DB2 for LUW was several years from existence when I started working with DB2 for the mainframe platform in 1986). By the late 1990s, DB2 was getting to be pretty interesting from my perspective, due to its growing sophistication and robustness (and due also to the enthusiasm of young colleagues of mine on IBM's DB2 National Technical Support team, such as Monty Wright and Michael Logan -- both still DB2 gurus in IBM's employ).

When I joined CheckFree Corporation (now part of FiServ) in 2000 (thereby moving over to the user side of the DB2 community), opportunities for gaining DB2 for LUW knowledge expanded: shortly after I came on board, CheckFree decided to implement its enterprise data warehouse on a DB2 for AIX (with the Data Partitioning Feature) platform, and not long after that the Company's CRM application was migrated to PeopleSoft with a DB2 for Solaris database. Both of these databases went relatively quickly into multi-terabyte territory, and I had a lot of fun learning about the technology (annual CheckFree visits to the Executive Briefing Center at IBM's Toronto Lab were highlights).

When I finally scratched my entrepreneurial itch by starting my own company last summer, I continued to work with DB2 for LUW as well as DB2 for z/OS. Take it from me: if you are a mainframe DB2 person, you can become productive as a DB2 for LUW person if you want to. In this post I'll share with you a few of the things I learned in the course of becoming a cross-platform DB2 practitioner; to wit:
  • Run it on your own system. Not all of us have our own mainframes. One thing that I really like about DB2 for LUW is having it on my laptop, in two flavors, to boot: under Windows, and also under Linux in a virtual machine. For me, DB2 9.5 Express-C is the ideal choice for my PC. The free version has just about everything with the exception of HADR (High Availability Disaster Recovery, an advanced failover clustering technology) and built-in data replication capability (these features are available with the DB2 Express-C paid subscription option).
  • Get a compact Linux helper guide (if you decide to run DB2 under Linux). There are several of these little books from different publishers. You don't have to be a Linux jock to use DB2 for Linux, but a small-footprint reference is nice to have when you need to look up a command to invoke an editor or create a directory or display the contents of a file.
  • Get some freeware for access to Linux from Windows (again, if you run DB2 under Linux). PuTTY is a nifty open-source program that enables you to securely log in to a remote Linux server (such as one on which DB2 is installed) from a Windows system. WinSCP, another piece of open-source software, makes it easy to move files between Windows and Linux systems. If you want to be able to use, on your local Windows system, a server-side DB2 GUI (such as the Setup Wizard that can be used to install DB2) that runs on a remote Linux system, a free program called Cygwin/X is your ticket. [This is NOT needed to use a client-side DB2 GUI such as the Control Center, which runs on YOUR system and enables you to interact with a remote DB2.]
  • Get comfortable with the file system. As far as I'm concerned, the biggest difference between DB2 for z/OS and DB2 for LUW, from an administrative perspective, is the need to know more about the file system when you're using the latter. At one time, mainframe DB2 DBAs had to know something about Access Method Services, the operating system component used to create the VSAM files used by DB2. Nowadays, just about all mainframe DB2 installations use DB2-defined objects via STOGROUPs, and people let DB2 handle the Access Method Services stuff. Not only that, but it's now common practice to have z/OS System Managed Storage take care of placement (within the disk subsystem) for DB2 tablespace and index files through the use of an asterisk as the volume designator on CREATE STOGROUP statements. While DB2 for LUW has made great strides in reducing one's need to deal with file-related plumbing (especially with the automatic storage feature introduced with DB2 9.1 for LUW), you still have to know more about files on this platform versus System Z. Don't be intimidated. You can pretty quickly learn enough about drive letters in Windows and file paths in Linux environments to get you by.
  • FixPacks versus PUT tapes. DB2 maintenance is packaged differently on LUW systems. One thing I learned early on: installing a DB2 for LUW FixPack is a two-step process. Know about the installFixPack and db2iupdt commands.
  • Parameters here, parameters there. On System Z, you have DB2 ZPARMs, and the technical term "database" is not much beyond a designation for a set of tables. On LUW systems, you have instance-level DB2 parameters and database-level parameters. An example of the former is the agent pool size (don't worry -- it can be set to AUTOMATIC), and an example of the latter is the log file size (each database -- and there can be several under one DB2 for LUW instance -- has its own transaction log files).
  • Google, baby! Need to untar a file? Need to know what "gzip" means? Need to know how to change the behavior of SELinux? The answers are out there, my friends, and Google gets you to them PDQ. No kidding: when in doubt, use the Great Search Engine, and chances are you'll see that the same questions have been asked by others -- and answered!
There's more, of course, but I mostly want you to know that what you need to learn CAN be learned, and learned readily. Also, know that the great bulk of your DB2 for z/OS knowledge is directly applicable to the DB2 for LUW world. SQL programming is virtually identical on Z and LUW. In both places you have tablespaces, and bufferpools, and archive logs, and catalog tables (actually, catalog views on LUW), and clustering indexes, and range-partitioned tables, and online REORGs, and RUNSTATs, and prefetch, and query parallelism, and materialized query tables, and so on and so on. They really are much more alike than they are different. So, broaden your DB2 horizons, and get to know DB2 for LUW. It's fun to do, and who knows? It could open some new career doors for you.


Anonymous Anonymous said...

I work with both z/OS and LUW as a DBA/systems programmer. IBM should have named DB2 for LUW DB3. They are almost totally different except for most sql. They were trying to make DB2 look like Oracle, which really IS the same everywhere.

April 1, 2015 at 7:30 AM  
Blogger Robert Catterall said...

I have not encountered instances of the Oracle DBMS in z/OS LPARs, so I think that it might be more relevant to say that Oracle is the same on Linux, UNIX, and Windows servers. So is DB2 for LUW.

Yes, DB2 for z/OS and DB2 for LUW have some differences that are most apparent to DBAs and systems programmers. These differences have a lot to do with the fundamentally different file system that you find in a z/OS system, versus the file systems used in Linux, UNIX, and Windows systems. Particularly as DB2 for LUW continues to enhance its system-managed storage capabilities (long a feature of DB2 for z/OS), the file-system-related differences will become less significant.

In my experience, the DB2 cross-family compatibility area that matters most to DB2-using organizations is at the application level, and in that regard DB2 for z/OS and DB2 for LUW are virtually identical. Recent versions of DB2 for z/OS, in particular, have added support for a lot of SQL statements and specifications that were formerly only available with DB2 for LUW (e.g., the MERGE statement and nested compound SQL statements with DB2 9 for z/OS; RETURN TO CLIENT cursors and OLAP moving aggregates with DB2 10; and CUBE, ROLLUP and GROUPING SETS with DB2 11).


April 3, 2015 at 1:13 PM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home