Machine Learning e l’uomo di Piltdown

Nell'interessante libro "Il pollice del Panda" si parla, tra l'altro, del caso dell'Uomo di Piltdown, una truffa perpetrata ai danni del mondo accademico nei primi anni del secolo scorso. Alcuni resti di un presunto ominide vennero ritrovati in Inghilterra: essi comprendevano una scatola cranica dalle fattezze umane ed una mandibola simile a quella di un orango. Tale era il desiderio del mondo accademico inglese di trovare finalmente sul suolo patrio un reperto paleontologico di rilievo, che subito la scoperta fu accettata da valenti studiosi.

Ai dubbi dello scienziato tedesco Franz Weidenreich sull'incongruenza reciproca dei reperti, Sir Keith rispose: "Questo non è altro che il tentativo di liberarsi di quei dati che non possono essere fatti rientrare nell'ambito di una teoria precostituita. Uno scienziato non dovrebbe eliminare tali fatti, ma dovrebbe costruire teorie in grado di spiegarli."

E qui arriva l'analogia con le tecniche di Machine Learning. Quando all'interno di un campione di dati sul quale stiamo addestrando un algoritmo di Data Mining troviamo degli elementi che si discostano palesemente da quanto visto in precedenza, abbiamo due possibilità.  La prima, nell'esempio dell'uomo di Piltdown,  è quella di adottare la posizione di Weidenreich: riteniamo che i dati siano degli errori nel campione, e quindi li scartiamo,  o filtrandoli oppure utilizzando un algoritmo che eviti l'overfitting su di essi.

La seconda possibilità è quella di seguire quanto disse (ma non fece) Sir Keith: elaboriamo una nuova teoria in grado di spiegarli, cioè modifichiamo i parametri dell'algoritmo di classificazione/regressione che stiamo utilizzando, oppure ne utilizziamo uno differente.

Sir Keith, invece, fece quanto non si dovrebbe mai fare: modificò i dati per adattarli alla teoria corrente. Egli infatti sottostimò il volume della scatola cranica trovata per renderla compatibile con quella di un ominide antenato dell'Homo Sapiens.

Meditate, gente, meditate!

Statement SQL per determinare il nome dell’AS400 corrente

Per determinare il nome della macchina AS400 alla quale ci stiamo connettendo, è possibile utlizzare il seguente semplice statement SQL:

SELECT DATABASE() FROM SYSIBM.SYSDUMMY1

Attenzione: lo statement funziona solo con sistemi operativi V5R3 e superiori.

Collegamento Windows 7 a IFS netserver AS400

Per collegarsi all'IFS di AS400 da Windows 7 occorre seguire i passi descritti nel seguente documento IBM.

In particolare, lanciare SECPOL.MSC e modificare i 2 valori come in figura, quindi riavviare il PC.




Per collegare il disco di rete, ad esempio come unità S:, ricordarsi di specificare come dominio AS400: usare quindi il comando

net use s: \\nome_as400\mf /user:nome_as400\nome_user /persistent:yes

poi

net use \\as400 /savecred

NOTA AGGIUNTA IL GIORNO 11/7/2013
In un successivo articolo IBM si legge:

After the changes are saved, the user profiles passwords will need to be reset to allow the LANMAN Hash to be generated. Also note that a stop and restart of Windows will be required for some of the policies to take effect.

Quindi potrebbe essere necesario:

  • Resettare la password dell'utente Windows
  • Riavviare il server Windows

Problemi console AS400 (IBM i)

Ho già scritto su questo argomento, ma vorrei ricapitolare con maggiore chiarezza quanto è necessario fare in caso di mancato funzionamento della console oppure di impostazione errata della stessa (ad esempio spesso l’AS400 viene impostato con l’Operation Console di default anche quando la console è twinax).
In queste situazioni può essere necessario ricorrere alla funzione 65 + 21 + 11.
La funzione 65 + 21 + 11 è utilizzabile solo dal pannello.

1. Da pannello portare l’AS/400 in manuale (01 B M)
2. Selezionare la funzione 25 e invio
3. Selezionare la funzione 26 e invio
(Se il sistema risponde con 65 FF ripetere i passi 2 e 3)

Il pannello passa alla modalità avanzata.

