Le domande “chi siamo“, “da dove veniamo”, “cosa facciamo” e “dove andremo” sono da sempre la base di tutta la filosofia e di cui non si riesce a dare una spiegazione precisa. Solamente un buon informatico/programmatore/amministratore sa che la risposta a tutte queste domande le si possono trovare nei cari file di Log.
Vediamo insieme cosa sono e come leggerne una tipologia.

I Log

Il termine Log viene utilizzato per indicare dei file solitamente di testo (ma nulla vieta che siano intesi come tabelle di database) sempre aperti in scrittura in cui vengono registrate in maniera sequenziale e cronologica le informazioni di cui si necessita aver traccia.
Sono nati quindi a questo scopo diverse tipologie di Log per catalogare e classificare tipi di dati differenti ed altrettanti tipi di verbose (tipi di visualizzazione delle informazioni).

In Sme.UP non dobbiamo sorprenderci quindi di trovare diverse tipologie di Log tra cui:

  • di sistema;
  • delle API;
  • client/server;
  • di sessione;
  • di Looc.UP;
  • di comunicazione;
  • di AS400;
  • di utenti;
  • ecc

Le informazioni al loro interno variano a seconda dell’utilizzo che si vuol fare di quella tipologia di log e sopratutto a chi è rivolta la visualizzazione e la comprensione di questi agglomeratori di dati. I campi contenuti possono andare dal nome dell’utente loggato in questo istante, al tempo intercorso fra l’esecuzione di un thread e l’altro, allo stato di allocazione della memoria, all’errore riscontrato ecc.
A tal proposito la sopracitata voce verbose sta ad indicare la quantità di dati che il log restituisce quando viene interrogato e solitamente è buona norma avere almeno 3 livelli di verbose:

    • flusso dati senza errori;
    • solo errori;
    • flusso dati e errori;

Vedremo ora quindi di rendere più chiare le idee di come visualizzare i Log di comunicazione di Sme.UP e di cercare di leggere e capirne il contenuto.

I Log di comunicazione

I log di comunicazione in Sme.UP raccolgono informazioni riguardo la “trasmissione di messaggi” che avvengono tra i componenti di un particolare device (moduli di Looc.UP, Web.UP, ecc) ed il server AS400.
Accederci è molto semplice, per Looc.UP basta infatti accedere all’albero di scelta a sinistra sulla home ed espandere la categoria “Architettura e sistemi di base” e cliccare su “B£ Funzioni base” (prima immagine). Dopodiché nelle icone comparse cliccare su “Log di SMEup” (seconda immagine). A questo punto sulla sinistra si potrà vedere il link a “Log di comunicazione” (terza immagine).

MenuB£ MenuLogDiComunicazione Oggetti_B£

Con il doppio click si arriverà alla scheda dei Log di comunicazione.

ModuloLogComunicazione

In Web.UP la procedura è pressoché uguale a quanto detto pocanzi, utilizzando ovviamente una grafica rivista appositamente per il web, e quindi con ovvie modifiche visive.
Vengono riassunti i passaggi precedenti per il web nella serie di immagini sottostanti:

A questo punto ci vengono date principalmente 3 azioni:

  • leggere i log, che tratteremo successivamente;
  • eliminazione completa di tutti i log di comunicazione creati dall’utente;
  • scegliere il livello di verbose dei log;

Proprio a questa ultima scelta si riferisce l’immagine sottostante in cui l’utente ha la possibilità di scegliere, tramite un livello crescente, la quantità di dati da raccogliere. Si fa notare che il livello 1 non è utile all’utente normale, ma viene lasciato per motivi di retrocompatibilità.

Come leggere i Log di comunicazione

Andando nella sezione “dettaglio log” si ha la possibilità di interrogare l’AS400 sui file memorizzati e accedere quindi alle informazioni volute. E’ necessario quindi inserire il lasso temporale di cui si intende visualizzare lo storico e inserire l’utente applicativo di cui si necessita sapere le comunicazioni effettuate(che al momento della stesura del documento è cablato per essere identico a quello di sistema, ma è previsto un cambiamento nel prossimo futuro).
Si ha la possibilità di visualizzare anche solo i log di errore flaggando l’opzione appropriata.

FiltriCattura

Cliccando sul pulsante di conferma avremo a disposizione tutti le informazioni riguardanti tutte le comunicazioni avvenute dall’utente selezionato nel lasso di tempo imposto. La matrice che verrà presentata a video sarà simile alla sottostante che racchiude le informazioni basilari (filtrate tramite il setup denominato Base, modificabile in ALL per avere un verbose maggiore):

Matrice log comunicazione

