Newsgroup: it.comp.retrocomputing
Titolo: OpenVMS nativo su x86

S�, il subject l'avete letto bene: due giorni fa � stato fatto pubblico annuncio
dell'accordo tra HP e VSI (VMS Software, Inc.) per la cessione dei sorgenti di
VMS e relativo futuro sviluppo sia su Integrity (Itanium) sia, udite udite (!),
di un port di VMS su architettura x86-64!
 
http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-odyssey/openvms.aspx
 
 
http://www.vmssoftware.com/news/announcement/RM/
 (il sito � ancora incompleto)
 
http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
 
 
http://www.theregister.co.uk/2014/07/31/openvms_spared/
 
 
http://www.computerworld.com/s/article/9250087/HP_gives_OpenVMS_new_life
 
 
http://www.enterprisetech.com/2014/08/01/upstart-breathe-new-life-venerable-openvms/
 
 
Come faranno? Semplice: VSI ha contattato e arruolato buona parte dei componenti
del gruppo di sviluppo originale di VMS, molti dei quali hanno una lunghissima
storia iniziata ancora ai tempi della Digital e proseguita fino a pochi anni fa,
quando HP decise di smantellare tutto e trasferire il supporto in India. Molti
di loro scrivono anche su comp.os.vms (e i loro nomi sono per sempre fissati nel
testo dell'help in linea di VMS*). A giudicare dal tenore delle discussioni che
si leggono in questi giorni, non vedono l'ora di cominciare. :)
 
Su comp.os.vms qualcuno ha scritto: future will take precedence over the past.
 
Ciao, :)
G.
 
 
* I nomi degli utenti e delle directory negli esempi d'uso dei comandi di VMS,
sia quelli visibili con HELP sia quelli dei manuali, non sono a caso: sono i
nomi dei programmatori che hanno contibuito allo sviluppo dei relativi moduli.

Ach, la prossima volta prima di fare un post, devo ricordarmi di fare un 
refresh del newsgroup...
 

Ciao
 
La notizia non è proprio retro visto che parla della v.next :) quindi software del 2017 o 2018... più che retrocomputing è futurecomputing... che però si chiama sience fiction :)
 
La cosa positiva è che dopo tanti anni HP ha compreso il valore di VMS... e lo ha venduto a terze parti!
VMS Software per ora che ha fatto... è vero che ha i diritti di VMS da pochi giorni, ma ha solo pubblicato una generica roadmap, in cui in pratica dice solo quello che gli utenti più affezionati sognavano.
Tra dirlo e realizzarlo, c'è molta strada, e infatti nessuna data specificata.
Non voglio fare il guastafeste, ma fino a scrivere una roadmap, ci riuscivo anche io...
 
Le versioni fattibili sono la v8.next e la v8.next+1 perché partono dal sorgente esistente, aggiungendo supporto a nuovi server e generici "enhancements"
 
La v.next, con il supporto a processori x86, è quella meno fattibile.
Sicuramente il codice VMS è altamente portabile, lo dimostra il porting da VAX a Alpha a Itanium.
Però non basta portarlo, non è codice Open Source, "provided AS IS", i clienti VMS si aspettano una qualità superiore, quindi c'è uno sforzo di testing notevole.
Più facile sarebbe passare direttamente ad una versione per macchine virtuali, stratificato sopra Linux o *BSD, dove i driver siano già forniti dal sistema sottostante, già collaudati anche se a livello "community"
 
La mia idea è che VMS software "ci proverà", cioè acquisirà i clienti, incasserà un po' di licenze e contratti di assistenza, porterà avanti lo sviluppo delle v.next e v.next+1, e poi si vedrà.
 
Se l'introito di licenze e contratti di assistenza (non di hardware, VMS software non ne produrrà) sarà sufficiente, allora si andrà avanti.
Altrimenti diranno "ci abbiamo provato", "non c'è abbastanza mercato", "i clienti hanno preferito migrare ad altre soluzioni", ecc...
 