La funzione 65 deve essere seguita entro 45 secondi da una funzione 21 e da una 11. Se passano 45 secondi, la funzione 21 forzerà il menù DST sulla console. A seconda dello stato dell’IPL, si potrebbero vedere dei cambiamenti sulla console se la console è ancora presente dopo la funzione 65.
Se le funzioni 65, 21 e 11 vengono richieste in meno di 45 secondi apparirà sul pannello un SRC: A6nn500A.
Ripetendo la funzione 65, 21 e 11 il sistema entra in modalità modifica in cui è possibile effettuare dei cambiamenti o eseguire delle operazioni. Dopo la seconda terna di 65, 21 e 11, sul pannello apparirà un altro SRC: A6nn500B per indicare il modo edit. A questo punto occorre ripetere la terna 65, 21 e 11 per incrementare “nn” all’interno dell’SRC . “nn” rappresenta quale operazione si intende eseguire.
A questo punto un singolo 21 indicherà la selezione della funzione.
L’SRC diventerà A6nn500C per indicare che la funzione è stata selezionata correttamente.
Se ogni volta che si effettua una funzione 65 e 21 si eccedono i 45 secondi o tra due 21 successivi, appare un SRC A6nn500D che indica il raggiungimento del time out e l’uscita dal modo edit. In questo caso per effettuare una modifica, occorre ripartire da capo.
L’uscita immediata dall’edit può essere effettuata con una funzione 66.
Ecco i codici di riferimenti (“nn”):

00 Nessuna console definita
01 Console twinax
02 Operation console diretta
03 Operation console di rete
04 Hardware management console
C3 Reimposta configurazione LAN
A3 Disattivazione e riattivazione della scheda di rete Operations Console

Utilizzando i codici C3 e A3 è possibile azzerare le impostazioni di rete dell’Operations Console

Cancellare la password del device Operations Console

Per cancellare la password dell’Operations Console, usare la procedura seguente.

1. Portare la console in modalità avanzata (vedi sopra)
2. 65 + invio. Il sistema dovrebbe rispondere con 65 00. Potrebbe essere necessario utilizzare la funzione 11 per mostrare i risultati (D1008065).
3. 13 + invio. Il sistema presenta due righe di valori numerici. La prima termina con una cifra che rappresenta il numero esecuzioni della funzione 65. Dovremo incrementare fino a 7 questo valor. La seconda riga 00000001 fino a quando non sono state eseguite le 7 funzioni 65, 00000000 al raggiungimento della settima iterazione.
4. Ripetere i passi 2 e 3 per 7 volte. Si hanno 5 minuti per concludere l’operazione.

Agile Day 2011

Anche quest'anno eccomi a stilare il mio personalissimo resoconto dell'Agile Day.
In primo luogo vorrei ringraziare gli organizzatori, che hanno svolto un lavoro perfetto. Se non ci siamo "accorti" di voi è perché tutto ha funzionato al meglio: bravi!
Ed ora mia una interpretazione delle sessioni a cui ho partecipato.

Back to basics: OOP and design

Il senso dell'intervento di Paolo Polce sta tutto nel titolo: dopo anni spesi a concentrarsi sul processo, abbiamo forse perso di vista i problemi tecnici, quasi fossero semplici dettagli implementativi. Scrum masters, sprints, story points, sì, vabbè, ma il codice? Beh, al codice ci penseranno le "risorse"... :-)
E' tempo di tornare a focalizzarsi sulle "risorse", ovvero sui programmatori, e sulle loro competenze, che devono costantemente essere allenate, come i muscoli di un atleta.
Come ottenere lo scopo? Con buone letture, buoni strumenti, ed un continuo esercizio volto a creare design realmente ad oggetti. Una buona architettura Object Oriented modularizza i problemi tramite gli oggetti, ed evita quindi classi "Star gate" (spesso incarnate da dei Singleton), che leggono attraverso una pioggia di getter le informazioni più disparate, collassando al loro interno l'intera logica applicativa. Occorre quindi evitare i getter, scrivendo sempre più metodi che restituiscono void. Ma come testare queste architetture? La chiave consiste nel passare da test sullo stato degli oggetti, a test che ne verificano le interazioni.

Codice legacy: usciamo dal pantano!

Bel workshop di Stefano Leli e Simone Casciaroli. I partecipanti sono stati invitati a fare refactoring su un piccolo progetto, che nella gerarchia Bird-Duck-Chicken mostra un caratteristico caso di violazione del Principio di sostituzione di Liskov, il complesso edipico irrisolto della programmazione ad oggetti.
La sessione, terminata con la presentazione della soluzione dei relatori, è stata interessante, anche se avrebbe richiesto sicuramente almeno un'altra ora per riuscire al meglio.

Lean, A3 e kaizen