Siamo giunti ora al punto in cui ci è possibile rispondere alle domande che ci siamo posti all’inizio dell’articolo sapendo la storia passata, la storia presente e poter così predire più o meno la storia futura dell’utente.
Vediamo quindi la spiegazione di tutte le colonne dei file di log.
La prima terna è univoca (lato server) per identificare il job che sta servendo quell’evento:

  • Lavoro AS400: identificativo del job (può essere inteso come servizio di Windows in ambiente AS400) che si è preso in carico la richiesta effettuata;
  • Utente AS400: utente di sistema loggato su AS400 a cui corrisponde il collegamento del record che si sta leggendo (come già detto, questo utente è cablato per essere identico a quello di applicativo, ma è previsto un cambiamento nel prossimo futuro);
  • N°Sessione AS400: identificativo che è univoco per ogni sessione aperta verso il server (sia essa da Looc.UP, che da Web.UP che da mobile, ecc);

Questa terna invece ha il compito di dare una panoramica veloce sul tipo di richiesta effettuata, come ad esempio i parametri di una FUN così da avere già un quadro iniziale su che tipo di collegamento è avvenuto. Il primo parametro viene indicato con “Messaggio/servizio” perché in taluni casi può essere richiesto un servizio (es. LOA60_SE) e in altri casi delle FUN (es. *SCO, che identifica l’apertura di una scheda):

  • Messaggio/Servizio
  • Dettaglio 1
  • Dettaglio 2

Gli altri campi invece sono:

  • Ambiente: ambiente in cui è loggato l’utente al momento del collegamento;
  • Utente Applicativo: utente loggato a cui corrisponde il collegamento del record che si sta leggendo (poco utile se si sta leggendo i log di un solo utente, ma molto utile in caso di multiutente);
  • Device: siccome è possibile interrogare il server con diversi dispositivi come Looc.UP, Web.UP, mobile, ecc questo campo identifica il tipo di device utilizzato;
  • Data Evento/inizio: data in cui è stato lanciato l’evento;
  • Ora Evento/inizio: orario in cui è stato lanciato l’evento;
  • Master: identificativo che raggruppa tutti i record di un’unica sessione;
  • Tipo Azione: serve a capire a colpo d’occhio che tipo di evento è stato lanciato (es. PNG è un ping, COL è di comunicazione, ecc);
  • Timestamp: timestamp in cui è stato registrato l’evento;
  • Durata millisecondi: durata che intercorre tra l’inizio e la fine dell’evento;
  • Durata significativa: serve ad indicare se la durata è stata correttamente calcolata o gli servono ulteriori informazioni per calcolarla (tipico esempio quando l’evento non è ancora stato processato e quindi non si ha la data di fine evento e quindi non può calcolare il tempo)
  • Errore: se ci sono stati errori;
  • Campo libero: campo in cui vengono inseriti ulteriori dettagli sul tipo di evento lanciato.

Come avviene la pulizia dei file di Log

Ultima nota sui file di log riguarda la loro gestione sul server.
Abbiamo visto che l’utilizzo dei file di log di comunicazione può risultare molto utile per l’individuazione di problemi che a prima vista non  si riuscirebbe a risolvere. Questo però comporta un’elevata scrittura di dati che aumenta di molto nel caso in cui sia impostato un livello di log “Attivo per tutte le info“.

Si raccomanda quindi la schedulazione di operazioni di pulizia periodiche di file  tramite il programma B£LOG4. Esso è un programma generico di pulizia per il JALOGT0F e pertanto per fargli comprendere che tipo di file cancellare è necessario passargli dei parametri di ingresso:

  • Funzione:
    • FLU: cancella log flussi;
    • BAT: cancella log LOA27 (Batch);
    • COM: cancella log di comunicazione;
    • LIN: cancella log modulo A£LING;
    • LIB: cancella log in base a TREC() e ORIGIN() ricevuti come parametro
  • metodo
  • utente
  • data minima
  • parametro
  • libreria

E’ possibile passare la keyword *ALL ai parametri utente e data per indicare di cancellare i dati di tutti gli utenti e/o di tutte le date.
E’ possibile anche indicare una data dinamica, in questo modo è possibile schedulare una chiamata del tipo:

CALL PGM(B£LOG4A) PARM('COM' '' '*ALL' '&OGI60-' '&OGI02-' '' '')

che cancella i dati di log di tutti gli utenti di oltre 60 giorni fa (e quelli più vecchi di 2 giorni per i dati di dettaglio se T$JA1F=’9′)
Per eseguire la riorganizzazione del file dopo la cancellazione dei record bisogna richiamare il B£LOG4B.