Indice generale del sito  | Indice analitico 

Pagina precedente
30.9. Stampa lista bibliografica con dati di copia dai Servizi   272 / 396  Pagina successiva
31.1. Test di un TARGET Z39.50 Indietro
ALEPH 500 (v. 16-18): documentazione tecnica  |  Torna alla pagina iniziale:
 31. Z39.50 configurazione 

Avvertenza:

  • questi appunti sono il frutto di esperienza di varie persone ed istituzioni, e comunque sono costruiti a partire dal documento dell'Università di Siena trasmesso a tutti in occasione del seminario ITALE su Z39.50 e cat. derivata -che si tenne all'Università di Udine nel marzo del 2003. Omissioni, errori ed ingenuità sono invece solo di chi scrive (fdo)
  • i caratteri maiuscoli e minuscoli nei nomi dei file sono significativi
  • l'esemplificazione qui è data sull'Università di Perugia come target perché è la prima -e per certi versi migliore- maniera di testare una configurazione  (cfr. il dettaglio della sua configurazione) : prima di renderla pubblica è molto utile testare la propria configurazione come target (da cliente esterno, da UTIL interna N/3/Z39 Gate check, o con lo yaz_client, dal proprio OPAC come gateway ...)
  • ad ogni modifica fermare e riavviare secondo le necessità: z39 server; z39 gate; www server; pc server
  • codifica dei caratteri: le varie possibilità di conversione stanno in $alephe_unicode/tab_character_conversion_line q.v., ad es.: UTF, 8859_1, 8859_5, WIN1251, MARC8, MAB etc. (e ANSEL ...), nella forma: [set]_TO_[set]. Occorre padroneggiare il funzionamento di questa tabella per controllare i nomi solo richiamati qui nei file di configurazione
Server

 Configurazione del server Z39.50