Claudio Perrone nel suo intervento ha illustrato i i Kaizen Memo ed il medoto A3.
I Kaizen Memo sono piccoli fogli di carta da appendere su una parete per dare evidenza ai miglioramenti raggiunti nel processo produttivo. Dovrebbero riportare il problema affrontato, la misura intrapresa per risolverlo e le conseguenze ottenute.
Il metodo A3 prevede di utilizzare un modulo di carta, solitamente di dimensione appunto A3, sul quale presentare in modo oggettivo:

  • la situazione corrente;
  • l'obiettivo da raggiungere (ciò definisce il problema come differenza tra situazione corrente ed obiettivo da realizzare);
  • l'analisi delle cause del problema;
  • l'elenco delle contromisure da adottare;
  • una matrice what-who-where-how per realizzare le contromisure;
  • un elenco di azioni supplementari (follow-up) da intreprendere in caso di problemi.

L'intervento è proseguito definendo la figura del manager ideale, che non dovrebbe essere né un poliziotto che punisce chi si comporta male, né una mamma che coccola i suoi figli, e neppure una figura assente. Il vero manager dovrebbe invece essere una persona che si occupa di eliminare i problemi che ostacolano il processo produttivo. La domanda che un manager dovrebbe rivolgere ai suoi sottoposti non è "cosa hai prodotto ieri", ma "quali problemi hai avuto".
Claudio Perrone ha concluso dando una bella definizione dei metodi lean/agili: strumenti per fare soldi attraverso la crescita delle persone.

Back to basics hands-on

Antonio Carpentieri e Paolo Polce hanno condotto un efficace workshop sul design ad oggetti. Utilizzando come esempio il gioco del monopoli, hanno mostrato nella pratica come realizzare software ad oggetti senza abusare di getters e favorendo composizione, basso accoppiamento ed alta coesione.
Molto importante la sottolineatura finale di Antonio Carpentieri che ha ripreso il keynote di Paolo Polce: un programmatore non può crescere lavorando solo su codice di produzione. Come un atleta non migliora solo con le partite, ma soprattutto con gli allenamenti, anche chi sviluppa software non può non allenarsi praticando i kata.

Unit Tests VS End to End Tests

Probabilmente il mio giudizio su questo intervento è falsato dalla fatica accumulata alla fine di una giornata così intensa, ma dalla presentazione di Domenico Musto non sono riuscito a trarre nessuna informazione interessante. Chiedo venia.

Conclusioni

Anche questa edizione dell'Agile Day è stata all'altezza delle aspettative. Mi è piaciuta molto l'enfasi sul codice, dopo troppo tempo speso sui problemi di processo. Grazie ancora agli organizzatori ed arrivederci al 2013!

Porte IBM Client Access per AS400

Uso questo post come promemoria per l'elenco delle porte usate da IBM Client Access, conosciuto anche come IBM i Access.
Ricapitolando, le porte indispensabili per l'emulazione video sono

  • Server Mapper - 449
  • License Management - 8470
  • Signon Verification - 8476
  • Telnet - 23

Per ODBC/JDBC

  • Server Mapper - 449
  • Signon Verification - 8476
  • Database - 8471

Ecco l'elenco completo delle porte

Funzione Nome server Non-SSL SSL
Mappa porte servizi as-svrmap 449 449
Gestore licenze as-central 8470 9470
Database as-database 8471 9471
Code dati as-dtaq 8472 9472
Accesso ai File as-file 8473 9473
Stampa di rete as-netprt 8474 9474
Comando remoto as-rmtcmd 8475 9475
Verifica collegamento as-signon 8476 9476
Telnet (emulazione 5250) telnet 23 992
Amministrazione HTTP as-admi 2001 2010
Management Central as-mgtc 5555 and 5544 5566
DRDA DRDA 446 ---
DDM DDM 447 448
NetServer netbios 137 ---
NetServer CIFS 445 ---
NetServer netbios 139 ---
Service Tools Server as-sts 3000 ---
RUNRMTCMD REXEC 512 ---

L’apostata del TDD

Ho seguito con molto interesse la discusione generata da un post che vuole essere iconoclasta già nel titolo: l'apostata del TDD. Vorrei sottoporvi le mie annotazioni.

Perché il post mi pare interessante

