OpenVMS nativo su x86

[G.]

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.

[Alessandro Mazzini]

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

[Gianluca Bonetti]

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

[dottor Piergiorgio M. d' Errico]

Il 05/08/2014 10:12, Gianluca Bonetti ha scritto:

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

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.

[Gianluca Bonetti]

Il giorno martedì 5 agosto 2014 10:28:23 UTC+2, dottor Piergiorgio M. d' Errico ha scritto:
> organizzazione interna ed organigramma ? un azienda IT raccoglie
> successi quando ha ottimi ingegneri e un management che non interferisce
> col lavoro di R&S....

Una azienda IT raccoglie successi quando vende e incassa molto... :)

Ciao
gl

[G.]

On Tue, 5 Aug 2014 01:12:43 -0700 (PDT), Gianluca Bonetti <g...@decadence.it>
wrote:

> La notizia non � proprio retro visto che parla della v.next :)

Vero, ma poich� il venerabile VMS � praticamente un fossile vivente, mi pareva
potesse essere pertinente con lo scopo di questo NG; non meno dei messaggi di
chi propone per lo scambio o la vendita desktop Pentium o parti di ricambio PC.

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

Vero anche questo, e anche io in effetti forse sarei capace, ma la differenza
tra noi e loro sono gli investimenti e i progetti per il futuro, tant'� vero che
loro sono riusciti a stringere un accordo con HP, a noi non � nemmeno venuto in
mente (o per lo meno, io una cosa del genere non l'avrei neppure immaginata).

Insomma, non credo che abbiano voluto sollevare tutto 'sto polverone solo per
soddisfare i sogni pi� perversi di quelli che leggono comp.os.vms :) Poi siamo
tutti d'accordo (credo) sul fatto che tra un progetto e la sua realizzazione ci
sia molta differenza, per� intanto il progetto c'� e l'impegno pure. Se hanno
messo in piedi tutta questa operazione (e ci stanno certamente spendendo un bel
po' di soldi) si vede che qualche idea di guadagno ce l'hanno.

Del resto, senti, se � in corso il port su x86 di qualcosa come NSK, che avr�
una base di installato che sar� a dir molto un decimo di quella di VMS, allora �
probabile che ci sia qualche possibilit� anche per VMS :)

> Sicuramente il codice VMS � altamente portabile, lo dimostra il porting da VAX a
> Alpha a Itanium.

In realt� non lo era per niente. Lo � diventato dopo lungo e laborioso lavoro.
Per dire, il 90% era (�) scritto in Macro-32.

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

Non credo sia cos� semplice. I dettagli dell'accordo tra HP e la nuova societ�
non sono stati resi pubblici (e non si sa neppure se lo saranno e/o se c'� un
NDA fra le parti), ma pare assodato che la nuova societ� NON potr� assorbire i
contratti di manutenzione di HP, quindi in particolare tutto quel che riguarda
il grosso parco di installazioni ancora su Alpha.

La cessione riguarda i sorgenti di VMS per Itanium. Si tratta di qualcosa di
abbastanza simile a quello che successe tra Digital e Mentec ai tempi della
cessione a quest'ultima di vari diritti di sviluppo per il software per PDP-11.

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

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.

[G.]

On Tue, 05 Aug 2014 10:28:23 +0200, "dottor Piergiorgio M. d' Errico"
<chied...@ask.me> wrote:

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

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.

[mr]

On Tuesday, August 5, 2014 4:25:58 PM UTC+2, G. wrote:

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

[G.]

On Tue, 5 Aug 2014 08:23:58 -0700 (PDT), mr <m.ri...@gmail.com> wrote:

> > 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 :-)

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.

[Gianluca Bonetti]

Il giorno martedì 5 agosto 2014 16:25:58 UTC+2, G. ha scritto:
> > La notizia non � proprio retro visto che parla della v.next :)
>
> Vero, ma poich� il venerabile VMS � praticamente un fossile vivente, mi pareva
> potesse essere pertinente con lo scopo di questo NG; non meno dei messaggi di
> chi propone per lo scambio o la vendita desktop Pentium o parti di ricambio PC.

Ma si, certo! :)
La mia era una battuta per arrivare al "science fiction" ovvero alla impossibilità (secondo mio modesto parere) di far decollare il progetto x86.
Per il resto, credo che in lingua italiana, solo su questo NG se ne possa discutere.

> > molta strada, e infatti nessuna data specificata. Non voglio fare il
> > guastafeste, ma fino a scrivere una roadmap, ci riuscivo anche io...
>
> Vero anche questo, e anche io in effetti forse sarei capace, ma la differenza
> tra noi e loro sono gli investimenti e i progetti per il futuro, tant'� vero che
> loro sono riusciti a stringere un accordo con HP, a noi non � nemmeno venuto in
> mente (o per lo meno, io una cosa del genere non l'avrei neppure immaginata).

Stringere un accordo... Mah... Quid prodest?
HP aveva detto ai clienti che avrebbe fatto supporto fino al 2020 (o 2018?) e potrebbe invece sbolognare tutto ad un gruppo di zeloti incalliti che ci metteranno l'anima e il cuore nel far decollare il progetto.
Tutti i clienti passano a VSI, e quando VSI va in bancarotta, HP ormai non ha più nessuna responsabilità.

> Insomma, non credo che abbiano voluto sollevare tutto 'sto polverone solo per
> soddisfare i sogni pi� perversi di quelli che leggono comp.os.vms :) Poi siamo
> tutti d'accordo (credo) sul fatto che tra un progetto e la sua realizzazione ci
> sia molta differenza, per� intanto il progetto c'� e l'impegno pure. Se hanno
> messo in piedi tutta questa operazione (e ci stanno certamente spendendo un bel
> po' di soldi) si vede che qualche idea di guadagno ce l'hanno.

L'effetto "troppo bello per essere vero", c'è.
In particolare quando parlano di dynamic translator.
E poi quando leggo la parola "desktop"... beh... dai... non è credibile...

> Del resto, senti, se � in corso il port su x86 di qualcosa come NSK, che avr�
> una base di installato che sar� a dir molto un decimo di quella di VMS, allora �
> probabile che ci sia qualche possibilit� anche per VMS :)

Si ma NSK HP se lo tiene.
Mentre VMS lo cede.
Che HP non abbia mai considerato VMS un prodotto da mantenere, o un prodotto tale da generare utili significativi, è chiaro.
Poi può essere giusto o sbagliato, ma è evidente che il management di HP la pensa così da sempre e continua a farlo nonostante i cambi al vertice.
Oppure semplicemente una guerra di religione: VMS e Tru64 sono OS non originari di HP, quindi vanno estirpati o ceduti.
NSK in realtà proviene da Tandem Computers, quindi non è originario di Digital, non ha questa colpa congenita.

> > Sicuramente il codice VMS � altamente portabile, lo dimostra il porting da VAX a
> > Alpha a Itanium.
>
> In realt� non lo era per niente. Lo � diventato dopo lungo e laborioso lavoro.
> Per dire, il 90% era (�) scritto in Macro-32.

Si, si, ne avevo sentito parlare.
Dicevo comunque che *adesso* il codice dovrebbe essere altamente portabile vista la triplice architettura.
(Su VAX la 8.x non c'è, ma solo perché non è stata rilasciata, non è detto che a livello di sviluppo non sia stata tentata e implementata)

> Non credo sia cos� semplice. I dettagli dell'accordo tra HP e la nuova societ�
> non sono stati resi pubblici (e non si sa neppure se lo saranno e/o se c'� un

> NDA fra le parti), ma pare assodato che la nuova societ� NON potr� assorbire > contratti di manutenzione di HP, quindi in particolare tutto quel che riguarda

> il grosso parco di installazioni ancora su Alpha.

Perché assodato?
E' vero che i dettagli non sono noti, ma io credo proprio che HP voglia smettere di occuparsi proprio di tutto ciò che resta di VMS.
Magari semplicemente i clienti saranno invogliati implicitamente a passare al supporto di VSI, per il semplice fatto che loro si che vogliono bene a VMS!

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

Vabbè il retrocomputing, ma questo discorso che Linux non è enterprise-class è datato :)
Basta vedere top500.org ... almeno fino alla 30-esima posizione sono tutti computer Linux.
A livelli più umani, ma pur sempre enterprise class, ormai direi che l'orientamento è per il clustering a livello applicativo, non di sistema operativo, basta vedere quanti sono e chi è in questa lista http://wiki.apache.org/hadoop/PoweredBy

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

C'è questa leggenda, ma poi non si sa quale operatore, e in che paese.
Quindi... leggenda rimane.

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

Dipende cosa intendi per mainframe, c'è sia il S390 di IBM che costa un fottio di soldi, che un sistema fatto di 10 rack di economici server x86 che eroga applicazioni AJAX.
Oppure il mainframe è in rete, vedi Amazon S3, Google App Engine, Heroku e altri 10 nomi che ora non mi vengono in mente.

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

Temo che il fuggi fuggi dal proprietario non sia terminato.
Purtroppo avere una unica alternativa non è mai una buona situazione.
Chi sviluppa software su VMS dovrebbe, se non lo ha già fatto, iniziare a valutare la migrazione altrove, perché di alternative ce ne sono e diverse.

> Comunque VMS non � single system image.

Mi fidavo della wikipedia... :)
http://en.wikipedia.org/wiki/Single_system_image

Ciao!
gl

[dottor Piergiorgio M. d' Errico]

Il 05/08/2014 18:31, G. ha scritto:
> On Tue, 5 Aug 2014 08:23:58 -0700 (PDT), mr <m.ri...@gmail.com> wrote:
>

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

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.

[G.]

On Tue, 5 Aug 2014 10:56:46 -0700 (PDT), Gianluca Bonetti <g...@decadence.it>
wrote:

> > Vero anche questo, e anche io in effetti forse sarei capace, ma la differenza

> > tra noi e loro sono gli investimenti e i progetti per il futuro, tant'è vero che
> > loro sono riusciti a stringere un accordo con HP, a noi non è nemmeno venuto in

> > mente (o per lo meno, io una cosa del genere non l'avrei neppure immaginata).
>
> Stringere un accordo... Mah... Quid prodest?
>
> HP aveva detto ai clienti che avrebbe fatto supporto fino al 2020 (o 2018?) e
> potrebbe invece sbolognare tutto ad un gruppo di zeloti incalliti che ci
> metteranno l'anima e il cuore nel far decollare il progetto. Tutti i clienti
> passano a VSI, e quando VSI va in bancarotta, HP ormai non ha più nessuna
> responsabilità.

Io ho capito che HP continuerà ad avere la responsabilità di tutto il parco
macchine e software già installato e sarà ben vincolata a quello (com'è già
successo per la causa che ha perso contro Oracle). I clienti si sposteranno da
una all'altra società quando avranno garanzie per loro adeguate e/o quando
decideranno di comprare nuove licenze da VSI per una delle sue nuove relase.

Come prima cosa VSI si impegna a rilasciare il supporto per i nuovi processori
Itanium entro circa sei mesi (da ora?). Visto l'ambiente in cui si propongono di
operare, suppongo che prima di fare affermazioni così "rischiose" avranno fatto
bene i loro calcoli: mancare il primo appuntamento potrebbe essere disastroso.

Per quanto riguarda il farcela, considerando il gruppo di pezzi da 90 che hanno
messo insieme, non avrei troppi dubbi in proposito. Se poi andiamo a considerare
a quale livello è ora il supporto di VMS (gli indiani hanno fatto disastri pure
con la gestione delle patch), non sarà molto difficile fare meglio. Per gli
update di VMS 8.4 su Itanium non dovrebbero esserci grosse soprese (o almeno non
negative); invece il discorso x86 è ovviamente tutto da vedere e valutare.

Se cerchi "win-win" fra i post di comp.os.vms, troverai un sacco di elaborate
dissertazioni sul perché questa mossa, in questo preciso momento, convenga a
tutti: HP, VSI, clienti, investitori, etc. Insomma, lo fanno per soldi, non per
la gloria, e neppure per la sempiterna gratitudine di un branco di vecchi
brontoloni in pensione che scrivono su comp.os.vms. Ribadisco: sono opinioni che
possono essere più o meno condivisibili, però il dato di fatto è che c'è della
gente che ha investito dei soldi (e non pochi, credo) in questa faccenda.
È un azzardo, senza dubbio, come tutte le start-up, specialmente se intendono
percorrere strade poco battute, ma è un azzardo ben calcolato, si spera.

Quindi, in base alle suddette opinioni, ecco cui prodest: prodest a tutti. :)

> L'effetto "troppo bello per essere vero", c'è. In particolare quando parlano
> di dynamic translator.

Se ti riferisci alla traduzione dei binari Itanium in binari x86, non mi farebbe
troppa meraviglia, visto che sarebbe la terza volta che lo fanno (vedi i tool
VEST e AEST per il passaggio VAX-Alpha e Alpha-Itanium). E s'è per quello anche
l'IBM l'ha fatto almeno due volte: prima nel passaggio da S/38 ad AS/400 CISC, e
poi nel passaggio da CISC a RISC (e dietro le quinte l'ha più o meno fatto anche
qualche altra volta, nel passaggio da certe versioni di Power ad altre).

Non ho mai studiato/capito come funzionino esattamente VEST e AEST, ma credo che
si basino proprio su una tecnologia mista statica e dinamica insieme.

Se invece ti riferisci a qualcos'altro, allora mi manca completamente un pezzo.

> E poi quando leggo la parola "desktop"... beh... dai... non è credibile...

Be', sai, una volta che sei su x86, puoi fare un po' quel che ti pare. Molto
probabilmente (ammettendo che facciano il port) sarà VM-aware, quindi si potrà
installare dentro le VM più diffuse e via...

Che poi abbia senso è tutto un altro paio di maniche, visto e considerato quanto
sia carente VMS come strumenti per un uso desktop moderno. anzi, diciamo meglio:
visto e considerato che VMS non ha proprio nulla per il desktop che vada oltre
il vecchio CDE ormai vecchio più di vent'anni.

> Si ma NSK HP se lo tiene.

Non credo sia molto contenta, sai? Credo che sia stata costretta suo malgrado da
qualche corposa causa legale in cui forse si è pure infognata da sola: mi pare
di aver letto che avessero promesso ai clienti NSK moltissimi anni di supporto,
poi quando è stato evidente che con Itanium non si andava da nessuna parte si
sono dovuti arrendere all'idea di fare il port, perché probabilmente gli costa
meno dei rimborsi e delle nuove cause che gli potrebbero intentare i clienti.

Del resto HP è anche stata costretta da Oracle (via tribunale) a mantenere il
supporto di VMS per più tempo di quel che voleva, sempre a causa di promesse
fatte e poi dimenticate (il management HP negli ultimi anni non ha brillato per
acume e lungimiranza), mentre Oracle a sua volta è costretta da accordi con la
Digital (!), antichi ma ancora in vigore, a mantenere RDB (credo anche per VAX)
e DBMS che non è neppure un DB relazionale e che risale ai tempi di DBMS-10.

Tutta roba che se potessero avrebbero probabilmente già buttato da un pezzo.

L'unica cosa che HP è davvero riuscita ad ammazzare senza tanti complimenti è
MPE, il suo sistema operativo proprietario per HP 3000. Purtroppo la base
installata era piuttosto ridotta sia nei numeri sia nelle dimensioni dei singoli
e quindi non c'è stata forza contrattuale sufficiente per salvarlo. Gli utenti
si sono disperati e hanno cercato di fare lobbying, ma non ce l'hanno fatta.

Pure HP-UX se lo stanno trascinando dietro tipo palla al piede, nonostante sia
uno Unix, il che permetterebbe di rimpiazzarlo abbastanza agevolmente con un
qualsiasi altro. Con l'aggravio della concorrenza fortissima che HP-UX subisce
da Linux e da altri Unix. Ma evidentemente ci sono problemi legali e formali
(certificazioni e quant'altro) che ne impediscono la dipartita definitiva.

> > ma pare assodato che la nuova società NON potrà assorbire contratti di

> > manutenzione di HP, quindi in particolare tutto quel che riguarda il grosso
> > parco di installazioni ancora su Alpha.
>
> Perché assodato? E' vero che i dettagli non sono noti, ma io credo proprio che
> HP voglia smettere di occuparsi proprio di tutto ciò che resta di VMS.

Assodato (pare!) perché è quanto sta emergendo in questi giorni man mano che
vengono delineate le caratteristiche della nuova società e i suoi legami con HP.
Che quest'ultima voglia liberarsi di VMS è chiarissimo (altrimenti non avrebbe
ceduto i diritti e prima di questo non avrebbe fatto fuori tutto il team di
sviluppo e spostato quel che rimaneva del supporto in India). Però per un po' di
anni da una parte sarà obbligata dai contratti che ha sottoscritto e dall'altra
cercherà di mungere la mucca finché ancora dà latte residuo.

> Magari semplicemente i clienti saranno invogliati implicitamente a passare al
> supporto di VSI, per il semplice fatto che loro si che vogliono bene a VMS!

Eh, ma questi sono ragionamenti che fa il sistemista innamorato. Già è ben più
difficile che li faccia il responsabile dell'infrastruttura IT, figurati poi chi
deve aprire i cordoni della borsa: quelli spesso non distinguono un PC da un
server e per loro Windows, Linux, VMS, MVS, etc. sono un nulla indistinto. Loro
vanno dove c'è la convenienza economica, diretta (costa meno) e indiretta (posso
evitare il costo della migrazione e/o lo posso ammortizzare su più anni di
quanto avevo preventivato perché qualcuno ha deciso di continuare il supporto).

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

>
> Vabbè il retrocomputing, ma questo discorso che Linux non è enterprise-class è datato :)
> Basta vedere top500.org ... almeno fino alla 30-esima posizione sono tutti computer Linux.

Ma quella non è roba enterprise. Quello è supercomputing a livelli altissimi,
che è un'altra cosa. Io intendo banche, assicurazioni, ministeri, INPS, Agenzia
delle entrate, etc. Tutte "cose" dove la potenza di calcolo pura non è il
principale indice di performance perché sono tutti ambiti in cui i calcoli
spicci sono piuttosto semplici e neppure in virgola mobile. Forse giusto il
calcolo delle tabelle attuariali è matematicamente un pochino più impegnativo.

Poi non dico che non si possa fare anche con Linux, eh! Anzi. Ma si parlava di
performance da diversi punti di vista: se hai bisogno di NSK probabilmente
lavori in un abito in cui ti interessa di più che il sistema non si fermi MAI
piuttosto che la velocità con cui ti dà la risposta. E anche Linux lo può fare,
lo so già, ma oltre alla resistenza al cambiamento, in certi ambiti c'è anche
una certa prudenza e diffidenza con cui bisogna convivere.

Cioè, in altre parole: in un campo arato ha performance migliori un vecchio
trattore cingolato che fa al massimo 4 km/h di una Ferrari che ne fa 300. :)
Ovvero: anche il concetto di performance è relativo. Non si può sempre tirare
fuori la batteria di macchine Linux economiche e configurate in un certo modo,
perché in certi casi magari (magari!) non è il setup più adatto, per mille
motivi. Non fosse altro per l'enorme quantità di software super-collaudato che
non si può sostiture a cuor leggero, magari anche "solo" perché il costo della
migrazione (se non della riscrittura) sarebbe più alto del risparmio dato dal
passaggio ad una architettura più recente e/o open source.

Leggo spesso, in ambito USA, di installazioni "certificate", addirittura di
release certificate, di compilatori certificati e di applicativi certificati.
Non so cosa significhi esattamente, ma da quel che capisco, per molti di coloro
che ne parlano, questa faccenda delle certificazioni è preponderante. Quindi nel
loro caso magari continuano imperterriti finché possono a causa di vincoli di
questo tipo. Roba brutta: tipo assicurazioni che non pagano il danno causato da
eventuale downtime se si scopre che sul sistema c'era software non certificato,
a prescindere dal fatto che il downtime sia stato causato da quel software.

> A livelli più umani, ma pur sempre enterprise class, ormai direi che
> l'orientamento è per il clustering a livello applicativo, non di sistema
> operativo, basta vedere quanti sono e chi è in questa lista
> http://wiki.apache.org/hadoop/PoweredBy

Sì, ma anche qui dipende dalle applicazioni. Per esempio, in tutto l'elenco non
ricorrono mai termini come "general ledger", "accounts payable" e "accounts
receivable", cioè i termini inglesi per le basi della gestione contabile.

Stiamo parlando di cose non paragonabili. VMS (e con lui diversi altri) hanno
funzioni di back-end che non hanno nulla a che fare con Hadoop, e viceversa. Si
parla di transazioni finanziarie (che non sono gli acquisti via internet) cioè
flussi di dati in formato standard tra enti commerciali. Guarda per esempio lo
standard ISO 8583. Insomma, sono cose complementari: quello che fa Hadoop non fa
VMS o un OS IBM (o meglio: non è concepito per farlo) e viceversa.

Per dire: immagino che una banca o un'istituzione analoga potrà utilizzare
Hadoop per gestire la parte web (pensa al classico home banking che ormai hanno
anche le banche più insignificanti), ma poi il back-end è tutto altrove, magari
(anzi, spesso) sul solito, classico, "vecchio" 390 IBM.

Altro esempio di cui si parlava qualche giorno fa in IRC (e che a me non era
neanche venuto in mente): nel mondo Unix in generale non esiste il concetto di
elaborazione batch, al massimo c'è il background con nohup ed '&', ma non è
affatto la stessa cosa, per esempio perché non permette l'accesso serializzato
alle risorse hardware e software, soprattutto per elaborazioni pesanti o lunghe.

Viceversa Unix ha processi molto leggeri, che "nascono" in brevissimo tempo e
sono facilmente spendibili, cosa che lo rende molto adatto a rispondere in
maniera efficace alle richieste provenienti via rete e ai carichi non uniformi.

> > è 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.
>
> Dipende cosa intendi per mainframe, c'è sia il S390 di IBM che costa un fottio
> di soldi, che un sistema fatto di 10 rack di economici server x86 che eroga
> applicazioni AJAX. Oppure il mainframe è in rete, vedi Amazon S3, Google App
> Engine, Heroku e altri 10 nomi che ora non mi vengono in mente.

No, su questo dissento. :) Mainframe è solo il 390 IBM. Dice Wikipedia (per quel
che può valere) che per oltre il 90% dei casi, quando si parla di mainframe si
intende il mostro IBM, il quale, come detto sopra, fornisce servizi diversi dal
gruppo di server x86 che erogano applicazioni AJAX. È di nuovo il discorso del
trattore e della Ferrari: ambiti diversi, necessità diverse, strumenti diversi.

> > Comunque VMS non è single system image.

>
> Mi fidavo della wikipedia... :)
> 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.

[Gianluca Bonetti]

Il giorno domenica 10 agosto 2014 18:26:23 UTC+2, G. ha scritto:
> Io ho capito che HP continuerà ad avere la responsabilità di tutto il parco
> macchine e software già installato e sarà ben vincolata a quello (com'è già
> successo per la causa che ha perso contro Oracle). I clienti si sposteranno da
> una all'altra società quando avranno garanzie per loro adeguate e/o quando
> decideranno di comprare nuove licenze da VSI per una delle sue nuove relase.

Dunque, HP ha sicuramente contratti scritti, anche bene, con i clienti.
Tipicamente, l'azienda più grossa fa contratti a suo vantaggio, ma se c'è una cosa su cui non può barare, è la durata del contratto
Quindi se dice "ti supporto fino al 2020", è così, ti supporto fino al 2020, oppure ti invoglio a cambiare fornitore, se una alternativa esiste.

Sul discorso HP-Oracle non mi sembra che sia andata così... oppure è un'altra causa quella a cui ti riferisci.
Oracle che cessò il rilascio di nuove release ai clienti con regolare contratto, su hardware Itanium; quindi HP fece causa ad Oracle, vincendo.
Alla fine Oracle fu vincolata a fare nuove release del software da distribuire ai clienti HP su Itanium, finché HP farà nuovo hardware Itanium
http://arstechnica.com/information-technology/2012/08/hp-wins-judgement-in-itanium-suit-against-oracle/

> Come prima cosa VSI si impegna a rilasciare il supporto per i nuovi processori
> Itanium entro circa sei mesi (da ora?). Visto l'ambiente in cui si propongono di
> operare, suppongo che prima di fare affermazioni così "rischiose" avranno fatto
> bene i loro calcoli: mancare il primo appuntamento potrebbe essere disastroso.

Sarò noioso... ma sarà così difficile rilasciare supporto ai nuovi processori IA64?
Sono come quelli vecchi, solo con più MHz, più cache, e qualche istruzione ottimizzata in più.
Probabilmente ci sono solo un po' di if-then-else che in caso di CPU non riconosciuta bloccano la sequenza di boot.
Per i MHz e la cache, l'ottimizzazione vien da sè.
Per le istruzioni ottimizzate in più, magari se usate rendono un 20% in più.
Se non usate... beh pazienza... basteranno MHz e cache!
Probabilmente questa release arriverà anche con largo anticipo sulle scadenze, per dare fiducia, ma da supportare una nuova CPU della stessa architettura a supportare una nuova architettura...

> Per quanto riguarda il farcela, considerando il gruppo di pezzi da 90 che hanno
> messo insieme, non avrei troppi dubbi in proposito. Se poi andiamo a considerare
> a quale livello è ora il supporto di VMS (gli indiani hanno fatto disastri pure
> con la gestione delle patch), non sarà molto difficile fare meglio. Per gli
> update di VMS 8.4 su Itanium non dovrebbero esserci grosse soprese (o almeno non
> negative); invece il discorso x86 è ovviamente tutto da vedere e valutare.

Pezzi da 90 o anche più... spero che riescano a tenere il passo coi tempi!
Sicuramente sono più bravi di me che ora sparo giudizi avventati, ma ci sono nuove generazioni di programmatori altamente motivati, intellettualmente superdotati, che lavorano su altri sistemi che erodono ogni giorno il mercato VMS, quello che è rimasto.
Inoltre la storia ci insegna che non basta avere il miglior team tecnico per avere successo.
Lo stesso Ken Olsen era convinto che i buoni prodotti si sarebbero venduti da soli, ma non è così.
Specialmente oggi poi tutti i produttori devono generare profitto (persino IBM non è in buone acque, da quel che leggo, alcuni ipotizzano un crollo tra 2-3 anni)

> Se cerchi "win-win" fra i post di comp.os.vms, troverai un sacco di elaborate
> dissertazioni sul perché questa mossa, in questo preciso momento, convenga a
> tutti: HP, VSI, clienti, investitori, etc. Insomma, lo fanno per soldi, non per
> la gloria, e neppure per la sempiterna gratitudine di un branco di vecchi
> brontoloni in pensione che scrivono su comp.os.vms. Ribadisco: sono opinioni che
> possono essere più o meno condivisibili, però il dato di fatto è che c'è della
> gente che ha investito dei soldi (e non pochi, credo) in questa faccenda.

In questo caso l'ipotesi win-win è una speranza bella, ma potrebbe essere un bel miraggio.
Potrebbe essere una VSI-trap, con tutto il team VSI in buona fede, si intende.
Pensa, HP spende che ne so 200 mln / anno per tenere VMS attivo.
Decide di investire, una tantum 100 mln in VSI, magari in questa cifra 50 mln sono il valore del source code VMS, quindi alla fine sganciano 50 mln (sono sempre cifre sparate)
E' vero che muovono un valore di 100 mln adesso, ma nel lungo periodo risparmieranno... sia che VMS viva, o che muoia... e la responsabilità sarà di VSI, con contratti nuovi/scadenze nuove, non di HP, con contratti vecchi/scadenza 2020.

> È un azzardo, senza dubbio, come tutte le start-up, specialmente se intendono
> percorrere strade poco battute, ma è un azzardo ben calcolato, si spera.

Però mi sembra azzardato paragonare ad una startup ad un team di pezzi da 90 che lavora con la metodologia degli anni 80 in cui il budget era illimitato, i tempi erano biblici (vedi tutti i progetti naufragati per troppo tempo tipo DEC Prism) e a tutti andava bene perché c'era grasso che colava ovunque.

> Quindi, in base alle suddette opinioni, ecco cui prodest: prodest a tutti. :)

