Versione 7 Release 1 - IBM - United States · sull'esonero di responsabilità e licenza del...

IBM i

DatabaseControllo del commitVersione 7 Release 1

��

NotaPrima di utilizzare le presenti informazioni e il prodotto da esse supportato, leggere leinformazioni contenute nella sezione “Informazioni particolari”, a pagina 123.

Questa edizione si applica a IBM i 7.1 (numero prodotto 5770-SS1) e a tutti i release e livelli di modifica successivi,a meno che non venga diversamente indicato nelle nuove edizioni. La presente versione non viene eseguita su tuttii modelli RISC (reduced instruction set computer) né sui modelli CISC.

© Copyright IBM Corporation 2003, 2010.

Indice

Controllo del commit . . . . . . . . . 1Novità in IBM i 7.1 . . . . . . . . . . . . 1File PDF per il controllo del commit . . . . . . 1Concetti di controllo del commit . . . . . . . . 2

Modalità di funzionamento del controllo delcommit . . . . . . . . . . . . . . . 2Modalità di funzionamento delle operazioni dicommit e di rollback. . . . . . . . . . . 3

Operazione di commit . . . . . . . . . 3Operazione di rollback . . . . . . . . . 4

Definizione di commit . . . . . . . . . . 5Ambito per una definizione di commit . . . 6Nomi di definizioni di commit . . . . . . 9Esempio: lavori e definizioni di commit . . . 10

Modalità di funzionamento del controllo delcommit con gli oggetti . . . . . . . . . . 12

Tipi di risorse di cui è possibile eseguire ilcommit . . . . . . . . . . . . . . 12Risorse di cui è possibile eseguire il commitlocali e remote . . . . . . . . . . . 15Intento di accesso di una risorsa di cui èpossibile eseguire il commit . . . . . . . 15Protocollo di commit di una risorsa di cui èpossibile eseguire il commit . . . . . . . 16File registrati su giornale e controllo delcommit . . . . . . . . . . . . . . 17Sequenza di voci di giornale sotto il controllodel commit . . . . . . . . . . . . 17Identificativo di ciclo di commit . . . . . 20Blocco di record . . . . . . . . . . . 21

Controllo del commit e lotti dischi indipendenti 22Considerazioni sui lotti dischi indipendentiper le definizioni di commit . . . . . . . 22Considerazioni per le transazioni XA . . . . 25

Considerazioni e limitazioni per il controllo delcommit . . . . . . . . . . . . . . . 25Controllo del commit per le applicazioni batch 27Controllo del commit in due fasi . . . . . . 28

Ruoli nell'elaborazione di commit . . . . . 29Stati della transazione per il controllo delcommit a due fasi . . . . . . . . . . 31Definizioni di commit per il controllo delcommit in due fasi . . . . . . . . . . 34

Definizione di commit per un commit indue fasi: consentire VRO (vote read-only) . 35Definizione di commit per un commit indue fasi: Non attendere risultato . . . . 37Definizione di commit per un commit indue fasi: indicazione di OK tralasciare . . 41Definizione di commit per un commit indue fasi: non selezione di un ultimo agent . 43Effetto della decisione affidabile sul flussodi elaborazione di commit . . . . . . 44

Supporto delle transazioni XA per il controllo delcommit . . . . . . . . . . . . . . . 46

Modalità server SQL e transazioni nell'ambito delsottoprocesso per il controllo del commit . . . 51

Avvio del controllo del commit . . . . . . . . 52Oggetto di notifica del commit . . . . . . . 53Livello di blocco del commit. . . . . . . . 55

Terminazione del controllo del commit . . . . . 58Terminazione avviata dal sistema del controllo delcommit . . . . . . . . . . . . . . . . 59

Controllo del commit durante la fine del gruppodi attivazione. . . . . . . . . . . . . 59Operazioni di commit e di rollback impliciti . . 60Controllo del commit durante la terminazionenormale del passo di instradamento . . . . . 63Controllo del commit durante la fine anomala dilavoro o sistema . . . . . . . . . . . . 64Aggiornamenti all'oggetto di notifica . . . . . 65Ripristino del controllo del commit durante l'IPL(initial program load) dopo la fine anomala . . 67

Gestione di transazioni e controllo del commit. . . 69Visualizzazione delle informazioni sul controllodel commit . . . . . . . . . . . . . 69

Visualizzazione di oggetti bloccati per unatransazione . . . . . . . . . . . . 70Visualizzazione di lavori associati a unatransazione . . . . . . . . . . . . 70Visualizzazione dello stato risorsa di unatransazione . . . . . . . . . . . . 71Visualizzazione delle proprietà delletransazioni . . . . . . . . . . . . 71

Ottimizzazione delle prestazioni per il controllodel commit . . . . . . . . . . . . . 71

Riduzione al minimo dei blocchi . . . . . 74Gestione della dimensione della transazione 75Commit soft . . . . . . . . . . . . 77

Scenari ed esempi: controllo del commit . . . . . 78Scenario: controllo del commit . . . . . . . 78Problema pratico per il controllo del commit . . 81

Flusso logico per l'esercizio pratico . . . . 87Passi associati al flusso logico per ilprogramma pratico . . . . . . . . . . 89

Esempio: utilizzo di un file di registrazione delletransazioni per avviare un'applicazione . . . . 90Esempio: utilizzo di un oggetto di notifica peravviare un'applicazione . . . . . . . . . 94

Esempio: oggetto di notifica univoco perciascun programma. . . . . . . . . . 96Esempio: oggetto di notifica singolo per tuttii programmi. . . . . . . . . . . . 100

Esempio: utilizzo di un programma dielaborazione standard per avviareun'applicazione. . . . . . . . . . . . 101

Esempio: codice per un programma dielaborazione standard . . . . . . . . 101

Flusso di elaborazione . . . . . . . 103Esempio: codice per un programma dielaborazione di commit standard . . . . . 104

© Copyright IBM Corp. 2003, 2010 iii

Esempio: utilizzo di un programma dielaborazione standard per decidere seriavviare l'applicazione . . . . . . . . 106

Risoluzione dei problemi relativi a transazioni econtrollo del commit . . . . . . . . . . . 107

Errori del controllo del commit . . . . . . 107Condizioni di errore . . . . . . . . . 108Condizioni senza errori . . . . . . . . 109Messaggi di errore da monitorare durante ilcontrollo del commit . . . . . . . . . 110Monitoraggio del verificarsi di errori dopoun comando CALL . . . . . . . . . 113Errore di elaborazione di commit o rollbacknormale . . . . . . . . . . . . . 113

Rilevazione di condizioni di stallo . . . . . 115

Ripristino delle transazioni dopo un errore nellecomunicazioni . . . . . . . . . . . . 116Quando forzare le opzioni di commit e dirollback e quando annullare larisincronizzazione . . . . . . . . . . . 117Fine di un rollback a lunga esecuzione . . . . 118Ricerca di transazioni di grandi dimensionioppure obsolete . . . . . . . . . . . 119

Informazioni correlate per il controllo del commit 120

Appendice. Informazioni particolari 123Informazioni sull'interfaccia di programmazione 125Marchi . . . . . . . . . . . . . . . 125Termini e condizioni . . . . . . . . . . . 125

iv IBM i: Database Controllo del commit

|||

Controllo del commit

Il controllo del commit è una funzione che assicura l'integrità dei dati. Definisce ed elabora un gruppo dimodifiche alle risorse, come ad esempio le tabelle o i file di database, come una transazione.

Il controllo del commit assicura che l'intero gruppo di modifiche individuali venga eseguito su tutti isistemi che partecipano alla transazione oppure che non venga eseguita nessuna delle modifiche. DB2 forIBM® i utilizza la funzione di controllo del commit per eseguire il commit e il rollback delle transazioni didatabase in esecuzione con un livello di isolamento diverso da *NONE (nessun commit).

È possibile utilizzare il controllo del commit per progettare un'applicazione in modo che il sistema possariavviare l'applicazione se un lavoro, un gruppo di attivazione in un lavoro o il sistema vengonoterminati in modo anomalo. Il controllo del commit consente di garantire che, quando l'applicazioneviene avviata nuovamente, nel database non siano presenti degli aggiornamenti parziali dovuti atransazioni incomplete dovute a un precedente malfunzionamento.

Nota: utilizzando gli esempi di codice, si accettano i termini indicati nella sezione “Informazionisull'esonero di responsabilità e licenza del codice” a pagina 121.

Novità in IBM i 7.1Questa sezione contiene informazioni nuove o modificate in modo significativo per la raccolta diargomenti Controllo del commit.v Supporto per le transazioni di controllo del commit che possono estendersi a un IASP (Independent

ASP) e *SYSBAS senza utilizzare una connessione remota (consultare le sezioni Considerazioni suImpostazione gruppo ASP e Considerazioni su IPL (initial program load) e disattivazione inConsiderazioni sui lotti dischi indipendenti per le definizioni di commit per informazioni dettagliate).

v Supporto per l'eliminazione di rami transazione XA orfani (consultare la sezione Considerazioni sulripristino in Supporto delle transazioni XA per il controllo del commit per informazioni dettagliate).

v Supporto per trovare transazioni di grandi dimensioni oppure obsolete (consultare Ricerca ditransazioni di grandi dimensioni oppure obsolete per informazioni dettagliate).

Come individuare le novità o le modifiche

Per facilitare l'individuazione dei punti in cui sono state apportate modifiche tecniche, questeinformazioni utilizzano:v L'immagine per segnalare dove iniziano le informazioni nuove o modificate.v L'immagine per segnalare dove finiscono le informazioni nuove o modificate.

Nei file PDF, vengono visualizzate delle barre (|) a sinistra delle informazioni nuove e modificate.

Per individuare ulteriori informazioni relative alle novità o alle modifiche, consultare l'argomento Memoper gli utenti.

File PDF per il controllo del commitÈ possibile visualizzare e stampare un file PDF che contiene le presenti informazioni.

Per visualizzare o scaricare la versione PDF di questo documento, selezionare Controllo del commit (circa1361 KB).

© Copyright IBM Corp. 2003, 2010 1

Salvataggio di file PDF

Per salvare un PDF sulla stazione di lavoro per la visualizzazione o per la stampa:1. Fare clic con il tasto destro del mouse sul collegamento PDF nel proprio browser.2. Selezionare l'opzione che effettua il salvataggio locale del PDF.3. Andare all'indirizzario in cui si desidera salvare il PDF.4. Fare clic su Salva.

Scaricamento di Adobe Reader

Per visualizzare o stampare tali PDF, è necessario che sul sistema sia installato Adobe® Reader. È possibile

scaricare una copia gratuita dal sito Web Adobe (www.adobe.com/products/acrobat/readstep.html) .Riferimenti correlati

“Informazioni correlate per il controllo del commit” a pagina 120I manuali dei prodotti, le pubblicazioni IBM Redbooks, i siti Web e altre raccolte di argomentidell'information center contengono informazioni correlate alla raccolta di argomenti Controllo del commit.È possibile visualizzare o stampare qualsiasi file PDF.

Concetti di controllo del commitQuesti concetti di controllo del commit aiutano a comprendere come funziona il controllo del commit,come interagisce con il sistema e come interagisce con gli altri sistemi nella rete.

Modalità di funzionamento del controllo del commitIl controllo del commit assicura che l'intero gruppo di modifiche individuali venga applicato su tutti isistemi partecipanti oppure che non venga applicata alcuna modifica.

Ad esempio, quando si trasferiscono dei fondi da un conto di risparmio a un conto corrente, vieneapplicata più di una modifica come un gruppo. Per l'utente, questo trasferimento sembra essere unasingola modifica. Tuttavia, viene applicata più di una modifica al database perché vengono modificati siail conto di risparmio sia il conto corrente. Per fare in modo che entrambi i conti siano accurati, tutte lemodifiche o nessuna delle modifiche devono essere applicate al conto corrente e al conto di risparmio.

Il controllo del commit consente di completare le seguenti attività:v Assicurarsi che tutte le modifiche in una transazione siano completate per tutte le risorse interessate.v Assicurarsi che tutte le modifiche in una transazione vengano eliminate se l'elaborazione viene

interrotta.v Rimuovere le modifiche apportate durante una transazione quando l'applicazione determina che una

transazione è in errore.

È anche possibile progettare un'applicazione in modo che il controllo del commit possa riavviarel'applicazione se un lavoro, un gruppo di attivazione in un lavoro o il sistema vengono terminati in modoanomalo. Il controllo del commit consente di garantire che, quando l'applicazione viene avviatanuovamente, nel database non siano presenti degli aggiornamenti parziali dovuti a transazioniincomplete dovute a un precedente malfunzionamento.

Transazione

Una transazione è un gruppo di singole modifiche agli oggetti sul sistema che si presenta all'utente comeuna singola modifica "atomica" (ossia indivisibile).

2 IBM i: Database Controllo del commit

http://www.adobe.com/products/acrobat/readstep.html

Nota: System i Navigator utilizza il termine transazione, mentre l'interfaccia basata sui caratteri utilizza iltermine LUW (logical unit of work o unità di lavoro logica). I due termini sono intercambiabili. Questoargomento, a meno che non faccia specificamente riferimento all'interfaccia basata sui caratteri,utilizza il termine transazione.

Una transazione può essere una delle seguenti situazioni:v Interrogazioni in cui non si verifica alcuna modifica del file di database.v Semplici transazioni che modificano un singolo file di database.v Transazioni complesse che modificano uno o più file di database.v Transazioni complesse che modificano uno o più file di database, ma queste modifiche rappresentano

solo una parte di un gruppo logico di transazioni.v Transazioni semplici e complesse che interessano i file di database su più di una singola ubicazione. I

file di database possono essere in una delle seguenti situazioni:– Su un sistema remoto singolo.– Sul sistema locale e uno o più sistemi remoti.– Assegnato a più di un giornale sul sistema locale. Ciascun giornale può essere considerato come

un'ubicazione locale.v Transazioni semplici o complesse sul sistema locale che interessano oggetti diversi dai file di database.

Modalità di funzionamento delle operazioni di commit e di rollbackLe operazioni di commit e di rollback interessano le modifiche apportate sotto il controllo del commit.

I seguenti linguaggi di programmazione e le seguenti API (application programming interface)supportano le operazioni di commit e di rollback.

Linguaggio o API Commit Rollback

CL Comando COMMIT Comando ROLLBACK

IBM ILE (Integrated LanguageEnvironment) RPG

Codice operazione COMIT Codice operazione ROLBK

ILE COBOL Verbo COMMIT Verbo ROLLBACK

ILE C Funzione _Rcommit Funzione _Rrollbck

PLI Sottoroutine PLICOMMIT Sottoroutine PLIROLLBACK

SQL Istruzione COMMIT Istruzione ROLLBACK

SQL CLI (Call Level Interface) Funzione SQLTransact() (Viene utilizzata per eseguire il commit e il rollbackdi una transazione)

API XA API xa_commit() e db2xa_commit() API xa_rollback() e db2xa_rollback()

Concetti correlati

SQL call level interfaceDatabase programmingInformazioni correlate

PDF del manuale WebSphere Development Studio: ILE C/C++ Programmer's GuideCL programmingApplication programming interfaces

Operazione di commitUn'operazione di commit rende permanenti tutte le modifiche eseguite sotto il controllo del commit dopola precedente operazione di commit o rollback. Il sistema rilascia anche tutti i blocchi correlati allatransazione.

Controllo del commit 3

http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzaha/sc092712.pdf

Quando riceve una richiesta di esecuzione di un commit, il sistema esegue le seguenti operazioni:v Il sistema salva l'identificazione di commit, se ne viene fornita una, per l'utilizzo al momento del

ripristino.v Il sistema scrive i record nel file prima di eseguire l'operazione di commit se ricorrono entrambe le

condizioni qui di seguito indicate:– I record sono stati aggiunti a un file di database locale o remoto sotto il controllo del commit.– SEQONLY(*YES) è stato specificato quando il file è stato aperto in modo che il sistema utilizzi il

feedback I/E bloccato ed esista un blocco parziale di record.Altrimenti, l'area di feedback I/E e i buffer I/E non vengono modificati.

v Il sistema esegue una chiamata al programma di uscita di rollback e di commit per ciascuna risorsa dicommit API presente nella definizione di commit. Se per un'ubicazione è registrato più di unprogramma di uscita, il sistema richiama i programmi di uscita per tale ubicazione nell'ordine in cuierano stati registrati.

v Se sono state eseguite delle modifiche di record per le risorse assegnate a un giornale, il sistema scriveuna voce di giornale C CM in ogni giornale locale associato alla definizione di commit. La sequenza divoci di giornale sotto il controllo del commit mostra le voci di norma scritte mentre è attiva unadefinizione di commit.

v Il sistema rende permanenti le modifiche a livello di oggetto in sospeso.v Il sistema sblocca i blocchi di record e oggetto acquisiti e mantenuti per scopi di controllo del commit.

Queste risorse sono rese disponibili ad altri utenti.v Il sistema modifica le informazioni nella definizione di commit per mostrare che la transazione corrente

è stata terminata.

Il sistema deve eseguire tutti i passi precedenti correttamente perché l'operazione di commit abbia esitopositivo.Concetti correlati

“Definizione di commit” a pagina 5La definizione di commit contiene informazioni pertinenti alle risorse di cui è in corso la modifica sotto ilcontrollo del commit durante una transazione.“Sequenza di voci di giornale sotto il controllo del commit” a pagina 17Questa tabella mostra la sequenza di voci di norma scritte mentre è attiva una definizione di commit. Èpossibile utilizzare il programma di ricerca delle informazioni sulle voci del giornale per ottenere ulterioriinformazioni sul contenuto delle voci di giornale.

Operazione di rollbackUn'operazione di rollback elimina tutte le modifiche apportate dopo la precedente operazione di commito rollback. Il sistema rilascia anche tutti i blocchi correlati alla transazione.

Il sistema esegue le seguenti operazioni quando riceve una richiesta di esecuzione di un rollback:v Il sistema elimina i record dal buffer I/E se ricorrono entrambe queste condizioni:

– Se i record sono stati aggiunti a un file di database locale o remoto sotto il controllo del commit.– Se SEQONLY(*YES) è stato specificato quando il file è stato aperto in modo che il sistema utilizzi

l'I/E bloccato ed esista un blocco parziale di record che non è stato ancora scritto nel database.Altrimenti, l'area di feedback I/E e i buffer I/E rimangono invariati.

v Il sistema esegue una chiamata al programma di uscita di rollback o di commit per ciascuna risorsa dicommit API presente nella definizione di commit. Se per un'ubicazione è registrato più di unprogramma di uscita, il sistema richiama i programmi di uscita per tale ubicazione in ordine inversorispetto a quello in cui erano stati registrati.

v Se un record è stato eliminato da un file, il sistema aggiunge nuovamente il record al file.v Il sistema rimuove le eventuali modifiche ai record che sono state eseguite durante questa transazione

e rimette i record originali (le immagini-precedenti) nel file.


v Se dei record sono stati aggiunti al file durante questa transazione, rimangono nel file come recordcancellati.

v Se sono state eseguite delle modifiche di record per le risorse assegnate a un giornale durante latransazione, il sistema aggiunge una voce di giornale di C RB al giornale, indicando che si è verificataun'operazione di rollback. Il giornale contiene anche immagini delle modifiche di record di cui è statoeseguito il rollback. Prima che venisse richiesta l'operazione di rollback. le immagini-precedenti e leimmagini-successive dei record modificati erano state inserite nel giornale. Il sistema scrive anche lavoce C RB nel giornale predefinito se a tale giornale è assegnata qualche risorsa di cui è possibileeseguire il commit.

v Il sistema posiziona i file aperti sotto il controllo del commit a una delle seguenti posizioni:– L'ultimo record cui è stato eseguito l'accesso nella transazione precedente– Alla posizione di apertura se non è stata eseguita alcuna operazione di commit per il file utilizzando

questa definizione di commit

Questa considerazione è importante se si sta eseguendo un'elaborazione sequenziale.v Il sistema non esegue il rollback delle modifiche di cui non è possibile eseguire il commit per i file di

database. Ad esempio, i file aperti non vengono chiusi e i file cancellati non vengono ripristinati. Ilsistema non riapre o riposiziona i file chiusi durante questa transazione.

v Il sistema sblocca i blocchi di record acquisiti per scopi di controllo del commit e rende questi recorddisponibili ad altri utenti.

v L'identificazione di commit attualmente salvata dal sistema rimane uguale all'identificazione di commitfornita con l'ultima operazione di commit per la stessa definizione di commit.

v Il sistema inverte le, o esegue il rollback delle, modifiche di cui è possibile eseguire il commit a livellodi oggetto eseguite durante questa transazione.

v I blocchi di oggetto acquisiti per scopi di controllo del commit vengono sbloccati e tali oggetti vengonoresi disponibili ad altri utenti.

v Il sistema stabilisce il limite di commit precedente come limite di commit corrente.v Il sistema modifica le informazioni nella definizione di commit per mostrare che la transazione corrente

è stata terminata.

Il sistema deve eseguire tutti i passi precedenti correttamente perché l'operazione di rollback abbia esitopositivo.

Definizione di commitLa definizione di commit contiene informazioni pertinenti alle risorse di cui è in corso la modifica sotto ilcontrollo del commit durante una transazione.

Per creare una definizione di commit, utilizzare il comando STRCMTCTL (Avvio controllo commit) peravviare il controllo del commit sul sistema. Inoltre, DB2 for i crea automaticamente una definizione dicommit quando il livello di isolamento è diverso da *NONE (nessun commit).

Il sistema conserva le informazioni di controllo del commit nella definizione di commit mentre le risorsedi commit vengono modificate fino al termine della definizione di commit. Ciascuna transazione attivasul sistema è rappresentata da una definizione di commit. Una transazione successiva può riutilizzareuna definizione di commit dopo ciascun commit o rollback di una transazione attiva.

Una definizione di commit di norma include le seguenti informazioni:v I parametri del comando STRCMTCTL.v Lo stato corrente della definizione di commit.v Le informazioni sui file di database e altre risorse di cui è possibile eseguire il commit che contengono

modifiche eseguite durante la transazione corrente.


Per le definizioni di commit con blocchi nell'ambito del lavoro, solo il lavoro che avvia il controllo delcommit conosce tale definizione di commit. Nessun altro lavoro conosce tale definizione di commit.

I programmi possono avviare e utilizzare più definizioni di commit. Ciascuna definizione di commit perun lavoro identifica una transazione separata cui sono associate delle risorse di cui è possibile eseguire ilcommit. È possibile eseguire il commit o il rollback di queste transazioni indipendentemente dalletransazioni associate ad altre definizioni di commit avviate per il lavoro.Concetti correlati

“Operazione di commit” a pagina 3Un'operazione di commit rende permanenti tutte le modifiche eseguite sotto il controllo del commit dopola precedente operazione di commit o rollback. Il sistema rilascia anche tutti i blocchi correlati allatransazione.“Controllo del commit e lotti dischi indipendenti” a pagina 22I lotti dischi indipendenti e i gruppi di lotti dischi indipendenti possono ognuno avere un database i5/OSseparato. È possibile utilizzare il controllo del commit con questi database.“Considerazioni sui lotti dischi indipendenti per le definizioni di commit” a pagina 22Quando si utilizzano i lotti dischi indipendenti, è necessario tenere presenti le seguenti considerazioni perle definizioni di commit.

Ambito per una definizione di commitL'ambito di una definizione di commit determina quali programmi utilizzano questa definizione dicommit e in che modo viene definito l'ambito dei blocchi acquisiti durante le transazioni.

L'interfaccia che avvia la definizione di commit determina l'ambito della definizione di commit. Gliambiti possibili per una definizione di commit sono quattro e rientrano in due categorie generali:

Definizioni di commit con blocchi nell'ambito del lavoro

v Definizione di commit a livello di gruppo di attivazionev Definizione di commit a livello di lavorov Definizione di commit denominata esplicitamente

Definizioni di commit con blocchi nell'ambito della transazione

v Definizione di commit nell'ambito della transazione

Le definizioni di commit con blocchi nell'ambito del lavoro possono essere utilizzate solo dai programmiche vengono eseguiti nel lavoro che ha avviato le definizioni di commit. Al confronto, più di un lavoropuò utilizzare le definizioni di commit con i blocchi nell'ambito della transazione.

Le applicazioni di norma utilizzano le definizioni di commit a livello di gruppo di attivazione o a livellodi lavoro. Queste definizioni di commit vengono create esplicitamente con il comando STRCMTCTL(Avvio controllo commit) oppure implicitamente dal sistema quando un'applicazione SQL viene eseguitacon un livello di isolamento diverso da *NONE.

Definizione di commit a livello di gruppo di attivazione

L'ambito più comune è quello del gruppo di attivazione. La definizione di commit a livello di gruppo diattivazione è l'ambito predefinito quando il comando STRCMTCTL avvia esplicitamente la definizione dicommit o quando un'applicazione SQL eseguita con un livello di isolamento diverso da *NONE (nessuncommit) avvia implicitamente la definizione di commit. Solo i programmi eseguiti in tale gruppo diattivazione utilizzano questa definizione di commit. Per un lavoro, possono essere attive molte definizionidi commit a livello di gruppo di attivazione alla volta. Tuttavia, ciascuna definizione di commit a livellodi gruppo di attivazione può essere associata solo a un singolo gruppo di attivazione. I programmieseguiti in tale gruppo di attivazione possono associare le loro modifiche di cui è possibile eseguire ilcommit solo a tale definizione di commit a livello di gruppo di attivazione.


Quando System i Navigator, il comando WRKCMTDFN (Gestione definizioni di commit), il comandoDSPJOB (Visualizzazione lavoro) o il comando WRKJOB (Gestione lavoro) visualizzano una definizione dicommit a livello di gruppo di attivazione, questi campi visualizzano le seguenti informazioni:v Il campo della definizione di commit visualizza il nome del gruppo di attivazione. Mostra il valore

speciale *DFTACTGRP per indicare il gruppo di attivazione predefinito.v Il campo del gruppo di attivazione visualizza il numero del gruppo di attivazione.v Il campo del lavoro visualizza il lavoro che ha avviato la definizione di commit.v Il campo del sottoprocesso visualizza *NONE.

Definizione di commit a livello di lavoro

Una definizione di commit può essere inclusa nell'ambito del lavoro solo immettendo STRCMTCTLCMTSCOPE (*JOB). Qualsiasi programma in esecuzione in un gruppo di attivazione per cui non è stataavviata una definizione di commit a livello di gruppo di attivazione utilizza la definizione di commit alivello di lavoro, se è già stata avviata da un altro programma per il lavoro. È possibile avviare solo unasingola definizione di commit a livello di lavoro per un lavoro.

Quando System i Navigator, il comando WRKCMTDFN (Gestione definizioni di commit), il comandoDSPJOB (Visualizzazione lavoro) o il comando WRKJOB (Gestione lavoro) visualizzano una definizione dicommit a livello di lavoro, questi campi visualizzano le seguenti informazioni:v Il campo della definizione di commit visualizza il valore speciale *JOB.v Il campo del gruppo di attivazione viene visualizzato vuoto.v Il campo del lavoro visualizza il lavoro che ha avviato la definizione di commit.v Il campo del sottoprocesso visualizza *NONE.

Per uno specifico gruppo di attivazione, i programmi eseguiti in tale gruppo di attivazione possonoutilizzare solo una singola definizione di commit. Pertanto, i programmi eseguiti in un gruppo diattivazione possono utilizzare la definizione di commit a livello di lavoro o quella a livello di gruppo diattivazione, ma non entrambe contemporaneamente. In un lavoro a più sottoprocessi che non utilizza lamodalità server SQL, il lavoro transazionale per un programma viene incluso nell'ambito dell'appropriatadefinizione di commit rispetto al gruppo di attivazione del programma, indipendentemente da qualesottoprocesso lo esegue. Se più sottoprocessi utilizzano lo stesso gruppo di attivazione, devono cooperareper eseguire il lavoro transazionale e assicurare che i commit e i rollback si verifichino al momentogiusto.

Anche quando la definizione di commit a livello di lavoro è attiva per il lavoro, un programma puòcomunque avviare la definizione di commit a livello di gruppo di attivazione se nessun programma inesecuzione in tale gruppo di attivazione ha eseguito operazioni o richieste di controllo del commit per ladefinizione di commit a livello di lavoro. Altrimenti, occorre prima terminare la definizione di commit alivello di lavoro per potere quindi avviare la definizione di commit a livello di gruppo di attivazione. Leseguenti operazioni o richieste di controllo del commit per la definizione di commit a livello di lavoropossono impedire l'avvio della definizione di commit a livello di gruppo di attivazione:v Apertura (piena o condivisa) di un file di database sotto il controllo del commit.v Utilizzo dell'API QTNADDCR (Aggiunta risorsa di commit) per aggiungere una risorsa di commit API.v Esecuzione del commit di una transazione.v Esecuzione del rollback di una transazione.v Aggiunta di una risorsa remota sotto il controllo del commit.v Utilizzo dell'API QTNCHGCO (Modifica opzioni di commit) per modificare le opzioni di commit.v Passaggio della definizione di commit a uno stato di rollback richiesto utilizzando l'API QTNRBRQD

(Rollback richiesto).


v Invio di una voce di giornale utente che include l'identificativo di ciclo di commit corrente utilizzandol'API QJOSJRNE (Invio voce di giornale) con il parametro di inclusione dell'identificativo di ciclo dicommit.

In modo analogo, se i programmi in un gruppo di attivazione stanno attualmente utilizzando ladefinizione di commit a livello di gruppo di attivazione, è necessario terminare prima la definizione dicommit perché poi i programmi in esecuzione nello stesso gruppo di attivazione possano utilizzare ladefinizione di commit a livello di lavoro.

Quando si apre un file di database, l'ambito di apertura per il file aperto può essere al gruppo diattivazione oppure al lavoro con una limitazione: se il programma sta aprendo un file sotto il controllodel commit e il file viene incluso nell'ambito del lavoro, il programma che esegue la richiesta di aperturadeve utilizzare la definizione di commit a livello di lavoro.

Definizione di commit denominata esplicitamente

Le definizioni di commit denominate esplicitamente vengono avviate dal sistema quando deve eseguiredelle proprie transazioni di controllo del commit senza interessare le transazioni utilizzate daun'applicazione. Un esempio di una funzione che avvia questi tipi di definizioni di commit è laregistrazione problemi. Un'applicazione non può avviare delle definizioni di commit denominateesplicitamente.

Quando System i Navigator, il comando WRKCMTDFN (Gestione definizioni di commit), il comandoDSPJOB (Visualizzazione lavoro) o il comando WRKJOB (Gestione lavoro) visualizzano una definizione dicommit denominata esplicitamente, questi campi visualizzano le seguenti informazioni:v Il campo di definizione di commit visualizza il nome ad essa assegnato dal sistema.v Il campo del gruppo di attivazione viene visualizzato vuoto.v Il campo del lavoro visualizza il lavoro che ha avviato la definizione di commit.v Il campo del sottoprocesso visualizza *NONE.

Definizioni di commit nell'ambito della transazione

Le definizioni di commit nell'ambito della transazione vengono avviate con le API XA per i blocchinell'ambito della transazione.

Queste API utilizzano i protocolli di controllo del commit basati sui sottoprocessi o sulla connessioneSQL, e non quelli basati sul gruppo di attivazione. In altre parole, le API vengono utilizzate per associarela definizione di commit a uno specifico sottoprocesso o a una specifica connessione SQL mentre vieneeseguito il lavoro transazionale e per eseguire il commit o il rollback delle transazioni. Il sistema collegaqueste definizioni di commit ai sottoprocessi che eseguono il lavoro transazionale in base ai protocolliAPI. Possono essere utilizzate dai sottoprocessi in lavori differenti.

Quando System i Navigator, il comando WRKCMTDFN (Gestione definizioni di commit), il comandoDSPJOB (Visualizzazione lavoro) o il comando WRKJOB (Gestione lavoro) visualizzano una definizione dicommit a livello della transazione, questi campi visualizzano le seguenti informazioni:v Il campo della definizione di commit visualizza il valore speciale *TNSOBJ.v Il campo del gruppo di attivazione viene visualizzato vuoto.v Il campo del lavoro visualizza il lavoro che ha avviato la definizione di commit. Se invece la

definizione di commit è attualmente collegata a un sottoprocesso, viene visualizzato il lavoro delsottoprocesso.

v Il campo relativo al sottoprocesso visualizza il sottoprocesso al quale è collegata la definizione dicommit (oppure *NONE, se la definizione di commit non è attualmente collegata ad alcunsottoprocesso).


Riferimenti correlati

XA APIs

Nomi di definizioni di commitIl sistema attribuisce dei nomi a tutte le definizioni di commit avviate per un lavoro.

La seguente tabella mostra varie definizioni di commit e i loro nomi associati per uno specifico lavoro.

Gruppo di attivazione Ambito di commit Nome di definizione di commit

Qualsiasi Lavoro *JOB

Gruppo di attivazione predefinito Gruppo di attivazione *DFTACTGRP

Gruppo di attivazione denominatodall'utente

Gruppo di attivazione Nome del gruppo di attivazione (adesempio, PAYROLL)

Gruppo di attivazione denominatodal sistema

Gruppo di attivazione Numero del gruppo di attivazione(ad esempio, 0000000145)

Nessuno Denominato esplicitamente QDIR001 (esempio di una definizionedi commit definita dal sistema peruso esclusivo da parte del sistema). Inomi di definizioni di commitdefinite dal sistema iniziano con Q.

Nessuno Transazione *TNSOBJ

Solo i programmi compilati IBM ILE (Integrated Language Environment) possono avviare il controllo delcommit per i gruppi di attivazione diversi dal gruppo di attivazione predefinito. Pertanto, un lavoro puòutilizzare più definizioni di commit solo se sta eseguendo uno o più programmi compilati ILE.

I programmi OPM (Original Program Model) vengono eseguiti nel gruppo di attivazione predefinito e,per impostazione predefinita, utilizzano la definizione di commit *DFTACTGRP. In un ambiente OPM eILE misto, i lavori devono utilizzare la definizione di commit a livello del lavoro se tutte le modifiche dicui è possibile eseguire il commit apportate da tutti i programmi devono essere sottoposte a commit o arollback insieme.

Un file di database aperto incluso nell'ambito di un gruppo di attivazione può essere associato a unadefinizione di commit a livello di gruppo di attivazione o a livello di lavoro. Un file di database apertoincluso nell'ambito del lavoro può essere associato solo alla definizione di commit a livello di lavoro.Pertanto, qualsiasi programma, OPM o ILE, che apre un file di database sotto il controllo del commitincluso nell'ambito del lavoro deve utilizzare la definizione di commit a livello di lavoro.

I programmi applicativi non utilizzano il nome di definizione di commit per identificare una specificadefinizione di commit quando si esegue una richiesta di controllo del commit. I nomi di definizione dicommit sono principalmente utilizzati nei messaggi per identificare una specifica definizione di commitper un lavoro.

Per le definizioni di commit a livello di gruppo di attivazione, il sistema determina quale definizione dicommit utilizzare, sulla base del gruppo di attivazione nel quale è in esecuzione il programmarichiedente. Questo è possibile perché i programmi eseguiti in un gruppo di attivazione in qualsiasimomento non possono utilizzare che una singola definizione di commit.

Per le transazioni con dei blocchi nell'ambito della transazione, le API XA e gli attributi correlati alletransazioni aggiunti alla CLI determinano quale definizione di commit è utilizzata dal sottoprocessorichiamante.


Informazioni correlate

ILE concepts PDF

Esempio: lavori e definizioni di commitQuesta figura mostra un esempio di un lavoro che utilizza più definizioni di commit.

La figura indica quali aggiornamenti di file sono sottoposti a commit o a rollback a ogni livello di gruppodi attivazione. L'esempio presume che tutti gli aggiornamenti apportati ai file di database da tutti iprogrammi vengano eseguiti sotto il controllo del commit.


La seguente tabella mostra in che modo viene eseguito il commit o il rollback dei file se lo scenario nellafigura precedente subisce delle modifiche.

Esempi aggiuntivi di più definizioni di commit in un lavoro

Modifica nelloscenario

Effetto sulle modifiche a questi file

F1 e F2 F3 e F4 F5 e F6 F7

PGMX esegueun'operazione dirollback invece diun'operazione dicommit (3==COMMIT diventaROLLBACK).

In sospeso Sottoposto a rollback Già sottoposto acommit

Sottoposto a rollback

PGMZ esegueun'operazione dicommit prima dellarestituzione a PGMX.

In sospeso Sottoposto a commitda PGMZ

Già sottoposto acommit

Sottoposto a commit

PGMZ prova adavviare il controllodel commitspecificandoCMTSCOPE(*ACTGRP)dopo l'aggiornamentodel file F7. Il tentativoha esito negativoperché le modifichesono in sospesoutilizzando ladefinizione di commita livello di lavoro.

In sospeso In sospeso Già sottoposto acommit

In sospeso

PGMX non avvia ilcontrollo del commite non apre i file F3 eF4 conCOMMIT(*YES).PGMZ prova adaprire il file F7 conCOMMIT(*YES).

In sospeso Non sotto il controllodel commit

Già sottoposto acommit

Il file F7 non puòessere aperto perchénon esiste alcunadefinizione di commit*JOB (PGMX non l'hacreata).

Modalità di funzionamento del controllo del commit con gli oggettiQuando viene posto sotto il controllo del commit, un oggetto diventa una risorsa di cui è possibileeseguire il commit. Viene registrato con la definizione di commit. Partecipa a ogni operazione di commite di rollback eseguita per la definizione di commit.

I seguenti argomenti descrivono questi attributi di una risorsa di cui è possibile eseguire il commit:v Tipo di risorsav Ubicazionev Protocollo di commitv Intento di accesso

Tipi di risorse di cui è possibile eseguire il commitQuesta tabella elenca i tipi differenti di risorse di cui è possibile eseguire il commit, inclusi FILE, DDL(Data Definition Language), DDM (distributed data management), LU (logical unit) 6.2, DRDA(Distributed Relational Database Architecture, API e TCP.


La tabella visualizza i seguenti elementi:v I tipi di risorse di cui è possibile eseguire il commit.v Come vengono posti sotto il controllo del commit.v Come vengono rimossi dal controllo del commit.v Le limitazioni che si applicano al tipo di risorsa.

Tipo di risorsa

Come metterla sottoil controllo delcommit

Come rimuoverla dalcontrollo del commit

Quali tipi dimodifiche è possibilesottoporre a commit Limitazioni

FILE- file di databaselocali

Aprendola sotto ilcontrollo del commit1

Chiudendo il file, senon c'è alcunamodifica in sospeso.

Se delle modifichesono in sospesoquando il file vienechiuso, dopol'esecuzione dellasuccessiva operazionedi commit o dirollback.

Modifiche a livello direcord

Per una singolatransazione nonpossono esserebloccate più di 500000 000 record2.

DDL- modifiche alivello di oggetto perle raccolte SQL e letabelle SQL locali.

Eseguendo SQL sottoil controllo delcommit

Eseguendoun'operazione dicommit o di rollbackdopo la modifica alivello di oggetto.

Modifiche a livello dioggetto, come:

v Creazione di unpacchetto SQL

v Creazione di unatabella SQL

v Eliminazione diuna tabella SQL

Solo delle modifiche alivello di oggettoeseguite utilizzandoSQL sono sotto ilcontrollo del commit.

DDM- file DDM(distributed datamanagement) remoto

Aprendo sotto ilcontrollo del commit.Il supporto delcontrollo del commitper DDM contieneulteriori informazionisul controllo delcommit e sullagestione dei datidistribuiti.

Chiudendo il file, senon c'è alcunamodifica in sospeso.

Se delle modifichesono in sospesoquando il file vienechiuso, dopol'esecuzione dellasuccessiva operazionedi commit o dirollback.

Modifiche a livello direcord

LU 6.2- conversazioneprotetta

Avviando laconversazione3

Terminando laconversazione

DRDA- databaserelazionale distribuito

Utilizzandol'istruzione SQLCONNECT

Terminando laconnessione


Tipo di risorsa

Come metterla sottoil controllo delcommit

Come rimuoverla dalcontrollo del commit

Quali tipi dimodifiche è possibilesottoporre a commit Limitazioni

API- risorsa dicommit API locale

API QTNADDCR(Aggiunta di risorsadi commit)

API QTNRMVCR(Rimozione risorse dicommit)

Questo vienedeterminato dalprogramma utente.Le voci di giornalepossono essere scrittedal programmautente utilizzandol'API QJOSJRNE(Invio voce digiornale) per unausilio nel tracciarequeste modifiche.

L'applicazione devefornire unprogramma di uscitada richiamare durantele operazioni dicommit, rollback orisincronizzazione.

ConnessioneTCP-TCP/IP

Utilizzandol'istruzione SQLCONNECT a un RDBdefinito per utilizzareconnessioni TCP/IP oaprendo un file DDMdefinito conun'ubicazione TCP/IP

Terminando laconnessione SQL ochiudendo il fileDDM se non ci sonomodifiche in sospeso.Se il file DDM vienechiuso con dellemodifiche in sospeso,la connessione vienechiusa dopol'esecuzione dellasuccessiva operazionedi commit o dirollback.

Note:1 Per informazioni dettagliate su come mettere un file di database sotto il controllo del commit, consultare ilmanuale di riferimento al linguaggio appropriato. Le informazioni correlate per il controllo del commit colleganoai manuali relativi al linguaggio che è possibile utilizzare.2 È possibile utilizzare un file QAQQINI per ridurre il limite di 500 000 000. Consultare “Gestione delladimensione della transazione” a pagina 75 per istruzioni.3 Quando viene avviata una connessione DDM, il file DDM specifica PTCCNV(*YES) e il file DDM è definito conun'ubicazione remota SNA; una risorsa LU 6.2 viene aggiunta con la risorsa DDM.

Quando viene avviata una connessione DRDA, una risorsa LU 6.2 viene aggiunta con la risorsa DRDA se ricorronoentrambe le seguenti condizioni:

v Il programma sta utilizzando i protocolli di connessione di unità di lavoro distribuita.

v La connessione è a un RDB (rational database) definito con un'ubicazione remota SNA. Per ulteriori informazioni

sull'avvio di conversazioni protette, consultare il manuale APPC Programming .


http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzahj/sc415443.pdf

Concetti correlati

Distributed database programming“Aggiornamenti all'oggetto di notifica” a pagina 65Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commiteseguita correttamente per tale definizione di commit.Riferimenti correlati

Add Commitment Resource (QTNADDCR) APIRemove Commitment Resource (QTNRMVCR) APISend Journal Entry (QJOSJRNE) API

Risorse di cui è possibile eseguire il commit locali e remoteUna risorsa di cui è possibile eseguire il commit può essere una risorsa locale o una risorsa remota.

Risorsa locale di cui è possibile eseguire il commit

Una risorsa locale di cui è possibile eseguire il commit si trova sullo stesso sistema dell'applicazione.Ciascun giornale associato alle risorse sotto il controllo del commit può essere considerato comeun'ubicazione locale. Tutte le risorse registrate senza un giornale (facoltativamente sia per le risorse DDLsia per le risorse API) possono essere considerate come un'ubicazione locale separata.

Se una risorsa di cui è possibile eseguire il commit si trova in un lotto dischi indipendente e ladefinizione di commit si trova in un lotto dischi differente, la risorsa non viene considerata locale.

Risorse remote di cui è possibile eseguire il commit

Una risorsa remota di cui è possibile eseguire il commit si trova su un sistema differente rispettoall'applicazione. Esiste un'ubicazione remota per ciascuna conversazione univoca con un sistema remoto.Una definizione di commit potrebbe avere una o più ubicazioni remote su uno o più sistemi remoti.

Quando si pone una risorsa locale sotto il controllo del commit per il lotto dischi di sistema, o qualsiasilotto dischi indipendente, è necessario utilizzare DRDA (Distributed Relational Database Architecture) peraccedere alle risorse sotto il controllo del commit in qualsiasi altro lotto dischi indipendente.

La seguente tabella mostra i tipi di risorse di cui è possibile eseguire il commit e le loro ubicazioni.

Tipo di risorsa Ubicazione

API Locale

DDL Locale

DDM Remota

DRDA Locale o remota

FILE Locale

LU62 Remota

TCP Remota

Concetti correlati

“Controllo del commit e lotti dischi indipendenti” a pagina 22I lotti dischi indipendenti e i gruppi di lotti dischi indipendenti possono ognuno avere un database i5/OSseparato. È possibile utilizzare il controllo del commit con questi database.

Intento di accesso di una risorsa di cui è possibile eseguire il commitL'intento di accesso determina in che modo le risorse compartecipano a una transazione.


Quando una risorsa viene posta sotto il controllo del commit, il gestore risorsa indica come si accede allarisorsa:v Aggiornav Sola letturav Indeterminato

La seguente tabella mostra quali intenti di accesso sono possibili per uno specifico tipo di risorsa e in chemodo il sistema determina l'intento di accesso per una risorsa quando ne viene eseguita la registrazione.

Tipo di risorsa Possibili intenti di accessoCome viene determinato l'intento diaccesso

FILE Aggiorna, sola lettura In base al modo in cui è stato apertoil file

DDL Aggiorna Aggiorna sempre

API Aggiorna Aggiorna sempre

DDM Aggiorna, sola lettura In base al modo in cui è stato apertoil file

LU62 Indeterminato Sempre indeterminato

DRDA Aggiorna, sola lettura, indeterminato Per DRDA Livello 1, l'intento diaccesso è aggiorna se non sonoregistrate altre risorse remote.Altrimenti l'intento di accesso è solalettura. Per DRDA Livello 2, l'intentodi accesso è sempre indeterminato.

TCP Indeterminato Sempre indeterminato

L'intento di accesso delle risorse che sono già registrate determina se è possibile registrare una nuovarisorsa. Si applicano le seguenti regole:v Una risorsa in una fase il cui intento di accesso è aggiorna non può essere registrata quando ricorre

una qualsiasi delle seguenti condizioni:– Le risorse il cui intento di accesso è aggiorna sono già registrate su altre ubicazioni.– Le risorse il cui intento di accesso è indeterminato sono già registrate su altre ubicazioni.– Le risorse il cui intento di accesso è indeterminato sono già registrate sulla stessa ubicazione e le

risorse sono state modificate durante la transazione corrente.v Una risorsa in due fasi il cui intento di accesso è aggiorna non può essere registrata quando una risorsa

in una fase il cui intento di accesso è aggiorna è già registrata.

Protocollo di commit di una risorsa di cui è possibile eseguire il commitIl protocollo di commit è la capacità che ha una risorsa di partecipare a un'elaborazione di commit in unafase o in due fasi. Le risorse locali, fatta eccezione per le risorse di cui è possibile eseguire il commit API,sono sempre delle risorse in due fasi.

Se una risorsa di cui è possibile eseguire il commit si trova in un lotto dischi indipendente e ladefinizione di commit si trova in un lotto dischi differente, la risorsa non viene considerata come unarisorsa locale o una risorsa in due fasi.

Una risorsa in due fasi è detta anche risorsa protetta. Le risorse remote e le risorse di cui è possibileeseguire il commit API devono essere registrate come risorse in una fase o come risorse in due fasiquando vengono poste sotto il controllo del commit. La seguente tabella mostra quali tipi di risorse di cuiè possibile eseguire il commit possono coesistere in una definizione di commit con una risorsa in unafase.


Tipo di risorsa Può coesistere con

Risorsa API in una fase Altre risorse locali. Nessuna risorsa remota.

Risorsa remota in una fase Altre risorse in una fase nella stessa ubicazione. Nessunarisorsa locale.

Concetti correlati

“Controllo del commit e lotti dischi indipendenti” a pagina 22I lotti dischi indipendenti e i gruppi di lotti dischi indipendenti possono ognuno avere un database i5/OSseparato. È possibile utilizzare il controllo del commit con questi database.

File registrati su giornale e controllo del commitÈ necessario registrare su giornale (registrazione) un file di database (tipo di risorsa FILE o DDM) primache possa essere aperto per l'emissione sotto il controllo del commit o prima che un'applicazione SQL,che utilizza un livello di isolamento diverso da *NONE (nessun commit), possa fare riferimento a essa.Un file non deve necessariamente essere registrato su giornale per aprirlo per operazioni limitateall'immissione sotto il controllo del commit.

Viene notificato un errore se si verifica una delle seguenti condizioni:v È stato effettuato un tentativo di aprire un file di database per l'emissione sotto il controllo del commit

ma il file non è attualmente registrato su giornale.v Non è avviata alcuna definizione di commit che può essere utilizzata dal file aperto sotto il controllo

del commit.

Se si stanno registrando su giornale solo le immagini-successive per un file di database aperto sotto ilcontrollo del commit, il sistema avvia automaticamente la registrazione su giornale sia per leimmagini-precedenti sia per le immagini-successive. Le immagini-precedenti vengono scritte solo per lemodifiche al file che si verificano sotto il controllo del commit. Se contemporaneamente vengonoapportate al file delle altre modifiche che non sono sotto il controllo del commit, per esse vengono scrittesolo le immagini-successive.

Il sistema scrive automaticamente le modifiche di cui è possibile eseguire il commit a livello di record e lemodifiche di cui è possibile eseguire il commit a livello di oggetto in un giornale. Per le modifiche alivello di record, il sistema utilizza quindi le voci di giornale, se necessario, per scopi di ripristino; ilsistema non utilizza le voci per le modifiche di cui è possibile eseguire il commit a livello di oggetto perscopi di ripristino. Inoltre, il sistema non scrive automaticamente le voci di giornale per le risorse dicommit API. Tuttavia, il programma di uscita per la risorsa API può utilizzare l'API QJOSJRNE (Inviovoce di giornale) per scrivere le voci di giornale per fornire una traccia di controllo o per essere di ausilionel ripristino. Il contenuto di queste voci è controllato dal programma di uscita utente.

Per eseguire il ripristino per le risorse di commit a livello di oggetto, il sistema utilizza un'altra tecnica,non il giornale. Il ripristino per le risorse di commit API viene eseguito richiamando il programma diuscita di commit e rollback associato a ogni specifica risorsa di commit API. È responsabilità delprogramma di uscita eseguire l'effettivo ripristino necessario per la situazione.Concetti correlati

Journal management

Sequenza di voci di giornale sotto il controllo del commitQuesta tabella mostra la sequenza di voci di norma scritte mentre è attiva una definizione di commit. Èpossibile utilizzare il programma di ricerca delle informazioni sulle voci del giornale per ottenere ulterioriinformazioni sul contenuto delle voci di giornale.

Le voci di controllo del commit vengono scritte in un giornale locale se ricorre almeno una delle seguenticondizioni:v Il giornale è specificato come giornale predefinito nel comando STRCMTCTL (Avvio controllo commit).


v Almeno un file registrato su giornale è aperto sotto il controllo del commit.v Almeno una risorsa di commit API associata al giornale è registrata sotto il controllo del commit.

Tipo di voce Descrizione Dove è scritta Quando è scritta

C BC Avvio del controllo delcommit

Nel giornale predefinito, sene è specificata una nelcomando STRCMTCTL.

Quando viene utilizzato ilcomando STRCMTCTL.

Nel giornale. Quando il primo fileregistrato su un giornaleviene aperto o quando unarisorsa API viene registrataper un giornale.

C SC Avvio del ciclo di commit Nel giornale. Quando si verifica la primamodifica di record per latransazione per un fileregistrato su questogiornale1.

Nel giornale per unarisorsa API.

Quando l'API QJOSJRNEviene utilizzata per laprima volta con la chiave diinclusione dell'identificativo diciclo di commit.

Codici giornale D ed F Voci a livello di oggettoDDL

Nel giornale associatoall'oggetto di cui si staeseguendo l'aggiornamento.Solo le voci di giornale checontengono unidentificativo di ciclo dicommit rappresentano unamodifica a livello dioggetto DDL che fa partedella transazione.

Quando si verificano degliaggiornamenti.

Codice giornale R Voci a livello di record Nel giornale associato alfile di cui si sta eseguendol'aggiornamento.

Quando si verificano gliaggiornamenti.

Codice giornale U Voci create dall'utente Nel giornale associato auna risorsa API.

Quando l'API QJOSJRNEviene utilizzata per laprima volta con la chiave diinclusione dell'identificativo diciclo di commit.

C CM Commit Nel giornale. Dopo che il commit è statocompletato correttamente.

Nel giornale predefinito. Se delle risorse di cui èpossibile eseguire il commitsono associate al giornale.

C RB Rollback Nel giornale. Dopo che l'operazione dirollback è stata completata.

Nel giornale predefinito. Se delle risorse di cui èpossibile eseguire il commitsono associate al giornale.



C LW Termine della transazione Nel giornale predefinito, sene è specificata una nelcomando STRCMTCTL. Ilsistema scrive un record diintestazione LW e uno opiù record di dettaglio.Queste voci vengono scrittesolo se OMTJRNE(*NONE)viene specificato nelcomando STRCMTCTL o sesi verifica un errore disistema.

Dopo che l'operazione dicommit o di rollback è statacompletata.

C EC Termine del controllo delcommit

Nel giornale. Dopo che il comandoENDCMTCTL (Finecontrollo commit) è statocompletato.

In un giornale locale chenon è il giornalepredefinito.

Quando viene stabilito unlimite di commit, dopo ilpunto in cui tutte le risorsedi cui è possibile eseguire ilcommit associate a talegiornale sono state rimossedal controllo del commit.

C SB Avvio di punto disalvataggio o ciclo dicommit nidificato.

Nel giornale. Quando l'applicazione creaun SQL SAVEPOINT oquando il sistema crea unciclo di commit nidificatointerno per gestire una seriedi funzioni database comeuna singola operazione2.

C SQ Rilascio del punto disalvataggio o esecuzionedel commit del ciclo dicommit nidificato.

Nel giornale. Quando l'applicazionerilascia un SQLSAVEPOINT o quando ilsistema esegue il commit diun ciclo di commitnidificato internamente2.

C SU Rollback del punto disalvataggio o del ciclo dicommit nidificato.

Nel giornale. Quando l'applicazioneesegue il rollback di unSQL SAVEPOINT o quandoil sistema esegue il rollbackdi un ciclo di commitnidificato internamente2.



Note:

1 È possibile specificare che la parte a lunghezza fissa della voce di giornale includa le informazioni sullatransazione specificando il valore *LUW (relativo all'unità di lavoro logica) per il parametro FIXLENDTA (relativo aidati a lunghezza fissa) del comando CRTJRN (Creazione giornale) o CHGJRN (Modifica giornale). Specificando ilparametro FIXLENDTA (*LUW), la parte a lunghezza fissa di ciascuna voce di giornale C SC conterrà il LUWID(Logical Unit of Work ID, ossia l'ID unità di lavoro logica) della transazione corrente. Allo stesso modo, per letransazioni XA, se si specifica il parametro FIXLENDTA (*XID), la parte a lunghezza fissa di ciascuna voce digiornale C SC conterrà l'XID della transazione corrente. Il LUWID o l'XID possono essere di ausilio nel trovare tuttii cicli di commit per una specifica transazione se la transazione coinvolge più giornali o sistemi.

2 Queste voci vengono inviate solo se si imposta la variabile di ambiente QTN_JRNSAVPT_MYLIB_MYJRN su *YES,dove MYJRN è il giornale che si sta utilizzando e MYLIB è la libreria in cui è memorizzato il giornale. Il valorespeciale *ALL è supportato per i valori MYLIB e MYJRN. È possibile impostare queste variabili a livello dell'interosistema oppure per uno specifico lavoro. Per fare in modo che le voci vengano inviate per il giornaleMYLIB/MYJRN per un solo lavoro, utilizzare questo comando in tale lavoro:

v ADDENVVAR ENVVAR(QTN_JRNSAVPT_MYLIB_MYJRN) VALUE(*YES)

Per fare in modo che le voci vengano inviate per tutti i giornali per tutti i lavori, utilizzare questo comando:

v ADDENVVAR ENVVAR('QTN_JRNSAVPT_*ALL_*ALL') VALUE(*YES) LEVEL(*SYS)

Il valore di questa variabile di ambiente viene memorizzato in cache internamente per ogni definizione di commit laprima volta che una risorsa correlata a uno specifico giornale viene posta sotto il controllo del commit. Se lavariabile di ambiente viene modificata dopo tale punto, il valore memorizzato nella cache deve essere aggiornatoperché diventi effettivo per tale giornale. Qualsiasi chiamata dell'API di richiamo di informazioni di commitQTNRCMTI aggiorna il valore memorizzato nella cache nel lavoro chiamante.

Concetti correlati

“Operazione di commit” a pagina 3Un'operazione di commit rende permanenti tutte le modifiche eseguite sotto il controllo del commit dopola precedente operazione di commit o rollback. Il sistema rilascia anche tutti i blocchi correlati allatransazione.Journal entry information finderRiferimenti correlati

End Commitment Control (ENDCMTCTL) command

Identificativo di ciclo di commitUn ciclo di commit è il tempo che intercorre tra un limite di commit e il successivo. Il sistema assegna unidentificativo di ciclo di commit per associare tra di loro tutte le voci di giornale per uno specifico ciclo dicommit. Ciascun giornale che partecipa a una transazione ha un proprio ciclo di commit e un proprioidentificativo di ciclo di commit.

L'identificativo di ciclo di commit è il numero di sequenza del giornale della voce di giornale C SC scrittaper il ciclo di commit. L'identificativo di ciclo di commit viene inserito in ciascuna voce di giornale scrittadurante il ciclo di commit. Se viene utilizzato più di un giornale durante il ciclo di commit,l'identificativo di ciclo di commit per ciascun giornale è differente.

È possibile specificare che la parte a lunghezza fissa della voce di giornale includa le informazioni sullatransazione specificando il valore *LUW (relativo all'unità di lavoro logica) per il parametro FIXLENDTA(relativo ai dati a lunghezza fissa) del comando CRTJRN (Creazione giornale) o CHGJRN (Modificagiornale). Specificando il parametro FIXLENDTA (*LUW), la parte a lunghezza fissa di ciascuna voce digiornale C SC conterrà il LUWID (Logical Unit of Work ID, ossia l'ID unità di lavoro logica) dellatransazione corrente. Allo stesso modo, per le transazioni XA, se si specifica il parametro FIXLENDTA(*XID), la parte a lunghezza fissa di ciascuna voce di giornale C SC conterrà l'XID della transazione


|||||

corrente. Il LUWID o l'XID possono essere di ausilio nel trovare tutti i cicli di commit per una specificatransazione se la transazione coinvolge più giornali o sistemi.

È possibile utilizzare l'API QJOSJRNE (Invio voce di giornale) per scrivere le voci di giornale per lerisorse API. Si dispone dell'opzione di includere l'identificativo di ciclo di commit in queste voci digiornale.

È possibile utilizzare l'identificativo di ciclo di commit per applicare/eliminare modifiche registrate sugiornale a/da un limite di commit utilizzando il comando APYJRNCHG (Applicazione modifichegiornale) oppure il comando RMVJRNCHG (Eliminazione modifiche giornale). Si applicano le seguentilimitazioni:v La maggior parte delle modifiche a livello di oggetto eseguite sotto il controllo del commit sono scritte

nel giornale ma non sono applicate o eliminate utilizzando i comandi APYJRNCHG e RMVJRNCHG.v L'API QJOSJRNE scrive le voci di giornale create dall'utente con un codice giornale di U. Queste voci

non possono essere applicate o eliminate utilizzando i comandi APYJRNCHG e RMVJRNCHG. Devonoessere applicate o eliminate con un programma scritto dall'utente.

Blocco di recordQuando un lavoro detiene un blocco del record e un altro lavoro prova a richiamare tale record perl'aggiornamento, il lavoro richiedente attende e viene rimosso dall'elaborazione attiva.

Il lavoro richiedente sarà inattivo finché non si verifica uno dei seguenti eventi:v Il blocco del record viene rilasciato.v Il tempo di attesa specificato termina.

Più di un lavoro può richiedere un record bloccato da un altro lavoro. Quando il blocco del record vienerilasciato, il record viene ricevuto dal primo lavoro che lo richiede. Quando si attende un record bloccato,specificare il tempo di attesa nel parametro WAITRCD nei seguenti comandi di creazione, modifica osostituzione:v CRTPF (Creazione file fisico)v CRTLF (Creazione file logico)v CRTSRCPF (Creazione file fisico origine)v CHGPF (Modifica file fisico)v CHGLF (Modifica file logico)v CHGSRCPF (Modifica file fisico origine)v OVRDBF (Sostituzione file di database)

Quando si specifica il tempo di attesa, considerare le seguenti informazioni:v Se non si specifica un valore, il programma attende per il tempo di attesa predefinito per il processo.v Per le definizioni di commit che hanno solo blocchi nell'ambito della transazione, il tempo di attesa

predefinito del lavoro può essere sovrascritto da un tempo di attesa di blocco della transazione che puòessere specificato:– Nell'API xa_open.– In un'interfaccia JDBC o JTA. Le transazioni distribuite elencano queste API.

v Se il record non può essere assegnato entro il tempo specificato, viene inviato un messaggio di notificaal programma HLL (high-level language).

v Se il tempo di attesa per un record viene superato, il messaggio inviato alla registrazione lavorofornisce il nome del lavoro che detiene il record bloccato che ha causato l'attesa per il lavororichiedente. Se si verificano delle eccezioni di blocco del record, è possibile utilizzare la registrazionelavoro come ausilio nel determinare quali programmi modificare in modo che non detengano deiblocchi per lunghi periodi.


I programmi detengono dei blocchi di record per lunghi periodi per uno dei seguenti motivi:v Il record rimane bloccato mentre l'utente della stazione di lavoro sta considerando una modifica.v Il blocco del record fa parte di una lunga transazione di commit. Considerare l'esecuzione di

transazioni più piccole per consentire un'esecuzione più frequente di un'operazione di commit.v Si è verificato un blocco indesiderato. Si presuma, ad esempio, che un file è definito come un file di

aggiornamento con delle chiavi univoche e che il programma aggiorni e aggiunga ulteriori record alfile. Se l'utente della stazione di lavoro desidera aggiungere un record al file, il programma potrebbeprovare ad accedere al record per determinare se la chiave esiste già. In questo caso, il programmainforma l'utente della stazione di lavoro che la richiesta eseguita non è valida. Quando il record vienerichiamato dal file, esso viene bloccato finché non viene rilasciato in modo implicito da un'altraoperazione di lettura sullo stesso file o finché non viene rilasciato esplicitamente.

Nota: per ulteriori informazioni su come utilizzare l'interfaccia HLL (high-level language) per rilasciarei blocchi del record, consultare l'appropriato manuale di riferimento HLL (high-level language).Le informazioni correlate per il controllo del commit hanno dei collegamenti ai manuali HLL(high-level language) che è possibile utilizzare con il controllo del commit.

La durata del blocco è molto più lunga se viene specificato LCKLVL(*ALL) perché il record che erastato richiamato dal file viene bloccato finché non si verifica la successiva operazione di commit o dirollback. Non viene rilasciato in modo implicito da un'altra operazione di lettura e non può essererilasciato in modo esplicito.

Un'altra funzione che può mettere un blocco su un file è la funzione di salvataggio durante l'utilizzo.Concetti correlati

Transazioni distribuite JDBCFunzione salva-mentre-attivoRiferimenti correlati

“Informazioni correlate per il controllo del commit” a pagina 120I manuali dei prodotti, le pubblicazioni IBM Redbooks, i siti Web e altre raccolte di argomentidell'information center contengono informazioni correlate alla raccolta di argomenti Controllo del commit.È possibile visualizzare o stampare qualsiasi file PDF.

Controllo del commit e lotti dischi indipendentiI lotti dischi indipendenti e i gruppi di lotti dischi indipendenti possono ognuno avere un database i5/OSseparato. È possibile utilizzare il controllo del commit con questi database.

Tuttavia, poiché ogni lotto dischi indipendente o gruppo di lotti dischi indipendente ha un database SQLseparato, occorre tener presente alcune considerazioni.Concetti correlati

“Definizione di commit” a pagina 5La definizione di commit contiene informazioni pertinenti alle risorse di cui è in corso la modifica sotto ilcontrollo del commit durante una transazione.“Risorse di cui è possibile eseguire il commit locali e remote” a pagina 15Una risorsa di cui è possibile eseguire il commit può essere una risorsa locale o una risorsa remota.“Protocollo di commit di una risorsa di cui è possibile eseguire il commit” a pagina 16Il protocollo di commit è la capacità che ha una risorsa di partecipare a un'elaborazione di commit in unafase o in due fasi. Le risorse locali, fatta eccezione per le risorse di cui è possibile eseguire il commit API,sono sempre delle risorse in due fasi.

Considerazioni sui lotti dischi indipendenti per le definizioni di commitQuando si utilizzano i lotti dischi indipendenti, è necessario tenere presenti le seguenti considerazioni perle definizioni di commit.


Considerazioni sulla libreria QRECOVERY

Quando si avvia il controllo del commit, la definizione di commit viene creata nella libreriaQRECOVERY. Ogni lotto dischi indipendente o gruppo di lotti dischi indipendenti ha la propria versionedi una libreria QRECOVERY. Su un lotto dischi indipendente, il nome della libreria QRECOVERY èQRCYxxxxx, dove xxxxx è il numero del lotto dischi indipendente. Ad esempio, il nome della libreriaQRECOVERY per il lotto dischi indipendente 39 è QRCY00039. Inoltre, se il lotto dischi indipendente faparte di un gruppo di lotti dischi, solo il lotto dischi primario ha una libreria QRCYxxxxx.

Quando si avvia il controllo del commit, la definizione di commit viene creata nella libreria QRECOVERYdel lotto dischi indipendente associato a tale lavoro, rendendo il controllo del commit attivo sul lottodischi indipendente.

Considerazioni su Impostazione gruppo ASP

Utilizzare il comando SETASPGRP (Impostazione gruppo ASP) mentre il controllo del commit è attivo suun lotto dischi indipendente ha i seguenti effetti:v Se si passa da un lotto dischi indipendente a un altro e le risorse sono registrate con il controllo del

commit sul lotto dischi, il comando SETASPGRP ha esito negativo con il messaggio CPDB8EC, codiceerrore 2, Nel sottoprocesso è presente una transazione non sottoposta a commit. Questomessaggio è seguito dal messaggio CPFB8E9.

v Se si passa da un lotto dischi indipendente a un altro e nessuna risorsa è registrata con il controllo delcommit, le definizioni di commit vengono spostate al lotto dischi indipendente cui si sta passando.

v Se si passa dal lotto dischi di sistema (gruppo ASP *NONE) a un altro, il controllo del commit rimaneinvariato. Le definizioni di commit restano sul lotto dischi di sistema. Se, successivamente, siposizionano le risorse del lotto dischi indipendente sotto il controllo del commit prima delle risorse dellotto dischi di sistema, la definizione di commit viene spostata al lotto dischi indipendente.

v Se si utilizza un oggetto di notifica, l'oggetto di notifica deve trovarsi sullo stesso lotto dischiindipendente o gruppo di lotti dischi indipendenti della definizione di commit.

v Se si sposta la definizione di commit in un altro lotto dischi indipendente o gruppo di lotti dischiindipendenti, anche l'oggetto di notifica deve trovarsi sull'altro lotto dischi indipendente o gruppo dilotti dischi indipendenti. L'oggetto di notifica sull'altro lotto dischi indipendente o gruppo di lottidischi indipendenti viene aggiornato se si verifica una fine anomala della definizione di commit. Sel'oggetto di notifica non viene trovato sull'altro lotto dischi indipendente o gruppo di lotti dischiindipendenti, l'aggiornamento ha esito negativo con il messaggio CPF8358.

Lo spazio nome corrente del lavoro determina qual è l'IASP (Independent ASP) in cui viene creata ladefinizione di commit. Se il lavoro non è associato a un IASP (Independent ASP), la definizione dicommit viene creata in *SYSBAS, altrimenti viene creata nell'IASP (Independent ASP). Se il lavoro èassociato a un IASP (Independent ASP), è possibile aprire i file sotto il controllo del commit che sitrovano nello spazio nome libreria corrente; possono trovarsi, ad esempio, nell'IASP (Independent ASP) oin *SYSBAS. Se la prima risorsa posta sotto il controllo del commit non si trova nello stesso ASP delladefinizione di commit, la definizione di commit viene spostata all'ASP della risorsa. Se sia la risorsa*SYSBAS sia la risorsa IASP (Independent ASP) sono registrate nella stessa definizione di commit, ilsistema utilizza implicitamente un protocollo di commit in due fasi per assicurare che le risorse venganosottoposte a commit in modo atomico (indivisibile) se si verifica un malfunzionamento del sistema.Pertanto, le transazioni che comportano dei dati sia in *SYSBAS sia in un IASP (Independent ASP)avranno prestazioni inferiori alle transazioni isolate a un singolo gruppo ASP.

Considerazioni sul giornale predefinito

Sono da notare le seguenti considerazioni sul giornale predefinito:v Se si utilizza il giornale predefinito, il giornale deve trovarsi sullo stesso lotto dischi indipendente o

gruppo di lotti dischi indipendenti della definizione di commit.


|||

|||||||||||

v Se il giornale predefinito non viene trovato sull'altro lotto dischi indipendente o gruppo di lotti dischiindipendenti quando viene avviato il controllo del commit, l'avvio del controllo del commit ha esitonegativo con il messaggio CPF9873.

v Se si sposta la definizione di commit in un altro lotto dischi indipendente o gruppo di lotti dischiindipendenti, anche il giornale predefinito deve trovarsi sull'altro lotto dischi indipendente o gruppo dilotti dischi indipendenti. Se il giornale non viene trovato sull'altro lotto dischi indipendente o gruppodi lotti dischi indipendenti, la definizione di commit viene spostata ma, da questo punto in poi, nonviene utilizzato alcun giornale predefinito.

Considerazioni su IPL (initial program load) e disattivazione

Sono da notare le seguenti considerazioni su IPL e disattivazione:v Il ripristino di definizioni di commit che si trovano su un lotto dischi indipendente viene eseguito

durante l'elaborazione di attivazione del lotto dischi indipendente ed è simile al ripristino IPL.v Le definizioni di commit in un lotto dischi indipendente non vengono ripristinate durante l'IPL di

sistema.v Quando è richiesto il ripristino per una definizione di commit che contiene risorse che si trovano sia in

*SYSBAS sia in un IASP (Independent ASP), la definizione di commit verrà divisa in due definizioni dicommit durante il ripristino, una in *SYSBAS e una nell'IASP (Independent ASP), come se esistesse unaconnessione a un database remoto tra i due gruppi ASP. La risincronizzazione può essere iniziata dalsistema durante il ripristino per assicurare che i dati in entrambi i gruppi ASP siano sottoposti acommit o a rollback in modo atomico (indivisibile).

v La disattivazione di un lotto dischi indipendente ha i seguenti effetti sulle definizioni di commit:– I lavori associati al lotto dischi indipendente terminano.– Non è consentita la creazione di alcuna nuova definizione di commit sul lotto dischi indipendente.– Le definizioni di commit che si trovano sul lotto dischi indipendente diventano inutilizzabili.– Le definizioni che si trovano sul lotto dischi indipendente, ma non collegate a un lavoro, rilasciano i

blocchi nell'ambito della transazione.

Considerazioni sui database remoti

Sono da notare le seguenti considerazioni sui database remoti:v Non è possibile utilizzare una connessione SNA LU 6.2 (conversazioni protette o DUW (Distributed

Unit of Work - unità di lavoro distribuita) per stabilire una connessione a un database remoto da undatabase di lotto dischi indipendente. È possibile utilizzare le conversazioni SNA non protette perstabilire una connessione da un database di lotto dischi indipendente a un database remoto.

v Quando il controllo del commit è attivo per un lavoro o un sottoprocesso, l'accesso ai datiesternamente al lotto dischi indipendente o al gruppo di lotti dischi cui appartiene la definizione dicommit è possibile solo in remoto, come se fossero dati che si trovano su un altro sistema. Quando siemette un'istruzione SQL CONNECT per stabilire una connessione al database relazionale (RDB) sullotto dischi indipendente, il sistema rende remota la connessione.

v Il lotto dischi di sistema e i lotti dischi di base non richiedono una connessione remota per l'accesso insola lettura ai dati che si trovano su un lotto dischi indipendente. In modo analogo, un lotto dischiindipendente non richiede una connessione remota per l'accesso in sola lettura ai dati che si trovanosul lotto dischi di sistema o su un lotto dischi di base.


||||||

Concetti correlati

“Definizione di commit” a pagina 5La definizione di commit contiene informazioni pertinenti alle risorse di cui è in corso la modifica sotto ilcontrollo del commit durante una transazione.“Oggetto di notifica del commit” a pagina 53Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioniche identificano l'ultima transazione eseguita correttamente completata per una specifica definizione dicommit se tale definizione di commit non è stata terminata normalmente.“Ripristino del controllo del commit durante l'IPL (initial program load) dopo la fine anomala” a pagina67Quando si esegue un IPL (initial program load) dopo la fine anomala del sistema, il sistema prova aripristinare tutte le definizioni di commit che erano attive quando il sistema è stato terminato.

Considerazioni per le transazioni XANell'ambiente XA, ciascun database viene considerato un gestore risorsa separato. Quando un gestoretransazioni desidera accedere a due database sotto la stessa transazione, deve utilizzare i protocolli XAper eseguire un commit in due fasi con i due gestori risorse.

Poiché ciascun lotto dischi indipendente è un database SQL separato, nell'ambiente XA ciascun lottodischi indipendente viene considerato anche un gestore risorsa separato. Per consentire al server delleapplicazioni di eseguire una transazione destinata a due lotti dischi indipendenti differenti, il gestoretransazioni deve utilizzare anche un protocollo di commit in due fasi.Concetti correlati

“Supporto delle transazioni XA per il controllo del commit” a pagina 46DB2 for i può partecipare nelle transazioni globali X/Open.Independent disk pool examples

Considerazioni e limitazioni per il controllo del commitÈ necessario tenere presente le seguenti considerazioni e limitazioni per il controllo del commit.

Considerazioni sul file di databasev Se si specifica che un file condiviso venga aperto sotto il controllo del commit, tutti i successivi utilizzi

di tale file devono essere aperti sotto il controllo del commit.v Se SEQONLY(*YES) viene specificato per il file aperto per la sola lettura con LCKLVL(*ALL)

(implicitamente o tramite un programma HLL (high-level language) oppure esplicitamente tramite ilcomando OVRDBF (Sostituzione con file database)), SEQONLY(*YES) viene ignorato e viene utilizzatoSEQONLY(*NO).

v Le modifiche a livello di record apportate sotto il controllo del commit vengono registrate in ungiornale. Queste modifiche possono essere applicate al, o eliminate dal, database con il comandoAPYJRNCHG (Applicazione modifiche giornale) oppure il comando RMVJRNCHG (Eliminazionemodifiche giornale).

v Sia le immagini-precedenti sia le immagini-successive dei file vengono registrate sul giornale sotto ilcontrollo del commit. Se si specifica di registrare sul giornale solo le immagini-successive dei file, ilsistema registra sul giornale automaticamente anche l'immagine-precedente delle modifiche al file chesi sono verificate sotto il controllo del commit. Tuttavia, poiché le immagini-precedenti non vengonocatturate per tutte le modifiche apportate ai file, non è possibile utilizzare il comando RMVJRNCHGper questi file.

Considerazioni per le modifiche a livello di oggetto e a livello di recordv Le modifiche a livello di oggetto e a livello di record eseguite sotto il controllo del commit utilizzando

SQL utilizzano la definizione di commit attualmente attiva per il gruppo di attivazione in cui è in


esecuzione il programma richiedente. Se non è attiva né la definizione di commit a livello di lavoro néquella a livello di gruppo di attivazione, SQL avvierà una definizione di commit a livello di gruppo diattivazione.

Considerazioni sul commit in una fase e in due fasiv Mentre è stabilita una connessione o una conversazione remota in una fase, le connessioni o le

conversazioni remote ad altre ubicazioni non sono consentite. Se è stabilito un limite di commit evengono eliminate tutte le risorse, l'ubicazione può essere modificata.

v Se si sta utilizzando il commit in due fasi, non è necessario utilizzare il comando SBMRMTCMD(Immissione comando remoto) per avviare il controllo del commit o eseguire eventuali altre operazionidi controllo del commit sulle ubicazioni remote. Il sistema esegue queste funzioni per conto dell'utente.

v Per un'ubicazione remota in una fase, i comandi CL COMMIT e ROLLBACK avranno esito negativo seSQL si trova nello stack di chiamata e il database relazionale remoto non si trova su un sistema. SeSQL non si trova nello stack di chiamata, i comandi COMMIT e ROLLBACK non avranno esitonegativo.

v Per un'ubicazione remota in una fase, il controllo del commit deve essere avviato sul sistema di origineprima di apportare delle modifiche di cui è possibile eseguire il commit alle risorse remote. Il sistemaavvia automaticamente il controllo del commit per l'SQL di database distribuito sul sistema di originein fase di connessione se il programma SQL è in esecuzione con l'opzione di controllo del commitimpostata su un valore diverso da *NONE. Quando la prima risorsa remota viene posta sotto ilcontrollo del commit, il sistema avvia il controllo del commit sul sistema di destinazione.

Considerazione sul salvataggio

Un'operazione di salvataggio non è consentita se il lavoro che esegue il salvataggio ha una o piùdefinizioni di commit attive con uno qualsiasi dei seguenti tipi di modifiche di cui è possibile eseguire ilcommit:v Una modifica di record a un file che si trova nella libreria di cui si sta eseguendo il salvataggio. Per i

file logici, vengono controllati tutti i file fisici correlati.v Qualsiasi modifica a livello di oggetto in una libreria di cui si sta eseguendo il salvataggio.v Qualsiasi risorsa API che è stata aggiunta utilizzando l'API QTNADDCR (Aggiunta risorsa di commit)

e con il campo che indica che è consentita la normale elaborazione di salvataggio impostato sul valorepredefinito di N.

Questo impedisce alle operazioni di salvataggio di salvare sul supporto di salvataggio le modifichedovute a una transazione parziale.

Nota: se si utilizza il nuovo salvataggio con la funzione di transazioni parziali, l'oggetto può esseresalvato senza terminare una definizione di commit.

I blocchi di oggetti e i blocchi di record impediscono il salvataggio sul supporto di salvataggiodelle modifiche in sospeso dalle definizioni di commit in altri lavori. Questo è vero solo per lerisorse di commit API se i blocchi vengono acquisiti quando vengono apportate delle modificheall'oggetto o agli oggetti associati alla risorsa di commit API.

Considerazioni e limitazioni variev Prima di aggiornare il sistema a una nuova release, tutte le risincronizzazioni in sospeso devono essere

completate o annullate.v I valori COMMIT e ROLLBACK vengono visualizzati nel campo relativo alla funzione di WRKACTJOB

durante un commit o un rollback. Se tale funzione rimane COMMIT o ROLLBACK per molto tempo, èpossibile che si sia verificato uno dei seguenti eventi:– Un errore di risorsa durante il commit o il rollback richiede la risincronizzazione. Il controllo non

ritornerà all'applicazione finché la risincronizzazione non sarà stata completata o annullata.


– Questo sistema ha indicato la decisione VRO (vote read-only) durante il commit. Il controllo nonritornerà all'applicazione finché il sistema che ha iniziato il commit non avrà inviato i dati a questosistema.

– Questo sistema ha indicato che era OK tralasciare durante il commit. Il controllo non ritorneràall'applicazione finché il sistema che ha iniziato il commit non invierà i dati a questo sistema.

Concetti correlati

Assicurazione dell'integrità del commit in due fasi“Livello di blocco del commit” a pagina 55Il valore specificato per il parametro LCKLVL nel comando STRCMTCTL (Avvio controllo commit)diventa il livello predefinito di blocco di record per i file di database aperti e posti sotto il controllo delcommit per la definizione di commit.Riferimenti correlati

Override with Database File (OVRDBF) commandApply Journaled Changes (APYJRNCHG) commandRemove Journaled Changes (RMVJRNCHG) commandSQL programmingSubmit Remote Command (SBMRMTCMD) commandCommit (COMMIT) commandRollback (ROLLBACK) commandAdd Commitment Resource (QTNADDCR) API

Controllo del commit per le applicazioni batchLe applicazioni batch possono richiedere o meno il controllo del commit. In alcuni casi, un'applicazionebatch può eseguire una singola funzione di lettura di un file di immissione e di aggiornamento di un filemaster. Tuttavia, è possibile utilizzare il controllo del commit per questo tipo di applicazione se èimportante avviarla nuovamente dopo una fine anomala.

Il file di immissione è un file di aggiornamento con un codice nei record per indicare che è statoelaborato un record. Questo file e gli eventuali file aggiornati vengono posti sotto il controllo del commit.Quando è presente nel file di immissione, il codice rappresenta una transazione completata. Il programmalegge il file di immissione e tralascia i record con un codice di completato. Questo consente l'utilizzo dellastessa logica di programma per le condizioni normali e di riavvio.

Se l'applicazione batch contiene dei record di immissione interdipendenti e contiene commutazioni ototali, è possibile utilizzare un oggetto di notifica per fornire informazioni sul riavvio. I valori conservatinell'oggetto di notifica vengono utilizzati per riavviare l'elaborazione dall'ultima transazione di cui è statoeseguito il commit nel file di immissione.

Se i record di immissione sono interdipendenti, possono essere elaborati come una transazione. Un lavorobatch può bloccare un massimo di 500 000 000 record. È possibile ridurre questo limite utilizzando un filedelle opzioni query (QAQQINI). Utilizzare il parametro QRYOPTLIB del comando CHGQRYA (Modificaattributi query) per specificare un file delle opzioni query che può essere utilizzato da un lavoro.Utilizzare il valore COMMITMENT_CONTROL_LOCK_LEVEL nel file delle opzioni query come limite diblocco per il lavoro. Il valore del limite di blocco viene memorizzato internamente nella cache perciascuna definizione di commit la prima volta che una risorsa registrata su giornale viene posta sotto ilcontrollo del commit. Se il limite di blocco viene modificato dopo tale punto, il valore memorizzato nellacache deve essere aggiornato perché diventi effettivo per tale definizione di commit. Qualsiasi chiamatadell'API di richiamo di informazioni di commit QTNRCMTI aggiorna il valore memorizzato nella cachenel lavoro chiamante. Il nuovo valore non si applicherà alle transazioni avviate prima dell'aggiornamentodella cache.


||||||||||||

Eventuali cicli di commit che superano i 2000 blocchi probabilmente rallentano notevolmente leprestazioni del sistema. Altrimenti, si applicano le stesse considerazioni di blocco valide per leapplicazioni interattive ma il lasso di tempo per cui i record sono bloccati in un'applicazione batchpotrebbe essere meno importante che nelle applicazioni interattive.Concetti correlati

“Oggetto di notifica del commit” a pagina 53Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioniche identificano l'ultima transazione eseguita correttamente completata per una specifica definizione dicommit se tale definizione di commit non è stata terminata normalmente.“Gestione della dimensione della transazione” a pagina 75Un altro modo per ridurre al minimo i blocchi di record consiste nel gestire la dimensione dellatransazione.Riferimenti correlati

Change Query Attributes (CHGQRYA) command

Controllo del commit in due fasiIl controllo del commit in due fasi assicura che le risorse di cui è possibile eseguire il commit su piùsistemi rimangano sincronizzate.

Il sistema operativo i5/OS supporta il commit in due fasi in base all'architettura SNA LU 6.2. Perinformazioni più dettagliate sui protocolli interni utilizzati dal sistema per il commit in due fasi,consultare il manuale SNA Transaction Programmer's Reference for LU Type 6.2, GC30-3084-05. Tutte lerelease supportate del sistema operativo i5/OS supportano i protocolli Presumed Nothing di SNA LU 6.2e i protocolli Presumed Abort di SNA LU 6.2.

Il commit in due fasi è supportato anche utilizzando TCP/IP come una protocollo DUW (DistributedUnit of Work - unità di lavoro distribuita) DRDA (Distributed Relational Database Architecture). Perutilizzare le connessioni DUW TCP/IP, tutti i sistemi (sia il richiedente dell'applicazione che il serverdelle applicazioni) devono essere alla V5R1M0 o successive. Per ulteriori informazioni su DRDA,consultare l'Open Group Technical Standard, DRDA V2 Vol. 1: Distributed Relational Database Architecturesul sito Web di The Open Group.

Sotto il commit in due fasi, il sistema esegue l'operazione di commit in due fasi:v Durante la fase di preparazione, un gestore risorse emette una richiesta di commit al suo gestore

transazioni. Il gestore transazioni informa le altre risorse che gestisce e gli altri gestori transazioni chela transazione è pronta per essere sottoposta a commit. Tutti i gestori risorse devono rispondere chesono pronti ad eseguire il commit. Questa è detta decisione.

v Durante la fase di commit, il gestore transazioni che inizia la richiesta di commit decide cosa fare, inbase all'esito della fase di preparazione. Se la fase di preparazione viene completata correttamente etutti i partecipanti decidono che sono pronti, il gestore transazioni può indicare a tutte le risorse chegestisce a agli altri gestori transazioni di eseguire il commit della transazione. Se la fase dipreparazione non viene completata correttamente, a tutti i gestori transazioni e a tutti i gestori risorseviene indicato di eseguire il rollback della transazione.

Operazioni di commit e rollback con le risorse remote

Quando le risorse remote sono sotto il controllo del commit, l'iniziatore invia una richiesta di commit atutti gli agent remoti. La richiesta viene inviata in tutta la rete del programma di transazione. Ciascunagent risponde con i risultati dell'operazione di commit.

Se si verificano degli errori durante la fase di preparazione, l'iniziatore invia una richiesta di rollback atutti gli agent. Se si verificano degli errori durante la fase di commit, il sistema prova a portare il maggior


numero di ubicazioni possibile allo stato di sottoposto a commit. Questi tentativi potrebbero determinareuno stato misto euristico. Consultare la sezione Stati della transazione per il controllo del commit in duefasi per ulteriori informazioni sugli stati possibili.

Eventuali errori vengono restituiti all'iniziatore dove vengono segnalati all'utente. Se è stato specificato ungiornale predefinito nel comando STRCMTCTL (Avvio controllo commit), vengono scritte le voci C LW.Se si verificano degli errori, queste voci vengono scritte anche se è stato specificato OMTJRNE(*LUWID).È possibile utilizzare queste voci, insieme ai messaggi di errore e alle informazioni sullo stato per ladefinizione di commit, per provare a sincronizzare manualmente le risorse di cui è possibile eseguire ilcommit.

Quando le risorse remote sono sotto il controllo del commit, l'iniziatore invia una richiesta di rollback atutti gli agent remoti. La richiesta viene inviata in tutta la rete del programma di transazione. Ciascunagent risponde con i risultati dell'operazione di rollback.Concetti correlati

The Open Group Web siteRiferimenti correlati

Start Commitment Control (STRCMTCTL) command

Ruoli nell'elaborazione di commitSe un commit di una transazione interessa più di un gestore risorse, ciascun gestore risorse ha un ruolonella transazione. Un gestore risorse è responsabile per il commit o il rollback delle modifiche apportatedurante la transazione.

I gestori risorse per tipo di risorsa sono i seguenti:

FILE Database manager

DDM Database manager

DDL Database manager

DRDAProgramma di transazioni relative alle comunicazioni

LU62 Programma di transazioni relative alle comunicazioni

API Programma di uscita API

Le seguenti figure mostrano i ruoli di base in una transazione. La struttura mostrata nelle figure è dettarete programma di transazione. La struttura può trovarsi in un albero a livello singolo e in un albero a piùlivelli.

Ruoli nell'elaborazione di commit in due fasi: albero a livello singolo

Quando un'applicazione sul Sistema A emette una richiesta di commit, il gestore risorse sul Sistema Adiventa l'iniziatore. Per l'unità di lavoro distribuita DRDA (Distributed Relational Database Architecture)su TCP/IP, l'iniziatore viene detto coordinatore.

I gestori risorse per gli altri tre sistemi (B, C e D) diventano agent per questa transazione. Per l'unità dilavoro distribuita DRDA su TCP/IP, gli agent sono a volte detti partecipanti.


http://www.opengroup.org/

Ruoli nell'elaborazione di commit in due fasi: albero a più livelli

Se l'applicazione sta utilizzando le comunicazioni APPC per eseguire il commit in due fasi, la relazionetra i sistemi può cambiare da una transazione alla successiva. La seguente figura mostra gli stessi sistemiquando un'applicazione sul Sistema B emette la richiesta di commit. Questa configurazione è un albero apiù livelli.

I ruoli in questa figura non sono validi per l'unità di lavoro distribuita DRDA su TCP/IP perché gli alberidi transazioni a più livelli non sono supportati.


La rete del programma di transazione ha un altro livello perché il Sistema B non sta comunicandodirettamente con il Sistema C e il Sistema D. Il gestore risorse nel Sistema A ora ha i ruoli di agent einiziatore a cascata.

Per migliorare le prestazioni delle transazioni in due fasi LU 6.2, l'iniziatore può assegnare il ruolo diultimo agent a uno degli agent. L'ultimo agent non partecipa alla fase di preparazione. Nella fase dicommit, l'ultimo agent esegue il commit per primo. Se il commit dell'ultimo agent non viene eseguitocorrettamente, l'iniziatore indica agli altri agent di eseguire il rollback.

Per l'unità di lavoro distribuita DRDA su TCP/IP, il coordinatore può assegnare il ruolo di server dirisincronizzazione a un partecipante. Il server di risincronizzazione è responsabile per larisincronizzazione degli altri partecipanti se si verifica un errore nelle comunicazioni con il coordinatore ose si verifica un errore di sistema per il coordinatore.Concetti correlati

“Definizione di commit per un commit in due fasi: consentire VRO (vote read-only)” a pagina 35Di norma, un gestore transazioni partecipa a entrambe le fasi dell'elaborazione di commit. Per migliorarele prestazioni dell'elaborazione di commit, è possibile configurare qualcuna delle ubicazioni, oppure tutte,in una transazione per consentire al gestore transazioni di eseguire il VRO (vote read-only).

Stati della transazione per il controllo del commit a due fasiUna definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma ditransazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazionecorrente e della transazione precedente.


Il sistema utilizza lo stato per decidere se eseguire il commit o il rollback se una transazione vieneinterrotta da un errore di sistema o nelle comunicazioni. Se più ubicazioni stanno partecipando a unatransazione, gli stati delle transazioni su ciascuna ubicazione potrebbero essere messi a confronto perdeterminare l'azione corretta (commit o rollback). Il processo di comunicazione tra le ubicazioni perdeterminare l'azione corretta è detto risincronizzazione.

La seguente tabella mostra questi elementi:v Gli stati di base che possono verificarsi durante una transazione.v Gli stati aggiuntivi che possono verificarsi.v Se uno stato richiede la risincronizzazione se la transazione viene interrotta da un errore di sistema o

nelle comunicazioni. I valori possibili sono i seguenti:

Non richiestoCiascuna ubicazione può prendere la decisione corretta indipendentemente.

Può essere necessarioCiascuna ubicazione può prendere la decisione corretta, ma l'iniziatore potrebbe richiedere diessere informato della decisione.

RichiestoLo stato di ciascuna ubicazione deve essere determinato prima che possa essere presa ladecisione corretta.

v Azione eseguita da un errore di sistema o nelle comunicazioni.

Nome stato Descrizione

Risincronizzazione se latransazione vieneinterrotta

Azione eseguita da unerrore di sistema o nellecomunicazioni

Stati di base durante l'elaborazione di commit in due fasi:

Ripristinare (RST) Dal limite di commit fino aquando il programmaemette una richiesta dicommit o di rollback.

Non necessario. Viene eseguito il rollbackdelle modifiche in sospeso.

Preparazione in corso (PIP) L'iniziatore ha avviato lafase di preparazione. Tuttele ubicazioni non hannoancora indicato la lorodecisione.

Potrebbe essere necessaria. Viene eseguito il rollbackdelle modifiche in sospeso.

Preparato (PRP) Questa ubicazione e tutte leubicazioni più in bassonella rete del programma ditransazione hanno decisoper il commit. Questaubicazione non ha ancoraricevuto la notificadall'iniziatore di eseguire ilcommit.

Richiesta. In dubbio. Dipende dairisultati del processo dirisincronizzazione.

Commit in corso (CIP) Tutte le ubicazioni hannodeciso per il commit.L'iniziatore ha avviato lafase di commit.

Richiesta. Le modifiche in sospesovengono sottoposte acommit. Viene eseguita larisincronizzazione perassicurare che tutte leubicazioni abbiano eseguitoil commit. Se vienenotificato un rollbackeuristico da un'altraubicazione, viene notificatoun errore.





Sottoposto a commit (CMT) Tutti gli agent hannoeseguito il commit erestituito una risposta aquesto nodo.

Potrebbe essere necessaria. Nessuna.

Stati aggiuntivi durante l'elaborazione di commit in due fasi:

Ultimo agent in sospeso(LAP)

Se viene selezionato unultimo agent, questo statosi verifica presso l'iniziatoretra lo stato PIP e lo statoCIP. L'iniziatore ha datoistruzione all'ultimo agentdi eseguire il commit e nonha ancora ricevuto unarisposta.

Richiesta. In dubbio. Dipende dairisultati del processo dirisincronizzazione.

Vote-Read-Only (VRO) Questo agent ha rispostoalla fase di preparazioneindicando che non hamodifiche in sospeso. Se èconsentito lo stato VRO(vote read-only), questoagent non viene inclusonella fase di commit.

Potrebbe essere necessaria. Nessuna.

Rollback richiesto (RBR) Si è verificato uno deiseguenti eventi:

v Un agent ha emesso unarichiesta di rollbackprima dell'operazione dicommit.

v Si è verificato un erroredi transazione.

v L'API QTNRBRQD èstata utilizzata permettere la transazione inuno stato di rollbackrichiesto.

Al programma ditransazione non èconsentito eseguire ulteriorimodifiche sotto il controllodel commit.

Potrebbe essere necessaria. Viene eseguito il rollbackdelle modifiche in sospeso.

Condizioni che si verificano a causa di errori o di azioni dell'operatore:

Rollback forzato Questa ubicazione e tutte leubicazioni più in bassonella rete del programma ditransazione, tranne l'ultimoagent, sono state sottopostea rollback per interventodell'operatore.

Potrebbe essere necessaria. Le modifiche in sospesosono già state sottoposte arollback.





Commit forzato Questa ubicazione e tutte leubicazioni più in bassonella rete del programma ditransazione, tranne l'ultimoagent, sono state sottopostea commit per interventodell'operatore.

Potrebbe essere necessaria. Le modifiche in sospesosono già state sottoposte acommit.

Euristico misto (HRM) Alcuni gestori risorsehanno eseguito il commit.Alcuni hanno eseguito ilrollback. È stato utilizzatol'intervento dell'operatoreoppure si è verificato unerrore di sistema. Euristicomisto non compare comeuno stato sullevisualizzazioni delledefinizioni di commit. Deimessaggi di notificavengono inviatiall'operatore.

Potrebbe essere necessaria. L'operatore deve eseguireun'operazione di ripristinosu tutte le ubicazionipartecipanti per portare ildatabase a uno statocongruente.

Concetti correlati

“Definizione di commit per un commit in due fasi: consentire VRO (vote read-only)” a pagina 35Di norma, un gestore transazioni partecipa a entrambe le fasi dell'elaborazione di commit. Per migliorarele prestazioni dell'elaborazione di commit, è possibile configurare qualcuna delle ubicazioni, oppure tutte,in una transazione per consentire al gestore transazioni di eseguire il VRO (vote read-only).“Definizione di commit per un commit in due fasi: Non attendere risultato” a pagina 37Quando si verifica un malfunzionamento nelle comunicazioni o di sistema durante un'operazione dicommit, ed è quindi richiesta una risincronizzazione, il valore predefinito prevede di attendere che larisincronizzazione sia terminata prima di completare l'operazione di commit.“Avvio del controllo del commit” a pagina 52Per avviare il controllo del commit, utilizzare il comando STRCMTCTL (Avvio controllo commit).“Ripristino del controllo del commit durante l'IPL (initial program load) dopo la fine anomala” a pagina67Quando si esegue un IPL (initial program load) dopo la fine anomala del sistema, il sistema prova aripristinare tutte le definizioni di commit che erano attive quando il sistema è stato terminato.“Errori del controllo del commit” a pagina 107Quando si utilizza il controllo del commit, è importante comprendere quali condizioni causano deglierrori e quali no.

Definizioni di commit per il controllo del commit in due fasiPer modificare le opzioni di commit per la transazione dopo l'avvio del controllo del commit, utilizzarel'API QTNCHGCO (Modifica opzioni di commit).

In base all'ambiente utilizzato e alle applicazioni utilizzate, la modifica delle opzioni di commit puòmigliorare le prestazioni del sistema.

Nota: se si sta utilizzando un'unità di lavoro distribuita DRDA su una connessione TCP/IP, la solaopzione valida è quella che consente VRO (vote read-only).



Change Commitment Options (QTNCHGCO) API

Definizione di commit per un commit in due fasi: consentire VRO (vote read-only):

Di norma, un gestore transazioni partecipa a entrambe le fasi dell'elaborazione di commit. Per migliorarele prestazioni dell'elaborazione di commit, è possibile configurare qualcuna delle ubicazioni, oppure tutte,in una transazione per consentire al gestore transazioni di eseguire il VRO (vote read-only).

Se l'ubicazione non ha modifiche di cui è possibile eseguire il commit durante una transazione, il gestoretransazioni esegue il VRO (vote read-only) durante la fase di preparazione. L'ubicazione non partecipaalla fase di commit. Questo migliora le prestazioni generali perché i flussi di comunicazioni che di normasi verificano durante la fase di commit vengono eliminati durante le transazioni in cui non viene eseguitoalcun aggiornamento su una o più ubicazioni remote.

Dopo aver avviato il controllo del commit, è possibile utilizzare l'API QTNCHGCO (Modifica opzioni dicommit) per modificare l'opzione VRO (Vote read only) consentito in Y. È possibile eseguire questaoperazione se ricorrono le seguenti condizioni:v Spesso uno o più sistemi remoti non hanno alcuna modifica di cui è possibile eseguire il commit per

una transazione.v Una transazione non dipende da dove il cursore del file (record successivo) è stato impostato dalla

transazione precedente. Quando un'ubicazione dà un'indicazione di VRO (vote read-only),l'applicazione non viene mai informata se viene eseguito il rollback della transazione. L'ubicazione haeseguito il commit delle operazioni di lettura con i file del database e, pertanto, ha spostato laposizione del cursore. La posizione del cursore del file è di norma importante solo se si esegueun'elaborazione sequenziale.

Se la definizione di commit è impostata per consentire VRO (vote read-only), l'applicazione attende ilsuccessivo flusso di messaggi da un'altra ubicazione.

L'opzione VRO (Vote read only) consentito è progettata per le applicazioni con una natura client/server.Se il solo scopo del programma A è soddisfare le richieste dal programma I e non di eseguire del lavoroindipendente, è appropriato consentire l'opzione VRO (vote read-only) per il programma A.

Flusso di elaborazione di commit senza l'ottimizzazione di ultimo agent quando l'agent dàun'indicazione di VRO (vote read-only)

La seguente figura mostra il flusso di messaggi tra i programmi applicativi e i gestori transazioni quandoun programma applicativo emette un'istruzione di commit senza l'ottimizzazione di ultimo agent quandol'agent dà come indicazione VRO (vote read-only). Né il programma applicativo iniziatore né iprogrammi applicativi agent rilevano l'elaborazione di commit in due fasi. I numeri tra parentesi () nellafigura corrispondono agli elementi numerati nella descrizione successiva.


Il seguente elenco è una descrizione degli eventi per l'elaborazione normale senza l'ottimizzazione diultimo agent quando l'agent dà l'indicazione di VRO (vote read-only). È rappresentata la descrizione diun flusso di base. La sequenza di eventi può diventare molto più complessa quando la rete delprogramma di transazione ha più livelli o quando si verificano degli errori.1. Il programma applicativo A esegue un'operazione di ricezione richiesta per indicare che è pronto a

ricevere una richiesta dal programma I.2. L'applicazione iniziatore (I) emette un'istruzione di commit.3. Il gestore transazioni per l'iniziatore (TM-I) assume il ruolo di iniziatore per questa transazione. Avvia

la fase di preparazione inviando un messaggio di preparazione a tutte le altre ubicazioni che stannopartecipando alla transazione.

4. I gestori transazioni per tutte le altre ubicazioni assumono il ruolo di agent (TM-A). Il programmaapplicativo A viene informato da TM-A che è stata ricevuta una richiesta di commit. Per i file ICF, lanotifica consiste nell'impostazione come attivo dell'indicatore ICF di ricezione di un'esecuzione dicommit (RCVTKCMT).

5. Il programma applicativo A risponde immettendo un'istruzione di commit (o un'istruzione dirollback). Questa è la decisione del programma applicativo.

6. Se il programma applicativo A ha utilizzato l'API QTNCHGCO (Modifica opzioni di commit) perimpostare l'opzione di commit VRO (Vote read only) consentito su Y e non è stata apportata alcunamodifica all'agent durante la transazione, l'agent (TM-A) risponde all'iniziatore (TM-I) con unmessaggio di reimpostazione. Non c'è alcuna fase di commit per l'agent.

7. Una restituzione viene inviata al programma applicativo (A) per indicare che la transazione ècompleta presso l'agent TM-A.

8. La volta successiva che l'iniziatore (TM-I) invia un messaggio all'agent (TM-A), sia esso un flusso didati o un'istruzione di commit, TM-I fa in modo che il suo ID transazione corrente venga inviato conil messaggio. Questo è dovuto al fatto che un nuovo ID transazione potrebbe essere stato generatopresso il TM-I se si era verificato un errore nelle comunicazioni tra il TM-I e un altro sistema durantel'operazione di commit.


9. Una restituzione viene inviata al programma applicativo (A) per indicare che la transazione ècompleta presso l'agent TM-A. La restituzione viene ritardata fino a dopo la ricezione del successivomessaggio perché il TM-I deve ricevere un nuovo ID transazione prima che l'applicazione A possaavviare la successiva transazione.

Concetti correlati

“Ruoli nell'elaborazione di commit” a pagina 29Se un commit di una transazione interessa più di un gestore risorse, ciascun gestore risorse ha un ruolonella transazione. Un gestore risorse è responsabile per il commit o il rollback delle modifiche apportatedurante la transazione.“Stati della transazione per il controllo del commit a due fasi” a pagina 31Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma ditransazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazionecorrente e della transazione precedente.“Ottimizzazione delle prestazioni per il controllo del commit” a pagina 71L'utilizzo del controllo del commit richiede delle risorse che possono influenzare le prestazioni delsistema. Diversi fattori influenzano le prestazioni del sistema relativamente al controllo del commit.Riferimenti correlati


Definizione di commit per un commit in due fasi: Non attendere risultato:

Quando si verifica un malfunzionamento nelle comunicazioni o di sistema durante un'operazione dicommit, ed è quindi richiesta una risincronizzazione, il valore predefinito prevede di attendere che larisincronizzazione sia terminata prima di completare l'operazione di commit.

Nota: l'opzione Non attendere risultato non si applica se si sta utilizzando un'unità di lavoro distribuitaDRDA (Distributed Relational Database Architecture) su una connessione TCP/IP. L'unità di lavorodistribuita DRDA su connessioni TCP/IP non attende mai il risultato.

Prendere in considerazione la possibilità di modificare questa modalità di funzionamento se ricorrono leseguenti condizioni:v Le applicazioni che partecipano sono indipendenti l'una dall'altra.v La logica di programma non richiede i risultati delle transazioni precedenti per assicurare che i file di

database rimangano sincronizzati.

Dopo aver avviato il controllo del commit, è possibile utilizzare l'API QTNCHGCO (Modifica opzioni dicommit) per specificare che la definizione di commit non attende il risultato della risincronizzazione. Se sispecifica N (No) per l'opzione Attesa risultato, il sistema utilizza un lavoro del server di database(QDBSRVnn) per gestire la risincronizzazione in modo asincrono.

Nota: questi lavori del server di database vengono avviati durante il processo IPL (initial program load -caricamento iniziale di programma). L'eventuale modifica delle opzioni per il controllo del commitnon influenza il numero di lavori avviato dal sistema.

Questo argomento fa riferimento solo ai due valori per l'opzione Attesa risultato risolta, Y (Sì) e N(No). Ci sono effettivamente altri due valori che è possibile specificare, L (Sì o Eredita da iniziatore) e U(No o Eredita da iniziatore). Quando si utilizzano questi valori, il valore effettivo utilizzato duranteciascuna operazione di commit viene risolto in Sì o No dal sistema. L'argomento relativo all'APIQTNCHGCO (Modifica opzioni di commit) contiene maggiori dettagli su questi valori.

Nota: il valore dell'iniziatore può essere ereditato solo da un agent se sia l'iniziatore sia l'agentsupportano la presunta fine anomala.


L'opzione WFO (wait for outcome, ossia attendere risultato) non influenza la normale elaborazione dicommit che non presenta errori. Se si verifica un errore, l'opzione WFO determina se l'applicazioneattende la risincronizzazione o meno, con le seguenti condizioni:v Se l'opzione WFO risolta è Y (Sì), l'applicazione attende il risultato della risincronizzazione.v Se l'opzione WFO risolta è N (No) e si verifica un errore nelle comunicazioni durante la fase di

preparazione o il rollback di un'ubicazione che supporta i protocolli di presunta fine anomala, nonviene eseguita alcuna risincronizzazione e la definizione di commit viene sottoposta a rollback.

v Se la definizione di commit è in dubbio (lo stato della transazione è Preparato o Ultimo agent insospeso), l'applicazione attenderà il risultato della risincronizzazione indipendentemente dal valoredell'opzione WFO risolta.

v Se l'opzione WFO risolta è N e non ricorre né la condizione due né quella tre, il sistema prova adeseguire la risincronizzazione una sola volta. Se l'operazione non viene eseguita con esito positivo, ilsistema segnala il messaggio di STATO CPF83E6 all'applicazione per indicare che la risincronizzazioneè in corso.Poiché CPF83E6 è un messaggio di STATO, ha un effetto solo se l'applicazione ne sta monitorandol'emissione. Di norma, l'applicazione può elaborare questo messaggio come un messaggio informativo.I sistemi che stanno partecipando al tentativo di transazione provano a risincronizzare la transazionefinché l'errore non viene corretto. Questi tentativi di risincronizzazione successivi vengono eseguiti neilavori del server di database. Se un successivo tentativo di risincronizzazione eseguito in un lavoro delserver di database ha esito negativo, il messaggio CPI83D0 viene inviato a QSYSOPR.

Valore di Attendi risultato: Sì

Nella seguente figura, la definizione di commit per l'iniziatore (I) utilizza il valore predefinito di Y (Sì)per l'opzione Attendi risultato. Quando le comunicazioni tra TM-I e TM-A si interrompono, sial'applicazione A sia l'applicazione I attendono che la transazione venga risincronizzata.


Valore di Attendi risultato: No

Nella seguente figura, la definizione di commit per l'iniziatore ha l'opzione WFO risolta impostata su N(No). TM-A soddisfa la condizione 3 nell'elenco precedente, mentre TM-I soddisfa la condizione 4. Ilcontrollo viene restituito all'applicazione I dopo un tentativo di risincronizzazione con TM-A. Un lavorodel server di database prova ad eseguire la risincronizzazione. L'applicazione I non riceve mai l'indicatoredi restituzione dopo il corretto completamento della richiesta di commit. Il controllo viene restituitoall'applicazione agent (A) solo dopo che le comunicazioni sono state ristabilite. Questo dipende daquando si verifica l'errore. In questo caso, l'errore nelle comunicazioni si verifica prima che l'iniziatorericeva il messaggio di commit, lasciando TM-A in dubbio se eseguire il commit o il rollback. Quando è indubbio, il gestore transazioni conserva il controllo finché la risincronizzazione non viene completata,indipendentemente dal valore dell'opzione WFO risolta per tale sistema.

Se si desidera che le applicazioni su tutti i sistemi continuino prima che venga completata larisincronizzazione, è necessario modificare l'opzione WFO risolta in N (No) su tutti i sistemi oppureimpostare l'iniziatore su N e il resto dei sistemi su U (No o Eredita da iniziatore). Tenere tuttavia presenteche l'opzione WFO risolta viene ignorata quando il gestore transazioni è in dubbio se eseguire il commito il rollback e attende sempre che la risincronizzazione venga completata prima di restituire il controllo.


Quando viene stabilita una connessione a un database relazionale remoto, e non sono già state avviatedelle conversazioni protette, il sistema modifica in modo implicito il valore Attendi risultato in N.Questo è dovuto al fatto che le prestazioni delle operazioni di commit sono migliori quando il valoreAttendi risultato è N e il sistema remoto supporta la presunta fine anomala. Questa modifica implicitadel valore Attendi risultato viene eseguita solo per le applicazioni DDM e DRDA. Le applicazioniAPPC utilizzano il valore predefinito Attendi risultato di Y a meno che non richiamino l'APIQTNCHGCO per modificarlo.


Concetti correlati

“Stati della transazione per il controllo del commit a due fasi” a pagina 31Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma ditransazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazionecorrente e della transazione precedente.“Errori del controllo del commit” a pagina 107Quando si utilizza il controllo del commit, è importante comprendere quali condizioni causano deglierrori e quali no.Riferimenti correlati


Definizione di commit per un commit in due fasi: indicazione di OK tralasciare:

Di norma, il gestore transazioni in qualsiasi ubicazione nella rete del programma di transazione partecipaa ogni operazione di commit o di rollback. Per migliorare le prestazioni, è possibile configurare qualcunao tutte le ubicazioni in una transazione per consentire al gestore transazioni di indicare che è OKtralasciare.

Nota: l'opzione OK tralasciare non si applica se si sta utilizzando un'unità di lavoro distribuita DRDAsulla connessione TCP/IP.

Se nessun flusso di comunicazioni viene inviato all'ubicazione durante una transazione, l'ubicazione vieneomessa quando viene eseguita un'operazione di commit o di rollback. Questo migliora le prestazionigenerali perché i flussi di comunicazioni che di norma si verificano durante il commit o il rollbackvengono eliminati durante le transazioni in cui nessun dato viene inviato a una o più ubicazioni remote.

Dopo aver avviato il controllo del commit, è possibile utilizzare l'API QTNCHGCO (Modifica opzioni dicommit) per modificare l'opzione OK tralasciare in Y (Sì). È possibile eseguire questa operazione se uno opiù sistemi remoti spesso non sono coinvolti in una transazione.

Se la definizione di commit è configurata per indicare che è OK tralasciare, l'applicazione attende ilsuccessivo flusso di messaggi da un'altra ubicazione.

L'opzione che indica che è OK tralasciare è progettata per le applicazioni con una natura client/server. Seil solo scopo del programma A è soddisfare le richieste dal programma I e non di eseguire del lavoroindipendente, è appropriato consentire l'opzione che indica che è OK tralasciare per il programma A.

Flusso di elaborazione di commit senza l'ottimizzazione di ultimo agent quando l'agent dàun'indicazione di OK tralasciare

La seguente figura mostra il flusso di messaggi tra i programmi applicativi e i gestori transazioni quandoun programma applicativo emette un'istruzione di commit senza l'ottimizzazione di ultimo agent quandol'agent dà come indicazione OK tralasciare. Sia il programma applicativo iniziatore sia i programmiapplicativi agent non rilevano l'elaborazione di commit in due fasi. I numeri tra parentesi () nella figuracorrispondono agli elementi numerati nella descrizione successiva.


Viene qui di seguito riportata una descrizione degli eventi per l'elaborazione normale senzal'ottimizzazione di ultimo agent quando l'agent dà l'indicazione di OK tralasciare. È rappresentata ladescrizione di un flusso di base. La sequenza di eventi può diventare molto più complessa quando la retedel programma di transazione ha più livelli o quando si verificano degli errori.1. Il programma applicativo A esegue un'operazione di ricezione richiesta per indicare che è pronto a

ricevere una richiesta dal programma I.2. L'applicazione iniziatore (I) emette un'istruzione di commit.3. Il gestore transazioni per l'iniziatore (TM-I) assume il ruolo di iniziatore per questa transazione.

Avvia la fase di preparazione inviando un messaggio di preparazione a tutte le altre ubicazioni chestanno partecipando alla transazione.

4. I gestori transazioni per tutte le altre ubicazioni assumono il ruolo di agent (TM-A). Il programmaapplicativo A viene informato da TM-A che è stata ricevuta una richiesta di commit. Per i file ICF, lanotifica consiste nell'impostazione dell'indicatore ICF di ricezione di un'esecuzione di commit(RCVTKCMT).


6. Se il programma applicativo A ha utilizzato l'API QTNCHGCO (Modifica opzioni di commit) perimpostare l'opzione di commit OK tralasciare su Y, viene inviato un indicatore quando l'agent(TM-A) risponde all'iniziatore (TM-I) con un messaggio di richiesta di commit.


Nota: qualsiasi modifica all'opzione di commit OK tralasciare non diventa effettiva fino allasuccessiva operazione di commit eseguita correttamente.

7. Quando l'iniziatore (TM-I) riceve tutte le decisioni, il TM-I invia un messaggio di commit. Questoavvia la fase di commit.

8. Ciascun agent (TM-A) esegue il commit e risponde con un messaggio di reimpostazione.9. Una restituzione viene inviata al programma applicativo (I) per indicare che la transazione è

completa presso l'iniziatore.10. Su TM-I può verificarsi qualsiasi numero di transazioni, nessuna delle quali richiede delle modifiche

a TM-A o dati da TM-A. TM-A non è incluso in queste transazioni.11. La volta successiva che l'iniziatore (TM-I) invia un messaggio all'agent (A), un nuovo ID transazione

viene inviato con il messaggio. Se l'iniziatore esegue qualche operazione di commit o di rollbackprima di inviare un messaggio all'agent, nessun messaggio viene inviato all'agent durante questeoperazioni (l'agent viene "escluso" da questi commit o rollback). Poiché una o più transazionipotrebbero essere state sottoposte a commit o rollback presso l'iniziatore mentre l'agent era escluso,l'iniziatore deve comunicare il suo ID transazione corrente quando viene inviato il messaggiosuccessivo all'agent.

12. Una restituzione viene inviata al programma applicativo (A) per indicare che il commit originario ècompleto e che sta partecipando alla transazione corrente.

Concetti correlati

“Ottimizzazione delle prestazioni per il controllo del commit” a pagina 71L'utilizzo del controllo del commit richiede delle risorse che possono influenzare le prestazioni delsistema. Diversi fattori influenzano le prestazioni del sistema relativamente al controllo del commit.

Definizione di commit per un commit in due fasi: non selezione di un ultimo agent:

Per impostazione predefinita, il gestore transazioni per l'iniziatore può selezionare qualsiasi agent comeun ultimo agent durante un'operazione di commit.

Nota: l'opzione che indica di non selezionare l'ultimo agent non è valida se si sta utilizzando l'unità dilavoro distribuita DRDA su una connessione TCP/IP.

Nel caso di un albero a più livelli, qualsiasi agent selezionato come ultimo agent dal suo iniziatore puòanche selezionare un proprio ultimo agent. Le prestazioni sono migliorate quando un ultimo agent vieneselezionato durante l'operazione di commit perché i due flussi di comunicazioni vengono eliminati tra uniniziatore e il suo ultimo agent (la fase di preparazione viene eliminata per questi sistemi).

Tuttavia, quando invia la richiesta di commit al suo ultimo agent, l'iniziatore deve attendere finché nonavrà ricevuto la decisione dell'ultimo agent prima di poter continuare. Questo è indipendente dal valoredi Attesa risultato per la definizione di commit. Durante la normale elaborazione di commit senza errori,questo non è un problema. Se però si verifica un errore durante questo intervallo di tempo, l'iniziatorenon può continuare finché non sarà stata completata la risincronizzazione. Se l'applicazione iniziatore stagestendo richieste da un utente a un terminale, questa può essere una considerazione di utilizzabilità.

È necessario considerare se delle prestazioni migliorate durante le normali operazioni di commit sono piùimportanti dell'impatto sull'utilizzabilità quando si verifica un errore di questo tipo. Nota: se l'errore siverifica prima che la richiesta di commit venga inviata all'ultimo agent, la LUW (Logical Unit of Work -unità di lavoro logica) eseguirà immediatamente il rollback e l'iniziatore non attenderà. Pertanto,l'intervallo di tempo durante il quale un errore può causare una condizione di attesa per l'iniziatore èabbastanza piccolo e, pertanto, un errore di questo tipo è raro.

Se si decide che l'impatto sull'utilizzabilità è eccessivo rispetto al miglioramento delle prestazioniottenuto, è possibile modificare le definizioni di commit per non selezionare un ultimo agent. Dopo averavviato il controllo del commit, è possibile utilizzare l'API QTNCHGCO (Modifica opzioni di commit) permodificare l'opzione Ultimo agent consentito in N.




Effetto della decisione affidabile sul flusso di elaborazione di commit:

La decisione affidabile è un'ottimizzazione che migliora le prestazioni velocizzando la restituzioneall'applicazione iniziatore dopo un'operazione di commit ed eliminando un messaggio duranteun'operazione di commit.

Non esiste alcuna ottimizzazione di decisione affidabile esplicita per l'unità di lavoro distribuita DRDA(Distributed Relational Database Architecture) su TCP/IP. Tuttavia, il sistema operativo i5/OS nonrichiede mai una conferma di reimpostazione (ignora) per le connessioni TCP/IP. Pertanto, unareimpostazione (ignora) è sempre implicita per le connessioni TCP/IP.

Dopo aver avviato il controllo del commit, è possibile utilizzare l'API QTNCHGCO (Modifica opzioni dicommit) per modificare l'opzione Accettazione decisione affidabile in Y.

Si può pensare alla decisione affidabile come a una promessa da parte di un agent al suo iniziatore chenon verranno prese decisioni euristiche presso l'agent se si verifica un errore nelle comunicazioni mentrel'agent è in dubbio. Un agent che sta utilizzando l'ottimizzazione di decisione affidabile invia unindicatore all'iniziatore durante la fase di preparazione del commit. Se anche l'iniziatore sta utilizzandol'ottimizzazione di decisione affidabile, esso invia un indicatore all'agent che non è richiesta alcunareimpostazione in risposta al messaggio di commit. Questo elimina il messaggio di reimpostazione econsente al gestore transazioni di eseguire la restituzione all'applicazione presso l'iniziatore appena vieneinviato il messaggio di commit.

Prendere in considerazione la possibilità di utilizzare l'ottimizzazione di decisione affidabile se ricorronole seguenti condizioni:v È improbabile che venga presa una decisione euristica presso un agent in dubbio se si verifica un

errore di sistema o nelle comunicazioni a meno che l'errore non possa essere riparato.v La logica di programma non richiede i risultati delle transazioni precedenti per assicurare che i file di

database rimangano sincronizzati.

L'ottimizzazione di decisione affidabile viene utilizzata dal sistema operativo i5/OS solo se ricorronotutte le seguenti condizioni:v Le ubicazioni iniziatore e agent supportano il livello di presunta fine anomala del controllo del commit.v L'ubicazione iniziatore accetta l'indicazione di decisione affidabile dall'agent. Sugli iniziatori i5/OS,

questo dipende dal valore delle due opzioni di commit:– Il valore dell'opzione di commit Attesa risultato deve essere N (Sì è il valore predefinito).– Il valore dell'opzione di commit Accettazione decisione affidabile deve essere Sì (Sì è il valore

predefinito).v L'ubicazione dell'agent dà un'indicazione di decisione affidabile durante la fase di preparazione. Gli

agent i5/OS danno sempre un'indicazione di decisione affidabile. Questo è dovuto al fatto che ledecisioni euristiche possono essere prese solo tramite una procedura manuale che avverte dei possibilieffetti collaterali negativi che esse comportano.

Flusso di elaborazione di commit con l'ottimizzazione di decisione affidabile

La seguente figura mostra il flusso di messaggi tra i programmi applicativi e i gestori transazioni quandoviene utilizzata l'ottimizzazione di decisione affidabile. Sia il programma applicativo iniziatore sia iprogrammi applicativi agent non rilevano l'elaborazione di commit in due fasi. I numeri tra parentesi ()nella figura corrispondono agli elementi numerati nella descrizione successiva.


Il seguente elenco descrive gli eventi per l'elaborazione normale senza l'ottimizzazione di ultimo agentquando l'agent dà l'indicazione di decisione affidabile. È rappresentata la descrizione di un flusso di base.La sequenza di eventi può diventare molto più complessa quando la rete del programma di transazioneha più livelli o quando si verificano degli errori.1. Il programma applicativo A esegue un'operazione di ricezione richiesta per indicare che è pronto a

ricevere una richiesta dal programma I.2. L'applicazione iniziatore (I) emette un'istruzione di commit.3. Il gestore transazioni per l'iniziatore (TM-I) assume il ruolo di iniziatore per questa transazione. Avvia

la fase di preparazione inviando un messaggio di preparazione a tutte le altre ubicazioni che stannopartecipando alla transazione.

4. I gestori transazioni per tutte le altre ubicazioni assumono il ruolo di agent (TM-A). Il programmaapplicativo A viene informato da TM-A che è stata ricevuta una richiesta di commit. Per i file ICF, lanotifica consiste nell'impostazione dell'indicatore ICF di ricezione di un'esecuzione di commit(RCVTKCMT).


6. L'agent (TM-A) risponde all'iniziatore (TM-I) con un messaggio di richiesta di commit. I sistemi i5/OSun indicatore affidabile di voto con la richiesta di commit.

7. Quando l'iniziatore (TM-I) riceve tutte le decisioni, il TM-I invia un messaggio di commit. Se l'opzionedi commit Attesa risultato è N (No) e l'opzione di commit Accettazione decisione affidabile è Y (Sì),con il messaggio di commit viene inviato un indicatore di non reimpostazione. Questo indica all'agentche non è richiesto alcun messaggio di reimpostazione in risposta al commit.


8. La transazione è completa. Una restituzione viene inviata ai programmi applicativi (I e A). Questarestituzione indica che l'operazione di commit è stata eseguita correttamente. Se si verifica un dannoeuristico sul sistema A dovuto a una decisione euristica presa prima che fosse ricevuto il messaggio dicommit eseguito, l'applicazione I non viene informata. Viene invece inviato un messaggio alla codamessaggi QSYSOPR. Tuttavia, l'applicazione A riceve l'indicazione di danno euristico.

9. La vota successiva che l'agent (TM-A) invia un messaggio all'iniziatore (TM-I), sia esso un flusso didati o un'istruzione di commit, un indicatore di reimpostazione implicita viene inviato insieme almessaggio per informare TM-I che TM-A ha completato il commit correttamente. Questo è dovuto alfatto che TM-I deve conservare le informazioni sulla transazione completata finché non conferma cheTM-A ha ricevuto correttamente il messaggio di commit nel passo 7 a pagina 45



Supporto delle transazioni XA per il controllo del commitDB2 for i può partecipare nelle transazioni globali X/Open.

The Open Group ha definito un modello standard del settore per il lavoro transazionale che consente amodifiche apportate a risorse non correlate di far parte di una singola transazione globale. Un esempio èrappresentato da modifiche ai database forniti da due fornitori separati. Questo modello è detto modelloX/Open Distributed Transaction Processing.

Le seguenti pubblicazioni descrivono in modo dettagliato il modello X/Open Distributed TransactionProcessing:v X/Open Guide, February 1996, Distributed Transaction Processing: Reference Model, Version 3

(ISBN:1-85912-170-5, G504), The Open Group.v X/Open CAE Specification, December 1991, Distributed Transaction Processing: The XA Specification

(ISBN:1-872630-24-3, C193 o XO/CAE/91/300), The Open Group.v X/Open CAE Specification, April 1995, Distributed Transaction Processing: The TX (Transaction

Demarcation) Specification (ISBN:1-85912-094-6, C504), The Open Group.

È necessario avere dimestichezza con le informazioni contenute in questi manuali, in particolar modo conla specifica XA, prima di provare a utilizzare il supporto delle transazioni XA fornito da DB2 for i. Questimanuali sono disponibili sul sito Web della The Open Group.

Il modello DTP (distributed transaction processing) presenta cinque componenti:

AP (application program, ossia programma applicativo)Implementa la funzione richiesta dell'utente specificando una sequenza di operazioni checoinvolge risorse come ad esempio i database. Definisce l'inizio e la fine delle transazioni globali,accede alle risorse nei limiti delle transazioni e, di norma, decide se eseguire il commit o ilrollback di ciascuna transazione.

TM (transaction manager, ossia gestore transazioni)Gestisce le transazioni globali e coordina la decisione di avviarle e di eseguirne il commit, o dieseguirne il rollback per assicurare il completamento della transazione atomica (indivisibile). IlTM coordina anche le attività di ripristino con gli RM dopo il malfunzionamento di uncomponente.

RM (resource manager, ossia gestore risorse)Gestisce una parte definita delle risorse condivise del computer, come ad esempio un sistema digestione del database. L'AP utilizza interfacce definite da ogni RM per eseguire il lavorotransazionale. Il TM utilizza le interfacce fornite dall'RM per eseguire il completamento dellatransazione.


CRM (communications resource manager)Consente a un'istanza del modello di accedere a un'altra istanza interna o esterna al dominio TMcorrente. I CRM non rientrano nell'ambito di DB2 for i e non sono trattati in questapubblicazione.

Protocollo per le comunicazioniI protocolli sono utilizzati dai CRM per comunicare tra loro. Questo non rientra nell'ambito diDB2 for i e non è trattato in questa pubblicazione.

La specifica XA è la parte del modello DTP che descrive un set di interfacce utilizzato dai componentiTM ed RM del modello DTP. DB2 for i implementa queste interfacce come un set di programmi di uscitae di API in stile piattaforma UNIX®. Consultare API XA per una documentazione dettagliata di questeAPI e per ulteriori informazioni su come utilizzare DB2 for i come un RM.

System i Navigator e le transazioni XA

System i Navigator supporta la gestione di transazioni XA come transazioni globali.

Una transazione globale può contenere modifiche sia esterne sia interne a DB2 for i. Una transazioneglobale è coordinata da un gestore transazioni esterno che utilizza l'architettura Open Group XA oun'altra architettura simile. Un'applicazione esegue il commit o il rollback di una transazione globaleutilizzando le interfacce fornite dal gestore transazioni. Il gestore transazioni utilizza protocolli di commitdefiniti dall'architettura XA, o da un'altra architettura, per completare la transazione. DB2 for i funge dagestore risorse XA quando partecipa a una transazione globale. Esistono due tipi di transazioni globali:v Blocchi nell'ambito della transazione: i blocchi acquisiti per conto della transazione sono inclusi

nell'ambito della transazione. La transazione può spostarsi da un lavoro o un sottoprocesso ad un altro.v Blocchi nell'ambito del lavoro: i blocchi acquisiti per conto della transazione sono inclusi nell'ambito

del lavoro. La transazione non può spostarsi dal lavoro che l'ha avviata.

Considerazioni per le transazioni XA

Le API XA per i blocchi nell'ambito della transazione sono consigliate per i nuovi utenti del supportodelle transazioni XA. Le API XA per i blocchi nell'ambito del lavoro continueranno a essere supportatema non presenteranno più alcun vantaggio rispetto alle API XA per i blocchi nell'ambito dellatransazione. Le API XA per i blocchi nell'ambito della transazione presentano meno limitazioni e offronomigliori prestazioni nelle seguenti situazioni:v Se vengono utilizzate più connessioni SQL per gestire un singolo ramo transazione XA.v Se viene utilizzata una singola connessione SQL per gestire più rami transazione XA simultanei.

In queste situazioni, è necessario avviare un lavoro separato per eseguire i rami transazione XA quando siutilizzano le API XA per i blocchi nell'ambito del lavoro.

Leggere attentamente le seguenti considerazioni e comprendere le seguenti limitazioni prima di utilizzareDB2 for i come un RM. Il termine sottoprocesso fa riferimento a un lavoro che non ha capacità disottoprocesso oppure a un singolo sottoprocesso in un lavoro con capacità di sottoprocesso.

Le seguenti considerazioni sono valide sia per le transazioni con i blocchi nell'ambito della transazionesia per le transazioni con i blocchi nell'ambito del lavoro, se non diversamente indicato.

Considerazioni su DB2 for iv Le transazioni XA su un database locale devono essere eseguite in lavori in esecuzione in modalità

server SQL. Per questo tipo di transazioni, se viene utilizzata l'API xa_open() o db2xa_open() in unlavoro che non è già in esecuzione in modalità server SQL, la modalità server SQL viene avviata inmodo implicito. È possibile fare riferimento a API XA per le limitazioni sulle interfacce di databasesupportate.


v le transazioni XA su un database remoto devono utilizzare la modalità server SQL quando siutilizzano le API XA per i blocchi nell'ambito del lavoro. Tuttavia, la modalità server è facoltativa perle transazioni XA su un database remoto quando si utilizzano le API XA per i blocchi nell'ambito dellatransazione. Inoltre, le modifiche ai file DDM utilizzando i classici metodi di accesso al database i5/OSsono consentite nelle transazioni XA su un database remoto quando non viene utilizzata la modalitàserver SQL.

v Durante i richiami di API XA, la specifica XA notifica eventuali errori rilevati da DB2 for i tramite icodici di ritorno. I messaggi di diagnostica vengono lasciati nella registrazione lavoro quando non èpossibile determinare il significato dell'errore dal solo codice di ritorno.

Considerazioni sull'SQL incorporatov Per utilizzare una connessione SQL (Structured Query Language) per le transazioni XA, è necessario

utilizzare l'API (application programming interface) xa_open() o db2xa_open() prima che vengastabilita la connessione SQL. Il database relazionale con il quale verrà stabilita la connessione deveessere trasmesso all'API xa_open() o db2xa_open() dal parametro xainfo. Il profilo utente e la parolad'ordine da utilizzare nel lavoro cui viene instradata la connessione potrebbero essere trasmessi all'APIxa_open() o db2xa_open(). Se non viene trasmesso, il profilo utilizzato è quello che è stato specificato outilizzato come predefinito durante il tentativo di connessione.

Nota: la seguente considerazione è valida solo per le transazioni con blocchi nell'ambito del lavoro.v Se per eseguire le transazioni XA viene utilizzato l'SQL incorporato, il lavoro eseguito per ciascuna

connessione viene instradato a un lavoro differente, anche se le connessioni vengono stabilite nellostesso sottoprocesso. Questo è diverso dalla modalità server SQL senza XA, dove il lavoro eseguito pertutte le connessioni in un singolo sottoprocesso viene instradato allo stesso lavoro. Questo è dovuto alfatto che la specifica XA richiede una chiamata di preparazione, commit o rollback separata perciascuna istanza del gestore risorse.

Nota: la seguente considerazione è valida solo per le transazioni con blocchi nell'ambito del lavoro.v Se per eseguire le transazioni XA viene utilizzato l'SQL incorporato, è possibile stabilire una sola

connessione per database relazionale per sottoprocesso. Quando il sottoprocesso non è attivamenteassociato a un ramo transazione, il lavoro richiesto su una delle connessioni del sottoprocesso farà sìche l'RM utilizzi il programma di uscita del TM ax_reg() per determinare se il lavoro consistenell'avviare, riprendere o eseguire l'unione a un ramo transazione.Se il lavoro consiste nell'avviare un ramo transazione, esso viene eseguito sulla connessione di talesottoprocesso al database relazionale corrispondente.Se il lavoro consiste nell'unirsi a un ramo transazione, esso viene reinstradato sulla connessione aldatabase relazionale corrispondente di cui era stata eseguita la creazione nel sottoprocesso che haavviato il ramo transazione. Notare che il sistema non impone che il profilo utente per la connessionesia uguale a quello per la connessione del sottoprocesso di unione. È responsabilità del TM assicurarsiche questo non rappresenti un problema per la sicurezza. I tipici TM utilizzano lo stesso profilo utenteper tutte le connessioni. Questo profilo utente è autorizzato a tutti i dati gestiti dal TM. Ulteriorimisure di sicurezza relative all'accesso a questi dati sono gestite dal TM o dall'AP invece di utilizzarele tecniche di sicurezza IBM i standard.

Nota: la seguente considerazione è valida solo per le transazioni con blocchi nell'ambito del lavoro.v Se il lavoro consiste nel riprendere un ramo transazione, la connessione utilizzata dipende dal fatto che

l'associazione di ramo transazione sospesa sia stata stabilita avviando un ramo transazione o unendosia esso.Il successivo lavoro viene eseguito sulla stessa connessione finché non viene utilizzata l'APIdb2xa_end() per sospendere o terminare l'associazione del sottoprocesso a tale ramo transazione.

Considerazioni sulla CLIv Se per eseguire le transazioni XA viene utilizzata la CLI, potrebbe essere stabilita più di una

connessione nello stesso sottoprocesso dopo l'utilizzo dell'API db2xa_open(). Le connessioni possono


essere utilizzate in altri sottoprocessi per eseguire delle transazioni XA, a condizione che questi altrisottoprocessi utilizzino prima l'API db2xa_open() con lo stesso valore di parametro xainfo.

Nota: la seguente considerazione è valida solo per le transazioni con blocchi nell'ambito del lavoro.v Se per eseguire le transazioni XA viene utilizzata la CLI, la connessione utilizzata per avviare un ramo

transazione deve essere utilizzata per tutto il lavoro su tale ramo transazione. Se un altro sottoprocessoconsiste nell'unirsi al ramo transazione, il gestore di connessione per la connessione utilizzata peravviare il ramo transazione deve essere trasmesso al sottoprocesso di unione in modo che possaeseguire il lavoro sulla stessa connessione. In modo analogo, se un sottoprocesso consiste nelriprendere il ramo transazione, deve essere utilizzata la stessa connessione.Poiché i gestori di connessione CLI non possono essere utilizzati in un lavoro differente, la funzione diunione è limitata ai sottoprocessi in esecuzione nello stesso lavoro che ha avviato il ramo transazionequando viene utilizzata la CLI.

Considerazioni sul database relazionale remoto

Nota: queste considerazioni relative a un database relazionale remoto sono valide solo per le transazionicon dei blocchi nell'ambito del lavoro.

v Le connessioni XA a un database relazionale remoto sono supportate solo se il database relazionale sitrova su un sistema che supporta le connessioni DUW (Distributed Unit of Work - unità di lavorodistribuita) DRDA. Questo include i prodotti System i che eseguono DRDA (Distributed RelationalDatabase Architecture) su conversazioni SNA LU 6.2 o che utilizzano V5R1 o successive quandoeseguono DRDA utilizzando connessioni TCP/IP. Questo include anche altre piattaforme chesupportano DRDA su SNA LU 6.2 o che supportano il protocollo XA utilizzando DRDA su TCP/IP.

v Prima di utilizzare la funzione di unione XA, l'API db2xa_open() deve essere utilizzata nelsottoprocesso di unione. È necessario specificare lo stesso nome di database relazionale e lo stessoRMID nell'API db2xa_open() sia nel sottoprocesso che ha avviato il ramo transazione sia nelsottoprocesso di unione. Se il ramo transazione è attivo quando viene tentata un'unione, ilsottoprocesso di unione viene bloccato. Il sottoprocesso di unione rimane bloccato finché il ramo attivonon sospende o termina la sua associazione al ramo transazione.

Considerazioni sul ripristinov Il supporto di rollback o commit euristico manuale fornito per tutte le definizioni di commit può essere

utilizzato se diventa necessario forzare un ramo transazione a eseguire il commit o il rollback mentre èin uno stato di preparato.

v Il supporto di rollback euristico manuale è consentito anche per i rami transazione che sono in unostato di attivo o inattivo. Questo supporto è soprattutto importante quando si verifica un errore diconnessione client dopo che l'API xa_end è stata utilizzata per passare il ramo transazione allo stato diinattivo ma prima dell'utilizzo di xa_commit o xa_rollback per completare la transazione. Se il gestoretransazioni del client non torna a completare il ramo transazione inattivo dopo l'errore di connessione,il ramo transazione inattivo diventa orfano e rimarrà in sospeso finché il sistema non viene riavviato ofinché non viene eseguito un rollback euristico manuale.

v Esiste anche un'opzione manuale per ignorare i rami transazione che sono in uno stato di completatoeuristicamente. Se un gestore transazioni non si attiene al protocollo XA per emettere l'API xa_forgetdopo aver ricevuto un codice di ritorno di decisione euristica, il ramo transazione diventa orfano erimarrà nello stato di euristicamente completato anche se viene eseguito un riavvio del sistema. Il ramotransazione non detiene modifiche in sospeso o blocchi in questo stato ma consuma memoria disistema che viene liberata quando viene applicata l'opzione "ignora".

Considerazioni sui rami transazionev Le informazioni sui rami transazione XA vengono visualizzate come parte delle informazioni sul

controllo del commit visualizzate da System i Navigator e dai comandi WRKJOB (Gestione lavoro),DSPJOB (Visualizzazione lavoro) e WRKCMTDFN (Gestione definizioni di commit). Il nome TM, lostato del ramo transazione, l'identificativo della transazione e il qualificatore ramo vengono tutti


|||||||

||||||

visualizzati. Le definizioni di commit correlate alle transazioni XA attualmente attive possono esserevisualizzate utilizzando il comando WRKCMTDFN JOB(*ALL) STATUS(*XOPEN) o visualizzando la cartellaTransazioni globali in System i Navigator.

Nota: la seguente voce è valida solo per le transazioni con blocchi nell'ambito del lavoro.v Se un'associazione tra un sottoprocesso e un ramo transazione esistente viene sospesa o terminata

utilizzando l'API db2xa_end(), il sottoprocesso potrebbe avviare un nuovo ramo transazione. Se laconnessione utilizzata per avviare il nuovo ramo transazione è stata utilizzata precedentemente peravviare un ramo transazione differente e l'associazione del sottoprocesso con tale ramo transazione èstata terminata o sospesa dall'API db2xa_end(), potrebbe essere avviato un nuovo lavoro server SQL.Un nuovo lavoro server SQL occorre solo se il primo ramo transazione non è stato ancora completatodall'API db2xa_commit() o db2xa_rollback(). In questo caso, alla registrazione lavoro viene inviato unaltro messaggio di completamento SQL7908 che identifica il nuovo lavoro server SQL, proprio come illavoro server SQL originario della connessione era stato identificato quando era stata stabilita laconnessione. Tutte le richieste SQL per il nuovo ramo transazione vengono instradate al nuovo lavoroserver SQL. Quando il ramo transazione viene completato dall'API db2xa_commit() o db2xa_rollback(),il nuovo lavoro server SQL viene riciclato (arrestato e riavviato) e restituito al lotto del lavoro dipreavvio.

v Un ramo transazione viene contrassegnato come Solo rollback nelle seguenti situazioni solo per letransazioni XA per i blocchi nell'ambito del lavoro:– Un sottoprocesso termina mentre è ancora associato al ramo transazione. Questo include un

sottoprocesso che termina in seguito alla terminazione di un processo.– Si verifica un malfunzionamento del sistema.

v Con le transazioni XA per i blocchi nell'ambito della transazione, un ramo transazione viene sottopostoa rollback dal sistema se qualche sottoprocesso è ancora associato a esso quando si verifica una delleseguenti situazioni:– La connessione correlata al ramo transazione viene terminata.– Il lavoro che ha avviato il ramo transazione viene terminato.– Si verifica un malfunzionamento del sistema.

Nota: la seguente considerazione è valida solo per le transazioni con blocchi nell'ambito del lavoro.v Esiste una situazione in cui un ramo transazione verrà sottoposto a rollback dal sistema,

indipendentemente dal fatto che ci siano ancora dei sottoprocessi associati. Questo si verifica quando illavoro server SQL cui si sta instradando il lavoro della connessione viene terminato. Questo si verificasolo quando su tale lavoro viene utilizzato il comando CL ENDJOB (Fine lavoro).

v Un ramo transazione non è interessato da questa condizione se nessun sottoprocesso haun'associazione attiva ad esso quando si verifica una delle seguenti situazioni. Il TM può eseguire ilcommit o il rollback del ramo transazione da qualsiasi sottoprocesso che ha utilizzato l'API xa_open() odb2xa_open() con lo stesso valore di parametro xainfo che era stato specificato nel sottoprocesso che haavviato il ramo transazione.– La connessione correlata al ramo transazione viene terminata.– Un sottoprocesso o un lavoro che ha eseguito del lavoro per il ramo transazione utilizza l'API

xa_close() o db2xa_close().– Si verifica un malfunzionamento del sistema. In questo caso, il ramo transazione non è interessato

da questa condizione solo se è in uno stato di preparato. Se si trova nello stato di inattivo, il sistemane esegue il rollback.

v Quando gli identificativi transazione (XID) di due rami transazione XA hanno lo stesso identificativotransazione globale (GTRID), ma qualificatori ramo (BQUAL) differenti, vengono indicati comeliberamente accoppiati (o loosely coupled). Per impostazione predefinita, i rami transazione liberamenteaccoppiati non condividono blocchi. Tuttavia, quando si utilizzano le API XA per i blocchi nell'ambitodella transazione, esiste un'opzione che consente alle transazioni liberamente accoppiate di condividereblocchi.


Concetti correlati

“Considerazioni per le transazioni XA” a pagina 25Nell'ambiente XA, ciascun database viene considerato un gestore risorsa separato. Quando un gestoretransazioni desidera accedere a due database sotto la stessa transazione, deve utilizzare i protocolli XAper eseguire un commit in due fasi con i due gestori risorse.

The Open Group Web site“Modalità server SQL e transazioni nell'ambito del sottoprocesso per il controllo del commit”Le definizioni di commit con dei blocchi nell'ambito del lavoro sono di solito inclusi nell'ambito di ungruppo di attivazione.Attività correlate

“Quando forzare le opzioni di commit e di rollback e quando annullare la risincronizzazione” a pagina117La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azioneabilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione cheè in uno stato Preparato.

Modalità server SQL e transazioni nell'ambito del sottoprocesso per ilcontrollo del commitLe definizioni di commit con dei blocchi nell'ambito del lavoro sono di solito inclusi nell'ambito di ungruppo di attivazione.

Se un lavoro è a più sottoprocessi, tutti i sottoprocessi nel lavoro hanno accesso alla definizione dicommit e le modifiche apportate per una specifica transazione possono essere distribuite su piùsottoprocessi. In altri termini, tutti i sottoprocessi i cui programmi vengono eseguiti nello stesso gruppodi attivazione partecipano a una singola transazione.

Ci sono casi in cui è desiderabile che il lavoro transazionale sia incluso nell'ambito del sottoprocessopiuttosto che di un gruppo di attivazione. In altre parole, ogni sottoprocesso ha una propria definizionedi commit e un proprio lavoro transazionale poiché ciascuna definizione di commit è indipendente dallavoro eseguito in altri sottoprocessi.

DB2 for i fornisce questo supporto utilizzando l'API QWTCHGJB (Modifica lavoro) per modificare illavoro da eseguire in modalità server SQL. Quando è richiesta in modalità server SQL, una connessioneSQL viene instradata a un lavoro separato. Anche tutte le successive operazioni SQL eseguite per taleconnessione vengono instradate a tale lavoro. Quando viene stabilita la connessione, il messaggio dicompletamento SQL7908 viene inviato alla registrazione lavoro del lavoro in modalità server SQL conl'indicazione del lavoro cui si stanno instradando le richieste SQL. La definizione di commit appartiene allavoro indicato in questo messaggio. Se si verificano degli errori, potrebbe essere necessario consultare leregistrazioni lavoro per entrambi i lavori per comprendere l'origine del problema perché nessunaoperazione effettiva viene eseguita nel lavoro che esegue le istruzioni SQL.

In fase di esecuzione in modalità server SQL, solo le interfacce SQL possono essere utilizzate per eseguiredelle operazioni sotto il controllo del commit. È possibile utilizzare l'SQL incorporato o CLI (Call LevelInterface). Tutte le connessioni stabilite tramite l'SQL incorporato in un singolo sottoprocesso sonoinstradate allo stesso lavoro di back-end. Questo consente a una singola richiesta di commit di eseguire ilcommit del lavoro per tutte le connessioni, proprio come può essere in un lavoro che non è in esecuzionein modalità server SQL. Ciascuna connessione stabilita tramite la CLI viene instradata a un lavoroseparato. La CLI richiede che il lavoro eseguito per ciascuna connessione venga sottoposto a commit o arollback indipendentemente.

Non è possibile effettuare le seguenti operazioni sotto il controllo del commit quando si è in esecuzionein modalità server SQL:v Modifiche di record eseguite con delle interfacce che non siano interfacce SQL


http://www.opengroup.org

v Modifiche ai file DDMv Modifiche alle risorse di commit API

Non è possibile avviare il controllo del commit direttamente in un lavoro in esecuzione in modalitàserver SQL.Concetti correlati

“Supporto delle transazioni XA per il controllo del commit” a pagina 46DB2 for i può partecipare nelle transazioni globali X/Open.Running DB2 CLI in server modeStarting DB2 CLI in SQL server modeRestrictions for running DB2 CLI in server modeRiferimenti correlati

Change Job (QWTCHGJB) API

Avvio del controllo del commitPer avviare il controllo del commit, utilizzare il comando STRCMTCTL (Avvio controllo commit).

Nota: il controllo del commit non deve necessariamente essere avviato dalle applicazioni SQL. SQL avviain modo implicito il controllo del commit in fase di connessione quando il livello di isolamentoSQL è diverso da *NONE.

Quando si utilizza il comando STRCMTCTL, è possibile specificare questi parametri.

Livello di blocco del commitSpecificare il livello di blocco con il parametro LCKLVL nel comando STRCMTCTL. Il livellospecificato diventa il livello predefinito di blocco di record per i file di database aperti e postisotto il controllo del commit per la definizione di commit.

Oggetto di notifica del commitUtilizzare il parametro NTFY per specificare l'oggetto di notifica. Un oggetto di notifica è unacoda messaggi, un'area dati o un file di database che contiene le informazioni che identificanol'ultima transazione eseguita correttamente completata per una specifica definizione di commit setale definizione di commit non è stata terminata normalmente.

Parametro di ambito del commitUtilizzare il parametro CMTSCOPE per specificare l'ambito del commit. Quando viene avviato ilcontrollo del commit, il sistema crea una definizione di commit. Il parametro di ambito delcommit identifica l'ambito per la definizione di commit. Il valore predefinito consistenell'includere la definizione di commit nell'ambito del gruppo di attivazione del programma cheesegue la richiesta di avvio del controllo del commit. L'ambito alternativo è quello del lavoro.

Parametro di giornale predefinitoÈ possibile specificare un giornale predefinito quando si avvia il controllo del commit. È possibileutilizzare un giornale predefinito per questi motivi:v Si desidera catturare le voci di giornale della transazione. Queste voci possono essere di ausilio

nell'analisi della cronologia di quali risorse sono associate a una transazione. Non sonoutilizzate per applicare e rimuovere modifiche registrate su giornale. Il parametro delle vocigiornale da omettere (OMTJRNE) determina se il sistema scrive le voci di transazione.

v Si desidera migliorare le prestazioni per i lavori che chiudono file e li aprono nuovamente inun passo di instradamento. Se si chiudono tutti i file assegnati a un giornale che non è quellopredefinito, tutte le informazioni di sistema sul giornale vengono eliminate dal passo diinstradamento. Se un file assegnato a tale giornale viene aperto successivamente, tutte le


informazioni sul giornale devono essere create nuovamente. Il sistema conserva le informazionisul giornale predefinito con la definizione di commit, se qualche risorsa assegnata al giornale èattiva.

Parametro di testo del commitUtilizzare il parametro TEXT per identificare il testo specifico da associare a una definizione dicommit quando si visualizzano le informazioni sulle definizioni di commit avviate per un lavoro.Se non viene specificato del testo, il sistema fornisce una descrizione di testo predefinita.

Parametro di omissione di voci del giornaleSe si specifica un giornale predefinito per migliorare le prestazioni, è possibile utilizzare ilparametro OMTJRNE per impedire al sistema di scrivere delle voci di giornale della transazione.Quando il sistema scrive delle voci di transazione, la dimensione del ricevitore di giornaleaumenta notevolmente, con una conseguente riduzione delle prestazioni durante le operazioni dicommit e rollback.

Le voci di transazione possono essere utili durante la configurazione e la verifica dell'ambiente dicontrollo del commit o di una nuova applicazione.

Le voci di transazione vengono scritte nel giornale predefinito indipendentemente dal valore delparametro OMTJRNE quando si verificano le seguenti condizioni:v Si verifica un errore di sistema durante un'operazione di commit o rollback.v Viene apportata una modifica manuale a una risorsa che partecipava a una transazione e la

modifica ha causato una condizione euristica mista. Consultare la sezione Stati dellatransazione per il controllo del commit in due fasi per una descrizione della condizioneeuristica mista. Questo tipo di modifica manuale è detto decisione euristica.

È possibile utilizzare le informazioni che indicano quali risorse partecipavano alla transazione perdeterminare quale azione eseguire in queste situazioni.

È possibile utilizzare il programma di ricerca delle informazioni sulle voci del giornale pervisualizzare i layout dei dati specifici per le voci di giornale della transazione (controllo delcommit).

Concetti correlati

“Stati della transazione per il controllo del commit a due fasi” a pagina 31Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma ditransazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazionecorrente e della transazione precedente.Journal entry information finderAttività correlate

“Quando forzare le opzioni di commit e di rollback e quando annullare la risincronizzazione” a pagina117La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azioneabilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione cheè in uno stato Preparato.Riferimenti correlati


Oggetto di notifica del commitUn oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioniche identificano l'ultima transazione eseguita correttamente completata per una specifica definizione dicommit se tale definizione di commit non è stata terminata normalmente.

Le informazioni utilizzate per identificare l'ultima transazione eseguita correttamente per una definizionedi commit vengono fornite dall'identificazione di commit che associa un'operazione di commit a unaspecifica serie di modifiche di risorse di cui è possibile eseguire il commit.


L'identificazione di commit dell'ultima transazione eseguita correttamente per una definizione di commitviene inserita nell'oggetto di notifica solo se la definizione di commit non termina normalmente. Leinformazioni possono essere utilizzate per aiutare a determinare dove è terminata l'elaborazione diun'applicazione, in modo che l'applicazione può essere avviata nuovamente.

Per i lotti dischi indipendenti, l'oggetto di notifica deve trovarsi sullo stesso lotto dischi indipendente ogruppo di lotti dischi indipendenti della definizione di commit. Se si sposta la definizione di commit inun altro lotto dischi indipendente o gruppo di lotti dischi indipendenti, anche l'oggetto di notifica devetrovarsi sull'altro lotto dischi indipendente o gruppo di lotti dischi indipendenti. L'oggetto di notificasull'altro lotto dischi indipendente o gruppo di lotti dischi indipendenti viene aggiornato se si verificauna fine anomala della definizione di commit. Se l'oggetto di notifica non viene trovato sull'altro lottodischi indipendente o gruppo di lotti dischi indipendenti, l'aggiornamento ha esito negativo con ilmessaggio CPF8358.

Se le risorse registrate su giornale partecipano alla transazione corrente e viene eseguita un'operazione dicommit con un'identificazione di commit, l'identificazione di commit viene inserita nella voce di giornaledi commit (codice giornale e tipo di voce C CM) che identifica quella specifica transazione come in fasedi commit. Una voce di giornale di commit che contiene l'identificazione di commit viene inviata aciascun giornale associato alle risorse che partecipavano alla transazione.

La seguente tabella mostra come specificare l'identificazione di commit e la sua dimensione massima. Sesupera la sua dimensione massima, l'identificazione di commit viene troncata quando viene scrittanell'oggetto di notifica.

Linguaggio OperazioneNumero massimo di caratterinell'identificazione di commit

CL Comando COMMIT 3000 1

ILE (Integrated LanguageEnvironment) RPG

Codice operazione COMIT 4000 1

PLI Sottoroutine PLICOMMIT 4000 1

ILE C Funzione _Rcommit 4000 1

ILE COBOL Verbo COMMIT Non supportato

SQL Istruzione COMMIT Non supportato

Nota: 1Se l'oggetto di notifica è un'area dati, la dimensione massima è 2000 caratteri.

Quando un oggetto di notifica viene aggiornato con l'identificazione di commit, viene aggiornato nelseguente modo:

File di databaseSe un file di database viene utilizzato come l'oggetto di notifica, l'identificazione di commit vieneaggiunta alla fine del file. Eventuali record esistenti verranno lasciati nel file. Poiché è possibileche più utenti o lavori modifichino i record contemporaneamente, ciascuna identificazione dicommit nel file contiene delle informazioni univoche per associare i dati al lavoro e alladefinizione di commit per cui si è verificato l'esito negativo. Il file che funge da oggetto dinotifica può essere registrato su giornale

Area datiSe un'area dati viene utilizzata come oggetto di notifica, l'intero contenuto dell'area dati vienesostituito quando l'identificazione di commit viene inserita nell'area dati. Se più di un utente o unlavoro sta utilizzando lo stesso programma, solo l'identificazione di commit dall'ultimadefinizione di commit che non è terminata normalmente si troverà nell'area dati. Di conseguenza,un singolo oggetto di notifica di area dati potrebbe non produrre le informazioni corrette perriavviare i programmi applicativi. Per risolvere questo problema, utilizzare un'area dati separataper ciascuna definizione di commit per ciascun lavoro o utente della stazione di lavoro.


Coda messaggiSe una coda messaggi viene utilizzata come oggetto di notifica, il messaggio CPI8399 vieneinviato alla coda messaggi. L'identificazione di commit viene inserita nel testo di secondo livelloper il messaggio CPI8399. Come succede con l'utilizzo di un file di database per l'oggetto dinotifica, il contenuto di ciascuna identificazione di commit identifica in modo univoco unaspecifica definizione di commit per un lavoro in modo che un programma applicativo possaessere riavviato.

Concetti correlati

“Controllo del commit per le applicazioni batch” a pagina 27Le applicazioni batch possono richiedere o meno il controllo del commit. In alcuni casi, un'applicazionebatch può eseguire una singola funzione di lettura di un file di immissione e di aggiornamento di un filemaster. Tuttavia, è possibile utilizzare il controllo del commit per questo tipo di applicazione se èimportante avviarla nuovamente dopo una fine anomala.“Esempio: utilizzo di un oggetto di notifica per avviare un'applicazione” a pagina 94Quando viene avviato dopo una fine anomala, un programma può cercare una voce nell'oggetto dinotifica. Se la voce esiste, il programma può riavviare una transazione. Dopo che la transazione è stataavviata nuovamente, l'oggetto di notifica viene cancellato dal programma per evitare che avvii la stessatransazione un'ennesima volta.

Livello di blocco del commitIl valore specificato per il parametro LCKLVL nel comando STRCMTCTL (Avvio controllo commit)diventa il livello predefinito di blocco di record per i file di database aperti e posti sotto il controllo delcommit per la definizione di commit.

Il livello predefinito di blocco di record non può essere sovrascritto quando si aprono i file di databaselocali. Tuttavia, i file di database cui accede tramite SQL utilizzano il livello di isolamento SQL correnteeffettivo quando viene emessa la prima istruzione SQL su di essi.

Il livello di blocco deve essere specificato in base alle proprie esigenze, ai periodi di attesa consentiti ealle procedure di rilascio utilizzate con maggiore frequenza.

Le seguenti descrizioni si applicano solo ai file aperti sotto il controllo del commit:

Livello di blocco *CHGUtilizzare questo valore se si desidera proteggere i record modificati da modifiche apportate daaltri lavori in esecuzione contemporaneamente. Per i file aperti sotto il controllo del commit, ilblocco è mantenuto per la durata della transazione. Per i file non aperti sotto il controllo delcommit, il blocco sul record viene detenuto solo da quando il record viene letto a quando vienecompletata l'operazione di aggiornamento.

Livello di blocco *CSUtilizzare questo valore per proteggere sia i record modificati sia quelli richiamati da modificheapportate da altri lavori in esecuzione contemporaneamente. I record richiamati non modificatisono protetti solo fino a quando vengono rilasciati o a quando viene richiamato un recorddifferente.

Il livello di blocco *CS assicura che altri lavori non possano leggere per l'aggiornamento unrecord che è stato letto da questo lavoro. Inoltre, il programma non può leggere i record perl'aggiornamento che sono stati bloccati con un tipo di blocco di record di *UPDATE in un altrolavoro finché il lavoro non accede a un record differente.

Livello di blocco *ALLUtilizzare questo valore per proteggere i record modificati e i record richiamati che sono sotto ilcontrollo del commit dalle modifiche apportate da altri lavori in esecuzione sotto il controllo delcommit contemporaneamente. I record richiamati o modificati sono protetti fino alla successivaoperazione di commit o rollback.


Il livello di blocco *ALL assicura che altri lavori non possano accedere per l'aggiornamento a unrecord che è stato letto da questo lavoro. Questo è diverso dal normale protocollo di blocco.Quando il livello di blocco è specificato come *ALL, non è possibile accedere neppure a recordche non è letto per l'aggiornamento, se è bloccato con un tipo di blocco di record di *UPDATE inun altro lavoro.

La seguente tabella mostra la durata dei blocchi di record per i file sotto il controllo del commit, o meno.

Richiesta Parametro LCKLVL Durata del blocco Tipo di blocco

Sola lettura Nessun controllo delcommit

Nessun blocco Nessuno

*CHG Nessun blocco Nessuno

*CS Da lettura a rollback,commit o lettura successivi

*READ

*ALL Da lettura a commit orollback

*READ

Lettura per aggiornamentoquindi aggiornamento ocancellazione1

Nessun controllo delcommit

Da lettura adaggiornamento ocancellazione

*UPDATE

*CHG Da lettura adaggiornamento ocancellazione

*UPDATE

Quindi da aggiornamento ocancellazione a rollback ocommit successivi2

*UPDATE

*CS Da lettura adaggiornamento ocancellazione

*UPDATE


*UPDATE

*ALL Da lettura adaggiornamento ocancellazione

*UPDATE


Lettura per aggiornamentoquindi rilascio1

Nessun controllo delcommit

Da lettura a rilascio *UPDATE

*CHG Da lettura a rilascio *UPDATE

*CS Da lettura a rilascio,commit o rollback

*UPDATE

Quindi da rilascio arollback, commit o letturasuccessivi

*UPDATE

*ALL Da lettura a rilascio,commit o rollback

*UPDATE

Quindi da rilascio arollback o commitsuccessivi


Richiesta Parametro LCKLVL Durata del blocco Tipo di blocco

Aggiunta Nessun controllo delcommit

Nessun blocco Nessuno

*CHG Da aggiunta a commit orollback

*UPDATE

*CS Da aggiunta a commit orollback

*UPDATE

*ALL Da aggiunta a commit orollback

*UPDATE

Scrittura diretta Nessun controllo delcommit

Per la durata della scritturadiretta

*UPDATE

*CHG Da scrittura diretta acommit o rollback

*UPDATE

*CS Da scrittura diretta acommit o rollback

*UPDATE

*ALL Da scrittura diretta acommit o rollback

*UPDATE

Note:

1Se un'operazione di commit o di rollback viene eseguita dopo un'operazione di lettura per l'aggiornamento maprima che il record venga aggiornato, cancellato o rilasciato, il record viene sbloccato durante l'operazione dicommit o di rollback. La protezione sul record non è più disponibile appena viene completato il commit o ilrollback.

2Se un record viene cancellato ma il commit o il rollback non è stato ancora emesso per la transazione, il recordcancellato non rimane bloccato. Se lo stesso lavoro, o uno differente, prova a leggere il record cancellato in base allachiave, tale lavoro riceve un'indicazione di record non trovato. Tuttavia, se esiste un percorso di accesso a chiaveunivoca sul file, a un altro lavoro non è consentito inserire o aggiornare un record con lo stesso valore di chiaveunivoca del record cancellato finché non sarà stato eseguito il commit della transazione.

Un tipo di blocco di record di *READ viene ottenuto sui record che non sono letti per l'aggiornamentoquando il livello di blocco è *CS o *ALL. Questo tipo di blocco impedisce ad altri lavori di leggere irecord per l'aggiornamento ma non impedisce l'accesso ai record da parte di un'operazione di sola lettura.

Un tipo di blocco di record di *UPDATE viene ottenuto sui record che vengono aggiornati, cancellati,aggiunti o letti per l'aggiornamento. Questo tipo di blocco impedisce ad altri lavori di leggere i record perl'aggiornamento e impedisce ai lavori in esecuzione sotto il controllo del commit con un livello di bloccodi record di *CS o *ALL di accedere ai record anche per un'operazione di sola lettura.

I programmi che non stanno utilizzando il controllo del commit possono leggere i record bloccati da unaltro lavoro ma non possono leggere i record per l'aggiornamento, indipendentemente dal valorespecificato per il parametro LCKLVL.

Il livello di blocco, specificato per una definizione di commit quando viene avviato il controllo delcommit per un gruppo di attivazione o per il lavoro, si applica solo alle aperture associate a tale specificadefinizione di commit.

Nota: i valori di livello di blocco *CS e *ALL proteggono dal richiamo di un record che ha attualmenteuna modifica in sospeso da un lavoro differente. Tuttavia, i valori di livello di blocco *CS e *ALLnon proteggono dal richiamo di un record utilizzando un programma in esecuzione in un gruppodi attivazione che attualmente ha una modifica in sospeso da un programma in esecuzione in ungruppo di attivazione differente nello stesso lavoro.


Nello stesso lavoro, un programma può modificare un record che è già stato modificato nella transazionecorrente a condizione che al record si acceda nuovamente utilizzando la stessa definizione di commit.Quando si utilizza la definizione di commit a livello di lavoro, l'accesso al record modificato può essereeseguito da un programma in esecuzione in un gruppo di attivazione che sta utilizzando la definizione dicommit a livello di lavoro.Concetti correlati

“Considerazioni e limitazioni per il controllo del commit” a pagina 25È necessario tenere presente le seguenti considerazioni e limitazioni per il controllo del commit.Riferimenti correlati


Terminazione del controllo del commitIl comando ENDCMTCTL (Fine controllo commit) termina il controllo del commit per la definizione dicommit a livello di gruppo di attivazione o a livello di lavoro.

L'immissione del comando ENDCMTCTL indica al sistema che la definizione di commit utilizzata dalprogramma che esegue la richiesta deve essere terminata. Il comando ENDCMTCTL termina una soladefinizione di commit per il lavoro e tutte le altre definizioni di commit per il lavoro rimangonoinvariate.

Se la definizione di commit a livello di gruppo di attivazione viene terminata, i programmi in esecuzionenel gruppo di attivazione non possono più apportare modifiche sotto il controllo del commit, a meno chela definizione di commit a livello di lavoro non sia già avviata per il lavoro. Se la definizione di commit alivello di lavoro è attiva, viene immediatamente resa disponibile per l'utilizzo da parte dei programmi inesecuzione nel gruppo di attivazione che hanno appena terminato il controllo del commit.

Se la definizione di commit a livello di lavoro viene terminata, gli eventuali programmi in esecuzione nellavoro che stavano utilizzando la definizione di commit a livello di lavoro non possono più apportaremodifiche sotto il controllo del commit senza prima riavviare il controllo del commit con il comandoSTRCMTCTL.

Prima di immettere il comando ENDCMTCTL, è necessario soddisfare le seguenti condizioni per ladefinizione di commit da terminare:v Devono prima essere chiusi tutti i file aperti sotto il controllo del commit per la definizione di commit

da terminare. Quando si termina la definizione di commit a livello di lavoro, l'operazione include tuttii file aperti sotto il controllo del commit da qualsiasi programma in esecuzione in qualsiasi gruppo diattivazione che sta utilizzando la definizione di commit a livello di lavoro.

v Devono prima essere rimosse tutte le risorse di commit API per la definizione di commit da terminareutilizzando l'API QTNRMVCR. Quando si termina la definizione di commit a livello di lavoro, questaoperazione include tutte le risorse di commit API aggiunte da qualsiasi programma in esecuzione inqualsiasi gruppo di attivazione che sta utilizzando la definizione di commit a livello di lavoro.

v Un database remoto associato alla definizione di commit da terminare deve essere disconnesso.v Tutte le conversazioni protette associate alla definizione di commit devono essere terminate

normalmente utilizzando il corretto livello di sincronizzazione.

Se si sta terminando il controllo del commit in un lavoro interattivo e una o più risorse di cui è possibileeseguire il commit associate alla definizione di commit hanno delle modifiche in sospeso, il messaggio diinterrogazione CPA8350 viene inviato all'utente richiedendo se eseguire il commit delle modifiche insospeso, il rollback delle modifiche in sospeso o l'annullamento della richiesta ENDCMTCTL.

Se si sta terminando il controllo del commit in un lavoro batch, e uno o più file chiusi associati alladefinizione di commit da terminare hanno ancora delle modifiche in sospeso, viene eseguito il rollbackdelle modifiche e viene inviato un messaggio:


v CPF8356 se sono registrate solo le risorse localiv CPF835C se sono registrate solo le risorse remotev CPF83E4 se sono registrate sia le risorse locali sia quelle remote

Se per la definizione di commit in fase di terminazione è definito un oggetto di notifica, ne potrebbeessere eseguito l'aggiornamento.

Quando un gruppo di attivazione che ha un'API registrata come ultimo agent sta terminando, ilprogramma di uscita per l'API viene richiamato per ricevere la decisione di commit o di rollback. Inquesto caso, anche se il gruppo di attivazione sta terminando normalmente, è comunque possibile cheuna richiesta di rollback venga restituita dal programma di uscita API. È pertanto possibile chel'operazione di commit implicito non venga eseguita.

Dopo che la definizione di commit è terminata normalmente, è stato eseguito tutto l'eventuale ripristinonecessario. Non viene eseguito alcun ripristino aggiuntivo per le risorse di commit associate alladefinizione di commit appena terminata.

Dopo che la definizione di commit è terminata, la definizione di commit a livello di gruppo di attivazioneo a livello di lavoro può essere quindi riavviata per i programmi in esecuzione nel gruppo di attivazione.La definizione di commit a livello di lavoro può essere avviata solo se non è stata già avviata per illavoro.

Anche se le definizioni di commit possono essere avviate e terminate molte volte dai programmi inesecuzione in un gruppo di attivazione, la quantità di risorse di sistema richiesta per le ripetuteoperazioni di avvio e terminazione può causare una riduzione delle prestazioni del lavoro e delleprestazioni generali del sistema. Si consiglia pertanto di lasciare attiva una definizione di commit se unprogramma da richiamare successivamente ne farà uso.Concetti correlati

“Aggiornamenti all'oggetto di notifica” a pagina 65Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commiteseguita correttamente per tale definizione di commit.Riferimenti correlati

End Commitment Control (ENDCMTCTL) command

Terminazione avviata dal sistema del controllo del commitIl sistema può terminare il controllo del commit oppure eseguire un'operazione di rollback o commitimplicito. A volte, la terminazione avviata dal sistema del controllo del commit è normale. Altre volte, ilcontrollo del commit termina con una fine lavoro o sistema anomala.

Controllo del commit durante la fine del gruppo di attivazioneIl sistema termina automaticamente una definizione di commit a livello di gruppo di attivazione quandotermina un gruppo di attivazione.

Se esistono delle modifiche in sospeso per una definizione di commit a livello di gruppo di attivazione eil gruppo di attivazione sta terminando in modo normale, il sistema esegue un'operazione di commitimplicito per la definizione di commit prima che venga terminata. Altrimenti, un'operazione di rollbackimplicito viene eseguita per la definizione di commit a livello di gruppo di attivazione prima che vengaterminata se il gruppo di attivazione sta terminando in modo anomalo o se il sistema ha rilevato deglierrori durante la chiusura di file aperti sotto il controllo del commit che erano nell'ambito del gruppo diattivazione.

Nota: un'operazione di rollback o di commit implicito non viene mai eseguita durante l'elaborazionedella fine del gruppo di attivazione per le definizioni di commit *JOB o *DFTACTGRP. Questo è


dovuto al fatto che le definizioni di commit *JOB e *DFTACTGRP non vengono mai terminateperché viene terminato un gruppo di attivazione. Queste definizioni di commit vengono inveceterminate in modo esplicito con un comando ENDCMTCTL oppure terminate dal sistema quandotermina il lavoro.

Il sistema chiude automaticamente i file che erano nell'ambito del gruppo di attivazione quando terminail gruppo di attivazione. Questo include i file di database che erano nell'ambito del gruppo di attivazioneaperto sotto il controllo del commit. La chiusura per questo tipo di file si verifica prima dell'esecuzione dieventuali operazioni di commit implicito per la definizione di commit a livello di gruppo di attivazione.Pertanto, i record che non si trovano in un buffer I/E vengono forzati nel database prima che venganoeseguite eventuali operazioni di commit implicito.

Come parte dell'operazione di rollback o commit implicito che potrebbe essere eseguita, viene fatta unachiamata al programma di uscita di rollback o di commit API per ciascuna risorsa di commit APIassociata alla definizione di commit a livello di gruppo di attivazione. Il programma di uscita devecompletare la sua elaborazione entro 5 minuti. Dopo il richiamo del programma di uscita di rollback o dicommit API, il sistema elimina automaticamente la risorsa di commit API.

Se un'operazione di rollback implicito viene eseguita per una definizione di commit che è in fase diterminazione perché è in fase di terminazione un gruppo di attivazione, l'oggetto di notifica, se ne èdefinito uno per la definizione di commit, potrebbe essere aggiornato.Concetti correlati

“Aggiornamenti all'oggetto di notifica” a pagina 65Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commiteseguita correttamente per tale definizione di commit.

Operazioni di commit e di rollback implicitiIn alcune istanze, un'operazione di commit o di rollback viene avviata dal sistema per una definizione dicommit. Questi tipi di operazioni di commit e di rollback sono noti come richieste di commit e rollbackimplicite.

Di norma, un'operazione di commit o di rollback viene avviata da un programma applicativo utilizzandouno dei linguaggi di programmazione disponibili che supporta il controllo del commit. Questi tipi dioperazioni di commit e di rollback sono noti come richieste di commit e rollback esplicite.

Le seguenti due tabelle mostrano cosa fa il sistema quando si verificano determinati eventi correlati a unadefinizione di commit che ha delle modifiche in sospeso. Una definizione di commit ha delle modifichein sospeso se si verifica una delle seguenti condizioni:v Una risorsa di cui è possibile eseguire il commit è stata aggiornata.v Un file di database aperto sotto il controllo del commit è stato letto perché la lettura di un file ne

modifica la posizione.v La definizione di commit ha una risorsa API. Poiché le modifiche alle risorse API vengono eseguite da

un programma utente, il sistema deve presumere che tutte le risorse API abbiano delle modifiche insospeso.

Le voci di giornale C CM (operazione di commit) e C RB (operazione di rollback) indicano sel'operazione era esplicita o implicita.

La seguente tabella mostra le azioni eseguite dal sistema quando un lavoro termina, in modo normale oanomalo, sulla base delle seguenti situazioni:v Lo stato della transazione.v Il valore di azione in caso di fine lavoro per la definizione di commit.v Se una risorsa API è l'ultimo agent.


Stato API ultimo agentopzione Azione incaso di fine lavoro1 Operazione di commit o di rollback

RST N/A N/A Se la definizione di commit non è associataa una transazione globale X/Open, vieneeseguito un rollback implicito.

Se la definizione di commit è associata auna transazione globale X/Open, siverificano i seguenti eventi:

v Se lo stato del ramo transazione non èAttivo (S1), non viene eseguita alcunaazione e il ramo transazione viene lasciatonello stesso stato.

v Se lo stato del ramo transazione è Attivo(S1), viene eseguito un rollback implicito.

PIP N/A N/A Se la definizione di commit non è associataa una transazione globale X/Open, vieneeseguito un rollback implicito.

Se la definizione di commit è associata auna transazione globale X/Open, il ramotransazione si trova nello stato Inattivo (S2)e viene lasciato nello stato Inattivo (S2).

PRP N/A WAIT Se la definizione di commit non è associataa una transazione globale X/Open2, siverifica quanto segue:

v La risincronizzazione viene avviata perricevere la decisione dall'iniziatoredell'operazione di commit.

v Viene eseguita la decisione restituita dieseguire il commit o il rollback. Vieneconsiderata un'operazione esplicita.

PRP N/A C Se la definizione di commit non è associataa una transazione globale X/Open2, vieneeseguita un'operazione di commit implicito.

R Se la definizione di commit non è associataa una transazione globale X/Open, vieneeseguita un'operazione di rollback implicito.

Se la definizione di commit è associata auna transazione globale X/Open, si verificaquanto segue:

v Se il lavoro che ha avviato la transazioneviene terminato, la transazione vienelasciata in uno stato preparato finché l'XATM non ne esegue il commit o il rollback.Lo stato del ramo transazione XA saràlasciato come Preparato (S3), in questocaso.

v Se il lavoro del server SQL cui si stainstradando il lavoro della transazioneviene terminato, viene eseguito in modoimplicito un rollback forzato. Lo stato delramo transazione XA verrà modificato inCompletato euristicamente (S5), in questocaso.


Stato API ultimo agentopzione Azione incaso di fine lavoro1 Operazione di commit o di rollback

CIP N/A N/A Viene eseguita un'operazione di commitesplicito.

LAP NO WAIT 1. La risincronizzazione all'ultimo agentviene utilizzata per richiamare la decisionedi eseguire il commit o il rollback.

2. Viene eseguita la decisione restituita dieseguire il commit o il rollback. Vieneconsiderata un'operazione esplicita.

LAP SÌ WAIT 1. L'API dell'ultimo agent viene richiamataper richiamare la decisione di commit o dirollback.

2. Viene eseguita l'operazione di commit odi rollback. Viene considerata un'operazioneesplicita.

LAP N/A C Viene eseguita un'operazione di commitimplicito.

R Viene eseguita un'operazione di rollbackimplicito.

CMT N/A N/A Un'operazione di commit è già statacompletata per questa definizione di commited eventuali ubicazioni successive.L'operazione di commit è completa.

VRO N/A N/A Gli agent locali e remoti hanno fornitol'indicazione per la sola lettura. Anche tuttigli agent successivi devono avere fornitol'indicazione per la sola lettura. Nessunaazione richiesta.

RBR N/A N/A È richiesta un'operazione di rollback. Vieneeseguita un'operazione di rollback esplicito.

Nota:

1 È possibile modificare l'opzione Azione in caso di fine lavoro con l'API QTNCHGCO (Modifica opzioni dicommit).

2Se la definizione di commit è associata a una transazione globale X/Open, si verificano i seguenti eventi:

v Se il lavoro che ha avviato la transazione viene terminato, la transazione viene lasciata in uno stato preparatofinché l'XA TM non ne esegue il commit o il rollback. Lo stato del ramo transazione XA sarà lasciato comePreparato (S3), in questo caso.

v Solo per i blocchi nell'ambito della transazione, se il lavoro del server SQL cui si sta instradando il lavoro dellatransazione viene terminato, viene eseguito in modo implicito un rollback forzato. Lo stato del ramo transazioneXA verrà modificato in Completato euristicamente (S5), in questo caso.

La seguente tabella mostra le azioni eseguite dal sistema quando un gruppo di attivazione termina e siapplica solo alle transazioni con dei blocchi nell'ambito del lavoro. Le azioni di sistema sono basate suiseguenti elementi:v Lo stato della transazione. (È sempre reimpostato (RST) quando termina un gruppo di attivazione).v Il modo in cui termina il gruppo di attivazione: normalmente o in modo anomalo.v Se una risorsa API è l'ultimo agent.


Nota: se una risorsa API è registrata come ultimo agent, questo dà il controllo della decisione diesecuzione del commit o del rollback all'ultimo agent. Il risultato della decisione è consideratoun'operazione esplicita

Stato API ultimo agent Tipo di terminazione Operazione di commit o di rollback

RST No Normale Viene eseguita un'operazione di commitimplicito. Se esistono delle conversazioniprotette, la definizione di commit diventeràl'iniziatore root dell'operazione di commit.

RST No Anomalo Viene eseguito un ripristino implicito.

RST Sì Normale Viene richiamato il programma di uscitaAPI. L'operazione di commit o di rollbackviene determinata dall'API.

RST Sì Anomalo Viene richiamato il programma di uscitaAPI. L'operazione di commit o di rollbackviene determinata dall'API.

Concetti correlati

“Controllo del commit durante la fine anomala di lavoro o sistema” a pagina 64Il sistema termina tutte le definizioni di commit per un lavoro quando il lavoro termina in modoanomalo. Queste definizioni di commit vengono terminate durante l'elaborazione della fine lavoro.Questo argomento è valido solo per le definizioni di commit con i blocchi nell'ambito del lavoro.Riferimenti correlati


Controllo del commit durante la terminazione normale del passo diinstradamentoIl sistema termina tutte le definizioni di commit per un lavoro quando un passo di instradamento vieneterminato normalmente.

Nota: le seguenti informazioni si applicano solo alle definizioni di commit con i blocchi nell'ambito dellavoro.

Un passo di instradamento termina normalmente con una delle seguenti situazioni:v Una terminazione normale per un lavoro batch.v Uno scollegamento normale per un lavoro interattivo.v Il comando RRTJOB (Reinstradamento lavoro), TFRJOB (Trasferimento lavoro) o TFRBCHJOB

(Trasferimento lavoro batch) termina il passo di instradamento corrente e avvia un nuovo passo diinstradamento.

Qualsiasi altra terminazione di un passo di instradamento è considerata anomala e viene riconosciuta inbase a un codice di completamento diverso da zero nel messaggio di completamento del lavoro CPF1164nella registrazione lavoro.

Prima di terminare una definizione di commit durante la terminazione del passo di instradamento, ilsistema esegue un'operazione di rollback implicito se la definizione di commit ha delle modifiche insospeso. Questo include il richiamo del programma di uscita di rollback o di commit API per ciascunarisorsa di commit API associata alla definizione di commit. Il programma di uscita deve completare lasua elaborazione entro 5 minuti. Dopo il richiamo del programma di uscita di rollback o di commit API,il sistema elimina automaticamente la risorsa di commit API.

Se per la definizione di commit è definito un oggetto di notifica, ne potrebbe essere eseguitol'aggiornamento.


Concetti correlati

“Aggiornamenti all'oggetto di notifica” a pagina 65Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commiteseguita correttamente per tale definizione di commit.

Controllo del commit durante la fine anomala di lavoro o sistemaIl sistema termina tutte le definizioni di commit per un lavoro quando il lavoro termina in modoanomalo. Queste definizioni di commit vengono terminate durante l'elaborazione della fine lavoro.Questo argomento è valido solo per le definizioni di commit con i blocchi nell'ambito del lavoro.

Se viene terminato in modo anomalo, il sistema termina tutte le definizioni di commit che erano stateavviate e che tutti i lavori attivi stavano utilizzando quando si è verificata la fine di sistema anomala.Queste definizioni di commit vengono terminate come parte dell'elaborazione di ripristino del databaseeseguita durante il successivo IPL dopo la fine anomala di sistema.

Attenzione: il ripristino per le definizioni di commit fa riferimento a una fine anomala per il sistema oper un lavoro dovuta a un'interruzione dell'alimentazione, un malfunzionamento hardware o un errorenel sistema operativo o nel LIC (Licensed Internal Code - Microprogramma interno su licenza). Non sideve utilizzare il comando ENDJOBABN (Fine anomala del lavoro) per forzare una fine anomala dellavoro. La fine anomala può determinare un commit o un rollback parziale delle modifiche in sospeso perle transazioni attive per il lavoro che si sta terminando. Il successivo IPL potrebbe tentare il ripristino perle eventuali transazioni parziali per il lavoro terminato con il comando ENDJOBABN.

L'esito del ripristino del controllo del commit eseguito dal sistema durante un IPL per un lavoroterminato con il comando ENDJOBABN è incerto. Questo è dovuto al fatto che tutti i blocchi per larisorsa di commit vengono rilasciati quando il lavoro viene terminato in modo anomalo. Le eventualimodifiche in sospeso dovute a transazioni parziali vengono rese disponibili ad altri lavori. Questemodifiche in sospeso possono quindi indurre atri programmi applicativi ad apportare delle erroneemodifiche aggiuntive al database. In modo analogo, qualsiasi ripristino IPL derivante che viene eseguitosuccessivamente può influenzare negativamente le modifiche apportate dalle applicazioni dopo che illavoro è stato terminato in modo anomalo. Ad esempio, una tabella SQL potrebbe essere cancellatadurante il ripristino IPL come azione di rollback per una creazione tabella in sospeso. Tuttavia, altreapplicazioni potrebbero già avere inserito diverse righe nella tabella dopo che il lavoro è stato terminatoin modo anomalo.

Il sistema esegue le seguenti operazioni per le definizioni di commit terminate durante una fine lavoroanomala o durante il successivo IPL dopo una fine sistema anomala:v Prima di terminare una definizione di commit, il sistema esegue un'operazione di rollback implicito se

la definizione di commit ha delle modifiche in sospeso, a meno che l'elaborazione per la definizione dicommit non sia stata interrotta durante un'operazione di commit. Se è stata terminata duranteun'operazione di commit, la transazione potrebbe essere sottoposta a rollback, risincronizzazione ocommit, a seconda del suo stato. L'elaborazione per eseguire l'operazione di rollback implicito o percompletare l'operazione di commit include il richiamo del programma di uscita di commit e rollbackAPI per ciascuna risorsa di commit API associata alla definizione di commit. Dopo il richiamo delprogramma di uscita di rollback o di commit API, il sistema elimina automaticamente la risorsa dicommit API.


Attenzione: terminare il lavoro mentre una transazione è in dubbio (lo stato transazione è LAP oPRP) può causare delle incongruenze nel database (le modifiche potrebbero essere state sottoposte acommit su uno o più sistemi e a rollback su altri sistemi).– Se l'opzione di commit Azione in caso di fine lavoro è COMMIT, le modifiche su questo sistema

vengono sottoposte a commit se il lavoro viene terminato, indipendentemente dal fatto che lemodifiche su altri sistemi che partecipano alla transazione vengano sottoposte a commit o a rollback.

– Se l'opzione di commit Azione in caso di fine lavoro è ROLLBACK, le modifiche su questo sistemavengono sottoposte a rollback se il lavoro viene terminato, indipendentemente dal fatto che lemodifiche su altri sistemi che partecipano alla transazione vengono sottoposti a commit o a rollback.

– Se l'opzione di commit Azione in caso di fine lavoro è WAIT, il lavoro verrà terminato solo dopo chesarà stata completata la risincronizzazione con il sistema proprietario della decisione di commit o dirollback. Per fare in modo che il lavoro venga terminato prima del completamento dellarisincronizzazione, è necessario eseguire un'operazione di decisione euristica e annullare larisincronizzazione.

Si sconsiglia di terminare il lavoro o il sistema in modo anomalo durante un rollback a lungaesecuzione. Questo causa l'esecuzione di un altro rollback quando termina il lavoro (oppure durante ilsuccessivo IPL, se viene terminato il sistema). Il successivo rollback ripeterà il lavoro eseguito dalrollback originario e avrà un tempo di esecuzione molto più lungo.

v Se per la definizione di commit è definito un oggetto di notifica, ne potrebbe essere eseguitol'aggiornamento.

Se il processo termina prima che il controllo del commit venga terminato e sono ancora attive delleconversazioni protette, potrebbe essere richiesto il commit o il rollback della definizione di commit.L'azione è basata sull'opzione Stato e sull'opzione Azione in caso di fine lavoro per la definizione dicommit.Concetti correlati

“Operazioni di commit e di rollback impliciti” a pagina 60In alcune istanze, un'operazione di commit o di rollback viene avviata dal sistema per una definizione dicommit. Questi tipi di operazioni di commit e di rollback sono noti come richieste di commit e rollbackimplicite.“Aggiornamenti all'oggetto di notifica”Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commiteseguita correttamente per tale definizione di commit.

Aggiornamenti all'oggetto di notificaIl sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione di commiteseguita correttamente per tale definizione di commit.

Per gli scopi dell'oggetto di notifica, queste sono considerate modifiche di cui non è stato eseguito ilcommit:v Un aggiornamento a un record eseguito sotto il controllo del commit.v Un record cancellato sotto il controllo del commit.v Una modifica a livello di oggetto eseguita su un oggetto DDL locale sotto il controllo del commit.v Un'operazione di lettura eseguita per un file di database che è stato aperto sotto il controllo del

commit. Questo è dovuto al fatto che la posizione del file viene riportata all'ultimo limite di commitquando viene eseguita un'operazione di rollback. Se si esegue un'operazione di lettura sotto il controllodel commit, la posizione del file viene modificata e, pertanto, esisterà una modifica di cui non è statoeseguito il commit per la definizione di commit.

v Una definizione di commit con una delle seguenti risorse aggiunte viene sempre considerata come sepresentasse delle modifiche di cui non è stato eseguito il commit:– Una risorsa di commit API


– Una risorsa DRDA * (Distributed Relational Database Architecture) remota– Una risorsa Distributed Database Management Architecture (DDM)– Una risorsa LU 6.2Questo è dovuto al fatto che il sistema non sa quando una vera modifica viene apportata all'oggetto oagli oggetti associati a questi tipi di risorse. La sezione Tipi di risorse di cui è possibile eseguire ilcommit contiene maggiori informazioni su come si aggiungono e gestiscono questi tipi di risorse.

Il sistema applica gli aggiornamenti all'oggetto di notifica in base ai seguenti modi in cui può terminareuna definizione di commit:v Se un lavoro termina normalmente e non esistono modifiche di cui non è stato eseguito il commit, il

sistema non inserisce l'identificazione di commit dell'ultima operazione di commit eseguitacorrettamente nell'oggetto di notifica.

v Se viene eseguita un'operazione di commit implicito per una definizione di commit a livello di gruppodi attivazione quando viene terminato il gruppo di attivazione, il sistema non inserisce l'identificazionedi commit dell'ultima operazione di commit eseguita correttamente nell'oggetto di notifica.

Nota: le operazioni di commit implicite non vengono mai eseguite per la definizione di commit*DFTACTGRP o *JOB

v Se il sistema, il lavoro o un gruppo di attivazione termina in modo anomalo prima della primaoperazione di commit eseguita correttamente per una definizione di commit, il sistema non aggiornal'oggetto di notifica perché non c'è alcuna identificazione di ultimo commit. Per distinguere tra questacondizione e un completamento di programma normale, il programma deve aggiornare l'oggetto dinotifica con una specifica voce prima di completare la prima operazione di commit eseguitacorrettamente per la definizione di commit.

v Se si verifica una fine lavoro anomala o una terminazione di sistema anomala dopo almenoun'operazione di commit eseguita correttamente, il sistema inserisce l'identificazione di commit di taleoperazione di commit nell'oggetto di notifica. Se l'ultima operazione di commit eseguita correttamentenon specificava un'identificazione di commit, l'oggetto di notifica non viene aggiornato. Per una finelavoro anomala, questa elaborazione di oggetto di notifica viene eseguita per ciascuna definizione dicommit che era attiva per il lavoro. Per una terminazione di sistema anomala, questa elaborazione dioggetto di notifica viene eseguita per ciascuna definizione di commit che era attiva per tutti i lavori sulsistema.

v Il sistema aggiorna l'oggetto di notifica con l'identificazione di commit dell'ultima operazione dicommit eseguita correttamente per tale definizione di commit se si verificano tutti gli eventi qui diseguito indicati:– Viene terminato un gruppo di attivazione non predefinito.– Un'operazione di rollback implicito viene eseguita per la definizione di commit a livello di gruppo

di attivazione.– Almeno un'operazione di commit eseguita correttamente è stata eseguita per tale definizione di

commit.Se l'ultima operazione di commit eseguita correttamente non specificava un'identificazione di commit,l'oggetto di notifica non viene aggiornato. Un'operazione di rollback implicito viene eseguita per unadefinizione di commit a livello di gruppo di attivazione se il gruppo di attivazione sta terminando inmodo anomalo o se si sono verificati degli errori durante la chiusura dei file che erano stati aperti sottoil controllo del commit e che erano nell'ambito di tale gruppo di attivazione. Per ulteriori informazionisull'inclusione dei file di database nell'ambito di gruppi di attivazione e sul modo in cui possono essereterminati i gruppi di attivazione, consultare il manuale di riferimento per il linguaggio ILE che si stautilizzando.

v Se esistono delle modifiche di cui non è stato eseguito il commit quando un lavoro termina in modonormale ed è stata eseguita almeno un'operazione di commit correttamente, l'identificazione di commitdell'ultima operazione di commit eseguita correttamente viene inserita nell'oggetto di notifica e vieneeseguito il rollback delle modifiche di cui non è stato eseguito il commit. Se l'ultima operazione dicommit eseguita correttamente non specificava un'identificazione di commit, l'oggetto di notifica non


viene aggiornato. Questa elaborazione di oggetto di notifica viene eseguita per ciascuna definizione dicommit che era attiva per il lavoro quando il lavoro è stato terminato.

v Se esistono delle modifiche di cui non è stato eseguito il commit quando viene eseguito il comandoENDCMTCTL, l'oggetto di notifica viene aggiornato solo se l'ultima operazione di commit eseguitacorrettamente specificava un'identificazione di commit:– Per un lavoro batch, viene eseguito il rollback delle modifiche di cui non è stato eseguito il commit e

l'identificazione di commit dell'ultima operazione di commit eseguita correttamente viene inseritanell'oggetto di notifica.

– Per un lavoro interattivo, se la risposta al messaggio di interrogazione CPA8350 è l'esecuzione delrollback delle modifiche, viene eseguito il rollback delle modifiche di cui non è stato eseguito ilcommit e l'identificazione di commit dell'ultima operazione di commit eseguita correttamente vieneinserita nell'oggetto di notifica.

– Per un lavoro interattivo, se la risposta al messaggio di interrogazione CPA8350 è l'esecuzione delcommit delle modifiche, il sistema chiede un'identificazione di commit da utilizzare e viene eseguitoil commit delle modifiche. L'identificazione di commit immessa sul pannello di richiesta vieneinserita nell'oggetto di notifica.

– Per un lavoro interattivo, se la risposta al messaggio di interrogazione CPA8350 è l'annullamentodella richiesta ENDCMTCTL, le modifiche in sospeso restano e l'oggetto di notifica non vieneaggiornato.

Concetti correlati

“Terminazione del controllo del commit” a pagina 58Il comando ENDCMTCTL (Fine controllo commit) termina il controllo del commit per la definizione dicommit a livello di gruppo di attivazione o a livello di lavoro.“Controllo del commit durante la fine del gruppo di attivazione” a pagina 59Il sistema termina automaticamente una definizione di commit a livello di gruppo di attivazione quandotermina un gruppo di attivazione.“Controllo del commit durante la terminazione normale del passo di instradamento” a pagina 63Il sistema termina tutte le definizioni di commit per un lavoro quando un passo di instradamento vieneterminato normalmente.“Controllo del commit durante la fine anomala di lavoro o sistema” a pagina 64Il sistema termina tutte le definizioni di commit per un lavoro quando il lavoro termina in modoanomalo. Queste definizioni di commit vengono terminate durante l'elaborazione della fine lavoro.Questo argomento è valido solo per le definizioni di commit con i blocchi nell'ambito del lavoro.“Tipi di risorse di cui è possibile eseguire il commit” a pagina 12Questa tabella elenca i tipi differenti di risorse di cui è possibile eseguire il commit, inclusi FILE, DDL(Data Definition Language), DDM (distributed data management), LU (logical unit) 6.2, DRDA(Distributed Relational Database Architecture, API e TCP.“Oggetto di notifica del commit” a pagina 53Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioniche identificano l'ultima transazione eseguita correttamente completata per una specifica definizione dicommit se tale definizione di commit non è stata terminata normalmente.

Ripristino del controllo del commit durante l'IPL (initial program load)dopo la fine anomalaQuando si esegue un IPL (initial program load) dopo la fine anomala del sistema, il sistema prova aripristinare tutte le definizioni di commit che erano attive quando il sistema è stato terminato.

In modo analogo, quando si attiva un lotto dischi indipendente, il sistema prova a ripristinare tutte ledefinizioni di commit correlate a tale lotto dischi indipendente che erano attive quando è stato disattivatoo terminato in modo anomalo.


Il ripristino viene eseguito dai lavori del server di database avviati dal sistema durante l'IPL. I lavori delserver di database vengono avviati dal sistema per gestire le operazioni che non possono o non devonoessere eseguite da altri lavori.

I lavori del server di database sono denominati QDBSRVnn, dove nn è un numero di due cifre. Il numerodi lavori del server di database dipende dalla dimensione del sistema. In modo analogo, il nome dellavoro del server di database per un lotto dischi indipendente o un gruppo di lotti dischi indipendenti èQDBSxxxVnn, dove xxx è il numero di lotto dischi indipendente e nn è un numero di due cifre. Adesempio, QDBS035V02 può essere il nome del lavoro del server di database per il lotto dischiindipendente 35.

La sezione Stati della transazione per il controllo del commit in due fasi mostra le azioni eseguite dalsistema, a seconda dello stato della transazione quando si è verificato il malfunzionamento. Per due stati,PRP e LAP, l'azione di sistema è in dubbio.

Note:

v Le seguenti informazioni si applicano solo alle definizioni di commit con i blocchi nell'ambitodel lavoro.

v Il gestore transazioni ripristina le definizioni di commit associate alle transazioni XA (sia se iloro blocchi sono nell'ambito del lavoro sia se sono nell'ambito della transazione) utilizzando leAPI XA, non il processo di risincronizzazione descritto in questo argomento.

Il sistema non può determinare cosa fare finché non esegue la risincronizzazione con le altre ubicazioniche partecipano alla transazione. Questa risincronizzazione viene eseguita dopo il completamento dell'IPLo dell'operazione di attivazione.

Il sistema utilizza i lavori del server di database per eseguire questa risincronizzazione. Le definizioni dicommit che devono essere ripristinate sono associate ai lavori del server di database. Durante l'IPL, ilsistema acquisisce tutti i blocchi di record e gli altri blocchi di oggetti che erano detenuti dalla definizionedi commit prima della terminazione del sistema. Questi blocchi sono necessari per proteggere le risorse dicommit locali finché la risincronizzazione non è completa ed è possibile eseguire il commit o il rollbackdelle risorse.

I messaggi vengono inviati alle registrazioni lavoro dei lavori del server di database per indicare lo statodella risincronizzazione con le ubicazioni remote. Se la transazione è in dubbio, la risincronizzazione deveessere completata con l'ubicazione proprietaria della decisione per la transazione prima che le risorselocali possano essere sottoposte a commit o a rollback.

Quando viene presa la decisione per una transazione, i seguenti messaggi potrebbero essere inviati allaregistrazione lavoro per il lavoro del server di database.

CPI8351Si sta eseguendo il rollback di &1 modifiche in sospeso

CPC8355Ripristino post-IPL della definizione di commit &8 per il lavoro &19/&18/&17 completato.

CPD835FIl ripristino IPL della definizione di commit &8 per il lavoro &19/&18/&17 ha avuto esitonegativo,

Possono essere inviati anche altri messaggi correlati al ripristino. Questi messaggi vengono inviati allaregistrazione cronologica (QHST). Se si verificano degli errori, dei messaggi vengono inviati anche allacoda messaggi QSYSOPR.

È possibile determinare l'avanzamento del ripristino utilizzando System i Navigator, visualizzando laregistrazione lavoro per il lavoro del server di database oppure utilizzando il comando WRKCMTDFN


(Gestione definizioni di commit). Anche se con System i Navigator e la visualizzazione Gestionedefinizioni di commit è possibile forzare il sistema ad eseguire il commit o il rollback, è necessarioricorrere a questa operazione solo quando non ci sono alternative. Se si prevede che tutte le ubicazioniche hanno partecipato alla transazione verranno eventualmente restituite allo stato operativo, è necessarioconsentire ai sistemi di risincronizzarsi. Questo assicura l'integrità dei database.Concetti correlati

“Considerazioni sui lotti dischi indipendenti per le definizioni di commit” a pagina 22Quando si utilizzano i lotti dischi indipendenti, è necessario tenere presenti le seguenti considerazioni perle definizioni di commit.“Stati della transazione per il controllo del commit a due fasi” a pagina 31Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma ditransazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazionecorrente e della transazione precedente.

Gestione di transazioni e controllo del commitUtilizzando queste istruzioni, è possibile visualizzare le informazioni di controllo del commit eottimizzare le prestazioni per il controllo del commit.

Visualizzazione delle informazioni sul controllo del commitSystem i Navigator può visualizzare informazioni su tutte le transazioni (unità di lavoro logiche) sulsistema. System i Navigator può anche visualizzare eventuali informazioni sul lavoro associate a unatransazione.

Nota: queste operazioni di visualizzazione non visualizzano il livello di isolamento per le applicazioniSQL.

Per visualizzare le informazioni, procedere nel seguente modo:1. Da System i Navigator, espandere il sistema che si desidera utilizzare.2. Espandere Database.3. Espandere il sistema che si desidera gestire.4. Espandere Transazioni.

Nota: per visualizzare una transazione associata a una transazione globale X/Open, espandereTransazioni globali. Per visualizzare una transazione gestita da DB2, espandere Transazionidatabase.

5. Espandere Transazioni globali o Transazioni database.

Questa visualizzazione mostra le seguenti informazioni:v ID unità di lavorov Stato unità di lavorov Lavorov Utentev Numerov Risincronizzazione in corsov Definizione di commit

La guida in linea fornisce informazioni su tutte le visualizzazioni di stato e sui campi contenuti inciascuna visualizzazione.


Attività correlate

“Rilevazione di condizioni di stallo” a pagina 115Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, esta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altrolavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere unblocco sull'oggetto A.“Ripristino delle transazioni dopo un errore nelle comunicazioni” a pagina 116Queste istruzioni aiutano a gestire le transazioni che eseguono delle attività su un sistema remoto dopoche si è verificato un errore nelle comunicazioni con tale sistema.“Quando forzare le opzioni di commit e di rollback e quando annullare la risincronizzazione” a pagina117La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azioneabilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione cheè in uno stato Preparato.“Ricerca di transazioni di grandi dimensioni oppure obsolete” a pagina 119Utilizzare il comando WRKCMTDFN (Gestione definizioni di commit) per trovare transazioni di grandidimensioni oppure obsolete.

Visualizzazione di oggetti bloccati per una transazioneÈ possibile visualizzare degli oggetti bloccati per le transazioni globali solo con i blocchi nell'ambito dellatransazione.

Per visualizzare gli oggetti bloccati per una transazione, attenersi alla seguente procedura:1. Da System i Navigator, espandere il sistema che si desidera utilizzare.2. Espandere Database.3. Espandere il sistema che si desidera gestire.4. Espandere Transazioni.5. Espandere Transazioni globali.6. Fare clic con il tasto destro del mouse sulla transazione che si desidera gestire e selezionare Oggetti

bloccati.Attività correlate

“Rilevazione di condizioni di stallo” a pagina 115Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, esta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altrolavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere unblocco sull'oggetto A.

Visualizzazione di lavori associati a una transazionePer visualizzare i lavori associati a una transazione, attenersi alla seguente procedura.1. Dalla finestra System i Navigator, espandere il sistema che si desidera utilizzare.2. Espandere Database.3. Espandere il sistema che si desidera gestire.4. Espandere Transazioni.5. Espandere Transazioni globali o Transazioni database.6. Fare clic con il tasto destro del mouse sulla transazione che si desidera gestire e selezionare Lavori.

Per le transazioni del database e quelle globali, con blocchi di lavori aperti, viene visualizzato un elencodi lavori associati alla transazione.

Per transazioni globali con blocchi nell'ambito della transazione, viene visualizzato un elenco di lavori acui è collegato questo oggetto transazione o che sono in attesa del collegamento con questo oggettotransazione


Attività correlate


Visualizzazione dello stato risorsa di una transazionePer visualizzare lo stato risorsa di una transazione, attenersi alla seguente procedura.1. Dalla finestra System i Navigator, espandere il sistema che si desidera utilizzare.2. Espandere Database.3. Espandere il sistema che si desidera gestire.4. Espandere Transazioni.5. Espandere Transazioni globali o Transazioni database.6. Fare clic con il tasto destro del mouse sulla transazione che si desidera gestire e selezionare Stato

risorsa.

Visualizzazione delle proprietà delle transazioniPer visualizzare le proprietà delle transazioni, attenersi alla seguente procedura.1. Dalla finestra System i Navigator, espandere il sistema che si desidera utilizzare.2. Espandere Database.3. Espandere il sistema che si desidera gestire.4. Espandere Transazioni.5. Espandere Transazioni globali o Transazioni database.6. Fare clic con il tasto destro del mouse sulla transazione che si desidera gestire e selezionare Proprietà.

Ottimizzazione delle prestazioni per il controllo del commitL'utilizzo del controllo del commit richiede delle risorse che possono influenzare le prestazioni delsistema. Diversi fattori influenzano le prestazioni del sistema relativamente al controllo del commit.

Un fattore che non influenza le prestazioni

Aprire un fileSe si apre un file senza specificare l'opzione di apertura del commit, non viene utilizzata alcunarisorsa di sistema aggiuntiva, anche se è stata avviata una definizione di commit. Per ulterioriinformazioni sulla specifica dell'opzione di apertura del commit, consultare l'appropriato manualedi riferimento HLL (high-level language).

Fattori che riducono le prestazioni

GiornaleLa registrazione su giornale di un file richiede delle risorse di sistema. Tuttavia, nella maggiorparte dei casi, la registrazione su giornale ha prestazioni migliori con il controllo del commit chesenza il controllo del commit. Se si specificano solo immagini-successive, il controllo del commitmodifica questa specifica indicando sia immagini-precedenti sia immagini-successive mentre èeffettivo il controllo del commit. Questa è di norma una considerazione relativa allo spazio, nonalle prestazioni.

Operazione di commitSe sono state apportate delle modifiche alle risorse registrate su giornale durante la transazione,ogni commit di una transazione aggiunge due voci a ciascun giornale correlato a queste risorse. Ilnumero di voci aggiunte può aumentare in modo significativo per un volume elevato di piccoletransazioni. È possibile inserire i ricevitori di giornale in un lotto dischi separato rispetto aigiornali.


Operazione di rollbackPoiché il controllo del commit deve eseguire il rollback delle modifiche in sospeso registrate neldatabase, sono richieste delle risorse di sistema aggiuntive quando si verifica un rollback. Inoltre,se delle modifiche di record sono in sospeso, un'operazione di rollback causa l'aggiunta di vociaggiuntive al giornale.

Comandi STRCMTCTL (Avvio controllo commit) e ENDCMTCTL (Fine controllo commit)Per il sistema si verifica un sovraccarico aggiuntivo ogni volta che una definizione di commitviene avviata utilizzando il comando STRCMTCTL e viene terminata utilizzando il comandoENDCMTCTL. Evitare di utilizzare i comandi STRCMTCTL e ENDCMTCTL per ciascunatransazione. Utilizzarli sono quando necessario. È possibile stabilire una definizione di commitall'inizio di un lavoro interattivo e utilizzarla per la durata del lavoro.

Utilizzare più di un giornale per le transazioni di controllo del commit.Con il commit in due fasi, i file aperti sotto il controllo del commit possono essere registrati sugiornale in più di un giornale. Tuttavia, l'utilizzo di più di un giornale richiede delle risorse disistema aggiuntive per gestire la definizione di commit. L'utilizzo di più di un giornale può ancherendere il ripristino più complicato.

Blocco di recordIl blocco di record può interessare altre applicazioni. Il numero di record bloccati in uno specificolavoro aumenta le risorse di sistema globali utilizzate per il lavoro. Le applicazioni che devonoaccedere allo stesso record devono attendere la fine della transazione.

Richiedere SEQONLY(*YES)Se si richiede l'opzione SEQONLY(*YES) (utilizzando il comando OVRDBF oppure il programmaapplicativo prova implicitamente a utilizzare SEQONLY(*YES)) e il file viene aperto solo perl'immissione sotto il controllo del commit con LCKLVL(*ALL), l'opzione viene modificata inSEQONLY(*NO). Questa opzione può influenzare le prestazioni dei file di immissione perché irecord non verranno bloccati.

Richiedere una modifica a livello di record per un file di database quando è attiva l'elaborazione disalvataggio durante l'utilizzo o di attesa IASP (Independent ASP)

Una richiesta per eseguire una modifica a livello di record sotto il controllo del commit per unfile di database potrebbe essere ritardata se la definizione di commit è a un limite di commit eun'operazione di salvataggio durante l'utilizzo o di attesa IASP (Independent ASP) è inesecuzione in un lavoro differente. Per l'operazione di salvataggio durante l'utilizzo, questo puòverificarsi quando un file viene registrato su giornale sullo stesso giornale di alcuni degli oggettinella richiesta di salvataggio.

Nota: la colonna Stato del comando WRKACTJOB (Gestione lavori attivi) visualizza CMTW (inattesa di commit) quando un lavoro è congelato per l'elaborazione del checkpoint delsalvataggio durante l'utilizzo.

Modifiche di commit o rollback quando l'elaborazione di salvataggio durante l'utilizzo o di attesaIASP (Independent ASP) è attiva

Un'operazione di commit o di rollback può essere ritardata a un limite di commit quandoun'operazione di salvataggio durante l'utilizzo o di attesa IASP (Independent ASP) è inesecuzione in un lavoro differente. Questo può verificarsi quando una risorsa di commit API èstata precedentemente aggiunta alla definizione di commit, a meno che non si verifichi una delleseguenti condizioni:v Per l'operazione di salvataggio durante l'utilizzo, la risorsa API è stata aggiunta utilizzando

l'API (Aggiunta risorsa di commit) e il campo che indica che è consentita la normaleelaborazione di salvataggio ha un valore di Y.

v Per l'operazione di attesa dell'IASP (Independent ASP), la risorsa API è stata aggiuntautilizzando l'API QTNADDCR e il campo Concessione stato di attesa IASP ha un valore di Y.

Poiché il lavoro viene detenuto durante la richiesta di commit o di rollback e poiché una richiestadi commit o di rollback può essere eseguita solo per una singola definizione di commit per volta,


i lavori con più di una definizione di commit con le risorse di commit API possono impedire ilcompletamento di un'operazione di salvataggio durante l'utilizzo o di attesa dell'IASP(Independent ASP).

Nota: se si utilizza il nuovo salvataggio con la funzione di transazioni parziali, l'oggetto puòessere salvato senza terminare una definizione di commit.

Richiedere una modifica a livello di oggetto quando l'elaborazione di salvataggio durante l'utilizzo odi attesa IASP (Independent ASP) è attiva

Una richiesta per eseguire una modifica a livello di oggetto sotto il controllo del commit potrebbeessere ritardata se la definizione di commit è a un limite di commit e un'operazione disalvataggio durante l'utilizzo o di attesa IASP (Independent ASP) è in esecuzione in un lavorodifferente. Questo può verificarsi quando viene eseguita una modifica a livello di oggetto mentrel'operazione di salvataggio durante l'utilizzo o di attesa dell'IASP (Independent ASP) è inesecuzione sulla libreria che contiene l'oggetto. Ad esempio, l'operazione di creazione della tabellaSQL sotto il controllo del commit per la tabella MYTBL nella libreria MYSQLLIB potrebbe essereritardata quando un'operazione di salvataggio durante l'utilizzo o di attesa dell'IASP(Independent ASP) è in esecuzione sulla libreria MYSQLLIB.

Nota: se il tempo di attesa supera i 60 secondi, viene inviato il messaggio di interrogazioneCPA8351 per chiedere all'utente se continuare l'attesa o se annullare l'operazione.

Aggiungere una risorsa API utilizzando l'API QTNADDCRUna richiesta di aggiungere una risorsa di commit API utilizzando l'API QTNADDCR potrebbeessere ritardata se tutte le definizioni di commit per il lavoro sono a un limite di commit eun'operazione di salvataggio durante l'utilizzo o di attesa dell'IASP (Independent ASP) è inesecuzione in un lavoro differente.

Note:

1. Se il tempo di attesa supera i 60 secondi, viene inviato il messaggio di interrogazioneCPA8351 per chiedere all'utente se continuare l'attesa o se annullare l'operazione.

2. Per l'operazione di salvataggio durante l'utilizzo, questo non si applica alle risorse APIche erano state aggiunte utilizzando l'API QTNADDCR se il campo che indica che èconsentita la normale elaborazione di salvataggio ha un valore di Y. Per l'operazione diattesa dell'IASP (Independent ASP), questo non si applica alle risorse API che eranostate aggiunte utilizzando l'API QTNADDCR se il campo Concessione stato di attesaIASP ha un valore di Y.

Fattori che migliorano le prestazioni

Utilizzare un giornale predefinitoL'utilizzo di un giornale predefinito può migliorare le prestazioni se si chiudono e riaprono tutti ifile sotto il controllo del commit mentre la definizione di commit è attiva. Tuttavia, l'utilizzo di ungiornale predefinito con OMTJRNE(*NONE) riduce le prestazioni delle operazioni di commit erollback.

Selezionare un ultimo agentLe prestazioni vengono migliorate quando viene selezionato un ultimo agent, in quanto èrichiesto un numero minore di interazioni tra il sistema e l'ultimo agent durante un'operazione dicommit. Tuttavia, se si verifica un errore nelle comunicazioni durante un'operazione di commit,l'operazione di commit non verrà completata finché non sarà stata completata larisincronizzazione, indipendentemente dal valore dell'opzione Attesa risultato. Questo tipo dierrore è raro ma questa opzione consente allo scrittore dell'applicazione di considerare l'impattonegativo derivante dal causare all'utente un'attesa indefinita del completamento dellarisincronizzazione quando si verifica un errore. Valutare quanto detto rapportandolo almiglioramento delle prestazioni fornito dall'ottimizzazione dell'ultimo agent durante delle


operazioni di commit eseguite correttamente. Questa considerazione è generalmente piùsignificativa per i lavori interattivi che per i lavori batch.

Il valore predefinito prevede che è consentito che un ultimo agent venga selezionato dal sistemama l'utente può modificare questo valore utilizzando l'API QTNCHGCO.

Non utilizzare l'opzione Attesa risultatoQuando le risorse remote sono sotto il controllo del commit, le esecuzioni sono migliorate quandol'opzione Attesa risultato è impostata su N (No) e tutti i sistemi remoti supportano la presuntafine anomala. L'opzione Attesa risultato è impostata su No dal sistema per l'applicazione DDM eDRDA quando la prima connessione viene stabilita con un sistema remoto. Le applicazioni APPCdevono impostare esplicitamente l'opzione Attesa risultato, altrimenti verrà utilizzato il valorepredefinito di Y.

Selezionare l'opzione OK tralasciareLe prestazioni sono migliorate quando viene selezionata l'opzione OK tralasciare.

Selezionare l'opzione Per sola letturaLe prestazioni sono migliorate quando è selezionata l'opzione Per sola lettura.

Concetti correlati

Journal management“Definizione di commit per un commit in due fasi: indicazione di OK tralasciare” a pagina 41Di norma, il gestore transazioni in qualsiasi ubicazione nella rete del programma di transazione partecipaa ogni operazione di commit o di rollback. Per migliorare le prestazioni, è possibile configurare qualcunao tutte le ubicazioni in una transazione per consentire al gestore transazioni di indicare che è OKtralasciare.“Definizione di commit per un commit in due fasi: consentire VRO (vote read-only)” a pagina 35Di norma, un gestore transazioni partecipa a entrambe le fasi dell'elaborazione di commit. Per migliorarele prestazioni dell'elaborazione di commit, è possibile configurare qualcuna delle ubicazioni, oppure tutte,in una transazione per consentire al gestore transazioni di eseguire il VRO (vote read-only).Informazioni correlate

Add Commitment Resource (QTNADDCR) API

Riduzione al minimo dei blocchiUn modo tipico per ridurre al minimo i blocchi di record consiste nel rilasciare il blocco di record.(Questa tecnica non funziona se è stato specificato LCKLVL(*ALL)).

Viene qui di seguito riportato un esempio di riduzione al minimo di blocchi di record rilasciando ilblocco di record. Una singola applicazione di gestione dei file di norma si attiene alla seguente procedura:1. Visualizzare una richiesta per un'identificazione di record da modificare.2. Richiamare il record richiesto.3. Visualizzare il record.4. Consentire all'utente della stazione di lavoro di apportare la modifica.5. Aggiornare il record.

Nella maggior parte dei casi, il record è bloccato dall'accesso del record richiesto tramite l'aggiornamento.Il tempo di attesa del record potrebbe essere superato per un altro lavoro che sta attendendo il record.Per evitare di bloccare un record mentre l'utente della stazione di lavoro sta considerando una modifica,rilasciare il record dopo che è stato richiamato dal database (prima che compaia la visualizzazione delrecord). Occorre quindi accedere nuovamente al record prima dell'aggiornamento. Se il record è statomodificato tra la data/ora in cui è stato rilasciato e quella in cui è stato nuovamente effettuato l'accessoad esso, è necessario informare l'utente della stazione di lavoro. Il programma può determinare se ilrecord è stato modificato salvando uno o più campi del record originale e confrontandoli con i campinello stesso record dopo che ne è stato eseguito il richiamo nel seguente modo:


v Utilizzare un campo di conteggio degli aggiornamenti nel record e aggiungere 1 al campoimmediatamente prima di un aggiornamento. Il programma salva il valore originale e lo confronta conil valore nel campo quando il record viene richiamato nuovamente. Se si è verificata una modifica,l'utente della stazione di lavoro viene informato e viene visualizzato nuovamente il record. Il campo diconteggio degli aggiornamenti viene modificato solo se si verifica un aggiornamento. Il record vienerilasciato mentre l'utente della stazione di lavoro sta considerando una modifica. Se si utilizza questatecnica, è necessario utilizzarla in ogni programma che aggiorna il file.

v Salvare il contenuto dell'intero record di dati e confrontarlo con il record la volta successiva che vienerichiamato.

In entrambi i casi precedenti, la sequenza di operazioni impedisce il semplice utilizzo di dati descrittiesternamente in RPG dove gli stessi nomi di campo vengono utilizzati nel record master e nel file video.L'utilizzo degli stessi nomi di campo (in RPG) non funziona perché le modifiche dell'utente della stazionedi lavoro vengono sovrapposte quando il record viene richiamato nuovamente. È possibile risolverequesto problema spostando i dati di record in una struttura di dati. In alternativa, se si utilizza la parolachiave DDS, RTNDTA, è possibile continuare a utilizzare i dati descritti esternamente. La parola chiaveRTNDTA consente al programma di leggere nuovamente i dati sul pannello senza che il sistemaoperativo debba spostare i dati dalla visualizzazione al programma. Questo consente al programma dieffettuare le seguenti attività:1. Richiedere l'identificazione del record.2. Richiamare il record richiesto dal database.3. Rilasciare il record.4. Salvare il campo o i campi utilizzati per determinare se il record è stato modificato.5. Visualizzare il record e attendere che l'utente della stazione di lavoro risponda.

Se l'utente della stazione di lavoro modifica il record nella visualizzazione, il programma utilizza laseguente sequenza:1. Richiamare nuovamente il record dal database.2. Mettere a confronto i campi salvati per determinare se il record di database è stato modificato. Se è

stato modificato, il programma rilascia il record e invia un messaggio quando il record vienevisualizzato.

3. Richiamare il record dalla visualizzazione eseguendo un'operazione di lettura con la parola chiaveRTNDTA e aggiornare il record nel record di database.

4. Procedere alla successiva richiesta logica perché non ci sono record aggiuntivi da rilasciare se l'utentedella stazione di lavoro annulla la richiesta.

LCKLVL(*CHG) e LCKLVL(*CS) funzionano in questa situazione. Se viene utilizzato LCKLVL(*ALL), ènecessario rilasciare il blocco di record utilizzando un'operazione di commit o di rollback.Attività correlate


Gestione della dimensione della transazioneUn altro modo per ridurre al minimo i blocchi di record consiste nel gestire la dimensione dellatransazione.

Per questa discussione, una transazione è interattiva. (Il controllo del commit può anche essere utilizzatoper le applicazioni batch, che spesso possono essere considerate una serie di transazioni). Molte dellestesse considerazioni sono valide per le applicazioni batch, che sono discusse nella sezione Controllo delcommit per le applicazioni batch.


È possibile bloccare un massimo di 500 000 000 record durante una transazione per ciascun giornaleassociato alla transazione. È possibile ridurre questo limite utilizzando un file delle opzioni query(QAQQINI). Utilizzare il parametro QRYOPTLIB del comando CHGQRYA (Modifica attributi query) perspecificare un file delle opzioni query che può essere utilizzato da un lavoro. Utilizzare il valoreCOMMITMENT_CONTROL_LOCK_LEVEL nel file delle opzioni query come limite di blocco per illavoro. Il valore del limite di blocco viene memorizzato internamente nella cache per ciascuna definizionedi commit la prima volta che una risorsa registrata su giornale viene posta sotto il controllo del commit.Se il limite di blocco viene modificato dopo tale punto, il valore memorizzato nella cache deve essereaggiornato perché diventi effettivo per tale definizione di commit. Qualsiasi chiamata dell'API dirichiamo di informazioni di commit QTNRCMTI aggiorna il valore memorizzato nella cache nel lavorochiamante. Il nuovo valore non si applicherà alle transazioni avviate prima dell'aggiornamento dellacache.

Quando si sceglie il livello di blocco per i record, prendere in considerazione la dimensione delletransazioni. Utilizzare la dimensione per determinare per quanto tempo i record sono bloccati prima chetermini una transazione. È necessario decidere se un'operazione di commit o di rollback per il controllodel commit è limitata a un singolo utilizzo del tasto Invio o se la transazione consiste in molti utilizzi deltasto Invio.

Nota: più breve è la transazione e prima il lavoro in attesa di avviare l'elaborazione del checkpoint disalvataggio durante l'utilizzo può continuare ed essere completato.

Ad esempio, per un'applicazione di immissione di ordini, un cliente può ordinare vari articoli in unsingolo ordine richiedendo un record di dettaglio ordine e un aggiornamento del record master diinventario per ogni articolo nell'ordine. Se la transazione è definita come l'intero ordine e ciascun utilizzodel tasto Invio ordina un articolo, tutti i record coinvolti nell'ordine sono bloccati per la durata dell'interoordine. Pertanto, i record utilizzati frequentemente (come ad esempio i record master di inventario)possono essere bloccati per lunghi periodi di tempo, impedendo l'avanzamento di altro lavoro. Se tutti gliarticoli vengono immessi con un singolo tasto Invio utilizzando un file secondario, la durata dei blocchiper l'intero ordine è ridotta al minimo.

In generale, il numero e la durata dei blocchi devono essere ridotti al minimo in modo che diversi utentidella stazione di lavoro possano accedere agli stessi dati senza lunghi periodi di attesa. È possibileeseguire questa operazione non applicando i blocchi mentre l'utente immette i dati sul pannello. Alcuneapplicazioni potrebbero richiedere che non più di un utente della stazione di lavoro acceda agli stessidati. Ad esempio, in un'applicazione di scrittura di importi con molti record di articolo aperti per cliente,il tipico approccio consiste nel bloccare tutti i record e ritardarli finché un utente della stazione di lavoronon ha completato la scrittura dell'importo per una specifica ricevuta.

Se l'utente della stazione di lavoro preme il tasto Invio varie volte per una transazione, è possibileeseguire la transazione in diversi segmenti. Ad esempio:v Il primo segmento è un'interrogazione in cui l'utente della stazione di lavoro richiede le informazioni.v Il secondo segmento è una conferma dell'intento dell'utente della stazione di lavoro di completare

l'intera transazione.v Il terzo segmento è il richiamo e l'aggiornamento dei record interessati.

Questo approccio consente di limitare il blocco di record a un singolo utilizzo di Invio.

Questo approccio che prevede prima l'esecuzione di un'interrogazione viene di norma utilizzato nelleapplicazioni in cui una decisione è determinata dalle informazioni visualizzate. Ad esempio, inun'applicazione di prenotazioni di una compagnia aerea, un cliente può desiderare sapere quali sono gliorari dei voli, le coincidenze e le disposizioni dei posti a sedere disponibili prima di decidere quale voloprendere. Dopo che il cliente ha preso una decisione, la transazione viene immessa. Se la transazione haesito negativo (il volo risulta pieno), è possibile utilizzare la funzione di rollback e immettere una


||||||||||||

richiesta differente. Se i record sono bloccati dalla prima interrogazione finché non viene presa unadecisione, un altro addetto alle prenotazioni attenderà finché l'altra transazione non sarà stata completata.Concetti correlati

“Controllo del commit per le applicazioni batch” a pagina 27Le applicazioni batch possono richiedere o meno il controllo del commit. In alcuni casi, un'applicazionebatch può eseguire una singola funzione di lettura di un file di immissione e di aggiornamento di un filemaster. Tuttavia, è possibile utilizzare il controllo del commit per questo tipo di applicazione se èimportante avviarla nuovamente dopo una fine anomala.

Commit softIl commit soft è una forma di controllo del commit che limita il numero di volte per cui il sistema scrivedelle voci di giornale associate a una transazione su disco.

Il commit soft può migliorare le prestazioni delle transazioni ma può causare la perdita di una o piùtransazioni nel caso di un errore di sistema. Il controllo del commit classico su DB2 for i assicura ladurabilità delle transazioni; questo significa che, quando viene eseguito il commit di una transazione,essa persiste sul sistema. Il commit soft non fornisce questa durabilità anche se assicura comunquel'atomicità della transazione. In altre parole, il sistema garantisce un limite di commit, ma una o piùtransazioni complete potrebbero andare perdute se si verifica un errore di sistema.

Per utilizzare il commit soft, sia per uno specifico lavoro o nell'ambito del sistema, specificare *NO nellavariabile di ambiente QIBM_TN_COMMIT_DURABLE. È possibile modificare questa variabile con ilcomando ADDENVVAR (Aggiunta variabile di ambiente).

Ad esempio, per richiedere il commit soft da uno specifico lavoro, immettere il seguente comando dallavoro:

ADDENVVAR ENVVAR (QIBM_TN_COMMIT_DURABLE) VALUE (*NO)

Per richiedere il commit soft nell'ambito del sistema, immettere il seguente comando:

ADDENVVAR ENVVAR (QIBM_TN_COMMIT_DURABLE) VALUE (*NO) LEVEL (*SYS)

Nota: è necessario disporre dell'autorizzazione *JOBCTL per impostare questa variabile di ambiente alivello del sistema.

Se la variabile di ambiente QIBM_TN_COMMIT_DURABLE non è stata aggiunta, o se la variabile diambiente è stata impostata su un valore diverso da *NO, il sistema non utilizza il commit soft; il sistemautilizza invece il controllo del commit classico in modo tale che la durabilità delle transazioni saràassicurata.

È possibile controllare l'esistenza di questa nuova variabile di ambiente e il suo valore e il livello, seesiste, utilizzando il comando WRKENVVAR (Gestione variabile di ambiente).

Il valore di questa variabile di ambiente viene memorizzato in cache internamente ogni volta che vieneavviato il controllo del commit. Se la variabile di ambiente viene modificata dopo tale punto, il valorememorizzato nella cache deve essere aggiornato perché diventi effettivo. Qualsiasi chiamata dell'API dirichiamo di informazioni di commit QTNRCMTI aggiorna il valore memorizzato nella cache nel lavorochiamante.

Per alcune transazioni, il sistema operativo sceglie di ignorare la richiesta di commit soft ed esegueinvece un commit classico. Questo si verifica in alcuni ambienti complessi, dove sono richieste piùconnessioni al database o dove sono in corso delle operazioni DDL. Il sistema operativo può determinarequando è appropriato eseguire la richiesta e quando ha più senso eseguire un'operazione di commitclassica. Non è pertanto pericoloso richiedere un commit soft in ambienti di questo tipo.


|||||

Scenari ed esempi: controllo del commitQuesti scenari ed esempi mostrano in che modo una società configura il controllo del commit. In questaraccolta di argomenti sono inclusi anche gli esempi di codice per i programmi che utilizzano il controllodel commit.

Il seguente scenario mostra il modo in cui la JKL Toy Company implementa il controllo del commit pertenere traccia delle transazioni sul suo database locale.

I seguenti esempi forniscono del codice di esempio per il controllo del commit. L'esercizio pratico è unprogramma RPG che implementa il controllo del commit. Include un flusso logico che mostra cosa siverifica a ogni passo del processo.

Scenario: controllo del commitLa JKL Toy Company utilizza il controllo del commit per proteggere i record di database per laproduzione e l'inventario. Questo scenario mostra in che modo la JKL Toy Company utilizza il controllodel commit per trasferire una parte dal suo reparto di inventario al suo reparto di produzione.

Scenario: l'argomento della gestione del giornale include una descrizione dell'ambiente di rete della JKLToy Company. Lo scenario riportato di seguito mostra in che modo il controllo del commit agisce sul suosistema di produzione JKLPROD.

Questo scenario illustra i vantaggi offerti dall'utilizzo del controllo del commit in due esempi. Il primoesempio mostra in che modo il programma di inventario della società, il programma A, può funzionaresenza il controllo del commit e i possibili problemi che possono verificarsi. Il secondo esempio mostracome funziona il programma con il controllo del commit.

La JKL Toy Company utilizza un programma applicativo di inventario, il programma A, sul suo sistemaJKLPROD. Il programma A utilizza due record. Un record tiene traccia degli articoli conservati inmagazzino. Un altro record tiene traccia degli articoli spostati dal magazzino e utilizzati nella produzione.

Programma A senza controllo del commit

Supporre che il seguente programma applicativo non utilizza il controllo del commit. Il sistema blocca irecord letti per l'aggiornamento. I seguenti passi descrivono in che modo il programma applicativo tienetraccia di un diodo dalla sua rimozione dal magazzino al suo trasferimento alla produzione:v Il programma A blocca e richiama il record del magazzino. (Questa azione potrebbe richiedere un'attesa

se il record è bloccato da un altro programma).v Il programma A blocca e richiama il record della produzione. (Anche questa azione potrebbe richiedere

un'attesa). Il programma A ora ha bloccato entrambi i record e nessun altro programma puòmodificarli.

v Il programma A aggiorna il record del magazzino. Questo determina il rilascio del record in modo chesia ora disponibile per essere letto per l'aggiornamento da qualsiasi altro programma.

v Il programma A aggiorna il record della produzione. Questo determina il rilascio del record in modoche sia ora disponibile per essere letto per l'aggiornamento da qualsiasi altro programma.

Senza l'utilizzo del controllo del commit, è necessario risolvere un problema per fare in modo che questoprogramma funzioni correttamente in tutte le circostanze. Ad esempio, si verifica un problema se ilprogramma A non aggiorna entrambi i record a causa di un errore di lavoro o di sistema. In questo caso,i due file non sono congruenti; i diodi vengono rimossi dal record del magazzino ma non vengonoaggiunti al record della produzione. L'utilizzo del controllo del commit consente di assicurare che tutte lemodifiche coinvolte nella transazione siano completate o che i file vengano ripristinati al loro statooriginario se l'elaborazione della transazione viene interrotta.


Programma A con il controllo del commit

Se viene utilizzato il controllo del commit, l'esempio precedente viene modificato nel seguente modo:1. Il controllo del commit è avviato.2. Il programma A blocca e richiama il record del magazzino. (Questa azione può richiedere un'attesa se

il record è bloccato da un altro programma).3. Il programma A blocca e richiama il record della produzione. (Anche questa azione può richiedere

un'attesa). Il programma A ora ha bloccato entrambi i record e nessun altro programma puòmodificarli.

4. Il programma A aggiorna il record del magazzino e il controllo del commit mantiene il blocco sulrecord.

5. Il programma A aggiorna il record della produzione e il controllo del commit mantiene il blocco sulrecord.

6. Il programma A esegue il commit della transazione. Le modifiche al record del magazzino e al recorddella produzione vengono rese permanenti nei file. Le modifiche vengono registrate nel giornale, chepresume che saranno presenti su disco. Il controllo del commit rilascia i blocchi su entrambi i record. Irecord sono ora disponibili per essere letti per l'aggiornamento da qualsiasi altro programma.

Poiché i blocchi su entrambi i record sono mantenuti dal controllo del commit finché non viene eseguitoil commit della transazione, non può verificarsi una situazione in cui un record viene aggiornato e l'altrono. Se si verifica un errore di sistema o del passo di instradamento prima dell'esecuzione del commitdella transazione, il sistema elimina le (esegue il rollback delle) modifiche che sono state eseguite inmodo che i file siano aggiornati al punto in cui è stato eseguito il commit dell'ultima transazione.

Per ogni passo di instradamento in cui i file devono essere sotto il controllo del commit, si verificano ipassi mostrati nella seguente figura:


Le operazioni eseguite sotto il controllo del commit vengono registrate su giornale. La voce di giornale diavvio del controllo del commit viene visualizzata dopo la prima voce di apertura file sotto il controllo delcommit. Questo è dovuto al fatto che la prima voce di apertura file determina quale giornale vieneutilizzato per il controllo del commit. La voce di giornale dalla prima operazione di apertura vienequindi utilizzata per controllare le successive operazioni di apertura per assicurare che tutti i file stianoutilizzando lo stesso giornale.

Quando si verifica un errore di sistema o di lavoro, le risorse sotto il controllo del commit vengonoaggiornate a un limite di commit. Se una transazione viene avviata ma non viene completata prima chetermini un passo di instradamento, tale transazione viene sottoposta a rollback dal sistema e non èpresente nel file dopo il termine del passo di instradamento. Se il sistema termina in modo anomaloprima che una transazione venga completata, tale transazione viene sottoposta a rollback dal sistema enon è presente nel file dopo un successivo IPL (initial program load) eseguito correttamente del LIC(Licensed Internal Code - Microprogramma interno su licenza). Quando si verifica un rollback, delle vociin ordine inverso vengono inserite nel giornale.

Si supponga, ad esempio, che la JKL Company abbia 100 diodi in stock. La produzione ne prende 20dallo stock; il nuovo saldo è pertanto pari a 80. L'aggiornamento del database determina sia una voce digiornale di immagine-precedente (100) sia una di immagine-successiva (80).

Si presuma che il sistema venga terminato in modo anomalo dopo la registrazione su giornale delle vocima prima di raggiungere il punto di commit o il punto di rollback. Dopo l'IPL, il sistema legge la voce di


giornale e aggiorna il corrispondente record di database. Questo aggiornamento produce due voci digiornale che invertono l'aggiornamento: la prima voce è l'immagine-precedente (80) e la seconda voce èl'immagine-successiva (100).

Quando l'IPL viene completato correttamente dopo la fine anomala. il sistema elimina le (o esegue ilrollback delle) modifiche al database di cui non è stato eseguito il commit. Nell'esempio precedente, ilsistema elimina le modifiche dal record del magazzino perché un'operazione di commit non è presentenel giornale per tale transazione. In questo caso, l'immagine-precedente del record di magazzino vieneinserita nel file. Il giornale contiene le modifiche sottoposte a rollback e un'indicazione che si è verificataun'operazione di rollback.Concetti correlati

Scenario: Journal management

Problema pratico per il controllo del commitQuesto esercizio pratico può essere di ausilio nel comprendere il controllo del commit e i suoi requisiti.Queste operazioni presumono che l'utente abbia dimestichezza con il programma su licenza i5/OS, laDFU (data file utility) e questa raccolta di argomenti.


Prima di iniziare questo problema, attenersi alla seguente procedura prerequisita:1. Creare una libreria speciale per questo esercizio pratico. Nelle istruzioni, la libreria è denominata

CMTLIB. Sostituire alle ricorrenze rilevate di CTMLIB il nome della propria libreria.2. Creare i file di origine e una descrizione del lavoro.

Per utilizzare il controllo del commit, attenersi alla seguente procedura:1. Creare un file fisico denominato ITMP (file master degli articoli). La DDS (data description

specification) per questo file è la seguente:10 A R ITMR20 A ITEM 230 A ONHAND 5 040 A K ITEM

2. Creare un file fisico denominato TRNP (file di transazioni). Questo file viene utilizzato come un filedi registrazione delle transazioni. La DDS per questo file è la seguente:10 A R TRNR20 A QTY 5 030 A ITEM 240 A USER 10

3. Creare un file logico denominato TRNL (logica transazioni). Questo file viene utilizzato come ausilionel riavvio dell'applicazione. Il campo USER è la sequenza di tipo LIFO. La DDS per questo file è laseguente:10 LIFO20 A R TRNR PFILE (TRNP)30 A K USER

4. Immettere il comando STRDFU e creare un'applicazione DFU denominata ITMU per il file ITMP.Accettare i valori predefiniti offerti da DFU durante la definizione dell'applicazione.

5. Immettere il comando CHGDTA ITMU e immettere i seguenti record per il file ITMP:

Articolo DisponibileAA 450BB 375CC 4000


6. Terminare il programma utilizzando F3. Questa immissione fornisce dei dati sui quali opererà ilprogramma.

7. Creare il programma CL di elaborazione degli articoli (ITMPCSC) nel seguente modo:PGMDCL &USER *CHAR LEN(10)RTVJOBA USER(&USER)CALL ITMPCS PARM(&USER)ENDPGM

Questo è il programma di controllo che richiama il programma ITMPCS. Richiama il nome utente elo trasmette al programma di elaborazione. Questa applicazione presume che vengano utilizzati deinomi utente univoci.

8. Creare un file video denominato ITMPCSD dalla DDS nel seguente modo.Esistono due formati: il primo per il pannello di richiesta di base e il secondo per consentireall'operatore di controllare l'ultima transazione immessa. Questo file video viene utilizzato dalprogramma ITMPCS.SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..

1.00 A R PROMPT2.00 A CA03(93 'End of program')3.00 A CA04(94 'Review last')4.00 A SETOFF(64 'No rcd to rvw')5.00 A 1 2'INVENTORY TRANSACTIONS'6.00 A 3 2'Quantity'7.00 A QTY 5 0I +18.00 A 61 ERRMSG('Invalid +9.00 A quantity' 61)10.00 A +5'ITEM'11.00 A ITEM 2 I +112.00 A 62 ERRMSG('Invalid +13.00 A Item number' 62)14.00 A 63 ERRMSG('Rollback +15.00 A occurred' 63)16.00 A 64 24 2'CF4 was pressed and +17.00 A there are no +18.00 A transactions for +19.00 A this user'20.00 A DSPATR(HI)21.00 A 23 2'CF4 Review last +22.00 A transaction'23.00 A R REVW24.00 A 1 2'INVENTORY TRANSACTIONS'25.00 A +5'REVIEW LAST TRANSACTION'26.00 A 3 2'Quantity'27.00 A QTY 5 0 +1EDTCDE(Z)28.00 A +5'Item'29.00 A ITEM 2 +1

9. Studiare il flusso logico fornito in Flusso logico per l'esercizio pratico per il controllo del commit.10. Immettere il comando STRSEU e immettere il sorgente nel seguente modo:

SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..

1.00 FITMP UF E K DISK2.00 F* KCOMIT3.00 FTRNP O E DISK4.00 F* KCOMIT5.00 FTRNL IF E K DISK6.00 F TRNR KRENAMETRNR17.00 FITMPCSD CF E WORKSTN8.00 C* Enter parameter with User name for -TRNP- file9.00 C *ENTRY PLIST10.00 C PARM USER 1011.00 C LOOP TAG12.00 C EXFMTPROMPT


13.00 C* Check for CF3 for end of program14.00 C 93 DO End of Pgm15.00 C SETON LR16.00 C RETRN17.00 C END18.00 C* Check for CF4 for review last transaction19.00 C 94 DO Review last20.00 C* Check for existence of a record for this user in -TRNL- file21.00 C USER CHAINTRNR1 64 Not found22.00 C 64 GOTO LOOP23.00 C EXFMTREVW24.00 C GOTO LOOP25.00 C END26.00 C* Access Item record27.00 C ITEM CHAINITMR 62 Not found28.00 C* Handle -not found- Condition29.00 C 62 GOTO LOOP30.00 C* Does sufficient quantity exist31.00 C ONHAND SUB QTY TEST 50 61 Minus32.00 C* Handle insufficient quantity33.00 C 61 DO34.00 C* Release Item record which was locked by the CHAIN for update35.00 C EXCPTRLSITM36.00 C GOTO LOOP37.00 C END38.00 C* Change ONHAND and update the Item record39.00 C Z-ADDTEST ONHAND40.00 C UPDATITMR41.00 C* Test for Special Simulation Conditions42.00 C ITEM IFEQ 'CC'43.00 C* Simulate program need for rollback44.00 C QTY IFEQ 10045.00 C SETON 63 Simult Rlbck46.00 C* ROLBK47.00 C GOTO LOOP48.00 C END49.00 C* Simulate an abnormal program cancellation by Div by zero50.00 C* Operator Should respond -C- to inquiry message51.00 C QTY IFEQ 10152.00 C Z-ADD0 ZERO 3053.00 C TESTZ DIV ZERO TESTZ 30 Msg occurs54.00 C END55.00 C* Simulate an abnormal job cancellation by DSPLY.56.00 C* Operator Should System Request to another job57.00 C* and cancel this one with OPTION(*IMMED)58.00 C QTY IFEQ 10259.00 C 'CC=102' DSPLY Msg occurs60.00 C END61 00 C END ITEM=CC62.00 C* Write the -TRNP- file63 00 C WRITETRNR64.00 C* Commit the update to -ITMP- and write to -TRNP-65.00 C* COMIT66.00 C GOTO LOOP67.00 OITMR E RLSITM

11. Immettere il comando CRTRPGPGM per creare il programma ITMPCS dal sorgente immesso nelpasso precedente.

12. Immettere il comando CALL ITMPCSC, premere Invio e premere F4. Un messaggio indica che non cisono immissioni per questo operatore.

13. Immettere i seguenti dati per verificare se il programma funziona correttamente:

Quantità Articolo3 AA4 BB


14. Premere F4. Il pannello di controllo mostra l'ultimo articolo BB immesso. Immettere i seguenti dati:

Quantità Articolo5 FF (Viene generato un messaggio di numero articolo non

valido).9000 BB (Viene generato un messaggio di errore di quantità

insufficiente).100 CC (Viene generato un messaggio di rollback).102 CC (Deve essere eseguita l'operazione RPG DSPLY.

Premere il tasto Invio).101 CC (il programma deve visualizzare un messaggio di

interrogazione che indica che si è verificata unacondizione di divisione per zero oppure un'indicazionedella condizione di terminazione, a secondadell'impostazione dell'attributo di lavoro INQMSGRPY. Seviene visualizzato il messaggio di interrogazione,immettere C per annullare il programma RPG e quindi Cper annullare il programma CL sull'interrogazionesuccessiva. Questo simula una condizione di erroreimprevista).

15. Immettere il comando di visualizzazione dati DSPDTA ITMP.Verificare se i record AA e BB sono stati aggiornati correttamente. I valori devono essere AA = 447,BB = 371 e CC = 3697. Notare che le operazioni di sottrazione di quantità da CC sono state eseguitema che i record delle transazioni non sono stati scritti.

16. Creare un ricevitore di giornale per il controllo del commit. Utilizzare il comando CRTJRNRCV(Creazione ricevitore di giornale) per creare un ricevitore di giornale denominato RCVR1 nellalibreria CMRLIB. Specificare una soglia di almeno 5000KB. Una soglia più elevata è consigliata se ilsistema dispone di una quantità sufficiente di spazio per ottimizzare il tempo tra la generazione dinuovi ricevitori di giornale al fine di ridurre al minimo l'impatto sulle prestazioni di giornali dimodifica troppo frequenti.

17. Creare un giornale per il controllo del commit. Utilizzare il comando CRTJRN (Creazione giornale)per creare un giornale denominato JRNTEST nella libreria CMTLIB. Poiché questo giornale vieneutilizzato solo per il controllo del commit, specificare MNGRCV(*SYSTEM) DLTRCV(*YES). Per ilparametro JRNRCV, specificare il ricevitore di giornale creato al passo 16.

18. Utilizzare il comando STRJRNPF (Avvio file fisico su giornale) con i parametri FILE(CMTLIB/ITMPCMTLIB/TRNP) JRN(CMTLIB/JRNTEST) per registrare su giornale i file da utilizzare per ilcontrollo del commit.Il parametro IMAGES utilizza un valore predefinito di *AFTER, che indica che solo le modifichepost-immagine dei record sono presenti nel giornale. I file ITMP e TRNP hanno ora avviato laregistrazione su giornale.Di norma, si salvano i file dopo l'avvio della registrazione su giornale. Non è possibile applicaredelle modifiche registrate su giornale a un file ripristinato che non ha lo stesso JID delle voci digiornale. Poiché questo esercizio pratico non richiede che si applichino le modifiche registrate sugiornale, è possibile tralasciare il salvataggio dei file registrati su giornale.

19. Immettere il comando CALL ITMPCSC e immettere le seguenti transazioni:


Terminare il programma premendo F3.20. Immettere il comando Visualizzazione giornale: DSPJRN CMTLIB/JRNTEST.

Notare le voci presenti nel giornale. La stessa sequenza di voci (R UP = aggiornamento di ITMPseguito da R PT = record aggiunto a TRNP) si verifica nel giornale così come è stata eseguita dal


programma. Questo è dovuto al fatto che un file logico è definito sul file fisico TRNP e il sistemasovrascrive il valore predefinito RPG. Se non esisteva alcun file logico, viene utilizzato il presuppostodi RPG di SEQONLY(*YES) e si presenta un blocco di voci PT perché i record vengono conservati nelbuffer RPG finché il blocco non è pieno.

21. Modificare il programma CL ITMPCSC nel seguente modo (le nuove istruzioni sono presentate conun asterisco).

PGMDCL &USER *CHAR LEN(10)RTVJOBA USER(&USER)

* STRCMTCTL LCKLVL(*CHG)CALL ITMPCS PARM(&USER)

* MONMSG MSGID(RPG9001) EXEC(ROLLBACK)* ENDCMTCTL

ENDPGM

Il comando STRCMTCTL configura l'ambiente di controllo del commit. La parola LCKLVL specificache i record letti per l'aggiornamento ma non aggiornati possono essere rilasciati durante latransazione. Il comando MONMSG gestisce gli eventuali messaggi di escape RPG ed esegue unROLLBACK in caso di fine anomala del programma RPG. Il comando ENDCMTCTL terminal'ambiente di controllo del commit.

22. Cancellare il programma ITMPCSC esistente e crearlo nuovamente.23. Modificare il programma RPG per eliminare i simboli di commenti alle istruzioni 2.00, 4.00, 46.00 e

65.00. Il sorgente è ora pronto per l'utilizzo con il controllo del commit.24. Cancellare il programma ITMPCS esistente e crearlo nuovamente. Il programma è ora pronto a

operare sotto il controllo del commit.25. Immettere il comando CALL ITMPCSC e le seguenti transazioni:


26. Utilizzare la richiesta di sistema e richiedere l'opzione per visualizzare il lavoro corrente. Quandoviene visualizzato il pannello Visualizzazione lavoro, selezionare l'opzione 16 per richiedere lavisualizzazione dello stato del controllo del commit.Notare i valori visualizzati. Ci devono essere due commit perché nel programma sono state eseguitedue istruzioni di commit.

27. Premere F9 per visualizzare un elenco dei file sotto il controllo del commit e la quantità di attivitàper ciascun file.

28. Ritornare al programma e terminarlo premendo F3.29. Immettere DSPJRN CMTLIB/JRNTEST e notare le voci per i file e le voci di giornale speciali per il

controllo del commit:

Voce SignificatoC BC Si è verificato un comando STRCMTCTL.C SC Avvio del ciclo di commit. Questo si verifica quando la

prima operazione di database nella transazione causal'inserimento, l'aggiornamento o la cancellazione di unrecord come parte del controllo del commit.

C CM Si è verificata l'operazione di commit.C EC Si è verificato un comando ENDCMTCTL.

Le immagini-precedenti e le immagini-successive (tipi R UB e R UP) del controllo del commit siverificano automaticamente anche se in origine era stato richiesto IMAGES(*AFTER) per il giornale.

30. Immettere il comando CALL ITMPCSC e le seguenti transazioni:


Quantità Articolo12 AA100 CC (Questa è la condizione per simulare l'esigenza per

un'applicazione di utilizzare il rollback. Il record CC nelfile ITMP, che era stato aggiornato dall'istruzione RPG40.00, viene sottoposto a rollback).

31. Premere F4 per determinare l'ultima transazione immessa.L'ultima transazione di cui è stato eseguito il commit è la voce per l'elemento AA.

32. Utilizzare la richiesta di sistema e richiedere l'opzione per visualizzare il lavoro corrente. Quandoviene visualizzato il pannello Visualizzazione lavoro, richiedere la visualizzazione dello stato delcontrollo del commit.Notare i valori visualizzati e come sono stati modificati dal rollback.

33. Ritornare al programma.34. Ritornare al pannello di richiesta di base e terminare il programma premendo F3.35. Immettere il comando DSPJRN CMTLIB/JRNTEST.

Notare le voci aggiuntive presenti nel giornale per l'utilizzo della voce di rollback (voce C RB).Quando viene eseguito il rollback del record ITMP, nel giornale vengono inserite tre voci. Questo èdovuto al fatto che qualsiasi modifica al file di database sotto il controllo del commit produce unavoce prima (R BR) e dopo (R UR).

36. Visualizzare le voci con il codice giornale R e questi tipi di voce: UB, UP, BR e UR. Utilizzarel'opzione 5 per visualizzare le voci complete. Poiché il campo Quantità è in decimale compatto,utilizzare F11 per richiedere una visualizzazione esadecimale. Notare le seguenti condizioni:v Il valore di disponibilità del record ITMP nel record UBv Come il valore di disponibilità viene ridotto dal record UPv Come il record BR sia uguale al record UPv Come il record UR restituisce il valore così come è visualizzato in origine per il record UBL'ultima voce è la voce RB per la fine del rollback.

37. Immettere il comando CALL ITMPCSC, premere Invio e premere F4. Notare l'ultima transazioneimmessa.

38. Immettere le seguenti transazioni:

Quantità Articolo13 AA101 CC (Questa è la condizione per simulare una condizione

di errore imprevista che causa la terminazione delprogramma. La simulazione si verifica dividendo uncampo per 0. Il programma visualizzerà un messaggio diinterrogazione o un'indicazione della condizione diterminazione, a seconda dell'impostazione dell'attributodi lavoro INQMSGRPY. Se viene visualizzato il messaggiodi interrogazione, immettere C per terminare ilprogramma. Poiché il programma CL è stato modificatoper monitorare il verificarsi di errori di programma RPG,la seconda interrogazione che si verificava non siverifica).

39. Immettere il comando DSPJRN CMTLIB/JRNTEST.Si è verificato lo stesso tipo di gestione del rollback, ma questa volta il rollback è stato causato dalparametro EXEC del comando MONMSG nel programma CL invece del programma RPG.Visualizzare le due voci RB per appurare quale programma li ha causati.

40. Immettere il comando WRKJOB e annotare il nome lavoro completo da utilizzare successivamente.


41. Immettere il comando CALL ITMPCSC e immettere la seguente transazione:

Quantità Articolo14 AA102 CC (L'operazione RPG DSPLY deve verificarsi sulla coda

messaggi esterna. Utilizzare il tasto di richiesta sistema eselezionare l'opzione 1 nel menu di richiesta sistema pereseguire il trasferimento a un lavoro secondario).

42. Collegarsi al secondo lavoro e ristabilire l'ambiente.43. Immettere il comando ENDJOB e specificare il nome lavoro completo identificato precedentemente e

l'opzione OPTION(*IMMED). Questo simula una fine anomala o una terminazione di sistema.44. Attendere circa 30 secondi, immettere il comando CALL ITMPCSC e premere F4.

Notare l'ultima transazione sottoposta a commit. Deve essere la voce AA immessa precedentemente.45. Ritornare al pannello di richiesta di base e terminare il programma premendo F3.46. Immettere il comando DSPJRN CMTLIB/JRNTEST.

Si è verificato lo stesso tipo di gestione del rollback, ma questa volta il rollback è stato causato dalsistema invece che da uno dei programmi. La voce RB è stata scritta dal programma QWTPITPP, cheè il programma di fine anomala della gestione lavoro.

A questo punto, sono state utilizzate le funzioni di base del controllo del commit. È possibile procederecon il controllo del commit sulle proprie applicazioni oppure provare qualcuna delle altri funzioni, tipo:v L'utilizzo di un oggetto di notificav Il blocco di record di sola lettura con LCKLVL(*ALL)v Il blocco di più record nello stesso file con LCKLVL(*ALL)

Flusso logico per l'esercizio praticoIl flusso logico può essere di ausilio nel comprendere ulteriormente questo programma pratico per ilcontrollo del commit. La seguente figura mostra il flusso dell'esercizio pratico per il controllo del commit.

Consultare “Passi associati al flusso logico per il programma pratico” a pagina 89 per informazionidettagliate su ciascuna delle operazioni illustrate nella figura.


Passi associati al flusso logico per il programma praticoQuesti passi sono associati al flusso logico per l'esercizio pratico.1. Richiamare il nome utente trasmesso come un parametro. Viene utilizzato per scrivere nel file TRNP

e anche per richiamare l'ultima transazione immessa da ciascun operatore . Questa applicazionepresume dei nomi utente univoci per gli operatori.

2. Richiedere il pannello di base utilizzando il nome formato PROMPT.3. Se viene premuto F3, avviare una funzione di terminazione del programma.4. Se viene premuto F4, avviare una routine per accedere all'ultima transazione immessa dall'operatore.5. Leggere il record di articolo utilizzando il campo ITEM. Poiché il file è un file di aggiornamento,

questa richiesta blocca il record.6. Controllare l'eventuale presenza di una condizione di non trovato nel file ITMP.7. Se non esiste alcun record ITMP, impostare come attivo un indicatore 62 per causare il messaggio di

errore e ritornare al passo 2.8. Sottrarre la quantità richiesta (QTY) dal saldo disponibile (ONHAND) in un'altra area di lavoro.9. Verificare se è disponibile una quantità sufficiente per soddisfare la richiesta.

10. Se è disponibile una quantità insufficiente, rilasciare il blocco sul record nel file ITMP. Questo passoè necessario perché la quantità non è sufficiente.

11. Impostare come attivo l'indicatore 61 per visualizzare un messaggio di errore di quantità insufficientee ritornare al passo 2.

12. Modificare il campo ONHAND per il nuovo saldo e aggiornare il record ITMR.13. Controllare la presenza di una voce speciale nel campo ITEM che è possibile utilizzare per simulare

le condizioni in cui è richiesto il ROLLBACK.14. Controllare la presenza di QTY=100. Emettere un'operazione ROLLBACK. Questo simula una

condizione in cui il programma rileva che è necessario eseguire il rollback.15. Controllare la presenza di QTY=101. Causare un'eccezione nel programma che produrrà un

messaggio di interrogazione. Utilizzare la divisione per zero per questa funzione. L'operatore deveimmettere C per annullare il programma, a meno che l'opzione INQMSGRPH della descrizione dellavoro non fornisca una risposta automatica. Questo simula una condizione in cui si è verificato unerrore imprevisto e l'operatore annulla il programma.

16. Controllare la presenza di QTY=102. Emettere una visualizzazione con l'operazione di interrogazione.Questo arresta il programma a questo passo e consente l'utilizzo del tasto di richiesta sistema perottenere un lavoro differente. Annullare il lavoro di aggiornamento. Questo simula una condizione incui si è verificata una fine anomala di lavoro o di sistema durante un limite di commit.

17. Scrivere il record di transazione in TRNP.18. Eseguire il commit dei record per la transazione e ritornare al passo 2.19. Leggere il primo record nel percorso di accesso per il file TRNL, utilizzando USER come chiave.

Poiché questo file è in sequenza LIFO, questo sarà l'ultimo record di transazione immesso da questoutente.

20. Controllare la presenza di una condizione di record non trovato nel file TRNL che si verifica se il filenon contiene voci per questo utente.

21. Se non ci sono record per questo utente, impostare come attivo l'indicatore 64 per causare unmessaggio di errore e ritornare al passo 2.

22. Visualizzare l'ultima transazione immessa per questo utente. Queste informazioni possono essereutilizzate se l'operatore dimentica cosa era stato immesso precedentemente o quando viene riavviatala transazione. Quando l'operatore risponde, ritornare al passo 2.

23. Eseguire le funzioni programma desiderate.


Esempio: utilizzo di un file di registrazione delle transazioni peravviare un'applicazioneQuesto esempio fornisce il codice di esempio e le istruzioni su come utilizzare un file di registrazionedelle transazioni per avviare un'applicazione dopo una fine anomala.


Un file di registrazione delle transazioni viene utilizzato per riavviare un'applicazione dopo un errore disistema o di lavoro quando non viene utilizzato un oggetto di notifica. Un file di registrazione delletransazioni viene spesso utilizzato nelle applicazioni interattive per riepilogare gli effetti di unatransazione.

Ad esempio, in un'applicazione di immissione di ordini, un record viene di norma scritto in un file diregistrazione delle transazioni per ogni articolo ordinato. Il record contiene l'articolo ordinato, la quantitàe il prezzo. Nell'applicazione di conti debitore, viene scritto un record in un file di registrazione delletransazioni per ogni numero di conto che deve ricevere un addebito. Questo record di norma contieneinformazioni quali il numero di conto, l'importo addebitato e il fornitore.

In molte delle applicazioni dove già esiste un file di registrazione delle transazioni, un utente dellastazione di lavoro può richiedere informazioni sull'ultima transazione immessa. Aggiungendo il controllodel commit alle applicazioni in cui già esiste un file di registrazione delle transazioni, è possibile:v Assicurare che i file di database siano aggiornati a un limite di commit.v Semplificare il riavvio della transazione.

È necessario poter identificare in modo univoco l'utente della stazione di lavoro se si utilizza un file diregistrazione delle transazioni per il riavvio delle applicazioni sotto il controllo del commit. Se vengonoutilizzati dei nomi di profilo utente univoci sul sistema, il nome profilo può essere inserito in un camponel record della registrazione della transazione. Questo campo può essere utilizzato come chiave per ilfile.

I seguenti esempi presumono che venga utilizzato un file di inventario dell'ordine per eseguire letransazioni e che già esista un file di registrazione delle transazioni. Il programma esegue le seguentiattività:1. Richiedere all'utente della stazione di lavoro una quantità e un numero di articolo.2. Aggiornare la quantità nel file master di produzione (PRDMSTP).3. Scrivere un record nel file di registrazione delle transazioni (ISSLOGL).

Se la quantità di inventario disponibile è insufficiente, il programma rifiuta la transazione. L'utente dellastazione di lavoro può chiedere al programma dove è stata interrotta l'immissione di dati perché ilnumero dell'articolo, la descrizione, la quantità, il nome utente e la data vengono scritti nel file diregistrazione delle transazioni.

DDS per il file fisico PRDMSTPSEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7

1.00 A R PRDMSTR TEXT('Master record')2.00 A PRODCT 3 COLHDG('Product' 'Number')3.00 A DESCRP 20 COLHDG('Description')4.00 A ONHAND 5 0 COLHDG('On Hand' 'Amount')5.00 A EDTCDE(Z)6.00 A K PRODCT


DDS per il file fisico ISSLOGP utilizzato da ISSLOGPSEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7

1.00 A R ISSLOGR TEXT('Product log record')2.00 A PRODCT 3 COLHDG('Product' 'Number')3.00 A DESCRP 20 COLHDG('Description')4.00 A QTY 3 0 COLHDG('Quantity')5.00 A EDTCDE(Z)6.00 A USER 10 COLHDG('User' 'Name')7.00 A DATE 6 0 EDTCDE(Y)8.00 A COLHDG('Date')

DDS per il file logico ISSLOGLSEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7

1.00 A LIFO2.00 A R ISSLOGR PFILE(ISSLOGP)3.00 A K USER

DDS per il file video PRDISSD utilizzato nel programmaSEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..

1.00 A REF(ISSLOGP)2.00 A R PROMPT3.00 A CA03(98 'End of program')4.00 A CA02(97 'Where am I')5.00 A 1 20'ISSUES PROCESSING'6.00 A 3 2'Quantity'7.00 A QTY R I +18.00 A 62 ERRMSG('Not enough +9.00 A Qty' 62)10.00 A +6'Product'11.00 A PRODCT R I +112.00 A 61 ERRMSG('No Product +13.00 A record found' 62)14.00 A 55 15 2'No Previous record exists'15.00 A 24 2'CF2 Last transaction'16.00 A R RESTART17.00 A 1 20'LAST TRANSACTION +18.00 A INFORMATION'19.00 A 5 2'Product'20.00 A PRODCT R +121.00 A 7 2'Description'22.00 A DESCRP R +123.00 A 9 2'Qty'24.00 A QTY R +1REFFLD(QTY)

Questo processo è illustrato nel Flusso di programma.


Il codice operazione RPG COMMIT viene specificato dopo l'aggiornamento del file PRDMSTP e lascrittura del record nel file di registrazione delle transazioni. Poiché ogni richiesta all'operatorerappresenta un limite per una nuova transazione, la transazione viene considerata come una transazionea singolo Invio.

Il nome utente viene trasmesso al programma quando viene richiamato. Il percorso di accesso per il filedi registrazione delle transazioni è definito in sequenza LIFO (last-in-first-out) in modo che il programmapossa accedere facilmente all'ultimo record immesso.

L'utente della stazione di lavoro può riavviare il programma dopo un errore di sistema o di lavoroutilizzando la stessa funzione che ha identificato il punto in cui è stata arrestata l'immissione di dati. Nonè necessario aggiungere nuovo codice al programma. Se si sta attualmente utilizzando un file diregistrazione delle transazioni ma non lo si sta utilizzando per appurare il punto in cui ci si trova,aggiungere il nome utente al file di registrazione delle transazioni (presumendo che i nomi utente sianounivoci) e utilizzare questo approccio nel programma.

Il seguente esempio mostra il programma RPG utilizzato. Le istruzioni richieste per il controllo delcommit sono contrassegnate con delle frecce (==>).

Programma RPGSEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... .. 7 ..=>1.00 FPRDMSTP UP E K DISK KCOMIT=>2.00 FISSLOGL IF E K DISK KCOMIT

3.00 PRDISSD CP E WORKSTN4.00 *ENTRY PLIST5.00 PARM USER 106.00 C*7.00 C* Initialize fields used in Trans Log Rcd8.00 C*9.00 C MOVE UDATE DATE10.00 C*11.00 C* Basic processing loop12.00 C*13.00 C LOOP TAG14.00 C EXFMTPROMPT15.00 C 98 GOTO END End of pgm16.00 C 97 DO Where am I17.00 C EXSR WHERE18.00 C GOTO LOOP19.00 C END20.00 C PRODCT CHAINPRDMSTR 61 Not found21.00 C 61 GOTO LOOP22.00 C ONHAND SUB QTY TEST 50 62 Less than23.00 C 62 DO Not enough24.00 C EXCPTRLSMST Release lock25.00 C GOTO LOOP26.00 C END27.00 C*28.00 C* Update master record and output the Transaction Log Record29.00 C*30.00 C Z-ADDTEST ONHAND31.00 C UPDATPRDMSTR32.00 C WRITEISSLOGR

=>33.00 C COMIT34.00 C GOTO LOOP35.00 C*36.00 C* End of program processing37.00 C*38.00 C END TAG39.00 C SETON LR


40.00 C*41.00 C* WHERE subroutine for "Where am I" requests42.00 C*43.00 C WHERE BEGSR44.00 C USER CHAINISSLOGL 55 Not found45.00 C N55 EXFMTRESTART46.00 C ENDSR47.00 OPRDMSTR E RLSMST

Programma CL utilizzato per richiamare il programma RPG PRDISSSEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..

1.00 PGM2.00 DCL &USER *CHAR LEN(10)3.00 STRCMTCTL LCKLVL(*CHG)4.00 RTVJOBA USER(&USER)5.00 CALL PRDISS PARM(&USER)6.00 MONMSG MSGID(RPG900l) EXEC(ROLLBACK)7.00 ENDCMTCTL8.00 ENDPGM

Per utilizzare il controllo del commit in questo programma, viene normalmente specificato un livello diblocco *CHG. Il record viene bloccato dalla modifica finché non viene eseguita un'operazione di commit.Notare che se è presente una quantità insufficiente di inventario, il record viene rilasciato in modoesplicito. (Se il record non viene rilasciato in modo esplicito nel programma, viene rilasciato quando ilsuccessivo record viene letto per l'aggiornamento dal file).

In questo esempio, l'utilizzo del livello di blocco *ALL non comporta alcun vantaggio aggiuntivo. Seviene utilizzato *ALL, è necessario utilizzare un'operazione di rollback o di commit per rilasciare il recordquando la quantità disponibile è risultata insufficiente.

Il codice precedente è un programma CL che richiama il programma RPG PRDISS. Notare l'utilizzo dicomandi STRCMTCTL/ENDCMTCTL. Il nome utente univoco viene richiamato (comando RTVJOBA) etrasmesso al programma. L'utilizzo del comando MONMSG per causare un rollback è descrittonell'Esempio: utilizzo di un programma di elaborazione standard per avviare un'applicazione.Concetti correlati

“Esempio: utilizzo di un programma di elaborazione standard per avviare un'applicazione” a pagina 101Un programma di elaborazione standard è un modo per riavviare l'applicazione utilizzando un singolofile di database come oggetto di notifica per tutte le applicazioni. Questo approccio presume che i nomidi profilo utente siano univoci in base all'utente per tutte le applicazioni che utilizzano il programmastandard.“Esempio: oggetto di notifica univoco per ciascun programma” a pagina 96L'utilizzo di un singolo oggetto di notifica univoco per ciascun lavoro consente l'utilizzo diun'identificazione di commit descritta esternamente anche se potrebbero esserci più utenti dello stessoprogramma.

Esempio: utilizzo di un oggetto di notifica per avviare un'applicazioneQuando viene avviato dopo una fine anomala, un programma può cercare una voce nell'oggetto dinotifica. Se la voce esiste, il programma può riavviare una transazione. Dopo che la transazione è stataavviata nuovamente, l'oggetto di notifica viene cancellato dal programma per evitare che avvii la stessatransazione un'ennesima volta.

È possibile utilizzare un oggetto di notifica nei seguenti modi:v Se l'identificazione di commit viene inserita in un file di database, eseguire la query di questo file per

determinare dove riavviare ciascun lavoro di applicazione o di stazione di lavoro.


v Se l'identificazione di commit viene inserita in una coda messaggi per una specifica stazione di lavoro,un messaggio può essere inviato agli utenti della stazione di lavoro quando si collegano per informarlidell'ultima transazione di cui è stato eseguito il commit.

v Se l'identificazione di commit viene inserita in un file di database che ha un nome utente o una chiave,il programma può leggere questo file quando viene avviato. Se esiste un record nel file, riavviare ilprogramma. Il programma può inviare un messaggio all'utente della stazione di lavoro che identifical'ultima transazione di cui è stato eseguito il commit. Eventuali ripristini vengono eseguiti dalprogramma. Se nel file di database esisteva un record, il programma cancella tale record alla fine delprogramma.

v Per un'applicazione batch, l'identificazione di commit può essere inserita in un'area di dati che contienei totali, le impostazioni di commutazione e altre informazioni sullo stato che occorrono per riavviarel'applicazione. Quando viene avviata, l'applicazione accede all'area di dati e verifica i valori in essamemorizzati. Se l'applicazione termina normalmente, l'area di dati è configurata per la successivaesecuzione.

v Per un'applicazione batch, l'identificazione di commit può essere inviata a una coda messaggi. Unprogramma eseguito quando viene avviata l'applicazione può richiamare i messaggi dalla coda eriavviare i programmi.

È possibile utilizzare diverse tecniche per riavviare le applicazioni, a seconda delle esigenze delleapplicazioni. Quando si sceglie la tecnica, considerare le seguenti informazioni:v Quando ci sono più utenti di un programma contemporaneamente, non è possibile utilizzare una

singola area di dati come oggetto di notifica perché, dopo una fine di sistema anomala, leidentificazioni di commit per ogni utente si sovrapporranno nell'area di dati.

v La progettazione per eliminare le informazioni nell'oggetto di notifica deve gestire la situazione in cuisi verifica un errore immediatamente dopo l'utilizzo delle informazioni:– Se le informazioni vengono cancellate immediatamente, esse non esistono se si verifica un altro

errore prima dell'elaborazione della transazione interrotta.– Le informazioni nell'oggetto di notifica non devono essere cancellate fino alla corretta elaborazione

della transazione interrotta. In questo caso, esisterà più di una voce nell'oggetto di notifica se sitratta di un file di database o di una coda messaggi.

– Il programma deve accedere all'ultimo record, se c'è più di una voce.v Un oggetto di notifica non può essere utilizzato per fornire all'utente della stazione di lavoro l'ultima

transazione di cui è stato eseguito il commit perché l'oggetto di notifica viene aggiornato solo se siverifica un errore di sistema o di lavoro o se esistono delle modifiche di cui non è stato eseguito ilcommit quando un lavoro viene terminato in modo normale.

v Se per l'utente della stazione di lavoro vengono visualizzate delle informazioni, esse devono esseresignificative. Questo potrebbe richiedere che il programma traduca dei codici conservati nell'oggetto dinotifica in informazioni che aiuteranno l'utente ad eseguire il riavvio.

v Le informazioni per il riavvio devono essere visualizzate se l'utente della stazione di lavoro ne habisogno. È necessaria della logica aggiuntiva nel programma per evitare che le informazioni venganonuovamente visualizzate quando non sono più significative.

v Un singolo oggetto di notifica e un programma di elaborazione standard possono fornire una funzionedi riavvio se l'oggetto di notifica è un file di database. Questo programma di elaborazione standardviene richiamato dai programmi che richiedono la capacità di eseguire il riavvio per ridurre al minimole modifiche a ogni singolo programma.


Concetti correlati

“Oggetto di notifica del commit” a pagina 53Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioniche identificano l'ultima transazione eseguita correttamente completata per una specifica definizione dicommit se tale definizione di commit non è stata terminata normalmente.

Esempio: oggetto di notifica univoco per ciascun programmaL'utilizzo di un singolo oggetto di notifica univoco per ciascun lavoro consente l'utilizzo diun'identificazione di commit descritta esternamente anche se potrebbero esserci più utenti dello stessoprogramma.

Nei seguenti esempi, un file di database viene utilizzato come un oggetto di notifica e viene utilizzatosolo da questo programma.

Il programma ha due file di database (PRDMSTP e PRDLOCP) che devono essere aggiornati per lericevute da inventariare. Il file video utilizzato dal programma è denominato PRDRCTD. Un file didatabase, PRDRCTP, viene utilizzato come oggetto di notifica. Questo oggetto di notifica è definito per ilprogramma come un file e viene utilizzato anche come definizione di una struttura di dati per lafunzione di notifica.


DDS per il file fisico PRDLOCPSEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7

1.00 A R PRDLOCR TEXT('Location record')2.00 A PRODCT 3 COLHDG('Product' 'Number')3.00 A LOCATN 6 COLHDG('Location')4.00 A LOCAMT 5 0 COLHDG('Location' 'Amount')5.00 A EDTCDE(Z)6.00 A K PRODCT7.00 A K LOCATN

DDS per il file video PRDRCTDSEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..

1.00 A REF(PRDMSTP)2.00 A R PROMPT3.00 A CA03(98 'End of program')4.00 A SETOFF(71 'RESTART')5.00 A 1 20'PRODUCT RECEIPTS'6.00 A 3 2'Quantity'7.00 A QTY 3 OI +18.00 A +6'Product'9.00 A PRODCT R I +110.00 A 61 ERRMSG('No record +11.00 A found in the +12.00 A master file' 62)13.00 A +6'Location'14.00 A LOCATN R I +1REFFLD(LOCATN PRDLOCP)15.00 A 62 ERRMSG('No record +16.00 A found in the +17.00 A location file' 62)18.00 A 9 2'Last Transaction'19.00 A 71 +6'This is restart +20.00 A information'21.00 A DSPATR(HI BL)22.00 A 12 2'Quantity'23.00 A 12 12'Product'24.00 A 12 23'Location'


25.00 A 12 35'Description'26.00 A LSTPRD R 14 15REFFLD(PRODCT)27.00 A LSTLOC R 14 26REFFLD(LOCATN *SRC)28.00 A LSTQTY R 14 5REFFLD(QTY *SRC)29.00 A EDTCDE(Z)30.00 A LSTDSC R 14 35REFFLD(DESCRP)

DDS per l'oggetto di notifica e la struttura di dati descritta esternamente (PRDRCTP)SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..

1.00 A LIFO2.00 A REF(PRDMSTP)3.00 A R PRDRCTR4.00 A USER 105.00 A PRODCT R6.00 A DESCRP R7.00 A QTY 3 08.00 A LOCATN R REFFLD(LOCATN PRDLOCP)9.00 A K USER

Il programma elabora l'oggetto di notifica nel seguente modo:v Inizialmente, il programma elabora casualmente l'oggetto di notifica e visualizza un record se esiste per

la chiave specifica:– Se esistono più record, viene utilizzato l'ultimo record per questa chiave perché il file PRDRCTP è in

sequenza LIFO.– Se non esiste alcun record, una transazione non è stata interrotta e quindi non è necessario

riavviarla.– Se il programma ha esito negativo prima della prima operazione di commit eseguita correttamente,

non valuta che è richiesto il riavvio.v La routine per cancellare i dati dall'oggetto di notifica si trova alla fine del programma:

– Se si sono verificati più malfunzionamenti, la routine può gestire la cancellazione di più recordnell'oggetto di notifica.

– Anche se il sistema inserisce l'identificazione di commit in un file di database, l'identificazione dicommit deve essere specificata come una variabile nel programma RPG.

– Poiché RPG consente la descrizione esterna di una struttura di dati, una struttura di dati è un modopratico per specificare l'identificazione di commit. In questo esempio, la struttura di dati utilizza lastessa descrizione esterna utilizzata dal file di database come oggetto di notifica.

L'elaborazione per questo programma richiede all'utente un numero di prodotto, un'ubicazione e unaquantità:v Devono essere aggiornati due file:

– Il file master del prodotto (PRDMSTP)– Il file di ubicazione del prodotto (PRDLOCP)

v In ciascun file deve esistere un record prima che l'uno o l'altro venga aggiornato.v Il programma sposta i campi di immissione ai corrispondenti ultimi campi dopo la corretta immissione

di ciascuna transazione. Questi ultimi campi vengono visualizzati all'operatore su ciascuna richiestacome feedback dell'immissione più recente.

v Se le informazioni per il riavvio esistono, vengono spostate a questi ultimi campi e sul pannello vienepresentato un messaggio speciale.

Questo processo è illustrato nella seguente figura. Il nome utente viene trasmesso al programma perfornire un record univoco nell'oggetto di notifica.


Il seguente esempio è relativo al codice sorgente RPG. L'oggetto di notifica (file PRDRCTP) vieneutilizzato come un file normale all'inizio e alla fine del programma e viene specificato anche comeoggetto di notifica nel CL (comando STRCMTCTL) prima di richiamare il programma.

Sorgente RPGSEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..

1.00 FPRDMSTP UF E K DISK KCOMIT2.00 FPRDLOCP UF E K DISK KCOMIT3.00 FPRDRCTD CF E WORKSTN4.00 F*5.00 F* The following file is the specific notify object for this pgm.6.00 F* It is accessed only in a restart situation and at the7.00 F* end of the program to delete any records. The records8.00 F* are written to the notify object by Commitment Control.9.00 F*10.00 FPRDRCTP UF E K DISK11.00 ICMTID E DSPRDRCTP12.00 C *ENTRY PLIST13.00 C PARM USER10 1014.00 C MOVE USER10 USER15.00 C*16.00 C* Check for restart information - get last rcd per user17.00 C* PRDRCTP file access path is in LIFO sequence18.00 C*19.00 C USER CHAINPRDRCTR 20 Not found20.00 C N20 DO Restart21.00 C EXSR MOVLST Move to last22.00 C SETON 71 Restart23.00 C END24.00 C*25.00 C* Basic processing loop26.00 C*27.00 C L00P TAG28.00 C EXFMTPROMPT29.00 C 98 GOTO END End of pgm30.00 C PRODCT CHAINPRDMSTR 61 Not found31.00 C 61 GOTO L00P32.00 C KEY KLIST33.00 C KFLD PRODCT34.00 C KFLD LOCATN35.00 C KEY CHAINPRDLOCR 62 Not found36.00 C 62 DO37.00 C EXCPTRLSMST Release lck38.00 C GOTO L00P39.00 C END40.00 C ADD QTY ONHAND Add41.00 C ADD QTY LOCAMT42.00 C UPDATPRDMSTR Update43.00 C UPDATPRDLOCR Update44.00 C*45.00 C* Commit and move to previous fields46.00 C*47.00 C CMTID COMIT48.00 C EXSR MOVLST Move to last49.00 C GOTO L00P50.00 C*51.00 C* End of program processing52.00 C*53.00 C END TAG54.00 C SETON LR55.00 C*56.00 C* Delete any records in the notify object57.00 C*


58.00 C DLTLP TAG59.00 C USER CHAINPRDRCTR 20 Not found60.00 C N20 DO61.00 C DELETPRDRCTR Delete62.00 C GOTO DLTLP63.00 C END64.00 C*65.00 C* Move to -Last Used- fields for operator feedback66.00 C*67.00 C MOVLST BEGSR68.00 C MOVE PRODCT LSTPRD69.00 C MOVE LOCATN LSTLOC70.00 C MOVE QTY LSTQTY71.00 C MOVE DESCRP LSTDSC72.00 C ENDSR73.00 OPRDMSTR E RLSMST

Concetti correlati

“Esempio: utilizzo di un file di registrazione delle transazioni per avviare un'applicazione” a pagina 90Questo esempio fornisce il codice di esempio e le istruzioni su come utilizzare un file di registrazionedelle transazioni per avviare un'applicazione dopo una fine anomala.“Oggetto di notifica del commit” a pagina 53Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioniche identificano l'ultima transazione eseguita correttamente completata per una specifica definizione dicommit se tale definizione di commit non è stata terminata normalmente.“Esempio: oggetto di notifica singolo per tutti i programmi”L'utilizzo di un singolo oggetto di notifica per tutti i programmi è vantaggioso. Questo è dovuto al fattoche tutte le informazioni richieste per il riavvio si trovano nello stesso oggetto ed è possibile utilizzare unapproccio standard all'oggetto di notifica in tutti i programmi.

Esempio: oggetto di notifica singolo per tutti i programmiL'utilizzo di un singolo oggetto di notifica per tutti i programmi è vantaggioso. Questo è dovuto al fattoche tutte le informazioni richieste per il riavvio si trovano nello stesso oggetto ed è possibile utilizzare unapproccio standard all'oggetto di notifica in tutti i programmi.

In questa situazione, utilizzare una combinazione univoca di identificazioni di utente e programma perassicurare che il programma acceda alle informazioni corrette al suo riavvio.

Poiché le informazioni richieste per il riavvio potrebbero variare da programma a programma, nonutilizzare una struttura di dati descritta esternamente per l'identificazione di commit. Se viene utilizzatoun singolo oggetto di notifica, il precedente programma può descrivere la struttura di dati all'interno delprogramma piuttosto che esternamente. Ad esempio:1 10 USER

11 20 PGMNAM21 23 PRODCT24 29 LOCATN30 49 DESC50 51 0 QTY52 220 DUMMY

In ogni programma che utilizza questo oggetto di notifica, le informazioni specificate per l'identificazionedi commit sono univoche per il programma (i nomi di utente e programma non sono univoci). L'oggettodi notifica deve essere abbastanza grande da contenere la quantità massima di informazioni che unprogramma può inserire nell'identificazione di commit.


Concetti correlati

“Esempio: oggetto di notifica univoco per ciascun programma” a pagina 96L'utilizzo di un singolo oggetto di notifica univoco per ciascun lavoro consente l'utilizzo diun'identificazione di commit descritta esternamente anche se potrebbero esserci più utenti dello stessoprogramma.“Oggetto di notifica del commit” a pagina 53Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioniche identificano l'ultima transazione eseguita correttamente completata per una specifica definizione dicommit se tale definizione di commit non è stata terminata normalmente.

Esempio: utilizzo di un programma di elaborazione standard peravviare un'applicazioneUn programma di elaborazione standard è un modo per riavviare l'applicazione utilizzando un singolofile di database come oggetto di notifica per tutte le applicazioni. Questo approccio presume che i nomidi profilo utente siano univoci in base all'utente per tutte le applicazioni che utilizzano il programmastandard.

Nota: utilizzando questo esempio di codice, si accettano i termini indicati nella sezione “Informazionisull'esonero di responsabilità e licenza del codice” a pagina 121.

Per questo approccio, il file fisico NFYOBJP viene utilizzato come oggetto di notifica e definito come:Nome profilo utente univoco 10 caratteriIdentificazione programma 10 caratteriInformazioni per riavvio Campo caratteri

(Deve essere abbastanza grandeda contenere la quantità massima diinformazioni per riavviarei programmi che richiedono informazioniper il riavvio.Questo campo è richiesto daiprogrammi applicativi.Nell'esempio, si presume che abbiauna lunghezza di 200).

Il file viene creato con SHARE(*YES). I primi due campi nel file sono la chiave per il file. (Questo file puòanche essere definito come una struttura di dati nei programmi RPG).Concetti correlati

“Esempio: utilizzo di un file di registrazione delle transazioni per avviare un'applicazione” a pagina 90Questo esempio fornisce il codice di esempio e le istruzioni su come utilizzare un file di registrazionedelle transazioni per avviare un'applicazione dopo una fine anomala.

Esempio: codice per un programma di elaborazione standardQuesto esempio mostra il codice per un programma di elaborazione standard che può essere utilizzatoper riavviare l'applicazione utilizzando un file di database come oggetto di notifica per tutte leapplicazioni.

L'applicazione presentata nel seguente esempio di codice esegue le seguenti operazioni:1. Il programma applicativo riceve il nome utente in un parametro o lo utilizza con il nome programma

come un identificativo univoco nell'oggetto di notifica.2. Il programma applicativo trasmette un codice di richiesta pari a R al programma di elaborazione di

commit standard, che determina se nell'oggetto di notifica è presente un record.3. Se il programma di elaborazione di commit standard restituisce un codice pari a 1, significa che è

stato trovato un record e il programma applicativo presenta le informazioni necessarie per il riavvioall'utente.

4. Il programma applicativo procede con la normale elaborazione.


5. Una volta completata una transazione, i valori vengono salvati per riferimento in modo che l'utentedella stazione di lavoro possa vedere le operazioni effettuate per la transazione precedente.Le informazioni salvate non vengono fornite dall'oggetto di notifica perché l'oggetto idi notifica vieneaggiornato solo se si verifica un errore di lavoro o sistema.


Esempio di programma applicativoSEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..

1.00 FPRDMSTP UF E K DISK KCOMIT2.00 FPRDLOCP UF E K DISK KCOMIT3.00 FPRDRCTD CF E WORKSTN4.00 F*5.00 F* The following is a compile time array which contains the6.00 F* restart information used in the next example7.00 F*8.00 E RTXT 50 50 1 Restart text9.00 I*10.00 I* Data structure used for info passed to notify object11.00 I*12.00 ICMTID DS13.00 I 1 10 USER14.00 I 11 20 PGMNAM15.00 I 21 23 PRODCT16.00 I 24 29 LOCATN17.00 I 30 49 DESCRP18.00 I P 50 510QTY19.00 I 52 170 DUMMY20.00 I 171 220 RSTART21.00 C *ENTRY PLIST22.00 C PARM USER10 1023.00 C*24.00 C* Initialize fields used to communicate with std program25.00 C*26.00 C MOVE USER10 USER27.00 C MOVEL'PRDRC2' PGMNAM28.00 C MOVE 'R' RQSCOD Read Rqs29.00 C CALL 'STDCMT'30.00 C PARM RQSCOD 131.00 C PARM RTNCOD 132.00 C PARM CMTID 220 Data struct33.00 C RTNCOD IFEQ '1' Restart34.00 C EXSR MOVLST Move to last35.00 C SETON 71 Restart36.00 C END37.00 C*38.00 C* Initialize fields used in notify object39.00 C*40.00 C MOVEARTXT,1 RSTART Move text41.00 C*42.00 C* Basic processing loop43.00 C*44.00 C LOOP TAG45.00 C EXFMTPROMPT46.00 C 98 GOTO END47.00 C PRODCT CHAINPRDMSTR 61 Not found48.00 C 61 GOTO LOOP49.00 C KEY KLIST50.00 C KFLD PRODCT51.00 C KFLD LOCATN


SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..

52.00 C KEY CHAINPRDLOCR 62 Not found53.00 C 62 DO54.00 C EXCPTRLSMST Release lck55.00 C GOTO LOOP56.00 C END57.00 C ADD QTY ONHAND Add58.00 C ADD QTY LOCAMT59.00 C UPDATPRDMSTR Update60.00 C UPDATPRDLOCR Update61.00 C*62.00 C* Commit and move to previous fields63.00 C*64.00 C CMTID COMIT65.00 C EXSR MOVLST Move to last66.00 C GOTO LOOP67.00 C* End of program processing68.00 C*69.00 C END TAG70.00 C MOVE 'D' RQSCOD Dlt Rqs71.00 C CALL 'STDCMT'72.00 C PARM RQSCOD73.00 C PARM RTNCOD74.00 C PARM CMTID75.00 C SETON LR76.00 C*77.00 C* Move to -Last Used- fields for operator feedback78.00 C*79.00 C MOVLST BEGSR80.00 C MOVE PRODCT LSTPRD81.00 C MOVE LOCATN LSTLOC82.00 C MOVE DESCRP LSTDSC83.00 C MOVE QTY LSTQTY84.00 C ENDSR85.00 OPRDMSTR E RLSMST86.00 ** RTXT Restart Text87.00 Inventory Menu - Receipts Option

Flusso di elaborazione:

Il programma standard viene richiamato dalle applicazioni che devono essere riavviate.

I programmi applicativi trasmettono questo elenco di parametri al programma standard:v Codice di richiestav Codice di ritornov Nome della struttura dati (il contenuto dell'oggetto di notifica)

I codici di richiesta eseguono le seguenti operazioni:v R (Lettura)

Richiama l'ultimo record aggiunto all'oggetto di notifica con la stessa chiave. Il codice di ritorno èimpostato come:

0 Non è disponibile alcun record (nessun riavvio richiesto).

1 Record restituito nel campo delle informazioni per il riavvio (riavvio richiesto).v WA (Scrittura)

Scrive un record nel file. Questo codice può essere utilizzato se si utilizza un oggetto di notifica perproprie attività. Ad esempio, se determina che la transazione deve essere riavviata, il programma puòscrivere un record per l'oggetto di notifica per simulare cosa farà il sistema se si verifica unmalfunzionamento di un lavoro o del sistema.


v DE (Cancellazione)Cancella tutti i record nell'oggetto di notifica con la stessa chiave. Il codice di ritorno è impostato come:

0 Non esiste alcun record da cancellare.

1 Sono stati cancellati uno o più record.v OE (Apertura)

Il codice richiesta O è facoltativo e viene utilizzato per evitare di dover avviare il programma dielaborazione ogni volta che viene richiamato.

v CA (Chiusura)Dopo che è stato utilizzato il codice di richiesta di apertura, l'utilizzo della richiesta di chiusuraassicura che il file venga chiuso.

v SA (Ricerca)Restituisce l'ultimo record per questo utente. Il nome programma non viene utilizzato. Questo codicepuò essere utilizzato in un programma iniziale per determinare se è richiesto il riavvio.

Esempio: codice per un programma di elaborazione di commit standardIl programma di elaborazione di commit standard (STDCMT) esegue le funzioni richieste per comunicarecon un singolo oggetto di notifica utilizzato da tutte le applicazioni.

Mentre la funzione di controllo del commit scrive automaticamente una voce nell'oggetto di notifica, unprogramma standard scritto dall'utente deve elaborare l'oggetto di notifica. Il programma standardsemplifica e standardizza l'approccio.

Il programma viene scritto per verificare i parametri trasmessi ed eseguire l'azione appropriata nelseguente modo.

O=AperturaIl programma chiamante richiede che il file di oggetto di notifica venga mantenuto aperto allarestituzione. Poiché l'oggetto di notifica viene aperto implicitamente dal programma RPG, ilprogramma non lo deve chiudere. L'indicatore 98 viene impostato in modo che il programmaesegua la restituzione con LR disattivato per conservare le aree di lavoro del programma e lascil'oggetto di notifica aperto in modo che possa essere chiamato nuovamente senza un sovraccaricoeccessivo.

C=ChiusuraIl programma richiamante ha determinato che non ha più bisogno dell'oggetto di notifica erichiede una chiusura. L'indicatore 98 è disattivato per consentire una chiusura completadell'oggetto di notifica.

R=LetturaIl programma chiamante richiede che un record con dei campi chiave corrispondenti venga letto erestituito. Il programma utilizza i campi chiave trasmessi per provare a richiamare un record daNFYOBJP. Se esistono dei record duplicati per la stessa chiave, viene restituito l'ultimo record. Ilcodice di ritorno viene impostato adeguatamente e, se il record esisteva, viene restituito nellastruttura di dati CMTID.

W=ScritturaIl programma chiamante richiede che un record venga scritto nell'oggetto di notifica perconsentire il riavvio del programma chiamante la volta successiva che viene richiamato. Ilprogramma scrive il contenuto dei dati trasmessi come un record in NFYOBJP.

D=CancellazioneIl programma chiamante richiede che i record per questa chiave corrispondente venganocancellati. Questa funzione viene di norma eseguita dopo il corretto completamento delprogramma chiamante per eliminare le eventuali informazioni sul riavvio. Il programma prova acancellare i record per i campi chiave trasmessi. Se non esiste alcun record, viene restituito uncodice di ritorno differente.


S=RicercaIl programma chiamante richiede una ricerca per un record per uno specifico utente,indipendentemente da quale programma lo abbia scritto. Questa funzione viene utilizzata nelprogramma per il collegamento per indicare che è richiesto il riavvio. Il programma utilizza soloil nome utente come chiave per verificare se esistono i record. Il codice di ritorno viene impostatoin modo appropriato e il contenuto dell'ultimo record per questa chiave (se esiste) viene letto erestituito.

Il seguente esempio mostra il programma di elaborazione di commit standard, STDCMT.

Programma di elaborazione di commit standard


SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..

1.00 FNFYOBJP UF E K DISK A2.00 ICMTID DS3.00 I 1 10 UNQUSR4.00 I 11 20 UNQPGM5.00 I 21 220 BIGFLD6.00 C *ENTRY PLIST7.00 C PARM RQSCOD 18.00 C PARM RTNCOD 19.00 C PARM CMTID 22010.00 C UNQUSR CABEQ*BLANKS BADEND H1 Invalid11.00 C UNQPGM CABEQ*BLANKS BADEND H2 Invalid12.00 C*13.00 C* 'O' for Open14.00 C*15.00 C RQSCOD IFEQ 'O' Open16.00 C SETON 98 End LR17.00 C GOTO END18.00 C END19.00 C*20.00 C* 'C' for Close21.00 C*22.00 C RQSCOD IFEQ 'C' Close23.00 C SETOF 9824.00 C GOTO END25.00 C END26.00 C*27.00 C* 'R' for Read - Get last record for the key28.00 C*29.00 C RQSCOD IFEQ 'R' Read30.00 C KEY KLIST31.00 C KFLD UNQUSR32.00 C KFLD UNQPGM33.00 C KEY CHAINNFYOBJR 51 Not found34.00 C 51 MOVE '0' RTNCOD35.00 C 51 GOTO END36.00 C MOVE '1' RTNCOD Found37.00 C LOOPl TAG38.00 C KEY READENFYOBJR 20 EOF39.00 C 20 GOTO END40.00 C GOTO LOOP141.00 C END42.00 C*43.00 C* 'W' FOR Write44.00 C*45.00 C RQSCOD IFEQ 'W' Write46.00 C WRITENFYOBJR47.00 C GOTO END48.00 C END


49.00 C*50.00 C* 'D' for Delete - Delete all records for the key51.00 C*52.00 C RQSCOD IFEQ 'D' Delete53.00 C KEY CHAINNFYOBJR 51 Not found54.00 C 51 MOVE '0' RTNCOD55.00 C 51 GOTO END56.00 C MOVE '1' RTNCOD Found57.00 C LOOP2 TAG58.00 C DELETNFYOBJR59.00 C KEY READENFYOBJR 20 EOF60.00 C N20 GOTO LOOP261.00 C GOTO END62.00 C END63.00 C*64.00 C* 'S' for Search for the last record for this user65.00 C* (Ignore the -Program- portion of the key)66.00 C*67.00 C RQSCOD IFEQ 'S' Search68.00 C UNQUSR SETLLNFYOBJR 20 If equal69.00 C N20 MOVE '0' RTNCOD70.00 C N20 GOTO END71.00 C MOVE '1' RTNCOD Found72.00 C LOOP3 TAG73.00 C UNQUSR READENFYOBJR 20 EOF74.00 C N20 GOTO LOOP375.00 C GOTO END76.00 C END77.00 C*78.00 C* Invalid request code processing79.00 C*80.00 C SETON H2 Bad RQS code81.00 C GOTO BADEND82.00 C*83.00 C* End of program processing84.00 C*85.00 C END TAG86.00 C N98 SETON LR87.00 C RETRN88.00 C* BADEND tag is used then fall thru to RPG cycle error return89.00 C BADEND TAG

Concetti correlati

“Esempio: utilizzo di un programma di elaborazione standard per decidere se riavviare l'applicazione”Il programma iniziale può richiamare il programma di elaborazione di commit iniziale per determinare seè necessario eseguire il riavvio. L'utente della stazione di lavoro può quindi decidere se eseguire ilriavvio.

Esempio: utilizzo di un programma di elaborazione standard per decidere seriavviare l'applicazioneIl programma iniziale può richiamare il programma di elaborazione di commit iniziale per determinare seè necessario eseguire il riavvio. L'utente della stazione di lavoro può quindi decidere se eseguire ilriavvio.

Il programma iniziale trasmette un codice di richiesta S (ricerca) al programma standard che ricerca uneventuale record per l'utente. Se esiste un record, le informazioni per il riavvio vengono trasmesse alprogramma iniziale e le informazioni vengono visualizzate per l'utente della stazione di lavoro.

L'identificazione di commit nell'oggetto di notifica contiene informazioni che il programma iniziale puòvisualizzare identificando quale programma deve essere riavviato. Ad esempio, gli ultimi 50 caratteridell'identificazione di commit possono essere riservati per contenere queste informazioni. Nel programmaapplicativo, queste informazioni possono trovarsi in una schiera al momento della compilazione ed essere


spostate alla struttura di dati in un passo di inizializzazione. Esempio: codice per un programma dielaborazione di commit standard che mostra come includere questa operazione nel programmaapplicativo.

Il seguente esempio mostra un programma iniziale che determina se esiste un record nell'oggetto dinotifica.

Esempio: programma iniziale


SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7

1.00 PGM2.00 DCLF CMTINLD3.00 DCL &RQSCOD *CHAR LEN(1) VALUE(S) /* Search */4.00 DCL &RTNCOD *CHAR LEN(1)5.00 DCL &CMTID *CHAR LEN(220)6.00 DCL &USER *CHAR LEN(10)7.00 DCL &INFO *CHAR LEN(50)8.00 RTVJOBA USER(&USER)9.00 CHGVAR &CMTID (&USER *CAT XX)10.00 /* The XX is required to prevent a blank Pgm nam */11.00 CALL STDCMT PARM(&RQSCOD &RTNCOD &CMTID)12.00 IF (&RTNCOD *EQ '1') DO /* RESTART REQD */13.00 CHGVAR &INFO %SST(&CMTID 171 50)14.00 SNDRCVF RCDFMT(RESTART)15.00 ENDDO16.00 /* */17.00 /* Enter normal initial program statements */18.00 /* or -TFRCTL- to first menu program */19.00 /* */20.00 ENDPGM

Concetti correlati

“Esempio: codice per un programma di elaborazione di commit standard” a pagina 104Il programma di elaborazione di commit standard (STDCMT) esegue le funzioni richieste per comunicarecon un singolo oggetto di notifica utilizzato da tutte le applicazioni.“Oggetto di notifica del commit” a pagina 53Un oggetto di notifica è una coda messaggi, un'area dati o un file di database che contiene le informazioniche identificano l'ultima transazione eseguita correttamente completata per una specifica definizione dicommit se tale definizione di commit non è stata terminata normalmente.

Risoluzione dei problemi relativi a transazioni e controllo del commitQueste informazioni possono aiutare a risolvere gli errori di controllo del commit, rilevare le condizionidi stallo, ripristinare le transazioni dopo un errore nelle transazioni, sapere quando forzare le operazionidi commit e rollback e quando annullare la sincronizzazione e terminare i rollback a lunga esecuzione.

Errori del controllo del commitQuando si utilizza il controllo del commit, è importante comprendere quali condizioni causano deglierrori e quali no.

In generale, gli errori si verificano quando le funzioni del controllo del commit vengono utilizzate inmodo non congruente, come ad esempio l'esecuzione di un comando ENDCMTCTL (Fine controllocommit) quando i file che utilizzano la definizione di commit sono ancora aperti.


Errori durante l'elaborazione di commit

Se si verifica un errore di sistema o nelle comunicazioni durante un'operazione di commit, potrebbeessere necessario eseguire la risincronizzazione per assicurare che i gestori transazioni mantengano i daticongruenti su tutti i sistemi coinvolti nella transazione. La modalità di funzionamento dellarisincronizzazione e il modo in cui essa influenza l'operazione di commit dipendono dai seguenti fattori:v L'opzione di commit Attesa risultato.v Lo stato della transazione.

Se l'errore è di entità tale da essere irreversibile, o se non può essere corretto nel tempo previsto, glioperatori di sistema per gli altri sistemi coinvolti nella transazione devono prendere una decisioneeuristica. La decisione euristica esegue il commit o il rollback delle modifiche apportate su tale sistemadurante la transazione. Se l'errore viene corretto dopo tale decisione, e la risincronizzazione rileva che ladecisione ha causato dei problemi di integrità dei dati, alla coda messaggi QSYSOPR viene inviato ilmessaggio CPD83D9 o il messaggio CPD83E9.Concetti correlati

“Definizione di commit per un commit in due fasi: Non attendere risultato” a pagina 37Quando si verifica un malfunzionamento nelle comunicazioni o di sistema durante un'operazione dicommit, ed è quindi richiesta una risincronizzazione, il valore predefinito prevede di attendere che larisincronizzazione sia terminata prima di completare l'operazione di commit.“Stati della transazione per il controllo del commit a due fasi” a pagina 31Una definizione di commit viene stabilita su ciascuna ubicazione che fa parte della rete del programma ditransazione. Per ciascuna definizione di commit, il sistema tiene traccia dello stato della sua transazionecorrente e della transazione precedente.

Condizioni di erroreSe si verifica un errore, viene inviato un messaggio di uscita per cui è possibile eseguire il monitoraggioin un programma.

Sono qui di seguito riportati alcuni errori tipici correlati al controllo del commit:v Vengono eseguiti dei comandi STRCMTCTL consecutivi senza un comando ENDCMTCTL intermedio.v I file vengono aperti sotto il controllo del commit, ma non è stato eseguito alcun comando

STRCMTCTL.Questa non è una condizione di errore per i programmi eseguiti in un gruppo di attivazione chedevono utilizzare la definizione di commit a livello di lavoro. La definizione di commit a livello dilavoro può essere avviata solo da un singolo programma ma, quando viene avviata da un programma,la definizione di commit a livello di lavoro viene utilizzata da qualsiasi programma in esecuzione in ungruppo di attivazione che non sta utilizzando una definizione di commit a livello di gruppo diattivazione. I programmi eseguiti in un gruppo di attivazione che devono utilizzare la definizione dicommit a livello di gruppo di attivazione devono prima avviare la definizione di commit a livello digruppo di attivazione con il comando STRCMTCTL.

v I file aperti per l'emissione sotto il controllo del commit non vengono registrati su giornale.v La prima operazione di apertura di un file condiviso pone il file sotto il controllo del commit, cosa che

invece non fanno le successive operazioni di apertura dello stesso file condiviso.v La prima operazione di apertura di un file condiviso non pone il file sotto il controllo del commit, cosa

che invece fanno le successive operazioni di apertura dello stesso file condiviso.v Il limite di blocchi di record per il lavoro viene raggiunto in una singola transazione.v Il programma emette un'operazione di lettura, un'operazione di commit e una modifica per lo stesso

record. L'operazione di lettura deve essere emessa nuovamente dopo l'operazione di commit perchél'operazione di commit ha liberato il blocco sul record.

v Per un'ubicazione in una fase, le risorse poste sotto il controllo del commit non risiedono nella stessaubicazione delle risorse che già sono sotto il controllo del commit per la definizione di commit.


v Delle modifiche di cui non è stato eseguito il commit esistono quando viene emesso un comandoENDCMTCTL.Questa non è una condizione di errore per il comando ENDCMTCTL se tutti i file sono chiusi,l'eventuale database remoto è disconnesso e nessuna risorsa di commit API è ancora associata alladefinizione di commit da terminare.

v Viene eseguito un comando di commit, rollback o ENDCMTCTL e non è stato eseguito un comandoSTRCMTCTL.Questa non è una condizione di errore per i programmi eseguiti in un gruppo di attivazione e ladefinizione di commit a livello di lavoro è attiva. La definizione di commit a livello di lavoro puòessere avviata solo da un singolo programma ma, quando viene avviata da un programma, ladefinizione di commit a livello di lavoro viene utilizzata da qualsiasi programma in esecuzione in ungruppo di attivazione che non sta utilizzando una definizione di commit a livello di gruppo diattivazione. I programmi eseguiti in un gruppo di attivazione e che devono utilizzare la definizione dicommit a livello di gruppo di attivazione devono prima avviare la definizione di commit a livello digruppo di attivazione con il comando STRCMTCTL.

v Un comando ENDCMTCTL viene eseguito con i file ancora aperti sotto il controllo del commit per ladefinizione di commit.

v Un lavoro che esegue un'operazione di salvataggio ha una o più definizioni di commit che non sitrovano a un limite di commit.

v Un'operazione di salvataggio durante l'utilizzo è terminata perché altri lavori con delle risorse di cui èpossibile eseguire il commit non hanno raggiunto un limite di commit nel tempo specificato per ilparametro SAVACTWAIT.

v Un processo di salvataggio durante l'utilizzo non è riuscito a continuare a causa di risorse di cui èpossibile eseguire il commit API aggiunte a più di una definizione di commit per un singolo lavoro.

v Più di 1023 definizioni di commit esistono per un singolo lavoro.v La conversazione a un'ubicazione remota si interrompe a causa di un errore di risorsa. Questo può

causare l'esecuzione del rollback della transazione.v Una risorsa in una fase aperta per l'aggiornamento è presente su un nodo che non ha iniziato

l'operazione di commit. È necessario rimuovere la risorsa o il nodo che ha iniziato la richiesta dicommit.

v Un'operazione di commit viene richiesta mentre la transazione è in uno stato di rollback richiesto(RBR). È necessario eseguire un'operazione di rollback.

v Un programma di uscita API emette una richiesta di commit o una richiesta di rollback.v Un programma di trigger emette una richiesta di commit o una richiesta di rollback per la definizione

di commit sotto cui è stato richiamato il programma di trigger.

Il programma di trigger può avviare una definizione di commit separata e emettere una richiesta dicommit o di rollback per tale definizione.

Condizioni senza erroriSono qui di seguito riportate alcune situazioni per il controllo del commit in cui non si verificano errori.v Un'operazione di commit o di rollback viene eseguita e nessuna risorsa è sotto il controllo del commit.

Questo consente di includere le operazioni di commit o di rollback nel programma senza considerarese ci sono risorse sotto il controllo del commit. Consente anche di specificare un'identificazione dicommit prima di eseguire modifiche di cui è possibile eseguire il commit.

v Un'operazione di commit o di rollback viene eseguita e non ci sono modifiche di risorse di cui non èstato eseguito il commit. Questo consente di includere le operazioni di commit e rollback nelprogramma senza considerare se ci sono delle modifiche di risorse di cui non è stato eseguito ilcommit.

v Un file sotto il controllo del commit viene chiuso ed esistono dei record di cui non è stato eseguito ilcommit. Questa situazione consente a un altro programma di essere richiamato per eseguirel'operazione di commit o di rollback. Questo si verifica indipendentemente dal fatto che il file sia


condiviso o meno. Questa funzione consente a un programma secondario di apportare delle modificheal database che fanno parte di una transazione che interessa più programmi.

v Un lavoro termina, in modo normale o anomalo, con delle modifiche di cui non è stato eseguito ilcommit per una o più definizioni di commit. Viene eseguito il rollback delle modifiche per tutte ledefinizioni di commit.

v Un gruppo di attivazione termina con delle modifiche in sospeso per la definizione di commit a livellodi gruppo di attivazione. Se il gruppo di attivazione sta terminando in modo normale e non sono statirilevati degli errori alla chiusura dei file aperti sotto il controllo del commit incluso nell'ambito dellostesso gruppo di attivazione che sta terminando, il sistema esegue un commit implicito. Altrimenti,viene eseguito un rollback implicito.

v Un programma accede nuovamente a un record modificato di cui non è stato eseguito il commit.Questo consente a un programma di:– Aggiungere un record e aggiornarlo prima di specificare l'operazione di commit.– Aggiornare lo stesso record due volte prima di specificare l'operazione di commit.– Aggiungere un record e cancellarlo prima di specificare l'operazione di commit.– Accedere nuovamente a un record di cui non è stato eseguito il commit da un file logico differente

(sotto il controllo del commit).v Si specifica LCKLVL(*CHG o *CS) nel comando STRCMTCTL e si apre un file con un'operazione di

commit per la sola lettura. In questo caso, non si verifica alcun blocco sulla richiesta. Ne viene eseguital'elaborazione come se il controllo del commit non fosse effettivo ma il file non compare nell'opzione dimenu WRKJOB di file sotto il controllo del commit.

v Si emette il comando STRCMTCTL e non si apre alcun file sotto il controllo del commit. In questasituazione, qualsiasi modifica a livello di record apportata ai file non viene eseguita sotto il controllodel commit.

Messaggi di errore da monitorare durante il controllo del commitDiversi messaggi di errore differenti possono essere restituiti dalle operazioni di commit o rollback oinviati alla registrazione lavoro, a seconda del tipo di messaggio e di quando si è verificato l'errore.

I messaggi di errore possono essere generati durante la seguente elaborazione:v Elaborazione di commit o rollback normalev Elaborazione di commit o rollback durante la fine dell'elaborazione del lavorov Elaborazione di commit o rollback durante la fine del gruppo di attivazione

Non è possibile eseguire il monitoraggio per i seguenti messaggi di errore durante la fine del gruppo diattivazione o la fine dell'elaborazione del lavoro. Inoltre, è possibile eseguire il monitoraggio solo per imessaggi CPFxxxx. I messaggi CPDxxxx sono sempre inviati come messaggi diagnostici di cui non èpossibile eseguire il monitoraggio. Eventuali errori rilevati quando si termina una definizione di commit alivello di gruppo di attivazione durante la terminazione del gruppo di attivazione o la fine di eventualidefinizioni di commit durante la terminazione del lavoro sono lasciati nella registrazione lavoro comemessaggi di diagnostica.

I messaggi di errore correlati al controllo del commit da cercare sono i seguenti:

CPD8351Le modifiche potrebbero non essere state sottoposte a commit.

CPD8352Modifiche non sottoposte a commit all'ubicazione remota &3.

CPD8353Le modifiche al database relazionale &1 potrebbero non essere state sottoposte a commit.

CPD8354Le modifiche al file DDM & 1 potrebbero non essere state sottoposte a commit.


CPD8355Le modifiche all'oggetto DDL di tipo &1 potrebbero non essere state sottoposte a commit.

CPD8356Le modifiche di cui è stato effettuato il rollback potrebbero essere state sottoposte a commit.

CPD8358È probabile che non sia stato eseguito il rollback delle modifiche ad un database relazionale &1.

CPD8359È probabile che non sia stato eseguito il rollback delle modifiche al file DDM &1.

CPD835AÈ probabile che non sia stato eseguito il rollback delle modifiche ad un oggetto DDL &3.

CPD835COggetto di notifica &1 in &2 non aggiornato.

CPD835DLa risorsa DRDA non consente il congelamento del cursore SQL.

CPF835FL'operazione di commit o di rollback ha avuto esito negativo.

CPD8360I membri, i file o entrambi sono già stati disallocati.

CPD8361Errore del programma di uscita API &1 durante il commit.

CPD8362Il programma di uscita API &1 ha riportato un errore durante l'elaborazione di rollback.

CPD8363Il programma di uscita API &1 è terminato dopo &4 minuti durante il commit.

CPD8364Il programma di uscita API &1 è terminato dopo &4 minuti durante il rollback.

CPD836FErrore del protocollo durante l'operazione di controllo del commit.

CPD83D1La risorsa API &4 non può essere l'ultimo agent.

CPD83D2Risorsa incompatibile con il controllo del commit.

CPD83D7L'operazione di commit è stata modificata in quella di rollback.

CPD83D9Si è verificata una condizione euristica mista.

CPF83DBL'operazione di commit ha causato il rollback.

CPD83DC'Azione in caso di problemi' è stata utilizzata per stabilire un'operazione di commit o rollback;causa &2.

CPD83DDLa conversazione è terminata; causa &1.

CPD83DELe informazioni di ritorno non sono valide.


CPD83ECIl programma di uscita API &1 ha stabilito il rollback.

CPD83EFÈ stato avviato il rollback dell'unità logica di lavoro successiva.

CPF8350Definizione di commit non trovata.

CPF8355ENDCMTCTL non è consentito. Sono presenti delle modifiche in sospeso.

CPF8356Il controllo del commit è terminato con &1 modifiche non sottoposte a commit.

CPF8358Oggetto di notifica &1 in &2 non aggiornato.

CPF8359L'operazione di rollback ha avuto esito negativo.

CPF835ALa chiusura della definizione di commit &1 è stata annullata.

CPF835BSi sono verificati degli errori durante la chiusura del controllo del commit.

CPF835CIl controllo del commit è terminato con le modifiche remote non sottoposte a commit.

CPF8363L'operazione di commit non è riuscita.

CPF8364Il valore del parametro relativo al controllo del commit non è valido. Il codice errore è &3.

CPF8367Non è possibile eseguire l'operazione di controllo del commit.

CPF8369Non è possibile porre la risorsa di commit API sotto controllo del commit; codice di errore &1.

CPF83D0L'operazione di commit non è consentita.

CPF83D2Commit completato == La risincronizzazione in corso è stata restituita.

CPF83D3Commit completato == È stato restituita l'operazione Euristica mista.

CPF83D4La voce di giornale dell'unità logica di lavoro non è stata inviata.

CPF83E1L'operazione di commit ha avuto esito negativo a causa di una violazione di restrizione.

CPF83E2Si richiede l'operazione di rollback.

CPF83E3Il livello di nidificazione richiesto non è attivo.

CPF83E4Il controllo del commit è terminato con delle risorse non sottoposte a commit.


CPF83E6Operazione controllo del commit completata con risincronizzazione in corso.

CPF83E7Convalida o ripristino non consentito per la transazione globale X/Open non consentiti.

Monitoraggio del verificarsi di errori dopo un comando CALLQuando viene richiamato un programma che utilizza il controllo del commit, monitorare se si verificanodegli errori imprevisti ed eseguire un'operazione di rollback, se si verifica un errore.

Ad esempio, dei record di cui non è stato eseguito il commit possono esistere quando un programmarileva un errore imprevisto come ad esempio un errore di divisione per zero RPG.

In base allo stato del parametro di Risposta al messaggio di interrogazione (INQMSGRPY) per un lavoro,il programma invia un messaggio di interrogazione o esegue un'azione predefinita. Se la rispostadell'operazione oppure l'azione predefinita terminano il programma, i record di cui non è stato eseguito ilcommit continuano a esistere, in attesa di un'operazione di commit o di rollback.

Se viene richiamato un altro programma che determina un'operazione di commit, viene eseguito ilcommit della transazione completata parzialmente dal programma precedente.

Per evitare che venga eseguito il commit di transazioni completate parzialmente, monitorare lagenerazione di eventuali messaggi di escape dopo il comando CALL. Ad esempio, se si tratta di unprogramma RPG, utilizzare la seguente codifica:CALL RPGAMONMSG MSGID(RPG9001)EXEC(ROLLBACK) /*Rollback if pgm is canceled*/

Se si tratta di un programma COBOL:CALL COBOLAMONMSG MSGID(CBE9001)EXEC(ROLLBACK) /*Rollback if pgm is canceled*/

Errore di elaborazione di commit o rollback normaleDurante l'elaborazione di commit o rollback, possono verificarsi degli errori in qualsiasi momento.

La seguente tabella divide questa elaborazione in quattro situazioni. La colonna di mezzo descrive leazioni eseguite dal sistema quando rileva degli errori durante ciascuna situazione. La terza colonnasuggerisce cosa l'utente o l'applicazione devono fare in risposta ai messaggi. Questi consigli sonocongruenti con il modo in cui l'elaborazione di controllo del commit è gestita dal sistema.

Situazione Elaborazione di commit o rollback Azione suggerita

Il commit di I/E a livello di recordha esito negativo

v Se l'errore si verifica durante lafase di preparazione, la transazioneviene sottoposta a rollback e vieneinviato il messaggio CPF83DB.

v Se l'errore si verifica durante lafase di commit, l'elaborazione dicommit continua ad eseguire ilcommit del massimo numero dirisorse rimanenti possibile. Ilmessaggio CPF8363 viene inviatoalla fine dell'elaborazione dicommit.

Monitoraggio della generazione dimessaggi; gestire come desiderato


Situazione Elaborazione di commit o rollback Azione suggerita

Malfunzionamento durante il commitdel programma di uscita di commit edi rollback o a livello di oggetto perla risorsa di commit API

v Se l'errore si verifica durante lafase di preparazione, la transazioneviene sottoposta a rollback e vieneinviato il messaggio CPF83DB.

v Se l'errore si verifica durante lafase di commit, l'elaborazionecontinua ad eseguire il commit o ilrollback del massimo numero dirisorse rimanenti possibile. Aseconda del tipo di risorsa dicommit, viene restituito uno deiseguenti messaggi:

– CPD8353

– CPD8354

– CPD8355

– CPD8361

Il messaggio CPF8363 viene inviatoalla fine dell'elaborazione dicommit.


Il rollback di I/E a livello di recordha esito negativo

1. Restituisce CPD8356

2. Provare a continuarel'elaborazione per eseguire ilrollback di risorse di commit APIo a livello di oggetto

3. Restituisce CPF8359 alla finedell'elaborazione


Malfunzionamento durante il rollbackdel programma di uscita di commit edi rollback o a livello di oggetto perle risorse di commit API

1. A seconda del tipo di risorsa dicommit, restituisce uno deiseguenti messaggi:

v CPD8358

v CPD8359

v CPD835A

v CPD8362

2. Continua l'elaborazione

3. Restituisce CPF8359 alla finedell'elaborazione


Elaborazione di commit o rollback durante la terminazione del lavoro

Tutte le situazioni descritte nella tabella precedente sono valide anche durante la terminazione di unlavoro, tranne per il fatto che viene inviato uno dei seguenti messaggi:v CPF8356 se sono registrate solo le risorse localiv CPF835C se sono registrate solo le risorse remotev CPF83E4 se sono registrate sia le risorse locali sia quelle remote

Inoltre, potrebbe essere visualizzato uno dei due messaggi specifici per il completamento del lavoro se èstato richiamato un programma di uscita di commit e rollback per una risorsa di cui è possibile eseguireil commit API. Se il programma di uscita di commit e rollback non viene completato entro 5 minuti vieneannullato; viene inviato un messaggio di diagnostica CPD8363 (per il commit) o CPD8364 (per il rollback)e il resto dell'elaborazione di commit o di rollback continua.


Elaborazione di commit o di rollback durante l'IPL (initial program load)

Tutte le situazioni descritte nella tabella precedente si applicano anche durante il ripristino IPL per ledefinizioni di commit, tranne per il fatto che viene inviato il messaggio CPF835F invece del messaggioCPF8359 o CPF8363. I messaggi inviati per una specifica definizione di commit possono essere presentinella registrazione lavoro per uno dei lavori QDBSRVxx o nella registrazione QHST. Nella registrazioneQHST, il messaggio CPI8356 indica l'inizio del ripristino IPL per una specifica definizione di commit. Ilmessaggio CPC8351 indica la fine del ripristino IPL per una specifica definizione di commit e qualsiasialtro messaggio relativo al ripristino di tale definizione di commit si trova tra questi due messaggi.

Potrebbe essere visualizzato uno dei due messaggi specifici per una definizione di commit, se è statorichiamato un programma di uscita di commit e rollback per una risorsa di cui è possibile eseguire ilcommit API. Se il programma di uscita di commit e rollback non viene completato entro 5 minuti vieneannullato; viene inviato un messaggio di diagnostica CPD8363 (per il commit) o CPD8364 (per il rollback)e il resto dell'elaborazione di commit o di rollback continua.

Rilevazione di condizioni di stalloUna condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, esta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altrolavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere unblocco sull'oggetto A.

Attenersi alla seguente procedura per determinare se si è verificata una condizione di stallo e, in casoaffermativo, correggerla:1. Individuare il lavoro sospeso nell'elenco di lavori attivi.2. Consultare gli oggetti che il lavoro sta attendendo di bloccare.3. Per tutti gli oggetti che il lavoro sta attendendo di bloccare, consultare l'elenco di detentori di blocchi

(transazioni o lavori) e provare a trovare un blocco in conflitto che corrisponde al livello richiesto dallavoro sospeso.

4. Se una transazione sta detenendo un blocco in conflitto, visualizzare i lavori associati a questatransazione e verificare se uno di essi sta attendendo di bloccare.

5. Determinare se il lavoro in attesa sta provando a bloccare uno degli oggetti bloccati dal lavorosospeso iniziale. Quando si trova il lavoro che sta provando a bloccare uno degli oggetti bloccati dallavoro sospeso iniziale, è possibile identificare gli oggetti in questione come possibili cause diproblemi.

6. Esaminare la transazione per determinare l'appropriato corso di azione.a. Consultare le proprietà della transazione per appurare quale applicazione l'ha iniziata e consultare

quindi il codice applicazione.b. In alternativa, tracciare le azioni della transazione fino a questo punto trovando l'ID di ciclo di

commit nelle proprietà della transazione e cercando quindi in un giornale le voci che contengonoquesto ID. Per eseguire questa operazione, è possibile utilizzare il comando RTVJRNE (Richiamovoce di giornale) e specificare il parametro CMTCYCID.

c. Dopo aver ottenuto informazioni pertinenti, è possibile scegliere di forzare un'operazione dirollback o di commit.


Attività correlate

“Riduzione al minimo dei blocchi” a pagina 74Un modo tipico per ridurre al minimo i blocchi di record consiste nel rilasciare il blocco di record.(Questa tecnica non funziona se è stato specificato LCKLVL(*ALL)).Determining the status of a job“Visualizzazione di oggetti bloccati per una transazione” a pagina 70È possibile visualizzare degli oggetti bloccati per le transazioni globali solo con i blocchi nell'ambito dellatransazione.“Visualizzazione di lavori associati a una transazione” a pagina 70Per visualizzare i lavori associati a una transazione, attenersi alla seguente procedura.“Visualizzazione delle informazioni sul controllo del commit” a pagina 69System i Navigator può visualizzare informazioni su tutte le transazioni (unità di lavoro logiche) sulsistema. System i Navigator può anche visualizzare eventuali informazioni sul lavoro associate a unatransazione.“Quando forzare le opzioni di commit e di rollback e quando annullare la risincronizzazione” a pagina117La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azioneabilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione cheè in uno stato Preparato.“Ricerca di transazioni di grandi dimensioni oppure obsolete” a pagina 119Utilizzare il comando WRKCMTDFN (Gestione definizioni di commit) per trovare transazioni di grandidimensioni oppure obsolete.Riferimenti correlati

Retrieve Journal Entry (RTVJRNE) command

Ripristino delle transazioni dopo un errore nelle comunicazioniQueste istruzioni aiutano a gestire le transazioni che eseguono delle attività su un sistema remoto dopoche si è verificato un errore nelle comunicazioni con tale sistema.

Nel caso di un errore nelle comunicazioni, il sistema di norma completa la risincronizzazione con isistemi remoti automaticamente. Tuttavia, se l'errore è talmente grave che le comunicazioni con il sistemaremoto non verranno mai ristabilite (ad esempio se la linea di comunicazione viene interrotta), ènecessario annullare la risincronizzazione e ripristinare le transazioni personalmente. Le transazionipotrebbero anche detenere dei blocchi che devono essere rilasciati.1. In System i Navigator, visualizzare le informazioni sul controllo del commit per la transazione con cui

si sta lavorando.2. Trovare la transazione cui si è interessati che sta provando ad eseguire la risincronizzazione con il

sistema remoto. Il campo Risincronizzazione in corso per tale transazione è impostato su sì.3. Cercare le transazioni che avevano una connessione al sistema remoto controllando lo stato della

risorsa per le singole transazioni.4. Dopo aver identificato le transazioni, è necessario forzare il commit o il rollback, a seconda dello stato

della transazione.5. È possibile decidere per l'esecuzione del commit o del rollback dopo aver esaminato le proprietà della

transazione.v È possibile utilizzare l'ID unità di lavoro per trovare altre parti della transazione su altri sistemi.v È anche possibile determinare l'esecuzione del commit o del rollback dallo stato della transazione.

Ad esempio, se una transazione del database sta eseguendo un commit in due fasi durante unerrore nelle comunicazioni e il suo stato dopo l'errore è "preparato" o "ultimo agent in sospeso", èpossibile scegliere di forzare il commit sulla transazione.

6. Dopo la forzatura di un commit o un rollback sulle transazioni in dubbio, arrestare larisincronizzazione sulla connessione in errore per le transazioni identificate.


Attività correlate

“Visualizzazione delle informazioni sul controllo del commit” a pagina 69System i Navigator può visualizzare informazioni su tutte le transazioni (unità di lavoro logiche) sulsistema. System i Navigator può anche visualizzare eventuali informazioni sul lavoro associate a unatransazione.“Quando forzare le opzioni di commit e di rollback e quando annullare la risincronizzazione”La decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azioneabilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione cheè in uno stato Preparato.

Quando forzare le opzioni di commit e di rollback e quando annullarela risincronizzazioneLa decisione di forzare un'operazione di commit o di rollback viene detta decisione euristica. Questa azioneabilita un operatore ad eseguire il commit o il rollback manualmente delle risorse per una transazione cheè in uno stato Preparato.

Quando si prende una decisione euristica, lo stato della transazione diviene euristicamente mista se lapropria decisione non è congruente con i risultati delle altre ubicazioni nella transazione. È necessarioassumersi l'onere di determinare l'azione eseguita da tutte le altre ubicazioni che hanno partecipato allatransazione e di risincronizzare i record di database.

Prima di prendere una decisione euristica, raccogliere tutte le informazioni possibili sulla transazione.Visualizzare i lavori associati alla definizione di commit e creare un record che indica i giornali e i fileinteressati. È possibile utilizzare queste informazioni successivamente se si devono visualizzare le voci digiornale e applicare o eliminare modifiche registrate su giornale manualmente.

Un punto ottimale di reperimento di informazioni su una transazione è l'ubicazione che ha iniziato taletransazione. Tuttavia, la decisione di eseguire il commit o il rollback potrebbe appartenere a una risorsaAPI o a un ultimo agent.

Se una risorsa API è stata registrata come una risorsa ultimo agent, la decisione finale di eseguire ilcommit o il rollback appartiene alla risorsa API. È necessario verificare le informazioni sull'applicazione esu come utilizza la risorsa API per determinare se eseguire il commit o il rollback.

Se per la transazione è selezionato un ultimo agent, la decisione di eseguire il commit o il rollbackappartiene all'ultimo agent. Consultare lo stato dell'ultimo agent per informazioni sulla transazione.

Quando è necessario prendere delle decisioni euristiche o annullare la risincronizzazione a causa di unerrore di sistema o nelle comunicazioni che non è possibile riparare, è possibile trovare tutte letransazioni in dubbio attenendosi alla seguente procedura:1. In System i Navigator, espandere il sistema che si desidera gestire.2. Espandere Database e il database locale per il sistema.3. Espandere Transazioni.4. Espandere Transazioni database o Transazioni globali.

In queste finestre di visualizzazione, è possibile vedere la definizione di commit, lo stato dirisincronizzazione, l'ID di unità di lavoro corrente e lo stato dell'unità di lavoro corrente per ciascunatransazione. Cercare le transazioni con le seguenti informazioni:v Transazioni con uno Stato unità logica di lavoro di Preparato o Ultimo agent in sospeso.v Transazioni che mostrano uno stato di Risincronizzazione in corso impostato su sì.


Per gestire il lavoro che sta partecipando nella transazione di questo sistema, fare clic con il tasto destrodel mouse sulla transazione e selezionare lavoro.

Quando si fa clic con il tasto destro del mouse sulla transazione, è anche possibile selezionare Forzacommit, Forza rollback o Annulla risincronizzazione.

Prima di prendere una decisione euristica o di annullare la risincronizzazione, è opportuno controllare lostato dei lavori sugli altri sistemi associati alla transazione. Controllare i lavori sui sistemi remoti puòaiutare ad evitare decisioni che causano incongruenze del database tra i sistemi.1. Fare clic con il tasto destro del mouse sulla transazione che si desidera gestire.2. Selezionare Stato risorsa.3. Nella finestra di dialogo Stato risorsa, selezionare la scheda Conversazione per le connessioni SNA;

selezionare Connessione per le connessioni TCP/IP.

Ciascuna risorsa di conversazione rappresenta un sistema remoto che sta partecipando alla transazione.Sui sistemi remoti, è possibile utilizzare System i Navigator per visualizzare le transazioni associate allatransazione.

La parte di base dell'ID dell'unità di lavoro è uguale su tutti i sistemi. Quando si visualizzano leinformazioni sul controllo del commit sul sistema remoto, cercare la parte di base dell'ID dell'unità dilavoro che è uguale sul sistema locale.

Ad esempio, se l'ID dell'unità di lavoro sul sistema locale inizia con: APPN.RCHASL97.X'112233445566,cercare l'ID dell'unità di lavoro sul sistema remoto che inizia anch'esso conAPPN.RCHASL97.X'112233445566.Concetti correlati

“Supporto delle transazioni XA per il controllo del commit” a pagina 46DB2 for i può partecipare nelle transazioni globali X/Open.“Avvio del controllo del commit” a pagina 52Per avviare il controllo del commit, utilizzare il comando STRCMTCTL (Avvio controllo commit).Attività correlate

“Rilevazione di condizioni di stallo” a pagina 115Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, esta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altrolavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere unblocco sull'oggetto A.“Ripristino delle transazioni dopo un errore nelle comunicazioni” a pagina 116Queste istruzioni aiutano a gestire le transazioni che eseguono delle attività su un sistema remoto dopoche si è verificato un errore nelle comunicazioni con tale sistema.“Visualizzazione delle informazioni sul controllo del commit” a pagina 69System i Navigator può visualizzare informazioni su tutte le transazioni (unità di lavoro logiche) sulsistema. System i Navigator può anche visualizzare eventuali informazioni sul lavoro associate a unatransazione.

Fine di un rollback a lunga esecuzioneÈ possibile terminare i rollback a lunga esecuzione che consumano tempo del processore critico, bloccanorisorse o utilizzano spazio di memorizzazione.

Un'operazione di rollback elimina tutte le modifiche apportate in una transazione dopo la precedenteoperazione di commit o di rollback. Durante un'operazione di rollback, il sistema rilascia anche i blocchicorrelati alla transazione. Se contiene migliaia di transazioni, il sistema impiega ore per completareun'operazione di rollback. Questi rollback a lunga esecuzione possono consumare tempo del processorecritico, bloccare risorse o utilizzare spazio di memorizzazione.


Prima di terminare un rollback a lunga esecuzione, è necessario sapere quali sono le definizioni dicommit di cui si sta eseguendo il rollback e qual è il loro stato. Il campo relativo allo stato per ledefinizioni di commit di cui è in corso il rollback è impostato su ROLLBACK IN CORSO.

Utilizzare il comando WRKCMTDFN (Gestione definizioni di commit) per controllare lo stato di unrollback attenendosi alla seguente procedura:1. Immettere WRKCMTDFN JOB(*ALL) dall'interfaccia basata sui caratteri.2. Immettere F11 per visualizzare il campo Stato.

Se si termina un rollback a lunga esecuzione, i file che erano stati modificati durante la transazioneverranno lasciati con delle transazioni parziali. Non si deve terminare un rollback se i file non possonoavere delle transazioni parziali. Per appurare quali sono i file che erano stati modificati durante latransazione, scegliere l'opzione 5 per visualizzare lo stato dall'elenco WRKCMTDFN. Premere F6 pervisualizzare lo stato della risorsa e selezionare Livello record.

È necessario disporre dell'autorizzazione speciale a tutti gli oggetti (*ALLOBJ) per terminare un rollback alunga esecuzione. Per terminare un rollback a lunga esecuzione, attenersi alla seguente procedura:1. Immettere WRKCMTDFN JOB(*ALL) dall'interfaccia basata sui caratteri.2. Immettere l'opzione 20 (Fine rollback) sulla definizione di commit che si desidera terminare.

I file con delle transazioni parziali hanno il campo Presenza transazione parziale, rollback terminatoimpostato su *YES nell'emissione dal comando DSPFD (Visualizzazione descrizione file). È necessariorimuovere le transazioni parziali prima che il file possa essere utilizzato. È possibile rimuovere letransazioni parziali eliminando il file e ripristinandolo da un salvataggio precedente. Se non si dispone diun salvataggio precedente, è possibile utilizzare il comando CHGJRNOBJ (Modifica oggetto registrato sugiornale) per reimpostare lo stato Presenza transazione parziale in modo da poter aprire il file. L'utilizzodi CHGJRNOBJ richiede che si modifichi il file per portarlo a uno stato congruente. È necessarioutilizzare il comando CHGJRNOBJ solo se non è disponibile un salvataggio precedente.

Disabilitazione della capacità di terminare un rollback a lunga esecuzione

Gli utenti con l'autorizzazione speciale *ALLOBJ possono terminare i rollback per impostazionepredefinita. Se si desidera impedire agli utenti che hanno l'autorizzazione speciale *ALLOBJ di terminarei rollback, è possibile farlo creando l'area dati QGPL/QTNNOENDRB.Riferimenti correlati

Create Data Area (CRTDTAARA) command

Ricerca di transazioni di grandi dimensioni oppure obsoleteUtilizzare il comando WRKCMTDFN (Gestione definizioni di commit) per trovare transazioni di grandidimensioni oppure obsolete.

Per trovare delle transazioni di grandi dimensioni oppure obsolete, attenersi alla seguente procedura:1. Immettere WRKCMTDFN JOB(*ALL) OUTPUT(*PRINT) dall'interfaccia basata sui caratteri.2. Utilizzare il comando WRKSPLF per gestire i file di spool.3. Utilizzare l'opzione 5=Visualizz. per visualizzare il file di spool creato dal comando WRKCMTDFN al

passo 1.4. Per trovare delle transazioni di grandi dimensioni, cercare i campi 'Blocchi record' e 'Modifiche in

sospeso' visualizzati nella sezione Visualizzazione dello stato del giornale per ciascuna definizione dicommit. Questi campi mostrano il numero totale di blocchi di record e di modifiche in sospesoattualmente per la transazione.

5. Per trovare delle transazioni obsolete, cercare il campo 'Registrazione data/ora' nella sezione Statocontrollo del commit per ciascuna definizione di commit. Questo campo mostra quando è stataavviata la transazione.


|

||

|

|

|

||

||||

|||

Queste informazioni sono visualizzate anche quando si utilizza System i® Navigator o IBM SystemsDirector Navigator per i per visualizzare le transazioni, ma è più facile trovare le transazioni di grandidimensioni oppure obsolete cercando nel singolo file di spool prodotto dal comando WRKCMTDFNinvece di visualizzare le proprietà e lo stato risorsa per ciascuna transazione.Attività correlate

“Rilevazione di condizioni di stallo” a pagina 115Una condizione di stallo può verificarsi quando un lavoro detiene un blocco su un oggetto, l'oggetto A, esta attendendo di ottenere un blocco su un altro oggetto, l'oggetto B. Contemporaneamente, un altrolavoro o un'altra transazione attualmente detiene un blocco sull'oggetto B e sta attendendo di ottenere unblocco sull'oggetto A.“Visualizzazione delle informazioni sul controllo del commit” a pagina 69System i Navigator può visualizzare informazioni su tutte le transazioni (unità di lavoro logiche) sulsistema. System i Navigator può anche visualizzare eventuali informazioni sul lavoro associate a unatransazione.

Informazioni correlate per il controllo del commitI manuali dei prodotti, le pubblicazioni IBM Redbooks, i siti Web e altre raccolte di argomentidell'information center contengono informazioni correlate alla raccolta di argomenti Controllo del commit.È possibile visualizzare o stampare qualsiasi file PDF.

Manuali

I seguenti manuali non sono inclusi nell'Information Center i5/OS V6R1. Tuttavia, questi manualipotrebbero contenere utili informazioni di riferimento. Ciascuno dei manuali è disponibile dal sito IBM

Publications Center (www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss?) come copia cartaceastampata che è possibile ordinare, nel formato in linea che è possibile scaricare gratuitamente o inentrambi i formati.v COBOL/400 User's Guidev RPG/400 User's Guide

IBM Redbooks

v Advanced Functions and Administration on DB2 for i (5529 KB)

v Stored Procedures, Triggers, and User Defined Functions on DB2 for i (5836 KB)

v Striving for Optimal Journal Performance on DB2 for i (3174 KB)

Siti Web

v The Open Group (www.opengroup.org)

Ulteriori informazioniv Database programmingv SQL programmingv XA APIsv Journal management


||||

|

|||||

||||

http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss?

http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss?

http://www.redbooks.ibm.com/abstracts/sg244249.html



http://www.opengroup.org


“File PDF per il controllo del commit” a pagina 1È possibile visualizzare e stampare un file PDF che contiene le presenti informazioni.

Informazioni sull'esonero di responsabilità e licenza del codiceIBM fornisce una licenza non esclusiva per utilizzare tutti gli esempi del codice di programmazione dacui creare funzioni simili personalizzate, in base a richieste specifiche.

OLTRE ALLE GARANZIE STABILITE DALLA LEGGE CHE NON POSSONO ESSERE ESCLUSE, IBM,GLI SVILUPPATORI DEL PROGRAMMA E I FORNITORI NON OFFRONO GARANZIE O CONDIZIONIESPRESSE O IMPLICITE, INCLUSO, MA NON SOLO, LE GARANZIE O CONDIZIONI IMPLICITE DICOMMERCIABILITA', ADATTABILITA' A UNO SCOPO PARTICOLARE E NON CONTRAFFAZIONERELATIVAMENTE AL PROGRAMMA E AL SUPPORTO TECNICO, SE PRESENTE.

IN NESSUN CASO IBM, GLI SVILUPPATORI DEL PROGRAMMA O I FORNITORI SARANNORESPONSABILI PER QUANTO SEGUE, ANCHE SE INFORMATI DEL POSSIBILE VERIFICARSI DITALI DANNI:1. PERDITA O DANNEGGIAMENTO DI DATI;2. DANNI PARTICOLARI, INCIDENTALI, DIRETTI O INDIRETTI O QUALSIASI DANNO

ECONOMICO CONSEGUENTE; OPPURE3. PERDITE DI PROFITTI, AFFARI, ENTRATE O SPESE ANTICIPATE.

LA LEGISLAZIONE DI ALCUNI PAESI NON CONSENTE L'ESCLUSIONE O LA LIMITAZIONE DELLEGARANZIE DI DANNI DIRETTI, INCIDENTALI O CONSEQUENZIALI, PERTANTO ALCUNE OTUTTE LE SUDDETTE ESCLUSIONI O LIMITAZIONI POTREBBERO NON ESSERE APPLICABILI.


Appendice. Informazioni particolari

Queste informazioni sono state sviluppate per prodotti e servizi offerti negli Stati Uniti.

IBM può non offrire i prodotti, i servizi o le funzioni presentati in questo documento in altri paesi.Contattare il rappresentante IBM locale per informazioni sui prodotti e servizi correntemente disponibilinella propria area. Qualsiasi riferimento ad un prodotto, programma o servizio IBM non implica ointende dichiarare che solo quel prodotto, programma o servizio IBM può essere utilizzato. Qualsiasiprodotto funzionalmente equivalente al prodotto, programma o servizio che non violi alcun diritto diproprietà intellettuale IBM può essere utilizzato. Tuttavia la valutazione e la verifica dell'uso di prodotti oservizi non IBM ricadono esclusivamente sotto la responsabilità dell'utente.

IBM può avere brevetti o domande di brevetto in corso relativi a quanto trattato nel presente documento.La fornitura di questa pubblicazione non garantisce la concessione di alcuna licenza su tali brevetti. Chidesiderasse ricevere informazioni relative alla licenza può rivolgersi per iscritto a:

IBM Director of Commercial RelationsIBM EuropeSchoenaicher Str. 220D-7030 BoeblingenDeutschland

Per informazioni sulle richieste di licenze relative al doppio byte (DBCS), contattare il reparto proprietàintellettuale IBM nel proprio paese o inviare le richieste per iscritto all'indirizzo:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan, Ltd.3-2-12, Roppongi, Minato-ku, Tokyo 106-8711, Japan

Le disposizioni contenute nel seguente paragrafo non si applicano al Regno Unito o ad altri paesi neiquali tali disposizioni non siano congruenti con le leggi locali: IBM FORNISCE QUESTAPUBBLICAZIONE “COSÌ COM'È” SENZA ALCUNA GARANZIA, ESPLICITA O IMPLICITA, IVIINCLUSE EVENTUALI GARANZIE DI COMMERCIABILITÀ ED IDONEITÀ AD UNO SCOPOPARTICOLARE. Alcuni stati non consentono la rinuncia ad alcune garanzie espresse o implicite indeterminate transazioni, pertanto, la presente dichiarazione può non essere applicabile.

Queste informazioni potrebbero contenere imprecisioni tecniche o errori tipografici. Si effettuanoperiodicamente modifiche alle informazioni qui accluse; queste modifiche saranno inserite in nuoveedizioni della pubblicazione. IBM si riserva di apportare senza preavviso e in qualsiasi momentomiglioramenti e/o modifiche al/i prodotto/i e/o al/i programma/i descritto/i in questa pubblicazione.

Qualsiasi riferimento a siti web non IBM, contenuto in queste informazioni, viene fornito solo percomodità e non implica in alcun modo l'approvazione di tali siti. Le informazioni reperibili nei siti Webnon sono parte integrante delle informazioni relative a questo prodotto IBM, pertanto il loro utilizzoricade sotto la responsabilità dell'utente.

IBM può utilizzare o distribuire le informazioni fornite in qualsiasi modo ritenga appropriato senzaobblighi verso l'utente.

I licenziatari di questo programma che desiderano avere informazioni allo scopo di abilitare: (i) loscambio di informazioni tra i programmi creati indipendentemente e gli altri programmi (incluso ilpresente) e (ii) il reciproco utilizzo di informazioni che sono state scambiate, dovrebbero contattare:

IBM Corporation

© Copyright IBM Corp. 2003, 2010 123

Software Interoperability Coordinator, Department YBWA3605 Highway 52 NRochester, MN 55901U.S.A.

Tali informazioni possono essere disponibili, in base ad appropriate clausole e condizioni, includendo inalcuni casi, il pagamento di una tassa.

Il programma su licenza descritto in questa pubblicazione e tutto il relativo materiale disponibile vienefornito da IBM nei termini dell'accordo IBM Customer Agreement, IBM International Program LicenseAgreement, IBM License Agreement for Machine Code o qualsiasi altro accordo equivalente tra le parti.

Qualsiasi dato sulle prestazioni contenuto in questa pubblicazione è stato stabilito in un ambientecontrollato. Quindi i risultati ottenuti in altri ambienti operativi potrebbero variare in modo significativo.È possibile che alcune misurazioni siano state effettuate su sistemi a livello di sviluppo e non esistealcuna garanzia che tali misurazioni siano le stesse su sistemi generalmente disponibili. Inoltre, èpossibile che alcune misurazioni siano state calcolate tramite estrapolazione. I risultati effettivi possonovariare. Gli utenti di questa pubblicazione devono verificare che i dati siano applicabili al loro specificoambiente.

Le informazioni riguardanti prodotti non IBM sono ottenute dai fornitori di tali prodotti, dai loro annuncipubblicati o da altre fonti pubblicamente reperibili. IBM non ha testato tali prodotti e non può confermarel'adeguatezza delle prestazioni, della compatibilità o di altre richieste relative a prodotti non IBM. Ledomande sulle capacità dei prodotti non IBM dovranno essere indirizzate ai fornitori di tali prodotti.

Tutte le specifiche relative alle direttive o intenti futuri di IBM sono soggette a modifiche o a revochesenza notifica e rappresentano soltanto scopi ed obiettivi.

Queste informazioni contengono esempi di dati e prospetti utilizzati in quotidiane operazioni aziendali.Per illustrarle nel modo più completo possibile, gli esempi includono i nomi di individui, società, marchie prodotti. Tutti questi nomi sono fittizi e qualsiasi somiglianza con nomi ed indirizzi utilizzati da gruppiaziendali realmente esistenti è puramente casuale.

LICENZA DI COPYRIGHT:

Queste informazioni contengono programmi di applicazione di esempio nella lingua di origine, cheillustrano le tecniche di programmazione su varie piattaforme operative. È possibile copiare, modificare edistribuire questi programmi di esempio in qualsiasi formato senza pagare alcun corrispettivo a IBM, alloscopo di sviluppare, utilizzare, commercializzare o distribuire i programmi dell'applicazione conformiall'interfaccia di programmazione dell'applicazione per la piattaforma operativa per cui i programmi diesempio vengono scritti. Questi esempi non sono stati interamente testati in tutte le condizioni. IBM,perciò, non fornisce nessun tipo di garanzia o affidabilità implicita, rispetto alla funzionalità o allefunzioni di questi programmi. I programmi di esempio vengono forniti "COSI' COME SONO", senzagaranzie di alcun tipo. IBM non intende essere responsabile per alcun danno derivante dall'utilizzo deiprogrammi di esempio.

Ogni copia, parte di questi programmi di esempio o lavoro derivato, devono includere un avviso sulcopyright, come ad esempio:

© (nome società) (anno). Le parti di questo codice provengono dai Programmi di esempio di IBM Corp.© Copyright IBM Corp. _immettere l'anno o gli anni_.

Se si sta utilizzando la versione in formato elettronico di questo manuale, le fotografie e le illustrazioni acolori potrebbero non essere visualizzate.


Informazioni sull'interfaccia di programmazioneQuesta pubblicazione di controllo del commit illustra le interfacce di programmazione che consentono alcliente di scrivere programmi per ottenere i servizi di IBM i.

MarchiIBM, il logo IBM e ibm.com sono marchi di International Business Machines Corp., registrati in moltegiurisdizioni del mondo. Altri nomi di prodotti e servizi possono essere marchi di IBM o di altre società.Un elenco attuale di marchi IBM è disponibile su Web nella sezione Copyright and trademarkinformation al sito www.ibm.com/legal/copytrade.shtml.

I seguenti termini sono marchi di IBM Corporation negli Stati Uniti e/o negli altri paesi:

COBOL/400DB2Distributed Relational Database ArchitectureDRDAIBM iIBMIBM (logo)Integrated Language EnvironmentRedbooksRPG/400System i

Adobe, il logo Adobe, PostScript® e il logo PostScript sono marchi di Adobe Systems Incorporated negliStati Uniti e/o in altri paesi.

UNIX è un marchio registrato di The Open Group negli Stati Uniti e in altri paesi.

Nomi di altre società, prodotti o servizi possono essere marchi o marchi di servizio di altre società.

Termini e condizioniLe autorizzazioni per l'utilizzo di queste pubblicazioni vengono concesse in base alle seguentidisposizioni.

Uso personale: È possibile riprodurre queste pubblicazioni per uso personale, non commerciale acondizione che vengano conservate tutte le indicazioni relative alla proprietà. Non è possibile distribuire,visualizzare o produrre lavori derivati di tali pubblicazioni o di qualsiasi loro parte senza chiaro consensoda parte di IBM.

Uso commerciale: È possibile riprodurre, distribuire e visualizzare queste pubblicazioni unicamenteall'interno del proprio gruppo aziendale a condizione che vengano conservate tutte le indicazioni relativealla proprietà. Non è possibile effettuare lavori derivati di queste pubblicazioni o riprodurre, distribuire ovisualizzare queste pubblicazioni o qualsiasi loro parte al di fuori del proprio gruppo aziendale senzachiaro consenso da parte di IBM.

Fatto salvo quanto espressamente concesso in questa autorizzazione, non sono concesse altreautorizzazioni, licenze o diritti, espressi o impliciti, relativi alle pubblicazioni o a qualsiasi informazione,dato, software o altra proprietà intellettuale qui contenuta.

IBM si riserva il diritto di ritirare le autorizzazioni qui concesse qualora, a propria discrezione, l'utilizzodi queste pubblicazioni sia a danno dei propri interessi o, come determinato da IBM, qualora non sianorispettate in modo appropriato le suddette istruzioni.

Appendice. Informazioni particolari 125

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/legal/copytrade.shtml

Non è possibile scaricare, esportare o ri-esportare queste informazioni se non pienamente conformi contutte le leggi e le norme applicabili, incluse le leggi e le norme di esportazione degli Stati Uniti.

IBM NON RILASCIA ALCUNA GARANZIA RELATIVAMENTE AL CONTENUTO DI QUESTEPUBBLICAZIONI. LE PUBBLICAZIONI SONO FORNITE "COSI' COME SONO", SENZA ALCUN TIPODI GARANZIA, ESPRESSA O IMPLICITA, INCLUSE, A TITOLO ESEMPLIFICATIVO, GARANZIEIMPLICITE DI COMMERCIABILITA' ED IDONEITA' PER UNO SCOPO PARTICOLARE.


��

Stampato in Italia

Versione 7 Release 1 - IBM - United States · sull'esonero di responsabilità e licenza del...

Documents

Transcript of Versione 7 Release 1 - IBM - United States · sull'esonero di responsabilità e licenza del...