Newsgroup: it.comp.retrocomputing
Titolo: [HELP] Disco VMS ?

Ho per le mani un disco da 1GB, forse contenente dati o VMS.
L'immagine disco, se avviata, riporta gli errori di cui ad un post 
precedente.
Data la mia limitata esperienza, mi chiedevo se:
1) Nel caso fosse un disco di sistema, ma corrotto, è possibile 
sistemarlo senza perdere i dati presenti ?
2) Nel caso fosse un disco dati, l'installazione del sistema provoca la 
cancellazione di questi ultimi ?

Mi rispondo da solo :)
00000000   A0 00 C6 15  00 02 C0 11  C0 65 1E 00  01 94 03 03  .........e......
00000010   F7 09 06 00  FB 01 05 00  00 00 5F 90  76 FF DF 8B  .........._.v...
00000020   74 FF FD 80  87 00 56 53  43 30 20 20  20 20 20 20  t.....VSC0
00000030   20 20 20 20  20 20 69 73  20 6E 6F 74  20 61 20 73        is not a s
00000040   79 73 74 65  6D 20 64 69  73 6B 0D 0A  0A 00 00 00  ystem disk......
00000BD0   20 20 20 20  20 20 20 20  56 53 37 33  20 20 20 20          VS73
00000BE0   20 20 20 20  20 20 20 20  20 20 20 20  20 20 20 20
00000BF0   44 45 43 46  49 4C 45 31  31 42 20 20  00 00 E4 B4  DECFILE11B  ....
00000C00   18 00 FF 7F  00 0C 50 41  47 45 46 49  4C 45 2E 53  ......PAGEFILE.S
00000C10   59 53 01 00  0E 00 01 00  00 00 18 00  FF 7F 00 0C  YS..............
00000C20   53 57 41 50  46 49 4C 45  2E 53 59 53  01 00 0F 00  SWAPFILE.SYS....

 cancellazione di questi ultimi ?
Dipende da cosa rispondi durante l'installazione: a un certo punto devi
scegliere tra INITIALIZE e PRESERVE, se scegli la seconda il disco non viene
inizializzato e il sistema operativo viene installato sopra l'eventuale
precedente, preservando le directory non di sistema eventualmente presenti.
Anzi credo pure che vengano preservati i file non di sistema e/o i file di
configurazione personalizzati presenti nelle directory di sistema.
Comunque la cosa più semplice in un caso del genere è montare il disco come
aggiuntivo di un sistema già funzionante e poi guardarci dentro normalmente
come fosse un disco qualunque.
Mi viene in mente che potrebbe esistere anche un'altra casistica: potrebbe
essere un system disk, ma con una root diversa da zero e quindi se non
glielo dici non la troverà. Difficile e raro, ma non del tutto impossibile.
Ma ti ripeto: il modo più pratico è semplicemente montarlo e verificare.
Ciao,
G.

 00000040   79 73 74 65  6D 20 64 69  73 6B 0D 0A  0A 00 00 00  ystem disk......
Non fidarti. Quella frase c'è sempre anche se il disco È un system disk. :-)
Tra l'altro il codice del boot block non viene sempre eseguito, anzi spesso
viene ignorato. Credo che quella frasetta possa eventualmente venire emessa
solo da un VAX, anche quando si tratta di un system disk per Alpha (o IA64).
Tralasciando come fa il boot un Itanium, perché ha varie complicazioni
dovute alla presenza dell'EFI e alla partizione FAT, in un Alpha la SRM
accede al system disk e dal boot block legge solo un paio di word: una che
contiene il numero del blocco al quale inizia APB.EXE e l'altra con la sua
dimensione in blocchi. Con quelle due informazioni la SRM accede al disco e
carica in memoria quel numero di blocchi a partire dalla posizione indicata
(infatti il file APB.EXE ha gli attributi Contiguous e Nomove impostati).
Dopodiché il controllo passa dalla SRM a quanto caricato, e se si tratta
effettivamente di APB.EXE il boot prosegue come deve. Quando si installa una
patch che sostituisce APB.EXE o comunque quando il file viene spostato, è
necessario aggionare il boot block con WRITEBOOT in modo che punti alla
posizione aggiornata di APB.EXE e contenga la sua nuova lunghezza.
Per i VAX dipende. Molti hanno VMB.EXE in ROM e quello è in grado di
interpretare il file system ODS-2, quindi fanno il boot senza bisogno di un
boot block ma cercando sul disco direttamente i file necessari. Altri molto
antichi caricavano VMB.EXE da console media (nastrino o floppy) e dopo si
ricadeva nel primo caso, cioè accesso al system disk tramite file system.
Solo alcuni (fra cui il VAX 6000, se non sbaglio), utilizzavano il boot
block caricandolo tutto in memoria e passandogli il controllo. Il boot block
conteneva del codice eseguibile che si incaricava di cercare e caricare
VMB.EXE con lo stesso metodo usato dalla SRM e se non riusciva nell'impresa
visualizzava sulla console la frasetta che hai trovato tu.
Credo che il comando INITIALIZE scriva sempre quel po' di codice nel boot
block, anche quando si tratta di quello presente in VMS per Alpha o IA64.
Comunque, alla fine, indipendentemente dal fatto che si tratti di VMB, APB o
IPB (quello per Itanium, caricato per mezzo di VMS_LOADER.EFI), tutti e tre
sanno leggere il file system ODS-2 da cui caricano SYSBOOT.EXE che a sua
volta carica il resto del kernel e fa tutto quello che occorre per il boot.
Idem vale per il boot di un satellite in cluster: in un modo o nell'altro
viene inviata al satellite un po' di roba che crea un ambiente standard per
SYSBOOT.EXE, per il quale tutti i vari tipi di boot sono indistinguibili.
Ciao,
G.

