>>The cheapest way to do this is to get yourself familiar with SQL queries,
>>all the information you need is in the tables.

Except -- it isn't.

Carefully compare the DSMSCHED.LOG with the messages recorded in the
activity log.
I went round and round with support on this when setting up 4.1 server with
some Novell clients.

*Some* errors are sent to the TSM server activity log; some are not.
Note that this isn't entirely decided by error level severity, but by some
magic number quantity in *some* cases.  I was never able to get an answer
about what the magic number/level was for deciding to stop sending errors to
the TSM server.

The only definitive location for all errors during a scheduled event is in
the nodes dsmsched.log.

That was the gist of the answer I got straight from developers during a
crit-sit (not directly related to this question ) at an
IT-department-out-sourced to IBM contract site.

My impression was that they see this as a feature - if you have enough
clients, if *every* error was sent to the server activity log, you could
quickly bring a server to its' knees.

And that was on TSM server 4.1 on AIX, and perhaps this has since changed;
your mileage may vary.
I simply use the server activity log as a starting point - if something is
bad enough to show up there, you can bet someone better be looking at the
client log file.