Franco Lombardo

E' da qualche giorno che sulla lista italiana di "Exteme programming" infuoca una polemica su cosa sia XP, chi abbia il diritto di darne una definizione e quale definizione se ne debba dare. Non so perché, ma tutte queste discussioni mi fanno tornare in mente un brano dell'Apologia di Socrate. Ecco cosa Platone fa dire a Socrate.

E se qualcuno vi ha ancora detto che io faccio l’educatore e che ne ricavo gran guadagno, neppure questo è vero. Riconosco certo che è bello essere capace di educare gli uomini, come un Gorgia Leontino, un Prodico di Ceo, o un Ippia di Elide. A costoro è concesso, o Ateniesi, di andare di città in città e di attirare al loro insegnamento i giovani, i quali invece potrebbero benissimo, senza spendere nulla, frequentare l’insegnamento di quei concittadini che volessero scegliersi; quelli invece sanno persuaderli ad allontanarsi da questi e a venire loro, a pagarli profumatamente e a mostrare anche la dovuta gratitudine. Che dico? E’ venuto qui fra noi un sapiente uomo, un cittadino di Paro, come ho potuto apprendere per avere io parlato con uno che con i Sofisti ha speso più denaro che tutti gli altri messi insieme, Callia precisamente, il figlio d’Ipponico. Voi sapete che egli ha due figli; ebbene io ho voluto interrogarlo:
-Callia [...] A chi dunque è bene affidare [i giovani]? Chi è abile a sviluppare in loro le virtù proprie dell’uomo e del cittadino? Suppongo che tu ci abbia molto riflettuto, poiché hai dei figli. C’è qualcuno che ne sia capace o no?
-Certamente, mi rispose.
-E chi è costui, chiesi, e di quale paese è, e che prezzo chiede per il suo insegnamento?
-E’ Evèno di Paro, o Socrate, mi rispose, e chiede cinque mine.
-Felice Evèno, pensai io, se veramente possiede quest’arte e l’insegna a così modico prezzo! Anch’io mi sentirei fiero e felice se sapessi fare altrettanto; ma io non so, o Ateniesi.

Anche noi, come gli Ateniesi di oltre due millenni fa, ci troviamo nelle condizioni di dover distinguere gli insegnamenti dei sofisti da quelli dei socratici. Alcuni indizi potrebbero forse aiutarci.

• Il sofista è colui interessato più al guadagno che alla ricerca della verità.
• Il sofista annuncia agli altri di conoscere la verità, il socratico dichiara solo di ricercarla.
• Il sofista vuole imporre la propria autorità, al socratico l'autorevolezza è data dagli altri.

In base a questi criteri, in me molti dubbi sorgono su alcuni presunti "guru"....

Un altro Agile Day è passato ed eccomi nuovamente a scrivere un sommario della mia esperienza.

Peter Stevens - Fixed Price Projects With Agile – It can be done!

Possiamo stimare a priori tempi e costi di un progetto agile? Possiamo applicare i metodi agili quando il costo ed il tempo sono scolpiti nella pietra? Certo, sarebbe bello poter vivere in un mondo in cui tutti i contratti fossero tagliati sul concetto di iterazione, di sviluppo incrementale. Purtroppo ci sono occasioni nelle quali dobbiamo stimare i costi, nei quali dobbiamo sapere se riusciremo a rilasciare entro una certa data, magari remota. Chi, ad esempio, sviluppa il software per gestire grandi eventi come i mondiali di calcio non può chiedere di spostare la data della finale perché lavora in un team agile e ha bisogno di una nuova iterazione per completare le storie!

Peter Stevens ritiene che lo sviluppo agile si possa adattare a queste situazioni, anzi che sia il miglior metodo da adottare. Questo perché è l'unico sistema per valutare in corso d'opera la velocità alla quale lo sviluppo si sta svolgendo.

Per affrontare progetti di questo tipo occorre però:

