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