Tra COBOL e dump

Bene, ora parliamo di dump. Avete presente quello che ho detto a proposito della tesi di laurea? Ecco: se lì ho avuto a che fare con chili di carta, qui si trattava di tonnellate.

Probabilmente ci sono molte persone, oggi, che non sanno cos’è un dump:
quando un programma va in errore (esiste un modo più professionale per dire che un programma va in errore: si dice che va in abend, ovvero che avviene “un’interruzione non pianificata di un programma software”. In parole povere, succede quando il computer cerca di fare un’operazione che non capisce, e termina il programma: avete presente Word di Office2000?), dicevamo: quando un programma va in errore, la stampa dello stato della memoria al momento dell’errore si chiama dump.

Lavorando su un mainframe (grande calcolatore) la stampa del dump avveniva in codifica esadecimale su fogli a 132 colonne a lettura semplificata.

Bene, quando lavoravo come analista programmatore di applicazioni gestionali in ambito bancario, avevo a che fare, in media, con un dump alla settimana. Conoscendo il programma, sapendo dove era allocata nella memoria e come era strutturata l’area delle variabili, io ne ricostruivo il contenuto nel momento dell’errore, e cercavo di capire cosa lo avesse generato. A quel punto tentavo la correzione del programma, e riprovavo. Se l’errore era banale, si risolveva in poco; altrimenti si generava una successione continua di dump.

In quel periodo ho trascorso 18 mesi nello sviluppo di un sistema di gestione dei libretti al risparmio: il programma più complicato era quello per il calcolo degli interessi mensili.

Programmavo in Cobol, uno dei primi linguaggi di programmazione: il primo programma l’ho scritto sui fogli di minuta che un collega correggeva con la penna rossa.

Sul piano più strettamente personale, all’epoca misi su 12 chili in 6 mesi, visitando approfonditamente tutti i ristoranti di Vicenza.

(continua)