Job list, Column 3 (Queue Y/N)
- Article Type: General
- Product: Aleph
- Product Version: 16.02
Description:
From our own testing we've observed the following:
1. Col. 3 (Queue Y/N) refers to whether or not the job should be submitted to the batch queue of the library specified in Col. 5, when running an Aleph procedure. Is that assumption correct?
2. Setting Col. 3 to "N" causes the Aleph procedure specified to bypass the batch queues entirely, including logging in batch logs, etc. Is that correct?
3. Setting Col. 3 to "N" seems to cause the output file specified in Col. 4 to go to a print/save-YYYY-MM-DD directory, to which the Task Manager/Print Daemon appears to have no access.
How do other Aleph customers work with these files?
Do you set all jobs to "Y" to send them through the batch queue and print daemon?
Do you send output from programs only to the print/save directory?
Have you worked out a way to print the contents of the print/save directory via a system printer?
Resolution:
Note: If the job list entry does not have any ALEPH library associated with it (that is, no library in column 5), then column 3 *must* be "N". (The "queue" is always the queue of a particular library.)
[From Christine Moulen, MIT:] At MIT, were running v14.2.2. I guess I've never really considered col 3 in the job_list. All of ours are set to Y. I can think of various reasons why I wouldn't generally want to set it to N, in addition to your observations, if they are correct. I like to see scheduled jobs appear in the batch queue. It's an easy way to check whether they have run, and how long they typically run. Depending on the job you are running, you may really need it to be queued. If one job depends on another one to finish, then you don't want the second job starting before the first one is done. It's difficult to schedule the second job perfectly. The server could be particularly busy one day, or there are just a lot of records to process another day. Or if you have 2 jobs that update the database in some way, you probably don't want them to be running at the same time. Or what if you're running a special process like indexing? Your scheduled jobs may (or may not) need to wait in queue until that special procedure is completed. This could be a difference between v14 and v15, or could be particular to the jobs you are testing, but whenever I run a procedure from the UNIX command line (which also skips the batch queue) it still ends up in the batch logs. [e.g. p_manage_02, p_manage_36, p_file_96]
I've never found a way to make the Task Manager client see the files that go into a print/save-xxxx-xx-xx directory. However, the only things that end up in ours are the output files that have already been handled by the print daemon. If for some reason the print job fails, staff can always call me and I'll move the file back into the print directory for re-printing. Or they can usually find it in their own client files directories.
[Additional from Andy Perry:] I use the col. 3 setting of "N" for all external scripts that I run via job daemon. At Binghamton we have done this for many jobs. All the regular aleph jobs I run with col. 3 = "Y". Examples:
W7 03:55:00 Y VIR01 clear_vir01 VIR01
! Acquisitions Commitments/Expenditures Report - runs Monday
WS 06:30:00 N com_exp.log /aleph/u50_5/batch/com_exp/com_exp.ksh
I do use system printers for much of our output rather than use print daemon. I use enscript on the unix host to do some minor reformatting of the output before printing directly to a system printer.
- Article last edited: 10/8/2013