Premessa
Le SAN sono ormai diventate un oggetto di larga diffusione presso tutti i CED: sotto le mie (in)capaci spalle ricade la gestione di apparati sia midrange (DS6000) che enterprise  (DS8100) di IBM (oltre a diverse entry level sparse a giro).
Naturalmente ogni produttore ha i propri tool di gestione e ovviamente IBM ha le proprie console, sia grafiche che a riga di comando (denominate DSCLI): ovviamente da GUI si puo' fare di tutto ma, com'è facilmente intuibile, alcune "finezze" sono disponibili solo dalla riga comandi (ogni buon amministratore predilige la riga comandi per le configurazioni!)

Problema
Nel mondo delle SAN IBM (ma presumo anche con altri produttori) vale la regola che il client di amministrazione deve avere la stessa versione (o versione superiore) del firmware/microcode installato sulla SAN: personalmente preferisco usare la DSCLI dello stesso "bundle" del firmware che ho sulla macchina.

Se avete una sola SAN il problema ovviamente non si pone: ma se avete più macchine con livelli di firmware diversi (e magari su alcune non potete fare nemmeno gli aggiornamenti dato che questi sono gestiti a insindacabile giudizio dal produttore), si presenta la necessità di installare, sulla propria postazione di amministrazione, versioni diverse della DSCLI. Qualcuno potrebbe comunque obiettare che da qualche parte esiste una macchina con lo Storage Center installato e che si potrebbe usare quella per gestire gli storage: questo però non è vero per i DS8000 che questa console ce l'hanno (HMC) ma è praticamente a solo ed esclusivo uso diagnostico.

Se si prova a fare due installazioni, ben presto si scopre che la seconda "sovrascrive" la prima anche se si utilizzano directory diverse: in pratica, supponendo di avere installata la versione 5.2 per un tipo di storage, quando installate la versione 5.3 per un altro storage, quest'ultima sembra "sovrascrivere" quella vecchia anche se, come già detto, l'installazione viene fatta in directory diverse.

Analisi e soluzione
Se avete notato, il termine "sovrascrivere" l'ho sempre messo tra virgolette per evidenziare che non si tratta di una vera sovrascrittura: infatti sul disco sono presenti entrambe le versioni (e ciascuna con i propri .jar, trattandosi di una applicazione JAVA) ma la versione che viene visualizzata è sempre una ed una sola, indipendentemente dall'eseguibile che viene avviato.


Ho quindi spulciato i vari files di configurazione (ed in particolare il CLI.CFG dentro la directory LIB) trovando però che i path dichiarati erano assolutamente corretti. Ad un certo punto però mi sono ricordato che alcune applicazioni JAVA usano anche delle variabili ambiente: e spulcando proprio le variabili di ambiente ho trovato un bel:

DSCLI_INSTALL=C:\programmi\ibm\DSxxxx\dscli

Ecco quindi spiegato il perchè di quello strano comportamento: dato che a ogni installazione la variabile di ambiente viene aggiornata, essa riporta sempre "l'ultima" versione installata e di conseguenza, anche invocando l'eseguibile "giusto", vengono caricate le librerie JAVA della versione indicata dalla variabile d'ambiente (non oso immaginare con quali conseguenze in caso di uso prolungato!)

La soluzione a questo punto è semplice: basta avviare la DSCLI tramite un batch che, come prima azione, imposta il valore adeguato per la variabile DSCLI_INSTALL.

Se qualcuno trova una qualche pagina nello sterminato sito IBM che riporta una nota sulla "convivenza" di versioni diverse mi fa un piacere....wink smile