Goran -

A few general recommendations...

In any preschedulecmd:

1. Always produce a log from that OS command execution.
   It's not evident that the output of the doob execution is being
saved anywhere,
   for you to inspect to see what it did or whether it was
successful.  This is
   vital because a bad return code from a preschedulecmd causes the
scheduled
   operation to fail.  (The corollary to this: the invoked OS
environment command
   needs to emit relevant return codes.)
2. Always use full path specs for executables.
   While it is likely that this prescheduled command will find 'su'
in /usr/bin/,
   there is no guarantee of that, absent the full pathing.

IBM provides lots of useful information on pursuing scheduler
mysteries, in its TSM Problem Determination Guide, and in Technotes
such as 1210438.  It's largely a matter of elimination to narrow down
such a problem.  Personally, I like to start out with DEFine
CLIENTAction as an elemental test, to invoke an OS command such as /
usr/bin/date.  If that doesn't work, then you have basic issues on
the client which need to be resolved, such as a previously scheduled
command which did not finish before the next schedule was to run.  In
that regard, note well the duration of the successful schedule you
included in this most recent posting, relative to the number of hours
in a day:
    Elapsed processing time:           26:08:51

I maintain a list of common foibles under entry "Schedule, missed" in
http://people.bu.edu/rbs/ADSM.QuickFacts .

Your logs suggest that your site is not doing time standard
synchronization, which is fundamental to client server operations.
This is evident in your client log entry:
  08/24/06   02:30:22   Server date/time: 08/24/06   02:34:21
At a minimum, drifting clocks confuse debugging, and can screw up
time-sensitive operations such as Kerberos authentication.

   Richard Sims