E se fosse un disco di un satellite ?
Dal momento che dispongo di un'immagine del disco, sulla quale lavorare, 
dove si troverebbe SYSBOOT.EXE o la radice [00000] nel disco ?
Ho cercato la stringa SYSBOOT.EXE nell'immagine, e sembra trovarsi solo 
nell'help di sistema.



Premessa: ma perché invece di farti tante domande non monti quel benedetto
disco in una macchina e ci guardi dentro, ovvero agganci la sua immagine a
Simh, fai il boot di un VMS già configurato e lo monti come disco dati? Se
ce l'hai, direi che potresti usare anche vmscd per guardarci dentro.
Detto questo, passiamo alla risposta. :-)
Ricordati che un satellite può benissimo funzionare senza alcun disco. Se
comunque fosse proprio il disco di un satellite, lo dovresti trattare come
un comune disco dati, perché alla fine di quello si tratta. E sempre se
fosse il disco di un satellite, SYSBOOT.EXE non lo dovresti trovare da
nessuna parte perché verrebbe ricevuto via rete al momento del boot.
Nelle versioni più recenti si trova qui:
	Dxxx:[SYSnn.SYSCOMMON.SYSEXE]SYSBOOT.EXE
	Dxxx:[VMS$COMMON.SYSEXE]SYSBOOT.EXE
In quelle meno recenti qui:
	Dxxx:[SYSnn.SYSEXE]SYSBOOT.EXE
	Dxxx:[SYSEXE]SYSBOOT.EXE
In entrambi i casi non si tratta di due copie del file, ma di una sorta di
"hard link" dello stesso file, presente in due directory diverse. Non mi
ricordo più se il passaggio da "meno recente" a "più recente" è avvenuto con
la V5 o la V6, comunque non è difficile capire di quale caso si tratta.
[000000] (sei zeri, non cinque, e puoi scrivere anche [0,0]) è la root del
disco e si trova sempre in Dxxx:[000000]. Quella che intendevo io parlando
di root differente è la struttura che si sviluppa dentro le varie possibili
Dxxx:[SYSnn], dove "nn" può andare da 0 a F per i nodi che fanno boot da
quel disco direttamente e da 10 a FF per i satelliti che usano quel disco
come system disk remoto via rete.
In verità le root [SYSD], [SYSE] e [SYSF] almeno su VAX sono riservate
rispettivamente per alcuni tipi di boot diagnostico, per lo stand-alone
backup e per la procedura di upgrade del sistema operativo. Se guardi nel
system disk del clusterino che hai configurato con Simh, dovresti trovare
almeno Dxxx:[SYS0] per la macchina stessa e Dxxx:[SYS10] per il satellite
che mi pare tu avessi configurato. Se ne avevi configurati due ci sarà
verosimilmente anche Dxxx:[SYS11].
Sono quasi certo di averle già scritte tutte queste cose, basterà andare a
cercare con Google groups. :-)
Ciao,
G.

 
Perché stavo curiosando nella struttura fisica per cercar di capirla 
senza montare il disco/immagine e lasciar fare al sistema :)
E poi ... c'è un altro perché ... ma non si può ancora dire ;)

 E poi ... c'è un altro perché ... ma non si può ancora dire ;)
Se vuoi sapere com'è fatto il file system ODS-2, non hai che da dirlo. Ci
sono un paio di esaurientissimi documenti in giro che ti spiegano com'è
fatto e come interpretarlo. Oltretutto non è neppure molto complicato, anzi
è molto lineare e non fa neppure uso di strutture non "leggibili" a occhio
nudo, tipo b-tree e cose del genere. :-)
G.