La lista librerie

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 quattro sezioni, sempre in questo ordine.

1. Parte di sistema. Comincia con QSYS e contiene le librerie del sistema operativo. È la stessa per tutti i job e si governa con il valore di sistema QSYSLIBL.
2. Librerie di prodotto. Fino a due, gestite dal sistema quando serve. Non si toccano.
3. Libreria corrente. Una sola, ed è quella in cui finiscono gli oggetti creati senza dire dove. Si imposta con CHGCURLIB o dal profilo.
4. Parte utente. L'elenco vero e proprio, quello dove stanno le librerie dell'applicativo. Il valore predefinito per i job nuovi è il valore di sistema QUSRLIBL, ma quasi sempre viene sovrascritto dalla descrizione di job.

Vedere quella del proprio job:

DSPLIBL

E quella di un job qualsiasi, che è il comando che serve davvero quando si indaga: WRKJOB sul job, opzione 2, e la lista è lì.

Da dove arriva

Ed è qui che stanno gli equivoci. Un job non eredita la lista librerie di chi lo ha lanciato. La prende dalla propria descrizione di job, il *JOBD, e solo da lì.

Perciò:

• una sessione interattiva ha la lista che le dà la sua JOBD, spesso modificata a mano durante la giornata con ADDLIBLE;
• un job sottomesso con SBMJOB prende quella indicata nella JOBD del comando, che non è necessariamente quella della sessione da cui si sottomette;
• un lavoro schedulato prende quella della JOBD della voce di schedulazione, che nessuno guarda mai finché non va storto qualcosa.

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.

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)

Il limite

La parte utente ha un limite al numero di librerie, cresciuto nei rilasci fino a un valore oggi ampio. Non è un vincolo con cui ci si scontra nella pratica, e comunque una lista lunga è già un problema di per sé: allunga la ricerca di ogni oggetto e moltiplica le occasioni di ambiguità.