• un cliente del quale fidarsi;
• una pianificazione che lasci "cuscinetti" liberi nei quali compensare eventuali ritardi;
• criteri certi (e automatizzabili) per determinare quando una funzionalità è conclusa;
• criteri per stabilire l'importanza delle varie funzionalità per realizzare prima le storie più importanti e consegnare alla fine del progetto, quando la pressione è maggiore e le energie si esauriscono, le funzioni di minor rilievo;
• un team esperto.

Maggiori dettagli sulla presentazione si trovano qui.

Alberto Brandolini - Possiamo fare di meglio

La presentazione mattutina di Alberto Brandolini è partita da una serie di provocazioni ad effetto sui seguenti temi.

• Spesso si rompe il rapporto di fiducia tra il software e chi lo usa, sia egli un utente finale o chi fa parte dello stesso team di sviluppo. Scatta allora il meccanismo della "complessità compensativa", cioè degli strani trucchi per aggirare i comportamenti errati dei sistemi.
• A volte gli sviluppatori accettano passivamente i requisiti che sono dati loro: ma chi dà questi requisiti è il vero esperto del problema, o, se lo è veramente, ha avuto modo di pensare ai requisiti in maniera critica? I requisiti non sono in alcuni casi semplicemente la mummificazione di un processo che potrebbe essere invece migliorato?
• Nei progetti software può nascere quello che è stato definito "technical debt". Brandolini suggerisce una metafora più calzante per questa progressiva deriva nella qualità del codice: inquinamento, ovverosia un processo estremamente dannoso, difficilmente reversibile e con un tempo di riparazione incalcolabile.
• A volte lo sviluppatore non ha abbastanza umiltà per capire di dover approfondire il dominio da un punto di vista non semplicemente informatico.

Dopo aver introdotto questi spunti di discussione, Brandolni ha lasciato la parola all'uditorio. L'esito di questo esperimento di "terapia di gruppo" a mio avviso non è però stato brillantissimo: purtroppo non è emerso molto di interessante, se non una collezione di aneddoti sul nostro lavoro.

Pietro Brambati - ASP.NET MVC: Programming & Testing

Dato che prima del pranzo non mi sembrava vi fossero relazioni degne d'interesse, mi sono infilato nell'auletta dedicata alla presentazione dell'ambiente di test creato per .NET MVC. Io odio gli strumenti di sviluppo Microsoft!!! Questo mio sentimento nacque anni fa quando Visual Basic 6, con un fantastico "Il controllo OCX non è registrato correttamente", mi fece affogare in un oceano marrone nel bel mezzo di una demo ad un centinaio di persone. Nonostante questo, mi è sembrato che il supporto di Microsoft ai test unitari sia discreto e che l'oratore, molto preparato, sia riuscito a dare a i colleghi della sponda Microsoft un buon numero di informazioni utili su come scrivere codice in modo più efficace. L'impressione comunque è che con questo prodotto Microsoft stia svolgendo un diligente compitino per conquistarsi la medaglietta "agile" e la relativa fetta di sviluppatori.

Alberto Quario - Scenario testing

Questo è forse stato l'intervento più interessante della giornata. All'Agile Day si è molto parlato di processi, ma ci si è un poco scordati del codice. Alberto Quario ci ha riportati nel cuore del problema, citando le parole di Gerard Meszaros: I test possono diventare il collo di bottiglia dei processi agili. (Ma allora non le sparavo così grosse quando parlavo dei test come palle al piede!). Uno dei principi da seguire per evitare che i nostri test divengano dei mostri incomprensibili, difficili da scrivere, leggere e manutenere è il seguente: nel corpo del test deve andare tutto e solo quanto è strettamente necessario per la sua comprensione.

Alcuni consigli sono quindi:

• radunare in metodi dal nome esplicito (operational methods) i dettagli di inizializzazione dello scenario del test
• se il test prevede, come nel caso si utilizzi DBUnit l'uso di file di inizializzazione, magari in XML, parametrizzarne la creazione rendendone chiaro l'intento all'interno del test

