Mi sembra di sognare!

Liberamente tratto da una mail del Poeta, altre ne seguiranno in futuro.
Vostro
Sir Gawain



Esimi Colleghi,
>
> Con l'inserimento della Patch 19 sul sistema Imss di FW,
>
> Sono stati introdotti due utili comandi per effettuare le attivita di
> controllo e manutenzione sugli impianti.
>
> Con il primo GRPST e possibile effettuale una interrogazione sistetica
> dello stato globale e delle sisngole porte riferito ad un determinato
> fascio CCS.
> In realtà sullo stesso, esiste la posssibilità di effettuare l'analisi
> ache su gruppi GNR e PBX. Direi però che su queste tipologie, le
> risposte del comando lascino ancora qualche dubbio ( ritengo che le
> risposte non siano per pbx e gnr sempre e completamente attendibili)
>
> Il secondo INTAUD effettua un controllo di congruenza tra le rarie
> tabelle del DB coinvolte nella prestazione di INDB a bordo di OMS.
>
> Se lanciato ad esemio settimanalmente e prima di effettuare eventoali
> interventi di analisi o correzione sulle stesse, rappresenti un
> ottivo strumento di analisi e monitoraggio simultaneo.
>
> Alla risposta del comando troverete sempre una incongruenza tra il
> numero di record effettuvamente allocati nel DB e la disponibilità
> degli stessi ( tabella di OMS dei bits di allocazione/disponibilità record ).
> Questa segnalazione sia pur veriiera non e preoccupante.

Dubbio

Perchè il correttore automatico di Word mi corregge Acme Packet in Acne Racket?

Exegi Monumentum Aere Perennium...

Sintesi e commento (sintetico anch’esso) della migrazione avvenuta in BBN*nella notte tra 13 e 14 Dicembre.

Premessa per chi volesse saltare il resto: esito positivo. Provisioning effettuato correttamente via massivo, nessun problema legato agli utenti da noi migrati sino ad ora (9,00 am).

Nel pomeriggio del 13 era stato effettuato il preprovisioning. I batch hanno girato senza significativi problemi, configurando la v52, gli utenti (POTS ed ISDN) e le porte. La migrazione vera e propria è cominciata a mezzanotte. Girati i flussi sulla erigenda v52 si è avuto un problema imprevisto: i bs non sono risaliti automaticamente. Studiando il problema con i colleghi di BBN*, e rilevando uno stato anomalo nelle porte dei flussi (che rimanevano INDISP), si è provato a far transire i 2M in off e poi in onl. Questo in effetti ha permesso ai bs di andare online, ma non è stato sufficiente: lo stato anomalo delle porte dei bearer è stato risolto tramite un kil-dea-act delle porte. A questo punto la v52 non ha più opposto resistenza, tutti i blocchi di sicurezza si sono stabilizzati su online e lo stato delle porte è passato ad IDLE. Queste manovre, fra indecisioni iniziali nostre e tattiche temporeggiatrici dei clienti, hanno preso poco più di un ora e mezza.

A questo punto è stato possibile dare inizio all’effettivo provisioning massivo: la procedura è stata effettuata in non più di venticinque minuti (rimozione delle entry + creazione delle nuove coppie DN-RN). Al suo termine sono stati effettuati i controlli del caso (audit, send, check dell’avvenuta risoluzione dei problemi della scorsa settimana, chiamata di prova): solo esiti positivi.

Le restanti ore tra le tre meno un quarto e le sette e mezza sono passate prevalentemente nell’attesa che CO*:

1 - portasse a termine a sua volta le sue operazioni

2 – si rendesse conto di un problema dal suo lato

3 – risolvesse tali problemi

4 – risolvesse gli ulteriori problemi derivanti dalla soluzione di cui al punto 3

Ulteriori test sono stati effettuati dai tecnici bbned sull’utenza migrata, nessun problema è stato posto alla nostra attenzione.

Grazie a tutti

Vito

Suppon a box...

Iniziasi oggi, così, senza motivo apparente, l'audace tentativo di valorosi operai del 2000...