Marc -

Thanks for the details on the objectives.

Before expending effort on making dsmj accomplish all that you want,
is the overall approach really viable?  In the client manual, review
the table of "Root and authorized user tasks", particularly for the
Restore task.  The show-stopper for the use of the Authorized User
approach would be the inability to restore the files to their
original ownership - if that user can indeed write to that location.
Carefully consider all the ramifications.

In your rigged execution of dsmj, you may not be seeing into
directories because of basic ownership issues.  In a standard TSM set-
up, with a backup performed by root, an ordinary user likewise cannot
see into TSM-stored directories because of ownership/permissions
issues.  If the Authorized User had performed the backup of the
objects under the directory, then I should think the AU should be
able to see them via dsmj - but likely not if the backup had been
done by root.  As Andy advises, try the command line client as a
comparator: do a thorough 'dsmc query backup' on the area, and see if
contents are revealed in that.

Note that where a GUI like dsmj is not tenable, the compromise
approach of 'dsmc -pick' may be acceptable.

In your objections to sudo, you talk of "ACLs set everywhere".  Sudo
does not necessarily grant root access: with -u invocation, it
operates as a single non-root user, as can be used in restoring just
their files.  Personally, I would approach this by having root-run
TSM scheduled backups, and use sudo -u for individual user restores,
which keeps the operator away from dangerous root stuff.

Others will likely have good suggestions based upon their experiences.

   Richard Sims