/ 0
Il 7070/7074 durante gli anni '60.
Superati i primi mesi di "parallelo" con il centro meccanografico, il nuovo centro elettronico del banco di Napoli, funzionava perfettamente e si era già sostituito per la maggior parte della meccanizzazione alle vecchie macchine.
Noi programmatori, continuavamo a scrivere nuovi programmi, miglioravamo continuamente quelli già funzionanti e a turno ci occupavamo direttamente del funzionamento della sala macchine.
Il centro lavorava 24 ore al giorno e si fermava soltanto alla domenica. Nella notte si facevano eseguire i programmi più importanti che duravano ore ed ore.
Le elaborazioni erano tutte batch e l'aggiornamento dell'archivio dei conti correnti o di quello dei depositi a risparmio erano quelli di maggior durata; le elaborazioni erano settimanali e gli inventari letti da un file che risiedeva su una serie di bobine di nastro venivano ricopiati su una nuova serie di nastri con l'aggiunta di tutta la movimentazione della settimana.
Ricordo che mi capitava spesso di far eseguire di notte il programma di aggiornamento dei depositi a risparmio (programma che io stesso avevo scritto); l'archivio impegnava otto bobine di nastro e i movimenti provenivano da un altro nastro; l'elaborazione durava quasi tutta la notte, in quell'occasione io ero il responsabile della sala macchina ed ero aiutato da un altro collega; ero seduto di solito alla console ed usavo appoggiare la testa sulla scrivania per sonnecchiare; venivo svegliato dal ticchettio della console all'incirca dopo ogni mezz'ora che richiedeva di cambiare un nastro di input o di output; mi alzavo, eseguivo l'perazione richiesta, premevo il tasto di START e riprendevo a sonnecchiare.
Qualche volta però la nottata poteva essere più movimentata; questo accadeva di solito quando si verificava un errore di lettura su una delle bobine di nastro dell'input; a questo punto si cercava di risolvere il problema così:
- Poichè l'errore veniva segnalato dopo che le routines dell'IOCS avevano già ritentata più volte la lettura, era assai difficile che riprovando ancora si poteva riuscire a leggere il blocco in errore; ciò nonostante aprivamo la porta dell'unità nastro in errore, segnavamo la posizione del nastro sulla sua parte non registrata in modo da poterlo riposizionare poi esattamente dove si trovava, aprivamo la testina di lettura/scrittura, soffiavamo sulle testine e sul nastro per eliminare l'eventuale polvere presente, richiudevamo il meccanismo di lettura/scrittura e con un apposito tasto presente sulla console ausiliaria e aiutandoci con i segni fatti col pennarello riposizionavamo il nastro al punto dove si era fermato; ancora con un tasto della console ausiliaria facevamo andare il nastro indietro di un record fisico e poi dalla console facevamo in modo che il programma (fermo immediatamente dopo l'errore di lettura) ripartisse nuovamente dall'istruzione di lettura, facendolo andare a "single cycle" per eseguire soltanto quell' istruzione; se gli strumenti disponibili della console mostravano che la lettura era andata bene proseguivamo con l'elaborazione e tutto era finito, altrimenti dovevamo tentare di risolvere il problema con le altre azioni descritte qui di seguito; prima però mi piace di ricordare che qualche volta nell'aprire il meccanismo di lettura/scrittura ci si accorgeva che il nastro non era impolverato ma era tutto pieghettato (un mio collega diceva che era "plissettato"), questa spiegazzatura si creava per un malfunzionamento dell'unità nastro durante la fase di riavvolgimento e precisamente quando si passava dal riavvogimento veloce a quello lento; in questo caso c'era un collega che si era specializzato nella "stiratura del nastro" e allora ricorrendo al trattamento che solo lui era capace di attuare, spesso ci salvavamo anche in quelle malaugurate occasioni.
- Comunque se la lettura fatta in "single cycle" non era andata a buon fine c'era ancora una speranza di risolvere il problema, esaminando la lista del programma si individuava l'indirizzo del buffer di lettura, con la console si esaminavano le varie word che lo componevano e conoscendo il tracciato record del file che si stava leggendo, si riconoscevano i dati letti; molto spesso l'errore di lettura aveva reso illeggibili soltanto pochi caratteri, i quali quando dovevano essere stampati dalla typewriter della console, non essendo interpretabili venivano evidenziati esponendo in colore rosso i singoli bit costituenti il carattere stesso; con molta pazienza, e qualche volta andando perfino ad esaminare i tabulati che andavamo a prendere negli uffici controllo dei piani di sopra (che naturalmente di notte non erano presidiati), molto spesso riuscivamo a ricostruire i records errati, li correggevamo direttamente nel buffer in memoria e facevamo poi riprendere l'elaborazione; ma se il record era così illeggibile da non poter essere corretto rimaneva soltanto un'ultima possibilità.
- Se la nottata era proprio ..nera, si poteva arrivava anche a questa fase, e se il nastro era assolutamente illeggibile non restava che ricostruirlo rieseguendo l'intera lavorazione della settimana precedente; in questo caso arrivavamo tranquillamente al mattino senza aver ancora completato il lavoro; ma una brillante soluzione fornita dall'IBM per ridurre questo tempo, consentì nei tempi successivi di ridurre fortemente i tempi di ricostruzione di un nastro illeggibile.
Credo che l'illustrazione dell'intelligente sistema che IBM suggeriva di adottare per ridurre i tempi di ricostruzione di una bobina di nastro non leggibile valga la pena di essere ricordata:
Premetto che in caso di errore di lettura irrecuperabile, se ad esempio in una lavorazione che prevedeva di leggere un file che impegnava 8 bobine si verificava l'errore alla quinta bobina, l'unica soluzione era quella di rieseguire la lavorazione precedente riproducendo le 8 bobine e poi ricominciare la lavorazione che si era interrotta dall'inizio; in questo caso quindi invece di leggere soltanto 8 bobine, se ne dovevano leggere 21; la combinazione di due "features" offerte dalla IBM (il checkpoint e il forced-end-of-reel) consentivano in questo caso di leggere complessivamente invece soltanto 10 bobine; per ottenere questo risultato bisognava richiedere all'IOCS di scrivere un checkpoint ad ogni cambio di bobina di input o di output (il checkpoint consisteva nella scrittura su un'apposita ulteriore unità nastro di un dump o fotografia della memoria presa al momento del cambio di bobina sia di input che di output); inoltre una modifica da farsi nei programmi doveva richiedere il cambio di bobina dei nastri di output prima che il nastro finisse fisicamente (lo si faceva richiamando la funzione di forced-end-of-reel dopo la scrittura di un numero di records che si era certi potessero essere accolti dal nastro) e ciò per avere la certezza che anche se si fosse ripetuta la lavorazione con nastri di lunghezza leggermente diversa o utilizzando unità nastro diverse che potevano produrre gaps più lunghi, ogni bobina prodotta avrebbe contenuto sempre lo stesso numero di records; fatto questo, se ad esempio si interrompeva una lavorazione per errore sulla quinta di 8 bobine, si poteva far ripartire la lavorazione precedente dal checkpoint prodotto al cambio tra la quarta e la quinta bobina di output e continuare quell'elaborazione fino a quando la quinta bobina fosse stata completamente prodotta; a questo punto si poteva ripartire con la lavorazione interrotta, facendola riprendere dal checkpoint prodotto al cambio tra la quarta e la quinta bobina di input utilizzando come quinta bobina quella appena ricostruita e continuando poi a montare le bobine successive alla quinta del vecchio set di bobine, sicuri che la sesta bobina sarebbe stata la giusta continuazione della quinta ricostruita.