Francesco Mondora: vivere in un angolo proattivo

Francesco Mondora nel corso della sua presentazione ha detto di apprezzare eventuali riscontri da parte del pubblico. Ecco quindi il mio, che è purtroppo negativo. Il tema trattato mi è apparso fumoso, ed il tono ieratico utilizzato era probabilmente fuori luogo. Ma forse il problema è solo mio che non sono riuscito a capire cosa si volesse comunicare...

Alberto Brandolini - Introduzione al Domain Driven Design

Ecco un'altra gran bella sessione, nella quale Brandolini ha descritto con abilità e preparazione i principi del Domain Driven Design.

Entrare nel dettaglio di quanto visto è molto difficile, data la mole di informazioni trasmesse. Mi piacerebbe comunque segnalare il concetto di Bounded context, ossia il limite entro il quale il significato di un'astrazione del dominio è non ambigua, o, per usare una visione più orientata al codice, il limite di applicabilità di un gruppo di classi del sistema. Mi sono imbattuto in questo problema quando, nella mia presentazione su Scala, ho parlato di oggetti che ingrassano a dismisura. Da quanto ho capito, anche nel DDD ci si occupa di questo problema, ma da una prospettiva "sistemica": occorre definire l'ambito entro il quale è opportuno riutilizzare il codice che definisce un'astrazione. All'esterno di tale ambito è meno costoso riscrivere parte delle astrazioni ed accettare una certa duplicazione nei sistemi. Il tema, interessante e complesso, è alla base del fallimento di grandi utopie Object Oriented come il progetto San Francisco di IBM. Anzi, a mio avviso mette in discussione tutti i miti dell'Object Orientation a partire dalla riusabilità, ma forse converrà parlarne in un'altra occasione.

Conclusioni

Anche quest'anno l'Italian Agile Day non ha deluso le aspettative: relazioni quasi tutte di altissimo livello, con l'apprezzabile idea di aprire a contributi internazionali. Se proprio si vuole fare un piccolo appunto, si dovrebbe parlare di un'eccessiva enfasi posta sugli aspetti di processo a scapito delle sessioni "pratiche", anche se, come avete potuto leggere, i "puri" sviluppatori come me non hanno avuto occasione di annoiarsi.

