Batch Job Info

[Jack Trachtman]

From within a Batch job (running a DCL script), how can I determine the name of the batch queue where the script is running and its batch que entry number? Thanks

[Jon Pinkley]

$ this_entry = f$getqui("display_job","entry_number",,"this_job")
$ this_jobname = f$getqui("display_job","job_name",,"this_job")
$ this_queue = f$getqui("display_job","queue_name",,"this_job")
$ this_param1 = f$getqui("display_job","parameter_1",,"this_job")

just some examples of what you can get.

[Jon Pinkley]

Sometimes you may want to know the name of the command file that was submitted, which
may not be the same as what is returned by f$environment("procedure"), for example if the submitted
job does an @getqui.com,

Also, if you are using generic queues, and you want the name of the queue the job was submitted to, you may want to use "restart_queue_name" instead of "queue_name". Not this is set even if you use submit/norestart

See attachment for an example showing the above two cases.

The attachment also shows how to get the log file specification using a program, as I am not aware of any way to get this information with the version number using builtin DCL functionality. It is not correct to assume that the highest version of a log file is the one associated with the running command procedure, for example if there are multiple instances running, at most one can be using the highest version of the log file.

If you are interested in the source code for the PPF program (ppf.mar) let me know, and I will attach it under a different reply, as I believe I can only attach a single attachment to a response.

Jon

[John Gillings]

re Jon's example:

When resubmitting the same job, F$ENVIRONMENT("PROCEDURE") can be a problem, because it returns the exact filespec, including version number. This means you won't resubmit a later version number if the procedure has been edited. To get around this I use:

$ self=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))

which returns the filespec of the latest version.

Log file specification can be a problem, as Jon has pointed out. If you're happy with device, directory and name you can do this:

$ IF f$getqui("DISPLAY_ENTRY",-
"JOB_LOG_NULL",,"THIS_JOB")
$ THEN
$ log_file = "NL:"
$ ELSE
$ log_file = F$PARSE(-
f$getqui("DISPLAY_ENTRY",-
"LOG_SPECIFICATION",,"THIS_JOB"),-
"SYS$LOGIN:.LOG;",-
f$getqui("DISPLAY_ENTRY",-
"JOB_NAME",,"THIS_JOB"))
$ ENDIF

If you care about the exact version, you can either use a program to determine the exact name from the PPF. If you want a pure DCL solution, try this:

$ IF f$getqui("DISPLAY_ENTRY",- "JOB_LOG_NULL",,"THIS_JOB")
$ THEN
$ log_file = "NL:"
$ ELSE
$ log_file = F$PARSE(-
f$getqui("DISPLAY_ENTRY",-
"LOG_SPECIFICATION",,"THIS_JOB"),-
"SYS$LOGIN:.LOG;",-
f$getqui("DISPLAY_ENTRY",-
"JOB_NAME",,"THIS_JOB"))
$ pid=F$GETJPI("","PID")
$ prcnam=F$GETJPI("","PRCNAM")
$ dev=F$PARSE(log_file,,,"DEVICE")
$ f=log_file-dev
$ PIPE SHOW DEVICE/FILE 'dev' | -
SEARCH SYS$PIPE: 'pid','f' /MAT=AND | -
(OPEN/READ in SYS$PIPE: ; -
READ in line ; -
DEFINE/JOB log_file &line)
$ lf=F$EDIT(F$TRNLNM("LOG_FILE")--
prcnam-pid,"COLLAPSE")
$ IF lf.NES."" THEN log_file=dev+lf
$ ENDIF

[Jack Trachtman]

Thanks all - when I scanned the f$getqui docs I missed the "this_job" param.

From the long repsonses, you may be interested in what I'm trying to accomplish.

We have batch jobs where the err handling includes notification via e-mail. I'm thinking it would be more efficient (in certain cases) to include the log file in the e-mail.

I'm thinking of have the err handler submit a script, passing it the submitter's batch quename, batch #, and list of e-mail addresses. The submitted job would wait for the submitter to finish via the SYNCHRONIZE cmd, then e-mail its log file.

Any suggestions/comments/ideas? Thanks

[Dean McGorrill]

hi Jack,
that should work quite nicely. you could always do a convert/share on its own
log from the running job w/o having an additional job. do a set output=00:00:10
wait 10 and you'll have everything in the
log. conv/shar it, and mail it. -Dean

[Jon Pinkley · Accepted solution]

Jack Trachtman wrote:
--------------------------------------------------------------------------------
We have batch jobs where the err handling includes notification via e-mail. I'm thinking it would be more efficient (in certain cases) to include the log file in the e-mail.

