Sign In
Create Account
Viandante Ad Honorem
.
Un cappuccino malupino
PSg01 era giornaliero, come chiaramente indica la “g” centrale.
Una procedura elaborativa riguardante la gestione delle cambiali presentate allo sconto dai clienti da eseguire quotidianamente, per l’aggiornamento degli archivi. Esecuzione solitamente notturna, per aver pronti i tabulati all’arrivo degli impiegati degli uffici amministrativi.
Quella notte, evidentemente qualcosa era andata storta perché i tabulati erano pieni di errori.
I colleghi degli uffici di controllo se ne accorsero quasi subito e dettero l’allarme: tempestivamente nei modi previsti.
Il nostro CED funzionava abbastanza bene, ma ovviamente di tanto in tanto qualche errore umano sfuggiva o c’era un malfunzionamento delle macchine o qualche altra diavoleria. Nulla di strano, vista la mole enorme di dati che venivano elaborati in poco meno di cento procedure suddivise in circa milleseicento “Jobs”, cioè lavorazioni diverse.
Come “paracadute” erano previsti molti possibili interventi per superare le situazioni di crisi, e procedure di salvataggio e ripristino per garantire la sicurezza e l’integrità delle informazioni.
Dal caso di un errore di programma o guasto di un elaboratore, fino al sabotaggio, all’incendio al terremoto o la distruzione totale dell’edificio ogni possibile accidente era stato analizzato.
Infine c’era il mio ufficio, il X/I detto anche “Ultima Thule”, che aveva fra i suoi compiti istituzionali quella di farsi carico di ogni emergenza che non fosse stata altrimenti prevista.
Qualunque emergenza: piccola o grande che fosse.
PSg01 era dunque uno dei “Jobs” di normale routine lavorativa. Era composto da diciotto programmi, e quella notte andò, inspiegabilmente, a pallino. I tabulati erano sbagliati, assurdamente, incomprensibilmente sbagliati.
E la cosa fu segnalata alla “Gestione” ed alla “Schedulazione” che immediatamente si attivarono per scoprire cosa non avesse funzionato o che errore si fosse verificato.
Prima di pranzo era stato accertato oltre ogni ragionevole dubbio che non si era sbagliato nulla e non si erano verificate “pannes” o disfunzioni nei calcolatori. Ci si era accertati anche che nessuno dei 18 programmi interessati al “Job” fosse stato modificato di recente.
Nulla di nulla.
Si trattava evidentemente di una rogna, e dopo aver tentato e scartato tutte le vie logiche, il problema fu passato al mio ufficio. Senza, come al solito, un briciolo di indizio.
Ricontrollammo tutto daccapo, non certo per sfiducia nei colleghi ma piuttosto dubbiosi su cos’altro tentare, ma ovviamente senza esito; di errori, nemmeno l’ombra.
Alle tre del pomeriggio, ma solo per scrupolo decisi: «si ripeta integralmente il Job»… ed ottenemmo identici risultati identicamente sbagliati.
Pensammo potesse esserci stata qualche contaminazione dei dati in ingresso, forse negli archivi da aggiornare o negli aggiornamenti da fare, ed anche se le indagini a campione, già fatte, avevano dato risultati negativi, e decidemmo di ripetere integralmente anche il ciclo di lavorazione del giorno precedente che aveva prodotto i nostri inputs e che era andato a buon fine.
In qualche modo fu questa la mossa vincente, anche se di vittoria non si potesse proprio parlare. La lavorazione ripetuta risultò questa volta piena di errori. Gli stessi assurdi inconcepibili errori su cui stavamo sbattendo la testa da ore.
Il Capocentro intervenì di autorità (si era ormai all’indomani ed io non ero affatto tornato a casa) e dispose che si ripetesse per controprova anche la lavorazione ancora precedente… che dette risultati parimenti sbagliati.
Punto della situazione: non eravamo più in grado di eseguire correttamente il PSg01, ma non sapevamo perché. Andai a casa, per dormirci sopra. Ma non ci restai a lungo.
A mali estremi, estremi rimedi. Sfasciammo il Job per eseguirlo passo passo, un programma alla volta, analizzando ogni “input” ed ogni “output”.
Trovammo quasi subito il programma che rovinava i dati. Era di “Carlucciello” , modificato l’ultima volta… venticinque mesi prima!…
Considerando la periodicità giornaliera del Job, questo programma aveva “girato” per più di cinquecento volte senza dare fastidi ed ora, di colpo, non voleva funzionare più.
Pensammo subito ad un sabotaggio, perché era quello il tempo dei primi attentati e degli allarmi-bomba negli uffici, ma naturalmente un sabotaggio stupido, perché ovviamente la copia originale del programma era ben custodita…
Riprovammo con la “copia del caveau”… e due ore dopo ci ritrovammo con gli stessi errori fra le braccia.
Nuovo punto della situazione: abbiamo un programma che non ha mai sbagliato, che non è stato modificato e che ora sbaglia improvvisamente e non riesce nemmeno a rifare cose che solo un giorno prima (ormai due giorni prima) aveva già fatto bene… Ovvio!… non dipende dal programma ma dal computer!… che nel frattempo però ha lavorato per altre cinquanta ore con altre centinaia di programmi senza dare il benché minimo problema!…
Poco, poco, poco… niente credibile. Il problema “deve” essere nel programma.
“Carlucciello” ed io, ci sediamo alla stessa scrivania. Memori di tanti patimenti sofferti insieme a cercare diavolerie nei programmi quando eravamo ancora allievi, scordiamo del tutto di essere responsabili ormai di due settori diversi e talvolta in competizione. Non c’è più da fare polemiche su di chi sia la colpa del malfunzionamento. Sappiamo entrambi che l’errore dobbiamo trovarlo noi, e che è in questo suo programma, anche se preferiremmo credere a streghe e fantasmi.
Controlliamo il programma in ogni sua singola istruzione facendo “il gioco del calcolatore” una volta, due, tre. Puntigliosamente, ogni volta daccapo.
E troviamo una istruzione “Assembler” sbagliata.
Un’istruzione del ramo principale, eseguita per ogni documento considerato. Un’istruzione già eseguita molte decine di milioni di volte!
Voleva semplicemente dire: “Se quel Byte è diverso da zero…. Fai una certa routine”. Era l’analisi del caso particolare, forse mai verificatosi, di una cambiale che, richiamata, fosse stata usata per un “risconto” (operazione anche questa eccezionale) con la Banca d’Italia.
Non c’era nessun “risconto”, in quel periodo.
Così com’era invece codificata erroneamente diceva al computer: “Se quel Byte ha un valore diverso da quello della posizione di memoria n° zero del calcolatore…eccetera”.
In tanti anni di funzionamento del programma non c’erano stati disguidi perché la memoria n° zero di quei calcolatori era normalmente effettivamente a zero. Le memorie di ordine molto basse infatti servivano ai tecnici dell’IBM per i loro programmi di test durante la manutenzione. Loro ci lavoravano, poi d’abitudine ripulivano la memoria azzerando tutto prima di restituire la macchina agli operatori.
Confrontare con zero, o con qualcosa che sia zero, è naturalmente lo stesso; ed il programma di Carlucciello era sempre andato avanti tranquillo. Ma…
Ma l’ultima manutenzione era stata davvero sfibrante per il nostro tecnico di turno: aveva dovuto caricare e controllare decine di “patchs” , sgobbando per molte ore filate.
E con gli operatori, al solito, ad alitargli sul collo per riavere presto l’elaboratore per le lavorazioni usuali:
«Alla fine non ce la facevo più» ci confermò candidamente: «dopo aver inserito l’ultima modifica, controllata ed “ok”ho piantato tutto lì e sono corso difilato al bar a prendermi un cappuccino.
E non ho rifatto l’IPL ».
L’esperienza di programmatori che giocavano coi Bytes si maturava anche così: con gli errori criptici ed i cappuccini malupini!
Lucio Musto 5 novembre 2004 Parole 1201
-----------------------------------------------------------------------------------
Un cappuccino malupino
Cronache di quando il Byte già c'era
ma non sapeva ancora di chiamarsi così
ma non sapeva ancora di chiamarsi così
PSg01 era giornaliero, come chiaramente indica la “g” centrale.
Una procedura elaborativa riguardante la gestione delle cambiali presentate allo sconto dai clienti da eseguire quotidianamente, per l’aggiornamento degli archivi. Esecuzione solitamente notturna, per aver pronti i tabulati all’arrivo degli impiegati degli uffici amministrativi.
Quella notte, evidentemente qualcosa era andata storta perché i tabulati erano pieni di errori.
I colleghi degli uffici di controllo se ne accorsero quasi subito e dettero l’allarme: tempestivamente nei modi previsti.
Il nostro CED funzionava abbastanza bene, ma ovviamente di tanto in tanto qualche errore umano sfuggiva o c’era un malfunzionamento delle macchine o qualche altra diavoleria. Nulla di strano, vista la mole enorme di dati che venivano elaborati in poco meno di cento procedure suddivise in circa milleseicento “Jobs”, cioè lavorazioni diverse.
Come “paracadute” erano previsti molti possibili interventi per superare le situazioni di crisi, e procedure di salvataggio e ripristino per garantire la sicurezza e l’integrità delle informazioni.
Dal caso di un errore di programma o guasto di un elaboratore, fino al sabotaggio, all’incendio al terremoto o la distruzione totale dell’edificio ogni possibile accidente era stato analizzato.
Infine c’era il mio ufficio, il X/I detto anche “Ultima Thule”, che aveva fra i suoi compiti istituzionali quella di farsi carico di ogni emergenza che non fosse stata altrimenti prevista.
Qualunque emergenza: piccola o grande che fosse.
PSg01 era dunque uno dei “Jobs” di normale routine lavorativa. Era composto da diciotto programmi, e quella notte andò, inspiegabilmente, a pallino. I tabulati erano sbagliati, assurdamente, incomprensibilmente sbagliati.
E la cosa fu segnalata alla “Gestione” ed alla “Schedulazione” che immediatamente si attivarono per scoprire cosa non avesse funzionato o che errore si fosse verificato.
Prima di pranzo era stato accertato oltre ogni ragionevole dubbio che non si era sbagliato nulla e non si erano verificate “pannes” o disfunzioni nei calcolatori. Ci si era accertati anche che nessuno dei 18 programmi interessati al “Job” fosse stato modificato di recente.
Nulla di nulla.
Si trattava evidentemente di una rogna, e dopo aver tentato e scartato tutte le vie logiche, il problema fu passato al mio ufficio. Senza, come al solito, un briciolo di indizio.
Ricontrollammo tutto daccapo, non certo per sfiducia nei colleghi ma piuttosto dubbiosi su cos’altro tentare, ma ovviamente senza esito; di errori, nemmeno l’ombra.
Alle tre del pomeriggio, ma solo per scrupolo decisi: «si ripeta integralmente il Job»… ed ottenemmo identici risultati identicamente sbagliati.
Pensammo potesse esserci stata qualche contaminazione dei dati in ingresso, forse negli archivi da aggiornare o negli aggiornamenti da fare, ed anche se le indagini a campione, già fatte, avevano dato risultati negativi, e decidemmo di ripetere integralmente anche il ciclo di lavorazione del giorno precedente che aveva prodotto i nostri inputs e che era andato a buon fine.
In qualche modo fu questa la mossa vincente, anche se di vittoria non si potesse proprio parlare. La lavorazione ripetuta risultò questa volta piena di errori. Gli stessi assurdi inconcepibili errori su cui stavamo sbattendo la testa da ore.
Il Capocentro intervenì di autorità (si era ormai all’indomani ed io non ero affatto tornato a casa) e dispose che si ripetesse per controprova anche la lavorazione ancora precedente… che dette risultati parimenti sbagliati.
Punto della situazione: non eravamo più in grado di eseguire correttamente il PSg01, ma non sapevamo perché. Andai a casa, per dormirci sopra. Ma non ci restai a lungo.
A mali estremi, estremi rimedi. Sfasciammo il Job per eseguirlo passo passo, un programma alla volta, analizzando ogni “input” ed ogni “output”.
Trovammo quasi subito il programma che rovinava i dati. Era di “Carlucciello” , modificato l’ultima volta… venticinque mesi prima!…
Considerando la periodicità giornaliera del Job, questo programma aveva “girato” per più di cinquecento volte senza dare fastidi ed ora, di colpo, non voleva funzionare più.
Pensammo subito ad un sabotaggio, perché era quello il tempo dei primi attentati e degli allarmi-bomba negli uffici, ma naturalmente un sabotaggio stupido, perché ovviamente la copia originale del programma era ben custodita…
Riprovammo con la “copia del caveau”… e due ore dopo ci ritrovammo con gli stessi errori fra le braccia.
Nuovo punto della situazione: abbiamo un programma che non ha mai sbagliato, che non è stato modificato e che ora sbaglia improvvisamente e non riesce nemmeno a rifare cose che solo un giorno prima (ormai due giorni prima) aveva già fatto bene… Ovvio!… non dipende dal programma ma dal computer!… che nel frattempo però ha lavorato per altre cinquanta ore con altre centinaia di programmi senza dare il benché minimo problema!…
Poco, poco, poco… niente credibile. Il problema “deve” essere nel programma.
“Carlucciello” ed io, ci sediamo alla stessa scrivania. Memori di tanti patimenti sofferti insieme a cercare diavolerie nei programmi quando eravamo ancora allievi, scordiamo del tutto di essere responsabili ormai di due settori diversi e talvolta in competizione. Non c’è più da fare polemiche su di chi sia la colpa del malfunzionamento. Sappiamo entrambi che l’errore dobbiamo trovarlo noi, e che è in questo suo programma, anche se preferiremmo credere a streghe e fantasmi.
Controlliamo il programma in ogni sua singola istruzione facendo “il gioco del calcolatore” una volta, due, tre. Puntigliosamente, ogni volta daccapo.
E troviamo una istruzione “Assembler” sbagliata.
Un’istruzione del ramo principale, eseguita per ogni documento considerato. Un’istruzione già eseguita molte decine di milioni di volte!
Voleva semplicemente dire: “Se quel Byte è diverso da zero…. Fai una certa routine”. Era l’analisi del caso particolare, forse mai verificatosi, di una cambiale che, richiamata, fosse stata usata per un “risconto” (operazione anche questa eccezionale) con la Banca d’Italia.
Non c’era nessun “risconto”, in quel periodo.
Così com’era invece codificata erroneamente diceva al computer: “Se quel Byte ha un valore diverso da quello della posizione di memoria n° zero del calcolatore…eccetera”.
In tanti anni di funzionamento del programma non c’erano stati disguidi perché la memoria n° zero di quei calcolatori era normalmente effettivamente a zero. Le memorie di ordine molto basse infatti servivano ai tecnici dell’IBM per i loro programmi di test durante la manutenzione. Loro ci lavoravano, poi d’abitudine ripulivano la memoria azzerando tutto prima di restituire la macchina agli operatori.
Confrontare con zero, o con qualcosa che sia zero, è naturalmente lo stesso; ed il programma di Carlucciello era sempre andato avanti tranquillo. Ma…
Ma l’ultima manutenzione era stata davvero sfibrante per il nostro tecnico di turno: aveva dovuto caricare e controllare decine di “patchs” , sgobbando per molte ore filate.
E con gli operatori, al solito, ad alitargli sul collo per riavere presto l’elaboratore per le lavorazioni usuali:
«Alla fine non ce la facevo più» ci confermò candidamente: «dopo aver inserito l’ultima modifica, controllata ed “ok”ho piantato tutto lì e sono corso difilato al bar a prendermi un cappuccino.
E non ho rifatto l’IPL ».
L’esperienza di programmatori che giocavano coi Bytes si maturava anche così: con gli errori criptici ed i cappuccini malupini!
Lucio Musto 5 novembre 2004 Parole 1201
-----------------------------------------------------------------------------------