Lo spero sicuramente... per tutti e perché comunque VMS mi sta simpatico.
Non lo comprendo (I'm a unix man), non lo comprenderò mai, ma mi sta simpatico :)

> > L'effetto "troppo bello per essere vero", c'è. In particolare quando parlano
> > di dynamic translator.

> Se ti riferisci alla traduzione dei binari Itanium in binari x86, non mi farebbe
> troppa meraviglia, visto che sarebbe la terza volta che lo fanno (vedi i tool
> VEST e AEST per il passaggio VAX-Alpha e Alpha-Itanium). E s'è per quello anche
> l'IBM l'ha fatto almeno due volte: prima nel passaggio da S/38 ad AS/400 CISC, e
> poi nel passaggio da CISC a RISC (e dietro le quinte l'ha più o meno fatto anche
> qualche altra volta, nel passaggio da certe versioni di Power ad altre).

Certamente fattibile, chi lo nega, specialmente conoscendo a fondo le specifiche di tutti gli eseguibili, del SO sottostante e delle CPU.

> Non ho mai studiato/capito come funzionino esattamente VEST e AEST, ma credo che
> si basino proprio su una tecnologia mista statica e dinamica insieme.
>
> Se invece ti riferisci a qualcos'altro, allora mi manca completamente un pezzo.

Se non sbaglio VEST genera un eseguibile in un wrapper che esegue il codice VAX. Lavorando a livello di emulazione chiamate OS e non a livello di emulazione CPU, oppure un mix, è sicuramente più performante di quanto puoi ottenere con un emulatore VM più complesso.

Da qualche parte hanno citato anche FX!32
FX!32 eseguiva codice win32-x86 su win64-Alpha, sfruttando il sistema di emulazione x86 di base degli Alpha, lo stesso che permette l'uso di schede PCI con ROM x86 come schede video e SCSI.

La versione per Linux di FX!32 si chiamava em86 e condivideva buona parte del codice e ai tempi che si installava su Linux (ormai le librerie sono datate, ininstallabili, sempre che siano ancora reperibili), io l'avevo provato sulla PWS500, e non funzionava...
Certo, se il sistema funziona, su release specifiche, col supporto adatto, tutto si può fare.

> > E poi quando leggo la parola "desktop"... beh... dai... non è credibile...
>
> Be', sai, una volta che sei su x86, puoi fare un po' quel che ti pare. Molto
> probabilmente (ammettendo che facciano il port) sarà VM-aware, quindi si potrà
> installare dentro le VM più diffuse e via...

Ah beh, allora sarà un VMS in Linux, con desktop Gnome, ecc...
Comunque si, la strada più facile per andare su x86 è passare per la macchina virtuale togliendosi l'onere dei driver.
Questo aprirebbe però la strada ad hardware non HP, vedi MacOS X / Hackintosh.

> > Si ma NSK HP se lo tiene.
>
> Non credo sia molto contenta, sai? Credo che sia stata costretta suo malgrado da
> qualche corposa causa legale in cui forse si è pure infognata da sola: mi pare
> di aver letto che avessero promesso ai clienti NSK moltissimi anni di supporto,
> poi quando è stato evidente che con Itanium non si andava da nessuna parte si
> sono dovuti arrendere all'idea di fare il port, perché probabilmente gli costa
> meno dei rimborsi e delle nuove cause che gli potrebbero intentare i clienti.

Non conosco affatto le vicende NSK, quindi ho seguito solo la sensazione che se lo tengono, i vantaggi siano maggiori degli svantaggi.
Probabilmente il vantaggio è solo di non farsi fare causa dai clienti con contratto attivo.

> Del resto HP è anche stata costretta da Oracle (via tribunale) a mantenere il
> supporto di VMS per più tempo di quel che voleva, sempre a causa di promesse
> fatte e poi dimenticate (il management HP negli ultimi anni non ha brillato per
> acume e lungimiranza), mentre Oracle a sua volta è costretta da accordi con la
> Digital (!), antichi ma ancora in vigore, a mantenere RDB (credo anche per VAX)
> e DBMS che non è neppure un DB relazionale e che risale ai tempi di DBMS-10.
>
> Tutta roba che se potessero avrebbero probabilmente già buttato da un pezzo.

RDB vedo che ha ancora un seguito, forse per cose semplici o forse perché se non ho capito male si programma e interfaccia facilmente in DCL.
Il DBMS non relazionale invece potrebbe tornare di moda, vista la tendenza No-SQL! :)

> L'unica cosa che HP è davvero riuscita ad ammazzare senza tanti complimenti è
> MPE, il suo sistema operativo proprietario per HP 3000. Purtroppo la base
> installata era piuttosto ridotta sia nei numeri sia nelle dimensioni dei singoli
> e quindi non c'è stata forza contrattuale sufficiente per salvarlo. Gli utenti
> si sono disperati e hanno cercato di fare lobbying, ma non ce l'hanno fatta.

Forse i contratti erano talmente vecchi, che non c'erano le scadenze, o penali o responsabilità particolari di HP e ne hanno approfittato!

> Pure HP-UX se lo stanno trascinando dietro tipo palla al piede, nonostante sia
> uno Unix, il che permetterebbe di rimpiazzarlo abbastanza agevolmente con un
> qualsiasi altro. Con l'aggravio della concorrenza fortissima che HP-UX subisce
> da Linux e da altri Unix. Ma evidentemente ci sono problemi legali e formali
> (certificazioni e quant'altro) che ne impediscono la dipartita definitiva.

La mia sensazione è che HP sia più affezionata a HP-UX di quanto non sia a VMS e Tru64 (RIP).
Nonostante i cambi di management forse c'è ancora uno zoccolo duro che vuole estirpare dal mondo gli ultimi residui di DEC.

> Assodato (pare!) perché è quanto sta emergendo in questi giorni man mano che
> vengono delineate le caratteristiche della nuova società e i suoi legami con HP.
> Che quest'ultima voglia liberarsi di VMS è chiarissimo (altrimenti non avrebbe
> ceduto i diritti e prima di questo non avrebbe fatto fuori tutto il team di
> sviluppo e spostato quel che rimaneva del supporto in India). Però per un po' di
> anni da una parte sarà obbligata dai contratti che ha sottoscritto e dall'altra
> cercherà di mungere la mucca finché ancora dà latte residuo.

Ah si, in questo è sicuro.
Se un cliente ha un contratto con HP, HP non può dire vai da VSI.
Può invogliare questa migrazione, rispondendo ad esempio ai ticket di assistenza all'ultimo minuto prima del tempo massimo per le penali.
Oppure peggiorando il livello del supporto, mettendo tecnici che parlano peggio l'inglese o centralini configurati male che dopo l'attesa dirottano al supporto amministrativo anziché tecnico...
Ci sono tanti modi...
Sfiduciare, rimanere nei termini per non pagare penali, poi quando restano 500 clienti, una raccomandata che dice "signori, il 90% dei clienti sono andati a VSI, è chiaro che loro lavorano meglio, se volete andare siete liberi di farlo"
Che faranno a quel punto i clienti?

> Eh, ma questi sono ragionamenti che fa il sistemista innamorato. Già è ben più
> difficile che li faccia il responsabile dell'infrastruttura IT, figurati poi chi
> deve aprire i cordoni della borsa: quelli spesso non distinguono un PC da un
> server e per loro Windows, Linux, VMS, MVS, etc. sono un nulla indistinto. Loro
> vanno dove c'è la convenienza economica, diretta (costa meno) e indiretta (posso
> evitare il costo della migrazione e/o lo posso ammortizzare su più anni di
> quanto avevo preventivato perché qualcuno ha deciso di continuare il supporto).

Questo è vero... come probabilmente un contratto di supporto di VSI potrebbe costare meno di uno con HP.
HP potrebbe addirittura fare un accordo segreto con VSI, pagando il 50% o tutto il canone di supporto di un cliente che migra per liberarsene, se effettivamente per HP è un peso VMS e i clienti su di esso.

> Ma quella non è roba enterprise. Quello è supercomputing a livelli altissimi,
> che è un'altra cosa. Io intendo banche, assicurazioni, ministeri, INPS, Agenzia
> delle entrate, etc. Tutte "cose" dove la potenza di calcolo pura non è il
> principale indice di performance perché sono tutti ambiti in cui i calcoli
> spicci sono piuttosto semplici e neppure in virgola mobile. Forse giusto il
> calcolo delle tabelle attuariali è matematicamente un pochino più impegnativo.

Ok, il famoso discorso di Transaction-Per-Second in cui VMS era al top anni fa.
Ma lo è ancora?
I sistemi x86 sono dannatamente veloci, e a meno che non compri gli scarti come facciamo noi comuni mortali, sono anche affidabili.

> Cioè, in altre parole: in un campo arato ha performance migliori un vecchio
> trattore cingolato che fa al massimo 4 km/h di una Ferrari che ne fa 300. :)

Vero.
Ma tu sai che fanno anche trattori più nuovi, no?
In un periodo in cui il grano si vende in tutto al prezzo delle sementi (verità!) il guadagno sta nel minor tempo che si impiega ad arare,seminare,mietere
Un trattore nuovo costa soldi subito, ma richiede meno manutenzione, meno personale, ricambi più economici, e farò il lavoro in meno tempo.
Come vedi in ogni ambito si può preferire il cambiamento!
O evitarlo, a seconda dei punti di vista!

> Ovvero: anche il concetto di performance è relativo. Non si può sempre tirare
> fuori la batteria di macchine Linux economiche e configurate in un certo modo,
> perché in certi casi magari (magari!) non è il setup più adatto, per mille
> motivi. Non fosse altro per l'enorme quantità di software super-collaudato che
> non si può sostiture a cuor leggero, magari anche "solo" perché il costo della
> migrazione (se non della riscrittura) sarebbe più alto del risparmio dato dal
> passaggio ad una architettura più recente e/o open source.

Tutto dipende anche da come è stato fatto il software in passato.
Se fatto bene e portabile, il costo del passaggio potrebbe essere anche molto basso.
Il cambio generazionale prima o poi bisogna farlo.
Non tutti possono continuare a lavorare come quella segheria del Canada dove vanno avanti con programmi in elettronica cablata per una vecchia fatturatrice IBM...

> Leggo spesso, in ambito USA, di installazioni "certificate", addirittura di
> release certificate, di compilatori certificati e di applicativi certificati.
> Non so cosa significhi esattamente, ma da quel che capisco, per molti di coloro
> che ne parlano, questa faccenda delle certificazioni è preponderante. Quindi nel
> loro caso magari continuano imperterriti finché possono a causa di vincoli di
> questo tipo. Roba brutta: tipo assicurazioni che non pagano il danno causato da
> eventuale downtime se si scopre che sul sistema c'era software non certificato,
> a prescindere dal fatto che il downtime sia stato causato da quel software.

Beh qui il discorso passa ad un altro piano.
Effettivamente il software open source è "provided AS IS" a meno che qualcuno non se ne assuma la responsabilità, che ne so, RedHat.
Forse neanche RedHat se la sente di fare un contratto con l'esercito americano e sostenere gli oneri di tale contratto...

> Sì, ma anche qui dipende dalle applicazioni. Per esempio, in tutto l'elenco non
> ricorrono mai termini come "general ledger", "accounts payable" e "accounts
> receivable", cioè i termini inglesi per le basi della gestione contabile.
>
> Stiamo parlando di cose non paragonabili. VMS (e con lui diversi altri) hanno
> funzioni di back-end che non hanno nulla a che fare con Hadoop, e viceversa. Si
> parla di transazioni finanziarie (che non sono gli acquisti via internet) cioè
> flussi di dati in formato standard tra enti commerciali. Guarda per esempio lo
> standard ISO 8583. Insomma, sono cose complementari: quello che fa Hadoop non fa
> VMS o un OS IBM (o meglio: non è concepito per farlo) e viceversa.

Non conosco questo settore e questi standard, se non per sentito dire.
Però qualunque cosa ancora operativa, anche retaggio del passato, gira su sistemi "general purpose" quindi tutto è fattibile, su qualunque sistema.
Sempre se si fosse senza limiti di budget, però :)

> Per dire: immagino che una banca o un'istituzione analoga potrà utilizzare
> Hadoop per gestire la parte web (pensa al classico home banking che ormai hanno
> anche le banche più insignificanti), ma poi il back-end è tutto altrove, magari
> (anzi, spesso) sul solito, classico, "vecchio" 390 IBM.

Su questo, qualche analista prevede un tracollo di IBM quando queste banche faranno migrazione...

> Altro esempio di cui si parlava qualche giorno fa in IRC (e che a me non era
> neanche venuto in mente): nel mondo Unix in generale non esiste il concetto di
> elaborazione batch, al massimo c'è il background con nohup ed '&', ma non è
> affatto la stessa cosa, per esempio perché non permette l'accesso serializzato
> alle risorse hardware e software, soprattutto per elaborazioni pesanti o lunghe.

Ah ecco... ora inizio a capire io tutto questo interesse per il Java Batch di Java 7 EE, per il quale mi sembrava ci fosse troppa enfasi, inizia ad avere senso.

> No, su questo dissento. :) Mainframe è solo il 390 IBM. Dice Wikipedia (per quel
> che può valere) che per oltre il 90% dei casi, quando si parla di mainframe si
> intende il mostro IBM, il quale, come detto sopra, fornisce servizi diversi dal
> gruppo di server x86 che erogano applicazioni AJAX. È di nuovo il discorso del
> trattore e della Ferrari: ambiti diversi, necessità diverse, strumenti diversi.

Ok, questione di definizione.

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

Ca%%o questa si che è una analisi da manuale!
Dovresti proporla alla Wikipedia per aggiornare la pagina fuorviante! :)
Spero che altri, oltre a me, abbiano letto questa parte della conversazione! :)

> 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

[G.]

On Tue, 12 Aug 2014 04:40:30 -0700 (PDT), Gianluca Bonetti <g...@decadence.it>
wrote:

> Sul discorso HP-Oracle non mi sembra che sia andata così... oppure è un'altra
> causa quella a cui ti riferisci.

Non ci metterei affatto la mano sul fuoco; non sono andato a controllare di
nuovo e quindi può essere benissimo che sia come dici tu. :)

> Sarò noioso... ma sarà così difficile rilasciare supporto ai nuovi processori
> IA64? Sono come quelli vecchi, solo con più MHz, più cache, e qualche istruzione
> ottimizzata in più. Probabilmente ci sono solo un po' di if-then-else che in
> caso di CPU non riconosciuta bloccano la sequenza di boot. Per i MHz e la cache,
> l'ottimizzazione vien da sè. Per le istruzioni ottimizzate in più, magari se
> usate rendono un 20% in più. Se non usate... beh pazienza... basteranno MHz e
> cache! Probabilmente questa release arriverà anche con largo anticipo sulle
> scadenze, per dare fiducia, ma da supportare una nuova CPU della stessa
> architettura a supportare una nuova architettura...

Be', un nuovo processore non è solo un nuovo chip; cambia anche il contorno: non
ho guardato le specifiche esatte, ma posso supporre che ci sia un chipset o
magari qualche controller integrato nella CPU o sulla scheda madre diverso dai
precedenti, etc. Qualunque cosa, anche fosse solo un nuovo chip per il controllo
della temperatura delle CPU, dev'essere supportato. Del resto, l'architettura
VAX è stata la stessa per più di vent'anni, eppure ogni CPU (o famiglia di CPU)
ha le sue routine specializzate – tutte raggruppate in un modulo SYSLOAxxx per
poter fornire un'unica base standard al resto del sistema operativo – e la
stessa cosa vale anche per VMS su Alpha e Itanium. Cosa che poi succede anche in
altri ambiti come il mondo PC, in cui finché non carichi i driver della scheda
madre forniti dal produttore, magari non riesci a mettere il laptop in stand-by.

Per quanto riguarda il "pazienza", non è così che funziona, secondo me: ti
compri la moto nuova, e magari la paghi anche abbastanza, e poi pazienza se il
carburatore non ce la fa o se i rapporti del cambio non sono ottimizzati, tanto
con tutti i centimetri cubi di cilindrata in più rispetto alla precedente va
comunque più veloce, no? Ti piace come idea? :P

Forse "pazienza" lo potresti dire ai comuni mortali (quelli da tua definizione),
i quali a volte sono però quelli che vanno a cercare l'overclock spintissimo, ai
limiti della fusione della CPU, ma non a un'azienda che investe dei soldi su un
aggiornamento hardware e si aspetta di tirarci fuori il meglio (o per lo meno
quello che dicono le specifiche).

Quanto ai tempi, a me sei mesi non sembrano neanche tanti, se si vuole fare una
cosa fatta bene. Può anche darsi che siano stati un po' larghi, giusto per
coprirsi un po' le spalle, ma fare la cresta artificialmente al tempo è una cosa
molto rischiosa: se dico a un cliente che per un lavoro da una giornata ce ne
vogliono sei, è molto probabile che ci creda; ma se lo dico a un collega, o dice
che sono un imbroglione o che sono un incompetente di cui diffidare.

> > È un azzardo, senza dubbio, come tutte le start-up, specialmente se intendono
> > percorrere strade poco battute, ma è un azzardo ben calcolato, si spera.
>
> Però mi sembra azzardato paragonare ad una startup ad un team di pezzi da 90 che
> lavora con la metodologia degli anni 80 in cui il budget era illimitato, i tempi
> erano biblici (vedi tutti i progetti naufragati per troppo tempo tipo DEC Prism)
> e a tutti andava bene perché c'era grasso che colava ovunque.

Non sappiamo come lavorano e non è affatto detto che abbiano una metodologia
anni '80, anzi, ne dubito abbastanza. Conosco un paio di nomi di gente sui 55-60
anni che maneggia java con una competenza che tanti ragazzini (anagraficamente
e/o mentalmente parlando) si sognano. Eppure è gente che ha cominciato con le
schede perforate e con i sistemi in cui UN megabyte di RAM era tanta roba.

[Dynamic translator]

> Certamente fattibile, chi lo nega, specialmente conoscendo a fondo le specifiche
> di tutti gli eseguibili, del SO sottostante e delle CPU.

Lo sapevi, per esempio, che con il port su Itanium hanno deciso di abbandonare
l'architettura binaria proprietaria e passare a ELF? :)

Tra l'altro, il supporto per gli ELF di VMS nel comando 'file' di Linux & co.
l'ho aggiunto io (e non solo quello)...

> RDB vedo che ha ancora un seguito, forse per cose semplici o forse perché se non
> ho capito male si programma e interfaccia facilmente in DCL.

RDB è niente meno che Oracle per VMS. Quindi altro che cose semplici (per quelle
c'è il supporto nativo ai file indicizzati dato dal file system e da RMS). Che
io sappia, RDB si distingue da Oracle standard per la migliore integrazione con
il sistema operativo, visto che è fatto apposta, e perché permette di accedere
al database non solo con SQL, ma anche con il linguaggio proprietario RDO, che è
concettualmente piuttosto simile, ma sintatticamente ben diverso. Se cerchi in
questo NG dovresti trovare (almeno) un mio post con alcuni esempi a confronto.

Da quando RDB è di Oracle ci sono stati parecchi travasi di funzionalità, in
entrambi i sensi. Anni fa rimasi molto stupito quando vidi dentro un Oracle per
Unix alcune tabelle di servizio (?) con dei nomi che gridavano VMS lontano un
miglio. Idem anche per i nomi di alcune costanti utilizzate (credo) nel codice
dei programmi con SQL embedded (non so essere più preciso perché di Oracle non
so praticamente nulla). Immagino sia successo anche l'opposto, da Oracle a RDB.

> Il DBMS non relazionale invece potrebbe tornare di moda, vista la tendenza
> No-SQL! :)

Ho i miei grossi dubbi. Se il Database relazionale è la strada principale, DBMS
(reticolare) è la prima traversa a sinistra, mentre i moderni DB NoSQL sono
dalla seconda a destra in poi... :) Forse, e molto forse, il vecchio DBMS può
somigliare in un certo senso a un DB a grafo. Scrissi qualche post su questo
tipo di DB quando raccontai della mia installazione di DBMS-10 su TOPS-10. :)

> Ok, il famoso discorso di Transaction-Per-Second in cui VMS era al top anni fa.
> Ma lo è ancora? I sistemi x86 sono dannatamente veloci, e a meno che non compri
> gli scarti come facciamo noi comuni mortali, sono anche affidabili.

Non è solo una questione di potenza pura: te la ricordi la pubblicità della
Pirelli che diceva "la potenza è nulla senza controllo", quella con l'immagine
di Carl Lewis con i tacchi a spillo? Ecco.

Non fai che sottolineare la mia tesi: se le macchine x86 sono così dannatamente
veloci, portare VMS su quell'architettura non potrà far altro che bene, dato che
si unirà a un hardware intrinsecamente veloce anche un software fatto apposta
per andare veloce su quel terreno (Carl Lewis, in pista, con le scarpe giuste).

E comunque scrivevo:

> > Ovvero: anche il concetto di performance è relativo. Non si può sempre tirare
> > fuori la batteria di macchine Linux economiche e configurate in un certo modo,
> > perché in certi casi magari (magari!) non è il setup più adatto, per mille
> > motivi. Non fosse altro per l'enorme quantità di software super-collaudato che
> > non si può sostiture a cuor leggero, magari anche "solo" perché il costo della
> > migrazione (se non della riscrittura) sarebbe più alto del risparmio dato dal
> > passaggio ad una architettura più recente e/o open source.
>
> Tutto dipende anche da come è stato fatto il software in passato. Se fatto bene
> e portabile, il costo del passaggio potrebbe essere anche molto basso.

"Fatto bene" e "portabile" non sono necessariamente caratteristiche dello stesso
software. Per esempio, potrebbe esistere software sicurissimo e collaudatissimo
scritto in TPL (linguaggio principe di NonStop) eppure impossibile da migrare
senza riscriverlo da capo, con tutti i costi e i rischi del caso.

Oppure, senza andare troppo lontano, vogliamo parlare dei quintali di programmi
per VMS che fanno uso di RMS o altre caratteristiche specifiche di quel mondo?
Oppure di tutta la roba scritta in Bliss? E di quella in Macro? (Non hai idea, e
non l'avevo neppure io, di quanta roba non low-level ci sia, scritta in Macro.)

Senza considerare che non ci sono solo Cobol e Fortran: per esempio, in questi
giorni in comp.os.vms si è parlato di Basic e su AS/400 va fortissimo l'RPG.

Comunque, anche parlando del solo Cobol (che di solito resiste meglio al tempo e
può essere più facile da migrare) e nonostante il linguaggio in sé sia piuttosto
portabile, diventa quasi impossibile portare un'applicazione scritta in Cobol
(che sia qualcosa di più di un singolo programma) da un ambiente all'altro, non
solo parlando di VMS > Unix. Ovviamente lo stesso discorso si applica anche al C
e al C++ (non vorrei che sembrasse un problema dei soli linguaggi "vecchi") e
vale anche per un ipotetico passaggio S/390 > AS/400, o AS/400 > Unix, o VMS >
AS/400, o VMS > Windows, e così via in tutte le combinazioni possibili.

Per esempio, rimanendo su cose che conosco, la gestione dell'interfaccia utente
di VMS è assolutamente, completamente, irriducibilmente diversa da quella di
OS/400, la quale a sua volta è ugualmente aliena rispetto a quella dei diversi
sistemi operativi per S/390 e delle varie soluzioni Unix (ncurses?). È talmente
diversa che non si tratta solo di cambiare qualche istruzione con 'sed', ma
cambia proprio il paradigma, l'idea, la filosofia...

Poi c'è il discorso dell'interfaccia con il resto del sistema operativo: VMS ha
le procedure DCL, sui mainframe ci sono le specifiche JCL, OS/400 ha i programmi
CLP, Unix gli script Bash. Devo continuare? Ho un cliente, neppure grosso, che
ne ha circa 1.800 di queste "cose" (CLP di OS/400). Cose che poi si relazionano
con il resto del sistema operativo, magari per verificare l'esistenza di un file
e/o per creare o svuotare un file temporaneo, e quindi lì si entra nel magico
mondo delle rappresentazioni dei dati: se VMS è simile a Unix e ha il concetto
di file e directory (per quanto diverso e a volte difficilmente adattabile, e.g.
le versioni dei file), nel mondo IBM non c'è neanche quello!

E poi naturalmente ci sono le modifiche ai sorgenti dei programmi veri e propri
in tutti quei punti in cui si interfacciano con il sistema o danno per scontate
certe peculiarità del sistema ospite (e mi vengono in mente decine di esempi).

> Il cambio generazionale prima o poi bisogna farlo.

> [...]

> Però qualunque cosa ancora operativa, anche retaggio del passato, gira su
> sistemi "general purpose" quindi tutto è fattibile, su qualunque sistema.
> Sempre se si fosse senza limiti di budget, però :)
>
> > Per dire: immagino che una banca o un'istituzione analoga potrà utilizzare
> > Hadoop per gestire la parte web (pensa al classico home banking che ormai hanno
> > anche le banche più insignificanti), ma poi il back-end è tutto altrove, magari
> > (anzi, spesso) sul solito, classico, "vecchio" 390 IBM.
>
> Su questo, qualche analista prevede un tracollo di IBM quando queste banche
> faranno migrazione...

Sempre ipotizzando che prima o poi la faranno, questa migrazione. Cosa che per
le ragioni dette sopra non è affatto scontata. Il salto potrebbe avvenire in
ambiti più ristretti, dove ci siano pochissimi clienti e pochissimi produttori:
in quel caso effettivamente un tracollo dell'uno o dell'altro soggetto potrebbe
portare alla sparizione di un intero mercato (leggevo pochi giorni fa qualcosa a
proposito della fine dell'industria del gas per illuminazione).

Mi viene un po' difficile immaginare che l'IBM e/o tutte le banche e le altre
analoghe enormi entità che fanno uso di sistemi mainframe spariscano in maniera
così globale e repentina da far sparire completamente quell'industria, oppure
viceversa che l'IBM, con tutte le commesse che ha, possa sparire/fallire.

Poi ovviamente l'evoluzione c'è, ma molto più lenta di quel che si teme (o che
si vorrebbe), altrimenti saremmo ancora qui con gli IBM 709 a valvole. Sono cose
che durano generazioni e scelte aziendali che durano una vita intera, un po'
come un mutuo per comprare casa: ci si pensa bene e poi è difficile (seppur non
impossibile) decidere di cambiare solo perché in zona non passa più una certa
linea di autobus o non ci sono più i bei negozi che c'erano un tempo. Per le
aziende i sistemi informatici non sono "commodities" come cambiare telefono
perché è uscito il nuovo modello, ma sono investimenti di vita che coinvolgono
decenni di storia aziendale.

Come ti scrivevo l'altra volta: non ci sono aziende "ancora" su VMS o su
mainframe o su AS/400, bensì ci sono aziende positivamente su quei sistemi.

L'unica vera, grossa, preoccupante differenza tra i sistemi IBM e VMS (e altri
nomi ancora più piccoli e oggi sconosciuti), è la base su cui poggiano.

Per base in questo caso intendo sia gli utenti sia chi vende certi tipi di
software. Esempio: decidi di aprire una nuova società finanziaria (non dico una
banca perché è troppo complicato anche solo da immaginare, ma di finanziarie ce
ne sono mille). Benissimo, hai bisogno di gestire l'operatività, come fai? Ti
scrivi tutto il software da zero? Impossibile. Quindi ti rivolgi al mercato:
cosa c'è sul mercato? Varia "roba", quasi tutta per il mondo IBM, quindi che
fai? Ti compri (noleggi / prendi in leasing) un sistema IBM (anche perché avrai
a che fare con banche, altre società finanziarie e varie agenzie pubbliche che
hanno tutto su sistemi IBM) ed entri nel magico mondo di Big Blue.

Ormai i giochi sono fatti: nessuno si mette più a scrivere, oggi, da zero, un
nuovo pacchetto per la gestione di certe cose. Il momento della ricerca è stato
negli anni '60, lo sviluppo negli anni '70 (quando molte aziende sviluppavano
tutto internamente) e il consolidamento negli anni '80. Da lì in poi sono stati
solo aggiornamenti e aggiunte per rispondere a nuove esigenze, magari con
qualche innesto da fuori per interfacciarsi con il web, ma il nocciolo ormai è
fatto. Sarebbe come pensare che oggi ci possa essere qualcuno che decida di
costruire una nuova rete ferroviaria parallela a quella di RFI, o una nuova rete
telefonica fisica, in rame, parallela a quella di Telecom. Impossibile. Certo,
aggiunte (anche molto corpose) e modifiche ce ne sono, e pure nuovi usi e nuove
tecnologie che non si erano neppure immaginate, ma l'intelaiatura è quella.

Cos'è rimasto su VMS? Abbastanza poco, pare: telecomunicazioni, utilities varie,
sanità, ospedali, borse e piazze finanziarie. Pochi, e soprattutto poco visibili
(ma del resto al grande pubblico quale OS che non sia Windows, OSX o al massimo
Linux è visibile?), però si suppone abbastanza buoni, se c'è chi si ostina con
le unghie e con i denti a tenere in vita l'ecosistema VMS (da cui ne discende
che essendoci su NSK senz'altro meno, sarà evidentemente di maggior valore).

Qualche anno fa, grazie al programma "centrali aperte" dell'Enel visitai una
centrale idroelettrica, tra l'altro una di quelle fondamentali perché con tutto
il necessario per riavviare autonomamente la rete come successe dopo il famoso
black-out nazionale del settembre 2003. Ebbene, c'erano dei rack di schede QBUS
e una DECwriter che stampava dei log (che purtroppo non potei fotografare).

Prima o poi anche quei sistemi verrano (o sono già stati) sostituiti, ma in ogni
caso con un'inerzia e un abbrivio che si calcolano in decenni. E solitamente
vengono sostituiti quando c'è qualcosa di equivalente: VMS ha sempre avuto la
possibilità di installare il layer di compatibilità con RSX-11, su OS/400 si
possono far girare ancora tranquillamente i programmi per S/36 ed S/38, su
mainframe attuali girano senza una piega programmi compilati su 360, e così via.

Le cose veramente sparite di colpo senza offrire alternative sono sempre state
molto poche, anche perché nel momento in cui ai tuoi clienti non offri alcuna
alternativa, c'è sempre il rischio che se ne vadano: devo migrare/riscrivere
tutto? Benissimo, invece che farlo sul tuo nuovo sistema, lo faccio sul nuovo
sistema del tuo concorrente, tanto devo migrare comunque.

Quelle schede nella centrale elettrica è più facile che spariscano perché l'Enel
decide di chiudere la centrale e farne una nuova più grossa e potente. Non mi
meraviglierei se si scoprisse che c'è qualche oscura società che offre ancora
servizi di manutenzione per quell'hardware (e relativo software). Del resto, qui
a Bologna c'è un'azienda (con un florido mercato) che offre manutenzione su
macchine IBM vecchissime, addirittura S/34 e S/38 che evidentemente aziende e
aziendine hanno ancora (stavolta sì, ancora) in funzione in qualche sottoscala.

Paradossalmente, la somiglianza di VMS con Unix, anziché fargli bene, gli ha
fatto male, dato che ha tutto sommato agevolato le migrazioni e dunque ha
assottigliato la base, lasciando solo i fedelissimi e chi è "costretto".

> Ah ecco... ora inizio a capire io tutto questo interesse per il Java Batch di
> Java 7 EE, per il quale mi sembrava ci fosse troppa enfasi, inizia ad avere
> 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.

[Gianluca Bonetti]

Il giorno domenica 17 agosto 2014 18:07:31 UTC+2, G. ha scritto:
> Be', un nuovo processore non è solo un nuovo chip; cambia anche il contorno: non
> ho guardato le specifiche esatte, ma posso supporre che ci sia un chipset o
> magari qualche controller integrato nella CPU o sulla scheda madre diverso dai

Io ho guardato sulla wikipedia, assumendo il fatto che sia esatta e completa, vedo dalle pagine
http://en.wikipedia.org/wiki/Itanium
http://en.wikipedia.org/wiki/List_of_Intel_Itanium_microprocessors

