Let's say that Java is really the best tool for doing XML, but I do not know Java, I know Perl. If Perl's XML tools are almost as good as Java, and I can save weeks of learning time by programming my XML in Perl, then I will probably do my XML in Perl even though Java may be better.

If a pure cron solution requires too much knowledge of Unix internals and a Perl solution requires only Date::Calc and a simple daily cron job, then I say write a Perl script that cron will run daily, and let Date::Calc, which is available from www.cpan.org, do the date calculations.

If you type in 'cron' in the search on this site, there was a discussion on it that may help. Also, on your unix machine, type in 'man cron'(but it sounds like you don't have access to the machine right away, so I'll paste what my man page says, at least some relavent parts)

I'd check out these manpages also, if you can: at(1), crontab(1), sh(1), queuedefs(4), attributes(5) (they were mentioned at the end of cron. I don't know much specifcially about cron, but you can access some manpages online at: http://www.tac.eu.org/cgi-bin/man-cgi?cron+8 if you don't have access to them. Here's an article thats rather useful, its from O'Reilly: http://www.onlamp.com/pub/a/bsd/2000/09/27/FreeBSD_Basics.html If you need anymore help, you can search the web, or ask someone--lots of people here are proficient with Unix; I'm, however, rather new to it, and only know a little.

DESCRIPTION The cron command starts a process that executes commands at specified dates and times. Regularly scheduled commands can be specified according to instructions found in crontab files in the directory /var/spool/cron/crontabs. Users can submit their own crontab file using the crontab(1) command. Commands which are to be executed only once may be submitted using the at(1) command.

cron only examines crontab or at command files during its own process initialization phase and when the crontab or at command is run. This reduces the overhead of checking for new or changed files at regularly scheduled intervals.

Since cron never exits, it should be executed only once. This is done routinely through /etc/rc2.d/S75cron at system boot time. The file /etc/cron.d/FIFO is used (among other things) as a lock file to prevent the execution of more than one instance of cron .

cron captures the output of the job's stdout and stderr streams, and, if it is non-empty, mails the output to the user. If the job does not produce output, no mail is sent to the user (unless the job is an at(1) job and the -m option was specified when the job was submitted).

Setting cron Defaults To keep a log of all actions taken by cron , CRONLOG=YES (by default) must be specified in the /etc/default/cron file. If CRONLOG=NO is specified, no logging is done. Keeping the log is a user configurable option since cron usually creates huge log files.

The PATH for user cron jobs can be set using PATH= in /etc/default/cron. The PATH for root cron jobs can be set using SUPATH= in /etc/default/cron. The security implica- tions of setting PATH and SUPATH should be carefully con- sidered.

Example /etc/default/cron file: CRONLOG=YES PATH=/usr/bin:/usr/ucb:

This example enables logging and sets the default PATH used by non-root jobs to /usr/bin:/usr/ucb:. Root jobs will continue to use /usr/sbin:/usr/bin.

/etc/cron.d/logchecker is a script that checks to see if the log file has exceeded the system ulimit. If so, the log file is moved to /var/cron/olog. FILES /etc/cron.d main cron directory /etc/cron.d/FIFO used as a lock file /etc/default/cron contains cron default settings /var/cron/log cron history information /var/spool/cron spool area /etc/cron.d/logchecker moves log file to /var/cron/olog if log file exceeds system ulimit. /etc/cron.d/queuedefs queue description file for at , batch , and cron .