On Jan 20, 2006, at 5:08 PM, Gene Shaffer wrote:
Sadly enough, on the AIX system that this lives on, /backupset IS the full path to gen_backupset2.sh.
Then by all means have that in your specification. Your original posting said "./backupset/gen_backupset2.sh" which is a relative, rather than absolute, specification. It's a great security risk for root to be incited to execute things from uncertain locations. When constructing run specs in TSM, cron, or any other facility, use full, absolute paths to avoid jeopardizing your system. Getting root to run things it's not expecting is a classic security exploit.
I'm beginning to lose heart and start considering alternatives like throwing this in crontab or maybe some administrative immediate action schedule. I have tried a simple test script that merely does [# cat test.sh] ID=blah PASS=blahblah dsmadmc -id=$ID -password=$PASS 'query node' >/backupset/test2.out And still no reaction.
Perform some basic checks, in particular whether the test.sh file has executable permissions set on it (as via 'chmod'), whereupon 'ls -l' will show permissions like "rwxr-xr-x". Whereas schedules are managed by the TSM server, look in its Activity Log, where there should be ANR messages reporting problems with the schedule. Naturally, there must be some kind of TSM receptor on the client node which is to run the scheduled command, being 'dsmc schedule' or dsmcad. If the schedule seems fine to the server and there is a receptor running on the client, then look in the client schedule and dsmerror.log files for indications of problems. Figuring this out is just a normal part of becoming familiar with TSM facilities. We all do this at one time or another. When something doesn't work, look around at all the points where evidence may be had: logs, file system object timestamps, accounting records, etc. For example, when an executable is run, it has to be read, and that updates its last-access timestamp. Richard Sims
