Scripting for DB2 LUW – Why Perl?

Why Perl?

Perl is my favorite scripting language. This was actually a conscious choice.

When I took an Oracle class earlier this year, I realized that I have a non-standard background. The instructor asked the class whether people became a DBA after being a developer or after being a system administrator. The class was split essentially down the middle – half from each background. I was the only one who came out of college straight into a DBA role.

The reason I tell you this is that many of our professional choices are colored by our backgrounds. I worked with DB2 specifically because I showed up for work at IBM and they said “you’re on a DB2 team”. Other DBAs who started around the same time ended up on the Oracle team or SQL server (or probably others, but not close to me). So that choice was made for me, and I couldn’t have been luckier in hindsight.

When it comes time to choose a scripting language, our background also plays a role. If you already know java or C, I suppose you could use them. If you come from a system administration background, you’re more likely to use some flavor of shell scripting, or possibly move on to something like Perl or Python or another simpler interpreted language.

I was on a “committee” at IBM Global Services that selected a standard scripting language to use across several departments full of DB2 DBAs based out of IBM Global Services in Boulder. We had a mish-mash of scripts, and we realized that was not ideal. Many times someone would start writing a script only to discover someone else already had one that would work. So we set out to consciously decide what language we should use. Being a committee, there was a lot of discussion, and initially I wasn’t happy with the result. I was a fan of KSH, and had several scripts in it already. But we were a LUW departments, and KSH wouldn’t work on Windows. We seriously discussed Java, C, Perl, and KSH. It essentially boiled down like this:

1. Compiled languages like C++ and Java were more full-featured and complicated than we needed
• not all clients would have compilers we could use
• we didn’t need things like control over where in memory things went
• the learning curve would be steep to learn these languages
2. KSH or other shell languages were limiting
• Only available on Linux or Unix, not Windows
• Must be paired with sed and awk to get all the functionality needed
• Advantage: most of us already knew it
3. Perl
• Interpreted language
• Easy to learn if you’re familiar with Linux/Unix
• Cross-platform – could run on Linux, Unix, and Windows, and was almost always already in place for Linux and Unix

Learning Perl

So when the decision was made by this committee to use Perl I picked up the greatest technical book I’ve ever read. Learning Perl from O’Reilly Media (I make no affiliate or other money from anyone clicking on that link).

Seriously, the book is an easy read and then a great reference when you start working. It is very lighthearted and fine to just read from cover to cover. I own a number of the O’Reilly books on Perl and other topics, and this is by far the best – especially for someone who does not come from a development background.

For ongoing reference, everything is online, and you can figure out how to do just about anything from a Google search. I decided the best way to learn Perl was to take my most complicated KSH script – one for reorgs and runstats, and re-do it. It was a challenge, but after doing it, I was competent in the basics of Perl.

Look for my next posts on scripting. I’m passionate about using Perl and about scripting best practices, so this sure isn’t the last you’ll hear from me on it.