Un AS/400 non è un server con sopra un sistema operativo diverso. È una macchina progettata a partire da un'idea che altrove non è stata seguita: il sistema operativo non conosce l'hardware.
Il livello che nasconde la macchina
Fra il sistema operativo e il ferro c'è uno strato chiamato SLIC (System Licensed Internal Code), e sopra di esso un'interfaccia astratta, il Machine Interface. Quando si compila un programma, il risultato non è codice per un processore preciso: è codice per questa macchina astratta. La traduzione in istruzioni reali avviene sotto, e non riguarda chi ha scritto il programma.
La conseguenza pratica è quella per cui la piattaforma è nota: un programma compilato negli anni Novanta gira su un Power di oggi, con processori che allora non esistevano. Non è emulazione, e non c'è una macchina virtuale in mezzo. È che il programma non ha mai saputo su cosa stava girando.
Avvertenza
la compatibilità non è assoluta. Il passaggio al rilascio 6.1 ha richiesto la riconversione degli oggetti programma al nuovo formato, e la riconversione ha bisogno del sorgente o dell'observability — le informazioni di traduzione conservate dentro l'oggetto. Un programma compilato su un rilascio molto vecchio, di cui nessuno ha più il sorgente e a cui qualcuno ha tolto l'observability per risparmiare spazio, è un oggetto che non si può portare avanti. Sono casi rari, e quando capitano bloccano un aggiornamento per mesi.
La memoria e il disco sono la stessa cosa
Il secondo pilastro si chiama single-level storage. Un programma non chiede "leggi questo blocco dal disco": indirizza un oggetto, e il sistema decide se quell'oggetto è già in memoria o va portato dentro. Non esiste un concetto di file aperto con una posizione sul disco che il programma debba gestire.
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à del pool a cui appartengono, e lo fa da solo. Aggiungere un disco non richiede di spostare niente a mano.
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 fisicamente. L'ASP 1 è quello di sistema, dove va tutto ciò che non è stato messo altrove; accanto possono essercene altri, fino a quelli indipendenti, che si staccano da una macchina e si attaccano a un'altra. I tre 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 dichiarato
che il sistema conosce e fa rispettare: un programma è di tipo *PGM, un file *FILE, un
profilo utente *USRPRF, una coda di stampa *OUTQ.
Non è una convenzione di nomi. Il sistema sa che cosa può essere fatto a un oggetto in base al suo tipo, e rifiuta il resto. Un file di dati non si può eseguire — non perché manchi un permesso, ma perché l'operazione non esiste per quel tipo. Questa è una parte importante del motivo per cui la piattaforma ha una storia di sicurezza diversa da quella di altri sistemi: molte classi di attacco presuppongono di poter far passare per codice qualcosa che è stato scritto come dato, e qui quel confine è nell'architettura, non in un controllo che si possa aggirare.
Il database non è un prodotto installato
Db2 for i è dentro il sistema operativo. Non si installa, non si avvia, non ha un processo da sorvegliare. Un file fisico creato con DDS trent'anni fa è una tabella interrogabile in SQL oggi, senza conversioni: sono la stessa cosa vista da due interfacce.
Per un sistemista questo cambia il lavoro quotidiano più di quanto sembri. Non c'è un database da tenere allineato al sistema operativo, non ci sono due elenchi di utenti, non esiste la domanda "chi amministra il database" come ruolo separato. E, all'inverso: molte informazioni sullo stato del sistema si leggono in SQL, perché il sistema le espone come viste. È il motivo per cui su questo sito buona parte delle ricette sono query.
Che cosa cambia per chi amministra
Tre cose, e conviene fissarle prima di andare avanti.
Non si configura quasi niente a livello di file. Non c'è un /etc da modificare. La
configurazione sta in oggetti — descrizioni di sottosistema, descrizioni di job, valori di
sistema — che si modificano con comandi e che il sistema valida nel momento in cui li si
tocca.
Il sistema è verboso di suo. Ogni job lascia un registro, ogni errore ha un codice, e il codice ha una spiegazione a due livelli consultabile sul momento. Chi viene da altri sistemi tende a cercare i log in una cartella: qui il registro è attaccato al job che lo ha prodotto.
Le impostazioni predefinite sono vecchie. Molte scelte iniziali risalgono agli anni Ottanta e sono rimaste per compatibilità. Questo non è un difetto, ma significa che "com'è uscito dalla fabbrica" non è mai una risposta a "com'è configurato bene".
Commenti
Nessun commento ancora. Sii il primo a commentare!
Devi avere un account per commentare. Accedi · Registrati