Che in pratica il nuovo Itanium 9500 è come il vecchio 9300, a parte:
+ MHz
+ Cache
+ Cores
+ Miglior processo produttivo

Ma socket e chipset restano uguali.
Sembra a tutti gli effetti un upgrade semplice e veloce ad una architettura morente.

> precedenti, etc. Qualunque cosa, anche fosse solo un nuovo chip per il controllo
> della temperatura delle CPU, dev'essere supportato. Del resto, l'architettura

Deve... può.
Basta una appendice alla release del software che dice, "funziona tutto tranne il sensore della temperatura sui server ABC1, ABC2 e ABC3".
Documentato, certificato, contrattualmente legittimo.

> VAX è stata la stessa per più di vent'anni, eppure ogni CPU (o famiglia di CPU)

> ha le sue routine specializzate - tutte raggruppate in un modulo SYSLOAxxx per
> poter fornire un'unica base standard al resto del sistema operativo - e la

> stessa cosa vale anche per VMS su Alpha e Itanium. Cosa che poi succede anche in
> altri ambiti come il mondo PC, in cui finché non carichi i driver della scheda
> madre forniti dal produttore, magari non riesci a mettere il laptop in stand-by.

I primi VAX 11/7x0 confrontati con gli ultimi VAX 4000 ecc sono molto diversi tra loro, molto più che Itanium 1 e 2 e le ultime due iterazioni di Itanium!

> Per quanto riguarda il "pazienza", non è così che funziona, secondo me: ti
> compri la moto nuova, e magari la paghi anche abbastanza, e poi pazienza se il
> carburatore non ce la fa o se i rapporti del cambio non sono ottimizzati, tanto
> con tutti i centimetri cubi di cilindrata in più rispetto alla precedente va
> comunque più veloce, no? Ti piace come idea? :P

Si, vero.
Ma Itanium 9500 è naturalmente più veloce di Itanium 9300: ha 1,5x MHz, ha 1,5x cache, ha 2x cores!
Un server con un solo socket di Itanium 9500 dovrebbe essere quindi 1.5x 1.5x 2.0 = 4,5x volte più veloce di un Itanium 9300!
Matematica spicciola, lo so, ma è per sbrigarmela veloce.
Diciamo che alla peggio sarà 2/3 volte più veloce di un 9300.
Ma anche se fosse solo 2 volte più veloce, chi può dire che l'implementazione software del S.O. potrebbe spingere di più le prestazioni?
Nessuno può farlo, perché non ci sono altre implementazioni software, c'è solo quello che fa HP in casa, oppure qualche strascico di supporto su Linux (che dubito abbia le performance di HP-UX sullo stesso hardware)
Quindi i clienti saranno soddisfatti dall'aumento di prestazioni, perché quello che vedono verrà venduto come il miglior incremento possibile immaginabile.

> Forse "pazienza" lo potresti dire ai comuni mortali (quelli da tua definizione),
> i quali a volte sono però quelli che vanno a cercare l'overclock spintissimo, ai
> limiti della fusione della CPU, ma non a un'azienda che investe dei soldi su un
> aggiornamento hardware e si aspetta di tirarci fuori il meglio (o per lo meno
> quello che dicono le specifiche).

Ma che overclock, è una parola che dimenticavo esistesse.
Guarda, HP paga Intel per continuare a produrre, è un dato assodato della causa HP-Oracle (HP portò i conti in tribunale come giustificativo, hanno pagato $400 mln in 4 anni per continuare la produzione)
Quindi Intel produce praticamente su commissione per HP.
Quindi le specifiche le fanno HP e Intel.
Sono sicuro che tutti i sistemi andranno oltre le specifiche dichiarate.
Semplicemente basta dichiarare specifiche più basse.
Tanto la concorrenza in questo settore non è come tra Xeon e Opteron, lì c'è battaglia vera.
In questo settore è inside trading, sai già di aver vinto sul precedente perché l'hai fatto tu, sai che era più lento e questo è più veloce!

> Quanto ai tempi, a me sei mesi non sembrano neanche tanti, se si vuole fare una
> cosa fatta bene. Può anche darsi che siano stati un po' larghi, giusto per
> coprirsi un po' le spalle, ma fare la cresta artificialmente al tempo è una cosa
> molto rischiosa: se dico a un cliente che per un lavoro da una giornata ce ne
> vogliono sei, è molto probabile che ci creda; ma se lo dico a un collega, o dice
> che sono un imbroglione o che sono un incompetente di cui diffidare.

Sono sicuro che in sei mesi realizzeranno la prossima minor release con supporto ai nuovi processori, e anche le successive per Itanium.
E' sulla versione per x86 che ho i dubbi, se non ci sarà ritorno di investimento in breve tempo.

> Non sappiamo come lavorano e non è affatto detto che abbiano una metodologia
> anni '80, anzi, ne dubito abbastanza. Conosco un paio di nomi di gente sui 55-60
> anni che maneggia java con una competenza che tanti ragazzini (anagraficamente
> e/o mentalmente parlando) si sognano. Eppure è gente che ha cominciato con le
> schede perforate e con i sistemi in cui UN megabyte di RAM era tanta roba.

Certo, ma questi pezzi da novanta non hanno nulla di start-up.
Le start-up non hanno budget illimitati e un parco clienti già esistente fatto di multinazionali miliardarie.
Le start-up hanno un'idea e la realizzano, il più delle volte senza successo, ma con mezzi limitati e budget misurabile in migliaia (decine se va bene, altrimenti meno) e non milioni, di euroz/dollarz.

> [Dynamic translator]

> Lo sapevi, per esempio, che con il port su Itanium hanno deciso di abbandonare
> l'architettura binaria proprietaria e passare a ELF? :)
>
> Tra l'altro, il supporto per gli ELF di VMS nel comando 'file' di Linux & co.
> l'ho aggiunto io (e non solo quello)...

Non sapevo, suppongo che molto si basi sul fatto che restano solo due compilatori per Itanium, che prediligono ELF.

> RDB è niente meno che Oracle per VMS. Quindi altro che cose semplici (per quelle

> ...
> [RDB / Oracle]
> ...

Ma se Oracle performa meglio su Solaris, perché lavorare su VMS quando si può lavorare su Solaris e avere il supporto a 360° del produttore del SO e del DB?

> Ho i miei grossi dubbi. Se il Database relazionale è la strada principale, DBMS
> (reticolare) è la prima traversa a sinistra, mentre i moderni DB NoSQL sono
> dalla seconda a destra in poi... :) Forse, e molto forse, il vecchio DBMS può
> somigliare in un certo senso a un DB a grafo. Scrissi qualche post su questo
> tipo di DB quando raccontai della mia installazione di DBMS-10 su TOPS-10. :)

Un DB Graph può ricadere o non ricadere nella definizione di No-SQL, a seconda dei punti di vista.
Quasi tutti i DB Graph si pubblicizzano come No-SQL.

> Non è solo una questione di potenza pura: te la ricordi la pubblicità della
> Pirelli che diceva "la potenza è nulla senza controllo", quella con l'immagine
> di Carl Lewis con i tacchi a spillo? Ecco.

Pubblicità atta a vendere un pneumatico costoso anziché un pneumatico economico, avente le stesse prestazioni.
(Che poi i Pirelli P0 sono i miei preferiti, ma è un altro discorso :))

> Non fai che sottolineare la mia tesi: se le macchine x86 sono così dannatamente
> veloci, portare VMS su quell'architettura non potrà far altro che bene, dato che
> si unirà a un hardware intrinsecamente veloce anche un software fatto apposta
> per andare veloce su quel terreno (Carl Lewis, in pista, con le scarpe giuste).

Forse non ho spiegato bene la mia versione...
Sono convinto che il port di VMS verso x86 non solo faccia bene a VMS, ma è l'unica via percorribile e contemporaneamente l'ultima spiaggia.
Ma la mia sensazione è che sia irrimediabilmente troppo tardi, e che in futuro potremmo più facilmente leggere "una versione per x86 fu annunciata, ma mai rilasciata definitivamente" piuttosto che "VMS è attivamente supportato su processori x86"

> "Fatto bene" e "portabile" non sono necessariamente caratteristiche dello stesso
> software. Per esempio, potrebbe esistere software sicurissimo e collaudatissimo
> scritto in TPL (linguaggio principe di NonStop) eppure impossibile da migrare
> senza riscriverlo da capo, con tutti i costi e i rischi del caso.

Portabile significa avere un piano di riserva (ovvero ricompilare sul target B anziché A, oppure non ricompilare affatto ma eseguire il bytecode)
Chi ha un piano di riserva è avvantaggiato rispetto a chi ha un solo piano.

> Oppure, senza andare troppo lontano, vogliamo parlare dei quintali di programmi
> per VMS che fanno uso di RMS o altre caratteristiche specifiche di quel mondo?
> Oppure di tutta la roba scritta in Bliss? E di quella in Macro? (Non hai idea, e
> non l'avevo neppure io, di quanta roba non low-level ci sia, scritta in Macro.)
> Senza considerare che non ci sono solo Cobol e Fortran: per esempio, in questi
> giorni in comp.os.vms si è parlato di Basic e su AS/400 va fortissimo l'RPG.

Senza addentrarmi nel discorso di AS400 che evito volutamente e fortemente, tutto quello che dici è sicuramente vero.
Ci sarà sicuramente tanto codice scritto in DCL, Bliss, Macro.
Anche in altre "lingue morte" come il REXX ad esempio.
Alcune vivono ancora in implementazioni aperte disponibili per diversi SO.
Forse è questa la strada migliore... sviluppare interpreti e compilatori più aperti.

> Comunque, anche parlando del solo Cobol (che di solito resiste meglio al tempo e
> può essere più facile da migrare) e nonostante il linguaggio in sé sia piuttosto
> portabile, diventa quasi impossibile portare un'applicazione scritta in Cobol
> (che sia qualcosa di più di un singolo programma) da un ambiente all'altro, non
> solo parlando di VMS > Unix. Ovviamente lo stesso discorso si applica anche al C
> e al C++ (non vorrei che sembrasse un problema dei soli linguaggi "vecchi") e
> vale anche per un ipotetico passaggio S/390 > AS/400, o AS/400 > Unix, o VMS
> AS/400, o VMS > Windows, e così via in tutte le combinazioni possibili.

Il kernel Linux ad esempio è noto per essere GCC dipendente, quindi non compila con altri compilatori (forse qualcosa è cambiato, recentemente, per supportare LLVM)

Indubbiamente oggi abbiamo metodi per una migrazione dolce di qualunque sistema legacy che è possibile, se veramente voluta o necessaria.
Molti di questi metodi si basano sull'integrazione mediante Web Services e sviluppo "per contratto" (la WSDL dei web services è appunto un contratto tra i software)

> Per esempio, rimanendo su cose che conosco, la gestione dell'interfaccia utente
> di VMS è assolutamente, completamente, irriducibilmente diversa da quella di
> OS/400, la quale a sua volta è ugualmente aliena rispetto a quella dei diversi
> sistemi operativi per S/390 e delle varie soluzioni Unix (ncurses?). È talmente
> diversa che non si tratta solo di cambiare qualche istruzione con 'sed', ma
> cambia proprio il paradigma, l'idea, la filosofia...

Ok, questo lo capisco... ma siamo forse un po' fuori rotta...
Il SO è un mezzo per ottenere uno scopo, non un fine di per se stesso.
Quindi non è il discorso di come si gestisce cosa, ma di cosa voglio gestire e quale sistema lo fa nel modo migliore.
Qualunque software giri oggi su VMS, dubito che la sua interazione con l'utente sia tramite VMS stesso ma sicuramente un front end browser based nella maggior parte dei casi e per questo l'utente non sarà altro che un record in un database e una gestione dettata dal programma specifico.

> Poi c'è il discorso dell'interfaccia con il resto del sistema operativo: VMS ha
> le procedure DCL, sui mainframe ci sono le specifiche JCL, OS/400 ha i programmi
> CLP, Unix gli script Bash. Devo continuare? Ho un cliente, neppure grosso, che
> ne ha circa 1.800 di queste "cose" (CLP di OS/400). Cose che poi si relazionano
> con il resto del sistema operativo, magari per verificare l'esistenza di un file
> e/o per creare o svuotare un file temporaneo, e quindi lì si entra nel magico
> mondo delle rappresentazioni dei dati: se VMS è simile a Unix e ha il concetto
> di file e directory (per quanto diverso e a volte difficilmente adattabile, e.g.
> le versioni dei file), nel mondo IBM non c'è neanche quello!

L'eccesso di complessità a volte è un problema più che una soluzione...
Non conosco OS400 ma se avessi un cliente con 1800 procedure bash oserei dire che la soluzione eccede il problema in complessità.

> Sempre ipotizzando che prima o poi la faranno, questa migrazione. Cosa che per
> le ragioni dette sopra non è affatto scontata. Il salto potrebbe avvenire in

Sarò stupido o visionario, ma non vedo il perché l'insieme di programma+dati debba essere specifico di una implementazione e non si possa migrare ad un'altra più performante o più espandibile.

> ambiti più ristretti, dove ci siano pochissimi clienti e pochissimi produttori:
> in quel caso effettivamente un tracollo dell'uno o dell'altro soggetto potrebbe
> portare alla sparizione di un intero mercato (leggevo pochi giorni fa qualcosa a
> proposito della fine dell'industria del gas per illuminazione).

Se vuoi un esempio specifico, ma in campo diverso, c'è una figura che è sparita per via dell'avanzamento tecnologico.
Con il cambio dalla fotografia analogica a digitale, è sparita una figura che era il tecnico del colore (non so bene il nome di questa figura) che praticamente divideva l'immagina analogica in quadricromia per mandarla alla stampa.
Questo almeno mi raccontava già diversi anni fa un amico che fa le foto degli arredamenti.

> Mi viene un po' difficile immaginare che l'IBM e/o tutte le banche e le altre
> analoghe enormi entità che fanno uso di sistemi mainframe spariscano in maniera
> così globale e repentina da far sparire completamente quell'industria, oppure
> viceversa che l'IBM, con tutte le commesse che ha, possa sparire/fallire.

Alcuni analisti prevedono l'IBM in bancarotta per motivi finanziari, non commerciali.
Dopo aver letto quell'articolo ho capito anche il tentativo di IBM di vendere le sue fabbriche di processori, ma a quanto sembra le devono tenere perché la vendita non produrrebbe cash (chissà perché, ma così è)
Evidentemente la nicchia sta iniziando a diventare stretta anche per IBM.

> ...

> Per base in questo caso intendo sia gli utenti sia chi vende certi tipi di
> software. Esempio: decidi di aprire una nuova società finanziaria (non dico una
> banca perché è troppo complicato anche solo da immaginare, ma di finanziarie ce
> ne sono mille). Benissimo, hai bisogno di gestire l'operatività, come fai? Ti
>
> scrivi tutto il software da zero? Impossibile. Quindi ti rivolgi al mercato:
> cosa c'è sul mercato? Varia "roba", quasi tutta per il mondo IBM, quindi che
> fai? Ti compri (noleggi / prendi in leasing) un sistema IBM (anche perché avrai
> a che fare con banche, altre società finanziarie e varie agenzie pubbliche che
> hanno tutto su sistemi IBM) ed entri nel magico mondo di Big Blue.

Sicuramente vero...

> Ormai i giochi sono fatti: nessuno si mette più a scrivere, oggi, da zero, un
> nuovo pacchetto per la gestione di certe cose. Il momento della ricerca è stato
> negli anni '60, lo sviluppo negli anni '70 (quando molte aziende sviluppavano
> tutto internamente) e il consolidamento negli anni '80. Da lì in poi sono stati
> solo aggiornamenti e aggiunte per rispondere a nuove esigenze, magari con
> qualche innesto da fuori per interfacciarsi con il web, ma il nocciolo ormai è
> fatto. Sarebbe come pensare che oggi ci possa essere qualcuno che decida di
> costruire una nuova rete ferroviaria parallela a quella di RFI, o una nuova rete
> telefonica fisica, in rame, parallela a quella di Telecom. Impossibile. Certo,
> aggiunte (anche molto corpose) e modifiche ce ne sono, e pure nuovi usi e nuove
> tecnologie che non si erano neppure immaginate, ma l'intelaiatura è quella.

Si... ma questo è abbastanza triste, perché contrario all'innovazione.
Applaudo quindi agli sforzi fatti altrove, di cablare in fibra intere città da parte di soggetti privati (vedi Google e altri negli USA)

> Cos'è rimasto su VMS? Abbastanza poco, pare: telecomunicazioni, utilities varie,
> sanità, ospedali, borse e piazze finanziarie. Pochi, e soprattutto poco visibili
> (ma del resto al grande pubblico quale OS che non sia Windows, OSX o al massimo
> Linux è visibile?), però si suppone abbastanza buoni, se c'è chi si ostina con
> le unghie e con i denti a tenere in vita l'ecosistema VMS (da cui ne discende
> che essendoci su NSK senz'altro meno, sarà evidentemente di maggior valore).

Ecco se non le banche, telecomunicazioni e ospedali sono due possibili mercati che potrebbero fare cambi per motivi di performance, o di contenimento dei costi.

> Qualche anno fa, grazie al programma "centrali aperte" dell'Enel visitai una
> centrale idroelettrica, tra l'altro una di quelle fondamentali perché con tutto
> il necessario per riavviare autonomamente la rete come successe dopo il famoso
> black-out nazionale del settembre 2003. Ebbene, c'erano dei rack di schede QBUS
> e una DECwriter che stampava dei log (che purtroppo non potei fotografare).

Ah... notevole :)

> Prima o poi anche quei sistemi verrano (o sono già stati) sostituiti, ma in ogni
> caso con un'inerzia e un abbrivio che si calcolano in decenni. E solitamente
> vengono sostituiti quando c'è qualcosa di equivalente: VMS ha sempre avuto la
> possibilità di installare il layer di compatibilità con RSX-11, su OS/400 si
> possono far girare ancora tranquillamente i programmi per S/36 ed S/38, su
> mainframe attuali girano senza una piega programmi compilati su 360, e così via.
>
> Le cose veramente sparite di colpo senza offrire alternative sono sempre state
> molto poche, anche perché nel momento in cui ai tuoi clienti non offri alcuna
> alternativa, c'è sempre il rischio che se ne vadano: devo migrare/riscrivere
> tutto? Benissimo, invece che farlo sul tuo nuovo sistema, lo faccio sul nuovo
> sistema del tuo concorrente, tanto devo migrare comunque.

Eh però qui descrivi proprio la situazione di VMS nei 4 anni passati...
E nell'anno futuro, fino alla prima release di VMS della VSI.
5 anni in informatica sono ere geologiche...

> Quelle schede nella centrale elettrica è più facile che spariscano perché l'Enel
> decide di chiudere la centrale e farne una nuova più grossa e potente. Non mi
> meraviglierei se si scoprisse che c'è qualche oscura società che offre ancora
> servizi di manutenzione per quell'hardware (e relativo software). Del resto, qui
> a Bologna c'è un'azienda (con un florido mercato) che offre manutenzione su
> macchine IBM vecchissime, addirittura S/34 e S/38 che evidentemente aziende e
> aziendine hanno ancora (stavolta sì, ancora) in funzione in qualche sottoscala.

Si ma quelle aziende che fanno supporto avranno ogni anno ridotto il proprio mercato, ad ogni 31/12 le probabilità di rimanere senza un solo cliente attivo sono altissime, e affidarsi solo al supporto di sistemi legacy è un bel rischio.
Anni fa facevo assistenza ad una azienda di riscossione tributi, poi confluita in Equitalia, su control unit 3270 e terminali IBM o schede emulazione.
Se mi fossi fossilizzato su quello, sarei appunto divenuto fossile.

> Paradossalmente, la somiglianza di VMS con Unix, anziché fargli bene, gli ha
> fatto male, dato che ha tutto sommato agevolato le migrazioni e dunque ha
> assottigliato la base, lasciando solo i fedelissimi e chi è "costretto".

Oddio... somiglianza... io adoro Unix ma non digerisco per niente VMS nonostante il mio Digital-feticismo :)

> > Ah ecco... ora inizio a capire io tutto questo interesse per il Java Batch di
> > Java 7 EE, per il quale mi sembrava ci fosse troppa enfasi, inizia ad avere
> > 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. :)

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

[G.]

On Thu, 21 Aug 2014 16:13:39 -0700 (PDT), Gianluca Bonetti <g...@decadence.it>
wrote:

[Tempi di rilascio e cosa dice Wikipedia su Itanium]
> in pratica il nuovo Itanium 9500 è come il vecchio 9300 [...] socket e
> chipset restano uguali.

Be', avevo premesso di non aver controllato, e infatti le mie erano solo
supposizioni (evidentemente sbagliate). Vedremo come va a finire. :)

L'unica cosa che mi viene in mente, e che forse potrebbe essere la fonte di
tanta cautela nel calcolo dei tempi, è il periodo necessario per accertarsi che
non ci siano problemi legati alla velocità: non sarebbe la prima volta che un
software smette di funzionare aumentando la velocità di calcolo, per i più
disparati motivi. Certo un incremento di 4,5 volte non è molto, ma non si può
mai sapere finché non ci si inciampa.

Se cerchi in giro, c'è un interessante PDF di Bob Supnik (l'autore di SimH) in
cui racconta di certi bug latenti in un sistema operativo Digital – ora non
ricordo quale – che si manifestarono improvvisamente solo quando il suddetto OS
si trovò a girare più veloce di quanto avesse mai fatto sulla CPU fisica più
potente mai prodotta. E sempre sullo stesso argomento mi viene in mente anche un
runtime error (200?) di tutti i programmi compilati con Borland Pascal se fatti
girare su PC con un Pentium a 233 MHz o superiore. :)

> I primi VAX 11/7x0 confrontati con gli ultimi VAX 4000 ecc sono molto diversi
> tra loro, molto più che Itanium 1 e 2 e le ultime due iterazioni di Itanium!

Indubbiamente. Era solo per dire che anche un "banale" aggiornamento di CPU può
risultare piuttosto complesso, visto che fisicamente può cambiare tutto mentre
l'architettura rimane la stessa; ma poi tu hai dimostrato che i due tipi di
Itanium sono pressoché identici, fatta salva la maggior velocità del più nuovo.

[Passaggio ad ELF]

> Non sapevo, suppongo che molto si basi sul fatto che restano solo due
> compilatori per Itanium, che prediligono ELF.

La ragione principale è spiegata nel bel resoconto di Clair Grant sul port di
VMS a Itanium (cfr. http://h71000.www7.hp.com/openvms/journal/v6/):

«Selecting the ELF/DWARF file format caused enormous shock waves. The compilers,
the linker, the librarian, the debugger, the dump analyzer, and the image
activator (just to name a few) would have completely different formats of input
and/or output. But we wanted to make OpenVMS more receptive to the world of
porting applications and analysis tools. The system would be more accessible to
applications because it would have more well-known internal formats and more
developers would understand them.

One of the goals of the project was to make OpenVMS more portable. Who knows,
maybe someone will be doing this again! The calling standard, ELF, and DWARF
decisions doubled the length of the port of OpenVMS, not just in the coding time
but also in the conceptualization and the debugging of completely new
implementations. It was hard work, but OpenVMS is a better system for it».

[RDB vs. Oracle]

> Ma se Oracle performa meglio su Solaris, perché lavorare su VMS quando si può
> lavorare su Solaris e avere il supporto a 360° del produttore del SO e del DB?

A causa di tutto il discorso sulle difficoltà e i costi di un port totale delle
applicazioni da un ambiente a un altro di cui discutiamo in questo thread.

Chi parte ex novo partirà con Solaris, ma chi ha già software su VMS è probabile
che rimanga dov'è finché può. È lì la grande sfida di VSI, forse già persa in
partenza (ma chissà, mai dire mai): fare in modo che qualcuno che parte ex novo
decida per VMS anziché per Solaris o altri.

[Portabilità del software]

> > "Fatto bene" e "portabile" non sono necessariamente caratteristiche dello stesso
> > software. Per esempio, potrebbe esistere software sicurissimo e collaudatissimo
> > scritto in TPL (linguaggio principe di NonStop) eppure impossibile da migrare
> > senza riscriverlo da capo, con tutti i costi e i rischi del caso.
>
> Portabile significa avere un piano di riserva (ovvero ricompilare sul target B
> anziché A, oppure non ricompilare affatto ma eseguire il bytecode)

In ogni caso, se il software è scritto in TPL (ho preso apposta come esempio un
linguaggio raro), difficilmente si troverà un compilatore per una piattaforma
che non sia la sua piattaforma nativa; e se l'output di compilazione e linking
non è bytecode ma codice macchina (che non è la stessa cosa), o hai un emulatore
di quella CPU o non lo esegui. Quindi quel particolare software non è portabile,
ma va riscritto, e si ricade nelle considerazioni già fatte. Riscrivere può
essere un possibile piano di riserva, ma in certi casi è talmente oneroso (non
solo in termini economici) da essere all'atto pratico pressoché non fattibile.

> Ci sarà sicuramente tanto codice scritto in DCL, Bliss, Macro. Anche in altre
> "lingue morte" come il REXX ad esempio. Alcune vivono ancora in implementazioni
> aperte disponibili per diversi SO.

Di tutti quelli che hai citato, l'unico linguaggio per il quale pare esistere un
interprete per Linux è Rexx. Per gli altri direi che non c'è nulla. E finché si
parla di "lingue morte" va anche bene, tutto sommato. Ma se parliamo di lingue
vive – per quanto relativamente rare – come l'RPG (uno a caso :P), che si fa?

(A proposito di linguaggi non subito facili da migrare, su un VAX recuperato da
qualche parte ricordo di aver trovato un centinaio di sorgenti Dibol...)

> Indubbiamente oggi abbiamo metodi per una migrazione dolce di qualunque sistema
> legacy che è possibile, se veramente voluta o necessaria.

Non sarei così sicuro. "Dolce" è una parola grossa. Hai presente la frase "too
big to fail"? Ecco, parafrasando, c'è roba che è davvero "too big to port".

Come ho scritto nel mio messaggio precedente, c'è roba talmente grossa, costosa
e complessa che rimarrà in uso ancora per chissà quanto, forse finché non si
esaurirà. A meno che appunto non ci sia la necessità (e la volontà) di migrarla.

Cioè intendimi: sono decisioni che si prendono solo se estremamente necessarie e
in quei casi la valutazione della velocità non è affatto la prima cosa.

> Molti di questi metodi si basano sull'integrazione mediante Web Services e
> sviluppo "per contratto" (la WSDL dei web services è appunto un contratto tra i
> software)

Purtroppo là fuori c'è un mondo intero che non sa manco cosa sia un web service.
Una vera e propria orda di sistemi legacy che per un motivo o per l'altro non
sfrutta certe nuove tecnologie e che quindi non può o non riesce ad entrare in
uno schema di migrazione più o meno dolce che faccia uso di quei metodi.

L'articolo Wikipedia in inglese sui legacy system dice molte delle cose che ho
scritto anch'io; non l'avevo mai letto prima e devo dire che mi pare un buon
riassunto: http://en.wikipedia.org/wiki/Legacy_system

Fra le varie cose dice appunto che a volte non si può migrare a causa dei costi
e/o della complessità, o anche per motivi meno "belli" come l'aver perduto la
documentazione sul funzionamento del sistema; cosa che ho visto succedere con i
miei occhi quando chi aveva sviluppato tutto è andato in pensione (o addirittura
è morto!) senza lasciare una documentazione completa ed esaustiva. Poi si può
discutere su come e perché è potuto succedere, ma intanto il problema è che non
hai la documentazione e non sai cos'hai fra le mani.

Fa anche l'esempio dello Shuttle, che ricalca più o meno il concetto che ho
espresso sopra, e cioè che certi sistemi stanno lì finché non si esauriscono,
proprio come tutto il "contorno" dello Shuttle che è stato tenuto in piedi
finché non è stata pensionata anche l'ultima navetta spaziale.

Magari passare a tecnologie basate su web service e affini potrebbe anche essere
molto utile, ma l'ostacolo è nell'ecosistema: se sei una banca – e perciò hai a
che fare con altri istituti, con enti statali, con banche dati creditizie, con
la centrale rischi della banca d'Italia, magari pure con l'(ex) Isvap – e tutti
ma proprio tutti ti parlano e si parlano con protocolli basati su SNA (quando va
bene), non puoi decidere da solo che tu parli via web service e che gli altri si
arrangino; devi adeguarti o sei "out of business".

Poi non dico che col tempo non si muova qualcosa anche lì, se no saremmo fermi
ai sistemi con le schede perforate, ma la maturazione è molto lenta. Un nuovo
servizio potrà venir implementato con nuove tecnologie, ma i servizi esistenti
probabilmente rimarranno come sono per decenni.

Giusto poco prima delle vacanze ho dovuto sistemare un paio di cosette per un
cliente: i tracciati CBI per bonifici e ricevute bancarie e quelli per il nuovo
(e sottolineo: nuovo) modello polivalente dell'agenzia delle entrate. Ebbene,
entrambi i tracciati gridano Cobol da lontano un miglio. Magari li trasmetti via
web con una connessione cifrata (anziché usare un modem o consegnare un floppy),
ma alla fine vanno comunque a finire in un mainframe.

Se tutto questo vale per chi non migra da sistemi IBM, dove tutto sommato è in
buona e grossa compagnia, a maggior ragione vale per chi ha resistito nonostante
tutto su VMS: tolto chi non migra per pigrizia (ma esiste?), gli altri avranno
tutte le loro ragioni per rimanere lì, e possono essere le più disparate.

[Non migrabilità delle interfacce utente]

> Qualunque software giri oggi su VMS, dubito che la sua interazione con l'utente
> sia tramite VMS stesso ma sicuramente un front end browser based nella maggior
> parte dei casi e per questo l'utente non sarà altro che un record in un database
> e una gestione dettata dal programma specifico.

Credo che dovresti dubitare di più. :) Francamente non ho dati precisi su VMS
(se non qualcosa di letto qua e là su comp.os.vms), ma se la cosa è anche solo
vagamente simile a quel che succede nel mondo IBM (e anche di certi vecchi Unix
tipo SCO e Olivetti), c'è ancora taaanta roba che va coi terminali non grafici.
Tanta tanta tanta. Al 90-95% su PC con un emulatore, ma c'è anche una discreta
fetta di gente che fa uso di terminali stupidi, nel 2014.

