Molte aziende che usano IBM i (AS400) hanno creato le proprie applicazioni 30 o più anni fa, quando spazio disco, RAM, processori costavano 1000 volte più di oggi.

• CODICE CLIENTE (CODCLI)

• CODICE PRODOTTO (CDPAR)

hanno un massimo di cinque o sei caratteri.

Questa configurazione potrebbe funzionare per molto tempo, ma tuttavia,  può presto diventare un problema, se l'azienda ha successo, cresce effettua fusioni, acquisizioni, incorporazioni.

Nessuno aveva pensato a questo tipo di situazione quando ha progettato il sistema originale .

• i CAMPI VALUTA

un problema che spesso deriva dall'internazionalizzazione.

Ad esempio, un'azienda desidera fare affari in Messico utilizzando pesos e deve considerare quanti pesos sono necessari per un dollaro.

La Conversione di Dollari in Pesos significa che poche migliaia di dollari per un articolo si trasforma in milioni di pesos.

Quando si esegue il riepilogo per i dettagli della fattura, è possibile che il campo per l'importo totale sia insufficiente.

La crescita regolare dell'azienda può causare lo stesso tipo di problema, dal momento che molte aziende non solo crescono per acquisizione, ma possono crescere perché stanno andando molto bene negli affari.

• I CAMPI UBICAZIONE (nuovo ufficio, negozi, ecc.).

Se un'azienda sta andando davvero bene, potrebbe aumentare da poche posizioni a molte, a volte migliaia.

A quel punto, potrebbero aver consumato quasi interamente il campo ubicazione  limitato a due caratteri.

Questi sono i motivi principali per cui le aziende avviano un progetto di ridimensionamento del campo.

Quali sono alcune delle sfide più comuni del ridimensionamento del campo?

Se avessimo un'applicazione scritta perfettamente, molti di questi progetti sarebbero semplici: si cambia il database si ricompilano i programmi... e il gioco è fatto!

La difficoltà è che molte cose sono duplicate, altrimenti la definizione non si trova necessariamente in una particolare fonte e può essere diffusa intorno alla loro applicazione.

Naturalmente, quando si cambia una tabella si verifica un effetto domino:

quel campo avrà un impatto su molte cose nei programmi, perché questi programmi hanno campi di lavoro associati che sono stati ridefiniti.

Questi campi di lavoro si associano ad altre variabili e campi e molte volte un programma chiama un altro programma passando come parametro uno o più di questi campi o variabili.

Qualcuno cerca di capire eseguendo la scansione del codice sorgente, se non hai un tool come X-Analysis.

E' difficile trovare dove si trova un campo particolare in una tabella, che è il punto di partenza di un progetto di espansione del campo.

L'assenza di una convenzione di denominazione dei file e dei parametri può rendere difficile trovare dove vengono utilizzati nell'applicazione, e questo è un motivo per cui le cose vengono perse se non si utilizzano gli strumenti giusti.

Tutti questi fattori rendono i progetti più complessi di quanto dovrebbero essere, e la parte triste è che molti dei nostri clienti sperimentano una o più di queste situazioni.
Questi progetti possono essere enormi e rischiosi, dal momento che toccano molte cose.

Molte organizzazioni impiegano anche due o tre anni per realizzare un progetto di ridimensionamento sul campo.

Quali sono i diversi approcci e strategie che le aziende possono adottare e in che modo X-Analysis  può svolgere un ruolo? In che modo vengono assegnate le priorità agli sforzi di ridimensionamento?
Molti dei nostri clienti hanno uno o più campi che impediscono loro di rilasciare un nuovo prodotto, che è sempre la massima priorità.

Ci sono anche altri campi che possono essere fastidiosi e hanno escogitato modi per aggirare il problema del dimensionamento.

Ad esempio, quando si tratta di codice cliente, molte volte hanno riciclato i codici.

Quali sono i problemi con questo?

Bene, il problema è che potresti aver associata una lunga vecchia storia ad  un cliente nuovo di zecca, a causa del fatto che stai riciclando un codice cliente.

Potresti mostrare la storia di un cliente che è stato inattivo per cinque anni, il che ti ha permesso di decidere di riciclare il suo numero, per poi mettere un nuovo cliente nel guscio di quello vecchio.

E' un trucco che le persone usavano in passato...

Perché le aziende stanno valutando un approccio automatizzato rispetto all'approccio tipico odierno a un progetto di ridimensionamento del campo?
La prima cosa è che, in ognuno di questi progetti di ridimensionamento del campo, una delle questioni più importanti è l'ambito. Come definisci l'ambito del tuo progetto?

1. Il primo passo che devi compiere è stabilire le tabelle in cui vengono utilizzati i campi da espandere.

2. Dopo averlo fatto, è necessario fare riferimento a tutti i programmi, gli oggetti e persino le query in cui vengono utilizzate queste tabelle.

In alcuni casi, questo sarà semplice, se sei abbastanza fortunato da avere ancora i programmatori che hanno creato l'applicazione.

Il loro contributo sarà molto prezioso poiché si tratta di conoscenza.

La realtà è che spesso non abbiamo quel tipo di lusso.

Spesso l'attuale staff ha lavorato con l'applicazione IBM i per pochissimo tempo.

L'esperienza che il personale ha in azienda sarà un fattore molto importante che determinerà quanto tempo sarà necessario anche per identificare quali tabelle sono interessate.

Lascia che ti fornisca un esempio del progetto di ridimensionamento del campo del database di un cliente:

ha stimato che il solo sforzo di identificare l'inventario di tutto ciò che sarà nell'ambito richiederebbe circa otto mesi.

Pensa: ci vorrebbero otto mesi prima che le persone trovassero le tabelle, i programmi, le query, ecc., nell'inventario in modo che l'ambito possa essere definito.

Con X-Analysis ed X-Resize siamo stati in grado di farlo in pochi giorni, non mesi.

Un approccio automatizzato ti aiuta con la coerenza delle modifiche

Un altro problema è che ci sono parti di codice che sono duplicate nell'intera applicazione IBM i, che forse possono essere trovate molte centinaia di volte.

Quindi anche un piccolo errore a un certo punto diventerà incoerente con il resto delle correzioni.

Queste incoerenze si traducono molte volte nell'aggiunta di nuovi bug nell'applicazione, portando all'argomento della mitigazione del rischio.

La coerenza dello strumento di ridimensionamento automatico del campo riduce il rischio, l'impatto di tale errore umano, che può essere piuttosto difficile da gestire.

Una delle ultime parti del progetto sarà il test e cosa succede quando il progetto tocca l'intera applicazione?

Un'azienda dovrebbe eseguire test integrati, ma con quale frequenza lo fanno effettivamente?

Potrebbero non avere gli strumenti o l'esperienza. Il progetto è stato probabilmente rischioso all'inizio e, se ci sono stati vincoli di tempo ad esso correlati, il test finale è allettante per essere tagliato. Questa non è una decisione saggia.

Una delle cose che amo di X-Resize  è che ci permette di iniziare i test il prima possibile, invece di aspettare che tutti abbiano finito. Questa funzione è ottima perché puoi ricontrollare le cose che normalmente troverai solo quando è troppo tardi nel tuo progetto.

Quando eseguiamo un progetto, includiamo il test dei dati come parte del pacchetto del progetto.

I principali vantaggi del nostro approccio al ridimensionamento dei campi con X-Analysis sono:

• Tempi più brevi per completare il progetto

• Migliore copertura

• Meno rischio

• Meno persone richieste

• Meno errori umani e manuali

• Test facilitati