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