Il mondo dei terminali non è affatto finito: ci sono diverse ditte che vendono
(tanto per dire) pistole laser per la lettura di codici a barre con l'emulazione
integrata IBM 5250, 3270 e ANSI/DEC VT100, proprio per interfacciarsi con certi
sistemi. Ho visto anche i marcatempo per l'entrata/uscita dei dipendenti con
integrati 5250, 3270 e compagni. Addirittura c'è qualcosa con l'interfaccia UTS
dei mainframe Unisys (ex Univac!): http://en.wikipedia.org/wiki/Uniscope :)

Vedi nomi tipo Telxon, Intermec, Honeywell, Datalogic e chissà quanti altri.

Digressione: i lettori 5250 sono molto comodi perché il programma sull'host è
identico a un qualunque altro programma; l'unica differenza è nel display più
piccolo del classico 80x24 (o 27x132). Per esempio, il debug si fa comodamente
da terminale (col display tutto vuoto tranne un riquadro in alto a sinistra).

> > Poi c'è il discorso dell'interfaccia con il resto del sistema operativo: VMS ha
> > le procedure DCL, sui mainframe ci sono le specifiche JCL, OS/400 ha i programmi
> > CLP, Unix gli script Bash. Devo continuare? Ho un cliente, neppure grosso, che
> > ne ha circa 1.800 di queste "cose" (CLP di OS/400). Cose che poi si relazionano
> > con il resto del sistema operativo, magari per verificare l'esistenza di un file
> > e/o per creare o svuotare un file temporaneo, e quindi lì si entra nel magico
> > mondo delle rappresentazioni dei dati: se VMS è simile a Unix e ha il concetto
> > di file e directory (per quanto diverso e a volte difficilmente adattabile, e.g.
> > le versioni dei file), nel mondo IBM non c'è neanche quello!
>

> Non conosco OS400 ma se avessi un cliente con 1800 procedure bash oserei dire
> che la soluzione eccede il problema in complessità.

Guarda che 1.800 non è mica una gran cifra! Ho qui un pacchetto per la gestione
finanziaria (carte di credito, prestiti, leasing, cessione del quinto, etc.) che
è composto da 5.516 programmi CLP, 17.203 programmi Cobol, 6.654 definizioni fra
tabelle e relativi indici, 6.066 definizioni di display video (per altrettanti
programmi interattivi fra i suddetti 17mila) e 5.401 pannelli di testo di aiuto.

Non ho esperienze professionali su VMS, ma da quel poco che ho avuto occasione
di vedere (spulciando il contenuto dei dischi di vari sistemi recuperati qua e
là), direi che il metodo di lavoro è abbastanza simile, quindi su macchine
grosse mi aspetto che si trovino numeri del genere in quanto a procedure DCL e
via dicendo (sorgenti di programmi, file FDL per la definizione dei dati, etc.).

Su mainframe, un po' per le dimensioni medie del sistema e un po' considerando
che quasi ogni programma richiede una relativa procedura JCL di avvio, credo che
i numeri siano di gran lunga maggiori. Non mi meraviglierei troppo di cifre
dieci volte tanto quelle dette qui sopra.

Del resto, se l'IBM pubblica benchmark con tabelle di esempio da 100, 500 e
1.000 milioni di record (un miliardo!), si può ipotizzare che anche il numero di
procedure possa più o meno essere proporzionato.

> Sarò stupido o visionario, ma non vedo il perché l'insieme di programma+dati
> debba essere specifico di una implementazione e non si possa migrare ad un'altra
> più performante o più espandibile.

Perché i programmi, volenti o nolenti, sono legati all'ambiente. E il formato
dei dati è legato ai programmi.

Un programma un minimo complesso fa uso dei servizi del sistema operativo.
Alcuni esistono più o meno ovunque, altri sono più specifici. E comunque anche
quelli più generali possono essere molto diversi fra un sistema e l'altro.

Per dire, in VMS la command line (pre-tokenizzata dal paser DCL che ne verifica
la correttezza formale) si maneggia con varie chiamate a servizi di sistema, fra
i quali CLI$GET_VALUE. Se porti il programma su Unix, dovrai rifare quella parte
di programma perché non si tratta solo di sostituire una chiamata con una
diversa (cosa che si potrebbe tentare con awk o sed), ma devi proprio modificare
la logica del programma visto che avrai una command line diversa, con una
sintassi diversa e dovrai gestirtela dentro il programma, magari con un po' di
getopt() qua e là. Un'altra strada potrebbe essere quella di implementare un
parser DCL che abbia la funzione CLI$GET_VALUE, ma poi ti scontreresti, fra le
altre cose, non solo con la complessità della sintassi DCL, ma anche con la
consuetudine Unix che assegna al carattere '/' un significato diverso. Insomma,
sono cose complesse e da valutare attentamente, specie quando i programmi sono
tanti. E questo è solo un esempio, ma ce ne sono mille: ogni punto in cui un
programma si interfaccia con il sistema va rivalutato e probabilmente rifatto.

Potrei anche raccontarti di come si fa in OS/400 a recuperare le caratteristiche
di un device (si fa chiamando QDCRDEVD), ma te lo risparmio. In Unix credo si
faccia con una chiamata a stat() e/o andando a vedere in /dev, /proc o /sys. In
VMS invece si fa chiamando SYS$GETDVI. Ovviamente non cambiano solo i nomi delle
funzioni, ma anche tutti i concetti e le strutture passate e ricevute.

Sono solo due esempi, ma prova a pensare a quante volte fai uso dei servizi del
sistema operativo in una procedura complessa.

Questo per quanto riguarda i programmi. Per quanto riguarda invece i dati, forse
la faccenda è un po' più semplice, anche se pure lì possono esserci delle belle
sorprese. Per esempio, mentre i dati alfanumerici sono più o meno uguali ovunque
(fatti salvi i terminatori di stringa che invece sono un mondo a parte), i dati
numerici sono tutti da rivedere. Intanto c'è da tenere presente che potresti
avere problemi di endianess, poi ad esempio i numeri in virgola mobile possono
essere in diversi formati (non c'è solo lo standard IEEE). Ci sono anche i
numeri packed, tanto amati dall'IBM, ma che altrove sono rari e quindi vanno
quasi certamente convertiti. Può darsi che quasi per ogni tabella tu debba
scrivere un programma di conversione, o magari anche due: da formato vecchio a
formato di transito, e da formato di transito a formato nuovo.

Dopodiché, parlando di dati si torna ai programmi: in VMS e nel mondo IBM c'è il
concetto di record già nel filesystem, in Unix no. Quindi ogni occorrenza di
un'istruzione READ o REWRITE a indici va sostituita con le equivalenti istruzoni
select o update SQL, le quali a loro volta richiedono un cursore, quindi dovrai
riguardarti praticamente ogni programma e aggiungere di sana pianta tutto il
codice necessario, compresa la valutazione dei codici di ritorno tipo SQLCODE (e
se c'è anche SQLSTATE) dopo ogni chiamata al database.

Eccetra, eccetra, eccetra. Tecnicamente tutto è fattibile, ma spesso sarebbero
necessari tempi e costi insostenibili. Senza contare i nuovi bug.

> Ecco se non le banche, telecomunicazioni e ospedali sono due possibili mercati
> che potrebbero fare cambi per motivi di performance, o di contenimento dei costi.

Sempre che invece non gli convenga rimanere dove sono finché possono, per i
motivi spiegati dall'articolo di Wikipedia sui legacy system e detti qui sopra.

[Azienda che fa manutenzione su vecchi sistemi]

> Si ma quelle aziende che fanno supporto avranno ogni anno ridotto il proprio
> mercato, ad ogni 31/12 le probabilità di rimanere senza un solo cliente attivo
> sono altissime, e affidarsi solo al supporto di sistemi legacy è un bel rischio.

Non fa assistenza solo a roba ultraventennale, ovviamente. Quella è e rimane una
nicchia, molto remunerativa però: ogni volta che vendono una vecchia scheda a
qualcuno che ne ha bisogno, per quella giornata potrebbero anche chiudere lì. :)

> Anni fa facevo assistenza ad una azienda di riscossione tributi, poi confluita
> in Equitalia, su control unit 3270 e terminali IBM o schede emulazione. Se mi
> fossi fossilizzato su quello, sarei appunto divenuto fossile.

Magari girano tuttora su 3270. :) Non ho idea di cosa usi Equitalia, ma non mi
meraviglierei affatto se si scoprisse che il back-end gira su 390, anche perché
direi che è la norma quando si parla di grossi enti (vedi sopra).

> > Paradossalmente, la somiglianza di VMS con Unix, anziché fargli bene, gli ha
> > fatto male, dato che ha tutto sommato agevolato le migrazioni e dunque ha
> > assottigliato la base, lasciando solo i fedelissimi e chi è "costretto".
>
> Oddio... somiglianza... io adoro Unix ma non digerisco per niente VMS nonostante
> 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

[Gianluca Bonetti]

Il giorno lunedì 25 agosto 2014 16:26:44 UTC+2, G. ha scritto:
> [Itanium 9500 vs 9300]

> Be', avevo premesso di non aver controllato, e infatti le mie erano solo
> supposizioni (evidentemente sbagliate). Vedremo come va a finire. :)

No neanche io avevo controllato fino a quel momento, e poi anche la Wiki va presa con le pinze anche se per cose così recenti dovrebbe essere autorevole.
Per essere sicuri bisognerebbe prendere le due specifiche tecniche Intel e spulciare le centinaia di pagine per capire le differenze... ma il mio interesse si ferma prima! :)

> L'unica cosa che mi viene in mente, e che forse potrebbe essere la fonte di
> tanta cautela nel calcolo dei tempi, è il periodo necessario per accertarsi che
> non ci siano problemi legati alla velocità: non sarebbe la prima volta che un
> software smette di funzionare aumentando la velocità di calcolo, per i più
> disparati motivi. Certo un incremento di 4,5 volte non è molto, ma non si può
> mai sapere finché non ci si inciampa.

Beh diciamo che 4,5 è la "incremento di potenza complessivo" considerato che ha più core, ma il singolo core gira al massimo a 2,53 MHz contro 1,73.
La differenza però è maggiore se si considera la prima generazione di Itanium a 800 MHz, che probabilmente rende meno di un VUP :)

> Se cerchi in giro, c'è un interessante PDF di Bob Supnik (l'autore di SimH) in

> cui racconta di certi bug latenti in un sistema operativo Digital - ora non
> ricordo quale - che si manifestarono improvvisamente solo quando il suddetto OS

> si trovò a girare più veloce di quanto avesse mai fatto sulla CPU fisica più
> potente mai prodotta. E sempre sullo stesso argomento mi viene in mente anche un
> runtime error (200?) di tutti i programmi compilati con Borland Pascal se fatti
> girare su PC con un Pentium a 233 MHz o superiore. :)

Ne ho sentiti diversi nel corso degli anni, ma mi resta difficile ricordare un singolo caso specifico... la memoria è poca per contenere le cose utili, figurarsi per i bug! :)

Se non erro sui PDP11 è possibile impostare un interrupt in base alla frequenza della CPU, ad un timing fisso, oppure alla frequenza della corrente in input.
Mi sbaglio?

> [Passaggio ad ELF]

> La ragione principale è spiegata nel bel resoconto di Clair Grant sul port di
> VMS a Itanium (cfr. http://h71000.www7.hp.com/openvms/journal/v6/):

> ...

Questo sicuramente ha richiesto più tempo che aggiungere il supporto a del nuovo hardware.
Per la fortuna di VMS, questo lavoro è già stato fatto! :)

> [RDB vs. Oracle]
> > Ma se Oracle performa meglio su Solaris, perché lavorare su VMS quando si può
> > lavorare su Solaris e avere il supporto a 360° del produttore del SO e del DB?
>
> A causa di tutto il discorso sulle difficoltà e i costi di un port totale delle
> applicazioni da un ambiente a un altro di cui discutiamo in questo thread.

Si infatti io sono dell'idea che "chi più spende meno spende".
Cioè spendi 10 adesso per rifare tutto, piuttosto che spendere 1 cento volte.

> Chi parte ex novo partirà con Solaris, ma chi ha già software su VMS è probabile
> che rimanga dov'è finché può. È lì la grande sfida di VSI, forse già persa in
> partenza (ma chissà, mai dire mai): fare in modo che qualcuno che parte ex novo
> decida per VMS anziché per Solaris o altri.

Bella sfida... se uno ha seguito un po' la vicenda negli ultimi anni non è che si affiderebbe a VSI alla cieca.
Cioè... *TU* lo faresti?
Affidare un tuo nuovo progetto alla piattaforma VSI+VMS?

> [Portabilità del software]

> In ogni caso, se il software è scritto in TPL (ho preso apposta come esempio un
> linguaggio raro), difficilmente si troverà un compilatore per una piattaforma
> che non sia la sua piattaforma nativa; e se l'output di compilazione e linking
> non è bytecode ma codice macchina (che non è la stessa cosa), o hai un emulatore
> di quella CPU o non lo esegui. Quindi quel particolare software non è portabile,
> ma va riscritto, e si ricade nelle considerazioni già fatte. Riscrivere può
> essere un possibile piano di riserva, ma in certi casi è talmente oneroso (non
> solo in termini economici) da essere all'atto pratico pressoché non fattibile.

Per fare un esempio che mi tange, ho molto codice scritto in un dialetto del BASIC specifico (proprietario) di un software gestionale per il mercato italiano.
E' talmente raro che non figura neanche nella lista dei dialetti del BASIC sulla Wikipedia :)
Per essere un dialetto proprietario di un gestionale, è anche troppo ben fatto: compila in bytecode (eseguibile solamente nel gestionale che è la sua VM, per così dire) e ha un ottimo accesso alla base dati proprietaria.
Per il resto è pessimo: non strutturato, limitazioni all'accesso alla memoria a 128k, e altre limitazioni peggiori.
Quindi richiede al programmatore 10 volte il tempo che ci vorrebbe a farlo con un altro strumento.
Il codice esistente funziona, è stabile, è usato da clienti che NON si lamentano... quindi... finché la barca va...
Eppure ho passato l'estate a riscrivere perché io per primo, fornitore di servizi, voglio avere delle alternative, se per qualche motivo domani un cliente mi fa una richiesta che col linguaggio proprietario non riesco a risolvere voglio aver la possibilità di risolvere la sua richiesta.
C'è voluto tempo, molti sforzi, ma nel mio caso specifico, meno sforzi di quanti avevo previsto all'inizio di questa scommessa perché, per nostra fortuna, gli strumenti sono migliorati nel tempo :)

> Di tutti quelli che hai citato, l'unico linguaggio per il quale pare esistere un
> interprete per Linux è Rexx. Per gli altri direi che non c'è nulla. E finché si
> parla di "lingue morte" va anche bene, tutto sommato. Ma se parliamo di lingue

> vive - per quanto relativamente rare - come l'RPG (uno a caso :P), che si fa?

Riscrivere... Un po' per volta prima di non avere alternative.
Chi ben comincia è a metà dell'opera! :)

> (A proposito di linguaggi non subito facili da migrare, su un VAX recuperato da
> qualche parte ricordo di aver trovato un centinaio di sorgenti Dibol...)

Codice ancora in uso?
Magari era codice vecchio già riscritto!

> > Indubbiamente oggi abbiamo metodi per una migrazione dolce di qualunque sistema
> > legacy che è possibile, se veramente voluta o necessaria.
>
> Non sarei così sicuro. "Dolce" è una parola grossa. Hai presente la frase "too
> big to fail"? Ecco, parafrasando, c'è roba che è davvero "too big to port".

Impossible is nothing. :)

> Come ho scritto nel mio messaggio precedente, c'è roba talmente grossa, costosa
> e complessa che rimarrà in uso ancora per chissà quanto, forse finché non si
> esaurirà. A meno che appunto non ci sia la necessità (e la volontà) di migrarla.
>
> Cioè intendimi: sono decisioni che si prendono solo se estremamente necessarie e
> in quei casi la valutazione della velocità non è affatto la prima cosa.

Ci sono altri fattori come ad esempio i costi di gestione e mantenimento.
Ci sono sistemi che a passare dal mainframe ad un cluster di ARM si ripagherebbe in un anno col solo risparmio di energia elettrica :)
Ma se non hai alternative...

> Purtroppo là fuori c'è un mondo intero che non sa manco cosa sia un web service.
> Una vera e propria orda di sistemi legacy che per un motivo o per l'altro non
> sfrutta certe nuove tecnologie e che quindi non può o non riesce ad entrare in
> uno schema di migrazione più o meno dolce che faccia uso di quei metodi.

Si può scrivere un Web Service anche in C, per qualunque piattaforma.
Riescono a mettere un WS su sistemi 8 bit con pochi kb di memoria, perché non si implementarlo su sistemi superiori?

> L'articolo Wikipedia in inglese sui legacy system dice molte delle cose che ho
> scritto anch'io; non l'avevo mai letto prima e devo dire che mi pare un buon
> riassunto: http://en.wikipedia.org/wiki/Legacy_system
>
> Fra le varie cose dice appunto che a volte non si può migrare a causa dei costi
> e/o della complessità, o anche per motivi meno "belli" come l'aver perduto la
> documentazione sul funzionamento del sistema; cosa che ho visto succedere con i
> miei occhi quando chi aveva sviluppato tutto è andato in pensione (o addirittura
> è morto!) senza lasciare una documentazione completa ed esaustiva. Poi si può
> discutere su come e perché è potuto succedere, ma intanto il problema è che non
> hai la documentazione e non sai cos'hai fra le mani.
>
> Fa anche l'esempio dello Shuttle, che ricalca più o meno il concetto che ho
> espresso sopra, e cioè che certi sistemi stanno lì finché non si esauriscono,
> proprio come tutto il "contorno" dello Shuttle che è stato tenuto in piedi
> finché non è stata pensionata anche l'ultima navetta spaziale.

... e non c'era una alternativa già pronta!
Cioè lo Shuttle 2.0 o lo Shuttle.next

> Magari passare a tecnologie basate su web service e affini potrebbe anche essere

> molto utile, ma l'ostacolo è nell'ecosistema: se sei una banca - e perciò hai a

> che fare con altri istituti, con enti statali, con banche dati creditizie, con

> la centrale rischi della banca d'Italia, magari pure con l'(ex) Isvap - e tutti

> ma proprio tutti ti parlano e si parlano con protocolli basati su SNA (quando va
> bene), non puoi decidere da solo che tu parli via web service e che gli altri si
> arrangino; devi adeguarti o sei "out of business".
>
> Poi non dico che col tempo non si muova qualcosa anche lì, se no saremmo fermi
> ai sistemi con le schede perforate, ma la maturazione è molto lenta. Un nuovo
> servizio potrà venir implementato con nuove tecnologie, ma i servizi esistenti
> probabilmente rimarranno come sono per decenni.

Mi arrendo, non ho abbastanza conoscenza del sistema bancario per poter valutare la cosa.
Anche perché far risparmiare le banche non è uno dei miei obbiettivi nella vita :)
Però ho visto diverse aziende stritolate nella morsa di sistemi proprietari senza alcuna razionale motivazione.

> Giusto poco prima delle vacanze ho dovuto sistemare un paio di cosette per un
> cliente: i tracciati CBI per bonifici e ricevute bancarie e quelli per il nuovo
> (e sottolineo: nuovo) modello polivalente dell'agenzia delle entrate. Ebbene,
> entrambi i tracciati gridano Cobol da lontano un miglio. Magari li trasmetti via
> web con una connessione cifrata (anziché usare un modem o consegnare un floppy),
> ma alla fine vanno comunque a finire in un mainframe.

Si ho sentito dire che questo modello polivalente è abbastanza particolare, ma non mi sono (per ora) cimentato nella questione.
Quando lo farò (t < 12 mesi) ti saprò dire che ne penso :)
Per quello che mi hanno detto, non è che sia proprio ben fatto.

> Se tutto questo vale per chi non migra da sistemi IBM, dove tutto sommato è in
> buona e grossa compagnia, a maggior ragione vale per chi ha resistito nonostante
> tutto su VMS: tolto chi non migra per pigrizia (ma esiste?), gli altri avranno
> tutte le loro ragioni per rimanere lì, e possono essere le più disparate.

Non questiono sulle scelte altrui, mi limito a citare (e fornire, ove possibile) le alternative.

> [Non migrabilità delle interfacce utente]

> Credo che dovresti dubitare di più. :) Francamente non ho dati precisi su VMS
> (se non qualcosa di letto qua e là su comp.os.vms), ma se la cosa è anche solo
> vagamente simile a quel che succede nel mondo IBM (e anche di certi vecchi Unix
> tipo SCO e Olivetti), c'è ancora taaanta roba che va coi terminali non grafici.
>
> Tanta tanta tanta. Al 90-95% su PC con un emulatore, ma c'è anche una discreta
> fetta di gente che fa uso di terminali stupidi, nel 2014.
>
> Il mondo dei terminali non è affatto finito: ci sono diverse ditte che vendono
> (tanto per dire) pistole laser per la lettura di codici a barre con l'emulazione
> integrata IBM 5250, 3270 e ANSI/DEC VT100, proprio per interfacciarsi con certi
> sistemi. Ho visto anche i marcatempo per l'entrata/uscita dei dipendenti con
> integrati 5250, 3270 e compagni. Addirittura c'è qualcosa con l'interfaccia UTS
> dei mainframe Unisys (ex Univac!): http://en.wikipedia.org/wiki/Uniscope :)
>
> Vedi nomi tipo Telxon, Intermec, Honeywell, Datalogic e chissà quanti altri.
>
> Digressione: i lettori 5250 sono molto comodi perché il programma sull'host è
> identico a un qualunque altro programma; l'unica differenza è nel display più
> piccolo del classico 80x24 (o 27x132). Per esempio, il debug si fa comodamente
> da terminale (col display tutto vuoto tranne un riquadro in alto a sinistra).

Anche da BlockBuster avevano la Digital PWS 433 con VMS e terminali VT510 in ogni negozio.
Poi BlockBuster è fallita :)

Per la data entry i terminali stupidi e l'interfaccia a carattere in generale sono ottimi.
Ma si può sviluppare anche qualcosa di nuovo e altrettanto funzionale.

> > Non conosco OS400 ma se avessi un cliente con 1800 procedure bash oserei dire
> > che la soluzione eccede il problema in complessità.
>
> Guarda che 1.800 non è mica una gran cifra! Ho qui un pacchetto per la gestione
> finanziaria (carte di credito, prestiti, leasing, cessione del quinto, etc.) che
> è composto da 5.516 programmi CLP, 17.203 programmi Cobol, 6.654 definizioni fra
> tabelle e relativi indici, 6.066 definizioni di display video (per altrettanti
> programmi interattivi fra i suddetti 17mila) e 5.401 pannelli di testo di aiuto.
>
> Non ho esperienze professionali su VMS, ma da quel poco che ho avuto occasione
> di vedere (spulciando il contenuto dei dischi di vari sistemi recuperati qua e
> là), direi che il metodo di lavoro è abbastanza simile, quindi su macchine
> grosse mi aspetto che si trovino numeri del genere in quanto a procedure DCL e
> via dicendo (sorgenti di programmi, file FDL per la definizione dei dati, etc.).
>
> Su mainframe, un po' per le dimensioni medie del sistema e un po' considerando
> che quasi ogni programma richiede una relativa procedura JCL di avvio, credo che
> i numeri siano di gran lunga maggiori. Non mi meraviglierei troppo di cifre
> dieci volte tanto quelle dette qui sopra.
>
> Del resto, se l'IBM pubblica benchmark con tabelle di esempio da 100, 500 e
> 1.000 milioni di record (un miliardo!), si può ipotizzare che anche il numero di
> procedure possa più o meno essere proporzionato.

Mi riferivo al fatto che 1800 procedure aggiuntive su un pacchetto standard sarebbe troppo.
Gli esempi che citi sembrano per dimensione più sistemi software ad hoc per aziende di livello enterprise che pacchetti standard.

> Perché i programmi, volenti o nolenti, sono legati all'ambiente. E il formato
> dei dati è legato ai programmi.
>
> Un programma un minimo complesso fa uso dei servizi del sistema operativo.
> Alcuni esistono più o meno ovunque, altri sono più specifici. E comunque anche
> quelli più generali possono essere molto diversi fra un sistema e l'altro.

Non so che dire, non riesco a pensare ad un programma che obbligatoriamente richieda l'uso di elementi specifici del SO.
Certo, dipende dal campo applicativo... sto ragionando seguendo il tema Aziende -> Gestionali, mentre se si trattasse di acquisizione dati da sensori l'applicativo sarebbe di più basso livello, anche se pure qui le cose stanno evolvendosi notevolmente.

> Per dire, in VMS la command line (pre-tokenizzata dal paser DCL che ne verifica
> la correttezza formale) si maneggia con varie chiamate a servizi di sistema, fra
> i quali CLI$GET_VALUE. Se porti il programma su Unix, dovrai rifare quella parte
> di programma perché non si tratta solo di sostituire una chiamata con una
> diversa (cosa che si potrebbe tentare con awk o sed), ma devi proprio modificare
> la logica del programma visto che avrai una command line diversa, con una
> sintassi diversa e dovrai gestirtela dentro il programma, magari con un po' di
> getopt() qua e là. Un'altra strada potrebbe essere quella di implementare un
> parser DCL che abbia la funzione CLI$GET_VALUE, ma poi ti scontreresti, fra le
> altre cose, non solo con la complessità della sintassi DCL, ma anche con la
> consuetudine Unix che assegna al carattere '/' un significato diverso. Insomma,
> sono cose complesse e da valutare attentamente, specie quando i programmi sono
> tanti. E questo è solo un esempio, ma ce ne sono mille: ogni punto in cui un
> programma si interfaccia con il sistema va rivalutato e probabilmente rifatto.
>
> Potrei anche raccontarti di come si fa in OS/400 a recuperare le caratteristiche
> di un device (si fa chiamando QDCRDEVD), ma te lo risparmio. In Unix credo si
> faccia con una chiamata a stat() e/o andando a vedere in /dev, /proc o /sys. In
> VMS invece si fa chiamando SYS$GETDVI. Ovviamente non cambiano solo i nomi delle
> funzioni, ma anche tutti i concetti e le strutture passate e ricevute.
>
> Sono solo due esempi, ma prova a pensare a quante volte fai uso dei servizi del
> sistema operativo in una procedura complessa.

Si capisco l'esempio, almeno credo.
Molti degli applicativi su cui ho messo mano però richiedono al massimo dei cronjobs e qualche file shell.
Per ottenere le caratteristiche di un device... il sistema operativo non dovrebbe astrarre i device per l'uso agli umani?
Se no a che serve?
Tanto vale scrivere l'applicativo per girare su "bare metal" :)
E quali device?
Stampanti?
Schede proprietari di acquisizione dati?

> Questo per quanto riguarda i programmi. Per quanto riguarda invece i dati, forse
> la faccenda è un po' più semplice, anche se pure lì possono esserci delle belle
> sorprese. Per esempio, mentre i dati alfanumerici sono più o meno uguali ovunque
> (fatti salvi i terminatori di stringa che invece sono un mondo a parte), i dati
> numerici sono tutti da rivedere. Intanto c'è da tenere presente che potresti
> avere problemi di endianess, poi ad esempio i numeri in virgola mobile possono
> essere in diversi formati (non c'è solo lo standard IEEE). Ci sono anche i
> numeri packed, tanto amati dall'IBM, ma che altrove sono rari e quindi vanno
> quasi certamente convertiti. Può darsi che quasi per ogni tabella tu debba
> scrivere un programma di conversione, o magari anche due: da formato vecchio a
> formato di transito, e da formato di transito a formato nuovo.

Il problema è sempre uscire dal sistema chiuso.
Chi l'ha fatto prima è più libero, gli altri dovranno liberarsi prima o poi.
La conversione dati, per quanto non sempre triviale, è comunque possibile.

> Dopodiché, parlando di dati si torna ai programmi: in VMS e nel mondo IBM c'è il
> concetto di record già nel filesystem, in Unix no. Quindi ogni occorrenza di
> un'istruzione READ o REWRITE a indici va sostituita con le equivalenti istruzoni
> select o update SQL, le quali a loro volta richiedono un cursore, quindi dovrai
> riguardarti praticamente ogni programma e aggiungere di sana pianta tutto il
> codice necessario, compresa la valutazione dei codici di ritorno tipo SQLCODE (e
> se c'è anche SQLSTATE) dopo ogni chiamata al database.
>
> Eccetra, eccetra, eccetra. Tecnicamente tutto è fattibile, ma spesso sarebbero
> necessari tempi e costi insostenibili. Senza contare i nuovi bug.

Un programma che usasse le READ e REWRITE del SO per ottenere dei record dati dal SO deve essere un programma che gira in una shell.
Capisco che scrivere un programma in DCL non è come farlo in file batch del MSDOS, ma più simile ad un programma BASH.
Però... sarò stupido... ci sono sistemi migliori... anche fosse solo per editing o debug... boh... evidentemente è un mio limite :)

> [Azienda che fa manutenzione su vecchi sistemi]
> > Si ma quelle aziende che fanno supporto avranno ogni anno ridotto il proprio
> > mercato, ad ogni 31/12 le probabilità di rimanere senza un solo cliente attivo
> > sono altissime, e affidarsi solo al supporto di sistemi legacy è un bel rischio.
>
> Non fa assistenza solo a roba ultraventennale, ovviamente. Quella è e rimane una
> nicchia, molto remunerativa però: ogni volta che vendono una vecchia scheda a
> qualcuno che ne ha bisogno, per quella giornata potrebbero anche chiudere lì. :)

Oh!
E quando vanno a fare assistenza (molto remunerativa) i clienti li maledicono :)
E ogni volta pensano "forse è ora di cambiare" :)

> Magari girano tuttora su 3270. :) Non ho idea di cosa usi Equitalia, ma non mi
> meraviglierei affatto se si scoprisse che il back-end gira su 390, anche perché
> direi che è la norma quando si parla di grossi enti (vedi sopra).

