You could do pretty much all of this with Perl and Test:: modules if you want. The benefit of Test:: modules is that you get nice output which can be run as a single file, or under something like Test::Harness which gives you a report for a group of tests.

1) verify all necessary dbms client and server files are in a directory, else fail

Write a perl script which reads in the directories of these and then check those values against a static list you constructed. This can be done with Test::More::is_deeply if you have them in order, or Test::More::eq_set if they are not in order (remember though that eq_set is not a Test function and must be wrapped with Test::More::ok).

There may also be a Test:: module out there for specifically checking file existence, I am not sure since I have never had the need. And if there isn't, you could always write one ;-)

2) verify versions of client and server binaries & libraries

I would expect that a combination of file test and shell commands (to libtool or something) would get you the answers you want to know, then just test those answers against your expected values using Test::More

3) run a series of queries that pass/fail where desired

Load DBI and run some tests, checking the output with Test::More

4) verify 3rd party binaries work correctly with the dbms server

I am not sure what this entails, but again, I am sure some shell commands using backticks or system() would get you the answers.

6) verify os patch and kernel options

see the last three answers above ...

Really you can do just about anything with perl assuming you have some kind of programattic access to it. And with a little work, you can hook it into Test::More.

And as I said above, if you develop any new and possibly useful Test:: modules, put them on CPAN and share the wealth.

nearly all of the modules I make are for work where they own the code. I've started the process of getting some of the modules (the ones where the code is not site or business specific) released to CPAN (red tape) but can't promise or predict if those will ever be released. What I do on my own time and equipment is mine as long as it isn't for work.. (I've been working on a TiVo Media Server written in Perl)

No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

I've started the process of getting some of the modules (the ones where the code is not site or business specific) released to CPAN (red tape) but can't promise or predict if those will ever be released.

I know the feeling, red tape can be seriously annoying (not to mention soul sucking). Fortunately my current boss sees the value in open sourcing modules to CPAN, especially since we utilize CPAN so heavily ourselves. If you utilize CPAN at your work as well, you might try that argument as well. After all, giving back the community only helps to strengthen it, and that helps everyone involed including your boss/job/coworkers/etc.

-stvn