VMS ha avuto il suo momento in cui era al top della tecnologia, ma non lo è più.
Nelle performance pure, non è sicuramente in grado di reggere contro installazioni Linux anche sulla stessa macchina.
Il clustering è sempre stato il punto di forza di VMS, ma ormai il concetto di single system image è un po' datato, il clustering oggi si fa con HADOOP: decine o centinaie di macchine economiche, setup in mezzora, performance paurose.
 
Mi dispiace dirlo, veramente, ma VMS è un cavallo mezzo morto.
Un cavallo prestigioso, di alto lignaggio, di grande e gloriosa fama, venduto ad una scuderia minore, che spera di fargli fare qualche ultima corsa buona prima del pensionamento... o dell'abbattimento.
 
Just my 2 cents...
Ciao
gl

 Un cavallo prestigioso, di alto lignaggio, di grande e gloriosa fama, venduto ad una scuderia minore, che spera di fargli fare qualche ultima corsa buona prima del pensionamento... o dell'abbattimento.
 
Cosa ï¿½ noto di questa VMS software, soprattutto per quanto riguarda 
organizzazione interna ed organigramma ? un azienda IT raccoglie 
successi quando ha ottimi ingegneri e un management che non interferisce 
col lavoro di R&S....
 
Saluti,
dott. Piergiorgio.
 

 col lavoro di R&S....
 
Una azienda IT raccoglie successi quando vende e incassa molto... :)
 
Ciao
gl

 economiche, setup in mezzora, performance paurose.
 
Qui credo valga lo stesso discorso di NSK: se fai tanto da aver bisogno di certo
software (e hardware, eventualmente), non c'� Linux che tenga e performance che
tengano. Anche perch� pure il concetto di performance � relativo: in alcuni casi
� un discorso di cicli CPU e potenza di calcolo; in altri casi � un discorso di
resistenza agli eventi avversi, anche a discapito della velocit� di calcolo.
 
Questi che vogliono fare il port di VMS verso x86 non si rivolgono certo al
saturatissimo mercato dei server Linux, ma ad ambienti dove VMS � un plus pi� o
meno irrinunciabile, non fosse altro per la mole di software sviluppato ad hoc.
Principalmente si tratta di utilities (reti elettriche, centrali nucleari,
etc.), finanza (borse, banche, transazioni monetarie) e telecomunicazioni (pare
che buona parte degli SMS del mondo viaggino grazie a VMS, per esempio).
 
� un po' lo stesso discorso dei dinosauri IBM: non ci sono aziende che sono
"ancora" su mainframe; ci sono aziende che sono su mainframe. Cio� non si tratta
di una scelta subita o dettata dall'inerzia, ma di qualcosa di fatto con
criterio: questo anzich� quello. Anzi, cosa che un po' ha stupito anche me,
qualcuno che lavora in IBM mi ha detto che negli ultimi due-tre anni la tendenza
si � invertita e alcuni "grossi player" stanno tornando su mainframe dopo aver
tentato altre strade, a volte anche stimolati dalle mode. 
 
Pu� darsi, ma questa � un'ipotesi tutta mia, che questi di VSI abbiano deciso di
entrare in gioco in un momento in cui la loro operazione di recupero di VMS
abbia una qualche possibilit� di riuscita, mentre fino a qualche anno fa, quando
c'era il fuggi fuggi da tutto ci� che era considerato proprietario e quindi
brutto a prescindere, avrebbero solo ricevuto risate in faccia. :)
 
Comunque VMS non � single system image.
 
Ciao, :)
G.
 

 ha ottimi ingegneri e un management che non interferisce col lavoro di R&S....
 
Ancora si sa poco, del resto la cosa � stata annunciata a sorpresa quattro
giorni fa (e con un fine settimana in mezzo); o forse so poco io che non ho
ancora avuto tempo di spulciare tutto. Comunque � certo e ormai confermato che
sia stato ricostituito in massima parte il team di sviluppo originario di VMS
(composto sia da veterani dei tempi Digital, sia da risorse pi� fresche ma ben
introdotte nel sistema) che fu smembrato nel 2010 quando HP decise di sospendere
tutto e trasferire il supporto in India con il solo scopo di fare manutenzione
spicciola senza ulteriori sviluppi.
 