Servizi attivi (definiti da Ex-Libris):
Init -per default usa ID z39 e password z39- INITIALIZATION  è la richiesta di apertura di una sessione che poviene dal client, il server la stabilisce rinviando una InitResponse. In questa fase usa per default z39/z39 come ID/PWD
Search  richiesta di effettuare una ricerca da parte del cliente con nome della base dati e l'espressione e già il nome (anche non dato esplicitamente) dell'insieme dei record che verranno reperiti, il server invia una SearchResponse con il totale dei documenti che soddisfano la richiesta
Sort il cliente invia una richiesta di ordinamento di un insieme di record in base ad un criterio, il server la trasforma in un messaggio recepibile da Aleph ed ordina l'insieme SortResponse
Present il cliente con una PresentRequest domanda la 'presentazione' visualizzazione dei dati cui il server risponde da par suo (se, opzionalmente, la richiesta indicava una sintassi, e questa era OPAC, l'elementsetname viene ignorato e vengono trasmesse solo le informazioni sulla conistenza, holdings)
Scan il cliente invia richiesta ed espressione di ordinamento dell'elenco e il server dopo averla tradotta per aleph manda la sua ScanResponse
Close richiesta di chiusura della sessione
Delete-Result-Set  cancellazione di uno o più insiemi di record reperiti

  /exlibris/aleph/u20_1/alephe/tab/z39_server = $alephe_tab/z39_server

  1. z39_server.conf (il file di configurazione generale: non ci si scrive "quasi" nulla, commenti CON #)
    - necessario indicare nome indirizzo del pc server con porta:
        hostname <host>:<port> = l'host è qui il pc_server con la sua porta hostnamebiblioteche.unipg.it:9909
    - si può indicare un file di log per i record in formato ISO 2709 [UNI]MARC (se non lo si indica non viene creato file di log), secondo quanto indicato dall'istruzione: 
        marclog </[dir]/marclog-file-name> = ad es. marclog  /tmp/aleph-marc.log qui nella directory standard Linux/Unix tmp
    (n.b. in -/exlibris/aleph/a18_1/tmp/  -ossia $TMPDIR- il nome è assegnato in automatico nella forma: es. z39_gate_record.[36206.1]  --vi finiscono i record restituiti sia dal server che le query da gateway)
    (da noi c'è anche un aleph-marc.log che sta in /exlibris/aleph/u20_1/upg01/scratch/aleph-marc.log ma deve essere una vecchia ubicazione) 
  2. z39_server_base elenca le basi che fungono da server, ci sia dunque UPG01 con routine di conversione caratteri in I/O e formato record, i.e. UNIMARC (secondo l'Upgrade express 14.1 -> 16.2 p. 46 questo non esiste più)  ]
  3. z39_server_[nome base, es.=UPG01].conf = (nome della base -fisica o logica- con la propria configurazione come server: nomi degli indici e attributo d'uso Z39.50, codifica caratteri: out-record-syntax per i vari contesti indica come il server li cederà ai clienti)
    # fra i General Settings
    in-find-char-conv  8859_1_TO_UTF  = un esempio di come il server recepisce e converte una richiesta (ISO 8859-1) di ricerca nel proprio set di caratteri (UTF-8), [cfr. codifica dei caratteri]
    in-scan-char-conv 8859_1_TO_UTF = idem per lo scan
    out-scan-char-conv UTF_TO_8859_1 = all'inverso come il servente restituisce al cliente che lo ha interrogato in modalità scorrimento (scan)  a partire dall propria codifica interna
    opac-record-size <num> <num> sono KB, se i record OPAC (n.b.) scaricati eccedono <num> allora nella risposta ci saranno solo record con TAG MARC senza dati di posseduto OPAC
    #se si indicano nosort e noscan non si offrono questi servizi ai clienti
    #<real-base> <base name> per avere due db che di fatto puntano al medesimo
    out-record-syntax <syntax> = out-record-syntax        UNIMARC, se ne possono indicare varie, per l'elenco di quella ammesse cfr. la doc. Ex-Libris, comunque SUTRS, OPAC, XML, UNIMARC, USMARC ... sono ammesse, se è OPAC ignora l'element set name e restituisce i dati di posseduto; se il cliente non la specifica nella richiesta viene usata la prima riga
    out-record-format <format> (opzionale) formato fisico in relazione alla sintassi per default prende quello del syntax, ma possono essere diversi [sic cfr. loro esempio: da provare, per vedere chi si fa carico della conversione dei TAG ... mi è parso senza effetto alla prova con uni01 syntax UNIMARC e format USMARC, cioè credo ci voglia ben altro, a questa altezza mi risulta una finezza Ex-Libirs che ahimé non capisco e trascurerei]
    out-record-char-conv <char-conv> = out-record-char-conv     UTF_TO_8859_1 come il nostro server restituisce i caratteri a partire dalla propria codifica interna
    our-record-fix  <fix>  una fix routine da tab_fix .... [mai chiarito in quale momento entra in gioco: all'atto stesso del prelievo?]
    out-record-expand <expand> = out-record-expand        Z39_SERVER  ad es. da usare per i tag alfabetici, cfr. infra, va indicata per ogni sintassi

    #seguono:
    --  l'indicazione dei vari indici di ricerca per parola WORD (find), si possono anche appaiare più indici in OR dimodoché la ricerca per un canale (uso) cerchi in più di uno:
    word    (wde,wsu)  21  qui la ricerca per soggetto (21) cerca anche (OR) nel nostro indice per le etichette discorsive dei numeri Dewey
     
    -- l'indicazione dei vari indici di ricerca per frase (phrase) scan/browse
    -- le indicazioni per l'ordinamento (sort) dei record ceduti, es.:
    sort    01      31      Year
    sort    02      1003    Author
    sort    03      4       Title
    appoggiate su:
    ...xx01/tab/tab_sort:
    !!-!!-!!!!!-!!!!!-!-!!!!!-!!!!!-!-!!!!!-!!!!!-!-!!!!!-!!!!!-!-!!!!!-!!!!!-!-!!-!!
    01 99 100           210## d                                                 13 04
    02 99 700## a       701## a       702## a       710## a       712## a       00 00
    03 11 500## a       200## a       200## e                                   00 00


  4. z39_server_elements (file nuovo della v. 16) per i campi da concedere (esportare), contiene :
    1. la base: UPG01 (o UPG10 se si desse anche quella)
    2. Element Set name (X per USMARC e basta: include i TAG alfanumerici di Aleph;  B Brief -o altri- se uno lo vuole va definito esplicitamente qui; F Full -default; e nel caso quali TAG restituire ad una 'Present request'
    3. FMT proprio di Aleph
    4. TAG dove "##" vale per tutti, se F non viene indicato allora il server cede tutti i dati; per UNIMARC e i TAG alfabetici di Aleph vedi l'accrocco della tab04 o la tab_type_config.lng
    5. sottocampi:
    !   1                2  3  4                5
    !!!!!!!!!!!!!!!!!!!!-!-!!-!!!!!-!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    UPG01                F ## #####
  5. z39_server_update_errors
  6. Lo z39.50 server usa per default z39 come user ID e come password, ma ne accetta e conserva altre. Se si richiedono ID e PWD particolari occorre definire un utente ALEPH con tali estremi, come ogni altro utente, ad esso vanno attribuiti diritti relativi a z39.50 users per la library in questione. Se non si richiedono né ID né PWD dobbiamo curare che esista comunque un utente di nome Z39 con tali diritti e che le richieste che pervengono siano prive di richiesta di authentication, ossia rechino ID e PWD (avvisando gli utenti)
  7. xxx01/tab/tab_expand deve contenere per la sezione Z39_SERVER:
    Z39_SERVER expand_doc_bib_psts
    Z39_SERVER expand_doc_fmt  (The expand_doc_fmt program builds a TYP field from the record's format FMT field)
    Z39_SERVER expand_doc_bib_z30
    Z39_SERVER expand_doc_bib_tab04
      
    (questa mi sa funziona solo per USMARC e per UNIMARC si ricorre alla sezione 90 della tab04)

 

Target

  Configurazione di un target Z39.50

/exlibris/aleph/u20_1/alephe/tab/z39_gate  =  $alephe_tab/z39_gate (gate)

  1. z39_gate.conf contiene l’include dei vari file ...[nbase].conf dei target col nome con cui sono identificati nei vari z39_gate_[target].conf, es.:
    ....
    include z39_gate_UNIROMA2.conf
    include z39_gate_ACNP.conf
    include z39_gate_UNICATTO.conf
    include z39_gate_PERUGIAZ.conf
  2. z39_gate_[PERUGIAZ].conf per ogni target un file z39_gate[target].conf: configurazione di base di un target, qui si indicano
    target         <il nome del database target in maiuscolo come incluso in z39_gate.conf e in alephe_tab/tab_base>
    hostname       <IPhost : porta del server Z39.50>
    database       <dbname es.: UPG01>
    recordtype     <record format es.: UNIMARC)
    elementsetname  <es.: B per brief, F per full>
    timeout        <55 secondi è il default>
    closeconnection <la connessione viene interrotta dopo ogni azione [sic: mai visto verificarsi e preso alla lettera darebbe noia, si interrompe se fai azione non prevista, ad es. ricerca CCL]>
    auth            <termini di autenticazione, se è il caso anche nella forma: ID/pwd>
    nosort          <fa guadagnare tempo se il target non ammette sort, così manco glielo si chiede> 
    noscan          <fa guadagnare tempo se il target non ammette scorrimento di indici, così manco glielo si chiede>
    nosets          se il target non ammette assegnazione di nome agli insiemi (set naming)
    scanterm
    presentrecordnum <num> default è 10, per i lotti di record da visualizzare, prova 1 con chi te ne darebbe 1 solo e sennò errore (SBN)
    sorttype        <val> "s" o "S" se fa differenza al maiuscolo e "I" "i" se non la fa

    indici da interrogare per find e scan con:
    il codice di ricerca CCL e la serie degli attributi BIB-1 [o altro] :
    u uso (type 1)
    r relazione (type 2) è per default 3 = uguale a (con possibile troncamento e definizione di struttura)
    p posizione (type 3) è per default 3 = qualsiasi
    s struttura (type 4) indicabile anche con codice Aleph come: p=1 w=2: s=pw (a me pare che li tratti tutti come 6=word list il che è meglio, però potrebbe dipendere dalla routine di trasformazione 3 che inserisce AND fra i termini di ricerca, o dalle regole implicite del server/target così come agisce Aleph rispondendo boh...)
    t troncamento (type 5) indicabile anche con codice Aleph come: l[eft]=2 r[ight]=1 b[oth]=3 : t=l,r,b 
    c completezza (type 6) è per default 1 = campo incompleto
    nella forma <tipo attributo>=<valore secondo lo standard Z39.50 oppure valori speciali Aleph per troncamento e struttura, vedi sopra> :
    find WAU  u=1003 t=l,r,b s=pw c=1
    N.b. particolarità per attivare la visualizzazione dei record completi selezionando una voce di un indice a scorrimento (altrimenti impossibile salvo ISBN e ISSN): definire l'indice a scorrimento come find (eseguirà dunque un FIND su lista SCAN/BROWSE), negare troncamento t=100, definire la struttura a frase s=1, es.: find TIT  u=4 t=100 s=1
    sort 
     nella forma sort <codice aleph 01 02 03> u=<valore dell'attributo 1 'uso'>, es.: sort=01 u=30 sort su data corrispondente a 'use 30' in z39.50 Bib-1

/exlibris/aleph/u20_1/alephe/gate = $alephe_gate (universal gateway)

  1. [perugiaz].conf (n.b. in minuscolo): per ogni target un file [target].conf che contiene anche (vedere documentazione Ex-Libris): 
    Z58-BASE-NAME                         che comparirà accanto alle copie nella scheda completa+link accanto al posseduto/collocazione (necessario cfr. sotto Z58-HOLDING-METHOD)
    Z58-ACCESS-METHOD                     Z39 fisso (necessario)
    Z58-BASE-REMOTE                       nome della configurazione presso di noi, es. PERUGIAZ in maiuscolo perché è quello di z39_gate_[PERUGIAZ].conf  (necessario)
    ## istruzioni OUT       verso il target = richieste/ricerche di Aleph che, quanto all'insieme dei caratteri, le formula in UTF-8 e vanno tradotte in ciò che il target accetta [cfr. sopra codifica dei caratteri]
    Z58-OUT-FIND-CHAR-CONV                <tipo-conversione> UTF_TO_8859_1 (necessario solo se diverso da Unicode UTF-8)
    Z58-OUT-SCAN-CHAR-CONV                <tipo-conversione> UTF_TO_8859_1  (idem)
    ## istruzioni IN        dal target = risposte del target: quanto all'insieme dei caratteri Aleph accetta in UTF-8 ma i dati provengono dal target che li cede a suo modo, che va ricavato dalla documentazione sul target [cfr. codifica dei caratteri]

    Z58-IN-RECORD-TYPE                    <record-type in entrata> importante: record syntax restituita dal target, es. USMARC (necessario)
    Z58-IN-RECORD-CREATE                  <programma> : vir_z00_z39_usmarc per USMARC e UNIMARC etc. (sarà vir_z00_z39_sutrs_<target> per record-type in SUTRS (simple unstructured record syntax:ad es. ad etichette) (necessario)
    #Z58-IN-RECORD-CREATE-PARAM           se Z58-IN-RECORD-CREATE è sutrs qui ci sta come oggetto-parametro il nome di una tabella di conversione da SUTRS in ALEPH, file che starà in ext02/tab ext01/tab... 
    Z58-IN-RECORD-CHAR-CONV               MARC8_TO_UTF (es.: Aleph recepisce e dunque converte in UTF-8, lasciare vuoto se è già Unicode anche ciò che viene dal target) [cfr. sopra codifica dei caratteri]
    Z58-IN-RECORD-FIX                     <fix routine> nome convenzionale del programma (ad es. 'FMT') che deve essere poi così richiamato e poi indicato col suo vero nome nella tab_fix della ETX00x appropriata al target da cui si ricavano i record (ne è un esempio fix_doc_create_fmt per trasformare il valore del LDR -MARC21 e UNIMARC- nel TAG proprio di Aleph FMT assente in molte cessioni di dati di server Z39.50, per cui comunque vedi anche sotto in tab04)
    Z58-IN-DIRECT-KEY                     <chiave> es: TAG cfr. sotto
    Z58-IN-DIRECT-KEY-PARAM               <001> TAG in cui spedire il $c del campo SID ricevuto, necesario se c'è il preced. (altri valori ammessi: 035, 092, 016, 544)
    Z58-IN-SCAN-CHAR-CONV  <char conv>    8859_1_TO_UTF, da cosa cede il server all'UTF-8 che accetta Aleph, è un es. come gli altri [cfr. codifica dei caratteri]
    Z58-SORT                              Y/N (default N) dipende da quanto è stato deciso da altri lato servente/target, cfr. in z39_gate_[target].conf per come ordinare i record recuperati all'interno delle possibilità date
    Z58-HOLDING-METHOD                    <metodo> es.: OPAC [n.b. aggiungere il campo ITM6 alla edit_doc_999.[lng] delle biblioteche EXT001 coinvolte], altri valori sono ammessi per il profilo Bath 2.0 (se c'è deve esserci Z58-BASE-NAME)

    qui eventualmente la ridirezione degli indici per ogni target e le trasformazioni che si specificano come TR "routine di trasformazione" della query (cancella, sostituisci, usa l'AND fra parole...: mai seriamente appurato quanto in effetti queste funzionino), eccone un esempio secondo la struttura dovuta:
    Z58-TAB01
    Z58-TAB01-TYPE            find [può essere find, scan, sfind)
    Z58-TAB01-CODE            WAU  [codice CCL Aleph usato in ricerca]
    Z58-TAB01-CODE-TARGET     WAU  [codice usato in z39_gate_[target].conf, se diverso dal prec. si attua una ridirezione da quello verso questo*]
    Z58-TAB01-FILING          7P([/<P_3

    *la ridirezione funziona mettendo in Z58-TAB01-CODE il canale usato per la ricerca, quello che apparentemente riceve la query e in Z58-TAB01-CODE-TARGET il campo del target in cui effettivamente cercherà, dunque ad es. se nel primo metto l'indice del formato Aleph, da noi WFT e nel secondo WTI, cercando CF (formato per computer files) dal canale Formato cercherà questa stringa in realtà nei titoli (naturalmente è solo un'esemplificazione con nessun senso bibliografico, mentre la può avere per la Cattolica, ad es. fare puntare WTI su WRD più permissivo)

  Target e tabelle delle varie libraries 

  1. indici da usare in ricerca: vanno dichiarati nella tab00.[lng] rispettivamente delle library EXT01 (USMARC) e EXT02 (UNIMARC) (normale che si fissi una volta per tutte, salvo casi particolari)
  2. indici da usare in ricerca selezionabili dal cliente GUI pc_tab_sear.[lng] rispettivamente delle library EXT01 (USMARC) e EXT02 (UNIMARC) (normale che si fissi una volta per tutte, salvo casi particolari)
  3. visualizzazione: edit_field.lngedit_doc_999.[lng] delle libraries EXT01 e EXT02 per visualizzare (che so: 856...), anche  i dati di copia  tramite istruzione ITM6 (normale che si fissi una volta per tutte, salvo casi particolari) (cfr. sopra il parametro Z58-HOLDING-METHOD nel file ) [target].conf
  4. target: $alephe_tab/tab_base.[lng] lista dei target: si aggiorna per ogni nuovo target
  5. target: [UPG01]/tab/tab_locate per la funzione localizza in catalogazione (nel cliente cfr. sotto ..\alephcom\tab\locate.dat) : N.B. si aggiorna in ogni library (ext01, ext02...) da cui si vuole fare eseguire la localizzazione e per ogni nuovo target la/le tab_locate saranno di presenza attiva nel modulo ILL2 del prestito interbibliotecario: i TAG devono essere propri alla library da cui parte la richiesta di localizzazione : in EXT01 la locate_tab avrà i TAG USMARC, quindi 245 per il titolo
  6. conversione per la catalogazione derivata: XXX01/tab/tab04  per la conversione da TAG a TAG, scarico dei dati (quanto qui non previsto verrà ignorato nel momento in cui la si rende operativa), (normale che si fissi una volta per tutte, salvo casi particolari)
    1. il server Aleph cede anche i tag alfabetici come FMT e dati di copia (discende da una fix Ex-Libris): per questi deve esserci una sezione 90 nella tab04 trattata divesramente dalle altre, tipo:  
      90 Z#### 1A368      950## N 1A368
      90 FMT##            009## N a
      90 SYS##            909##
      !90 CAT##            955## N
      90 #####            ##### N
    2. XXX01/tab/tab_fix dà un nome e richiama la tab04-nn dove 'nn' è la porzione della tab04 interessata al tipo di conversione, es.:
      ...
      04-01   fix_doc_tab04_01
      ...
      dove "04-01" è il nome in cui il suffisso "_01" è la porzione della tab04 interessata alla conversione
    3. il nome è usato nella XXX01/pc_tab/catalog/fix_doc.[lng] e la didascalia accanto (Conversione da USMARC a UNIMARC) è quanto si vede da cliente GUI in Aggiusta record:
      04-01 N L Conversione da USMARC a UNIMARC 
      ciò entra in causa solo quando in Catalogazione derivata -dopo apri, duplica-, si attiva la fix descritta secondo fix_doc.[lng] per l'Aggiusta record, altrimenti, cfr. usando EndNote, tira giù tutti i TAG presenti nel record, anche ignorati dalla tab04 e infatti l'help della tab04 dice che i TAG verranno eliminati quando si attiva la tab_fix o la expand_doc routine, ma non altrimenti.
      Nota per il formato FMT: può venire ceduto dal server in un TAG proprio ad hoc -tipo 009- e come tale intercettato in tab04 rispetto ad altri traget Aleph cedenti, 04-01 o 02 ..., es.: 02 009  FMT
      [ad oggi nella v. 18 appone ancora un blank di troppo davanti che lo rende intrattabile ad es. ad EndNote, questo non si vede, non si verifica ad es. con lo yaz client; Ex-Libris ha poi proposto di creare un campo virtuale per il formato, ma i miei esiti sono stati anche peggiori: alternativa per il trattamento dello FMT cfr. documentazione a parte])

  Target e Cliente GUI

  1. ../alephcom/tab/library.ini lista delle library che includerà EXT01 e EXT02 (stesso IP e porta del pc-server per tutti: normale che si fissi una volta per tutte), es.:

    ALEPH                          ALEPH biblioteche.unipg.it:6991
    UPG01 - Catalogo bibl.         UPG01 biblioteche.unipg.it:6991
    UPG10 - Catalogo di autorità   UPG10 biblioteche.unipg.it:6991
    USMARC  EXT01 globale          EXT01 biblioteche.unipg.it:6991
    UNIMARC EXT02 globale          EXT02 biblioteche.unipg.it:6991
    etc. ... 

  2. ../alephcom/tab/searbase.dat lista delle basi Aleph con ancoraggio a EXT01, EXT02 etc.: si aggiorna per ogni nuovo target, es.:
    Catalogo bibliograf. UPG01 UPG01                UPG01
    Catalogo autorità UPG10    UPG10                UPG10
    Library of Congress  (US)  LOC                  EXT01
    Melvyl California.DL (US). MELVYL               EXT01
    Oxford University (UK)     OXFORD               EXT01
    LOUVAIN (BE) Univ. cathol. ULOUVAIN             EXT01
    LYON (FR) Univ. Lyon 3     ULYON3               EXT02
    BRESCIA Università         UBRESCIA             EXT01
  3. ../alephcom/tab/locate.dat per localizzare in catalogazione, nomi dei target in chiaro, si aggiorna per ogni nuovo target anche copiandovi la searbase.dat, ad es.:
    Library of Congress        LOC                  EXT01
    LYON (FR) Univ. Lyon 3     ULYON3               EXT02
    etc. ...

  4. ../catalog/tab/per_lib.ini lista acronimi delle libraries Aleph contemplate (permitted) UPG01, EXT01 per USMARC/MARC21, EXT02 per UNIMARC etc.: una volta toccato di norma non si aggiorna più, es.:
    UPG01
    UPG10
    UPG50
    UNI01
    UNI10
    UNI50
    EXT01
    EXT02 etc.
     

  Target e OPAC web
../alephe_root/www_f_ita

  1. - find-m : la lista dei target come da tab_base.lng (cfr. sopra) si aggiorna per ogni nuovo target 
  2. - find-code-include : indici da usare  una volta toccato normalmente non si aggiorna più (ma dipende se un target ne ha di suoi che vogliamo considerare...) 
  3. - locate-list : basi su cui localizzare il record (cercarne di simili) si aggiorna incrementandolo per ogni nuovo target

  Sort dei risultati in OPAC web

tab_sort di EXT02 (database di appoggio per i target UNIMARC, idem per EXT01 MARC21) fissa i campi su cui effettuare l'ordinamento, nell'esempio UNIV-PG:
01 99 100           210## d                   00 00                         13 04
02 99 700## a       701## a                   00 00
03 99 500## a       200## a                   00 00

devono essere in armonia, sempre in EXT02, le definizioni nelle tabelle www_f_sort_heading.[lng]:
01---D       Anno (discendente)             Anno(d)
01---A       Anno (ascendente)              Anno(a)
02---A       Autore                         Autore
03---A       Titolo                         Titolo

[che in caso di cattivo funzionamento erano:
!02---A01---A Autore, poi Anno               Autore, poi Ann
!01---D02---A Anno, poi Autore               Anno, poi Autor
!01---D02---D Anno, poi Autore               Anno, poi Autor
!02---A03---A Autore, poi Titolo             Autore, poi Tit
!03---A01---A Titolo, poi Anno               Titolo, poi Ann
!03---A01---D Titolo, poi Anno               Titolo, poi Ann
!01---D03---D Anno, poi Titolo               Anno, poi Titol]

Si armonizzano le specifiche nei vari file di gateway (alephe_tab/z39_gate/z39_gate_[TARGET].conf ) dove si fissa:

sort 01 u=31  
sort 02 u=1003
sort 03 u=4

ottenendo così un ordinamento discendente per anno.
Ma il sort sta anzitutto come possibilità nella configurazione del servente (target cedente), cfr. dunque sopra.

  variabile www_parallel_search_base nel file $alephe_root/www_server.conf deve puntare a db [UPG]01 di produzione

  LOG in $LOGDIR/z39_gate_<numero porta> e cfr. sopra nella configurazione del server

  VIR001 db temporaneo per i record recuperati

nascitaoristano
terralba
trento
Parole chiave Porta (dei server) ; Z39.50
Università degli studi di Perugia - CSB - Servizio della biblioteca digitale: Ufficio Aleph / a cura di Francesco Dell'orso 
v. 2.3 - ottobre 2010;
vai alla pagina iniziale