Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    exploring restructuring our hold request procedures

    • Article Type: General
    • Product: Aleph
    • Product Version: 18.01

    We are considering restructuring our hold request procedures - because our current practices are not advantageous to our staff. We are thinking about creating a cron job (or something similar) to run each night, seperately for each of our sublibraries. Each job would hopefully retrieve the items on hold for the following day and notify the sublibrary staff by email and possibly by printing to a specific printer.

    I have never created a cron job, and I can't seem to find any documentation on the Ex Libris Documentation Portal or in the Knowledge Base about creating them for hold request reports. I also wonder what the advantages are for the different Circulation jobs: cir-07, cir-11, and cir-24? Or is there another that is better? Are there certain reports that your customers have preferred over others?

    Background versions of these hold-request report jobs could be created using cron. Cron is outside of Aleph and there is no Aleph doc on using cron (though there are a few KB records).

    But since these are standard Aleph jobs it makes more sense to run them using the job_list and job_daemon anyway. This is described in KB's 3168 and 3169 and the "Aleph Configuration Guide" on the Doc Portal.

    As to which job to use ... statistics show that p_cir_11 is the most commonly run, followed by p_cir_07. p_cir_24 is less commonly run. I suggest that you look at the GUI Services - Help for each job, see if it seems to meet your needs, and try running each.

    [Later, followup question from customer:]

    We want to be able to email these reports to staff, will we be able to do that with the job list?

    [Reply, from Joan Kolarik:]

    The problem with emailing reports is that they don't have an email address embedded in them like personal patron/vendor letters do.

    The cron job might be a reasonable solution, but doesn't it just email a notification that a job is complete?

    It wasn't clear to me if they want the content or just a notification that the job is run. The initial question sounds like they want alerts, the later detail sounds like they want content.

    You could use the tab_alert table to direct emails about jobs to a user, but this is not applicable at a report-specific level. It's all CIRC reports or none.
    This is a sample of Aleph's alert email that a job has been run (note that you can see if any letters were generated -- would this be sufficient?):
    - - - - -
    Date: 24/03/2010


    Batch job details :
    Job-number: 495
    Job-name : Overdue Summary Single Letter (cir-52)
    Parameters: NPL50,jkcir52,Y,,Y,,,,00,00,N,00,4,3,Y,
    Start At : 24/03/2010 10:22
    End At : 24/03/2010 10:25
    Status : Success
    Log File : /exlibris/aleph/u20_1/alephe/scratch/npl50_p_cir_52.00243
    Job Type : CIRC
    User : MASTER

    Job specific parameters
    Number of processed records:10878
    Number of filtered out by loan status:0
    Number of filtered out by filters:0
    Number of overdue letters:2545

    Job Errors
    No Errors


    Sincerely yours,
    ALEPH system
    - - - - -

    In theory, of course, you could email all CIRC report alerts to a generic email address and use a tool like Outlook to automatically forward certain emails to specific people.
    This might be a better solution than cron because you could get pretty elaborate in your forwarding rules.
    But it's still only an alert, not the job content.

    You can always manually email any printable file generated by a service from the Print History dialog, but I don't know a way to automatically email the content of a report (although I can imagine a cron job that would run a script that would poll the ADM print directory, or wherever, for new files with certain names and automatically mail those files to someone -- but then they'd be receiving the raw XML and would have to figure out what to do with that).

    • Article last edited: 10/8/2013