Grazie a Marco Abis ed ai ragazzi dell'XPUG Bologna per l'enorme e riuscitissimo sforzo organizzativo.
(Ah, avete già donato qualcosa all'Agile Day? )

Ho partecipato ad un sondaggio promosso da un nostro fornitore. Alla domanda "Quali delle seguenti azioni sono state intraprese dalla Vostra azienda per affrontare la difficile congiuntura economica?" le risposte possibili erano:

• Riduzione dell’organico
• Riduzione degli stipendi
• Incremento dell’attività commerciale per trovare nuovi clienti
• Incremento delle tariffe
• Riduzione delle tariffe
• Automatizzazione delle attività svolte per i clienti
• Nessuna delle prededenti

La risposta "Investimento in ricerca e sviluppo per migliorare la qualità dei prodotti e dei servizi offerti" non era prevista!!!

Ecco, un bel sondaggio pensato da un managment lungimirante....

Ho deciso di provare il servizio di Slideshare pubblicando la presentazione su Scala che avevo tenuto presso l' XP-UG di bergamo qualche mese fa.

Ho finalmente completato il sito dell'artista contemporaneo Claudio Destito. Questo artista, che attinge al vocabolario del minimalismo reinterpretandolo in chiave nuova ed ironica, è a mio avviso uno degli autori più interessanti che operano attualmente nell'area di Milano.
E' stato interessante realizzare questo sito, sia perché le opere d'arte di Destito mi hanno coinvolto profondamente, sia perché ho avuto modo di scrivere codice di produzione in PHP.
L'impressione che ho avuto di questo linguaggio è stata ambivalente: da un lato PHP è uno strumento estremamente facile da apprendere, dall'altro...beh, forse non il più adatto a creare codice pulito. Ma probabilmente questo è solo l'impressione di un novizio: per avere un quadro diverso della situazione sarebbe magari opportuno seguire il corso sull'argomento di Francesco Cirillo

In questo post mostrerò la mia discutibilissima soluzione all’RDS Kata proposto sul blog di SI-Agile, il vivace gruppo che raccoglie gli agilisti della Svizzera Italiana. Il codice è presente in questo file zip, spero a breve di creare un progetto su Google Code per ulteriori sviluppi.

Funzioni di utilità

Partiamo subito con la prima sequenza di test.
Leggendo tutti i requisiti del Kata, ho pensato fosse necessario avere in primo luogo una funzione che centrasse le stringhe secondo le specifiche. Ho pertanto creato dei test per un metodo statico center da inserire nella mitica classe di utilità StringUtils, che non può mancare in qualsiasi progetto Java. Il primo banale test, testCenterDoesNotChangeTooLongStrings, mi è servito per disegnare l’interfaccia del metodo. Per scrivere i test successivi mi è sorta la necessità di avere una funzione blanks, che, guarda caso, mi è poi tornata utile anche nel codice di produzione. Ho deciso di non scrivere un test specifico per blanks, avendo fiducia che, una volta creata correttamente la funzione stringOf, la sua specializzazione che creasse stringhe di spazi fosse banale.
Uso qui volutamente il termine di funzione, in quanto questi metodi hanno la proprietà di trasparenza referenziale, ovvero restituiscono sempre gli stessi valori a fronte dei medesimi ingressi, indipendentemente da un qualsiasi concetto di “stato” del sistema; inoltre non hanno alcun effetto collaterale. Se ci fosse la possibilità di utilizzare i metodi statici come parametri di altre funzioni…
Concludendo le divagazioni, vorrei solo annotare che, per migliorare la leggibilità del codice e ridurre le duplicazioni, ho fatto un po’ di refactoring sui test estraendo il metodo assertCenterReturnsAStringOfFixedLength.

Le classi principali

Sono poi passato al disegno principale della mini applicazione tramite i test di RDSGeneratorTest che ho cercato di rendere indipendenti dal numero di caratteri del display.
Leggendo le specifiche del Kata ho cercato di elaborare una metafora: le varie parti da mostrare sul display (autore, data, titolo) sono gruppi distinti di parole, ovvero delle frasi. Ho quindi stilato i test di RDSSentenceTest, facendo anche in questo caso attenzione a rendermi indipendente dalla lunghezza del display. La prima stesura della classe RDSSentence, che comunque supera tutti i test, è stata la seguente:

 
public class RDSSentence {
 
  private final String sentence;
  private final int displaySize;
 
  public RDSSentence(String sentence, int displaySize) {
    this.sentence = sentence;
    this.displaySize = displaySize;
  }
 
  public String[] tokens() {
    if ("".equals(sentence.trim())) {
      return new String[]{};
    }
 
    String[] tokens = sentence.trim().split("\\s+");
    if (tokens.length == 0) {
      return new String[]{};
    }
 
    Collection<String> result = new ArrayList<String>();
    StringBuffer accumulator = new StringBuffer();
    for (int i = 0; i < tokens.length; i++) {
       if (accumulator.length() + tokens[i].length() + 1 <= displaySize) {
         if (accumulator.length() > 0)  {
           accumulator.append(" ");
         }
         accumulator.append(tokens[i]);
       } else {
         if (accumulator.length() > 0) {
           result.add(accumulator.toString());
         }
         accumulator = new StringBuffer(tokens[i]);
       }
       if (i == tokens.length -1) {
         result.add(accumulator.toString());
       }
    }
 
    return result.toArray(new String[]{});
  }
 
}
 

Come potete vedere, il codice è troppo complesso, con un numero ciclomatico molto elevato. Per un buon refactoring occorreva un’altra metafora: il display che accumula parole fino ad una certa lunghezza può essere appunto visto come un accumulatore elettrico, o, se vogliamo, idraulico che, raggiunta la capienza, si svuota in un tubo di scarico. Sono nate così le classi Accumulator e StringWharehouse, che non hanno test autonomi, ma vengono esercitate indirettamente dai test di RDSSentenceTest. La classe StringWharehouse, con una leggera modifica, mi è poi stata utile per migliorare il MockRadioStation, che in un primo tempo accumulava i dati in un semplice StringBuffer.

Conclusioni

Cosa ho cercato di esercitare con questo Kata?

• L’uso di metafore come guida per lo sviluppo.
• La costruzione di test robusti ad eventuali modifiche delle specifiche.
• La costruzione di codice di test leggibile e manutenibile quanto il codice di produzione.

Sicuramente non ho raggiunto completamente i miei obiettivi, spero comunque di aver fatto un piccolo passo in questa direzione.

Troppo spesso i sostenitori delle metodologie agili si fanno trasportare dall'entusiasmo, e, quando cercano di convincere qualche collega ad abbracciare l'agilismo, si lasciano scappare frasi come Quando inizierai a fare i test unitari vedrai che la tua produttività aumenterà. Niente di più falso: iniziare a scrivere i test unitari abbassa drammaticamente la produttività! Per quale motivo? Ho vissuto l'esperienza sulla mia pelle, ma la chiara consapevolezza delle ragioni del fenomeno mi è arrivata quando ho collaborato alla revisione di un ottimo volume pubblicato da Manning: The art of unit testing. Questo è il primo libro che abbia letto a mettere in evidenza un fatto spesso taciuto: i test unitari hanno un costo enorme, specialmente se non vengono scritti nel modo corretto.
Il costo dei test non risiede solamente nel tempo speso per la loro scrittura, ma, come per qualsiasi pezzo di software, soprattutto nello sforzo necessario per la loro manutenzione. Vi è inoltre un'altro aspetto da considerare nell'introduzione dei test unitari: il codice deve essere scritto in modo differente, secondo un design che consenta la testabilità. Questo, però, porta generalmente ad un miglioramento netto della qualità del software, anche se potrebbe indurre qualche programmatore maldestro in inutili complicazioni.
Dunque, perché i test unitari possono divenire una palla al piede? Perché il neofita generalmente non è in grado di scrivere test che abbiano le seguenti caratteristiche:

• Affidabilità
• Manutenibilità
• Leggibilità

Affidabilità

Come dicevo, i test unitari, anche se scritti bene, anche se generati automaticamente, costano. Quelli scritti male costano enormemente di più, ma tutti hanno in ogni caso un costo, quello della loro manutenzione. Siamo comunque invogliati a pagare un prezzo anche salato quando riceviamo in cambio un beneficio maggiore. Il beneficio dei test, oltre al già citato obbligo ad elaborare un design più efficiente, consiste nella loro affidabilità, che dovrebbe rispecchiare l'affidabilità generale del nostro software. Un test dovrebbe fallire se, E SOLO SE, esiste un errore nel software di produzione. Se il test fallisce anche per altre ragioni (un baco nel test, il DB che non è stato inizializzato opportunamente, il fatto che il test funzioni solo sul sitema operativo della mia macchina e non su quello che usano i miei colleghi), allora stiamo buttando dei soldi dalla finestra. Inoltre il test dovrebbe fallire in caso di errori. E' ovviamente impossibile riuscire a scrivere un test per tutti i possibili errori, ma questo dovrebbe essere il nostro obiettivo. Scrivere il test prima del codice, per poterlo vederlo fallire, è una tecnica che ci aiuta in questo senso.

Manutenibilità

Questa è la bestia nera dei test unitari. In molti casi è già un affare raggiungere l'affidabilità, la manutenibilità è in molti casi una chimera. Si dice spesso, a ragione, che dei buoni test aiutano il cambiamento del software. Test scritti male possono essere invece un ostacolo all'evoulzione del nostro programma. Quante volte ho visto andare in barra rossa decine di test per una piccola modifica nel protocollo di comunicazione con un oggetto! Come poter raggiungere questo obiettivo?

In primo luogo con il refactoring accurato del codice di test. Rimuovere duplicazioni dai test è fondamentale per non dover cambiare manualmente tonnellate di codice alla prima modifica nel nostro design.
Un altro punto chiave è quello di cercare di non testare lo stato privato di un oggetto, ma di verificarne il funzionamento in relazione ai suoi collaboratori (trasformati in opportuni Stub o Mock). Se questo non è possibile, allora potrebbe valere la pena di estrarre il comportamento nascosto in oggetti da testare separatamente.
Si deve inoltre fare attenzione a non testare più di quanto sia necessario: l'uso eccessivo di Mock quando degli Stub potrebbero essere sufficienti può farci incorrere in questo problema.

Leggibilità

La leggibilità dei test è fondamentale. Quando va in barra rossa un test illeggibile è come quando si accende una spia sconosciuta sul cruscotto di una macchina di cui non avete il libretto di manutenzione: o andate nel panico, o fate finta di nulla incrociando le dita e sperando che tutto vada bene.
Occorre curare i nomi dei test, senza aver paura di scrivere troppe lettere. testCarrello non significa nulla, testSeAggiungoUnProdottoAlCarrelloAumentaIlTotale indica chiaramente l'intento del test. Altri accorgimenti sono estrarre fasi di inizializzazione in medodi di servizio con nomi espressivi, definire il metodo toString in modo tale che mostri valori significativi in caso di fallimento, evitare di inserire magic numbers e, anche in questo caso, refactoring, refactoring, refactoring!

Conclusioni

Quindi non dobbiamo scrivere test, dobbiamo abbandonare il Test Driven Development (TDD)? No, al contrario, dobbiamo scrivere test con sempre maggiore cura, avendo ben chiaro che i test sono come i figli: non basta farli, poi bisogna anche mantenerli!

Dopo l'epoca del RAID (Redudant Arrays of Inexpensive Disks), è giunta l'ora del RAIS (Redudant Arrays of Inexpensive Servers)? Mi chiedo cioè se la disponibilità dei nuovi PlugComputer, unitamente alla diffusione di database distribuiti come CouchDB, non possa portare ad un nuovo modello di computazione, nel quale scalabilità ed affidabilità di elaborazione siano raggiunte tramite un enorme numero di piccolissimi server dai costi e dai consumi contenuti.

E' stata annunciata la data per lo svolgimento del sesto Italian Agile Day: si terrà il 20 novembre 2009 a Bologna. Come sempre la conferenza si annuncia interessantissima: vi darò aggiornamenti nei prossimi giorni.

La mente degli ingegneri IBM ha partorito un ennesimo mostro per la gestione della console dei sistemi AS400 (o iSeries o IBM i o come diavolo si chiamano questa mattina). Il deforme frutto del peccato si chiama Operation Console LAN (o LAN console). Il virgulto genera speciale raccapriccio per la sua particolarità di legare in modo indissolubile l'AS400 al PC sul quale la console è stata installata per la prima volta, come se la vita dei due dispositivi fosse intrecciata da un patto di sangue. Per spezzare questa catena elettronica ed installare la console su un nuovo PC, occorre effettuare dei riti esoterici sul pannello del server quattrocentesco. Alcuni narrano che nella prossima versione saranno necessari dei sacrifici umani! Vediamo comunque i passi da seguire attualmente.

Fase A: reset della Lan Console

In primo luogo occorre resettare la scheda ethernet quattrocentesca dedicata allo scopo. Seguendo le istruzioni IBM, si può procedere così:

1. Impostare sul pannello la modalità manuale: 01 B M
2. Selezionare la funzione 25 e premere invio
3. Selezionare la funzione 26 e premere invio
4. Selezionare la funzione 65 e premere invio
5. Selezionare la funzione 21 e premere invio
6. Selezionare la funzione 11 e premere invio La funzione 11 ha lo scopo di mostrare sul pannello di controllo un codice che descrive la situazione corrente della procedura. Nel nostro caso dovrebbe apparire A603500A. Questi codici hanno la forma A6xx500y, dove le cifre xx hanno il seguente significato:

   00 = Nessuna console definita
   01 = Console biassiale
   02 = Operations Console (Diretta)
   03 = Operations Console (LAN )
   04 = HMC (Hardware Management Console)
          oppure Thin Console
   C3 = Annulla la configurazione LAN
   A3 = Disattivazione seguita dall'attivazione
          dell'adattatore LAN di Operations Console
   DD = Dump di tutti i flight recorder relativi alla
          console in una serie di vlog
   D1 = Disabilita la porta Ethernet incorporata
   D2 = Disabilita l'adattatore LAN 5706/5707 aggiuntivo
   E1 = Abilita la porta Ethernet incorporata
   E2 = Abilita l'adattatore LAN 5706/5707 aggiuntivo
   Bn = Abilita l'adattatore LAN nell'alloggiamento
          (C1, C2, C3, C4, C5)
   Fn = Abilita l'adattatore asincrono nell'alloggiamento
           (C1, C2, C3, C4, C5)

   La cifra y è invece da interpretarsi così:

    A6xx 500A = Viene visualizzato il valore corrente della console.
    A6xx 500B = È stata eseguita una seconda coppia di funzioni 65+21,
                     pertanto si è in modalità modifica.
    A6xx 500C = È stata eseguita una seconda funzione 21
                     per eseguire un'azione.
    A6xx 500D = È trascorso troppo tempo dopo avere impostato
                      la modalità modifica per eseguire un'azione.

   Nel nostro caso, quindi, il codice dice che siamo in modalità visualizzazione (A) e che la console è l'Operations console LAN (03)

7. Selezionare la funzione 65 e premere invio
8. Selezionare la funzione 21 e premere invio. A questo punto abbiamo richiesto di incrementare il contatore xx, quindi la funzione 11 dovrebbe mostrare il codice A604500B
9. Selezionare la funzione 65 e premere invio
10. Selezionare la funzione 21 e premere invio
11. Selezionare la funzione 11 e premere invio. Il display dovrebbe mosrare il codice A6A3500B che indica che stiamo per chiedere il reset dell'adattatore LAN console.
12. Selezionare la funzione 21 e premere invio. Ciò dovrebbe eseguire l'azione, ed il codice sul pannellino dovrebbe divenire A6A3500C come conferma.
13. Proseguiamo con una serie di 65 21 11 sino a giungere al valore A6E1500B, per essere sicuri che la porta ethernet della console sia abilitata.
14. Confermiamo con il codice 21 e verifichiamo con il codice 11 che sul pannello appaiaA6E1500B.

Ricapitolando, la prima sequenza 65 21 mostra lo stato della console, la seconda e le successive incrementano le cifre xx, il codice 21 conferma la modifica, mentre con 11 si visualizza sul display l'SRC che indica lo stato corrente dell'operazione.

Fase B: rottura del legame tra PC e AS400

Come dicevamo, tra l'AS400 ed il PC che ne costutuisce la LAN console si instaura un patto di sangue elettronico, sancito da uno scambio di password tra i due. Per romperlo è necessario utilizzare nuovamente il pannello di controllo, come descritto in questo documento IBM.

1. Impostare sul pannello la modalità manuale: 01 B M
2. Selezionare la funzione 25 e premere invio
3. Selezionare la funzione 26 e premere invio
4. Selezionare la funzione 65 e premere invio
5. L'operazione 65 deve essere eseguita sette volte. Per verificare il contatore, utilizzare la funzione 13

Concludo con un link ad un documento che può aiutare ad orientarsi nel mare periglioso della LAN console.