L'ultima volta che sono passato avevano un emulatore 3270 in finestra di Internet Explorer...
Ma è tanto che non vado, erano miei clienti quando era una azienda di riscossione locale, da quando si chiama Equitalia non sono più clienti (il che in qualche modo mi solleva anche)

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

Ok i tools, ma per GNV... non è che sia proprio up-to-date...
Almeno a giudicare dalla sezione download di sf.net

> 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 GNV è un po' un accrocchio :)
Non credo (ma non posso verificarlo) che basti prendere il codice e ricompilarlo su VMS ma anzi penso richieda pesanti patch.

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

Alla faccia dei web services... sistemiamo prima la printf() :)
Scherzo dai :)

> 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

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

[G.]

On Mon, 25 Aug 2014 16:41:21 -0700 (PDT), Gianluca Bonetti <g...@decadence.it>
wrote:

> Se non erro sui PDP11 è possibile impostare un interrupt in base alla frequenza
> della CPU, ad un timing fisso, oppure alla frequenza della corrente in input.
> Mi sbaglio?

Di preciso non saprei, perché di PDP-11 non so praticamente nulla. Considerando
che era molto usato per controlli real-time, non mi meraviglierei affatto se
avesse funzioni del genere. Quasi certamente i modelli più vecchi derivavano il
clock della CPU dalla frequenza della linea di alimentazione, tant'è vero che
durante la generazione del sistema era necessario specificare se era 50 o 60 Hz.
Cosa che succedeva anche con i modelli più vecchi di PDP-10, poi resero il tutto
indipendente, probabilmente con un apposito cristallo su una scheda della CPU.

> Bella sfida... se uno ha seguito un po' la vicenda negli ultimi anni non è che
> si affiderebbe a VSI alla cieca. Cioè... *TU* lo faresti? Affidare un tuo nuovo
> progetto alla piattaforma VSI+VMS?

Attualmente no, perché anche se esiste VSI siamo ancora in una fase in cui è
come se non esistesse, quindi le garanzie di HP non sono sufficienti. In un
futuro chissà. Non sappiamo come potrà andare, anche se possiamo fare qualche
ipotesi. Magari chiudono in fretta, magari sopravvivono per 20 anni come ha
fatto Mentec, magari sfondano (nei limiti del possibile e delle proporzioni).

Se diventasse una soluzione possibile e rispondente alle mie necessità, perché
no? Del resto c'è stato un tempo in cui Linux era solo un gadget da nerd e
nessuno si sarebbe sognato di sceglierlo per qualcosa di serio: guarda ora com'è
la situazione (e incidentalmente come stanno gli altri Unix)... :)

> Per fare un esempio che mi tange, ho molto codice scritto in un dialetto del
> BASIC specifico (proprietario) di un software gestionale per il mercato
> italiano. E' talmente raro che non figura neanche nella lista dei dialetti del
> BASIC sulla Wikipedia :) Per essere un dialetto proprietario di un gestionale, è
> anche troppo ben fatto: compila in bytecode (eseguibile solamente nel gestionale
> che è la sua VM, per così dire) e ha un ottimo accesso alla base dati
> proprietaria. Per il resto è pessimo: non strutturato, limitazioni all'accesso
> alla memoria a 128k, e altre limitazioni peggiori. Quindi richiede al
> programmatore 10 volte il tempo che ci vorrebbe a farlo con un altro strumento.

Molto interessante (sul serio, non sono ironico). Ma dimmi un po', la VM su cosa
gira (su quali sistemi operativi)? Ed è possibile scrivere programmi esterni
alla VM che dialogano con i programmi Basic all'interno? E verso gli utenti che
interfaccia ha? Da come l'hai descritto dev'essere un animale ben strano... :)

Cioè, tu cos'hai riscritto? Programmi che girano dentro la VM? Programmi esterni
che funzionano senza la necessità della VM? Un po' e un po'?

(Sì, ho capito che è una VM sui generis, ma l'ho chiamata così per semplicità.)

> > Di tutti quelli che hai citato, l'unico linguaggio per il quale pare esistere un
> > interprete per Linux è Rexx. Per gli altri direi che non c'è nulla. E finché si
> > parla di "lingue morte" va anche bene, tutto sommato. Ma se parliamo di lingue
> > vive - per quanto relativamente rare - come l'RPG (uno a caso :P), che si fa?
>
> Riscrivere... Un po' per volta prima di non avere alternative.
> Chi ben comincia è a metà dell'opera! :)

Sì, sempre partendo dall'assunto che qualunque cosa non giri su Unix sia morta.

Dovresti farti un giretto su it.comp.as400 e luoghi simili (dove c'è gente molto
più talebana di me, ma soprattutto molto più aggiornata sulle tecniche più
recenti, web service compresi) e provare a dire che tu rifaresti tutto da capo
(tra l'altro: in quale linguaggio? non ne abbiamo mai parlato) perché secondo te
è tutta roba destinata a sparire più o meno entro breve. E poi aspettare... :D

> > (A proposito di linguaggi non subito facili da migrare, su un VAX recuperato da
> > qualche parte ricordo di aver trovato un centinaio di sorgenti Dibol...)
>
> Codice ancora in uso? Magari era codice vecchio già riscritto!

Ritengo fosse codice ancora in uso, dato che era collegato agli utenti (cioè se
facevi login con uno dei nomi utente originali ti ritrovavi dentro al menu
principale dell'applicazione). Poi, visto che il tutto era dentro un vecchio VAX
che avevamo recuperato, evidentemente lì non era più roba uso, ma non sappiamo
se fu trasferita di peso su una macchina più nuova o se fu riscritta.

> > Guarda che 1.800 non è mica una gran cifra! Ho qui un pacchetto per la gestione
> > finanziaria (carte di credito, prestiti, leasing, cessione del quinto, etc.) che
> > è composto da 5.516 programmi CLP, 17.203 programmi Cobol, 6.654 definizioni fra
> > tabelle e relativi indici, 6.066 definizioni di display video (per altrettanti
> > programmi interattivi fra i suddetti 17mila) e 5.401 pannelli di testo di aiuto.
> >

> > [...]

>
> Mi riferivo al fatto che 1800 procedure aggiuntive su un pacchetto standard
> sarebbe troppo. Gli esempi che citi sembrano per dimensione più sistemi software
> ad hoc per aziende di livello enterprise che pacchetti standard.

Quelle 1800 non sono procedure aggiuntive: sono parte integrante del pacchetto
standard! E anche il secondo esempio che ho citato (quello quotato qui sopra)
non è un pacchetto ad hoc per un'azienda specifica, ma è "semplicemente" un
pacchetto italiano per società finanziarie e affini, utilizzato dai nomi più
noti del settore (fra cui quelli che magari vedi nei centri commerciali quando
compri qualcosa di costoso con un finanziamento). Poi non è detto che ognuna di
queste società usi proprio tutte tutte le funzionalità, però volendo ci sono.

E allo stesso modo quasi tutte le suddette società hanno le loro specifiche
personalizzazioni, sia sotto forma di modifiche ai programmi standard, sia come
programmi esterni chiamati dai programmi standard in punti e momenti precisi.

(Se vuoi dettagli più espliciti tipo nomi etc. te li do in privato, non qui.)

> > Un programma un minimo complesso fa uso dei servizi del sistema operativo.
> > Alcuni esistono più o meno ovunque, altri sono più specifici. E comunque anche
> > quelli più generali possono essere molto diversi fra un sistema e l'altro.
>
> Non so che dire, non riesco a pensare ad un programma che obbligatoriamente
> richieda l'uso di elementi specifici del SO.

> [...]

> Si capisco l'esempio, almeno credo. Molti degli applicativi su cui ho messo mano
> però richiedono al massimo dei cronjobs e qualche file shell.

Forse non ho fatto gli esempi migliori, ma insomma, mi sembra banale dover dire
che un pacchetto appena un po' complesso è comunque "tagliato addosso" a un
certo sistema operativo. Anche cose sciocche come verificare l'esistenza di un
file si fanno in modi diversissimi in base al sistema operativo sui si lavora.

Nelle 1800 procedure pensa a quante volte verrà creato un qualunque piccolo file
temporaneo, con tutte le sue caratteristiche (quindi non un banale stream di
byte, ma qualcosa di più simile a una tabella di database), il quale poi verrà
riempito, utilizzato e infine svuotato o eliminato.

Su sistemi diversi i file (le tabelle) si creano in modi diversi, quindi in un
progetto di migrazione non solo si dovrebbero riscrivere tutte le 1800 procedure
(ciascuna lunga anche varie decine se non centinaia di righe), ma pure tutte le
descrizioni accessorie utilizzate da quelle procedure per creare i file: in
fondo al messaggio ti allego un esempio di FDL (File Description Language) per
VMS che crea un semplice file indicizzato con una sola chiave.

Hai presente il vecchio dBase III per DOS? Ecco, pensa a una cosa del genere, ma
molto più potente, centralizzata e perfettamente integrata nel nocciolo del
sistema operativo; non un prodotto a parte. I file FDL di VMS (o altri metodi
altrove) servono per generare l'equivalente dei vecchi file .DBF di dBase III:

$ CREATE <tuofile>.RMS /FDL=<tuofile>.FDL

Avevo anche descritto i vari modi per ricevere i parametri con cui un programma
viene chiamato, diversissimi fra i vari sistemi operativi (perché i sistemi
operativi collaborano con i programmi in modi diversi per la raccolta parametri;
Unix di fatto non collabora e il programma deve arrangiarsi da solo). Pensa a
quante volte quei 1800 programmi (per non dire quegli altri 17mila) si chiamano
e si passano e si restituiscono dei parametri. Ecco, ora porta tutto su un
sistema che non ha lo stesso meccanismo, o che magari non ce l'ha affatto e che
al massimo ti fornisce strutture primitive come argc e argv...

> Per ottenere le caratteristiche di un device... il sistema operativo non
> dovrebbe astrarre i device per l'uso agli umani? Se no a che serve? Tanto vale
> scrivere l'applicativo per girare su "bare metal" :) E quali device? Stampanti?
> Schede proprietari di acquisizione dati?

Per esempio potrei aver bisogno di sapere se dentro una certa unità nastri c'è
una cassetta piuttosto che un'altra, oppure potrei aver bisogno di sapere se sto
dialogando con un terminale che può visualizzare 132 colonne invece di 80, o
magari potrei voler sapere se su una certa stampante è stata caricata la carta
normale anziché gli assegni, etc. etc. etc. Tutte operazioni di alto livello per
le quali i device astraggono completamente l'hardware. Però appunto, in qualche
modo bisogna interrogare il sistema e le sue astrazioni.

Del resto anche fare 'cat /proc/<qualcosa>' è accedere a un'astrazione.

Per non dire delle astrazioni che fa VMS con gli application terminal virtuali:
il programma crede di dialogare con un semplice "terminale" e invece sotto c'è
una connessione TCP/IP (o LAT o DECnet) per la quale lui non deve assolutamente
fare nulla di più che "aprire" il device e vedere se è pronto.

La quale astrazione, tra l'altro, permette l'esecuzione dello stesso programma
senza cambiare una virgola anche su trasporti diversissimi come TCP/IP vs. LAT.

> Il problema è sempre uscire dal sistema chiuso. Chi l'ha fatto prima è più
> libero, gli altri dovranno liberarsi prima o poi.

Sai, in questi giorni mi è capitato di pensare un po' a sta faccenda del sistema
chiuso vs. sistema aperto, e sono abbastanza giunto alla conclusione, anche per
esempio parlandone con altri su #retrocomputing (perché non vieni a trovarci?!),
che in realtà siano tutti sistemi chiusi e aperti nello stesso momento: già chi
volesse migrare da uno Unix a un altro (penso anche solo a Linux e BSD) avrebbe
un po' di lavoro da fare; chi poi volesse migrare fra altri sistemi (anche nel
caso in cui si escluda Unix dall'affare) si troverebbe non poco in difficoltà.
Quindi alla fine, visto che non c'è un vero e proprio leader indiscusso in tutti
i settori, si tratta di tanti sistemi tutti più o meno incompatibili tra loro
che si contendono vari mercati nei quali di volta in volta uno è leader e altri
vanno un po' alla rincorsa, per un motivo o l'altro.

> Un programma che usasse le READ e REWRITE del SO per ottenere dei record dati
> dal SO deve essere un programma che gira in una shell. Capisco che scrivere un
> programma in DCL non è come farlo in file batch del MSDOS, ma più simile ad un
> programma BASH. Però... sarò stupido... ci sono sistemi migliori... anche fosse
> solo per editing o debug... boh... evidentemente è un mio limite :)

Più che altro mi sembra che tu abbia fatto una bella confusione. :P

Nei programmi Basic della VM di cui dicevi, se tu volessi (per dire) leggere i
dati di un cliente dall'anagrafica clienti, come faresti? useresti un'istruzione
SQL oppure istruzioni Basic standard tipo READ o ancora altra roba non standard?

Le istruzioni READ e REWRITE che dico io non sono "del sistema operativo", ma di
almeno un paio di linguaggi di programmazione (Cobol e Fortran), perciò non
hanno nulla a che fare con alcuna shell. Una differenza tra Unix e altri sistemi
sta nel fatto che Unix di default non ti offre nulla di più di uno stream di
byte, mentre altri (VMS, IBM, etc.) già nel filesystem hanno i concetti basilari
di record e di indice, quindi è quasi come avere un database sempre disponibile:
vedi a questo proposito il parallelo che facevo prima col venerabile dBase III.

(In C si userebbero fread(), fwrite(), fscanf(), fprintf(), etc. che però, di
nuovo, non conoscono le astrazioni necessarie per manipolare record e indici.)

Se migri a Unix un pacchetto che proviene da un sistema del genere, dovrai
trovare un modo per fare le stesse cose senza quello specifico supporto da parte
del sistema operativo, per esempio sostituendolo con un database SQL.

Io infatti scrivevo:

| Dopodiché, parlando di dati si torna ai programmi: in VMS e nel mondo IBM c'è
| il concetto di record già nel filesystem, in Unix no. Quindi ogni occorrenza
| di un'istruzione READ o REWRITE a indici va sostituita con le equivalenti
| istruzoni select o update SQL, le quali a loro volta richiedono un cursore,
| quindi dovrai riguardarti praticamente ogni programma e aggiungere di sana
| pianta tutto il codice necessario, compresa la valutazione dei codici di
| ritorno tipo SQLCODE (e se c'è anche SQLSTATE) dopo ogni chiamata al database.

Esempio in Cobol per leggere i dati del cliente AB1234:

MOVE 'AB1234' TO CODICE-CLIENTE
READ ANAGRAFICA INTO DATI-CLIENTE
INVALID KEY
DISPLAY 'Cliente non trovato'
NOT INVALID KEY
<qui elabora>
END-READ.

Oppure:

MOVE 'AB1234' TO CODICE-CLIENTE
READ ANAGRAFICA INTO DATI-CLIENTE
IF FILE-STATUS = '00'
<qui elabora>
ELSE
DISPLAY 'Errore lettura anagrafica: ', FILE-STATUS
END-IF.

ANAGRAFICA sarebbe il nome simbolico del file con l'anagrafica clienti, qualcosa
di simile agli handle tipo '#1' del Basic. DATI-CLIENTE sarebbe il tracciato
record del suddetto file e CODICE-CLIENTE sarebbe il campo chiave all'interno
del tracciato, cioè uno dei tanti campi del medesimo.

Un'ipotetica riscrittura per SQL (che però presuppone che "sotto" ci sia un
database SQL e che il compilatore Cobol supporti in qualche modo le embedded
query), e sottolineo riscrittura più che migrazione, potrebbe essere così:

MOVE 'AB1234' TO CODICE-CLIENTE

EXEC SQL
SELECT <elenco campi>
FROM <tabella angrafica>
INTO <elenco variabili>
WHERE CUST-CODE = :CODICE-CLIENTE
END-EXEC

EVALUATE SQLCODE
WHEN < 0
DISPLAY 'Errore: ', SQLCODE
WHEN > 0
DISPLAY 'Warning: ', SQLCODE
WHEN OTHER
<qui elabora>
END-EVALUATE.

Al momento (?) GNU Cobol non supporta questo modo di procedere e usa la libreria
Berkley DB di Oracle per fornire un accesso analogo a quello dei primi due
esempi qui sopra, ma ancora non sufficiente per un vero uso pratico (tanto per
dire: non supporta le cosiddette split keys e non c'è modo né di definire né di
manipolare i dati al di fuori dei singoli programmi). È una mancanza paradossale
perché costringe a servirsi di software di terze parti (es. Microfocus) che è
proprietario, non del tutto standard, e molto costosamente a pagamento.

Il file FDL di cui scrivevo prima serve per creare i file a indici a cui poi si
accede come ho appena mostrato. In un'ipotetica migrazione, il file FDL si può
anche analizzare ed elaborare con strumenti tipo awk, ma il problema rimane cosa
fare delle informazioni che contiene, cioè come trasformarle in qualcosa di
accessibile come un DB. Si potrebbe provare a trasformare ogni FDL in un CREATE
TABLE, ma poi ci sarebbe da mettere pesantemente mano a tutti i programmi che
utilizzavano il file per trasformarli in programmi SQL (vedi terzo esempio)...

Si fa tutto, eh. È sempre un problema di costi, sia in senso stretto (danaro)
sia in senso lato (tempo e ritorno economico di un'operazione del genere) sia in
senso tecnico (pensa a quanti bug si possono introdurre in 17mila (!) programmi
Cobol riscritti a mano uno per uno come mostrato sopra).

Considerando la complessità di certi programmi, credo che sia già una ipotesi
impossibile quella di tradurre (leggi: rifare) un programma al giorno, ma
facciamo finta che in media sia possibile (perché ci sono programmi più facili
per i quali ci vuole meno tempo): 17mila programmi sono 17mila giorni, cioè 65
anni (ipotizzando di lavorare cinque giorni la settimana, senza neppure una
settimana di vacanza o di malattia). Se fai fare il lavoro a 10 persone gli anni
diventano 6,5. Io per prudenza aumenterei la cifra di una buona metà perché i
programmatori non lavorano come criceti nella ruota e in più c'è tutto il debug
e il testing da fare; diciamo allora 9,75 anni. Se poi ci aggiungi che nel
frattempo anche il software pre-migrazione continua ad evolvere e quindi gli
devi "correre dietro", gli anni diventano più di 10 (e secondo me è una ipotesi
molto più che rosea, quasi utopistica direi). Se poi fra i sorgenti c'è roba che
contiene cose tipo EXEC CICS o EXEC DLI, allora ciao!

Quando arrivi dopo 10 anni ad aver rifatto tutto per Linux/Unix, nel frattempo
chissà cosa c'è nel mondo, specie in quello di certa informatica che è sempre in
evoluzione rapidissima (e tumultuosissima).

E questo vale per i soli sorgenti Cobol, che appunto da soli non servono a
niente se non hanno i dati a cui accedere o i mezzi per interfacciarsi con gli
utenti, dunque ci sono le altre decine di migliaia di sorgenti da prendere in
considerazione. Puoi aggiungere altri programmatori al team principale, in modo
da rimanere nei 10 anni, ma poi li devi anche pagare; la cosa incomincia a
diventare un po' molto costosa se non sei l'IBM o quasi...

(E naturalmente non rientra nel conteggio tutto il tempo necessariamente speso
per la pianificazione tecnica e finanziaria di un'operazione del genere.)

> > [Azienda che fa manutenzione su vecchi sistemi]
> > > Si ma quelle aziende che fanno supporto avranno ogni anno ridotto il proprio
> > > mercato, ad ogni 31/12 le probabilità di rimanere senza un solo cliente attivo
> > > sono altissime, e affidarsi solo al supporto di sistemi legacy è un bel rischio.
> >
> > Non fa assistenza solo a roba ultraventennale, ovviamente. Quella è e rimane una
> > nicchia, molto remunerativa però: ogni volta che vendono una vecchia scheda a
> > qualcuno che ne ha bisogno, per quella giornata potrebbero anche chiudere lì. :)
>
> Oh!
> E quando vanno a fare assistenza (molto remunerativa) i clienti li maledicono :)
> E ogni volta pensano "forse è ora di cambiare" :)

Tu sei troppo sicuro delle tue idee. :P C'è chi li benedice perché costano meno
dell'IBM e/o perché hanno roba che l'IBM dice di non tenere più (a meno che uno
non abbia agganci molto in alto e/o sia pronto a sputare sangue dorato) e c'è
chi dice che mai soldi furono meglio spesi (un atteggiamento un po' da copertina
di Linus, ma tant'è)... Chi li maledice è una minoranza perché anche chi pensa
che sia ora di cambiare si rivolge poi a loro per sostituire il vecchio S/36 con
un AS/400, usato, ovviamente: vuoi che gente che ha ancora lì il 36 compri una
macchina nuova? Figuriamoci! :)

> Anche GNV è un po' un accrocchio :) Non credo (ma non posso verificarlo) che basti
> 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

[nda]

Gianluca Bonetti <g...@decadence.it> wrote:

> Il kernel Linux ad esempio � noto per essere GCC dipendente,
> quindi non compila con altri compilatori (forse qualcosa �

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

[Gianluca Bonetti]

Il giorno sabato 6 settembre 2014 00:45:46 UTC+2, G. ha scritto:
Uè, qua ci vuole una settimana per rispondere ad un messaggio così! :)

> > Bella sfida... se uno ha seguito un po' la vicenda negli ultimi anni non è che
> > si affiderebbe a VSI alla cieca. Cioè... *TU* lo faresti? Affidare un tuo nuovo
> > progetto alla piattaforma VSI+VMS?
>
> Attualmente no, perché anche se esiste VSI siamo ancora in una fase in cui è
> come se non esistesse, quindi le garanzie di HP non sono sufficienti. In un
> futuro chissà. Non sappiamo come potrà andare, anche se possiamo fare qualche
> ipotesi. Magari chiudono in fretta, magari sopravvivono per 20 anni come ha
> fatto Mentec, magari sfondano (nei limiti del possibile e delle proporzioni).

Mentec ha catalizzato un interesse molto forte in un settore in cui reali alternative non c'erano.
Tant'è che ma General Electric del Canada ricerca programmatori PDP11 fino al 2050.
Cioè non esistevano sistemi operativi RealTime per x86, o se esistevano non hanno avuto fortuna, o non erano comunque all'altezza.
Mentec non ha preso un cavallo mezzo morto, ma un purosangue un po' vecchiotto, con un parco clienti molto fidelizzato.
Per quello che si fa su VMS, oggi esistono alternative, e il parco clienti non so quanto sia così fidelizzato.
Voglio dire, la parentesi indiana del supporto era espressamente studiata per rovinare la reputazione di VMS.
Se ci fossero riusciti anche solo a metà...

> Se diventasse una soluzione possibile e rispondente alle mie necessità, perché
> no? Del resto c'è stato un tempo in cui Linux era solo un gadget da nerd e
> nessuno si sarebbe sognato di sceglierlo per qualcosa di serio: guarda ora com'è
> la situazione (e incidentalmente come stanno gli altri Unix)... :)

Linux è ancora nella sua parabola crescente, non si sa per quanto durerà questa fase ma ancora non è terminata.
Per VMS non si può proprio dire che sia nato adesso e con tante possibilità di crescere.
Quello che poteva fare lo ha fatto, il suo stato dell'arte lo ha già raggiunto, si può solo manterenere così com'è, magari lavorando sulle performance, non non credo sulle features.

> > Per fare un esempio che mi tange, ho molto codice scritto in un dialetto del
> > BASIC specifico (proprietario) di un software gestionale per il mercato
> > italiano. E' talmente raro che non figura neanche nella lista dei dialetti del
> > BASIC sulla Wikipedia :) Per essere un dialetto proprietario di un gestionale, è
> > anche troppo ben fatto: compila in bytecode (eseguibile solamente nel gestionale
> > che è la sua VM, per così dire) e ha un ottimo accesso alla base dati
> > proprietaria. Per il resto è pessimo: non strutturato, limitazioni all'accesso
> > alla memoria a 128k, e altre limitazioni peggiori. Quindi richiede al
> > programmatore 10 volte il tempo che ci vorrebbe a farlo con un altro strumento.
>
> Molto interessante (sul serio, non sono ironico). Ma dimmi un po', la VM su cosa
> gira (su quali sistemi operativi)? Ed è possibile scrivere programmi esterni
> alla VM che dialogano con i programmi Basic all'interno? E verso gli utenti che
> interfaccia ha? Da come l'hai descritto dev'essere un animale ben strano... :)

Dunque, è un gestionale che ha una ventina di anni o più, orientato alle PMI, che gira su Windows e su Linux (50%/50% del parco installato, i miei clienti sono tutti su Linux a parte le monutenze).
Inizialmente lavorava in telnet/ssh con interfaccia carattere, poi verso il 2000 il client è diventata un client leggero, potresti considerarlo un browser proprietario o un emulatore di terminale proprietario, che converte la matrice carattere in UI grafica.
I programmi che ho scritto in questo mezzo BASIC sono stampe che vanno oltre la logica di base del gestionale, oppure funzionalità aggiuntive.
E' possibile invocare l'esecuzione di questi programmi da linea di comando, e in questo modo girano in maniera "headless" con I/O su file.

> Cioè, tu cos'hai riscritto? Programmi che girano dentro la VM? Programmi esterni
> che funzionano senza la necessità della VM? Un po' e un po'?
>
> (Sì, ho capito che è una VM sui generis, ma l'ho chiamata così per semplicità.)

Per via dell'accesso alla base dati bisogna comunque che il programma giri sulla "VM", anche se qualcuno viene invocato da linea di comando (cioè, via cron).
Ho scritto delle stampe di analisi dati e altre stampe varie.
Il lavoro più grosso è un applicativo di produzione, perché il modulo disponibile per il programma è molto costoso e chi lo ha visto o usato lo considera molto farraginoso, quindi per me è stato necessario riscriverlo.
Un altro lavoro altrettanto voluminoso è un applicativo per la lavorazione delle carni, con tracciabilità.
Col mio programma si producono ottimi salumi in un noto salumificio vicino a Pesaro! :)

Entrambi gli applicativi lavorano nel client del gestionale, con un paio di procedure schedulate per la notte via cronjob per quanto riguarda le carni.
Entrambi questi due applicativi sono un mio grande cruccio.
Ho faticato molto a scriverli, ogni volta che ci devo mettere mano è faticosissimo (è un BASIC che non conosce programmazione strutturata... cioè si, un minimo, ma proprio minimo) e soprattutto se li avessi scritti con altri strumenti, sarei svincolato dal gestionale/VM per tutta una serie di vantaggi, sia tecnici, che commerciali.
Per questo, sto già riscrivendo la produzione, nel 2015, riscriverò la parte alimentare.
Per questo, ti dico con cognizione di causa, riscrivere con strumenti più nuovi è più facile che fare manutenzione sul vecchio.
Poi sicuramente esisteranno altri linguaggi migliori, su cui fare manutenzione sarà una passeggiata piacevole, ma la mia esperienza è questa...

> > Riscrivere... Un po' per volta prima di non avere alternative.
> > Chi ben comincia è a metà dell'opera! :)
>
> Sì, sempre partendo dall'assunto che qualunque cosa non giri su Unix sia morta.

Touché :)
Ma solo in parte.
Tu pensi che io ho in mente solo Linux, non è così.

> Dovresti farti un giretto su it.comp.as400 e luoghi simili (dove c'è gente molto
> più talebana di me, ma soprattutto molto più aggiornata sulle tecniche più
> recenti, web service compresi) e provare a dire che tu rifaresti tutto da capo
> (tra l'altro: in quale linguaggio? non ne abbiamo mai parlato) perché secondo te
> è tutta roba destinata a sparire più o meno entro breve. E poi aspettare... :D

Oh, si, ci ho discusso una volta di persona con un talebano degli AS400, per questo non voglio più parlare di AS400 :)
Il problema è che si, oggi si fa tutto su AS400, anche interfacce web, web services, ecc...
Ma *quando* il sistema è arrivato a fare questo?
E *quando* i programmatori hanno iniziato a sfruttare queste possibilità?
Voglio dire, vedo siti web di aziende del settore AS400 che pubblicizzano *oggi* come svecchiare gli applicativi dandogli una facciata web!
Comunque, nel frattempo, altri sistemi correvano molto veloce, e il gap è difficile da colmare.
Non basta compilare Apache2+PHP5 e farlo girare su System i per renderlo una piattaforma così appetibile.

> > Codice ancora in uso? Magari era codice vecchio già riscritto!
>
> Ritengo fosse codice ancora in uso, dato che era collegato agli utenti (cioè se
> facevi login con uno dei nomi utente originali ti ritrovavi dentro al menu
> principale dell'applicazione). Poi, visto che il tutto era dentro un vecchio VAX
> che avevamo recuperato, evidentemente lì non era più roba uso, ma non sappiamo
> se fu trasferita di peso su una macchina più nuova o se fu riscritta.

L'universo è grande! :)

> Quelle 1800 non sono procedure aggiuntive: sono parte integrante del pacchetto
> standard! E anche il secondo esempio che ho citato (quello quotato qui sopra)
> non è un pacchetto ad hoc per un'azienda specifica, ma è "semplicemente" un
> pacchetto italiano per società finanziarie e affini, utilizzato dai nomi più
> noti del settore (fra cui quelli che magari vedi nei centri commerciali quando
> compri qualcosa di costoso con un finanziamento). Poi non è detto che ognuna di
> queste società usi proprio tutte tutte le funzionalità, però volendo ci sono.
>
> E allo stesso modo quasi tutte le suddette società hanno le loro specifiche
> personalizzazioni, sia sotto forma di modifiche ai programmi standard, sia come
> programmi esterni chiamati dai programmi standard in punti e momenti precisi.

Ok, allora qui ci rimettiamo in linea.
1800 procedure per un pacchetto così non sono poche, probabilmente il giusto.
Il mio lavoro attuale consiste in 415 classi e 85 file vari (UI, reports) e fa solo magazzino e customer service, per cui 1800 procedure nel pacchetto standard di un sistema finanziario sono giuste, anzi siete stati parsimoniosi :)