Uno dei leader del team sar� Clair Grant, autore del godibilissimo e non troppo
tecnico "racconto" dall'interno sul port di VMS verso Itanium (HTML e PDF):
 
http://h71000.www7.hp.com/openvms/journal/v6/porting_openvms_to_integrity.html
 
http://h71000.www7.hp.com/openvms/journal/v6/porting_openvms_to_integrity.pdf
 
 
Il quale Clair Grant (il nome � fuorviante, ma � un uomo) ha dichiarato:
 
| We are planning to port VMS to x86 just like we ported VMS to Alpha
| and Itanium.
| 
| Clair Grant
| Director of R&D
| VMS Software Inc
 
Ciao, :)
G.

 Il quale Clair Grant (il nome � fuorviante, ma � un uomo) ha dichiarato:
 
La variante senza la "e" finale è in effetti tipicamente maschile, anche se assolutamente desueta.
 
Scusa, ma il caldo mi rende un po' (troppo) pignolo :-)
 
m.

 Scusa, ma il caldo mi rende un po' (troppo) pignolo :-)
 
Figurati, anzi! :) Era una cosa che mi ero domandato anch'io. Ho chiesto a una
mia amica traduttrice, ma lei di questa variante maschile non ha mai sentito
parlare... Quindi insomma, esiste(va), non era un'idea pi� unica che rara dei
genitori di questo qui. Interessante. :)
 
G.
 

 Comunque VMS non � single system image.
 
Mi fidavo della wikipedia... :)
http://en.wikipedia.org/wiki/Single_system_image
 
 
Ciao!
gl

 genitori di questo qui. Interessante. :)
 
quanto importa ï¿½ se riesce a mandare la boccia in buca, senza spacconate 
(scusate... clar/chiaro/chiara... non ho resistito...)
 
seriamente, dalla breve descrizione che haid dato mi sembra una persona 
piï¿½ capace per dirigere tecnicamente il complesso lavoro di fronte
 
Saluti,
dott. Piergiorgio.

 
http://en.wikipedia.org/wiki/Single_system_image
 
 
Eh, quell'articolo in effetti non è molto preciso. Alla fine, semplificando, un
cluster VMS è formato da macchine separate con lo storage in comune. È vero che
i PID sono univoci all'interno dell'intero cluster, ma non è vero (secondo il
mio punto di vista) che si ha l'illusione di una macchina sola: se faccio SHOW
SYSTEM vedo solo i processi del nodo a cui sono collegato (a meno di aggiungere
/CLUSTER, ma rimane comunque evidente cosa gira su quale macchina). Però un
comando come STOP/ID (equivalente a kill) funziona da/verso qualunque macchina.
 
La root comune, dipende. :) Più nodi possono partire dallo stesso disco e quindi
condividere gli stessi effettivi programmi, ma il cluster esiste e funziona
anche se ogni macchina ha il suo system disk separato dagli altri (ad esempio in
un cluster misto VAX-Alpha-Itanium in cui i binari sono per forza diversi).
 
È vero che lo storage è in comune e che da qualunque macchina si può accedere
agli stessi file senza dover cambiare una virgola nel percorso per raggiungerli.
Ed è anche vero che l'I/O space è comune (volendo) dato che qualunque device è
raggiungibile da qualunque nodo del cluster (e.g. i nastri per i backup). Però
come detto sopra può e deve rimanere la separazione tra binari per architetture
differenti e tra i file di configurazione specifici delle singole macchine.
 
Infine, e mi pare che l'articolo di Wikipedia non lo dica esplicitamente, è vero
che VMS fa load balancing tra i nodi del cluster: un job batch (vedi sopra)
inoltrato per l'elaborazione a una coda comune a tutto il cluster viene posto in
esecuzione sul nodo che in quel momento ha la CPU più libera. Idem vale per i
collegamenti da remoto via LAT, DECnet e TCP/IP (se il cluster alias è attivo):
risponde alla richiesta di login la macchina al momento più scarica.
 