I'm thinking of have the err handler submit a script, passing it the submitter's batch quename, batch #, and list of e-mail addresses. The submitted job would wait for the submitter to finish via the SYNCHRONIZE cmd, then e-mail its log file.
------------------------------

Yes, that will work, and I have done that. It appears that was your plan to synchronize using the entry number, which in my opinion is what should always be done, as opposed to the queue and jobname, which are not guaranteed to be unique. Also, with entry number, you don't need to know the queue, and it will work even it the job has been requeued to another queue between the time it was originally submitted, and the time the synchronize command starts.

In fact you could write a command file like mail_this_logfile.com that you could invoke from any number of command files, and pass it things like a subject line, and who to send mail to, and that could default to the current user if not specified.

Generally I have the batch job that is synchronizing use search on the log file and send the portion with the error, searching for things like "-W-","-E-","-F-" and any other job specific errors. But these were for jobs that had large (1000 block or more) log files. And then send the interesting part along with a pointer to the original file, etc.

This may be obvious to you, but if you plan to mail the log file, it is a requirement that it doesn't get deleted before you mail it. So the job that is going to mail its log file needs to have been submitted with /keep (either explicit or implied by /noprint). You may get lucky sometimes if the logfile is being printed prior to be deleted, but you have no guarantee of when a batch job you submit will be executed. And of course, it has to have a log file produced in the first place. You could try Dean's suggestion of using convert/share. My preference is to use the synch method, as you are guaranteed to get the whole log file, including the statistics at the end.

I have some messages send mail that ends up as text messages on my cell phone, and for those, I send only the subject line, with a line similar to this.

$ mail/noself nla0: "secret@cellphone" /subject="Job ''this_job', entry ''this_entry' Aborted, see ''fid_file_name'"

If you are going to be mailing the log file, you want to make sure you send the correct version, so you should either use something like the PPF program or John Gillings' suggestion of searching the output of show device/files for the PID of the currently executing job. I wish there was an f$ppf(logical,name_type) function in DCL.

BTW, here's a modification to John Gillings' pure DCL version that will work with files on rooted logicals like sys$manager and also has the line that was not wrapped fixed.

$ IF f$getqui("DISPLAY_ENTRY","JOB_LOG_NULL",,"THIS_JOB")
$ THEN
$ log_file = "NL:"
$ ELSE
$ log_file = F$PARSE(-
f$getqui("DISPLAY_ENTRY",-
"LOG_SPECIFICATION",,"THIS_JOB"),-
"SYS$LOGIN:.LOG;",-
f$getqui("DISPLAY_ENTRY",-
"JOB_NAME",,"THIS_JOB"),,"NO_CONCEAL") - "][" - ">[" - "><" - "]<"
$ pid=F$GETJPI("","PID")
$ prcnam=F$GETJPI("","PRCNAM")
$ dev=F$PARSE(log_file,,,"DEVICE")
$ f=log_file-dev
$ PIPE SHOW DEVICE/FILE 'dev' | -
SEARCH SYS$PIPE: 'pid','f' /MAT=AND | -
(OPEN/READ in SYS$PIPE: ; -
READ in line ; -
DEFINE/JOB log_file &line)
$ lf=F$EDIT(F$TRNLNM("LOG_FILE")--
prcnam-pid,"COLLAPSE")
$ IF lf.NES."" THEN log_file=dev+lf
$ ENDIF

This returns in the log_file symbol what PPF does in the FID_FILE_NAME symbol except that the device name returnd is the physical device name instead of the f$getdvi(dev,"logvolnam"), but that would be easy to change if you prefer that form of device name.

I am attaching PPF.MAR which was renamed to, it has usage documentation in the comments.

To get PPF.EXE

save the attachment and get it to your VMS system. Rename to PPF.MAR, then

$ macro ppf
$ link ppf

Not tested by me on IA64, but I have no reason to think it will not work. Someone want to try it on IA64 and report whether it works?

PPF is useful for any process permanent file, for example files opened by DCL for which you want to know the version number that is opened. Even when you open a new version of a file, you should not assume it is the highest version after the open has finished. John Gillings' technique should also work for that case, although you would need to pass in the filespec used when the file was opened instead of the log file spec.

Jon

[Hoff]

There comes a time when it's easier to have a scheduling package riding herd on the batch queues and batch jobs (and various other tasks); when it becomes easier to centrally manage these tasks, rather than to build and maintain error handling, reporting and recovery throughout the various and individual tasks...

If you have reached your limit, there's a Kronos port around from the Freeware, and a recent update to the cron port was posted not to long ago, and there are commercial scheduling packages.

http://64.223.189.234/node/97

I've also used DECscheduler for many uses for many years; now called CA Unicenter Job Management for OpenVMS, IIRC. There are other choices in the commercial space.

[Jack Trachtman]

Thanks all