How to get at -l to work please

[jp]

Well, it doesnt work for me (11.11, N series).
Have a job running, can find it in ps -ef, but at -l returns nothing.
Question - the job number returned by at or batch - does it mean anything? Can I relate it to anything? Even if I put
exec >/tmp/stdlist.$$ 2>&1
in the start of the job, I only get a process id, not the job number in my stdlist file. I need to relat job ids to output files so I know what happened.
TIA,
jp

[Naveej.K.A]

hi,
at -l is only going to return the jobs which are shceduled to run and not the running jobs.

with best wishes
naveej

[Mark Grant]

Unfortunately, the script does not know the job number. The only way I can think of doing this sounds a bit overly complicated.

Make sure you have an environment variable set to something unique to your job. For example "THISJOB=tuesday". This must be set in the shell before you issue the "at" command. Then, get your script to grep for "THISJOB=tuesday" in all the files in /var/spool/cron/atjobs. It should find one file and that will have the name of the jobnumber.

The reason this might work is that "at" creates a file with the name of the job number in /var/spool/cron/atjobs. This file contains the environment when "at" was run and the job to do. This is the file that cron runs when the time is right. I imagine that this file exists while your job is running.

[jp]

Thanks guys, gives me something to chase. I read at -l as showing running jobs, maybe I misread the man page, but thats the way it seems to me.
I dont understand at issuing a job number that is not stored anywhere useful, doesnt make sense. On MPE you can SHOWJOB the number, show all jobs and see their numbers, find their stdouts by job number, find their printer outputs by job number etc. The queues are a nice touch though, like that part.
jp

[Naveej.K.A]

hi,
What i meant was at -l would return all the jobs which are sheducled to run and not the one which are currently getting executed or run in the background.

As mark has told, the at command copies all the shell variables and other umask and ulimit infomration adn the commands to be executed to a file with the same job-id in /var/spool/cron/atjobs and this file is getting executed at the scheduled time. this file gets deleted immediately after the run time and the information regarding the job-id is lost

try the -m option and it will mail the user who invoked the at job and it will contain info about the job-id

with best wishes
naveej

[Ed Sampson]

One way to tie the at job id to the pid is
to parse the cron log file /var/adm/cron/log.
this file will have 3 entries for each job that is run. The first entry will look
something like this.
> CMD: 1078386840.a
> root 16475 a Thu Mar 4 01:54:00 CST 2004
< root 16475 a Thu Mar 4 01:55:00 CST 2004

The > signs are starting messages and the
< sign is an ending message. If the cron job bombs you will also see a cc= on the ending line with the condition code. Hope this helps.

[jp]

Getting there I think. These jobs are going to be programmatically submitted by users who will never see the op system or mail, so -m is a waste of space. If something goes wrong, they will ring me and say 'What happened to my job?' I will say what was its number', they will say 'Que?'. So then I have to sort through somewhere looking for the stdout based on the program they think they ran, at some forgotten time, probably yesterday, so I am deep in it, unless I can find a way to produce an audit trail of some sort......
jp

[Jakes Louw]

I think you'll have to convince them to make proper use of log files to keep track of their jobs.
Then they can do their own diagnosis.

That's what I do, and it takes a whole load of my shoulders!