Ciao,
G.
 
 
P.S. Ho cambiato encoding dei messaggi. Vediamo se ora Google Groups va meglio.

 P.S. Ho cambiato encoding dei messaggi. Vediamo se ora Google Groups va meglio.
 
Da anni uso Google Groups, convivendo con i suoi vantaggi e svantaggi, ma lo trovo molto pratico, per quel poco uso dei gruppi che faccio.
 
Ciao!
gl

 senso.
 
Non ne avevo mai sentito parlare e sono andato a vedere. :) E sì, in effetti
hanno più o meno reinventato la ruota (con rispetto parlando), anzi alcune
spiegazioni che ho letto sul sito Oracle sembrano quelle di qualche vecchio
manuale anni '60 che spiegava come fare con le schede perforate e l'output su
tabulato a modulo continuo. :) A volte la saggezza dei vecchi ritorna. :)
 
Ciao,
G.
 

 tabulato a modulo continuo. :) A volte la saggezza dei vecchi ritorna. :)
 
Beh significa che c'era pressione per avere su Java quelle funzionalità.
Le può aver richieste solo chi già le usa per passare su Java qualche sistema legacy... qualcuno sta affilando le armi, dunque...
 
Ciao!
gl

 il mio Digital-feticismo :)
 
Più somigliante di quanto tu creda: ha il concetto di standard input e standard
output, ha i processi, ha file e directory strutturate ad albero, ha una linea
di comando "mobile", cioè su terminali "scorrevoli", etc. e il fatto che esista
GNV (GNU per VMS) la dice lunga sulla compatibilità di fondo. Per VMS ci sono
tool come wget, awk, tar, zip etc. etc. etc.
 
Nel mondo IBM tutte queste cose sono state impiantate dopo; inizialmente più o
meno come accrocchi, curiosità, o per poter dire di avercelo come gli altri, poi
sono via via migliorate e oggi effettivamente l'interfaccia Posix è una realtà;
ma rimane il fatto che sono sempre state funzionalità del tutto estranee alla
filosofia di quei sistemi e oggi sono implementate per mezzo di massicce dosi di
software aggiuntivo e astrazioni di ogni genere.
 
Anche una cosa banale come la funzione printf() diventa complessa perché il
sistema non è fisicamente predisposto (se parliamo di terminali) ad aggiungere
una riga in fondo a un display e a far sparire la riga più in alto: essendo
tutto rigorosamente a blocchi deve salvare il display, modificarlo e inviarlo
nuovamente al terminale, il tutto traducendo/inventando gli attributi video che
printf() non sa neppure cosa siano, ma che al terminale servono.
 
Anche VMS in passato è stato un ambiente piuttosto ostile a Unix, ma è comunque
partito da una posizione enormemente più vicina rispetto ad altri sistemi tipo
quelli IBM. Una cosa come printf() esisteva già nativamente come concetto ancor
prima che come funzione vera e propria (vedi il servizio di sistema SYS$FAO cioè
Formatted ASCII Output). Infatti, fra i cugini di VMS c'è anche TOPS-20 che
nacque come TENEX in casa BBN e fu poi acquistato dalla Digital che da lì prese
parecchi spunti per i suoi OS successivi. Ed è risaputo e accettato che le prime
comunità Unix si ispirarono alle strutture interne di TOPS-20 (un paio di casi:
il filesystem UFS è un'evoluzione, mentre le fork sono una semplificazione).
 
Ciao,
G.
 
 
P.S.
http://www.99-bottles-of-beer.net/language-tandem-tal-437.html
 
http://www.99-bottles-of-beer.net/language-cl-for-as400-128.html
 
http://www.99-bottles-of-beer.net/language-jcl-6.html
 
http://www.99-bottles-of-beer.net/language-dibol-214.html
 

 
http://www.99-bottles-of-beer.net/language-dibol-214.html
 
 
Il codice per DIBOL è sicuramente il più leggibile delle 4 versioni citate.
Gli altri linguaggi sono più simili ad una punizione che il programmatore deve scontare per qualche crimine commesso in una vita precedente :)
 
