Newsgroup: it.comp.retrocomputing
Titolo: WAN DECnet italiana

Chi frequenta #retrocomputing (
irc.azzurra.org
) ne ha già certamente
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

 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

merda!!
Io pensavo aveste chiuso tutto!
Ho ancora tutte le macchine del mio nodo.
Quando torno dalle ferie riattivo.. promesso:)
Bau
BBK

Sono alieno, per ora, al mondo DEC/VMS ma
il tuo post mi ha messo addosso un certo 
prurito sperimentatorio che conosco bene ...
Colmerò la lacuna.
Grazie e ciao
                     Antonio

ger...@no.spam.mail.com
 ha scritto:

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)



 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.

 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

 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

 Quasi quasi mi porto simh..
Dai che è meglio Sardegna in moto d'estate e VMS a casa d'inverno che il
contrario! :)
ciao!
gl

 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...

 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.

 ricordo una beneamata MAZZA! :P
E dire che l'11/780 non è una macchina che passa inosservata :-P
G.

 it-alt.comp.folklore dunque fare attenzione a dove si risponde...
Ok, allora continuo qui. :)
Ciao!
gl

 
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.

 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.

 [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.

 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

 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.

 Devo metabolizzare, poi ti dirò se è più chiaro! :)
[...]
Tranquillo, anche io lo devo ancora digerire... BURP! :)
Ciao.
	Fabio.