Checking Perl version & bit version & error in AIX

— ny_wk

To check the Perl version and bit width on AIX, run perl -V and inspect the use64bitint and use64bitall values: if both read undef your interpreter is 32-bit. This matters most when a 32-bit Perl tries to load 64-bit database client libraries such as DB2 and fails with a cryptic shared-object error.

The problem: a 32-bit Perl cannot load 64-bit DB2 libraries

A classic AIX failure looks like this. You install the DB2 Perl driver (DBD::DB2) against a 64-bit DB2 instance, then a script that does use DBD::DB2; dies immediately at load time. The error names a shared object it cannot bring in:

1. '/usr/opt/perl5/lib/site_perl/5.8.0/aix-thread-multi/auto/DBD/DB2/DB2.so' for module DBD::DB2:
2. 0509-022 Cannot load module /usr/opt/db2_08_01/lib/libdb2.a(shr.o).

The AIX runtime loader message 0509-022 means "cannot load module," and the real cause is almost always an architecture mismatch. The libdb2.a(shr.o) object is compiled 64-bit, but the Perl process loading it is 32-bit. The two cannot be mixed inside a single process image on AIX.

Why mixing bit widths fails

On AIX a process runs in exactly one execution mode: either 32-bit or 64-bit. Every shared library it loads must match that mode. A 32-bit Perl interpreter can only dynamically load 32-bit objects, and a 64-bit Perl can only load 64-bit objects. When DBD::DB2 reaches out to the 64-bit libdb2.a from a 32-bit interpreter, the loader refuses it. The fix is therefore not to patch the driver but to run the interpreter in the matching bit width.

How to check the Perl version and bit width on AIX

The single most useful diagnostic is the capital-V dump. Where the lowercase perl -v only prints a one-line version banner, perl -V prints the full compile-time configuration, including the architecture flags you need.

1. Confirm which Perl is first on your PATH: which perl
2. Print the version banner: perl -v
3. Print the full configuration: perl -V

A representative perl -V header on AIX 5.2 looks like this:

• osname=aix, osvers=5.2.0.0, archname=aix-thread-multi
• usethreads=define useithreads=define usemultiplicity=define
• useperlio=define uselargefiles=define
• use64bitint=undef use64bitall=undef uselongdouble=undef

Read the last line carefully. Because use64bitint and use64bitall are both undef, this Perl was compiled 32-bit. That is exactly the build that cannot load 64-bit DB2 libraries.

What the two flags actually mean

For loading 64-bit external libraries, the one that counts is use64bitall. When it is define, the process is a true 64-bit image and can pull in libdb2.a(shr.o) without complaint.

Faster one-line checks

You do not always want to scroll the whole config dump. These extract just the relevant facts:

1. Print the build flags directly from the running interpreter: perl -e 'print "int=$Config::Config{use64bitint} all=$Config::Config{use64bitall}\n"' -MConfig
2. Filter the full dump for the bit lines: perl -V | grep 64bit
3. Confirm the version number programmatically: perl -e 'print "$]\n"' (prints something like 5.008000 for Perl 5.8.0)

You can also inspect the binary itself with the AIX object tools. file $(which perl) reports whether the executable is a 32-bit or 64-bit XCOFF object, and dump -ov $(which perl) shows the object header flags. These are useful when several Perl builds live on the same box.

The solution: switch AIX Perl 5 between 32-bit and 64-bit

IBM's AIX Perl 5 packaging ships both a 32-bit and a 64-bit build and lets you flip the default with small linker scripts in /usr/opt/perl5. You must run them as root because they relink the system perl symlinks. To move from 32-bit to 64-bit:

1. Become root (or use sudo).
2. Run the 64-bit linker: /usr/opt/perl5/link_perl_64
3. Re-check the build: perl -V | grep 64bit should now show use64bitall=define.
4. Re-run the failing script; DBD::DB2 now loads the 64-bit libdb2.a(shr.o) cleanly.

If you ever need to go back the other way, the reverse script restores the 32-bit build:

1. As root, run: /usr/opt/perl5/link_perl_32
2. Verify: perl -V | grep 64bit should show both flags as undef again.

These scripts only repoint which prebuilt interpreter your perl command resolves to. They do not recompile anything, so the switch is fast and fully reversible.

Rebuild the database driver after switching

Switching the interpreter is necessary but not always sufficient. Any XS module that links against external libraries, including DBD::DB2 and the underlying DBI, was compiled against whichever Perl was active when you installed it. After a 32-to-64 switch you should rebuild and reinstall those modules so their compiled .so objects also become 64-bit:

