Newsgroup: it.comp.retrocomputing
Titolo: Configurazione DECnet

Ho un piccolo problema ...
Ho "clonato" simh su alcune macchine (per non ripetere l'installazione di 
OpenVMS) ed ho avuto la necessità di variare l'indirizzo IP, SCSNODE e 
SCSSYSTEMID.
Con tcpip$config ho cambiato l'indirizzo IP.
Ho "spento" la rete DECnet con
mc ncp set exec state off 
ed ho provato a configurare con NETCONFIG, cambiando il nome del nodo e 
l'ID.
Al riavvio, mi ritrovavo lo stesso nome del nodo ed ID iniziali, cioé non 
riuscivo a cambiare nulla.
Cerca, cerca,
http://labs.hoffmanlabs.com/node/589
mi sono accorto che la "clonazione" non è una buona idea.
Il node name è utilizzato un po' dappertutto, e cambiarlo è alquanto 
complicato. Conviene reinstallare OpenVMS ...

 complicato. Conviene reinstallare OpenVMS ...
Mah, lì la fa particolarmente difficile secondo me. È vero che quando c'è di
mezzo un cluster — tanto per fare un esempio — la cosa si complica, ma se il
nodo è stand-alone, non è poi così difficile cambiargli nome o indirizzo.
Alcune delle cose che dice lì noi non le abbiamo mai cambiate (ci siamo pure
dimenticati a dire il vero) e non abbiamo mai avuto problemi. In alternativa
potresti farti una volta per tutte un'installazione pulita, non configurarla
e tenerla come base per i cloni che quindi "nasceranno" belli puliti invece
che già con la configurazione di un altro nodo.
Ad ogni modo, noi di solito facciamo così (in verità sono appunti che mi ero
fatto solo per cambiare indirizzo, ci ho aggiunto ora i comandi per cambiare
anche il nome. Non l'ho provato ma dovrebbe funzionare):
$ MCR NCP
NCP> PURGE EXE ADDR
NCP> PURGE EXE NAME
NCP> DEF EXE ADDR new.addr
NCP> DEF EXE NAME newname
NCP> EXIT
$ EDIT MODPARAMS.DAT (Sistemare SCSSYSTEMID e SCSNODE)
$ MCR SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET SCSSYSTEMID xxxx
SYSGEN> SET SCSNODE xxxxxx
SYSGEN> WRITE CURRENT
SYSGEN> EXIT
$ REBOOT
Volendo, c'è qualcosa da fare anche se cambi il label del system disk, come
del resto viene suggerito nell'help di SET VOLUME/LABEL, se proprio vuoi:
$ SET VOLUME ddcu: /LABEL=newlabel
$ PROD REG VOL oldlabel ddcu:
Tutto il discorso sulle code da ricreare credo che sia valido solo quando si
tratta di un cluster, non credo altrimenti che rimanga il vecchio nome. Una
cosa che non abbiamo mai fatto (ma di solito ci capita di cambiare indirizzo
di un nodo, non il nome), è modificare l'identificativo SYS$NODE_xxxxxx in
AUTHORIZE, ma pure quella è comunque una cosa da pochi secondi.
In verità direi che tutto quanto è modificabile con una bella procedura DCL
che pensi a tutto... Potresti approfittarne per provare a scriverla! :-)
Ciao,
G.


A dir il vero, i "cloni" non sono abbastanza puliti... sono 
un'installazione di base con TCP/IP e DECnet. Quasi quasi mi conviene 
creare un'installazione senza licenze, senza DECnet e senza TCP/IP, ed 
aggiungere solo i due "pacchetti" volta per volta.
Ad ogni modo, dovevo cambiare un nodo standalone, niente cluster.
Cosa accade se due nodi hanno lo stesso nome ma indirizzi DECnet diversi ?
Mi gira la "malsana" idea di cambiare solo l'indirizzo :P

 Mi gira la "malsana" idea di cambiare solo l'indirizzo :P
