La registrazione a giornale è una di quelle funzioni che si attivano perché "serve per il commitment control" e poi restano lì senza che nessuno le usi davvero. È un peccato, perché il giornale risponde a una domanda che nelle aziende si sente tutte le settimane: questo record chi l'ha cambiato, quando, e cosa c'era scritto prima?
Come è fatto
Servono due oggetti:
- Il ricevitore di giornale (
*JRNRCV), il file fisico dove le voci vengono scritte. - Il giornale (
*JRN), che punta al ricevitore attivo e a cui si agganciano i file da sorvegliare.
CRTJRNRCV JRNRCV(MIALIB/JRNRCV0001)
TEXT('Ricevitore dati applicativi')
CRTJRN JRN(MIALIB/JRNDATI)
JRNRCV(MIALIB/JRNRCV0001)
MNGRCV(*SYSTEM)
DLTRCV(*NO)
MNGRCV(*SYSTEM) è importante: lascia al sistema il compito di staccare il ricevitore pieno e crearne uno nuovo. Senza, il ricevitore cresce finché non riempie il disco, ed è uno degli incidenti più classici.
DLTRCV(*NO) dice di non cancellare i ricevitori vecchi automaticamente. Vale la pena partire così con la cancellazione automatica si rischia di perdere le voci prima di averle salvate, e passare a *YES solo quando la procedura di salvataggio dei ricevitori è in piedi e verificata.
Attivare la registrazione su un file
STRJRNPF FILE(MIALIB/CLIENTI)
JRN(MIALIB/JRNDATI)
IMAGES(*BOTH)
OMTJRNE(*OPNCLO)
Le due opzioni contano molto:
IMAGES(*BOTH) registra sia il record prima della modifica sia quello dopo. Con *AFTER si vede solo il risultato: si sa cosa c'è adesso, non cosa c'era prima. Occupa di più, ma è ciò che rende il giornale utile per capire cosa è successo.
OMTJRNE(*OPNCLO) esclude dalla registrazione le voci di apertura e chiusura dei file. Sono rumore che gonfia il ricevitore senza aggiungere informazione.
La domanda di tutti i giorni
Un cliente sostiene che il fido era diverso. Il giornale sa rispondere:
DSPJRN JRN(MIALIB/JRNDATI)
FILE(MIALIB/CLIENTI)
FROMTIME('27/07/2026' '00:00:00')
ENTTYP(*RCD)
OUTPUT(*OUTFILE)
OUTFILE(QTEMP/VOCI)
I tipi di voce che interessano nel lavoro sui dati sono tre: PT (record inserito), UP (record aggiornato) e DL (record cancellato). Con IMAGES(*BOTH) un aggiornamento produce due voci: l'immagine prima e quella dopo.
Riversando il risultato in un file (OUTPUT(*OUTFILE)), lo si interroga in SQL come qualsiasi altra tabella: si filtra per utente, per intervallo di tempo, per contenuto del record. È molto più pratico dello sfoglio a video, soprattutto quando le voci sono migliaia.
Ogni voce porta con sé l'ora, il job, il programma e il profilo utente che ha eseguito la modifica. È la risposta completa alla domanda iniziale, e non richiede che l'applicazione abbia previsto nessuna tracciatura.
Il ruolo per cui è nato: ripartire dopo un guasto
Il giornale colma la distanza fra l'ultimo salvataggio e il momento del guasto. Si ripristina il backup della sera prima, e poi si riapplicano dal giornale tutte le modifiche successive con APYJRNCHG. Se il salvataggio è delle 22 e il guasto arriva alle 17, si recupera l'intera giornata invece di perderla.
C'è anche l'operazione opposta, RMVJRNCHG, che toglie le modifiche a partire da un certo punto, utile quando un batch sbagliato ha aggiornato migliaia di record e occorre tornare indietro.
Entrambi i comandi vanno provati prima, in una libreria di collaudo. Sono operazioni che riscrivono i dati: non è il caso di conoscerli per la prima volta durante un'emergenza.
Lo spazio, che è il problema pratico
I ricevitori crescono, e su un file molto movimentato crescono in fretta. Le contromisure:
MNGRCV(*SYSTEM), così il cambio ricevitore è automatico.- Salvare i ricevitori insieme al backup, e solo dopo cancellarli.
- Registrare i file giusti. Non tutti i file meritano il giornale: le tabelle di lavoro e quelle ricostruibili si possono escludere senza perdere nulla.
OMTJRNE(*OPNCLO), che toglie una quantità sorprendente di voci inutili.
Un controllo periodico dello spazio occupato dai ricevitori evita la sorpresa:
DSPOBJD OBJ(MIALIB/JRNRCV*) OBJTYPE(*JRNRCV) DETAIL(*FULL)
Il giornale di audit, che è una cosa diversa
Accanto ai giornali applicativi esiste QAUDJRN, il giornale di sicurezza: registra accessi, modifiche ai profili, tentativi di autorizzazione negati. Non riguarda i dati ma chi fa cosa sul sistema, e si attiva tramite i valori di sistema QAUDCTL e QAUDLVL.
Vale la pena averlo attivo anche se nessuno lo legge tutti i giorni: il momento in cui serve è sempre un momento in cui non lo si può più attivare retroattivamente.
Su quali versioni funziona
CRTJRNRCV, CRTJRN, STRJRNPF, DSPJRN, APYJRNCHG, RMVJRNCHG comandi
storici, presenti su tutte le release in uso e con lo stesso comportamento. La
registrazione a giornale è una delle parti più stabili del sistema.
MNGRCV(*SYSTEM) per la gestione automatica dei ricevitori è disponibile da molte
release ed è il valore da preferire. Il metodo manuale, staccare il ricevitore con
CHGJRN JRNRCV(*GEN) da un programma pianificato, è quello che si usava prima e che si
trova ancora su installazioni vecchie: funziona, ma richiede che qualcuno ricordi di farlo.
Il giornale di audit QAUDJRN, con i valori di sistema QAUDCTL e QAUDLVL, esiste
da molto tempo. I singoli tipi di evento registrabili sono stati però ampliati nel corso
delle release: l'elenco valido è quello della documentazione della propria versione.
La lettura in SQL delle voci di giornale le release più recenti offrono
QSYS2.DISPLAY_JOURNAL, che evita il passaggio per OUTFILE. È una IBM i Service, quindi
la disponibilità dipende da release e livello di PTF. Il metodo mostrato nell'articolo
(DSPJRN con OUTPUT(*OUTFILE) e poi query sul file) funziona su qualsiasi versione ed è
per questo che l'ho usato.
Il commitment control si appoggia al giornale ed è anch'esso presente da molte release.
Commenti
Nessun commento ancora. Sii il primo a commentare!
Devi avere un account per commentare. Accedi · Registrati