Franco Lombardo

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.

Sono già passati 20 anni dalla strage di piazza Tiananmen, ma sembra che siano 1000.
Chi potrebbe infatti ricordare eventi così spiacevoli, che potrebbero turbare i rapporti con uno dei nostri interlocutori commerciali più importanti, specialmente ora, in tempo di crisi?
Pecunia non olet, nemmeno di sangue...

Ieri, 29 maggio 2009, ho tenuto una breve presentazione sul linguaggio Scala alla riunione dell'XP User Group di Bergamo. Parlare con delle persone brillanti come gli amici dell'XP-UG-BG è stato veramente una bella esperienza. L'unico mio rammarico è quello di non essere stato in grado di creare una presentazione sufficientemente chiara. Come sempre, la cosa più complessa è essere semplici! Il principio KISS è il più difficile da seguire. Spero comunque di poter fare meglio la prossima volta.

E' stata una coincidenza fortunata. Nei giorni scorsi stavo scrivendo del codice, per la prima volta da tempo del codice altamente algoritmico. Da bravo scolaretto XP, avevo creato una serie completa di test, avevo rifattorizzato estraendo metodi, rinominando variabili, abbassando il numero ciclomatico. Le classi erano piccole, i metodi corti, eppure il codice, pur funzionando egregiamente, in qualche modo mi infastidiva.
Poi alla scorsa riunione dell'XP-UG di Milano, Matteo Vaccari ha parlato brevissimamente dell'argomento, ed è stato illuminante. Da qui il suo interessante post.
In particolare una frase pesa come un macigno su quanti, come me, pensano di essere agili solo perché fanno TDD (o qualche altra pratica XP):
"TDD could be a crouch that allows you to give up finding a good design and settle for a mediocre one".
Puoi fare tutto quello che dice il libro bianco di Kent Beck, ma forse non ti accorgi che c'è una tessera mancante....

Nei sistemi Unix esiste il comando su che permette, avendone la password, di impersonare il "superutente" root.
Anche su AS400 ciò è possibile, anzi, se si possiede l'autorizzazione *USE sul profilo utente desiderato, si può far girare il proprio lavoro sotto mentite spoglie.

Ecco un semplice CL che a tale scopo usa le API di sistema QSYGETPH e QWTSETP.

             PGM        PARM(&UTENTE)

             DCL        VAR(&UTENTE) TYPE(*CHAR) LEN(10)
             DCL        VAR(&USCITA) TYPE(*CHAR) LEN(50)
             DCL        VAR(&TESTOERROR) TYPE(*CHAR) LEN(100)
             DCL        VAR(&HUSER) TYPE(*CHAR) LEN(12)

             MONMSG     MSGID(CPF0000) EXEC(GOTO CMDLBL(ERRORE))
/*------------------------------------------------------------------*/
/* RECUPERO L'HANDLE DEL PROFILO UTENTE                             */
             CALL       PGM(QSYS/QSYGETPH) PARM(&UTENTE *NOPWDCHK +
                          &HUSER)
/* PASSO AL NUOVO PROFILO UTENTE                                   */
             CALL       PGM(QSYS/QWTSETP) PARM(&HUSER)
/* INVIO UN MESSAGGIO DI COMPLETAMENTO OPERAZIONE                  */
             SNDPGMMSG  MSG('Profilo utente cambiato')
/*------------------------------------------------------------------*/
/* FINE                                                             */
/*                                                                  */
             GOTO       CMDLBL(FINE)

/* GESTIONE ERRORI                                                  */
  ERRORE:     RCVMSG     MSGTYPE(*EXCP) MSG(&TESTOERROR)
              SNDPGMMSG  MSG(&TESTOERROR)
/*                                                                  */
FINE:
     ENDPGM

I vantaggi dei test unitari sono ben noti a tutti: miglioramento del design, documentazione del codice, aumento della qualità tramite la diminuzione dei bachi e la possibilità di ristrutturare il codice in modo sicuro. Quello che gli agilisti (a volte) non dicono è che i test unitari, pur portando tutti questi benefici, rappresentano anche un costo nel processo di sviluppo. Un primo costo è banalmente rappresentato dal tempo necessario per il loro sviluppo, ma questo non è l'aspetto principale del problema. L'onere principale dei test, forse più difficile da cogliere, ci è indicato proprio dalle metodologie agili: tutto il codice prodotto comporta un costo di manutenzione, anche lo stesso codice di test.
Occorre quindi saper capire quando il prezzo dei test sia ripagato dai benefici e quando no. La mia opinione è che la creazione di test approfonditi per le interfacce grafiche non è quasi mai "economicamente" conveniente. Riprendo qui alcuni esempi che ho portato in una discussione nata con Matteo Vaccari sulla lista dell'XP User group di Bergamo.

