Hope u have checked the permission of that file and also
user have the permssion to run the cron.
please check with the following
ls -ltr /home/user/test.sh --->check executable permission
/var/adm/cron/cron.allow-->add the user whom u want to execute crontab

Not knowing what the script does, it is hard to see what could be
wrong. One thing you could check is your PATH variable. When
cron runs, it uses a very small PATH subset. You might have to
initialize your PATH variable in your script to make sure all
your commands are in the path.

Lamar - I was taught that the entries in your crontab file are read into
memory each time you refresh the cron daemon and/or boot the machine.
Though this description may not be 100% accurate, the truth is that the
crontab file entries are NOT read dynamically off the disk by the cron
daemon. When you refresh the daemon, all the entries are read and
"stored somewhere" ... maybe not in memory, but the fact is they are not
read dynamically off of the disk where they reside.

Did you read my message completely ? Yes, you have to refresh the cron
daemon and this is what I describe in the closing lines. This is why
you should use crontab -e vs. vi the actual cron file and running a
crontab <filename>.

Do you understand what would happen if you created a cron file called
crontab.dmp and read it in as root with the crontab <filename> command ?
It does not APPEND the /var/spool/cron/crontabs/root file; it will
OVERWRITE it with the information in this file.

All you need to do is a crontab -e and exit to reread the cron file. I
understand what you are saying; but editing the cron files then
rerunning the crontab <filename> command is not wise. The best method
using this logic would be the following:

My crontab.dmp file and the "/var/spool/cron/crontabs/root" files are
one and the same. As such, I know full well that the crontab.dmp file,
when the cron daemon is refreshed, overwrites the
/var/spool/cron/crontabs/root file

To me, in my configuration, having more than one cron file running is
not necessary. Perhaps it is naïve of me to think that most others
share my view.

Hey Lamar.... Be carefull with that crontab -e option. That e is
really really close to r and crontab -r is not good at all.

I always make a copy of the user cron entry I am going to edit
/var/spool/cron/crontabs/oracle.date as an example. Then I can
edit the original using the editor of choice, file and then do
crontab -e very very carefully. I have seen a lot on new admins
get bit by crontab -r fat fingering....

I have only had to restore crontab once. I think it is best to
use the crontab -e command instead of vi. We have at least 3
different crontab files and there doesn't seem to be much
problem.

Back to the original question, was there an email generated from
the job? What did the log say? Did it run at all or did it bomb
out somewhere in the middle? We have had some problems in the
past because our scripts were written in korn shell. Once we
specified korn shell with the #!ksh on the first line of the
script they worked fine.