Le librerie sono un livello solo e non contengono altre librerie. La domanda che segue è ovvia: come fa un programma a trovare un file se nessuno gli dice in quale libreria si trova?
La risposta è la lista librerie: un elenco ordinato di librerie che appartiene al job, non al programma. Quando si nomina un oggetto senza dire dove sta, il sistema lo cerca nelle librerie della lista, una dopo l'altra, e si ferma alla prima che lo contiene.
Questo è il posto della gerarchia che sembrava mancare. Ed è anche l'origine di quasi tutti i problemi che cominciano con "sul mio ambiente funziona".
Le quattro parti
La lista non è un elenco piatto: ha fino a quattro parti, e solo la prima c'è sempre.
- Parte di sistema. Contiene le librerie che servono al sistema. La si prende dal valore di
sistema
QSYSLIBL, che di fabbrica contiene QSYS, QSYS2, QHLPSYS e QUSRSYS e ne può tenere fino a quindici. Per un job solo si cambia conCHGSYSLIBL. - Librerie di prodotto. Fino a due, e le gestisce il sistema: le mette e le toglie quando un comando o un menu ne ha bisogno. Non si toccano.
- Libreria corrente. Una sola. È quella in cui finisce un programma creato senza dire la
libreria; se il job non ne ha una, si usa QGPL. Si cambia con
CHGCURLIB. - Parte utente. L'elenco vero e proprio, quello dove stanno le librerie dell'applicativo,
fino a 250. Il suo valore di partenza dipende da come nasce il job (sezione qui sotto); il
valore di sistema
QUSRLIBL, fino a venticinque librerie, si usa quando la descrizione di job dice*SYSVAL.
Un cambiamento a QSYSLIBL o a QUSRLIBL vale per i job che partono dopo, non per quelli già
attivi.
Vedere quella del proprio job:
DSPLIBL
SELECT ORDINAL_POSITION, SYSTEM_SCHEMA_NAME, TYPE, TEXT_DESCRIPTION
FROM QSYS2.LIBRARY_LIST_INFO
ORDER BY ORDINAL_POSITION
La colonna TYPE dice a quale parte appartiene ogni libreria: SYSTEM, PRODUCT, CURRENT o
USER.
E quella di un altro job, che è quella che serve quando si indaga:
WRKJOB JOB(123456/MARIO/CHIUSURA) OPTION(*LIBL)
Solo per un job attivo: la lista di un job finito non c'è più.
Da dove arriva
Ed è qui che stanno gli equivoci, perché la parte utente iniziale non arriva sempre dallo stesso posto.
- Una sessione interattiva la prende dalla sua descrizione di job (parametro
INLLIBL), e durante la giornata la si modifica spesso a mano conADDLIBLE. - Un job sottomesso con
SBMJOB, se non si dice niente, eredita la lista di chi lo sottomette: il valore di serie diINLLIBLè*CURRENT. ConINLLIBL(*JOBD)la prende invece dalla descrizione di job usata dal job, con*SYSVALdaQUSRLIBL. - Una voce di schedulazione (
ADDJOBSCDE) non ha un parametro per la lista: il job la prende dalla sua descrizione di job, che di serie è quella del profilo utente.
Avvertenza
è la causa classica del «funziona quando lo lancio io e di notte no». Lo
stesso programma, sottomesso da una sessione, eredita la lista di quella sessione, comprese le
librerie aggiunte a mano; schedulato, riceve quella della descrizione di job, che spesso è più
corta. L'errore parla di un oggetto non trovato e sembra che manchi qualcosa: la libreria c'è,
ma non è nella lista di quel job. La verifica si fa con DSPJOBD sulla descrizione che il job
usa davvero, non sulla propria sessione.
Un modo per andare a colpo sicuro c'è, ed è dichiarare la lista nel comando che sottomette:
SBMJOB CMD(CALL PGM(PRODLIB/CHIUSURA)) +
JOB(CHIUSURA) +
JOBD(PRODLIB/JOBDBATCH) +
INLLIBL(PRODLIB DATILIB QGPL QTEMP)
Il rischio dell'ambiguità
Se due librerie della lista contengono un oggetto con lo stesso nome, vince la prima. Silenziosamente: nessun avviso, nessuna traccia nel job log, nessun modo di accorgersene se non chiedendoselo.
È il modo in cui nascono gli incidenti peggiori, perché il sintomo non è un errore ma un risultato sbagliato. Un file di collaudo lasciato in una libreria messa in cima alla lista "solo per una prova" fa girare la chiusura mensile sui dati di collaudo, e il programma non ha modo di saperlo.
Consiglio
la difesa che regge negli anni non è una lista librerie più corta ma la
qualificazione degli oggetti nei programmi — scrivere PRODLIB/ORDINI invece di
ORDINI dove la scelta non deve dipendere dall'ambiente. Costa un po' di flessibilità e
toglie di mezzo un'intera categoria di guasti. Nei punti in cui la flessibilità serve
davvero — perché lo stesso programma deve girare su collaudo e produzione — la lista
librerie è lo strumento giusto, ma allora la scelta va dichiarata e non subita.
Modificarla
Durante il job, per la sessione corrente:
ADDLIBLE LIB(PROVALIB) POSITION(*FIRST)
RMVLIBLE LIB(PROVALIB)
CHGCURLIB CURLIB(MIALIB)
In modo permanente, cambiando la descrizione di job da cui la prendono i lavori:
CHGJOBD JOBD(PRODLIB/JOBDBATCH) +
INLLIBL(PRODLIB DATILIB QGPL QTEMP)
Avvertenza
una JOBD è spesso condivisa da molti lavori. Toglierle una libreria li
rompe tutti insieme, e l'errore che ne esce parla di un oggetto mancante, cioè indica il
sintomo e non la causa. Prima di modificare una descrizione di job conviene sapere chi la
usa: WRKJOBSCDE per le schedulazioni, e la JOBD dei profili utente con
SELECT AUTHORIZATION_NAME, JOB_DESCRIPTION_NAME, JOB_DESCRIPTION_LIBRARY_NAME FROM QSYS2.USER_INFO. La libreria va chiesta insieme al nome: una job description senza la sua
libreria è ambigua, ed è esattamente l'ambiguità di cui parla questo capitolo.
Il limite
La parte utente arriva a 250 librerie, QUSRLIBL a 25, QSYSLIBL a 15. Non sono vincoli con
cui ci si scontra nella pratica, e una lista lunga è già un problema di per sé: moltiplica le
occasioni di ambiguità.
Commenti
Nessun commento ancora. Sii il primo a commentare!
Devi avere un account per commentare. Accedi · Registrati