Qui non scherzo, indubbiamente è più leggibile la versione Assembly x86!
http://www.99-bottles-of-beer.net/language-assembler-x86-(tasm-flavour)-1205.html
 
 
Questa è semplice e ben leggibile
http://www.99-bottles-of-beer.net/language-java-4.html
 
 
ma questa è arte pura... ClassLoader magic...
http://www.99-bottles-of-beer.net/language-java-1162.html
 
 
Ciao!
gl

 prendere il codice e ricompilarlo su VMS ma anzi penso richieda pesanti patch.
 
Decisamente esatto. Se cerchi fra i thread di comp.os.vms dovresti trovarne uno
che descrive gli sfracelli che uno dei soliti frequentatori (non ricordo chi) ha
dovuto fare per portare non so quale versione di wget su VMS. Il che non fa
altro che confermare la mia tesi: se è difficile portare un solo programma che
alla fine non fa altro che scrivere un po' su disco e sul terminale dell'utente
e fare un po' di leggi/scrivi su un socket TCP, pensa cos'è portare un intero
pacchetto complesso e ramificato che lavori intensamente con dati strutturati...
 
Ciao,
G.
 
 
P.S. il contenuto di un FDL come dicevo prima:
 
| FILE
|         ORGANIZATION            indexed
|         GLOBAL_BUFFER_COUNT     0
|         OWNER                   [1,4]
| 
| RECORD
|         CARRIAGE_CONTROL        none
|         FORMAT                  variable
|         SIZE                    0
| 
| AREA 0
|         ALLOCATION              600
|         BEST_TRY_CONTIGUOUS     yes
|         BUCKET_SIZE             12
|         EXTENSION               300
| 
| AREA 1
|         ALLOCATION              120
|         BEST_TRY_CONTIGUOUS     yes
|         BUCKET_SIZE             12
|         EXTENSION               60
| 
| KEY 0
|         CHANGES                 no
|         DATA_AREA               0
|         DATA_FILL               80
|         DATA_KEY_COMPRESSION    no
|         DATA_RECORD_COMPRESSION no
|         DUPLICATES              yes
|         INDEX_AREA              1
|         INDEX_COMPRESSION       no
|         INDEX_FILL              80
|         LEVEL1_INDEX_AREA       1
|         PROLOG                  3
|         SEG0_LENGTH             8
|         SEG0_POSITION           0
|         TYPE                    int8

 cambiato, recentemente, per supportare LLVM)
 
Risulta anche a me che in generale i sistemi *BSD fossero pi� avanti con
il lavoro su LLVM/Clang rispetto a quelli *Linux, anche se le
informazioni che ho sono ferme a due se non a tre anni fa.
 
 
-- 
Nicola D'Agostino
<!-- 
http://www.nicoladagostino.net
 -->
<!-- 
http://www.storiediapple.it
 -->

 pacchetto complesso e ramificato che lavori intensamente con dati strutturati...
 
La mia tesi è che esiste tanto software utile, come wget.
Se wget non compila sul tuo sistema che fai?
Che alternative ci sono?
All'altezza di wget?
Oppure mi devo scrivere un tool analogo, da solo?
E quante altre librerie esistenti, funzionali, testate e pronte, mi resteranno precluse perché incompatibili?
 