Mi spaventava l'idea che, dato un pacchetto standard di N procedure, ci fossero 1800 personalizzazioni sopra quello! :)

> (Se vuoi dettagli più espliciti tipo nomi etc. te li do in privato, non qui.)

Se vuoi in privato ti faccio il nome del dialetto del BASIC :)

> > Si capisco l'esempio, almeno credo. Molti degli applicativi su cui ho messo mano
> > però richiedono al massimo dei cronjobs e qualche file shell.
>
> Forse non ho fatto gli esempi migliori, ma insomma, mi sembra banale dover dire
> che un pacchetto appena un po' complesso è comunque "tagliato addosso" a un
> certo sistema operativo. Anche cose sciocche come verificare l'esistenza di un
> file si fanno in modi diversissimi in base al sistema operativo sui si lavora.

Mmm...
Se lo scrivessi in Java, il metodo è lo stesso per qualunque sistema operativo.
Basta usare la stringa java.io.File.separator come separatore anziché presumere "/" o "\\"
Se proprio devo aggiungere qualcosa in testa al path in caso di Windows o altro, posso fare una serie di if-then-else controllando System.getProperty("os.name")
Sono metodi standard in ogni classpath di tutte le JVM dalle specifiche anche più basse.
Ovviamente, basta che ci sia una JVM... ma quasi ovunque c'è, magari datata (come su VMS... 5.0...) però qualcosa c'è.

> Nelle 1800 procedure pensa a quante volte verrà creato un qualunque piccolo file
> temporaneo, con tutte le sue caratteristiche (quindi non un banale stream di
> byte, ma qualcosa di più simile a una tabella di database), il quale poi verrà
> riempito, utilizzato e infine svuotato o eliminato.

Anche creare un file temporaneo è una operazione che si astrae bene.
Sempre in Java, è una operazione "single line" :)

File temp = java.io.File.createTempFile("abc", ".temp");

"Creates an empty file in the default temporary-file directory"
Quindi la JVM sa quale è la directory temporanea, che eventualmente si può cambiare a runtime.
Ma è preferibile rimanere agnostici del S.O. e risparmiarsi ogni problema.

> Su sistemi diversi i file (le tabelle) si creano in modi diversi, quindi in un
> progetto di migrazione non solo si dovrebbero riscrivere tutte le 1800 procedure
> (ciascuna lunga anche varie decine se non centinaia di righe), ma pure tutte le
> descrizioni accessorie utilizzate da quelle procedure per creare i file: in
> fondo al messaggio ti allego un esempio di FDL (File Description Language) per
> VMS che crea un semplice file indicizzato con una sola chiave.

Vero, ma anche qui ci sono grandi possibilità di astrazione.
Bisognerebbe erigere un monumento enorme e indistruttibile nei secoli dei secoli, agli strumenti di persistenza degli oggetti.
Io sono particolarmente appassionato di JDO e in particolare dell'implementazione DataNucleus (open source, http://www.datanucleus.org).

Scrivo le classi specificandole @PersistenceCapable(table="una-tabella-su-un-db-supportato")
Definisco quale campo è @Persistent o @NotPersistent

@PersistenceCapable(table="anagrafiche", detachable="true", identityType=IdentityType.APPLICATION)
@Version(strategy=VersionStrategy.VERSION_NUMBER)
public final class Anagrafiche {
@Persistent(primaryKey="true", valueStrategy=IdGeneratorStrategy.IDENTITY, nullValue=NullValue.EXCEPTION)
@Column(name="id")
@Unique
private long id;
public final long getId() {
return id;
}
public final void setId(long id) {
this.id = id;
}

@Persistent
@Column(name="nome")
private String nome;
public final String getNome() {
return nome;
}
public final void setNome(String nome) {
this.nome = nome;
}

...
}

Poi ad esempio posso persistere i dati così...

// PersistenceManagerFactory e PersistenceManager possono essere creati una volta sola e mantenuti
PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory(props);
PersistenceManager pm = pmf.getPersistenceManager();

Anagrafica obj = new Anagrafica();
obj.setNome("Guybrush");
pm.makePersistent(obj); // obj.id è valorizzato automaticamente con un seriale univoco, come specificato in Class

L'oggetto finisce nel DB, qualunque esso sia, uno JDBC capable, oppure XLS, XML, LDAP, ecc...
Se le tabelle non esistono... vengono create!!! :)
Tutto lo schema può essere migrato in automatico, cambiando nomi ai campi, aggiungendo colonne o rimuovendole, ecc...
Solo degrada le prestazioni e io preferisco farlo esplicitamente a mano, ma si fa anche in automatico.

> Hai presente il vecchio dBase III per DOS? Ecco, pensa a una cosa del genere, ma
> molto più potente, centralizzata e perfettamente integrata nel nocciolo del
> sistema operativo; non un prodotto a parte. I file FDL di VMS (o altri metodi
> altrove) servono per generare l'equivalente dei vecchi file .DBF di dBase III:
>
> $ CREATE <tuofile>.RMS /FDL=<tuofile>.FDL

Il metodo della "Persistenza degli oggetti" invece non è integrato con niente, non confligge con niente, non ha bisogno di tuning del SO (al limite dell'applicativo) ed è altamente portabile per sua natura.

> Avevo anche descritto i vari modi per ricevere i parametri con cui un programma
> viene chiamato, diversissimi fra i vari sistemi operativi (perché i sistemi
> operativi collaborano con i programmi in modi diversi per la raccolta parametri;
> Unix di fatto non collabora e il programma deve arrangiarsi da solo). Pensa a
> quante volte quei 1800 programmi (per non dire quegli altri 17mila) si chiamano
> e si passano e si restituiscono dei parametri. Ecco, ora porta tutto su un
> sistema che non ha lo stesso meccanismo, o che magari non ce l'ha affatto e che
> al massimo ti fornisce strutture primitive come argc e argv...

Si, quei 1800 programmi sono così da sempre e collaborano così da sempre...
Ma... passare ad un sistema di messaggistica?
Tipo MQ (anche quello di IBM :))
Oppure se i programmi trasportassero dati in POST via rete verso http://server.remoto/un/web/service/
Se una volta programmi in linguaggi eterogenei dialogavano per command line, sullo stesso sistema, ora programmi eterogenei dialogano via web service su macchine anche su sistemi differenti (o anche verso la stessa macchina)

Per passare a tutt'altro settore, ti faccio questo esempio di REST API scritte veramente bene, anche ottimanete documentate.
Qualunque cosa stai scrivendo, ovunque giri, puoi esportare i dati su Wordpress mediante queste semplici chiamate web.
http://developer.wordpress.com/docs/api/
Tra l'altro, la documentazione mi sembra veramente ben fatta.

> > Per ottenere le caratteristiche di un device... il sistema operativo non
> > dovrebbe astrarre i device per l'uso agli umani? Se no a che serve? Tanto vale
> > scrivere l'applicativo per girare su "bare metal" :) E quali device? Stampanti?
> > Schede proprietari di acquisizione dati?
>
> Per esempio potrei aver bisogno di sapere se dentro una certa unità nastri c'è
> una cassetta piuttosto che un'altra, oppure potrei aver bisogno di sapere se sto
> dialogando con un terminale che può visualizzare 132 colonne invece di 80, o
> magari potrei voler sapere se su una certa stampante è stata caricata la carta
> normale anziché gli assegni, etc. etc. etc. Tutte operazioni di alto livello per
> le quali i device astraggono completamente l'hardware. Però appunto, in qualche
> modo bisogna interrogare il sistema e le sue astrazioni.

Mumble mumble...
Nastri... decisamente è una operazione a livello sistemistico, non a livello applicativo.
Permettimi, un applicativo, specialmente contabile, non deve neanche sapere dove finiscono i suoi dati, deve solo sapere che sono sempre disponibili.
Che ne vengano fatte delle copie, è la base della sicurezza dei dati.
E attualmente, con gli storage contemporanei, tutti i dati possono essere sempre disponibili, in repliche multiple, locali e remote.

Terminali... ok... i terminali... mi piacciono, ne ho una ventina in casa... ma... è ora di andare un po' avanti?

Carta nella stampante... ah questa è bella. :)
Allora ti prometto di cercare come posso farlo a livello astratto in Java.
Non ho le specifiche delle stampanti con doppia alimentazione carta+assegni, supporrò che si tratti di carta a4+a3 nelle mie ricerche.
Immagino che, alla peggio, si faccia una procedura C wrapped in Java class.
Ne avevo fatta una per leggere il seriale degli harddisk, era una piccola "protezione hardware".
Non garantisco che avrò la soluzione entro la prossima iterazione di questi messaggi, ma il problema mi è entrato in testa, e finché non lo risolvo non può uscire :)
Comunque questa problematica è una minima frazione di un sistema completo.

> Del resto anche fare 'cat /proc/<qualcosa>' è accedere a un'astrazione.

Credo sia il motivo per cui si inizia ad avere qualcosa di /proc anche sui BSD (l'ultima volta che ho avviato un NetBSD...)

> Per non dire delle astrazioni che fa VMS con gli application terminal virtuali:
> il programma crede di dialogare con un semplice "terminale" e invece sotto c'è
> una connessione TCP/IP (o LAT o DECnet) per la quale lui non deve assolutamente
> fare nulla di più che "aprire" il device e vedere se è pronto.
>
> La quale astrazione, tra l'altro, permette l'esecuzione dello stesso programma
> senza cambiare una virgola anche su trasporti diversissimi come TCP/IP vs. LAT.

Tirarsi il martello nei piedi così, nel 2014, è puro masochismo :)
Ma parto sempre dalla considerazione che i sistemi legacy, siano masochismo, per cui sono prevenuto.
Comunque il mondo sembra che sia andato avanti con TCP e non LAT :)

> > Il problema è sempre uscire dal sistema chiuso. Chi l'ha fatto prima è più
> > libero, gli altri dovranno liberarsi prima o poi.
>
> Sai, in questi giorni mi è capitato di pensare un po' a sta faccenda del sistema
> chiuso vs. sistema aperto, e sono abbastanza giunto alla conclusione, anche per
> esempio parlandone con altri su #retrocomputing (perché non vieni a trovarci?!),

Sarebbe bello... ma... il tempo... chissà forse una volta o due! :)

> che in realtà siano tutti sistemi chiusi e aperti nello stesso momento: già chi
> volesse migrare da uno Unix a un altro (penso anche solo a Linux e BSD) avrebbe
> un po' di lavoro da fare; chi poi volesse migrare fra altri sistemi (anche nel
> caso in cui si escluda Unix dall'affare) si troverebbe non poco in difficoltà.
> Quindi alla fine, visto che non c'è un vero e proprio leader indiscusso in tutti
> i settori, si tratta di tanti sistemi tutti più o meno incompatibili tra loro
> che si contendono vari mercati nei quali di volta in volta uno è leader e altri
> vanno un po' alla rincorsa, per un motivo o l'altro.

Come ti dicevo in precedenza, io credo che il S.O. diventerà un aspetto sempre più marginale in futuro.
1) L'applicativo client diventerà "il/un browser web"
2) Il server diventerà "quello che tiene i dati", qualunque sia il S.O., i server, i dischi, ecc...

E gli applicativi in mezzo.
Se hai degli applicativi scritti per sistemi molto astratti, sicuramente i punti 1 e 2 non sono un tuo problema.
Eliminare i problemi è per natura procurarsi un vantaggio :)

> > Un programma che usasse le READ e REWRITE del SO per ottenere dei record dati
> > dal SO deve essere un programma che gira in una shell. Capisco che scrivere un
> > programma in DCL non è come farlo in file batch del MSDOS, ma più simile ad un
> > programma BASH. Però... sarò stupido... ci sono sistemi migliori... anche fosse
> > solo per editing o debug... boh... evidentemente è un mio limite :)
>
> Più che altro mi sembra che tu abbia fatto una bella confusione. :P

Troppa teoria... preferisco i casi specifici... :)

> Nei programmi Basic della VM di cui dicevi, se tu volessi (per dire) leggere i
> dati di un cliente dall'anagrafica clienti, come faresti? useresti un'istruzione
> SQL oppure istruzioni Basic standard tipo READ o ancora altra roba non standard?

Roba non $tandard >:(

> Le istruzioni READ e REWRITE che dico io non sono "del sistema operativo", ma di
> almeno un paio di linguaggi di programmazione (Cobol e Fortran), perciò non
> hanno nulla a che fare con alcuna shell. Una differenza tra Unix e altri sistemi
> sta nel fatto che Unix di default non ti offre nulla di più di uno stream di
> byte, mentre altri (VMS, IBM, etc.) già nel filesystem hanno i concetti basilari
> di record e di indice, quindi è quasi come avere un database sempre disponibile:
> vedi a questo proposito il parallelo che facevo prima col venerabile dBase III.

Cobol e Fortran hanno compilatori cross-platform però.
Le librerie standard di READ e WRITE si occuperanno di chiedere al SO, che chiederà al filesystem, che chiederà al disco.
Non è che il programmatore deve fare tutto da solo :)

> (In C si userebbero fread(), fwrite(), fscanf(), fprintf(), etc. che però, di
> nuovo, non conoscono le astrazioni necessarie per manipolare record e indici.)

In C standard non credo ci siano, per quel che conosco io, solo con librerie esterne.

> Se migri a Unix un pacchetto che proviene da un sistema del genere, dovrai
> trovare un modo per fare le stesse cose senza quello specifico supporto da parte
> del sistema operativo, per esempio sostituendolo con un database SQL.

Se migro un pacchetto che legge e scrive i suoi dati direttamente su disco con fread() e fwrite() sto decisamente migrando qualcosa che va rifatto.
Senza dubbio, se accede ai dati così, o sono pochi pochi, oppure è il modo sbagliato.
Poi comunque fread() e fwrite() sono C standard, e il C puro è la cosa più cross-compilabile che esista.

> Io infatti scrivevo:
> | Dopodiché, parlando di dati si torna ai programmi: in VMS e nel mondo IBM c'è
> | il concetto di record già nel filesystem, in Unix no. Quindi ogni occorrenza
> | di un'istruzione READ o REWRITE a indici va sostituita con le equivalenti
> | istruzoni select o update SQL, le quali a loro volta richiedono un cursore,
> | quindi dovrai riguardarti praticamente ogni programma e aggiungere di sana
> | pianta tutto il codice necessario, compresa la valutazione dei codici di
> | ritorno tipo SQLCODE (e se c'è anche SQLSTATE) dopo ogni chiamata al database.
>
> Esempio in Cobol per leggere i dati del cliente AB1234:
>
> MOVE 'AB1234' TO CODICE-CLIENTE
> READ ANAGRAFICA INTO DATI-CLIENTE
> INVALID KEY
> DISPLAY 'Cliente non trovato'
> NOT INVALID KEY
> <qui elabora>
> END-READ.
> Oppure:
> MOVE 'AB1234' TO CODICE-CLIENTE
> READ ANAGRAFICA INTO DATI-CLIENTE
> IF FILE-STATUS = '00'
> <qui elabora>
> ELSE
> DISPLAY 'Errore lettura anagrafica: ', FILE-STATUS
> END-IF.

A gusto personale, il promo esempio è più raffinato :)
Ma la sensazione, è la stessa che mi da vedere il colosseo e i fori imperiali :)
O buona parte di casa mia, cioè tutta la parte dove tengo le retromacchine!

> ANAGRAFICA sarebbe il nome simbolico del file con l'anagrafica clienti, qualcosa
> di simile agli handle tipo '#1' del Basic. DATI-CLIENTE sarebbe il tracciato
> record del suddetto file e CODICE-CLIENTE sarebbe il campo chiave all'interno
> del tracciato, cioè uno dei tanti campi del medesimo.
>
> Un'ipotetica riscrittura per SQL (che però presuppone che "sotto" ci sia un
> database SQL e che il compilatore Cobol supporti in qualche modo le embedded
> query), e sottolineo riscrittura più che migrazione, potrebbe essere così:
>
> MOVE 'AB1234' TO CODICE-CLIENTE
> EXEC SQL
> SELECT <elenco campi>
> FROM <tabella angrafica>
> INTO <elenco variabili>
> WHERE CUST-CODE = :CODICE-CLIENTE
> END-EXEC
>
> EVALUATE SQLCODE
> WHEN < 0
> DISPLAY 'Errore: ', SQLCODE
> WHEN > 0
> DISPLAY 'Warning: ', SQLCODE
> WHEN OTHER
> <qui elabora>
> END-EVALUATE.

Si, per chi vuole ancora migrare verso SQL... legacy to legacy :)
Tu qui ipotizzi un percorso di migrazione passando per la base dati in SQL.
Io penso che la migrazione giusta sia mantenere inizialmente la base dati com'è, ma astrarre l'accesso ai dati mediante un connettore (RPC o web service che sia, anche se girasse in locale)
Una volta passati all'uso di un connettore, puoi migrare le parti che vuoi in maniera indipendente, per assurdo puoi tenere i dati come e dove sono e cambiare la piattaforma della logica applicativa.
Non conosco il COBOL e non so se implementare delle RPC o WS con il linguaggio standard sia fattibile.
Provo quindi a fare una ricerca su Google, e vedo che la strada dei Web Service comunque non sembra aliena al mondo IBM.
http://www.ibm.com/developerworks/systems/library/es-webservicesrpg/

> Al momento (?) GNU Cobol non supporta questo modo di procedere e usa la libreria
> Berkley DB di Oracle per fornire un accesso analogo a quello dei primi due
> esempi qui sopra, ma ancora non sufficiente per un vero uso pratico (tanto per
> dire: non supporta le cosiddette split keys e non c'è modo né di definire né di
> manipolare i dati al di fuori dei singoli programmi). È una mancanza paradossale
> perché costringe a servirsi di software di terze parti (es. Microfocus) che è
> proprietario, non del tutto standard, e molto costosamente a pagamento.

Se vivi in un ecosistema proprietario, lo hai scelto e ne paghi il prezzo... a Microfocus! :)

> Il file FDL di cui scrivevo prima serve per creare i file a indici a cui poi si
> accede come ho appena mostrato. In un'ipotetica migrazione, il file FDL si può
> anche analizzare ed elaborare con strumenti tipo awk, ma il problema rimane cosa
> fare delle informazioni che contiene, cioè come trasformarle in qualcosa di
> accessibile come un DB. Si potrebbe provare a trasformare ogni FDL in un CREATE
> TABLE, ma poi ci sarebbe da mettere pesantemente mano a tutti i programmi che
> utilizzavano il file per trasformarli in programmi SQL (vedi terzo esempio)...

Questo mix è complesso... Keep It Silly Stupid.
Astrarre l'accesso ai dati esponendo un web service e accedere ai dati consumando il web service è la strategia migliore.
Il client che accede al WS non sa, non deve sapere, ma soprattutto non gli interessa, in che modo vengano memorizzati i dati o recuperati dallo storage.
Gli interessa solo che i dati siano disponibili, il più velocemente possibile.

> Si fa tutto, eh. È sempre un problema di costi, sia in senso stretto (danaro)
> sia in senso lato (tempo e ritorno economico di un'operazione del genere) sia in
> senso tecnico (pensa a quanti bug si possono introdurre in 17mila (!) programmi
> Cobol riscritti a mano uno per uno come mostrato sopra).
>
> Considerando la complessità di certi programmi, credo che sia già una ipotesi
> impossibile quella di tradurre (leggi: rifare) un programma al giorno, ma
> facciamo finta che in media sia possibile (perché ci sono programmi più facili
> per i quali ci vuole meno tempo): 17mila programmi sono 17mila giorni, cioè 65
> anni (ipotizzando di lavorare cinque giorni la settimana, senza neppure una
> settimana di vacanza o di malattia). Se fai fare il lavoro a 10 persone gli anni
> diventano 6,5. Io per prudenza aumenterei la cifra di una buona metà perché i
> programmatori non lavorano come criceti nella ruota e in più c'è tutto il debug
> e il testing da fare; diciamo allora 9,75 anni. Se poi ci aggiungi che nel
> frattempo anche il software pre-migrazione continua ad evolvere e quindi gli
> devi "correre dietro", gli anni diventano più di 10 (e secondo me è una ipotesi
> molto più che rosea, quasi utopistica direi). Se poi fra i sorgenti c'è roba che
> contiene cose tipo EXEC CICS o EXEC DLI, allora ciao!

Riscrivere il vecchio, ok, ci vuole tempo.
Ma se scrivi qualcosa di nuovo, fallo con un sistema nuovo!
Che ne so, ogni nuovo report, con un sistema di reportistica nuovo, sicuramente orientato al web.
Le procedure più vecchie, quelle vecchie vecchie vecchie, andranno a morire prima o poi.
Voglio dire, se hai un programma di una finanziaria per calcolare un prestito come si faceva nel 2000, potresti anche rimuovere quel programma dal pacchetto prima o poi.
Un percorso di migrazione di un pacchetto così grande sicuramente deve partire da una analisi di quanto dell'esistente viene veramente utilizzato.
Dubito il 100% di 17k procedure/programmi.
Secondo applicahiamo le regole dell'analisi ABC al codice, dovrebbe essere:
A) 80% dell'uso viene fatto sul 20% delle procedure <--- prima necessità
B) 15% dell'uso viene fatto sul 30% delle procedure <--- secondo step
C) 5% dell'uso viene fatto sul restante 50% delle procedure <--- buttale via

> Quando arrivi dopo 10 anni ad aver rifatto tutto per Linux/Unix, nel frattempo
> chissà cosa c'è nel mondo, specie in quello di certa informatica che è sempre in
> evoluzione rapidissima (e tumultuosissima).

Vero, ma allo stesso tempo se non evolvi, resti ancora più indietro!
Ma poi, chi dice di riscrivere per Linux/Unix?
Io insisto sin dai primi messaggi, che il S.O. diventerà sempre più marginale nel tempo.

Potresti decidere di migrare ad esempio verso Amazon Elastic Cloud, Jelastic, Heroku, Google App Engine, IBM SoftLayer, HP Helion, Microsoft Azure... no, fai finta che questo non l'ho detto veramente :)
Oppure un sistema simile da fare girare su una propria server farm, come AppScale (compatibile Google App Engine), oppure OpenShift, OpenStack (è quello che vende anche HP dalla sua cloud), ecc...

> E questo vale per i soli sorgenti Cobol, che appunto da soli non servono a
> niente se non hanno i dati a cui accedere o i mezzi per interfacciarsi con gli
> utenti, dunque ci sono le altre decine di migliaia di sorgenti da prendere in
> considerazione. Puoi aggiungere altri programmatori al team principale, in modo
> da rimanere nei 10 anni, ma poi li devi anche pagare; la cosa incomincia a
> diventare un po' molto costosa se non sei l'IBM o quasi...

Voglio sperare che gli altri sorgenti siano più evolvibili in qualcosa di moderno...

> > > [Azienda che fa manutenzione su vecchi sistemi]

> Tu sei troppo sicuro delle tue idee. :P C'è chi li benedice perché costano meno
> dell'IBM e/o perché hanno roba che l'IBM dice di non tenere più (a meno che uno
> non abbia agganci molto in alto e/o sia pronto a sputare sangue dorato) e c'è
> chi dice che mai soldi furono meglio spesi (un atteggiamento un po' da copertina
> di Linus, ma tant'è)... Chi li maledice è una minoranza perché anche chi pensa
> che sia ora di cambiare si rivolge poi a loro per sostituire il vecchio S/36 con
> un AS/400, usato, ovviamente: vuoi che gente che ha ancora lì il 36 compri una
> macchina nuova? Figuriamoci! :)

Dicevano così anche di me quando facevo assistenza a terminali 3270 su macchine x86.
Eravamo più economici di altri perché in qualche fiera avevo messo mano su un cartone pieno di schede di emulazione 3270 ISA per 10 euro in tutto.
Mai soldi furono meglio spesi!
Così per qualche anno ho fatto buona assistenza, economica per il cliente, profiqua per me.
Poi hanno migrato tutto su ethernet, quindi il mio lavoro in quel mercato è diventato pari a zero.
Per fortuna non era il mio unico mercato!

> > Anche GNV è un po' un accrocchio :) Non credo (ma non posso verificarlo) che basti
> > 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...

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

[Gianluca Bonetti]

Il giorno lunedì 8 settembre 2014 20:57:27 UTC+2, nda ha scritto:
> > Il kernel Linux ad esempio � noto per essere GCC dipendente,
> > quindi non compila con altri compilatori (forse qualcosa �
> > 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.

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

[nda]

Gianluca Bonetti <g...@decadence.it> wrote:


> Se non sbaglio Clang � il compilatore C degli strumenti di sviluppo Apple,

> che fa la buona parte dello sviluppo di questo compilatore.

LLVM originariamente non era "di Apple" (e considerata la sua licenza
non lo � nemmeno ora). Inoltre l'idea di Lattner era di usare LLVM con
gcc e solo in seguito si � deciso di fornire un'alternativa completa a
gcc con Clang.
Apple ha ovviamente colto la palla al balzo e ha assunto Lattner,
incorporando LLVM e Clang in Xcode (cos� come anni fa ha incorporato
Dtrace) sganciandosi da gcc (che si dice si faceva modificare da Cygnus
per PowerPC) e passando a un sistema pi� moderno e potenzialmente
migliore.

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

[G.]

On Thu, 11 Sep 2014 08:27:53 -0700 (PDT), Gianluca Bonetti <g...@decadence.it>
wrote:

* DOVEROSA PREMESSA * In quest'ultima settimana sono successe molte cose e non
per ultima sono stato molto impegnato con un cliente per il quale ho dovuto
scrivere alcuni programmi nuovi, per un'esigenza nuova, in Cobol ed RPG. E no,
il cliente non sta fallendo, non sta per chiudere, non sta pianificando alcuna
migrazione e il sistema attuale risponde perfettamente alle sue esigenze (e non
si tratta di un'aziendina da tre scrivanie e due impiegati).

Detto questo, non ho trovato il tempo per completare la risposta, ma mi dispiace
cancellare / non pubblicare quello che avevo già fatto, quindi invio così com'è
un messaggio un po' monco. In più, considerando che il gioco è bello finché dura
poco, che il ferro va battuto finché è caldo, etc. etc. etc. non mi pareva il
caso di ritardare ancora a tempo indefinito per rispondere con precisione a ogni
punto che ritenessi avesse bisogno di essere chiarito (e poiché il lavoro di cui
sopra è ancora in corso, rischierei di ritardare chissà quanto).

Per lo stesso motivo penso anche che si potrebbe chiudere qui, considerando il
palese e mostruoso OT che stiamo portando avanti e l'irriducibilità delle nostre
posizioni. Per fortuna il mondo è abbastanza grande da contenere entrambe le
idee, entrambi i modi di lavorare, e soprattutto i relativi clienti, nonché per
fare in modo che le nostre strade possano non incrociarsi mai.

> Uè, qua ci vuole una settimana per rispondere ad un messaggio così! :)

Eh, io cerco di sfrondare, ma le cose da dire sono sempre tante. Comunque di
solito ci metto una mezz'oretta abbondante in una giornata/serata libera :)

> Mentec ha catalizzato un interesse molto forte in un settore in cui reali
> alternative non c'erano. Tant'è che ma General Electric del Canada ricerca
> programmatori PDP11 fino al 2050.

Non mi dire che della roba real-time per PDP-11 non si riesce a migrare... :P

> Mentec non ha preso un cavallo mezzo morto, ma un purosangue un po' vecchiotto,
> con un parco clienti molto fidelizzato.

E secondo te questa definizione non calza a pennello anche per chi si ostina a
usare VMS (per qualunque motivo più o meno valido)? Purosangue lo è (un cavallo
di razza lo è per sempre, anche quando non corre più) e il parco clienti non mi
pare che si possa definire poco fidelizzato. Più di così cosa vuoi? Un attacco
all'arma bianca alla sede di HP da parte di qualcuno di comp.os.vms? :)

> Per quello che si fa su VMS, oggi esistono alternative

Come esistono alternative per VMS ne esistono anche per RSX e altri fossili. Poi
ovvio, se vai a domandare a qualcuno che è ancora su <vecchio_sistema_qualunque>
ti dirà che come quello non c'è nessun altro.

La General Electric è un tuo esempio che io manco conoscevo :)

> Per VMS non si può proprio dire che sia nato adesso e con tante possibilità di
> crescere.

Stiamo comunque parlando di sistemi anziani. Così su due piedi non riesco a
farmi venire in mente un sistema operativo che non sia nato almeno 30 anni fa.
VMS è del 1977 e prende spunto da sistemi precedenti. Unix è degli anni '70 e
Linux bene o male ne è una derivazione. OS/400 è del 1988, ma deriva dal CPF del
System/38 che era del 1978 (ed ereditava progetti precedenti mai completati).
Gli OS per mainframe vanno addirittura indietro agli anni '60...

> Quello che poteva fare lo ha fatto, il suo stato dell'arte lo ha già raggiunto,
> si può solo manterenere così com'è, magari lavorando sulle performance, non non
> credo sulle features.

Nella mia tutto sommato povera esperienza con VMS (ci ho giocato tanto, ma mai
davvero in produzione) penso che gli ambiti in cui abbia ancora qualcosa da dire
siano il clustering e la business continuity. Ovvio che oggi non vai molto
avanti se pubblicizzi (solo) le magnifiche sorti e progressive della linea di
comando DCL. Però nel suo complesso ha ancora qualche carta interessante da
giocare. Prova ne è il fatto che ci sono un paio di filesystem distrubuiti (uno
è Lustre, l'altro ora non mi ricordo, forse GPFS) nella cui documentazione c'è
scritto senza mezzi termini che hanno risolto il problema della sincronizzazione
degli accessi copiando pari pari il dynamic lock manager di VMS (che fu pensato
e implementato intorno al 1982-83 per VMS 4.x quando nacque il clustering).

Se vogliono andare da qualche parte credo dovrebbero battere il chiodo sulla
robustezza e resilienza di tutto l'ecosistema. A maggior ragione dopo che in una
delle ultime versioni hanno aggiunto la possibilità di utilizzare il protocollo
IP per il clustering al posto del vecchio protocollo proprietario e alcune altre
cosette tipo la replica trasparente in tempo reale dei dischi fino a sei volte
in sei siti diversi (direi) e varie altre funzioni orientate all'HA.

> Col mio programma si producono ottimi salumi in un noto salumificio vicino a
> Pesaro! :)