1. Make sure the 64-bit DB2 environment is sourced: . /home/db2inst1/sqllib/db2profile
2. Reinstall the driver against the now-64-bit Perl, for example with cpan: perl -MCPAN -e 'install DBD::DB2'
3. Or build it by hand from the source directory: perl Makefile.PL, then make, then make test, then make install.

If you skip the rebuild you can hit the opposite mismatch: a 64-bit Perl trying to load a stale 32-bit DB2.so. The symptom is the same 0509-022 family of errors, just pointing at the driver object instead of the DB2 library.

Common pitfalls when checking Perl bit width on AIX

• Confusing perl -v with perl -V. Lowercase tells you the version; uppercase tells you the architecture. You need the uppercase form to diagnose a bit-width mismatch.
• Multiple Perl installs. A vendor tool may ship its own Perl under a different prefix. Always confirm with which perl and type -a perl that the interpreter you tested is the one the failing script actually runs.
• Forgetting OBJECT_MODE. Some AIX build and database tools key off the OBJECT_MODE environment variable. For 64-bit work set export OBJECT_MODE=64 before compiling drivers, so the toolchain produces matching objects.
• Not re-sourcing the DB2 profile. A 64-bit instance exports library paths through db2profile. If LIBPATH still points at 32-bit libraries, even a 64-bit Perl may grab the wrong libdb2.a.
• Editing scripts to "fix" the driver. The error is architectural, not code-level. No amount of changing your Perl program will let a 32-bit process load a 64-bit shared object.

Verification: prove the fix worked

Do not assume success from the absence of an error. Confirm each layer:

1. Interpreter is 64-bit: perl -V | grep 64bit shows use64bitall=define.
2. Binary is a 64-bit object: file $(which perl) reports a 64-bit executable.
3. The driver imports: perl -MDBD::DB2 -e 'print "DBD::DB2 loaded OK\n"' prints the success line with no 0509 error.
4. A real connection works: a short script using DBI->connect("dbi:DB2:SAMPLE", $user, $pass) returns a live handle, confirming the full path from Perl through DBI to the 64-bit DB2 client.

When all four pass, the architecture mismatch is genuinely resolved rather than merely hidden.

A note on legacy versus modern systems

AIX 5.2 and DB2 Universal Database Version 8 are long past end of support, so treat the exact paths above (/usr/opt/perl5, /usr/opt/db2_08_01) as period-correct for that vintage. The underlying principle is timeless and still applies on current systems: a process and every library it loads must share the same bit width.

On modern AIX 7.x and current Db2 releases, native installs are 64-bit by default, the helper scripts may live under different prefixes, and you would generally use the supported perl -V diagnostics plus a freshly built DBD::DB2 from a vendor-provided client. If you are maintaining an old box you cannot upgrade, the 32-bit/64-bit switch and the verification steps here remain the correct repair.

Key Takeaways

• Run perl -V (capital V) and read use64bitint and use64bitall; both undef means a 32-bit Perl.
• The AIX 0509-022 "Cannot load module" error against libdb2.a(shr.o) is an architecture mismatch, not a code bug.
• On AIX a process and all its loaded libraries must share one bit width; a 32-bit Perl cannot load 64-bit DB2 client libraries.
• Switch the system Perl with /usr/opt/perl5/link_perl_64 or link_perl_32 as root, then rebuild DBD::DB2.
• Verify the fix in layers: interpreter flags, binary object type, module import, and a live DB2 connection.

Frequently Asked Questions

How do I check if my Perl is 32-bit or 64-bit?

Run perl -V and look at the use64bitall line. If it says define, your Perl is 64-bit; if it says undef, it is 32-bit. For a quick check use perl -V | grep 64bit, or inspect the binary with file $(which perl).

What does the AIX error 0509-022 mean?

It is the AIX runtime loader saying "cannot load module." When it appears while loading a DB2 or other database object, it almost always means the process and the shared library have different bit widths, such as a 32-bit Perl trying to load a 64-bit libdb2.a(shr.o).

How do I switch AIX Perl from 32-bit to 64-bit?

As root, run /usr/opt/perl5/link_perl_64 to make the 64-bit build the default, or /usr/opt/perl5/link_perl_32 to go back. Confirm with perl -V | grep 64bit, then rebuild any XS modules such as DBD::DB2 so their compiled objects match.

Do I need to reinstall DBD::DB2 after switching bit widths?

Yes. DBD::DB2 contains compiled C code linked to a specific architecture. After switching the interpreter, reinstall it (for example perl -MCPAN -e 'install DBD::DB2' or a manual Makefile.PL build) so the driver's shared object matches the new bit width.

For more sysadmin and troubleshooting walkthroughs, subscribe to our YouTube channel @explorenystream.