Se wget o una qualche libreria può essere uno strumento marginale, sul fronte web server VMS non è messo meglio.
Vedo che l'ultima versione di Secure Web Server 2.2 (basata su Apache 2.0) per VMS è del febbraio 2011, con qualche patch a settembre 2012...
Primo, Apache 2.0 è al limite dell'obsoleto. Ook, funziona, questo basta, ma se così fosse non avrebbero sviluppato nuove versioni di Apache.
E poi sarà aggiornato per tutte le patch di sicurezza?
Di certo, se ho del software che gira su VMS ed eroga applicazioni o dati tramite SWS, farei bene a non dormire tranquillo...
Le mie alternative sono:
1) aspettare che VSI muova qualcosa (e c'è tanta roba da muovere), sempre che accada
2) muoversi verso altre soluzioni nello stesso tempo in cui VSI muova ipoteticamente qualcosa
Ai posteri l'ardua sentenza! :)
 
Ciao
gl

 informazioni che ho sono ferme a due se non a tre anni fa.
 
Ciao! :)
 
Di sicuro FreeBSD compila tutto su LLVM/Clang.
Di questo i programmatori FreeBSD sono molto fieri, perché LLVM/Clang ha licenza BSD mentre GNU GCC è GPL, quindi si sono resi indipendenti da codice GPL almeno per il sistema di base.
 
Se non sbaglio Clang è il compilatore C degli strumenti di sviluppo Apple, che fa la buona parte dello sviluppo di questo compilatore.
 
Ho letto che anche il kernel OpenBSD dovrebbe essere compilabile, mentre non lo è NetBSD.
Con delle patch anche Linux si compila con Clang, ma non la versione ufficiale.
 
Ciao!
gl

 Con delle patch anche Linux si compila con Clang, ma non la versione ufficiale
 
 
  Secondo un intervento che ho intravisto sino a un paio d'anni fa era
abbastanza dura e piena di errori.


 dubbio, se accede ai dati così, o sono pochi pochi, oppure è il modo sbagliato.
 
Se è scritto in C, può darsi. Se è COBOL o RPG (o un qualunque altro linguaggio
che sa come si accede stile database a dati strutturati), allora no. Anzi, è un
discorso poco rispettoso dell'esercito di programmatori che su quella roba ci ha
campato, ci campa e ci camperà ancora per chissà quanto.
 
Il pacchetto dei famosi 17.000 COBOL è fatto tutto così, è in vendita e va per
la maggiore. Fai tu :) E ho visto con i miei occhi programmi di quel pacchetto
macinarsi tabelle da 70 milioni di record (che non saranno tanti tanti, ma non
sono neppure pochi pochi) a forza di READ, WRITE e REWRITE dirette.
 
Se poi appunto in C non ci sono le primitive per accedere a dati strutturati, ma
solo fread() e fwrite() con cui al massimo puoi manipolare un primitivo e banale
PIPPO.TXT, allora è un problema dello strumento (e in quel caso il programma non
andrebbe migrato, non perché non si possa, ma perché è un crimine farlo).
 
Come dicevo, se vuoi/devi migrare a Unix un sistema come quello detto sopra - e
attento: migrare, mi-gra-re, non riscrivere da capo - allora dovrai trovare il
modo di rendere quei programmi compatibili con il nuovo ambiente e specularmente
il nuovo ambiente compatibile con quei programmi.
 
* FINE * La mail cui faccio riferimento nel testo la invierò appena riesco. :)
 
G.

 
http://en.wikipedia.org/wiki/Nuclear_power_in_Canada
 
 
(notare la locazione dei reattori....)
 
Saluti,
dott. Piergiorgio.
 
 

 (notare la locazione dei reattori....)
 
Alzo la mano perchï¿½ non l'ho capita (forse perchï¿½ non ho seguito il thread).

 il nuovo ambiente compatibile con quei programmi.
 
Migrare è anche riscrivere, se si produce lo stesso risultato.
Perché quello che conta è il risultato che un programma o ecosistema di programmi produce.
Poi come venga fatto conta fino ad un certo punto (la cosa principale, è che il sistema sia esatto e veloce)
 
Se i 17000 programmi sono un ecosistema, se ne possono sostituire alcuni con altri dalle stesse funzioni.
Basta scrivere un test che deve dare esito identico sul vecchio e sul nuovo programma.
Se invece i 17000 programmi non sono un ecosistema ma un monolito... sarà impossibile.
 
