Come già scrivevo, ho recuerato questa macchina, purtroppo senza terminale.
Sono alla ricerca anche di manuali e sistema operativo, purtroppo non trovo
molto in giro. Qualuno ne sa qualcosa?
Dubito che in rete troverai qualcosa di sostanzioso e interessante. Come
saprai (lo sai, vero?), quello è un sistema della famiglia S/36, diciamo non
troppo ambìto da chi si interessa di retrocomputing perché non ci si può
fare molto di più che accenderlo e giocherellare un po' con i comandi ed
eventualmente con i programmi contabili e gestionali di chi lo usava per il
suo scopo originale, visto che nasce specificatamente come sistema per la
gestione aziendale (ordini, bolle, fatture, pagamenti, magazzino ecc.).
Ho visto un altro messaggio in cui chiedi informazioni sui terminali e ti
rispondo qui: un terminale Twinax ti serve per forza, almeno per la console,
e le porte seriali servono solo per funzioni di telecomunicazione tipo SNA
su SDLC. Su macchine più vecchie le seriali potevano addirittura non essere
collegate: erano montate sul telaio, ma poi era necessario acquistare a
parte le schede di interfaccia verso il resto del sistema. Il TCP/IP su quel
genere di host non è mai esistito, quindi non pensare a cose tipo SLIP.
Quello che noi oggi chiameremmo sistema operativo, lì è suddiviso in due
parti distinte: un microcodice che svolge tutte le funzioni di basso livello
(ma non è dato sapere se è effettivamente un microcodice in senso stretto) e
un sistema operativo formato da una miriade di programmi più o meno piccoli
che svolgono le varie funzioni di alto livello, compresa l'interfaccia verso
l'utente. Il microcodice non ha nome, il sistema operativo (nell'accezione
IBM appena detta) si chiama SSP, cioè System Support Program.
Non ho mai avuto occasione di lavorare su un vero S/36, ma ho trafficato
parecchio sia con l'ambiente 36 di OS/400, cioè in pratica un'estensione
dell'interprete dei comandi di OS/400 che quindi accetta anche buona parte
dei comandi SSP (ma sempre OS/400 è), sia con la c.d. "Macchina 36" che
invece è una vera e propria macchina virtuale ospitata da OS/400 in cui si
installa un'apposita versione di SSP: la macchina virtuale fa le veci del
microcodice detto sopra che infatti non esiste e non va installato.
Quindi eventualmente ti saprò dire come si installa SSP (è tutto automatico,
basta caricare i supporti e avviare), invece non sono mai riuscito a trovare
documentazione chiara ed esaustiva su come si carichi il microcodice, cosa
che non ho mai avuto bisogno di fare perché in emulazione appunto non c'è.
Dato che ci sono e non ho niente da fare, aggiungo un po' di informazioni.
Secondo gli standard attuali SSP è abbastanza rudimentale e poco lineare.
Presenta un'interfaccia utente facilitata a menù numerati che attivano le
varie funzioni, richiamabili più velocemente anche da linea comandi. I veri
comandi sono abbastanza pochi e riguardano soprattutto funzioni hardware di
sistema come disconnettere una sessione bloccata o avviare una stampante,
invece la maggior parte delle altre operazioni sono svolte da procedure in
linguaggio OCL (Operator Control Language) che verificano i vari parametri
specificati dall'utente e poi li passano ad appositi programmi di utilità
che fanno parte di SSP, programmi che in alcuni casi è anche previsto che
possano essere richiamati direttamente dagli utenti esperti a mo' di API.
Per esempio, per creare un file si utilizza la procedura BLDFILE (Build
File) che richiama il programma $MAINT utilizzabile direttamente anche dagli
utenti e quindi in buona parte documentato nei manuali.
Tutto lo spazio disponibile sui vari dischi viene aggregato in un unico pool
(quindi se si guasta un disco si perde tutto) e viene gestito in modo non
gerarchico, quindi non esiste un vero e proprio concetto di subdirectory.
All'interno di questo spazio è possibile creare dei file formati da record a
larghezza fissa eventualmente indicizzati (BLDFILE), indici aggiuntivi per i
medesimi (BLDINDEX) e speciali file partizionabili detti librerie (BLDLIBR).
Le librerie sono suddivise in entità dette membri di libreria che possono
essere di quattro tipi: sorgenti (S), oggetti compilati (O), procedure OCL
(P) e subroutine binarie linkabili (R). SSP è tutto contenuto in una grossa
libreria di nome #LIBRARY contenente diverse centinaia di membri O e P.
Eventuali prodotti aggiuntivi sono contenuti in altre librerie, per esempio
il compilatore RPG è contenuto in #RPGLIB, oppure #COBLIB per il Cobol.
In altre parole, i file veri e propri possono contenere solo dati, mentre i
sorgenti letti dai compilatori e i programmi risultanti dalla compilazione
vengono conservati dentro i membri di una libreria, che non è altro che uno
speciale tipo di file (idea abbastanza comune fra i sistemi IBM dell'epoca).
Il microcodice invece è in una zona del disco invisibile, inaccessibile ed
esterna allo spazio disponibile per SSP e i dati degli utenti.
Quando si digita qualcosa sulla linea di comando, prima viene verificato che
non si tratti di un comando vero e proprio, poi viene cercata nella libreria
corrente una procedura (membro tipo P) con nome corrispondente a quanto si è
digitato. Se non viene trovata si riceve un errore. Da qui si capisce che
per avviare un programma occorre sempre la relativa procedura OCL che lo
carichi e lo esegua, a meno che non si voglia digitare a mano ogni volta la
corretta sequenza di specifiche OCL (// LOAD, // FILE, // RUN). La libreria
corrente può essere una sola e per comodità è quasi sempre la #LIBRARY che
quindi col tempo tende a riempirsi di "sporcizia". Volendo, le procedure si
possono sottomettere per l'esecuzione batch senza che l'utente sia costretto
a rimanere collegato in attesa della fine dell'elaborazione.
File e librerie non sono ad estensione automatica, quindi quando sono pieni
occorre fare varie manovre. Per i file si deve creare una nuova copia più
grande e poi travasare i dati, per le librerie invece bisogna compattare
tutti i membri con la procedura CONDENSE e poi se c'è spazio contiguo sul
disco si può estendere. Una cosa poco pratica. I nomi di file, librerie e
membri sono al massimo di otto caratteri senza estensioni, ma è possibile
sacrificare un carattere del nome per metterci un punto per poi filtrare in
base alla parte di nome prima del punto: X.AAA, X.BBB, X.CCC, ...
La configurazione è abbastanza rigida: si fa per mezzo di apposita procedura
interattiva CNFIGSSP che crea un cosiddetto membro di configurazione (tipo
O), di solito salvato nella libreria #CNFGLIB, poi copiato in una specifica
locazione del disco, nella zona del microcodice. Quindi si deve riavviare.
Tutto questo anche per operazioni banali come aggiungere un terminale o una
stampante. Nelle ultimissime versioni c'era il riconoscimento automatico dei
device Twinax, ma aveva comunque alcune limitazioni che potevano essere
evitate solo configurando i device a mano in modo permanente con CNFIGSSP.
Il controllo degli accessi mediante password (tipo PIN di quattro caratteri
al massimo) e la protezione dei dati sono facoltative e non attivate di
default. Non mi ricordo più come si chiamava la procedura per attivare il
tutto, forse SECDEF, però mi ricordo che quella di gestione era SECEDIT.
Non c'è molto altro da dire, si tratta di un sistema abbastanza semplice e
anche parecchio noioso per chi non è addetto ai lavori. Io qualche manualone
ce l'ho, se serve qualcosa posso spulciare e riferire su singole questioni.
HTH,
G.
