Actually, it's documented in the client README (or at least was on the 2.x
client)..

1. The user executing the client process (be it dsm, dsmc, etc) must been
       running as either root or as the same uid of the processing running
       the server (dsmserv).  There are some work-arounds for the restrictions,
       none of which eliminates the requirements for authenticating to the
       server.  In other words, these work-arounds simply allow non-root users
       to use the shared memory protocol.  The user will still need to supply
       a valid password, if one would have been required anyway.  The
       work-arounds are:

       A. If you use passwordaccess=generate in the dsm.sys options file,
          ADSM will use the dsmtca process.  The dsmtca process runs as root,
          so it will have the authority to connect.  This work-around can be
          used for the backup/archive clients (dsm and dsmc).

       B. For the admin clients (dsmadm and dsmadmc), the dsmtca process is not
          used.  You can, however, change the ownership of the dsmadm and
          dsmadmc programs to root and set the setuid bit on.  Example:
              chown root.system dsmadmc
              chmod u+s dsmadmc
          This will cause dsmadmc to execute as root, which gives it authority
          to connect.  You still need to pass authentication checking for the
          actual admin session.

       C. For programs using the API, you can do the same as in B. above.  That
          is, make the program owner root, and set the setuid bit on.