Qualche anno fa, penso fosse il 2003, assistetti ad una presentazione al Webbit nella quale Bruno Bossola mostrò come fosse possibile applicare il TDD alla realizzazione di interfacce Swing, andando a testare lo stato dei vari "model" dei componenti. Tornai a casa entusiasta e provai a mettere in pratica la lezione: fu un disastro! Questo per due motivi. In primo luogo non sono un programmatore valido come Bossola (e allora ero ancora molto meno esperto). Secondariamente lo sforzo per cercare di domare le idiosincrasie di Swing non portava alcun vantaggio. I problemi della GUI sono al 90% del tipo: "Se visualizzo la mia maschera a 800x600 anziché a 1024x768 i bottoni scompaiono", oppure "Se passo a 1280x1024 il carattere è così piccolo che non si legge una fava". Certo, il debugging di questi aspetti si può fare anche con il TDD, ma penso che il debugging umano sia insostituibile, più efficace e molto meno costoso.

Secondo esempio. All'XP UG di Milano tentammo di sviluppare l'UG-Aggregator, una mini applicazione web per inserire e visualizzare gli eventi dei vari XP-UG. Questa applicazione non aveva alcun tipo di logica significativa, ma noi, essendo agilisti DOC, dovevamo scrivere i test! Ci venne quindi l'idea di testare la struttura dell'HTML prodotto, per vedere che ci fossero determinati tag con attributi che dovevano identificarne il contenuto. Il risultato fu circa il seguente, correggimi se sbaglio: tempo per scrivere il codice 1, tempo per scrivere il test 2, tempo per debuggare il test (e non il codice) che non funzionava 4. (OK ho un po' esagerato, ma penso che la mia ricostruzione non sia troppo lontana dalla realtà). Questo a mio avviso è un esempio di programma senza logica per cui il TDD può non essere efficace. Inoltre in questa situazione modificammo non solo la struttura interna dell'applicazione per renderla più testabile, ma anche il suo comportamento. Questa ritengo sia una "puzza" del processo di test!

In questo senso mi ha confortato l'esempio di TDD presentato nell'ultima riunione dell'XP User Group di Bergamo da Alessandro melchiori e Emanuele DelBono. Partendo dai test è stata abbozzata una banale applicazione Windows secondo il paradigma Model - View - Presenter. Ebbene, tutto il codice risultava coperto da test, ad eccezione della parte di view!
(Un unico neo nella presentazione dei due amici bresciani: tutto in C#!!!)

1. Scaricare ed installare
   Pstools
2. Avviare psexec \\nome_o_ip > /u dominio\utente cmd
3. Da una installazione già esistente di VNC 4, copiare il file winvnc4.exe in una cartella del PC di destinazione (ad esempio c:\programmi\vnc).
4. Sempre da una installazione già esistente di VNC 4, dopo aver configurato l'istanza server con la password desiderata, esportare la chiave di registro HKEY_LOCAL_MACHINE\SOFTWARE\RealVNC in un file vnc.reg. Copiare quindi tale file sulla macchina di destinazione
5. Nel propmt remoto sulla macchina di destinazione digitare
   regedit /c /s "percorso\vnc.reg"
6. Dal propmt remoto sulla macchina di destinazione avviare winvnc4.exe -register
7. Dal propmt remoto sulla macchina di destinazione avviare winvnc4.exe -start

Quando un PC con sistema operativo Windows non riesce a partire, sarebbe utile avere un CD, dal quale effettuare il boot, che contenesse qualche strumento di diagnostica. Ecco come crearne uno contenente Spybot.
Continue reading ‘Come creare un boot CD contenente Spybot’ »

Nel ripristinare un database su una diversa macchina Windows con IBM DB2 ho avuto i seguenti problemi. Riporto qui le soluzioni come promemoria.
Continue reading ‘Problemi nel restore di un database in DB2 su Windows’ »