Paul -

Don't use GUIs in debugging client -> server connectivity problems:
use basic commands for clarity and isolation.  Don't attempt more
complex scheduler starts until basic interactivity is established.

The ANS2604S from the Web GUI may or may not have resulted in useful
messages in your dsmwebcl.log, so check there, as well as the
dsmerror.log.

Check the timestamps on the /etc/adsm/TSM.PWD (or whereever a
PASSWORDDIR client option may be pointing) on that Linux client for
when it was last changed, and assure that the file was not deleted or
damaged.

The general approach is to start with baby steps, then work your way
up to high-level TSM functions in isolating the problem.  I would
start by performing 'dsmc query session', as root on the client, and
see what results on the client, and TSM server Activity Log.  This
may result in a password re-establishment interaction, which may cure
the problem.  You can then graduate to 'dsmc query backup ...', when
then gets deeper into client work, to see what comes of that.  If
that works, then perform 'dsmc incremental ________' on an individual
file and see if that works.  Whereas your Query Admin indicates that
an ANL2 admin of type Client Owner exists, try some basic dsmadmc
interactions and see what results there.

Refer to the TSM Problem Determination Guide for general guidance.

   Richard Sims