Huff, con la mia roba si va sul meccanico/industriale/metallurgico... :|

> Entrambi gli applicativi lavorano nel client del gestionale, con un paio di
> procedure schedulate per la notte via cronjob per quanto riguarda le carni.

Uhm, "nel client del gestionale"? Quindi su ogni PC c'è una copia (immagino
sincronizzata in qualche modo) del tuo programma che accede a un server centrale
per ottenere i dati? e i cronjob dove girano? Client o server?

> Per questo, ti dico con cognizione di causa, riscrivere con strumenti più nuovi
> è più facile che fare manutenzione sul vecchio.

Nel tuo caso non lo metto in dubbio, anche perché non ho elementi per esprimere
un giudizio, ma ti inviterei a non generalizzare e semplificare: non è detto che
fare manutenzione sul vecchio sia sempre così tragico da far desiderare a ogni
momento una riscrittura totale o piuttosto farsi passare a fil di spada :)

Molto (se non tutto) dipende da chi e come ha sviluppato il pregresso. Mi sono
capitati casi orrendi, roba che non avrei voluto toccare neppure con un bastone,
talmente brutta o talmente incomprensibile che l'ho dovuta abbandonare o che
l'ho volente o nolente ancora peggiorata: ricordo un programma famigerato da ben
300 kB di puro testo senza manco un commento, stracolmo di GOTO, in cui l'unico
modo che ho trovato per sistemare un problema è stato aggiungerne altri due o
tre. E no, non potevo riscriverlo tutto perché ero lì solo per un paio d'ore.

Sai come si dice? Merd-in merd-out! :)

Viceversa mi sono capitati programmi anche molto vecchi ma funzionalissimi,
proprio belli, con una logica ineccepibile, e addirittura da ammirare non solo
nella forma ma anche nella sostanza, con i sorgenti tutti ordinatissimi, ben
allineati, senza una riga fuori posto, con i commenti pertinenti e chiarissimi,
etc. etc. etc. Roba che la guardi e dici: "che piccolo capolavoro". Del resto ho
sempre sostenuto che programmare, e soprattutto farlo bene, sia una vera arte.

Ho visto che di solito la robaccia capita nel piccolo, cioè dove chi sviluppa è
anche chi fa analisi e magari è uno o sono in due o tre, magari senza una vera
formazione specifica, mentre la roba bella viene fuori dove c'è un gruppo più
grande e dove le modifiche sono meditate con cura prima di essere applicate.

Si può scrivere codice orrendo o meraviglioso in quasi qualunque linguaggio, sia
con risorse risicatissime sia con risorse pressoché infinite.

> Poi sicuramente esisteranno altri linguaggi migliori, su cui fare manutenzione
> sarà una passeggiata piacevole, ma la mia esperienza è questa...

Appunto.

> Il problema è che si, oggi si fa tutto su AS400, anche interfacce web, web
> services, ecc... Ma *quando* il sistema è arrivato a fare questo? E *quando* i
> programmatori hanno iniziato a sfruttare queste possibilità?

Questo è ed è stato spesso un annoso problema del mondo AS/400, dovuto a molti
fattori che non è semplice identificare con precisione. Un'idea che mi sono
fatto io è che il ritardo, paradossalmente, sia dovuto alla qualità: ha sempre
funzionato così bene che molti non hanno sentito l'esigenza di cambiare o anche
solo aggiungere funzionalità nuove. Cioè si è ingenerato un circolo vizioso tra
l'IBM che non si sforza(va) di proporre cose nuove e gli sviluppatori e clienti
che quelle cose non usavano, e via così in una spirale involutiva.

Tuttora, nonostante su it.comp.as400 ci sia gente all'avanguardia, cioè persone
che sfruttano tutte le nuove possibilità al massimo, il grosso delle migliaia di
aziende e aziendine sparso in giro per l'Italia continua a usare l'AS/400 come
ai tempi del S/38, per non dire di quelli che girano ancora in modalità 36, cioè
in compatibilità col più vecchio (e mooolto più limitato) S/36.

> Voglio dire, vedo siti web di aziende del settore AS400 che pubblicizzano *oggi*
> come svecchiare gli applicativi dandogli una facciata web!

Questa è molto una conseguenza di quanto detto sopra: sviluppatori che da tempo
si sono seduti sugli allori e che non sanno come affrontare le nuove tecnologie,
motivo per cui (piuttosto che aggiornarsi) si rivolgono a soluzioni esterne che
non di rado sono accrocchi mostruosi. OS/400 può stampare PDF a colori, codici a
barre, loghi, inviare mail, etc. etc. etc. (come qualunque sistema moderno), ma
spesso si preferisce non toccare i vecchi programmi e piazzare un'applicazione
esterna (tipicamente su Windows) che intercetti le stampe e le le manipoli come
desiderato. In tutto questo, secondo me, ha colpa anche l'IBM che da una parte
non ha mai abbassato i prezzi per rendere appetibili le soluzioni native, mentre
dall'altra non le ha mai pubblicizzate abbastanza e soprattutto non le ha rese
semplici: ci sono prodotti IBM ottimi, ma dimensionati per ambienti enormi, che
per la piccola aziendina da dieci-quindici postazioni sono come togliere le
ragnatele con le cannonate...

> > (Se vuoi dettagli più espliciti tipo nomi etc. te li do in privato, non qui.)
>
> Se vuoi in privato ti faccio il nome del dialetto del BASIC :)

Bene, insieme a questo messaggio è partita una mail :)

> Se lo scrivessi in Java, il metodo è lo stesso per qualunque sistema operativo.

Attento. Ormai questo thread è andato alla deriva, ma all'inizio si parlava di
migrazione, non di riscrittura: se ho 17.000 programmi COBOL e li migro, intendo
dire che quei sorgenti li prendo, li modifico il minimo necessario per risolvere
le incompatibilità e li ricompilo così sulla nuova piattaforma.

Ed è proprio da qui che era nato tutto il discorso: un programma COBOL (Fortran,
BASIC, etc.) più o meno con fatica forse riesco a migrarlo, il resto no perché è
peculiare di quel sistema (ti facevo l'esempio dei vai tipi di "script").

> Basta usare la stringa java.io.File.separator come separatore anziché presumere "/" o "\\"

Sarei curioso di sapere come funziona in VMS, dove il separatore è multiplo: in
Windows e Unix il separatore tra le varie directory del path e tra queste ultime
e il file è un unico carattere ('/' o '\'), in VMS invece ci sono i caratteri
'[' e ']' per racchiudere il path e '.' per separare fra loro le directory del
path, senza contare i file manipolati in modo trasparente su un altro nodo.

nodo::device:[dir.dir.dir]file.ext;versione

> Mumble mumble... Nastri... decisamente è una operazione a livello sistemistico,
> non a livello applicativo. Permettimi, un applicativo, specialmente contabile,
> non deve neanche sapere dove finiscono i suoi dati, deve solo sapere che sono
> sempre disponibili. Che ne vengano fatte delle copie, è la base della sicurezza
> dei dati. E attualmente, con gli storage contemporanei, tutti i dati possono
> essere sempre disponibili, in repliche multiple, locali e remote.

Come ti scrivevo prima, ti invito a non semplificare troppo. I nastri non si
usano solo per i salvataggi, ma anche per molto altro. La banca d'Italia, oggi,
nel 2014, manda ancora in giro un grosso volume di dati su nastri IBM 3480 (e
qui "ancora" ci sta tutto): http://www.uark.edu/staff/techserv/ibm-3480.html

Allo stesso modo, un sacco di società finanziarie, ministeri, agenzie statali,
grandi aziende etc. etc. etc. scambiano tra di loro dati in quel modo (prova a
fare una ricerca su Google con IBM 3480, ministero, gazzetta ufficiale, etc.).
Di fatto, il 3480 è diventato uno formato franco accettato da tutti.

Quindi c'è il caso (visto personalmente) dell'utente che dalla propria sedia
"comanda" l'unità nastri e verifica che sia caricato il nastro giusto prima di
leggerlo o scriverlo con certi dati.

> Terminali... ok... i terminali... mi piacciono, ne ho una ventina in casa...
> ma... è ora di andare un po' avanti?

Intendevo sessioni. Per il sistema (mi pare più o meno sia così anche su Unix),
una sessione collegata, sia un vero device fisico o un emulatore su un PC, è
comunque rappresentata da un terminale, più o meno virtuale.

E poi sottovaluti quello di cui si parlava qualche messaggio fa: pistole laser,
marcatempo, terminali veri e propri al posto di PC in magazzini e capannoni,
thin client che fanno solo quello, etc. etc. etc.

> Non ho le specifiche delle stampanti con doppia alimentazione carta+assegni,
> supporrò che si tratti di carta a4+a3 nelle mie ricerche. Immagino che, alla

> peggio, si faccia una procedura C wrapped in Java class. Non garantisco che

> avrò la soluzione entro la prossima iterazione di questi messaggi, ma il
> problema mi è entrato in testa, e finché non lo risolvo non può uscire :)

Di solito gli assegni sono fogli A4 di carta speciale come quella delle
banconote (costosissima) e ci sono in due formati: con e senza lettera. Quelli
con lettera hanno l'assegno nella parte bassa, staccabile, e sopra il resto
della pagina è disponibile per un testo; viceversa quelli senza lettera sono tre
o quattro assegni per pagina A4, ma si usano meno perché se non ne stampi un
multiplo esatto poi ti avanzano degli assegni che da soli sono troppo piccoli
per essere accettati dalla meccanica della stampante.

Si usano molto le stampanti laser a modulo continuo che si alimentano con un
pacco da centinaia di assegni che poi vengono separati man mano che vengono
stampati. Idem si fa con i bollettini postali quando non sono su mezzo A4.
Ovviamente tutto dipende dalle dimensioni dell'azienda e dalla necessità di
stampare assegni. Se ne devi stampare pochi o li fai a mano con la macchina da
scrivere (incredibile ma vero) o generi un pratico file da mandare alla banca
via web o magari via 3480 o floppy (!) con dentro il tracciato record standard
ABI per gli assegni di traenza e poi ci pensano loro.

Ho visto anche stampanti in grado di leggere via MICR il numero dell'assegno per
fare il controllo incrociato con il programma prima di stampare il modulo.

Piccola parentesi: guarda questo file: http://goo.gl/Mzfr8w (Bitsavers, 2.8 MB);
a parte il frontespizio tipografico, vedrai che è stampato con un carattere che
dovresti riconoscere perché è quello con cui fino a non molto tempo fa arrivava
a casa la maggior parte delle comunicazioni di banche, assicurazioni, utilities
varie, enti dello stato, etc. Ebbene, si chiama IBM Gothic Text ed è segno che
dietro ognuna di quelle lettere c'era o c'è un mainframe IBM. Poi fortunatamente
il progresso ha avuto la meglio sull'inerzia e i sistemi sono stati aggiornati
per stampare anche con caratteri più amichevoli, ma ogni tanto qualcosa stampato
così arriva ancora (e no, non è affatto detto che abbiano buttato a mare il
mainframe, e neppure la stampante, ma solo il carattere!).

Nota tra l'altro che il documento originale da cui è ricavato quel PDF è del
1979: a quell'epoca l'IBM aveva già in produzione da anni le mitiche laser
veloci 3800: http://www.herring.pwp.blueyonder.co.uk/webimages/pcs/IBM3800.jpg
(così torniamo anche un po' in topic col newsgroup) :)

> Se migro un pacchetto che legge e scrive i suoi dati direttamente su disco con
> fread() e fwrite() sto decisamente migrando qualcosa che va rifatto. Senza
> 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.

[dottor Piergiorgio M. d' Errico]

Il 21/09/2014 08:15, G. ha scritto:

>> Mentec ha catalizzato un interesse molto forte in un settore in cui reali

>> alternative non c'erano. Tant'� che ma General Electric del Canada ricerca

>> programmatori PDP11 fino al 2050.
>
> Non mi dire che della roba real-time per PDP-11 non si riesce a migrare... :P

se ne � gi� parlato qua; il nocciolo del problema � che questi PDP-11
controllano *centrali nucleari* (incluso il core, nel senso nucleare):
non credo sia prudente migrare quando l' applicazione real-time
controlla dei reattori nucleari....

Non so se il particolare ambiente di lavoro richiede memoria a nuclei
(core memory) ma reputo che in questo caso il "fandango on core" porta
diritto al fandango in un altro, e mooolto pi� pericoloso core (il
nucleo di un reattore nucleare...)

spero che li selezionino bene, 'sti programmatori, l' eleganza e l'
ortogonalita' dell' architettura DEC permette di brasare il sistema con
una sola istruzione macchina, come notai a suo tempo.

quindi, non e' banale roba real-time. e per programmatori ben selezionati:

> http://en.wikipedia.org/wiki/Nuclear_power_in_Canada

(notare la locazione dei reattori....)

Saluti,
dott. Piergiorgio.

[Journeyman]

On 23/09/2014 01:26, dottor Piergiorgio M. d' Errico wrote:

>> http://en.wikipedia.org/wiki/Nuclear_power_in_Canada
> (notare la locazione dei reattori....)

Alzo la mano perch� non l'ho capita (forse perch� non ho seguito il thread).

[Gianluca Bonetti]

Eccoci di nuovo qua :)
L'ho presa comoda con la risposta perché il lavoro mi ha assorbito completamente negli ultimi giorni.

Il giorno domenica 21 settembre 2014 08:15:28 UTC+2, G. ha scritto:
> * DOVEROSA PREMESSA * In quest'ultima settimana sono successe molte cose e non
> per ultima sono stato molto impegnato con un cliente per il quale ho dovuto
> scrivere alcuni programmi nuovi, per un'esigenza nuova, in Cobol ed RPG. E no,
> il cliente non sta fallendo, non sta per chiudere, non sta pianificando alcuna
> migrazione e il sistema attuale risponde perfettamente alle sue esigenze (e non
> si tratta di un'aziendina da tre scrivanie e due impiegati).

Ecco, questa tua premessa mi fa già pensare ad una questione importante.
Noi dialoghiamo di massimi sistemi, ma il tessuto produttivo italiano è fatto all'80% di aziendine da tre scrivanie e due impiegati, anzi, alcune sono anche più piccole.
Alcune erano grandi, nei ruggenti anni '90 e nei favolosi anni '00, e quella volta si potevano permettere l'AS400.
Il titolare non sapeva neanche cos'era ma costava più dell'automobile di un suo impiegato quindi voleva dire che era il meglio.
Poi la crisi, il declino, e adesso il titolare lo sa bene cos'è l'AS400, ogni volta che c'è da fare un intervento e il preventivo passa per la sua scrivania.
I nomi di persone ed aziende sono omessi, ma i fatti narrati sono reali.

> Per lo stesso motivo penso anche che si potrebbe chiudere qui, considerando il
> palese e mostruoso OT che stiamo portando avanti e l'irriducibilità delle nostre
> posizioni. Per fortuna il mondo è abbastanza grande da contenere entrambe le
> idee, entrambi i modi di lavorare, e soprattutto i relativi clienti, nonché per
> fare in modo che le nostre strade possano non incrociarsi mai.

OT non saprei, alcune domande di ICR in passato sono arrivate al modernariato piuttosto che al retrocomputing, per cui...
Comunque su una cosa non ti sbagli, che siamo due irriducibili (== testoni) :)

> > Mentec ha catalizzato un interesse molto forte in un settore in cui reali
> > alternative non c'erano. Tant'è che ma General Electric del Canada ricerca
> > programmatori PDP11 fino al 2050.
>
> Non mi dire che della roba real-time per PDP-11 non si riesce a migrare... :P

Sicuramente si può.
L'equivalente della potenza di calcolo di un PDP11 oggi si contiene in un chip di pochi mmq e ha anche il wireless :)
Non scherzo! L'AVR ATMEGA128RFA1 è incredibile!
Ed è pieno di OS realtime molto interessanti.

Il punto è che qui veramente non serve, quelle macchine non devono interfacciarsi con nulla.
Anzi, devono stare più isolate possibili.
Perché sono i sistemi di controllo delle centrali nucleari!
Ma su centrali nuove, verranno sicuramente adottati sistemi più recenti.

> > Mentec non ha preso un cavallo mezzo morto, ma un purosangue un po' vecchiotto,
> > con un parco clienti molto fidelizzato.
>
> E secondo te questa definizione non calza a pennello anche per chi si ostina a
> usare VMS (per qualunque motivo più o meno valido)? Purosangue lo è (un cavallo

Ai tempi in cui Mentec prese il mercato PDP, non c'era il rinnovamento tecnologico che c'è oggi.
Mentec all'epoca ha comprato tecnologia rivendibile per almeno 10 anni, quindi di sicuro ritorno dell'investimento.
VSI compra tecnologia che era già obsoleta 4 anni fa quando si è arrestato lo sviluppo vero di VMS, e prima che possa sfornare qualcosa ci vorranno anni.
Immagino che VSI andrà subito in passivo, e se questa passività dura per più di 2-3 anni allora VSI sarà solo una sontuosa piramide in cui tumulare VMS.

> di razza lo è per sempre, anche quando non corre più) e il parco clienti non mi
> pare che si possa definire poco fidelizzato. Più di così cosa vuoi? Un attacco
> all'arma bianca alla sede di HP da parte di qualcuno di comp.os.vms? :)

Il parco clienti è fidelizzato? Veramente?
I clienti non sono quei 10-15 sistemisti che scrivono frequentemente su COV.
I clienti di quei 10-15 sistemisti di COV sono il parco clienti.
Non mi sembra di aver mai letto nulla di scritto da un vero cliente finale di VMS da nessuna parte.

> Come esistono alternative per VMS ne esistono anche per RSX e altri fossili. Poi
> ovvio, se vai a domandare a qualcuno che è ancora su <vecchio_sistema_qualunque>
> ti dirà che come quello non c'è nessun altro.
>
> La General Electric è un tuo esempio che io manco conoscevo :)

Su RSX non girano gestionali :)
O meglio, quello che ancora è installato su RSX sono sistemi di controllo di centrali elettriche, dighe, ecc...

> Nella mia tutto sommato povera esperienza con VMS (ci ho giocato tanto, ma mai
> davvero in produzione) penso che gli ambiti in cui abbia ancora qualcosa da dire
> siano il clustering e la business continuity. Ovvio che oggi non vai molto
> avanti se pubblicizzi (solo) le magnifiche sorti e progressive della linea di
> comando DCL. Però nel suo complesso ha ancora qualche carta interessante da
> giocare. Prova ne è il fatto che ci sono un paio di filesystem distrubuiti (uno
> è Lustre, l'altro ora non mi ricordo, forse GPFS) nella cui documentazione c'è
> scritto senza mezzi termini che hanno risolto il problema della sincronizzazione
> degli accessi copiando pari pari il dynamic lock manager di VMS (che fu pensato
> e implementato intorno al 1982-83 per VMS 4.x quando nacque il clustering).
>
> Se vogliono andare da qualche parte credo dovrebbero battere il chiodo sulla
> robustezza e resilienza di tutto l'ecosistema. A maggior ragione dopo che in una
> delle ultime versioni hanno aggiunto la possibilità di utilizzare il protocollo
> IP per il clustering al posto del vecchio protocollo proprietario e alcune altre
> cosette tipo la replica trasparente in tempo reale dei dischi fino a sei volte
> in sei siti diversi (direi) e varie altre funzioni orientate all'HA.

Il clustering multi-site è sicuramente la funzionalità più prestigiosa.
Sul clustering single-site, la tendenza è il clustering a livello applicativo, ivi compreso il FS distribuito (sempre che un FS sia necessario)
Comunque quanti nuovi clienti hanno bisogno del clustering multi-site?
Per un nuovo progetto, sinceramente, con assoluto rammarico, avrebbe più senso orientarsi verso altre soluzioni che non siano una trappola dorata.

> > Col mio programma si producono ottimi salumi in un noto salumificio vicino a
> > Pesaro! :)
>
> Huff, con la mia roba si va sul meccanico/industriale/metallurgico... :|

Più luccicante ma con meno sapore! :)

> > Entrambi gli applicativi lavorano nel client del gestionale, con un paio di
> > procedure schedulate per la notte via cronjob per quanto riguarda le carni.
>
> Uhm, "nel client del gestionale"? Quindi su ogni PC c'è una copia (immagino
> sincronizzata in qualche modo) del tuo programma che accede a un server centrale
> per ottenere i dati? e i cronjob dove girano? Client o server?

No, non ho illustrato bene.
Gli applicativi che ho fatto hanno interfaccia utente eseguibile solo all'interno del client del gestionale, non stand-alone.
Sono comunque eseguiti sul server e ci sono dei cronjob schedulati sul server.
Alla fine sono solo 2 cronjob, che in pratica lanciano l'esecuzione di due programmi, ma non c'è interazione con il filesystem.
Era solo più pratico usare dei cronjob per schedulare le operazioni.
Anche per applicazioni scritte più recentemente uso un paio di cronjob.
Certo potrei scrivermi uno scheduler ma non ha senso farlo per lanciare un paio di procedure ogni 3 minuti e 1 solo una volta al giorno.

> > Per questo, ti dico con cognizione di causa, riscrivere con strumenti più nuovi
> > è più facile che fare manutenzione sul vecchio.
>
> Nel tuo caso non lo metto in dubbio, anche perché non ho elementi per esprimere
> un giudizio, ma ti inviterei a non generalizzare e semplificare: non è detto che
> fare manutenzione sul vecchio sia sempre così tragico da far desiderare a ogni
> momento una riscrittura totale o piuttosto farsi passare a fil di spada :)

Forse lo strumento che ho usato io in precedenza era veramente terribile.
Se penso ora di riscriverci qualcosa, mi vengono i peggio pensieri.
Quindi riscrivere è stato talmente facile, da diventare divertente.
Diciamo che cose che prima avrei fatto con difficoltà sono diventate una passeggiata, e cose che prima erano impossibili sono diventate fattibili (anche se non una passeggiata)
Comunque certo, io ragiono sul mio caso specifico.
Forse prima programmavo proprio in una merda di piattaforma :) che comunque è installata in Italia in circa 22.000 aziende.

> Molto (se non tutto) dipende da chi e come ha sviluppato il pregresso. Mi sono
> capitati casi orrendi, roba che non avrei voluto toccare neppure con un bastone,
> talmente brutta o talmente incomprensibile che l'ho dovuta abbandonare o che
> l'ho volente o nolente ancora peggiorata: ricordo un programma famigerato da ben
> 300 kB di puro testo senza manco un commento, stracolmo di GOTO, in cui l'unico
> modo che ho trovato per sistemare un problema è stato aggiungerne altri due o
> tre. E no, non potevo riscriverlo tutto perché ero lì solo per un paio d'ore.
>
> Sai come si dice? Merd-in merd-out! :)

In molti considerano il GOTO come la peste bubbonica!
Ti sei disinfettato bene, spero :)

> Viceversa mi sono capitati programmi anche molto vecchi ma funzionalissimi,
> proprio belli, con una logica ineccepibile, e addirittura da ammirare non solo
> nella forma ma anche nella sostanza, con i sorgenti tutti ordinatissimi, ben
> allineati, senza una riga fuori posto, con i commenti pertinenti e chiarissimi,
> etc. etc. etc. Roba che la guardi e dici: "che piccolo capolavoro". Del resto ho
> sempre sostenuto che programmare, e soprattutto farlo bene, sia una vera arte.

Numerosi siti elogiano l'arte della programmazione.
Vabbè sono programmatori che elogiano altri programmatori! :)
La definizione che preferisco è quella del film Tron, il programmatore è un "creativo".

> Ho visto che di solito la robaccia capita nel piccolo, cioè dove chi sviluppa è
> anche chi fa analisi e magari è uno o sono in due o tre, magari senza una vera
> formazione specifica, mentre la roba bella viene fuori dove c'è un gruppo più
> grande e dove le modifiche sono meditate con cura prima di essere applicate.

Team "agili" non sempre sono smastriccioni.
Dipende da come si è abituati a lavorare.
C'è chi non commenta nulla nel codice, perché tanto se lo ricorda come funziona.
C'è chi usa un version control system, ma non commenta le revisioni, o ne pubblica poche, o affatto...

Dipende anche dallo strumento...
Io non riesco a rimettere mano facilmente ai programmi che ho scritto in quel BASIC non strutturato anche se in presenza di miei abbondanti commenti.
Nel codice Java ci si orienta molto bene, anche senza commenti.
Se i commenti sono abbondanti è molto facile, ed è buona prassi farlo anche se programmi da solo.
Tempo fa ho riguardato del vecchio codice assembly x86 scritto da me, il file più nuovo è del 1994.
Beh era commentato, almeno un pochino..., ma non ci capisco più niente lo stesso :)
Quindi il commento da se non basta, se il linguaggio è complesso.

> > Il problema è che si, oggi si fa tutto su AS400, anche interfacce web, web
> > services, ecc... Ma *quando* il sistema è arrivato a fare questo? E *quando* i
> > programmatori hanno iniziato a sfruttare queste possibilità?
>
> Questo è ed è stato spesso un annoso problema del mondo AS/400, dovuto a molti
> fattori che non è semplice identificare con precisione. Un'idea che mi sono
> fatto io è che il ritardo, paradossalmente, sia dovuto alla qualità: ha sempre
> funzionato così bene che molti non hanno sentito l'esigenza di cambiare o anche
> solo aggiungere funzionalità nuove. Cioè si è ingenerato un circolo vizioso tra
> l'IBM che non si sforza(va) di proporre cose nuove e gli sviluppatori e clienti
> che quelle cose non usavano, e via così in una spirale involutiva.
>
> Tuttora, nonostante su it.comp.as400 ci sia gente all'avanguardia, cioè persone
> che sfruttano tutte le nuove possibilità al massimo, il grosso delle migliaia di
> aziende e aziendine sparso in giro per l'Italia continua a usare l'AS/400 come
> ai tempi del S/38, per non dire di quelli che girano ancora in modalità 36, cioè
> in compatibilità col più vecchio (e mooolto più limitato) S/36.

Non vorrei sbagliare, mi sembra che per un periodo dei primi AS Power, il collegamento ethernet avvenisse mediante una scheda PC x86 da aggiungere all'AS.
Quindi dovevi prenderti la scheda x86 da 5 milioni, la ethernet da 1 milione, e alla fine potevi mettere l'AS da 10 milioni in rete :)
Che ci abbiano impiegato per arrivare a qualcosa di moderno, se questo è stato l'inizio, non ne dubito.

> > Voglio dire, vedo siti web di aziende del settore AS400 che pubblicizzano *oggi*
> > come svecchiare gli applicativi dandogli una facciata web!
>
> Questa è molto una conseguenza di quanto detto sopra: sviluppatori che da tempo
> si sono seduti sugli allori e che non sanno come affrontare le nuove tecnologie,
> motivo per cui (piuttosto che aggiornarsi) si rivolgono a soluzioni esterne che
> non di rado sono accrocchi mostruosi. OS/400 può stampare PDF a colori, codici a
> barre, loghi, inviare mail, etc. etc. etc. (come qualunque sistema moderno), ma
> spesso si preferisce non toccare i vecchi programmi e piazzare un'applicazione
> esterna (tipicamente su Windows) che intercetti le stampe e le le manipoli come
> desiderato. In tutto questo, secondo me, ha colpa anche l'IBM che da una parte
> non ha mai abbassato i prezzi per rendere appetibili le soluzioni native, mentre
> dall'altra non le ha mai pubblicizzate abbastanza e soprattutto non le ha rese
> semplici: ci sono prodotti IBM ottimi, ma dimensionati per ambienti enormi, che
> per la piccola aziendina da dieci-quindici postazioni sono come togliere le
> ragnatele con le cannonate...

Tutto questo mi era noto, e mi è sempre sembrato folle.
Per questo penso che aziende da 10 postazioni abbiano più vantaggio a migrare!

> > Se vuoi in privato ti faccio il nome del dialetto del BASIC :)
>
> Bene, insieme a questo messaggio è partita una mail :)

Attendo, quando vuoi, tanto non è nulla di particolarmente interessante!

> > Se lo scrivessi in Java, il metodo è lo stesso per qualunque sistema operativo.
>
> Attento. Ormai questo thread è andato alla deriva, ma all'inizio si parlava di
> migrazione, non di riscrittura: se ho 17.000 programmi COBOL e li migro, intendo
> dire che quei sorgenti li prendo, li modifico il minimo necessario per risolvere
> le incompatibilità e li ricompilo così sulla nuova piattaforma.
>
> Ed è proprio da qui che era nato tutto il discorso: un programma COBOL (Fortran,
> BASIC, etc.) più o meno con fatica forse riesco a migrarlo, il resto no perché è
> peculiare di quel sistema (ti facevo l'esempio dei vai tipi di "script").

Si, siamo andati molto alla deriva :)
La mia idea di migrazione è comunque di migrare di parti del programma verso piattaforme più aperte.
Anche scrivere codice Java/PHP/Python/ecc... su AS 400 è una migrazione verso un sistema più aperto.
Prima il codice, poi la base dati, poi il S.O. diventa irrilevante.

> > Basta usare la stringa java.io.File.separator come separatore anziché presumere "/" o "\\"
>
> Sarei curioso di sapere come funziona in VMS, dove il separatore è multiplo: in
> Windows e Unix il separatore tra le varie directory del path e tra queste ultime
> e il file è un unico carattere ('/' o '\'), in VMS invece ci sono i caratteri
> '[' e ']' per racchiudere il path e '.' per separare fra loro le directory del
> path, senza contare i file manipolati in modo trasparente su un altro nodo.
>
> nodo::device:[dir.dir.dir]file.ext;versione

Da programmatore Java... me ne infischio! :)

