All of the various headers in gdbm-devel-1.8.0-36.el6.ppc64 define datum as:
      typedef struct {
        char *dptr;
        int   dsize;
      } datum;

Note the use of "int" for dsize.

This fragment of code in python's Modules/dbmmodule.c:dbm_contains:
          if (PyString_AsStringAndSize(v, (char **)&key.dptr,
                                       (Py_ssize_t *)&key.dsize)) {
                  return -1;
          }
assumes that
  sizeof(datum.dsize) == sizeof(Py_ssize_t)
which is not correct on these architectures; on ppc64:
(gdb) p sizeof(key.dsize)
$25 = 4
(gdb) p sizeof(Py_ssize_t)
$26 = 8

On ppc64, when PyString_AsStringAndSize writes the 0x00000000000000001 value for the ob_size of "a" to &key.dsize, I believe the 0x00000000 part is written to &key.size, and the 0x00000001 part is written to the 4 bytes following it, due to the incorrect cast from (int*) to (Py_ssize_t*)

Thankfully
(gdb) p sizeof(key)
$28 = 16
so I believe it writes this value to padding within the "datum key", rather than corrupting the stack.

The dbm_fetch() is thus invoked with a 0 dsize, and doesn't find the key, hence the test fails.

The various other uses with that source file appear correct:
(i) there are various PyArg_Parse* calls using s#, with int, which is correct, given the absence of the PY_SSIZE_T_CLEAN macro.
(ii) there are various calls of PyString_FromStringAndSize(, datum.dsize), which I believe is correct: I believe the compiler will coerce this int to the wider Py_ssize_t type.

Filed upstream as http://bugs.python.org/issue9687, with a patch

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, the "in" operator for dbm mappings erroneously returned False for all keys on big-endian 64-bit builds of Python (ppc64 and s390x). This update fixes this issue.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0554.html

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0554.html