Ma quanto sei pigro... :P
Comunque direi che non dovrebbe succedere granché: in rete viaggia solo
l'indirizzo DECnet numerico, non il nome, e non essendoci l'equivalente di
un DNS centralizzato non dovrebbero esserci conflitti. Certo però che dopo
un SET HOST xxxxxx non funzionerebbe proprio bene e dovresti avere nel
database di NCP un nome diverso da quello effettivo del nodo. Fattibile e
permesso, ma caotico.
Dai, che ti costa? Ci metti pochi secondi: NCP e SYSGEN li devi usare in
ogni caso, MODPARAMS.DAT pure lo devi modificare in ogni caso, anche se
cambi solo l'indirizzo. Tanto vale cambiare anche il nome. Per le code
secondo me non hai nulla da fare e l'identificativo in AUTHORIZE si risolve
con un singolo RENAME al prompt UAF>. E pure il reboot va fatto comunque.
Se anche avessi messo il nome del nodo nel label del system disk, fai prima
tu a cambiarlo con un SET VOLUME/LABEL che io a scrivere queste due righe.
Idem se tu volessi fare il fine e registrare la modifica nel database dei
prodotti installati con PRODUCT REGISTER VOLUME, cosa del tutto facoltativa.
Ciao,
G.

 Ma quanto sei pigro... :P
Mi piace conoscere tutte le alternative, anche se poi scelgo la più lunga 
e più elegante :)
Avevo anch'io pensato al caos di SET HOST :P

Tralasciamo il mal di testa per le finestre aperte ed i vari "strati" :)
Connessione a Simh #1: Host Linux -> Putty (ssh) verso host OpenBSD -> 
simh
Connessione a Simh #2: Host Linux -> simh -> putty (telnet) verso la 
porta interna 23000
in modo da gestire tutto da una sola postazione video/tastiera.
Tralascio altre due istanze di Putty, telnet, verso i due VAX virtuali 
che, a loro volta, erano connessi sia in TCP/IP (un altro telnet).
-----------------
Ho incontrato il seguente problema: 
%RMS-F-DEV, error in device
name or inappropriate device type for operation
che ho risolto.
Però, le due macchine non si vedono fra di loro :(
%SYSTEM-F-UNREACHABLE, remote node is not currently reachable
Nodo 1
======
Product:  DECNET        Node:  ASUSVX               Address(es):  1.1
Product:  TCP/IP        Node:  vax.none             Address(es):  
192.168.1.176
Nodo 2 (Cluster master)
======
Product:  DECNET        Node:  SVXVAX               Address(es):  1.943
Product:  TCP/IP        Node:  vax.none             Address(es):  
192.168.1.175
Funziona SET HOST 0, SET HOST nodo_locale, ma non SET HOST nodo_remoto
tcpdump sul Nodo 2, mostra pacchetti del tipo
16:20:58.101465 aa:00:04:00:af:07 (oui Unknown) > ab:00:04:01:01:01 (oui 
Unknown), ethertype SCA (0x6007), length 134: 
	0x0000:  7600 ab00 0401 0101 0100 aa00 0400 af07  v...............
	0x0010:  a000 0800 0080 0501 0000 0653 5658 5641  ...........SVXVA
	0x0020:  5800 8001 ff83 0004 0000 0000 0000 0000  X...............
	0x0030:  001f 0300 0000 0000 0000 0000 0000 0000  ................
	0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
	0x0050:  9205                        
e set host 1.1 (o 1) mostra un lungo tentativo di connessione.
tcpdump sul nodo 1 indica pacchetti identici (nel senso uguali byte per 
bute), sempre con SVXVAX e mai con ASUSVX.
Sul Nodo 1, poi, set host x (x <>1) genera immediatamente
%SYSTEM-F-UNREACHABLE, remote node is not currently reachable
Mi chiedo se sia un problema di OpenVMS sul nodo 1 (server Asus dedicato 
a simh) oppure sia l'host OpenBSD a filtrare i pacchetti.
Propendo per la prima ipotesi... vado a veder che pesci posso prendere :P

Molto semplice !
In 
systartup_vms.com
 era commentato l'avvio della DECnet :(
Adesso funziona tutto, tranne la mia testa :P
Ricapitolando, abbiamo una rete virtuale con tre VAXen:
Un cluster master, un satellite, uno standalone.
La DECnet funziona, TCP/IP anche.
Non resta che inserire l'Alpha, nell'attesa di un VAX.
Oggi me ne hanno "soffiato" uno dalla Spagna.
VAX 4000/100 dual DSSI. Non c'era una foto, uno straccio di descrizione 
(a parte il titolo). Ho chiesto una foto e qualche informazione e qualcun 
altro se l'è preso con il compralo subito ... neanche i falchi in 
picchiata ...

 Product:  TCP/IP        Node:  vax.none         Address(es): 192.168.1.175
I due nodi hanno lo stesso hostnome TCP/IP?

 I due nodi hanno lo stesso hostnome TCP/IP?
È l'ultima cosa rimasta da sistemare, ma non dà grandi problemi (per 
ora) ... utilizzo solo indirizzi numerici.

