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

    cir-79

    • Article Type: General
    • Product: Aleph
    • Product Version: 20, 21, 22, 23

    Description:
    What is the purpose of the Title Request router (cir-79) - the batch service used to move requested items along the roster (according to alephe/tab/tab_roster)? 

    Resolution:
    Info on the cir-79 Service from the "PDQ_Loaning and Returning Everywhere" Powerpoint....

    This batch process moves the active request to the next stop in the roster: it determines whether the request should be moved on and who the next potential supplier is.
    The request will be moved on to the next potential supplier if:
    - the requested item is not on a hold shelf
    - date set in the input variable has expired
    - call slip (paging slip) has not been printed
    - no item has been put in transfer to fulfill the request

    Other Services related to title requests are:
    call slip printing (cir-12, ue_06)
    Expired request deletion (cir-17)
    Item recalling (cir-13)

    A specific case in Nov. 2018:

    These "Hold Request Waiting Letter"s -- which use the ./nov01/form_eng/hold-request-wait-nn.xsl form -- are produced by three different programs: 

    b_cir_12_b 
    b_cir_26_b 
    ue_06_print_letters 

    In your case, we see that it is the nov50 ue_06 request daemon which is producing them. (If you doubt this, then please stop ue_06 in the evening before cir-79 runs. Check in the morning to confirm that no "Hold Request Waiting Letter"s or "Hold Request Slip"s have been produced. Then restart ue_06 and you will see them being produced.) 

    The z370.pdf document {describing the fields in the z370 ("Title Requests") record} says this: 

    "Every title request that is created in ALEPH is represented by two types of Oracle records: the Z37 record representing the requested item, and Z370 representing the title request. While the Z37 record includes information on the item that will fulfill the request, the Z370 record contains information that is related to the title request, such as which items may fulfill the request, in what libraries and in which order. 

    "Whenever a title request is submitted a single Z370 record is created. In addition, for every potential supplier a Z37 record is created. The currently active supplier’s request will be an active Z37 record. The rest will be inactive Z37 records. The non active supplier records become active when the roster batch ‘Title Requests Router (cir-79)’ activates them." 

    It seems to me that cir-79 cancels the request for the current supplier and makes the z37 request for a new supplier active. ue_06 sees this active request and, if the item is available, prints a hold-request-slip, and, if unavailable, prints a hold-request-waiting-letter. 

    Each z37_rec_key contains a Z37-SEQUENCE number. It would seem that the ue_06 program might use the logic that, if Z37-SEQUENCE is > 0001 (indicating that it is not the first request for this item), then don't produce a "Hold Request Waiting Letter", but, since this z37 request *could* be for some other patron, then it would seem that wouldn't really work. 

    I think what you suggest would require another field in the z37 record indicating that this is the first, second, third, etc., z37 *for this patron*. This could be an enhancement request, but I doubt anything would happen with it for at least a year or two. 

    **Actually**  the real problem (with the title-request not being created when is should be) in this case required a change to the create_z37s_from_supplier_list program, which was incorporated into Aleph 23 as a rep_change.

     

     


    • Article last edited: 10/8/2013