Perché il post mi pare interessante? Perché tocca le corde della mia esperienza personale: anche io, come l'autore, ho provato curiosità nel notare di aver sviluppato a volte del buon codice senza l'uso del TDD e del pessimo codice con il TDD. Posto che è plausibile che problema risieda in me e non nel metodo, mi pare lecito comunque chiedersi se anche il metodo stesso non abbia qualche pecca. Provo infatti un certo fastidio quando, durante l'analisi di fallimenti del TDD (e mi pare che comunque ve ne siano), si escluda dogmaticamente che lo strumento possa avere qualche difetto. Tutto questo mi ricorda le critiche che (inutilmente) qualcuno negli anni 70 muoveva a psicanalisi e marxismo: ci si chiedeva infatti se fosse possibile che queste dottrine fossero di per sè corrette, mentre ogni loro clamorosa debacle si dovesse addebitare sempre ad una loro incorretta realizzazione, pienamente giustificabile ed interpretabile all'interno delle dottrine stesse.

Cosa non funziona nel TDD?

Ma allora cosa ci sarebbe di sbagliato nel TDD? Non so se vi sia qualcosa di "sbagliato", sicuramente indagherei su questi punti.

La visione d'insieme

Riprendendo quanto detto da Carlo Bottiglieri sulla lista extremeprogramming-it, il TDD potrebbe far perdere la visione d'insieme del problema, o anche problematiche trasversali all'intero sistema.

Cicli troppo stretti

Il TDD si basa sul "mantra" "red-green-refactor", che però, nella sua definizione, prevede di essere un ciclo di breve durata, per consentire un riscontro immediato. Ciò a mio avviso implica che la fase di refactor non possa spostare di molto l'"inerzia" del sistema: ciclo breve, refactoring breve, quindi spesso indirizzato a piccoli obiettivi. Il refactoring, inoltre, nascendo come "cura" per le puzze del codice, a risulta uno strumento di ottimizzazione locale: diminuisco la lunghezza dei metodi ed il numero di parametri, creo classi disaccoppiate, ottimizzo gli indicatori "locali" di qualità, ma la struttura generale è comprensibile e riutilizzabile?

Coesione vs accoppiamento

Durante un suo corso, Francesco Cirillo mi ha fatto riflettere su questo concetto: del buon codice deve essere ad alta coesione e a basso accoppiamento, ma vi è una tensione tra i due aspetti. Il mio dubbio è: il TDD tende a sistemi a basso accoppiamento, ma forse anche a bassa coesione?

No Big Upfront Design?

Il TDD ha viaggiato a braccetto con il concetto di "No Big Upfront Design", anche nella sua variante "non facciamo design prima di scrivere il codice, ma solo scrivendolo". Ma siamo proprio sicuri che il codice sia il l'unco luogo, o comunque quello ideale, dove disegnare il codice stesso?

Il lato oscuro dei test

Non dobbiamo dimenticare quello che Matteo Vaccari chiama "il lato oscuro dei test": paradossalmente un sistema copero al 100% da test potrebbe invitarci a scrivere codice "peggiore", in quanto, qualsiasi schifezza volessimo introdurre, avremmo sempre la certezza di non rompere nulla.

Sono anch'io un apostata?

Non so se dirmi apostata anch'io: forse non posso, non essendo mai stato un fedele praticante. ;-)
Sicuramente diffido di chi ha fatto del TDD una religione, o meglio un feticcio.
Forse, riprendendo la bella analogia di Jacopo Romei, sono nella fase "Ha – Vìola la regola" del ciclo "Shu-Ha-Ri": sto cercando di mettermi in opposizione al TDD, al fine di capirlo meglio.
Certamente vorrei saper usare il TDD come Carlo, ma a volte mi chiedo se questo non sia un tipo di programmazione che solo dei grandi virtuosi sono in grado di svolgere.
O forse sto ancora ricercando la mia via e sono ancora molto lontano anche dalla fase "Shu"...

Italian Agile Day 2010

Anche l'Italian Agile Day del 2010 è stato un bellissimo evento, e vorrei darne qui il mio personalissimo resoconto.

Keynote