Ora è evidente che ragioniamo su sistemi di diversi ordini di grandezza.
Non tutte le aziende d'Italia usano programmi personalizzati da 17000 procedure.
Ci sono anche aziende che usano programmi più piccoli.
E molto di questo è standard, cioé il magazzino è magazzino per tutti, la contabilità pure.
Non è che un programma scritto in COBOL che fa magazzino non si possa riscrivere e stesso discorso per la contabilità, la produzione, ecc...
Per fortuna si può fare, almeno c'è più lavoro per i programmatori :)
 
Ciao!
gl

 nello scanner per poterla inviare in email :)
 
No dài, questo non lo fa neppure il mio cliente più piccolo e più sgarruppato,
quello col braccino così corto che non pagherebbe per uno spillo in più.
 
Bon. Ti mando la mail e poi torno a studiarmi come modificare i file di avvio di
un'installazione di TOPS-20 che ho ferma da tempo. :)
 
Ciao,
G.
 

 un'installazione di TOPS-20 che ho ferma da tempo. :)
 
Ti invidio di brutto. :)
Io vorrei tornare all'installazione del 2.11BSD sul PDP11, ma penso che prima di natale non ci riuscirò...
 
Ciao!
gl

 Ti invidio di brutto. :)
 
Eh, dovrò pur fare qualcosa per svagarmi mentre mi passa l'influenza, no? :)
 
Ve' che meraviglia: relink del monitor (il kernel): 
http://dpaste.com/08HG0Z7
 
 
Ciao,
G.
 

 schedone "blindate" a libro. Esempio a caso: 
http://goo.gl/h0L9rl
 
 
Credevo che i modelli su schede/bus proprietario fossero tutti CISC, di nuovo, sbagliando.
 
Ciao!
gl

On Tue, 14 Oct 2014 12:41:35 -0700, Gianluca Bonetti wrote:
 
#SPD Token Ring
http://tinyurl.com/l3332fb
 
 
#2723
http://tinyurl.com/ol6jop3
 
 
#2738
http://tinyurl.com/kpc4mmh
 

 Credevo che i modelli su schede/bus proprietario fossero tutti CISC
 
Eh no, ce ne sono stati tanti RISC e soprattutto l'IBM ha continuato (e credo
continui tuttora) a supportare quel bus – anche quando le macchine erano già
tutte da un pezzo solo PCI – per mezzo di appositi armadi con dentro almeno un
paio di backplane SPD, collegati all'unità centrale via HSL (High Speed Link,
proprietario, ottico, a 1063 Mbit/s), in modo da poter continuare a usare le
vecchie schede proprietarie SPD preservandole dalla svalutazione.
 
Vedi 
https://publib.boulder.ibm.com/iseries/v5r1/ic2924/books/c4154142.pdf
 
 
Credo anzi che una versione simile (ma non identica) di quel bus sia stata
utilizzata per parecchio tempo anche in ambito mainframe, forse pure per un
periodo più esteso di quanto sia stato fatto per il mondo OS/400.
 
Era un bel bus l'SPD, proprio da backplane, con le schede a fare da "jumper" fra
il bus vero e proprio e il connettore locale dello slot, per esempio nel caso
degli storage controller, i quali infatti dovevano essere inseriti in slot ben
precisi in modo che entrambi i connettori sul retro della scheda avessero una
corrispondenza, quello superiore col bus e quello inferiore con la "testa" del
flat che poi andava al backplane dietro le slitte dei dischi. :)
 
Ciao, :)
G.
 
 
P.S. Se continuiamo qui, cambiamo topic? :P

 
http://tinyurl.com/ol6jop3
 
 
Dai, regalagliela :)
 
Tra l'altro, con Sadness, molto tempo fa si era scoperto che era identica a una
scheda per PC (se non ricordo male) e che la differenza stava evidentemente
tutta nel firware. Avevamo provato a metterne una da PC in un 150, ma non gli
piaceva perché la riconosceva come estranea (device di tipo UNK)...
 
G.