Che cos'è un AS/400, e perché non somiglia a nient'altro

Un AS/400 non è un server con sopra un sistema operativo diverso. È una macchina progettata a partire da un'idea precisa: i programmi non sono scritti per il processore che li esegue.

Il livello che nasconde la macchina

Fra il sistema operativo e il ferro c'è il Licensed Internal Code, e sopra di esso un'interfaccia astratta, il Machine Interface (MI). Un programma compilato è fatto di istruzioni per questa macchina astratta. Le istruzioni del processore vere le genera il sistema quando crea il programma, e IBM scrive che quelle istruzioni «possono essere cambiate nel tempo per ottenere programmi più efficienti o per adattarsi a hardware nuovo».

È da qui che viene la fama della piattaforma: un programma non dipende dal processore su cui è nato, e quando cambia l'hardware non va riscritto.

La memoria e il disco

Il secondo pilastro si chiama single-level storage: la macchina gestisce la memoria centrale e il disco con la stessa unità, la pagina, e un programma lavora su oggetti, non su blocchi di disco.

Da qui discende un fatto che sorprende chi arriva da altri sistemi: non si sceglie su quale disco mettere una libreria. Il sistema distribuisce i dati su tutte le unità dell'insieme a cui appartengono, e lo fa da solo. Quando si aggiunge un disco, i dati esistenti si possono ridistribuire con il bilanciamento dell'ASP (capacity balance).

Gli insiemi di dischi si chiamano ASP (Auxiliary Storage Pool), e sono l'unico punto in cui si decide qualcosa su dove i dati finiscono. L'ASP 1 è quello di sistema, dove va tutto ciò che non è stato messo altrove; accanto possono essercene altri, fino a quelli indipendenti, che in un cluster passano da una macchina all'altra. I tipi si comportano in modo diverso, e la differenza conta abbastanza da meritare il capitolo che segue.

Tutto è un oggetto

Su Unix tutto è un file. Qui tutto è un oggetto, e ogni oggetto ha un tipo che il sistema conosce: un programma è di tipo *PGM, un file *FILE, un profilo utente *USRPRF, una coda di stampa *OUTQ.

Non è una convenzione di nomi. I comandi lavorano su tipi precisi, e il tipo decide che cosa si può fare con un oggetto: un file si legge e si scrive, un programma si chiama. Il capitolo sugli oggetti e le librerie lo racconta per esteso.

Il database non è un prodotto a parte

Db2 for i è integrato nel sistema operativo: IBM lo descrive come «il gestore di database relazionale completamente integrato nel sistema». Non è un prodotto separato da comprare e installare.

Un file fisico creato con DDS è una tabella interrogabile in SQL, senza conversioni: IBM tiene una tabella dei termini che lo dice in chiaro. La tabella SQL è il file fisico, la riga è il record, la vista è il file logico, lo schema è la libreria.

Per un sistemista questo cambia il lavoro quotidiano. Non ci sono due elenchi di utenti, uno del sistema e uno del database: i diritti sono quelli degli oggetti. E molte informazioni sullo stato del sistema si leggono in SQL, perché il sistema le espone come viste e funzioni: è il motivo per cui su questo sito buona parte delle ricette sono query.

Che cosa cambia per chi amministra

Non si configura quasi niente a livello di file. La configurazione sta in oggetti (descrizioni di sottosistema, descrizioni di job, valori di sistema) che si modificano con comandi.

Il sistema è verboso di suo. I messaggi IBM stanno in file di messaggi, come QCPFMSG, e ogni messaggio ha un testo di primo livello e uno di secondo livello, con la causa e il rimedio. Chi viene da altri sistemi tende a cercare i log in una cartella: qui il registro, il job log, è attaccato al job che lo ha prodotto.

Le impostazioni di serie vanno guardate una per una. Il sistema ne porta molte da molti rilasci, e ognuna ha un valore di fabbrica che il sistema stesso conosce. Che siano adatte a una macchina precisa è un'altra domanda: «com'è uscito dalla fabbrica» non è una risposta a «com'è configurato bene».

Esempio. Un valore di sistema accanto al suo valore di fabbrica, in SQL:

SELECT SYSTEM_VALUE_NAME, SYSTEM_VALUE, SHIPPED_DEFAULT_VALUE
  FROM QSYS2.SYSTEM_VALUE_INFO
 WHERE SYSTEM_VALUE_NAME = 'QSECURITY'

Fonti

• IBM: Machine Interface Introduction (paragrafo «Atomicity»)
• IBM: Analyze Object Conversion (ANZOBJCVN)
• IBM: Types of disk pools
• IBM: Working with ASP trace and ASP balance
• IBM: Database overview
• IBM: Terminology: SQL versus traditional file access
• IBM: Types of messages
• IBM: Add Message Description (ADDMSGD)
• IBM: SYSTEM_VALUE_INFO view