WAN DECnet italiana
ger...@no.spam.mail.com
sentito parlare, per gli altri è giunta l'ora di scrivere questo post.
La nostra storia inizia da lontano, da quando cioè alcuni di noi sono
entrati in possesso di macchine DEC in grado di eseguire una qualunque
versione di OpenVMS. Grazie al programma ufficiale DEC (poi Compaq ed
ora HP) OpenVMS Hobbyist è possibile utilizzare liberamente il sistema
operativo e una grande quantità di software aggiuntivo a costo zero e
in modo perfettamente legale, per scopi NON commerciali, semplicemente
facendo richiesta delle apposite chiavi di licenza, consegnate in modo
automatico via mail.
VMS è un fuoco che brucia lento e cova sotto la cenere, una volta
acceso è molto difficile spegnerlo e il desiderio di provare tutte le
funzionalità offerte dal sistema cresce inesorabilmente. Una delle
feature più famose (oltre naturalmente al leggendario VAXcluster) è la
rete di comunicazione DECnet, perfettamente e completamente integrata
nel resto del sistema operativo in maniera veramente mirabile. Chi non
l'ha vista in funzione non può capire esattamente cosa significhi.
DECnet ha una storia lunga e gloriosa: un tempo, nei giorni della sua
massima gloria, era sinonimo di Internet. In un'epoca in cui le reti
erano appannaggio di grandi corporation o di enti di studio e ricerca,
esisteva una grande rete denominata HEPnet/SPAN [1] che collegava
virtualmente fra loro, e con tutti i maggiori centri di supercalcolo e
di ricerca, le facoltà scientifiche di tutte le università del mondo.
E' possibile rintracciare tuttora della documentazione ufficiale in
cui si parla semplicemente di "Internet" o "Inter-network" intendendo
questa grande rete DECnet e non l'attuale rete TCP/IP. Chi volesse
passare un po' di tempo a fare ricerche sui NG con Google, scoprirebbe
che ci sono tantissimi post risalenti alla seconda metà degli anni '80
in fondo ai quali, nelle signature, compare non solo l'indirizzo per
la posta elettronica come la intendiamo comunemente oggi, ma anche
quello per la posta DECnet, nella forma NODO::UTENTE (e magari anche
l'indirizzo per la posta BITNET o UUCP).
Fatta questa doverosa premessa, è facile capire come possa essere nato
il desiderio di esplorare le possibilità di stabilire un collegamento
DECnet fra le nostre macchine. Il problema non appariva di facile
soluzione: in una rete DECnet la comunicazione fra i nodi avviene
principalmente via Ethernet (esistono anche altre soluzioni, tutte
molto più scomode, almeno dal nostro punto di vista). Questo significa
che è molto semplice attivare un collegamento DECnet fra due macchine
fisicamente vicine tra loro, ad esempio nella stessa casa, ma diventa
piuttosto complesso ottenere la stessa cosa se i nodi sono distanti
fra loro, magari in città diverse.
Avevamo il necessario, ma non sapevamo come combinare il tutto: era
ovvio che avremmo utilizzato Internet (quella TCP/IP) per veicolare i
frame DECnet, ma come? Una VPN avrebbe comportato una gran quantità di
problemi, altre soluzioni a base di ebtables e tun/tap apparivano
impraticabili e infine erano state scartate anche certe strane
soluzioni con hardware autocostruito di cui avevamo letto qualcosa.
Per un po' di tempo il problema fu accantonato per mancanza di ovvie
soluzioni, però il pungolo a risolvere la questione era sempre
presente, tanto più che nel frattempo avevamo scoperto l'esistenza di
HECnet [2], una rete DECnet amatoriale svedese simile a quella che
avremmo voluto creare noi, basata però su link seriali a bassa
velocità (9600 bps), più dimostrativa che utile.
Nel frattempo i link diretti privati passavano di moda anche per le
grandi strutture: sempre più spesso si abbandonavano le costose linee
dedicate in favore di collegamenti di vario genere instradati via
Internet e dunque il problema di veicolare DECnet su TCP/IP si era
presentato anche ad altri, anche alle aziende. Fu su queste basi che
un paio di società di software svilupparono una soluzione funzionante
che comprendeva uno stack TCP/IP alternativo a quello Digital e un
meccanismo per inoltrare le comunicazioni DECnet su un circuito
virtuale, qualcosa di vagamente simile a una scheda Ethernet emulata.
Tempo dopo queste due società si fusero e divennero l'attuale Process
Software. La nuova società scelse di aderire al programma Hobbyist e
rese disponibile a costo zero per scopi amatoriali la sua soluzione
basata sul suo stack alternativo e sui circuiti virtuali. Fu grazie a
questo software che facemmo i primi timidi tentativi di collegamento
DECnet attraverso Internet. A dire il vero il funzionamento di questo
sistema lasciava molto a desiderare: era molto scomodo gestire più di
un collegamento per volta, la documentazione non era assolutamente
chiara e l'errore PATHLOST era frequentissimo. Inoltre, problema per
noi in assoluto più grave, era impossibile gestire in maniera almeno
parzialmente automatica il cambio di indirizzo IP delle nostre
connessioni dinamiche a Internet, cosicché ad ogni cambio di indirizzo
era necessario rifare la configurazione dei tunnel. Un incubo. Ancora
una volta il progetto di una DECnet amatoriale italiana finì purtroppo
in fondo a un cassetto. Una grande delusione.
Passa il tempo (un paio d'anni), i partecipanti di #retrocomputing
interessati a VMS crescono, le macchine aumentano, viene anche formato
un cluster, manca solo la DECnet. Un giorno di novembre del 2006 ci
rimettiamo all'opera, a caccia di informazioni per trovare una
soluzione definitiva al nostro problema. Riverifichiamo tutte le
informazioni in nostro possesso in cerca di nuove idee, sperimentiamo
anche il supporto IP di DECnet/OSI (dovrebbe essere l'evoluzione della
DECnet classica, in pratica: un ORRORE durato un pomeriggio) e infine
torniamo quasi per caso sul sito di HECnet, la rete svedese, e notiamo
che nel frattempo è cresciuta, ha abbandonato i link seriali a bassa
velocità e ora si appoggia a un piccolo programma in C per Linux.
La soluzione è talmente semplice che non sembra possibile. Scarichiamo
e compiliamo il programma, all'inizio non funziona nulla, non c'è
documentazione, niente di niente, vorremmo abbandonare, ma sentiamo
che quella è la Soluzione. Proviamo per ore, apriamo porte sui
firewall, controlliamo il traffico con tcpdump, cambiamo mille volte
la configurazione (non documentata) del programma, tentiamo tutte le
opzioni possibili di NCP (Network Control Program) su VMS e alla fine
la nostra costanza è premiata: due macchine, un Alpha e un VAX in due
città diverse comunicano via DECnet attraverso Internet.
Ce l'abbiamo fatta!
I primi giorni sono pieni di euforia, ma anche di scoramento, i
problemi sono tanti e a volte sembrano insormontabili: il programma è
molto rigido e più di una volta si formano dei loop di rete con i
frame DECnet che rimbalzano da una macchina all'altra come impazziti,
fino a saturare la banda disponibile. Ma la soluzione è quella,
l'abbiamo tra le mani, non può sfuggirci. Una mattina alle 7 (!) ci
troviamo tutti in #retrocomputing, senza esserci dati appuntamento, e
inziamo una sessione di debug condiviso: analizziamo il codice del
programma riga per riga fino a capire come funziona. Lo modifichiamo
più volte secondo i nostri bisogni e in una settimana arriviamo a
quattro release diverse. Alla fine vinciamo noi: la DECnet esiste.
Funziona perfettamente e non perde un colpo.
Tecnicamente il programma si appoggia a una macchina Unix che sia
sullo stesso segmento Ethernet delle macchine che devono comunicare
via DECnet, cattura i frame basandosi sul MAC address e sull'Ethertype
e li invia incapsulati in pacchetti UDP a un'altra macchina Unix, a
destinazione, dove un'altra copia del programma fa il procedimento
inverso e immette sulla Ethernet i frame che riceve via UDP. Questa
soluzione ha moltissimi vantaggi sulle altre, soprattutto perché
permette di non modificare assolutamente il nodo DECnet ed è
indipendente da software particolari, dunque può essere utilizzata per
collegare alla rete macchine di qualunque genere (vari tipi di PDP-11
o DECsystem-10 veri o emulati, tanto per fare due esempi) e con
qualunque sistema operativo per il quale esista il supporto DECnet
(penso ad esempio a Ultrix o anche a Linux).
A circa sei mesi di distanza da quei giorni fatidici la nostra DECnet
conta 31 nodi ufficialmente registrati, uniformemente distribuiti tra
VAX e Alpha, con varie versioni di OpenVMS. Su ogni nodo sono attivi
tutti i servizi di rete (posta, trasferimento file, accesso
interattivo ai nodi remoti, etc.) e funzionano senza alcun problema.
Alcuni nodi sono costantemente online e fanno da repository di
software e patch per gli altri. Ognuno gestisce in autonomia i propri
nodi e c'è un minimo di coordinamento solo per quanto riguarda
l'assegnazione degli indirizzi, per il resto c'è la più ampia libertà.
Per altre informazioni, tecniche e non, stiamo allestendo un sito
all'indirizzo http://decnet.ipv7.net
Che dire ancora? Chi è interessato può anche venire a trovarci su
#retrocomputing, qualcuno c'è sempre.
Ciao!
G. (ALPHA::RPT alias 1055::RPT)
[1] High Energy Physics network / Space Physics Analysis Network
[2] http://www.update.uu.se/~bqt/hecnet.html
g...@decadence.it
> Chi frequenta #retrocomputing (irc.azzurra.org) ne ha già certamente
> sentito parlare, per gli altri è giunta l'ora di scrivere questo post.
Ciao :)
Complimenti per il notevole lavoro compiuto!
Ne avevo sentito parlare ma non ho mai avuto tempo di provarlo.
Dopo tutto la mia scarsa affinità con VMS è celebre e l'unica macchina
(VS4000/96) su cui ho fatto un setup e configurazione decente ha visto il
suo monitor DEC VRT rompersi due giorni dopo...
Nel lungo e freddo inverno cercherò di unirmi alla DECnet!
ciao!
gl
bbk
Io pensavo aveste chiuso tutto!
Ho ancora tutte le macchine del mio nodo.
Quando torno dalle ferie riattivo.. promesso:)
Bau
BBK
Antonio d'Avino
il tuo post mi ha messo addosso un certo
prurito sperimentatorio che conosco bene ...
Colmerò la lacuna.
Grazie e ciao
Antonio
Marco Wile Paolini
Richiedesi "corso di formazione su VMS". ^__^
Un AlphaServer 800 attende il suo VMS installato!! ;-)
--
Signature automatica inserita a mano.
Punteggiatura: Nel caso mancasse nel messaggio, aggiungete!!
In God we trust, all others we monitor.(NSA)
Marco Wile Paolini
Fabio Bizzi
[...]
> Dopo tutto la mia scarsa affinità con VMS è celebre e l'unica macchina
> (VS4000/96) su cui ho fatto un setup e configurazione decente ha visto il
> suo monitor DEC VRT rompersi due giorni dopo...
MA IO DICO!!!! La persona che in rete HA PIU' VAX DI TUTTI (a parte il
rubinelli forse), IL SITO PIU' DEC DI TUTTI che mi va' a casacare su
quello che e' il simbolo del VAX, il VMS!!!!!
Urge immediato full-immersion su VMS!!!!
E già che ci stiamo lo facciamo tutti e due dato che anche io non mi
ricordo una beneamata MAZZA! :P
Che se non era per Gerry col quasi che lo rimettevo su' l'alpha server
1000 con la 8.3 :)
Ciao.
Fabio.
g...@decadence.it
> MA IO DICO!!!! La persona che in rete HA PIU' VAX DI TUTTI (a parte il
> rubinelli forse), IL SITO PIU' DEC DI TUTTI che mi va' a casacare su
> quello che e' il simbolo del VAX, il VMS!!!!!
Tu mi sopravvaluti... :)
> Urge immediato full-immersion su VMS!!!!
>
> E già che ci stiamo lo facciamo tutti e due dato che anche io non mi
> ricordo una beneamata MAZZA! :P
>
> Che se non era per Gerry col quasi che lo rimettevo su' l'alpha server
> 1000 con la 8.3 :)
Con VMS ci ho provato molte volte, su VAX a Alpha il problema erano i
lettori CDROM che vanno e non vanno, fino a trovare quello giusto che è
supportato pienamente.
A quel punto sulla VS4000 ci ho lavorato per giorni, installazione e
aggiornamenti, configurazioni varie, poi il monitor salta, ma la macchina
è ancora funzionante e aspetta solo che abbia il tempo di riparare o
sostituire il monitor (la seconda, credo).
Ho VMS 7.3 anche su un AS2100 con due CPU, una delle quali da problemi e
anche lì toccherà metterci mano anche se con la sola CPU primaria è in
grado di lavorare.
VMS mi è decisamente alieno, ormai ho troppa affinità con lo GNU e il
processo credo sia irreversibile.
Alla peggio, ripiegherò sull'ambiente GNV (GNU Not VMS) per VMS.
A periodi (tipicamente d'inverno) VMS torna ad interessarmi, vedremo
quest'anno, ma allo stato attuale sto impiegando le mie energie in alcune
inconcludenti sperimentazioni che però mi divertono abbastanza.
Quei pochi 15 giorni vacanze estive le trascorrerò interamente a Shaolin,
Cina, quindi non avrò modo di lavorare sul VMS...
Però ho un progettino da realizzare per VMS, riuscire a compilare Links2
per VMS/VAX, in modo da avere un browserino leggero e abbastanza recente
per le VS4000.
Links2 si appoggia solo sulle librerie X, JPEG, TIFF, PNG tutto materiale
disponibile su VMS e si dovrebbe riuscire anche solo con un po' di pazienza
come solito.
Vedremo che porterà l'inverno, tu intanto prosegui pure col VMS poi mi
dirai se ti trovi meglio di me! :)
ciao!
gl
bbk
> Vedremo che porterà l'inverno, tu intanto prosegui pure col VMS poi mi
> dirai se ti trovi meglio di me! :)
Pero' siete bastardi...
Ora mi e' venuta la scimmia e tra 4 giorni parto per la sardegna in moto!
Quasi quasi mi porto simh..
Bau
BBK
g...@decadence.it
> Pero' siete bastardi...
>
> Ora mi e' venuta la scimmia e tra 4 giorni parto per la sardegna in moto!
>
> Quasi quasi mi porto simh..
Dai che è meglio Sardegna in moto d'estate e VMS a casa d'inverno che il
contrario! :)
ciao!
gl
ger...@no.spam.mail.com
wrote:
> A quel punto sulla VS4000 ci ho lavorato per giorni, installazione e
> aggiornamenti, configurazioni varie, poi il monitor salta, ma la macchina
> è ancora funzionante e aspetta solo che abbia il tempo di riparare o
> sostituire il monitor (la seconda, credo).
... E perché invece non utilizzare una console seriale (che in fin dei
conti non serve quasi mai: sono pochissimi i casi in cui non si può
operare in altro modo) e per il resto accedere via telnet? Non mi dire
che così perdi la parte grafica, eh? :->
> VMS mi è decisamente alieno, ormai ho troppa affinità con lo GNU e il
> processo credo sia irreversibile.
Sì, è peggio della peste, quando arriva non si può fare nulla se non
abbandonare la propria roba e bruciare tutto...
> Alla peggio, ripiegherò sull'ambiente GNV (GNU Not VMS) per VMS.
Cito quanto è passato (tra le altre cose) su comp.os.vms a proposito
di GNV: "Why anyone would want to even THINK of wading in the sewer of
GNV unixisms and its brain damage when you have an OS that works is
beyond explanation." :-) Faccio notare che "wading in the sewer"
significa più o meno rimestare nella fogna :-P
Ne aggiungo un'altra, tanto per chiarire il concetto: "This doesn't
prove that VMS has poorly chosen command names...it just shows that
Unix causes brain damage."
In effetti, parlando seriamente, GNV soprattutto nelle sue ultime
incarnazioni mi risulta che "rompa" la filosifia di VMS in più punti,
e se fosse solo un problema filosofico si potrebbe anche chiudere un
occhio, il guaio è che crea anche problemi tecnici. Ad esempio viola
la separazione dei file system tipica di VMS creando dei collegamenti
tra uno e l'altro (un po' come fa Unix appunto, in cui tutti i file
system di una macchina sono montati sotto un'unica root), oppure più
di una volta ho letto di loop fra le directory che mandano in crisi i
tool che in buona fede non pensano che possa esserci un pasticcio del
genere...
Ciao,
G.
P.S.: occhio al multipost (diverso da crosspost): il mio messaggio
originale, per una mia distrazione è in multipost tra qui e il NG
it-alt.comp.folklore dunque fare attenzione a dove si risponde...
ger...@no.spam.mail.com
<paolin...@libero.it> wrote:
> Richiedesi "corso di formazione su VMS". ^__^
> Un AlphaServer 800 attende il suo VMS installato!! ;-)
Tu fatti vedere su #retrocomputing ogni tanto e vedremo di darti una
mano :-P Quanti secoli sono passati dalla tua ultima apparizione?
G.
ger...@no.spam.mail.com
wrote:
> MA IO DICO!!!! La persona che in rete HA PIU' VAX DI TUTTI (a parte il
> rubinelli forse), IL SITO PIU' DEC DI TUTTI che mi va' a casacare su
> quello che e' il simbolo del VAX, il VMS!!!!!
Secondo me è una grave forma di schizofrenia computeristica...
> E già che ci stiamo lo facciamo tutti e due dato che anche io non mi
> ricordo una beneamata MAZZA! :P
E dire che l'11/780 non è una macchina che passa inosservata :-P
G.
g...@decadence.it
>> A quel punto sulla VS4000 ci ho lavorato per giorni, installazione e
>> aggiornamenti, configurazioni varie, poi il monitor salta, ma la macchina
>> è ancora funzionante e aspetta solo che abbia il tempo di riparare o
>> sostituire il monitor (la seconda, credo).
>
> ... E perché invece non utilizzare una console seriale (che in fin dei
> conti non serve quasi mai: sono pochissimi i casi in cui non si può
> operare in altro modo) e per il resto accedere via telnet? Non mi dire
> che così perdi la parte grafica, eh? :->
Eh sì, DECwindows Motif!
Gli avevo messo anche lo sfondo, potendo lavorare solo con immagini
monocromatiche avevo optato per un particolare di Sin City fumetto.
Un desktop da favola.
Comunque VAXstation... ci *devo* collegare un monitor.
In verità sto pensando di buttar via i CRT SoG e comprare un paio di LCD
con supporto SoG. In giro ho letto che con 3W3<--->BNC<--->BNC<--->VGA
funziona.
>> VMS mi è decisamente alieno, ormai ho troppa affinità con lo GNU e il
>> processo credo sia irreversibile.
>
> Sì, è peggio della peste, quando arriva non si può fare nulla se non
> abbandonare la propria roba e bruciare tutto...
>
>> Alla peggio, ripiegherò sull'ambiente GNV (GNU Not VMS) per VMS.
>
> Cito quanto è passato (tra le altre cose) su comp.os.vms a proposito
> di GNV: "Why anyone would want to even THINK of wading in the sewer of
> GNV unixisms and its brain damage when you have an OS that works is
> beyond explanation." :-) Faccio notare che "wading in the sewer"
> significa più o meno rimestare nella fogna :-P
>
> Ne aggiungo un'altra, tanto per chiarire il concetto: "This doesn't
> prove that VMS has poorly chosen command names...it just shows that
> Unix causes brain damage."
No, era uno scherzo. :)
Se voglio un ambiente GNU, è inutile fare accrocchi per averlo su VMS.
Comunque ti ringrazio, mi hai risparmiato qualche ora di craniate sul
monitor per cercare di installarlo! :)
Poi a che mi serviva... forse per far funzionare OpenOffice su Alpha?
Boh, qualche software lo richiedeva.
> In effetti, parlando seriamente, GNV soprattutto nelle sue ultime
> incarnazioni mi risulta che "rompa" la filosifia di VMS in più punti,
> e se fosse solo un problema filosofico si potrebbe anche chiudere un
> occhio, il guaio è che crea anche problemi tecnici. Ad esempio viola
> la separazione dei file system tipica di VMS creando dei collegamenti
> tra uno e l'altro (un po' come fa Unix appunto, in cui tutti i file
> system di una macchina sono montati sotto un'unica root), oppure più
> di una volta ho letto di loop fra le directory che mandano in crisi i
> tool che in buona fede non pensano che possa esserci un pasticcio del
> genere...
Eh, ma il filesystem *nix è quanto di più razionale esista.
Loop di symlinks si possono creare, ma devi andarne proprio in cerca o
farli appositamente.
La mia difficoltà maggiore con VMS è proprio il filesytem con cui non mi
trovo affatto. Poi i comandi si imparano, ma se il filesystem è
strutturato in un modo, non ci posso fare niente.
In verità allo stato attuale mi manca qualunque interesse per VMS, infatti
cercavo lo stimolo iniziando a fare esperimenti su DECwindows Motif sulla
VS4000/96 per far funzionare Links2.
Però si è rotto il monitor proprio appena avevo finito l'installazione del
compilatore e stavo scaricando le librerie...
> P.S.: occhio al multipost (diverso da crosspost): il mio messaggio
> originale, per una mia distrazione è in multipost tra qui e il NG
> it-alt.comp.folklore dunque fare attenzione a dove si risponde...
Ok, allora continuo qui. :)
Ciao!
gl
Fabio Bizzi
>
>> E già che ci stiamo lo facciamo tutti e due dato che anche io non mi
>> ricordo una beneamata MAZZA! :P
>
> E dire che l'11/780 non è una macchina che passa inosservata :-P
>
Eh si' è vero.... Ma io ero giovane ed inesperto..... :)
Qualcosa di indelebile è rimasto nei miei ricordi, tipo i megadump che
faceva sulla tty vms 4.x quando il 32 utente lancava la megacompilazione
e il misero mega di ram sovrassaturo non ce la faceva più a paginare,
oppure quando il lunedì mattina c'era il rito dell'accensione, mettere
la chiavetta su RUN, accendere i dischi, accendere la tty, aspettare il
"." sulla tty, dare "boot cpu", aspettare ">>>" sulla tty e dare il
fatidico boot, poi dopo 15 minuti verificare se il boot era finito... :D
Ehhhhh queste sono cose che non si dimenticano, ti marchiano per tutta
la vita!!!
C'e' qualcuno che si da' via un 11/780 da queste parti? :P:P:P
Ciao.
Fabio.
ger...@no.spam.mail.com
wrote:
> Poi a che mi serviva... forse per far funzionare OpenOffice su Alpha?
> Boh, qualche software lo richiedeva.
Io credo, CREDO, che installando GNV tu dopo possa avere - tra le
altre cose - ls, cp, rm e così via...
> Eh, ma il filesystem *nix è quanto di più razionale esista.
Razionale e terribilmente semplice, anche troppo per certi versi :P
Fin dalla sua nascita, inizio anni '80, ha sempre avuto un ricchissimo
set di caratteristiche che oggi chiameremmo avanzate e che molti file
system Unix hanno guadagnato solo in periodi relativamente recenti:
versioning, che all'atto pratico diventa molto utile in tanti casi in
cui si debba recuperare qualche modifica; capacità di distinguere tra
file sequenziali, ad accesso relativo ed indicizzati; conservazione
delle date di creazione, ultima modifica (con contatore delle
modifiche), backup, scadenza, registrazione, etc.; gestione dello
stato on-line, near-line e off-line dei dati di un file (HSM);
preallocazione dello spazio con varie politiche (contiguous, best try,
sparse, etc.); meccanismi di sicurezza tipo high water marking, erase
on allocate e erase on delete; giornalizzazione applicativa dei dati
(before, after, recovery); ACL per audit e allarmi di accesso; caching
modificabile (write behind, write through, flush on close, etc.); vari
tipi di verifica dei dati (doppia lettura e/o lettura dopo scrittura);
possibilità di montare lo stesso file system contemporaneamente da
parte di più macchine all'interno di un cluster; etc. etc. etc. :-)
> Loop di symlinks si possono creare, ma devi andarne proprio in cerca o
> farli appositamente.
Infatti l'idea che si erano fatti in comp.os.vms era che quella famosa
versione di GNV fosse stata preparata da qualche "t33n" con la mania
di Linux dapperttutto e senza alcuna conoscenza di VMS :P
> La mia difficoltà maggiore con VMS è proprio il filesytem con cui non mi
> trovo affatto. Poi i comandi si imparano, ma se il filesystem è
> strutturato in un modo, non ci posso fare niente.
Forse più che con il file system in sé non ti trovi con la struttura
delle directory che in effetti non è subito semplice da capire, ma una
volta capita non è poi più complessa di altre cose.
Il problema direi che nasce nei system disk, cioè quelli bootabili, in
cui possono esserci più root contemporaneamente (nel senso VMS del
termine, non in quello Unix) dato che lo stesso disco può essere
utilizzato per fare il boot da più macchine nello stesso momento.
Vediamo se mettendo insieme un po' di cose scritte in momenti diversi
riesco a spiegarmi abbastanza.
Nella radice del disco, oltre ai file riservati tipo l'indice del
disco stesso, c'è una directory per ogni root il cui nome è SYSn, dove
n è una cifra da 0 a FF con alcune eccezioni (ad esempio SYSE e SYSF
se esistono sono root riservate). In ogni root c'è una serie di
directory dai nomi abbastanza ovvi tipo SYSEXE, SYSLIB, SYSHLP, SYSUPD
(e altre) e c'è una SYSCOMMON.
Nella radice del disco oltre ai file riservati e alle root SYSn c'è
anche una directory VMS$COMMON che contiene lo stesso set di directory
di una qualunque root (tranne la SYSCOMMON). A questa directory punta
la directory SYSCOMMON di ogni root o meglio, con una terminologia
Unix potremmo dire che la directory SYSCOMMON di una qualunque root è
un hard link alla vera directory VMS$COMMON.
Quindi, per fare un esempio, partendo da una qualunque root sarà
possibile accedere a due SYSEXE: una sarà SYSn.SYSEXE e l'altra sarà
SYSn.SYSCOMMON.SYSEXE. Idem vale per tutte le altre directory del set.
Al boot vengono creati una serie di logical names che puntano alle
varie coppie di directory, qualcosa di molto vagamente simile a tanti
path, in VMS parlance si chiamano search list: ci sarà un SYS$SYSTEM
che punta in sequenza a SYSn.SYSEXE e poi a SYSn.SYSCOMMON.SYSEXE
(come detto sopra) e poi tanti altri tipo SYS$LIBRARY per le directory
SYSLIB, SYS$HELP per le SYSHLP, SYS$UPDATE per le SYSUPD e via
dicendo.
In pratica cosa si ottiene da tutto questo? Anche se il disco ha più
root e viene utilizzato per il boot di più macchine, si ha una sola
copia dei file invariabili come gli eseguibili del sistema o i testi
dell'help i quali file risiedono tutti nella VMS$COMMON che viene
raggiunta dalle varie SYSCOMMON, mentre nelle directory specifiche di
ogni root (SYSn.SYSxxx) risiedono solo quei file che variano da una
macchina all'altra tipo ad esempio le impostazioni di configurazione o
quei file che si desidera sostituiscano per qualche motivo quelli
comuni, per esempio una patch per un problema specifico. Viceversa una
patch applicata a un file in VMS$COMMON diventa subito attiva per
tutte le macchine che bootano da quel disco.
Esempio: il comando RUN SYS$SYSTEM:PIPPO.EXE fa sì che PIPPO.EXE venga
cercato prima in SYSn.SYSEXE e poi in SYSn.SYSCOMMON.SYSEXE, appena
viene trovato la ricerca termina, quindi se ci fosse in entrambe le
directory verrebbe eseguito quello di SYSn.SYSEXE che magari potrebbe
essere una patch o un aggiornamento di quello comune a tutti.
Schema:
000000 --+-- SYSn --+-- SYSxxx
| :
| +-- SYSCOMMON ----+
| |
+-- SYSm --+-- SYSxxx |
| : |
| +-- SYSCOMMON --+ |
: | |
+-- VMS$COMMON ------------+-+---- SYSxxx
Forse ora è più chiaro? ... O ancora più confuso di prima? :-)
Ciao,
G.
ger...@no.spam.mail.com
> Fin dalla sua nascita, inizio anni '80, ha sempre avuto un ricchissimo
> set di caratteristiche che oggi chiameremmo avanzate e che molti file
> system Unix hanno guadagnato solo in periodi relativamente recenti:
>
> [snip]
E naturalmente c'è la possibilità di attivare le quote sullo spazio
utilizzato, con tanto di overdraft. Mi è venuto in mente di tutto
tranne la cosa più ovvia, vedremo se manca qualcos'altro che ora mi
sfugge :P
G.
g...@decadence.it
> Io credo, CREDO, che installando GNV tu dopo possa avere - tra le
> altre cose - ls, cp, rm e così via...
Certo quei comandi, ma mi serviva per provare questo:
http://www.oooovms.dyndns.org/
>> Eh, ma il filesystem *nix è quanto di più razionale esista.
>
> Razionale e terribilmente semplice, anche troppo per certi versi :P
>
> Fin dalla sua nascita, inizio anni '80, ha sempre avuto un ricchissimo
> set di caratteristiche che oggi chiameremmo avanzate e che molti file
> system Unix hanno guadagnato solo in periodi relativamente recenti:
>
> versioning, che all'atto pratico diventa molto utile in tanti casi in
> cui si debba recuperare qualche modifica; capacità di distinguere tra
> file sequenziali, ad accesso relativo ed indicizzati; conservazione
> delle date di creazione, ultima modifica (con contatore delle
> modifiche), backup, scadenza, registrazione, etc.; gestione dello
> stato on-line, near-line e off-line dei dati di un file (HSM);
> preallocazione dello spazio con varie politiche (contiguous, best try,
> sparse, etc.); meccanismi di sicurezza tipo high water marking, erase
> on allocate e erase on delete; giornalizzazione applicativa dei dati
> (before, after, recovery); ACL per audit e allarmi di accesso; caching
> modificabile (write behind, write through, flush on close, etc.); vari
> tipi di verifica dei dati (doppia lettura e/o lettura dopo scrittura);
> possibilità di montare lo stesso file system contemporaneamente da
> parte di più macchine all'interno di un cluster; etc. etc. etc. :-)
E' certo che alcune queste features del filesystem di OVMS sono molto
interessanti, prima tra tutte il versioning (che mi pare esista anche nel
FS ISO 9660) o le varie politiche come "erase on delete" di cui scopro
l'esistenza solo ora :) comunque di sicuro tutte le volte che ho
cancellato un file su un FS journaling su Linux non ho mai potuto
recuperare nulla (anche se è certo che una traccia resta).
Altre cose, come la preallocazione di spazi può essere interessante, ma è
certo che queste politiche sono da demandare al filesystem stesso, e sui
FS unix ben distinti in partizioni/slice la frammentazione dei dati è un
problema trascurabile data la sua scarsa rilevanza.
Una feature molto interessante del XFS è la possibilità di creare dei
"realtime subvolumes", uso XFS su tutti i sistemi che amministro, ma non
ho mai avuto necessità di questa funzione.
Le altre funzionalità più o meno sono comuni a tutti i moderni FS unix,
tra cui il journaling, gestioni di date, ecc... così che l'unica mancanza
apparente è quella del versioning.
Una cosa che non si può fare, o almeno non mi risulta, è partizionare un
disco, inutile dirai, ma quando un hobbyista c'ha un solo HD da 18GB sulla
PWS e vuole tenere due sistemi operativi allora si attacca... :)
Al contrario su Linux è possibile mischiare due FS diversi (filesystem
translucency) in cui ad esempio più /usr si mischiano e se ne visualizza
una sola (virtuale).
Che serve? Ad esempio per avere un filesystem readonly (magari in
ROM/Flash) da mischiare con un fileystem R/W di file per i quali si fa
aggiornamento, oppure per avere modifiche volatili ai file esistenti (una
append che sparisce al reboot ad esempio).
Questa discussione si sta trasformando in un dibattito su cosa ha in più
quel sistema e cosa in più quell'altro e non era la mia intenzione.
Volevo solo indicare che su Unix esistono molte se non tutte le
funzionalità FS di VMS, con la visione unix-ista del FS, in particolare
della / unica.
Nel tempo ho scoperto che questa visione è quella che più gradisco per cui
ho difficoltà con la visione VMS.
Forse devo partire dalle radici: ho avuto un RSX-11 per alcuni giorni su
PDP-11, mi ci trovavo bene, ora forse potrei evolvere al VMS :)
>> Loop di symlinks si possono creare, ma devi andarne proprio in cerca o
>> farli appositamente.
>
> Infatti l'idea che si erano fatti in comp.os.vms era che quella famosa
> versione di GNV fosse stata preparata da qualche "t33n" con la mania di
> Linux dapperttutto e senza alcuna conoscenza di VMS :P
Come ti dicevo, deve servire a qualcos'altro, tipo OO.org, Perl e Python,
ma non mi sono addentratro troppo.
>> La mia difficoltà maggiore con VMS è proprio il filesytem con cui non
>> mi trovo affatto. Poi i comandi si imparano, ma se il filesystem è
>> strutturato in un modo, non ci posso fare niente.
>
> Forse più che con il file system in sé non ti trovi con la struttura
> delle directory che in effetti non è subito semplice da capire, ma una
> volta capita non è poi più complessa di altre cose.
Purtroppo... (ma che dico!) da molto tempo mi sono comodamente abituato al
FS unix-like, e alla sua visione taoista del sistema, una sola struttura,
una sola radice, tutto è file.
Diciamo che hai fatto un'ottima sintesi, per di più in lingua italiana :)
di quanto è espresso in molti capitoli e in lingua inglese sui siti
HP/OpenVMS vari che ho letto e riletto ed è come imparare il cinese con
una grammatica, meglio gli esempi pratici!
Devo metabolizzare, poi ti dirò se è più chiaro! :)
Comunque grazie, salvo in testo questa email che mi servirà di sicuro.
Non ho detto che non ho sistemi VMS in casa, ma che ci faccio un po'
attrito sopra, magari con questa breve guida riesco a scivolare via un po'
meglio! :)
ciao
gl
ger...@no.spam.mail.com
wrote:
> Questa discussione si sta trasformando in un dibattito su cosa ha in più
> quel sistema e cosa in più quell'altro e non era la mia intenzione.
> Volevo solo indicare che su Unix esistono molte se non tutte le
> funzionalità FS di VMS, con la visione unix-ista del FS, in particolare
Veramente non volevo neppure io, anche perché sono io il primo che usa
e apprezza Unix (Linux) per varie cose delle quali non potrei quasi
fare a meno e che non sono rimpiazzabili, però ciò non toglie che
molte delle caratteristiche che ho elencato in precedenza NON siano
ancora implementate nei file system Unix, almeno non in quelli più
comunemente noti e accessibili liberamente.
Non dico le quote o le ACL che ormai sono arrivate (a colpi di patch),
ma altre feature tipo ad esempio la possibilità di montare in sharing
tra più macchine che fanno accesso concorrente in lettura e scrittura,
senza dover ricorrere ad esempio a nfs, oppure le funzioni simili a un
database tipo i file indicizzati e il journaling (N.B.: non quello del
file system, ma quello dei dati, con le classiche funzioni commit e
rollback tipiche da DB) che sono tanto comodi quando un'applicazione
deve salvare qualcosa che non sia puro testo, senza dover scomodare un
DB vero e proprio. Idem vale per le date di backup.
Mi dicono che anche la possibilità di gestire senza aggiunte lo stato
online, nearline e offline di un file sia molto carina, ma non avendo
mai avuto a che fare con sistemi HSM (Hierarchical Storage Management)
non mi pronuncio e mi fido sulla parola :-)
> Nel tempo ho scoperto che questa visione è quella che più gradisco per cui
> ho difficoltà con la visione VMS.
> Forse devo partire dalle radici: ho avuto un RSX-11 per alcuni giorni su
> PDP-11, mi ci trovavo bene, ora forse potrei evolvere al VMS :)
Bè VMS affonda le sue radici in RSX-11, quindi... VMS 3.x fu il primo
ad essere formato tutto da codice nativo a 32 bit scritto apposta per
lui: le versioni precedenti avevano parti del sistema operativo
formate da pezzi di RSX-11 che giravano in compatibility mode!
> Comunque grazie, salvo in testo questa email che mi servirà di sicuro.
> Non ho detto che non ho sistemi VMS in casa, ma che ci faccio un po'
> attrito sopra, magari con questa breve guida riesco a scivolare via un po'
> meglio! :)
L'importante è non ostinarsi a usare le directory fisiche quando ci
sono i logical perché non è pensato che si faccia così e dopo un po'
non si capisce più niente visto che molti logical puntano a più
directory contemporaneamente.
Ciao,
G.
Fabio Bizzi
[...]
> Una feature molto interessante del XFS è la possibilità di creare dei
> "realtime subvolumes", uso XFS su tutti i sistemi che amministro, ma non
> ho mai avuto necessità di questa funzione.
Il realtime FS di xfs è un qualcosa di veramente strano, in pratica
utilizza più dischi contemporaneamente, ma al contrario dei vari
mirroring e striping il dato viene scritto contemporaneamente su più
settori dei vari volumi, poi se viene acceduto da più applicativi
contemporaneamente o se un unico applicativo lo accede diverse volte ma
su blocchi differenti (ad esempio un film che viene mandato in streaming
a diversi client che inizano a vederlo in momenti differenti) viene
erogato il blocco "meno acceduto" in modo da poter bilanciare il carico
sui vari dischi fisici e diminuire drasticamente latenza e tempi di accesso.
Unica cosa brutta, se fai un RTFS con ad esempio 5 dischi ti ritrovi la
capacità di uno solo... :D
[...]
> Purtroppo... (ma che dico!) da molto tempo mi sono comodamente abituato al
> FS unix-like, e alla sua visione taoista del sistema, una sola struttura,
> una sola radice, tutto è file.
[...]
In questi giorni che sto giocando un pò di più col vms ma sempre in
contemporanea con *nix mi stanno accadendo delle cose diaboliche,
mischio i comandi dei due sistemi con risultati alienanti tipo:
del -Rf *.*;*
:D
Comunque è solo il tempo di prenderci la mano e di rendersi conto su
quale terminale stai... :P
[...]
> Devo metabolizzare, poi ti dirò se è più chiaro! :)
[...]
Tranquillo, anche io lo devo ancora digerire... BURP! :)
Ciao.
Fabio.