>
Me l'ha dato ad un certo punto il nodo master del cluster, tentando SET 
HOST 0.
Da premettere che, dopo la creazione del cluster, non avevo più provato 
la DECnet, e che prima SET HOST 0 funzionava, anche se, non avendo ancora 
altri nodi, non avevo sperimentato la connessione.
Sul nodo 2, invece, quello cui ho cambiato il nome e l'indirizzo DECnet, 
al successivo riavvio TCP/IP era completamente disabilitato, e 
l'interfaccia di rete non configurata.
In entrambi, comunque, si è reso necessario eliminare il commento $! dal 
file 
SYSTARTUP_VMS.COM
, relativo all'avvio di DECnet.
Non escludo qualche mia responsabilità: per questo sto smanettando con 
simh, prima di distruggere l'Alpha :P
In realtà sto decidendo dove piazzarlo in camera (e cosa spostare, 
probabilmente uno dei 5170), in modo da averlo sottomano (liberando il 
tavolo del salone e contribuendo alla pace familiare ...)

 file 
SYSTARTUP_VMS.COM
, relativo all'avvio di DECnet.
Sì, ovvio, come per il TCP/IP. E ci sono addirittura due modi per far
partire DECnet: uno è mediante la sottomissione batch di 
STARTNET.COM
 e
l'altro con START/NET DECNET. Meglio quest'ultimo che non richiede le code
batch funzionanti e non rischia conflitti e incroci con l'avvio del TCP/IP.
Sappi (non ricordo se te l'ho già detto) che DECnet Phase IV deve sempre
partire prima del TCP/IP perché ha bisogno di cambiare il MAC address della
Ethernet e non è possibile se la scheda di rete è già in uso. È una
necessità insita nel funzionamento di DECnet e non una limitazione di VMS o
della relativa implementazione di rete, infatti è così anche su Linux.
Ciao,
G.

 G.
Lo sapevo, grazie ! È stata la prima cosa che ho verificato nel file 
SYSTARTUP ...
Ed ho anche visto la riga relativa al SUBMIT 
STARTNET.COM
. Non avendo né 
code né job manager attivo, l'ho lasciata così com'era. D'altronde, 
l'ordine era quello ed ora funziona tutto ... che posso voler di più ? :)

 code né job manager attivo, l'ho lasciata così com'era.
Oh be', questo si fa presto e può sempre essere utile:
$ START/QUEUE/MANAGER/NEW
$ INIT/QUEUE/BATCH/JOB=3 SYS$BATCH
$ START/QUEUE SYS$BATCH
Dopodiché vedere SHO QUE, HELP QUE, HELP SUBMIT e togliere il commento allo
START /QUEUE in SYSTARTUP. :)
Ciao,
G.