Paolo Perrotta ha condotto con brio ed intelligenza un bellissimo escursus su come, nel corso del tempo, sia stato affrontato il problema di ridurre i fallimenti nei progetti software.
Un primo tentativo si è basato su un mito: i progetti falliscono perché gli strumenti di programmazione sono troppo complessi, tant'è che richiedono degli specialisti come i programmatori per essere realizzati. Se solo potessimo eliminare i programmatori...:-) Si cerca così soppressione dei programmatori tramite strategie che si chiamano di volta in volta SOA, UML, CASE; persino il Cobol è nato per scrivere programmi senza avere programmatori! Tutti questi tentativi si sono però scontrati contro un medesimo scoglio: scrivere algoritmi che vengano eseguiti è qualcosa di intrinsecamente complesso.
Si è anche pensato di controllare il fallimento eliminando la componente di errore umano. Nascono quindi i metodi formali di verifica di correttezza del software, che comunque non sembrano aver avuto molto successo.
Si è quindi pensato di eliminare la variabilità dei progetti irregimentando lo sviluppo all'interno di procedure ben determinate. Ecco allora nascere metodi di lavoro come il Waterfall, che conteneva alle sue origini idee apprezzabili come la valorizzazione delle persone e l'enfasi sul test anche automatizzato del codice. Waterfall, come molte altro processi di sviluppo, si sono nel tempo "distorti" nel loro divenire strumenti di successo. Anche "Agile" subirà la stessa fine? Forse sì, ma sicuramente lascerà qualcosa di buono alle sue spalle. Il seme "Agile" consiste nell'idea non eliminare, ma di accettare la variabilità dei progetti, scomponendoli in piccole parti, ognuna delle quali attraversa tre fasi (il corsivo indica mie ipotesi)

  1. Osservazioni (user stories)
  2. Ipotesi (codice)
  3. Verifica sperimentale (test)

Questo è il cuore dei "Metodi agili", che è destinato a rimanere perché non è altro che il cuore del metodo scientifico.

Affiliamo i nostri strumenti: un test driver fatto in casa

In questa interessante sessione Jacopo Franzoi ha illustrato la sua esperienza nell'introdurre in un progetto reale i test unitari anche in quel regno dimenticato costituito dalle interfacce web.
Jacopo è infatti riuscito a creare una mini libreria per testare le pagine generate tramite FreeMarker.
Il messaggio è stato chiaro: anche in ambienti apparentemente ostili, come lo sviluppo di pagine web, è possibile crearsi strumenti che consentano di testare le nostre applicazioni. La sovrabbondanza di dettagli implementativi, che probabilmente sono sfuggiti a chi non ha mai utilizzato il particolare strumento di template in esame, è forse stato l'unico piccolo neo nella presentazione.

Code Kata Live

Una brillante presentazione di Gabriele Lana sui code Kata ha introdotto la perfomance di Giordano Scalzo e Tonino Lucca.
Tesi centrale dell'esposizione di Gabriele: il talento non è (solo) innato, bensì sgorga da un esercizio costante. Perché l'esercizio giunga a dei risultati occorre che:

  1. sia sfidante: ogni prova deve essere leggermente più difficile delle precedenti, senza però essere frustrante;
  2. sia ripetuto;
  3. abbia un riscontro da parte di altri, sia da persone più esperte, che sappiano dare suggerimenti, sia da persone meno esperte, che possano dare opinioni non convenzionali.

Ripetere incessantemente buoni esempi ci consente di passare dal codice "quick and dirty" al codice "quick and clean". Quando le nostre abilità sono limitate, il codice "dirty" ci risulta "quick" perché non sappiamo fare altro. Al crescere delle nostre competenze invece, il codice "clean" ci dovrebbe risultare più "quick", cioè più veloce e naturale da scrivere di quello "dirty".

Guelfi versus Ghibellini


"Noi tutti dobbiamo essere animati da un grande desiderio di competere fra noi per sapere cosa sia il vero e cosa il falso sull'argomento che stiamo trattando; è infatti comune interesse che ci sia chiarezza su questo punto.
Mi accingo ad esporre il mio pensiero; se a qualcuno di voi sembra che io ammetta cose non vere, costui dovrà interrompermi e confutarmi. Del resto io non dico le cose che dico forte di una verità di cui sono sicuro, ma ricerco assieme a voi; pertanto, qualora il mio oppositore mi paia avere ragione, sarò io il primo a riconoscermi d'accordo con lui."

Questo passo del Gorgia di Platone è perfetto per descrivere il messaggio che Sergio Berisso, coaudiuvato da Tonino Lucca, ha voluto indicare nella sua presentazione interattiva. Occorre affrontare le retrospettive, ed in genere tutti i momenti di riflessione e confronto dei gruppi di sviluppo, con questo spirito costruttivo, cercando di trovare i punti di sintesi comuni tra visioni discordanti.

Open space sul Kata "Sasso-forbici-carta" svolto secondo le regole "Aperto-Chiuso"

