tag:blogger.com,1999:blog-1718921294435140810.post7834210267195482879..comments2023-07-14T00:50:59.579-07:00Comments on The Born-again Sysadmin: Fun dealing with 'at'Olivier S. Massehttp://www.blogger.com/profile/10917993970005588091noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-1718921294435140810.post-74462310208773044782010-09-07T08:25:27.340-07:002010-09-07T08:25:27.340-07:00Have you thought about writing an AT like front en...Have you thought about writing an AT like front end to an existing scheduler like CA's AutoSys? With AutoSys you can create batch schedules run jobs put them on hold etc. from a *NIX or DOS shell but it is not exactly easy. It also has a web based GUI for managing and tracking your batch schedule, graphing batch history etc. unfortunately the license doesn't come cheaply.Unknownhttps://www.blogger.com/profile/00172266416775238015noreply@blogger.comtag:blogger.com,1999:blog-1718921294435140810.post-7114588899916458672010-03-01T15:24:27.398-08:002010-03-01T15:24:27.398-08:00You could put /var/spool/cron/atjobs on to shared ...You could put /var/spool/cron/atjobs on to shared storage. Then you don't need to move that at jobs around.<br /><br />The best strategy is often to have a scheduled jobs package which then uses ssh to log in to the IP address of the package where the job should run.<br /><br />You can see the contents of an "at" job with "-d", which I presume is what you used in your wrapper.<br /><br />But yes, at/batch are a bit lame, aren't they?Greg Bakerhttp://www.ifost.org.au/~gregbnoreply@blogger.com