L'ambiente Java, se ottiene la conformità alle specifiche, mi fornisce i metodi di accesso agli oggetti nel modo conforme alle specifiche.
Se HP dichiara di avere un JDK 6.0, può farlo perché questo JDK ha superato i test del Java TCK.
Possiamo vedere il codice di OpenJDK per come fa queste operazioni, ma OpenJDK non gira su VMS.
L'implementazione Java su VMS è solamente quella di HP, il cui codice è chiuso.
E quindi non lo possiamo vedere, non possiamo sapere come fa, ma non è un fatto importante.
Il fatto importante è che funziona come da specifiche.

Poi se vogliamo fare i pignoli e vogliamo sapere come fa, possiamo analizzarlo.
Ma di base, il programmatore, se ne può infischiare.
Questo perché il sistemista VMS che installerà il programma sul server/cluster, avrà installato il JDK nel modo giusto, come da specifiche del produttore.
Installare e configurare il JDK su Linux e Windows è facilissimo, su VMS sarà difficile come tutte le cose che si fanno su VMS :) ma il sistemista VMS saprà come fare.

Per farla breve, leggerà le specifiche di HP, che stanno qui:
http://h18012.www1.hp.com/java/documentation/1.6.0/ivms/docs/user_guide.html#unix_style
In particolare proprio la sezione "UNIX-Style Filenames on OpenVMS Systems"
Non l'ho letta, ma solo guardata, comunque il senso mi è chiaro, ci sono delle impostazioni di variabili di sistema da fare e in base a quelle si può configurare il comportamento nel modo più adatto.
Copio/incollo solo un esempio:

...
For example, a name like:
$disk1:[smith]/test.jtjtj/test.jtjtj
maps into:
/$disk1/smith/test.jtjtj/test.jtjtj
...

Poi è buona norma non utilizzare path completi, ma relativi all'applicativo (a volte sono nello stesso file JAR/WAR) ma se uno si vuole complicare la vita, usare path completi dalla radice, e rendere in un colpo solo il proprio programma OS-dependent, è sua scelta consapevole.

> > Mumble mumble... Nastri... decisamente è una operazione a livello sistemistico,
> > non a livello applicativo. Permettimi, un applicativo, specialmente contabile,
> > non deve neanche sapere dove finiscono i suoi dati, deve solo sapere che sono
> > sempre disponibili. Che ne vengano fatte delle copie, è la base della sicurezza
> > dei dati. E attualmente, con gli storage contemporanei, tutti i dati possono
> > essere sempre disponibili, in repliche multiple, locali e remote.
>
> Come ti scrivevo prima, ti invito a non semplificare troppo. I nastri non si
> usano solo per i salvataggi, ma anche per molto altro. La banca d'Italia, oggi,
> nel 2014, manda ancora in giro un grosso volume di dati su nastri IBM 3480 (e
> qui "ancora" ci sta tutto): http://www.uark.edu/staff/techserv/ibm-3480.html
>
> Allo stesso modo, un sacco di società finanziarie, ministeri, agenzie statali,
> grandi aziende etc. etc. etc. scambiano tra di loro dati in quel modo (prova a
> fare una ricerca su Google con IBM 3480, ministero, gazzetta ufficiale, etc.).
> Di fatto, il 3480 è diventato uno formato franco accettato da tutti.
>
> Quindi c'è il caso (visto personalmente) dell'utente che dalla propria sedia
> "comanda" l'unità nastri e verifica che sia caricato il nastro giusto prima di
> leggerlo o scriverlo con certi dati.

Ok, quante aziende in Italia ricevono nastri dalla Banca d'Italia?
E' un caso statisticamente irrilevante... saranno lo 0.000001% delle aziende italiane?
Poi se la Banca d'Italia manda dei nastri a quell'azienda, sono sicuro che è giusto che quell'azienda che ha ricevuto nastri dalla Banca d'Italia debba pagare un conto salato, molto salato.
Ben gli sta.
:)

Per quello che riguarda i ministeri, ecco la burocrazia con mezzi informatici.
La distribuzione dati con supporti legacy!
Alla faccia della DigitPA!
Un carroziere che deve fatturare una riparazione da 100 euro ad una vettura della polizia municipale deve fare fattura in XML, spedirla con la PEC, conservarla in archiviazione sostitutiva (a che costi, poi!) e i ministeri si scambiano dati su nastri.
C'è del marcio in Italia.

> > Terminali... ok... i terminali... mi piacciono, ne ho una ventina in casa...
> > ma... è ora di andare un po' avanti?
>
> Intendevo sessioni. Per il sistema (mi pare più o meno sia così anche su Unix),
> una sessione collegata, sia un vero device fisico o un emulatore su un PC, è
> comunque rappresentata da un terminale, più o meno virtuale.

Emulare un terminale non cambia, è sempre un sistema antico.
Quindi i terminali sono belli, stupendi, anche esteticamente, ma sono antichi.
Gli utenti che usano un programma, oggi, non dovrebbero farlo su un terminale, neanche se fosse un terminale emulato da una App di Android.

> E poi sottovaluti quello di cui si parlava qualche messaggio fa: pistole laser,
> marcatempo, terminali veri e propri al posto di PC in magazzini e capannoni,
> thin client che fanno solo quello, etc. etc. etc.

C'è roba più nuova.
Più funzionale.
Più economica.
Migliore.
E' ora di usarla.

> > Non ho le specifiche delle stampanti con doppia alimentazione carta+assegni,
> > supporrò che si tratti di carta a4+a3 nelle mie ricerche. Immagino che, alla
> > peggio, si faccia una procedura C wrapped in Java class. Non garantisco che
> > avrò la soluzione entro la prossima iterazione di questi messaggi, ma il
> > problema mi è entrato in testa, e finché non lo risolvo non può uscire :)
>
> Di solito gli assegni sono fogli A4 di carta speciale come quella delle
> banconote (costosissima) e ci sono in due formati: con e senza lettera. Quelli
> con lettera hanno l'assegno nella parte bassa, staccabile, e sopra il resto
> della pagina è disponibile per un testo; viceversa quelli senza lettera sono tre
> o quattro assegni per pagina A4, ma si usano meno perché se non ne stampi un
> multiplo esatto poi ti avanzano degli assegni che da soli sono troppo piccoli
> per essere accettati dalla meccanica della stampante.
>
> Si usano molto le stampanti laser a modulo continuo che si alimentano con un
> pacco da centinaia di assegni che poi vengono separati man mano che vengono
> stampati. Idem si fa con i bollettini postali quando non sono su mezzo A4.
> Ovviamente tutto dipende dalle dimensioni dell'azienda e dalla necessità di
> stampare assegni. Se ne devi stampare pochi o li fai a mano con la macchina da
> scrivere (incredibile ma vero) o generi un pratico file da mandare alla banca
> via web o magari via 3480 o floppy (!) con dentro il tracciato record standard
> ABI per gli assegni di traenza e poi ci pensano loro.
>
> Ho visto anche stampanti in grado di leggere via MICR il numero dell'assegno per
> fare il controllo incrociato con il programma prima di stampare il modulo.

Quindi aspetta... se il formato è sempre A4... mi sembra un non-problema :)
Quelle stampanti laser a modulo continuo, di cui ignoravo l'esistenza, non penso verranno utilizzate per molte altre cose oltre la stampa di assegni per cui potrei quasi presupporre che quella stampante stampi solo assegni...
Comunque anche se il volume di assegni stampato è altissimo, sono poche le realtà che stampano questo altissimo numero di assegni.
Sono più le aziende che fanno un po' di assegni a vuoto, che quelle che compilano migliaia si assegni al giorno!

> > Se migro un pacchetto che legge e scrive i suoi dati direttamente su disco con
> > fread() e fwrite() sto decisamente migrando qualcosa che va rifatto. Senza
> > 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.

Mi sembrava stessimo parlando delle fread() e fwrite() del C.
Forse mi sbaglio, la discussione si dirama in più direzioni...

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

Sicuramente un tempo 70M record era big-data.
Oggi big-data è più di questo, ma 70M record non sono pochi.
Allo stesso modo, non sono molte le aziende che elaborano 70M di record.
Molte aziende invece stampano la fattura dal sistema legacy e poi la passano nello scanner per poterla inviare in email :)

> Come dicevo, se vuoi/devi migrare a Unix un sistema come quello detto sopra - e

Aridaiè :)
Mai detto di migrare a Unix (o Linux, o *BSD)
Io suggerisco una pattaforma o ecosistema più aperto, e te ne avevo citate diverse, copio/incollo me stesso:

Amazon Elastic Cloud, Jelastic, Heroku, Google App Engine, IBM SoftLayer, HP Helion, Microsoft Azure... no, fai finta che questo non l'ho detto veramente :)
Oppure un sistema simile da fare girare su una propria server farm, come AppScale (compatibile Google App Engine), oppure OpenShift, OpenStack (è quello che vende anche HP dalla sua cloud), ecc...

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

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

[G.]

On Sat, 4 Oct 2014 10:35:29 -0700 (PDT), Gianluca Bonetti <g...@decadence.it>
wrote:

> Eccoci di nuovo qua :)
> L'ho presa comoda con la risposta perché il lavoro mi ha assorbito completamente
> negli ultimi giorni.

Cavolo, io mi sono completamente scordato che dovevo mandarti la mail...

> Noi dialoghiamo di massimi sistemi, ma il tessuto produttivo italiano è fatto
> all'80% di aziendine da tre scrivanie e due impiegati, anzi, alcune sono anche
> più piccole. Alcune erano grandi, nei ruggenti anni '90 e nei favolosi anni '00,
> e quella volta si potevano permettere l'AS400.

Mah, guarda, io non so quale sia la tua realtà e quale sia la situazione delle
Marche, ma qui non siamo messi così male, eh. Questo non solo a Bologna e nei
suoi dintorni (cioè un polo produttivo non indifferente), ma anche più su, nelle
zone colpite dal terremoto del 2012.

Ho diversi clienti, più o meno grandi e più o meno piccoli, che stanno su AS/400
perché gli va bene. Anzi uno (medio-piccolo) ha comprato proprio l'hanno scorso
la macchina nuova, l'ha pagata circa 15.000 euro chiavi in mano, poi ha pagato a
me cinque giorni di lavoro perché gli configurassi e passassi tutto quanto sul
nuovo sistema e ora via che va felice e contento.

Visto che frequentiamo giri diversi, io probabilmente non vedo gli scontenti e
tu non vedi i contenti che non sentono il bisogno di scappare via.

> Il titolare non sapeva neanche cos'era ma costava più dell'automobile di un suo
> impiegato quindi voleva dire che era il meglio.

Ti assicuro che i "miei" titolari sanno benissimo di cosa si tratta, e sono poi
quelli che magari decidono di comprare la macchina nuova. È più facile che non
lo sappiano i presidenti di grosse aziende mie clienti, i quali hanno tali e
tanti strati di gente sotto di loro, tra amministratori delegati, vari direttori
generali e affini, che non solo non sanno cos'è l'AS/400 (o il mainframe), ma
non firmano neppure per l'acquisto. Al massimo si preoccupano degli arredi dello
yacht per la prossima estate (o dello sviluppo di mercati emergenti in Asia, se
sono un po' meno frivoli e più coi piedi per terra).

> Il parco clienti è fidelizzato? Veramente? I clienti non sono quei 10-15
> sistemisti che scrivono frequentemente su COV. I clienti di quei 10-15
> sistemisti di COV sono il parco clienti. Non mi sembra di aver mai letto nulla
> di scritto da un vero cliente finale di VMS da nessuna parte.

Perché, tu vedi i (tuoi) clienti finali scrivere su qualche NG (o forum) per
chiedere lumi? Vedi qualche cliente finale scrivere su it.comp.as400 (ammesso
che tu lo segua)? Tra l'altro ormai quel NG è deserto perché qualcuno s'è
divertito a segnalarlo a Google ed è stato tolto da Google Groups per spam.

> La definizione che preferisco è quella del film Tron, il programmatore è un "creativo".

E i (veri) creativi di solito cosa creano, se non arte? :)

> Nel codice Java ci si orienta molto bene, anche senza commenti.

Io che Java non lo conosco quasi per niente (anzi, diciamo pure niente) lo trovo
pressoché illeggibile. Viceversa capisco piuttosto bene il Cobol (anche se non è
il mio primo linguaggio di lavoro) e lo capisco bene anche senza commenti.

Mi è capitato di parlare di lingue straniere con una persona che non sa il
francese (che io invece capisco e parlo abbastanza, anzi ultimamente ho scoperto
di saperlo meglio di quanto credevo di ricordare): a me sembra piuttosto
comprensibile e mi viene istintivo pensare che possa esserlo anche per chi non
l'ha studiato; questa persona invece mi diceva di capirne ben poco.

> Non vorrei sbagliare, mi sembra che per un periodo dei primi AS Power, il
> collegamento ethernet avvenisse mediante una scheda PC x86 da aggiungere all'AS.

Sbagli. :) Gli AS/400 hanno sempre avuto la Ethernet, o perlomeno hanno sempre
avuto la possibilità di installarne una, fin dai primissimi modelli CISC bianchi
del 1988. Certo, l'IBM spingeva più per la sua Token-Ring, ma Ethernet c'era.

Semmai lasciava più a desiderare il supporto software: l'implementazione del
TCP/IP non credo proprio fosse una delle migliori e più solide sul mercato. Si
era in un epoca in cui ciascun produttore spingeva ancora moltissimo per le
proprie soluzioni proprietarie e il TCP/IP non era ancora emerso come sistema di
comunicazione universale (andavano ancora fortissimo X.25 e OSI, per esempio).

Viceversa poi c'erano cose commoventi, come la possibilità di attaccare come
console all'AS/400 un Macintosh via AppleTalk! :)

Andando un po' indietro rispetto agli AS/400, su S/36 c'era la possibilità di
avere solo Token-Ring (solo in alcuni modelli) e solo SNA come suite di rete.
Sistemi ancora più vecchi avevano solo seriali e/o altri tipi di collegamento
perché erano precedenti l'introduzione della tecnologia Token-Ring.

Quello che dici tu era l'integrated server, una scheda con una CPU x86 su cui
installare Windows, la quale aveva a sua volta una porta Ethernet che poteva
essere condivisa fra Windows e OS/400. Se poi uno non aveva la Ethernet e invece
di comprare quella decideva di comprare tutto l'ambaradan con Windows solo per
avere la rete, be', complimenti al commerciale del Business Partner IBM. :)

Supervinx, che scrive(va) qui, ha fatto un bellissimo lavoro in proposito:
http://www.supervinx.com/Retrocomputer/IBM/AS400/9406/170/ (vedi verso il fondo,
dove compaiono le immagini degli schermi di installazione di Windows).

> > Bene, insieme a questo messaggio è partita una mail :)
>
> Attendo, quando vuoi, tanto non è nulla di particolarmente interessante!

Lo faccio subito, altrimenti va a finire che mi dimentico di nuovo. :)

> Un carroziere che deve fatturare una riparazione da 100 euro ad una vettura
> della polizia municipale deve fare fattura in XML, spedirla con la PEC,
> conservarla in archiviazione sostitutiva (a che costi, poi!) e i ministeri si
> scambiano dati su nastri.

La PEC è proprio una robaccia tutta italiana! Io per fortuna non ho a che fare
con la pubblica amministrazione (e me ne guardo bene), così mi evito le fatture
XML e soprattutto l'archiviazione sostitutiva: le mie fatture le faccio in PDF e
le mando ai clienti via mail, poi ne stampo una copia su carta (come fanno loro)
e la tengo archiviata alla vecchia maniera. :)

> Quelle stampanti laser a modulo continuo, di cui ignoravo l'esistenza, non penso
> verranno utilizzate per molte altre cose oltre la stampa di assegni per cui
> potrei quasi presupporre che quella stampante stampi solo assegni...

In realtà, visto che si parla di grossissimi volumi di stampa e visto che gli
assegni sono roba vecchia che tende(rà) a scomparire, quelle stampanti sono
utilizzate soprattutto per altro. Ma qui si parla di centri stampa veri e propri
tipo Postel o società come la Telecom che stampano le bollette di milioni di
italiani. Sono laser, ma non ci somigliano neanche: ricordano di più le rotative
dei giornali e si mangiano diversi chili di toner in un'ora. :)

Guarda che belline:

https://www.youtube.com/watch?v=y_9_RKlWMo0
https://www.youtube.com/watch?v=aP4fe2HWCR4
https://www.youtube.com/watch?v=APRpKRohX2U

Pensa se si inceppano! :)))

Io su una cosa del genere, utilizzando un AS/400 come despooler, sono arrivato a
vedere l'emissione di stampe da 125.000 pagine. Uno spettacolo pazzesco. :)

> Allo stesso modo, non sono molte le aziende che elaborano 70M di record.

Settanta milioni di record no, ma una decina sì, anche l'aziendina da tre
scrivanie e due impiegati. :)

> Molte aziende invece stampano la fattura dal sistema legacy e poi la passano
> 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.

[Gianluca Bonetti]

Il giorno domenica 5 ottobre 2014 13:37:42 UTC+2, G. ha scritto:
> Mah, guarda, io non so quale sia la tua realtà e quale sia la situazione delle
> Marche, ma qui non siamo messi così male, eh. Questo non solo a Bologna e nei
> suoi dintorni (cioè un polo produttivo non indifferente), ma anche più su, nelle
> zone colpite dal terremoto del 2012.

Qui su Pesaro il panorama è veramente catastrofico.
Chiudono aziende tutti i giorni.
Non è un modo di dire, è vero, le posso contare personalmente.
Nel resto delle Marche, non è che è messa meglio, anzi...

> Ho diversi clienti, più o meno grandi e più o meno piccoli, che stanno su AS/400
> perché gli va bene. Anzi uno (medio-piccolo) ha comprato proprio l'hanno scorso
> la macchina nuova, l'ha pagata circa 15.000 euro chiavi in mano, poi ha pagato a
> me cinque giorni di lavoro perché gli configurassi e passassi tutto quanto sul
> nuovo sistema e ora via che va felice e contento.
>
> Visto che frequentiamo giri diversi, io probabilmente non vedo gli scontenti e
> tu non vedi i contenti che non sentono il bisogno di scappare via.

Decisamente giri diversi.
Difficilmente una azienda medio-piccola delle Marche può permettersi un server da 15.000 euro.

> Ti assicuro che i "miei" titolari sanno benissimo di cosa si tratta, e sono poi
> quelli che magari decidono di comprare la macchina nuova. È più facile che non
> lo sappiano i presidenti di grosse aziende mie clienti, i quali hanno tali e
> tanti strati di gente sotto di loro, tra amministratori delegati, vari direttori
> generali e affini, che non solo non sanno cos'è l'AS/400 (o il mainframe), ma
> non firmano neppure per l'acquisto. Al massimo si preoccupano degli arredi dello
> yacht per la prossima estate (o dello sviluppo di mercati emergenti in Asia, se
> sono un po' meno frivoli e più coi piedi per terra).

Aziende con un amministratore delegato sono delle grandi aziende.
Il 90% delle aziende italiane però non ha un amministratore delegato...

> > Il parco clienti è fidelizzato? Veramente? I clienti non sono quei 10-15
> > sistemisti che scrivono frequentemente su COV. I clienti di quei 10-15
> > sistemisti di COV sono il parco clienti. Non mi sembra di aver mai letto nulla
> > di scritto da un vero cliente finale di VMS da nessuna parte.
>
> Perché, tu vedi i (tuoi) clienti finali scrivere su qualche NG (o forum) per
> chiedere lumi? Vedi qualche cliente finale scrivere su it.comp.as400 (ammesso
> che tu lo segua)? Tra l'altro ormai quel NG è deserto perché qualcuno s'è
> divertito a segnalarlo a Google ed è stato tolto da Google Groups per spam.

Si, esistono anche utenti finali che scrivono sui forum.
Ad esempio i commercialisti scrivono molto sui forum, dai newsgroup ai forum di linkedin.
Anche sul settore dei gestionali si trovano forum di utenti che si scambiano opinioni.
Ma tornando ai sistemi operativi, ci sono gruppi e forum in cui gli utenti ne decantano le lodi, ne parlano bene o male, ma almeno ne parlano.
Sono gruppi e forum di Windows, Linux, *BSD, MacOS, in cui gli utenti finali parlano del sistema operativo.
Per VMS invece vedo solo un gruppo di sistemisti, una cerchia ristretta di zeloti, che ne decanta le lodi, ma utenti finali non ne ho mai visti.
Tuttavia esisteranno.
Come altre forme di vita da qualche parte nell'universo :)

> > Nel codice Java ci si orienta molto bene, anche senza commenti.
>
> Io che Java non lo conosco quasi per niente (anzi, diciamo pure niente) lo trovo
> pressoché illeggibile. Viceversa capisco piuttosto bene il Cobol (anche se non è
> il mio primo linguaggio di lavoro) e lo capisco bene anche senza commenti.

Ci sono tutta una serie di considerazioni riguardo la leggibilità del codice che esulano dalla discussione iniziale :)
Leggevo tempo fa un articolo sul fatto che il codice è più leggibile per il team che l'ha scritto.
Ad esempio un team che usa la "conditional expression" è più abituato a leggerla, mentre chi non la usa fa difficoltà, nonostante che sia un costrutto storico del linguaggio.

> Mi è capitato di parlare di lingue straniere con una persona che non sa il
> francese (che io invece capisco e parlo abbastanza, anzi ultimamente ho scoperto
> di saperlo meglio di quanto credevo di ricordare): a me sembra piuttosto
> comprensibile e mi viene istintivo pensare che possa esserlo anche per chi non
> l'ha studiato; questa persona invece mi diceva di capirne ben poco.

Beh, semplicemente ci sono persone più o meno portate per le lingue, come per lo sport e l'arte.

> > Non vorrei sbagliare, mi sembra che per un periodo dei primi AS Power, il
> > collegamento ethernet avvenisse mediante una scheda PC x86 da aggiungere all'AS.
>
> Sbagli. :) Gli AS/400 hanno sempre avuto la Ethernet, o perlomeno hanno sempre
> avuto la possibilità di installarne una, fin dai primissimi modelli CISC bianchi
> del 1988. Certo, l'IBM spingeva più per la sua Token-Ring, ma Ethernet c'era.

Allora, sto cercando una ethernet per l'unico AS400 che ho.
Anche in questo senso non riesco a appacificarmi con gli AS400.
La fortuna non mi aiuta, pur avendo un AS400 non ho una ethernet ne una scheda 5250 per usarlo.
Sarà possibile?

Allora cerco in giro e trovo diverse schede 2838, ma per essere sicuro ho cercato se è compatibile con il 9401 che ho e su un forum di AS400 ho letto che non si può usare la 2838 come ethernet nativa ma solo utilizzarla come ethernet per la scheda Integrated PC Server.
http://compgroups.net/comp.sys.ibm.as400.misc/9401-150-and-2838-problems-please-hel/1341889

Essendo il 9401 uno dei primi AS Power, pensavo che i primi AS avessero la possibilità di andare in ethernet solo tramite scheda IPCS.
Evidentemente mi sbaglio.
Forse è solo la 2838 che non può essere usata nativamente.

> Quello che dici tu era l'integrated server, una scheda con una CPU x86 su cui
> installare Windows, la quale aveva a sua volta una porta Ethernet che poteva
> essere condivisa fra Windows e OS/400. Se poi uno non aveva la Ethernet e invece
> di comprare quella decideva di comprare tutto l'ambaradan con Windows solo per
> avere la rete, be', complimenti al commerciale del Business Partner IBM. :)

Sia una trovata commerciale, ma anche quello che si dice "Security through diversity".
Per arrivare all'AS devi prima impossessarti del IPC, e poi da lì all'AS.
Anche perché se non è per questo motivo, non credo ce ne fossero per dotarsi di una scheda IPCS.

> La PEC è proprio una robaccia tutta italiana! Io per fortuna non ho a che fare
> con la pubblica amministrazione (e me ne guardo bene), così mi evito le fatture
> XML e soprattutto l'archiviazione sostitutiva: le mie fatture le faccio in PDF e
> le mando ai clienti via mail, poi ne stampo una copia su carta (come fanno loro)
> e la tengo archiviata alla vecchia maniera. :)

Invece penso che la PEC è una delle poche cose che sono utili.
In pratica è una raccomandata A/R a costo di un canone annuale.
Trasmesse fatture via PEC nessuno può contestarti che "non è arrivata l'email".
Almeno uno dei problemi amministrativi più comuni tra azienda e azienda negli anni scorsi, è sparito.

> In realtà, visto che si parla di grossissimi volumi di stampa e visto che gli
> assegni sono roba vecchia che tende(rà) a scomparire, quelle stampanti sono
> utilizzate soprattutto per altro. Ma qui si parla di centri stampa veri e propri
> tipo Postel o società come la Telecom che stampano le bollette di milioni di
> italiani. Sono laser, ma non ci somigliano neanche: ricordano di più le rotative
> dei giornali e si mangiano diversi chili di toner in un'ora. :)
>
> Guarda che belline:

> ...

Non ne conoscevo l'esistenza.
Molto belle! :)

> > Allo stesso modo, non sono molte le aziende che elaborano 70M di record.
>
> Settanta milioni di record no, ma una decina sì, anche l'aziendina da tre
> scrivanie e due impiegati. :)

Beh si, dipende sempre cosa intendi per record.
La mia attuale deviazione NoSQL document-based mi fa pensare al record come oggetto intero (ad esempio testata+righe di fattura sono un documento nella logica document-based), mentre in altri sistemi è scomposto in più oggetti (testate e righe)
Due giorni fa ho fatto un dump di un database di un cliente dal 2008 al 2014 e su un server Xeon quad core con buoni dischi ha impiegato mezzora per una produzione di testo di 200 MB.
Non ho contato i record ma ho decisamente riconsiderato la quantità di dati prodotte da aziende piccole.
Anche perché per altri motivi ho dovuto rifare il dump due volte ed ero in territorio Far West Digita Divide (no-DSL no-3G) per cui ho avuto molto tempo per pensare :)

> > Molte aziende invece stampano la fattura dal sistema legacy e poi la passano
> > 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ù.

Lo fanno... lo fanno...
L'altro giorno da un cliente in avviamento mi è passata per le mani una fattura scansionata in PDF.
Testata e righe stampate da PC, il piede scritto a mano, si, esattamente, con la penna a sfera di colore blu.
Forse gli hanno chiesto dei soldi per mettere l'aliquota al 22% e hanno preferito fare i conti a mano... che ne so... non so darmi altra spiegazione

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

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

[G.]

On Sat, 11 Oct 2014 03:52:32 -0700 (PDT), Gianluca Bonetti <g...@decadence.it>
wrote:

> Allora, sto cercando una ethernet per l'unico AS400 che ho. Anche in questo
> senso non riesco a appacificarmi con gli AS400. La fortuna non mi aiuta, pur
> avendo un AS400 non ho una ethernet ne una scheda 5250 per usarlo. Sarà
> possibile? Allora cerco in giro e trovo diverse schede 2838, ma per essere
> sicuro ho cercato se è compatibile con il 9401 che ho e su un forum di AS400 ho
> letto che non si può usare la 2838 come ethernet nativa ma solo utilizzarla come
> ethernet per la scheda Integrated PC Server.

Dunque, premesso che la console 5250 o seriale (all'epoca più rognosa) ti
servirebbe in ogni caso, la ethernet giusta che non richiede altro hardware per
funzionare non è la 2838 a 10/100 Mbit, ma la 2723 a 10 Mbit, con RJ45 e AUI.

Il perché la 2838 richieda l'IPCS per funzionare rimane un mistero anche per me,
ma così è (e lo dice anche il System Handbook IBM). Ipotesi mia: a 100 Mbit è
troppo veloce per il bus e/o caricherebbe di troppi interrupt la CPU, motivo per
cui sfrutta parte della potenza dell'IPCS per fare offloading... Ci avrò preso?

> Essendo il 9401 uno dei primi AS Power, pensavo che i primi AS avessero la
> possibilità di andare in ethernet solo tramite scheda IPCS.

In realtà il 9401-150 non è uno dei primi Power, anzi è di seconda o terza
generazione (riconoscibile rispettivamente dallo zoccolo tutto nero o con la
parte bassa in rosso). I primi Power sono quelli tipo il mio 9402-400 che
infatti non è neppure PCI ma ha il vecchio bus proprietario SPD, quello con le
schedone "blindate" a libro. Esempio a caso: http://goo.gl/h0L9rl

Di queste ho sia una preziosa ethernet sia un'interfaccia SCSI esterna :)

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

[Gianluca Bonetti]

Il giorno domenica 12 ottobre 2014 00:16:22 UTC+2, G. ha scritto:
> Dunque, premesso che la console 5250 o seriale (all'epoca più rognosa) ti
> servirebbe in ogni caso, la ethernet giusta che non richiede altro hardware per
> funzionare non è la 2838 a 10/100 Mbit, ma la 2723 a 10 Mbit, con RJ45 e AUI.

Sono quasi a gettare la spugna, ne ho vista solo una sul "mercato" e me la sono fatta sfuggire.
Altre che si trovano in vendita sono tutte 2838 oppure altre che non credo compatibili.

> Il perché la 2838 richieda l'IPCS per funzionare rimane un mistero anche per me,
> ma così è (e lo dice anche il System Handbook IBM). Ipotesi mia: a 100 Mbit è
> troppo veloce per il bus e/o caricherebbe di troppi interrupt la CPU, motivo per
> cui sfrutta parte della potenza dell'IPCS per fare offloading... Ci avrò preso?

Chissà... non farmi domande su AS/400 :)
Ho dimostrato ampiamente di non conoscerne una cippa, ma vabbè qualcun altro potrebbe essere sintonizzato...

> In realtà il 9401-150 non è uno dei primi Power, anzi è di seconda o terza
> generazione (riconoscibile rispettivamente dallo zoccolo tutto nero o con la
> parte bassa in rosso). I primi Power sono quelli tipo il mio 9402-400 che
> infatti non è neppure PCI ma ha il vecchio bus proprietario SPD, quello con le
> 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

[test]

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

[G.]

On Tue, 14 Oct 2014 12:41:35 -0700 (PDT), Gianluca Bonetti <g...@decadence.it>
wrote:

> 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

[G.]

On Tue, 14 Oct 2014 20:00:11 +0000 (UTC), test <test_is_in...@gmail.com>
wrote:

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