In un angolino molto defilato, io e l'amico Marco Testa dell'XP User Group di Bergamo abbiamo provato a rifare il Kata "Sasso-forbici-carta" seguendo le regole "Aperto-chiuso" suggerite da Matteo Vaccari. Il pubblico non era certo numeroso...ehm...ehm...vabbe', se vi interessa qui sono le slides e questo è il codice.

TDD per le viste

Questa è stata sicuramente la presentazione più interessante fra quelle da me seguite nella giornata: valeva la pena di partecipare all'Agile Day solo per sentire Matteo Vaccari e Carlo Bottiglieri tenere questa lectio magistralis sul TDD.
TDD spinto sino alle estreme conseguenze: Matteo ha infatti mostrato come gestire con questa tecnica anche la produzione di interfacce HTML, mentre Carlo ha dato un esempio di come costruire partendo dalle fondamenta dei test ogni singolo aspetto dell'architettura di un'applicazione, inclusa l'interfaccia Javascript e l'ambiente di esecuzione dell'application server. Geniale l'idea di Carlo di simulare in un test l'occhio dell'utente che guarda la videata! Non so se questa visione radicale del TDD sia realmente applicabile da noi comuni mortali, ma sono certo che il suo fascino mi rimarrà impresso a lungo.
Ecco il link alle slides di Matteo, mentre rimango in attesa spasmodica di quelle di Carlo.

Conclusioni

Ancora una volta l'Italian Agile Day si è dimostrato un evento eccezionale: complimenti agli organizzatori e arrivederci alla prossima edizione! (A Roma? Io, voto per un Genova-bis! Ma a Milano proprio no???)

P.S. Ricevo da Carlo il link alle sue slides. Ragazzi, non perdetevele!!!

Esportare le definizione delle stampanti su un altro AS400

Per copiare la definizione delle stampanti (o in generale di device) da un AS400 ad un altro è possibile seguire il procedimento seguente.

Sull'AS400 di partenza digitare

SAVCFG TAP01

dove TAP01 è l'identificativo dell'unità nastro da utilizzare (è possibile far ricorso anche ad un save file)

Sull'AS400 di destinazione, dopo aver inserito il nastro su cui la configurazione di partenza è stata memorizzata, digitare

RSTCFG OBJ(NOME_STAMPANTE)  DEV(TAP01)  OBJTYPE(*DEVD)  SRM(*NONE)

Si noti che NOME_STAMPANTE può essere generico: ad esempio PRT* indica tutte le stampanti il cui nome inizia per PRT.

ATTENZIONE: È MOLTO IMPORTANTE INDICARE IL PARAMETRO SRM(*NONE), altrimenti la configurazione ripristinata potrebbe essere inutilizzabile.

In alcuni casi i device potrebbero non essere ripristinati perché il nome dell’unità di controllo è differente tra i due sistemi. In questo caso occorre quindi ripristinare anche l’unità di controllo con il comando:

RSTCFG OBJ(NOME_UNITA_CONTROLLO)  DEV(TAP01)  OBJTYPE(*CTLD)  SRM(*NONE)

Spegnere la luce di attenzione arancione dal Service Action Log di AS400

- Collegarsi con l'utente QSECOFR di sistema operativo.

- Digitare dalla riga comandi STRSST

- Inserire l'utente e password di manutenzione DST richiesti

Type choice, press Enter.  

Service tools user ID. . . . . QSECOFR
Service tools password . . . xxxxxxx (case sensitive)

- Selezionare Start a service tool / Avvio di un programma di manutenzione
(opz.1)

- Selezionare Hardware Service manager / Programma di manutenzione hardware
(opz.7)

- Selezionare Work with service action log / Gestione delle registrazioni
delle azioni di assistenza (opz.6)

- Dare la data di inizio ricerca errori più vecchia possibile (installazione del sistema ) fino alla data attuale, quindi invio.....

- Verificare gli errori che appaiono sul sito INFOCENTER

- Spegnere la luce di attenzione facendo l'acknowledge dei problemi
F6=Acknowledge All Errors / Ricezione di tutti gli errori

- Rimuovere tutti gli errori presenti , uno alla volta, utilizzando l'opzione 8 di Close (Chiusura) e poi 9 di Delete (Cancellazione).
Se non ci sono errori nella pagina ma è presente la funzione F6 fare comunque l'acknowledge per spegnere la luce.
Verrà richiesto un F10 di conferma

- Una volta eseguito l'Acknowledge(Ricezione) appare sul fondo della videata la scritta: All errors have been acknowledged / Tutti gli errori sono stati ricevuti (a questo punto la luce si dovrebbe essere spenta)