Amministrare un AS/400: come funziona il sistema · Capitolo 3 di 10

Oggetti, librerie e il file system

· 5 min di lettura · Software

Rivista il Verificata su IBM i 7.5

Accedi per salvare

Ogni cosa che esiste sul sistema è un oggetto, e ogni oggetto sta in una libreria. Sono le due frasi da cui parte tutto il resto di questo capitolo.

I tipi che si incontrano davvero

I tipi di oggetto sono decine, ma quelli che un sistemista vede tutti i giorni sono pochi:

Tipo Che cos'è
*LIB una libreria
*FILE un file: di dati, di sorgenti, video, di stampa
*PGM un programma compilato
*USRPRF un profilo utente
*JOBD una descrizione di job: da dove un lavoro prende le sue impostazioni
*OUTQ una coda di uscita, dove finiscono le stampe
*JOBQ una coda di lavori in attesa di partire
*SBSD una descrizione di sottosistema
*MSGQ una coda di messaggi
*DTAARA un'area dati: un valore che sopravvive alla fine del job

Il tipo si dichiara nei comandi, e va dichiarato: DLTF cancella un file, DLTPGM un programma, e comandi generici come WRKOBJ chiedono OBJTYPE perché due oggetti di tipo diverso possono avere lo stesso nome nella stessa libreria senza darsi fastidio.

Nota

un file di dati contiene membri. È l'eredità più visibile del modello a record: un file sorgente ne contiene uno per ogni programma, e anche un file di dati può averne più d'uno, cosa che oggi si vede quasi solo nei file di archivio storici. Molti comandi hanno perciò un parametro MBR, e quando MBR(*FIRST) non è quello che serve, il comportamento risulta inspiegabile finché non ci si accorge del parametro.

Le librerie sono un livello solo

Una libreria contiene oggetti. Non contiene altre librerie. Non esiste un percorso, non esiste una gerarchia, non si scende in un sottolivello: l'indirizzo completo di un oggetto è LIBRERIA/OGGETTO e finisce lì.

Chi arriva da un file system trova questo scomodo per una settimana e poi capisce che il posto della gerarchia è preso da un'altra cosa — la lista librerie, che è l'argomento del prossimo capitolo, e che è il vero motivo per cui un solo livello basta.

Alcune librerie sono sempre presenti e conviene riconoscerle:

  • QSYS — la libreria di sistema. Contiene tutti i comandi, tutti i programmi del sistema operativo, e — unica eccezione alla regola — le librerie stesse: un oggetto di tipo *LIB sta in QSYS.
  • QGPL — general purpose library. Il magazzino di tutto ciò che non ha trovato posto altrove. Su un sistema con vent'anni di vita è il primo posto dove guardare per capire che cosa è stato fatto in fretta.
  • QTEMP — una libreria privata di ogni job, creata quando il job parte e cancellata quando finisce. Due job che creano un file con lo stesso nome in QTEMP non si vedono a vicenda. È il posto giusto per i file di lavoro, ed è anche la trappola più comune: un oggetto messo in QTEMP da un programma non esiste più per il programma successivo se gira in un altro job.
  • QUSRSYS — dati di sistema che appartengono all'installazione e non a IBM: code di messaggi degli utenti, elenchi, alcune configurazioni.

Avvertenza

mettere oggetti propri dentro le librerie che cominciano per Q è una pratica che si paga agli aggiornamenti. Le librerie IBM vengono sostituite, e ciò che ci si è aggiunto non è garantito che sopravviva. QGPL e QUSRSYS sono le eccezioni previste per questo scopo; le altre no.

Guardare che cosa c'è

Il modo interattivo:

WRKLIB LIB(PROD*)
WRKOBJ OBJ(PRODLIB/*ALL) OBJTYPE(*FILE)
DSPOBJD OBJ(PRODLIB/ORDINI) OBJTYPE(*FILE) DETAIL(*FULL)

Lo stesso in SQL, che è la strada da prendere quando il risultato serve ordinato, filtrato, o dentro un programma:

SELECT OBJNAME, OBJTYPE, OBJOWNER,
       OBJSIZE / 1024 / 1024 AS MB,
       LAST_USED_TIMESTAMP, OBJTEXT
  FROM TABLE(QSYS2.OBJECT_STATISTICS('PRODLIB', '*ALL'))
 ORDER BY OBJSIZE DESC

Consiglio

ogni oggetto ha un campo di descrizione libera, il text. È di gran lunga la documentazione più utile del sistema, perché sta attaccata all'oggetto e si vede ovunque l'oggetto compaia. Vale la pena compilarlo — con CHGOBJD ... TEXT('...') — e vale la pena leggerlo prima di chiedersi a cosa serva un oggetto trovato per caso.

L'altro file system

Accanto alle librerie il sistema ha un file system gerarchico vero, l'IFS (Integrated File System), con cartelle, percorsi, permessi e nomi lunghi. Ci stanno i log dei server web, i file scambiati con l'esterno, i PDF, gli script, il Java.

L'IFS è organizzato in file system separati che si vedono tutti sotto la radice /:

  • / — la parte gerarchica, quella che ci si aspetta;
  • /QSYS.LIB — le librerie viste come cartelle: PRODLIB diventa /QSYS.LIB/PRODLIB.LIB e un file /QSYS.LIB/PRODLIB.LIB/ORDINI.FILE. Serve a far raggiungere gli oggetti agli strumenti che sanno usare solo percorsi;
  • /QOpenSys — un file system che distingue maiuscole e minuscole, per il software portato da Unix;
  • /QDLS — il vecchio sistema documentale, oggi da considerare storia.

I comandi sono altri: WRKLNK al posto di WRKOBJ, CPY al posto di CPYF, CHGAUT al posto di GRTOBJAUT. Chi si collega in SSH o via ACS si muove nell'IFS con i comandi Unix di sempre.

Avvertenza

l'IFS cresce senza che nessuno se ne accorga, perché non compare in nessuno degli elenchi in cui si guarda di solito. Spool e IFS sono le due cause più frequenti di un disco che si riempie su un sistema per il resto tranquillo. Una verifica periodica dello spazio, con WRKLNK o con SELECT * FROM TABLE(QSYS2.IFS_OBJECT_STATISTICS(...)), evita la sorpresa.

Torna all'indice della guida

#oggetti #librerie #ifs
← Torna al blog

Potrebbe interessarti

Commenti

Nessun commento ancora. Sii il primo a commentare!

Devi avere un account per commentare. Accedi · Registrati