Data recovery: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (Admin moved page Data Recovery to Data recovery without leaving a redirect: title caps)
m (more conversion cleanup)
Line 1: Line 1:
===Overview===
==Overview==
<p>If hardware or software failures occur during the process of updating <var class="product">Model&nbsp;204</var> files, database integrity problems can arise. These problems result from the fact that updates to a file can require coordinated changes, and a failure can interrupt the process of writing to storage a complete set of these changes. </p>
<p>
<p>Normally in a <var class="product">Model&nbsp;204</var> installation, the system manager is responsible for the coordination of recovery activity for the installation, and the file manager determines which recovery features are applied to each of the files.  </p>
If hardware or software failures occur during the process of updating <var class="product">Model&nbsp;204</var> files, database integrity problems can arise. These problems result from the fact that updates to a file can require coordinated changes, and a failure can interrupt the process of writing to storage a complete set of these changes. </p>
<p>For a complete description of the <var class="product">Model&nbsp;204</var> recovery process, refer to the Rocket <var class="product">Model&nbsp;204</var> File Manager's Guide.</p>
<p>
====Transaction back out====
Normally in a <var class="product">Model&nbsp;204</var> installation, the system manager is responsible for the coordination of recovery activity for the installation, and the file manager determines which recovery features are applied to each of the files.  </p>
<p>One of the recovery features that can be selected by the file manager is an integrity facility called transaction backout. This facility can reverse the effects of an incomplete transaction (a sequence of file updating operations).  </p>
<p>
====Application considerations====
For a complete description of the <var class="product">Model&nbsp;204</var> recovery process, see [[File integrity and recovery]].</p>
<p>Although the file manager determines whether the transaction backout facility is defined for a file, the application designer must understand the facility's capabilities and requirements in order to ensure file integrity for an application. </p>
<p>This chapter explains those capabilities and requirements and describes how applications can be designed to ensure file integrity. In particular, see the last section in this chapter for application design considerations.</p>
===Transaction back out===
===Transaction backout===
<p>
<p>The transaction backout facility allows <var class="product">Model&nbsp;204</var> to logically reverse the effects of an incomplete update to a file. </p>
One of the recovery features that can be selected by the file manager is an integrity facility called transaction backout. This facility can reverse the effects of an incomplete transaction (a sequence of file updating operations).  </p>
<p>A backout can be initiated only on incomplete update units; completed update units cannot be backed out. A backout can be automatically performed by <var class="product">Model&nbsp;204</var> or initiated by the user.  </p>
====FOPT and FRCVOPT parameters====
===Application considerations===
<p>Transaction backout is an option of the FOPT and FRCVOPT parameters and is enabled or disabled on a file-by-file basis. Refer to the Rocket <var class="product">Model&nbsp;204</var> Parameter and Command Reference Manual for more information on these parameters.</p>
<p>
====Types of backout====
Although the file manager determines whether the transaction backout facility is defined for a file, the application designer must understand the facility's capabilities and requirements in order to ensure file integrity for an application. </p>
<p>You can use the transaction backout facility to specify two types of files:  </p>
<p>
This page explains those capabilities and requirements and describes how applications can be designed to ensure file integrity. In particular, see the last section in this chapter for application design considerations.</p>
==Transaction backout==
<p>
The transaction backout facility allows <var class="product">Model&nbsp;204</var> to logically reverse the effects of an incomplete update to a file. </p>
<p>
A backout can be initiated only on incomplete update units; completed update units cannot be backed out. A backout can be automatically performed by <var class="product">Model&nbsp;204</var> or initiated by the user.  </p>
===FOPT and FRCVOPT parameters===
<p>
Transaction backout is an option of the <var>[[FOPT parameter|FOPT]]</var> and <var>[[FRCVOPT parameter|FRCVOPT]]</var> parameters and is enabled or disabled on a file-by-file basis. </p>
===Types of backout===
<p>
You can use the transaction backout facility to specify two types of files:  </p>
<table>
<table>
<tr class="head">
<tr class="head">
<th>backout  
<th>backout
file types </th>
file types </th>
<th>
<th>
Line 24: Line 39:
Discussion</th>
Discussion</th>
</tr>
</tr>
<tr>
<tr>
<td>Transaction backout </td>
<td>Transaction backout </td>
<td>Enable both lock pending updates and backout. </td>
<td>Enable both lock pending updates and backout. </td>
<td>
<td>
<p>A transaction can be backed out automatically by <var class="product">Model&nbsp;204</var> or manually by the application. </p>
<p>
<p>A transaction backout file ensures:</p>
A transaction can be backed out automatically by <var class="product">Model&nbsp;204</var> or manually by the application. </p>
<p>Logical consistency</p>
<p>
<p>Data and file integrity,</p>
A transaction backout file ensures:</p>
<p>High degree of data sharing.</p>
<p>
Logical consistency</p>
<p>
Data and file integrity,</p>
<p>
High degree of data sharing.</p>
</td>
</td>
</tr>
</tr>
<tr>
<tr>
<td>Non-transaction backout</td>
<td nowrap>Non-transaction backout</td>
<td>Disable transaction backout. </td>
<td>Disable transaction backout. </td>
<td>
<td>
<p>Incomplete updates cannot be automatically reversed.    </p>
<p>
<p>Non-transaction backout files cannot be accessed remotely. Attempts to open a non-transaction backout file in remote context fails and generates the following error message: </p>
Incomplete updates cannot be automatically reversed.    </p>
<p>
Non-transaction backout files cannot be accessed remotely. Attempts to open a non-transaction backout file in remote context fails and generates the following error message: </p>
<p class="code"><var>M204.1973: NON-TBO REMOTE FILE</var>
<p class="code"><var>M204.1973: NON-TBO REMOTE FILE</var>
</p></td>
</p></td>
</tr>
</tr>
</table>
</table>
===Update units===
<p>An update unit is any sequence of operations that updates the database and that has a beginning and ending point. One update unit must end before another update unit can begin.      </p>
==Update units==
<p>A request or procedure can have two types of update units:</p>
<p>
An update unit is any sequence of operations that updates the database and that has a beginning and ending point. One update unit must end before another update unit can begin.      </p>
<p>
A request or procedure can have two types of update units:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 53: Line 80:
<th>Discussion</th>
<th>Discussion</th>
</tr>
</tr>
<tr>
<tr>
<td>Backoutable </td>
<td>Backoutable </td>
<td>A backoutable unit consists of updates to transaction backout files using file updating statements (such as STORE RECORD). The unit can either be completed so that it persists in the file, or backed out so that the update is logically reversed in the file.  </td>
<td>A backoutable unit consists of updates to transaction backout files using file updating statements (such as STORE RECORD). The unit can either be completed so that it persists in the file, or backed out so that the update is logically reversed in the file.  </td>
</tr>
</tr>
<tr>
<tr>
<td>Non-backoutable </td>
<td>Non-backoutable </td>
Line 62: Line 91:
</tr>
</tr>
</table>
</table>
====Backoutable units====
<b>Beginning a backoutable unit</b>
===Backoutable units===
<p>A backoutable unit begins at the execution of the first User Language statement that performs an update operation on a transaction backout file. The statements that perform update operations are:    </p>
====Beginning a backoutable unit====
<p>
A backoutable unit begins at the execution of the first User Language statement that performs an update operation on a transaction backout file. The statements that perform update operations are:    </p>
<ul>
<ul>
<li>ADD fieldname = value</li>
<li>ADD fieldname = value</li>
</li>
<li>CHANGE fieldname TO value                   </li>
<li>CHANGE <i>fieldname</i> TO <i>value</i>   </li>
</li>
<li>DELETE EACH fieldname</li>
<li>DELETE EACH <i>fieldname</i></li>
</li>
<li>DELETE fieldname [= value]</li>
<li>DELETE <i>fieldname</i> [= <i>value</i>]</li>
</li>
<li>DELETE RECORD</li>
<li>DELETE RECORD</li>
</li>
<li>DELETE RECORDS</li>
<li>DELETE RECORDS</li>
</li>
<li>FILE RECORDS</li>
<li>FILE RECORDS</li>
</li>
<li>INSERT fieldname = value</li>
<li>INSERT <i>fieldname</i> = <i>value</i></li>
</li>
<li>STORE RECORD</li>
<li>STORE RECORD  
</li>
</li>
</ul>
</ul>
<b>Ending a backoutable unit</b>
<p>A backoutable unit ends when the unit is committed by using the COMMIT statement or is backed out. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this chapter) also can end an active update unit. Refer to the Rocket <var class="product">Model&nbsp;204</var> File Manager's Guide for a complete list of conditions that end an active update unit.  </p>
====Ending a backoutable unit====
====Non-backoutable units====
<p>
<b>Beginning a non-backoutable unit</b>
A backoutable unit ends when the unit is committed by using the COMMIT statement or is backed out. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this page) also can end an active update unit.
<p>A non-backoutable unit begins with the first User Language statement that performs an update operation on a non-transaction backout file. </p>
Refer to [[File integrity and_recovery#Update units and transactions]] for a complete list of conditions that end an active update unit.  </p>
<b>Ending a non-backoutable unit</b>
<p>A non-backoutable unit ends when the unit is committed by using the COMMIT statement. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this chapter) also can end an active update unit. Refer to the Rocket <var class="product">Model&nbsp;204</var> File Manager's Guide for a complete list of conditions that start or end an active update unit.           </p>
===Non-backoutable units===
===Using backout===
<p>The transaction backout facility performs two types of backouts:</p>
====Beginning a non-backoutable unit====
<p>
A non-backoutable unit begins with the first User Language statement that performs an update operation on a non-transaction backout file. </p>
====Ending a non-backoutable unit====
<p>
A non-backoutable unit ends when the unit is committed by using the COMMIT statement. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this page) also can end an active update unit.
Refer to [[File integrity and_recovery#Update units and transactions]] for a complete list of conditions that start or end an active update unit.       </p>
==Using backout==
<p>
The transaction backout facility performs two types of backouts:</p>
<table>
<table>
<tr class="head">
<tr class="head">
Line 99: Line 142:
<th>Invoked...</th>
<th>Invoked...</th>
</tr>
</tr>
<tr>
<tr>
<td>Automatic </td>
<td>Automatic </td>
<td>
<td>
<p>Automatically by a request cancellation</p>
<p>
<p>An attention or *CANCEL command without an ON ATTENTION unit</p>
Automatically by a request cancellation</p>
<p>File full condition</p>
<p>
<p>User restart.    </p>
An attention or *CANCEL command without an ON ATTENTION unit</p>
<p>
File full condition</p>
<p>
User restart.    </p>
</td>
</td>
</tr>
</tr>
<tr>
<tr>
<td>Manual </td>
<td>Manual </td>
Line 113: Line 162:
</tr>
</tr>
</table>
</table>
====Automatic backout====
<p><var class="product">Model&nbsp;204</var> automatically backs out the current update unit for a transaction backout file under any of the following conditions:</p>
===Automatic backout===
<p>
<var class="product">Model&nbsp;204</var> automatically backs out the current update unit for a transaction backout file under any of the following conditions:</p>
<ul>
<ul>
<li>If a request is cancelled by <var class="product">Model&nbsp;204</var> </li>
<li>If a request is cancelled by <var class="product">Model&nbsp;204</var> </li>
</li>
<li>If there is a file integrity problem</li>
<li>If there is a file integrity problem</li>
</li>
<li>If <var class="product">Model&nbsp;204</var> is restarting a user who has an active update unit       </li>
<li>If <var class="product">Model&nbsp;204</var> is restarting a user who has an active update unit  
</li>
</li>
</ul>
</ul>
<p>When a request accessing a transaction backout file is cancelled, the following events occur:</p>
<p>
When a request accessing a transaction backout file is cancelled, the following events occur:</p>
<ul>
<ul>
<li>The user receives a message that explains why the request was cancelled.</li>
<li>The user receives a message that explains why the request was cancelled.</li>
</li>
<li>The current update unit is backed out automatically.</li>
<li>The current update unit is backed out automatically.</li>
</li>
<li><var class="product">Model&nbsp;204</var> returns to the terminal command level unless an ON ERROR or ON ATTENTION unit is invoked.   </li>
<li><var class="product">Model&nbsp;204</var> returns to the terminal command level unless an ON ERROR or ON ATTENTION unit is invoked.
</li>
</li>
</ul>
</ul>
<p>Remote updates are backed out automatically when appropriate.</p>
<p>
====Manual backout====
Remote updates are backed out automatically when appropriate.</p>
<p>You can backout an incomplete update unit by using the BACKOUT statement. This statement is valid only for updates to transaction backout files.  </p>
<p>The BACKOUT statement releases the exclusive lock on updated records and backs out the current update unit. No found sets are released and the current record does not change.</p>
===Manual backout===
<p>After the BACKOUT statement is processed, evaluation continues with the next statement. A message is displayed to the user upon the successful completion of a backout operation.</p>
<p>
<p>The BACKOUT statement is supported in remote context. If records on any remote nodes have been updated, the BACKOUT statement causes all remote updates on all remote nodes to be backed out, in addition to any local updates.</p>
You can backout an incomplete update unit by using the BACKOUT statement. This statement is valid only for updates to transaction backout files.  </p>
<b>Example</b>
<p>
<p>The BACKOUT statement is typically used in data entry applications where a transaction might have to be backed out after it has updated a file (for example, a sales or airline reservations application). </p>
The BACKOUT statement releases the exclusive lock on updated records and backs out the current update unit. No found sets are released and the current record does not change.</p>
<p>An example of a request that uses the BACKOUT statement is provided below.</p>
<p>
After the BACKOUT statement is processed, evaluation continues with the next statement. A message is displayed to the user upon the successful completion of a backout operation.</p>
<p>
The BACKOUT statement is supported in remote context. If records on any remote nodes have been updated, the BACKOUT statement causes all remote updates on all remote nodes to be backed out, in addition to any local updates.</p>
====Example====
<p>
The BACKOUT statement is typically used in data entry applications where a transaction might have to be backed out after it has updated a file (for example, a sales or airline reservations application). </p>
<p>
An example of a request that uses the BACKOUT statement is provided below.</p>
<p class="code">BEGIN
<p class="code">BEGIN
<b></b>*
<b></b>*
Line 170: Line 231:
FEOSELECT:  FOR EACH OCCURRENCE OF SELECTION
FEOSELECT:  FOR EACH OCCURRENCE OF SELECTION
               IF SELECTION(OCCURRENCE IN FEOSELECT) EQ -
               IF SELECTION(OCCURRENCE IN FEOSELECT) EQ -
                 %SELECTION THEN  
                 %SELECTION THEN
                 %ONHAND=ONHAND(OCCURRENCE IN FEOSELECT)
                 %ONHAND=ONHAND(OCCURRENCE IN FEOSELECT)
                     %DECREMENT=%ONHAND-1
                     %DECREMENT=%ONHAND-1
Line 181: Line 242:
             JUMP TO GETVAL
             JUMP TO GETVAL
             END FOR
             END FOR
 
<b></b>*
<b></b>*
<b></b>* IF CUSTOMER IS READY TO PROCEED WITH THE SALE, THEN
<b></b>* IF CUSTOMER IS READY TO PROCEED WITH THE SALE, THEN
Line 201: Line 262:
         PRINT 'THANK YOU'
         PRINT 'THANK YOU'
DONE:    *COMMENT
DONE:    *COMMENT
END    *  
END    *
</p>
</p>
===Design considerations for transaction backout files===
<p>This section identifies the factors to consider when designing an application that uses transaction backout files. </p>
==Design considerations for transaction backout files==
<p>Transaction backout provides increased file logical consistency over the FIND share lock and FOR loop exclusive lock, and provides increased data sharing over the FIND AND RESERVE exclusive lock. However, effective use of the transaction backout facility depends on careful design and implementation.</p>
<p>
====Update requests====
This section identifies the factors to consider when designing an application that uses transaction backout files. </p>
<p>Requests that update transaction backout files cannot access non-transaction backout files in any way. This restriction ensures that all update units for a transaction backout file are logged correctly, can be backed out, and do not overlap with any update units that cannot be backed out.</p>
<p>
<p>Non-updating requests can access any type of file, and requests that update non-transaction backout files can read transaction backout files.</p>
Transaction backout provides increased file logical consistency over the FIND share lock and FOR loop exclusive lock, and provides increased data sharing over the FIND AND RESERVE exclusive lock. However, effective use of the transaction backout facility depends on careful design and implementation.</p>
====ON ATTENTION units====
<p>ON ATTENTION units should be used within requests to avoid inadvertently backing out an active update unit. If an ON ATTENTION unit is not specified and the user presses one of the ATTENTION identifier (AID) keys at the terminal or enters <var>*CANCEL</var> at a terminal I/O point, then the request is cancelled. The cancellation causes an automatic backout of the current update unit if the request updates transaction backout files.    </p>
===Update requests===
====CCATEMP space====
<p>
<p>The backout facility must have the necessary information to backout each active update unit in the <var class="product">Model&nbsp;204</var> run. A log of compensating updates is built for each active unit on the system file, CCATEMP. When the unit ends or is backed out, the log for that particular unit is discarded.</p>
Requests that update transaction backout files cannot access non-transaction backout files in any way. This restriction ensures that all update units for a transaction backout file are logged correctly, can be backed out, and do not overlap with any update units that cannot be backed out.</p>
<p>To minimize the amount of CCATEMP space used, update units should be designed to contain only a few file updates. Units of a sizable amount can greatly increase the amount of CCATEMP space used by <var class="product">Model&nbsp;204</var>. Therefore, update units should be committed frequently to minimize the size of the backout log.    </p>
<p>
====Logical inconsistency====
Non-updating requests can access any type of file, and requests that update non-transaction backout files can read transaction backout files.</p>
<p>Although transaction backout does increase the logical consistency of a file through the lock pending updates option, logical inconsistency can occur when an update unit is backed out. For example, logical inconsistency can arise when a unit involving DELETE RECORD is backed out because deleted records are not locked by the lock pending updates option. </p>
<b>Example</b>
===ON ATTENTION units===
<p>The following requests illustrate such a logical inconsistency:</p>
<p>
<table>
ON ATTENTION units should be used within requests to avoid inadvertently backing out an active update unit. If an ON ATTENTION unit is not specified and the user presses one of the ATTENTION identifier (AID) keys at the terminal or enters <var>*CANCEL</var> at a terminal I/O point, then the request is cancelled. The cancellation causes an automatic backout of the current update unit if the request updates transaction backout files.    </p>
<tr class="head">
<th>User 1 </th>
===CCATEMP space===
<th>User 2</th>
<p>
</tr>
The backout facility must have the necessary information to backout each active update unit in the <var class="product">Model&nbsp;204</var> run. A log of compensating updates is built for each active unit on the system file, CCATEMP. When the unit ends or is backed out, the log for that particular unit is discarded.</p>
<tr>
<p>
<td>
To minimize the amount of CCATEMP space used, update units should be designed to contain only a few file updates. Units of a sizable amount can greatly increase the amount of CCATEMP space used by <var class="product">Model&nbsp;204</var>. Therefore, update units should be committed frequently to minimize the size of the backout log.    </p>
<p class="code">BEGIN
</p></td>
===Logical inconsistency===
<td>
<p>
<p class="code">
Although transaction backout does increase the logical consistency of a file through the lock pending updates option, logical inconsistency can occur when an update unit is backed out. For example, logical inconsistency can arise when a unit involving DELETE RECORD is backed out because deleted records are not locked by the lock pending updates option. </p>
</p></td>
</tr>
====Example====
<tr>
<p>
<td>
The following requests illustrate such a logical inconsistency:</p>
<p class="code">SMH: FIND ALL RECORDS FOR WHICH
<div id="user1" style="display:table-cell; width:250px">
</p></td>
 
<td>
<p class="code"><b>User 1</b>
<p class="code">
</p></td>
BEGIN
</tr>
SMH: FIND ALL RECORDS FOR WHICH
<tr>
        NAME = SMITH
<td>
    END FIND
<p class="code">         NAME = SMITH
    FOR EACH RECORD IN SMH
</p></td>
        DELETE RECORD
<td>
    END FOR
<p class="code">
JNS: FIND ALL RECORD FOR WHICH
</p></td>
        NAME = JONES
</tr>
    END FIND
<tr>
    FOR EACH RECORD IN JNS
<td>
        ADD TYPE = SPECIAL
<p class="code">    END FIND
            .
</p></td>
            .
<td>
            .
<p class="code">
            .
</p></td>
            .
</tr>
            .
<tr>
            .
<td>
            .
<p class="code">    FOR EACH RECORD IN SMH
            .
</p></td>
            .
<td>
DEL: BACKOUT
<p class="code">
ALL: FIND ALL RECORDS
</p></td>
    END FIND
</tr>
    FOR EACH RECORD IN ALL
<tr>
         PRINT NAME AND TYPE
<td>
    END FOR
<p class="code">         DELETE RECORD
END</p>
</p></td>
</div> <!-- ends user1 div -->
<td>
 
<p class="code">
<div id="user2" style="display:table-cell; width:250px;">
</p></td>
<p class="code" style="border-left-width:0"><b>User 2</b>
</tr>
 
<tr>
 
<td>
 
<p class="code">    END FOR
 
</p></td>
 
<td>
 
<p class="code">  
 
</p></td>
</tr>
BEGIN
<tr>
FD.RECS: FIND ALL RECORDS FOR WHICH
<td>
            NAME = SOLOBY OR -
<p class="code">JNS: FIND ALL RECORD FOR WHICH
            NAME = SMITH OR -
</p></td>
            NAME = SAUNDERS
<td>
        END FIND
<p class="code">BEGIN
        FOR EACH RECORD IN FD.RECS
</p></td>
            ADD TYPE = SPECIAL
</tr>
        END FOR
<tr>
FD.SPEC: FIND ALL RECORDS FOR WHICH
<td>
            TYPE = SPECIAL
<p class="code">        NAME = JONES
        END FIND
</p></td>
PRT: FOR EACH RECORD IN FD.SPEC
<td>
        PRINT NAME AND TYPE
<p class="code">FD.RECS:  FIND ALL RECORDS FOR WHICH
    END FOR
</p></td>
END
</tr>
 
<tr>
 
<td>
 
<p class="code">     END FIND
 
</p></td>
 
<td>
 
<p class="code">              NAME = SOLOBY OR -
</p>  
</p></td>
</div>   <!-- ends user2 div -->
</tr>
 
<tr>
<p>
<td>
User 1 deletes the set of records with NAME = SMITH. Although the update unit is not complete, the deleted set of records is not locked. Before user 1's unit completes, user 2 finds the set of records with NAME = either SOLOBY, SMITH, or SAUNDERS. There is no locking conflict because the deleted records are not locked. User 2 adds a field to the found set, prints a report, and ends.</p>
<p class="code">    FOR EACH RECORD IN JNS
<p>
</p></td>
User 1 then decides to backout the unit in progress. The deletion of the SMITH records is in the backed out unit and the SMITH records reappear on the file. However, because the SMITH records do not have the TYPE = SPECIAL field added by user 2, there is a logical inconsistency. The chances of this type of inconsistency can be reduced by keeping units short, especially when the units involve record deletion. If user 1 had a COMMIT statement after the DELETE RECORD loop, no inconsistency would arise unless the backout was automatically activated during that short piece of the user request. It also is likely that the records deleted by an application are meant to be deleted, and a logical inconsistency in a set of records intended for deletion is unimportant.</p>
<td>
<p class="code">              NAME = SMITH OR -
====FILE RECORDS statement====
</p></td>
<p>
</tr>
Similar logical inconsistency can occur using the FILE RECORDS statement because FILE RECORDS does not lock any records. For the FILE RECORDS statement, a FIND statement can be used to lock the records to be updated in share mode, or FIND AND RESERVE can be used to lock the records in exclusive mode. If the FIND set is locked exclusively and not released until after the update unit containing the FILE RECORDS statement has ended, then logical inconsistency is prevented. </p>
<tr>
<td>
===Terminal I/O points===
<p class="code">        ADD TYPE = SPECIAL
<p>
</p></td>
Terminal I/O points should not be placed between the start of an update unit and the unit's end or backout. This precaution stems from the exclusive lock placed on updated records. If a response is required from a terminal operator either to complete or backout an update unit, there is a possibility that a set of records could be locked for an extended period of time.</p>
<td>
<p class="code">              NAME = SAUNDERS
</p></td>
</tr>
<tr>
<td>
<p class="code">            .
</p></td>
<td>
<p class="code">          END FIND
</p></td>
</tr>
<tr>
<td>
<p class="code">            .
</p></td>
<td>
<p class="code">          FOR EACH RECORD IN FD.RECS
</p></td>
</tr>
<tr>
<td>
<p class="code">            .
</p></td>
<td>
<p class="code">              ADD TYPE = SPECIAL
</p></td>
</tr>
<tr>
<td>
<p class="code">            .
</p></td>
<td>
<p class="code">          END FOR
</p></td>
</tr>
<tr>
<td>
<p class="code">            .
</p></td>
<td>
<p class="code">FD.SPEC:  FIND ALL RECORDS FOR WHICH
</p></td>
</tr>
<tr>
<td>
<p class="code">            .
</p></td>
<td>
<p class="code">              TYPE = SPECIAL
</p></td>
</tr>
<tr>
<td>
<p class="code">            .
</p></td>
<td>
<p class="code">          END FIND
</p></td>
</tr>
<tr>
<td>
<p class="code">            .
</p></td>
<td>
<p class="code">PRT:      FOR EACH RECORD IN FD.SPEC
</p></td>
</tr>
<tr>
<td>
<p class="code">            .
</p></td>
<td>
<p class="code">              PRINT NAME AND TYPE
</p></td>
</tr>
<tr>
<td>
<p class="code">            .
</p></td>
<td>
<p class="code">          END FOR
</p></td>
</tr>
<tr>
<td>
<p class="code">DEL: BACKOUT
</p></td>
<td>
<p class="code">END
</p></td>
</tr>
<tr>
<td>
<p class="code">ALL: FIND ALL RECORDS
</p></td>
<td>
<p class="code">
</p></td>
</tr>
<tr>
<td>
<p class="code">    END FIND
</p></td>
<td>
<p class="code">
</p></td>
</tr>
<tr>
<td>
<p class="code">    FOR EACH RECORD IN ALL
</p></td>
<td>
<p class="code">
</p></td>
</tr>
<tr>
<td>
<p class="code">        PRINT NAME AND TYPE
</p></td>
<td>
<p class="code">
</p></td>
</tr>
<tr>
<td>
<p class="code">    END FOR
</p></td>
<td>
<p class="code">
</p></td>
</tr>
<tr>
<td>
<p class="code">END
</p></td>
<td>
<p class="code">
</p></td>
</tr>
</table>
<p>User 1 deletes the set of records with NAME = SMITH. Although the update unit is not complete, the deleted set of records is not locked. Before user 1's unit completes, user 2 finds the set of records with NAME = either SOLOBY, SMITH, or SAUNDERS. There is no locking conflict because the deleted records are not locked. User 2 adds a field to the found set, prints a report, and ends.</p>
<p>User 1 then decides to backout the unit in progress. The deletion of the SMITH records is in the backed out unit and the SMITH records reappear on the file. However, because the SMITH records do not have the TYPE = SPECIAL field added by user 2, there is a logical inconsistency. The chances of this type of inconsistency can be reduced by keeping units short, especially when the units involve record deletion. If user 1 had a COMMIT statement after the DELETE RECORD loop, no inconsistency would arise unless the backout was automatically activated during that short piece of the user request. It also is likely that the records deleted by an application are meant to be deleted, and a logical inconsistency in a set of records intended for deletion is unimportant.</p>
<b>FILE RECORDS statement</b>
<p>Similar logical inconsistency can occur using the FILE RECORDS statement because FILE RECORDS does not lock any records. For the FILE RECORDS statement, a FIND statement can be used to lock the records to be updated in share mode, or FIND AND RESERVE can be used to lock the records in exclusive mode. If the FIND set is locked exclusively and not released until after the update unit containing the FILE RECORDS statement has ended, then logical inconsistency is prevented. </p>
====Terminal I/O points====
<p>Terminal I/O points should not be placed between the start of an update unit and the unit's end or backout. This precaution stems from the exclusive lock placed on updated records. If a response is required from a terminal operator either to complete or backout an update unit, there is a possibility that a set of records could be locked for an extended period of time.</p>
[[Category:SOUL]]
[[Category:SOUL]]

Revision as of 22:53, 17 January 2014

Overview

If hardware or software failures occur during the process of updating Model 204 files, database integrity problems can arise. These problems result from the fact that updates to a file can require coordinated changes, and a failure can interrupt the process of writing to storage a complete set of these changes.

Normally in a Model 204 installation, the system manager is responsible for the coordination of recovery activity for the installation, and the file manager determines which recovery features are applied to each of the files.

For a complete description of the Model 204 recovery process, see File integrity and recovery.

Transaction back out

One of the recovery features that can be selected by the file manager is an integrity facility called transaction backout. This facility can reverse the effects of an incomplete transaction (a sequence of file updating operations).

Application considerations

Although the file manager determines whether the transaction backout facility is defined for a file, the application designer must understand the facility's capabilities and requirements in order to ensure file integrity for an application.

This page explains those capabilities and requirements and describes how applications can be designed to ensure file integrity. In particular, see the last section in this chapter for application design considerations.

Transaction backout

The transaction backout facility allows Model 204 to logically reverse the effects of an incomplete update to a file.

A backout can be initiated only on incomplete update units; completed update units cannot be backed out. A backout can be automatically performed by Model 204 or initiated by the user.

FOPT and FRCVOPT parameters

Transaction backout is an option of the FOPT and FRCVOPT parameters and is enabled or disabled on a file-by-file basis.

Types of backout

You can use the transaction backout facility to specify two types of files:

backout file types File options set to... Discussion
Transaction backout Enable both lock pending updates and backout.

A transaction can be backed out automatically by Model 204 or manually by the application.

A transaction backout file ensures:

Logical consistency

Data and file integrity,

High degree of data sharing.

Non-transaction backout Disable transaction backout.

Incomplete updates cannot be automatically reversed.

Non-transaction backout files cannot be accessed remotely. Attempts to open a non-transaction backout file in remote context fails and generates the following error message:

M204.1973: NON-TBO REMOTE FILE

Update units

An update unit is any sequence of operations that updates the database and that has a beginning and ending point. One update unit must end before another update unit can begin.

A request or procedure can have two types of update units:

Update unit type Discussion
Backoutable A backoutable unit consists of updates to transaction backout files using file updating statements (such as STORE RECORD). The unit can either be completed so that it persists in the file, or backed out so that the update is logically reversed in the file.
Non-backoutable A non-backoutable unit consists of updates to non-transaction backout files.

Backoutable units

Beginning a backoutable unit

A backoutable unit begins at the execution of the first User Language statement that performs an update operation on a transaction backout file. The statements that perform update operations are:

  • ADD fieldname = value
  • CHANGE fieldname TO value
  • DELETE EACH fieldname
  • DELETE fieldname [= value]
  • DELETE RECORD
  • DELETE RECORDS
  • FILE RECORDS
  • INSERT fieldname = value
  • STORE RECORD

Ending a backoutable unit

A backoutable unit ends when the unit is committed by using the COMMIT statement or is backed out. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this page) also can end an active update unit. Refer to File integrity and_recovery#Update units and transactions for a complete list of conditions that end an active update unit.

Non-backoutable units

Beginning a non-backoutable unit

A non-backoutable unit begins with the first User Language statement that performs an update operation on a non-transaction backout file.

Ending a non-backoutable unit

A non-backoutable unit ends when the unit is committed by using the COMMIT statement. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this page) also can end an active update unit. Refer to File integrity and_recovery#Update units and transactions for a complete list of conditions that start or end an active update unit.

Using backout

The transaction backout facility performs two types of backouts:

Backout type Invoked...
Automatic

Automatically by a request cancellation

An attention or *CANCEL command without an ON ATTENTION unit

File full condition

User restart.

Manual Using the BACKOUT statement within a request.

Automatic backout

Model 204 automatically backs out the current update unit for a transaction backout file under any of the following conditions:

  • If a request is cancelled by Model 204
  • If there is a file integrity problem
  • If Model 204 is restarting a user who has an active update unit

When a request accessing a transaction backout file is cancelled, the following events occur:

  • The user receives a message that explains why the request was cancelled.
  • The current update unit is backed out automatically.
  • Model 204 returns to the terminal command level unless an ON ERROR or ON ATTENTION unit is invoked.

Remote updates are backed out automatically when appropriate.

Manual backout

You can backout an incomplete update unit by using the BACKOUT statement. This statement is valid only for updates to transaction backout files.

The BACKOUT statement releases the exclusive lock on updated records and backs out the current update unit. No found sets are released and the current record does not change.

After the BACKOUT statement is processed, evaluation continues with the next statement. A message is displayed to the user upon the successful completion of a backout operation.

The BACKOUT statement is supported in remote context. If records on any remote nodes have been updated, the BACKOUT statement causes all remote updates on all remote nodes to be backed out, in addition to any local updates.

Example

The BACKOUT statement is typically used in data entry applications where a transaction might have to be backed out after it has updated a file (for example, a sales or airline reservations application).

An example of a request that uses the BACKOUT statement is provided below.

BEGIN * * DECREMENT INVENTORY BEFORE MAKING SALE TO CUSTOMER * DECLARE %INPUT STRING LEN 70 DECLARE %VINTNER STRING LEN 30 DECLARE %SELECTION STRING LEN 40 * * ENTER PURCHASER'S SELECTION * GETVAL: %INPUT=$READ('ENTER VINTNER/SELECTION:') IF %INPUT EQ 'QUIT' THEN STOP END IF %VINTNER=$SUBSTR(%INPUT,1,$INDEX(%INPUT,'/')-1) %SELECTION=$SUBSTR(%INPUT,$INDEX(%INPUT,'/')+1) FDVINTNER: FD REC=VINTNER AND NAME=%VINTNER CTVINTNER: COUNT RECORDS IN FDVINTNER IF COUNT IN CTVINTNER EQ '0' THEN PRINT 'VINTNER DOES NOT EXIST TRY AGAIN' JUMP TO GETVAL END IF * * IF SELECTION EXISTS THEN UPDATE RECORD BY DECREASING * THE AMOUNT ON HAND * CTSELECTION: FOR EACH RECORD IN FDVINTNER FEOSELECT: FOR EACH OCCURRENCE OF SELECTION IF SELECTION(OCCURRENCE IN FEOSELECT) EQ - %SELECTION THEN %ONHAND=ONHAND(OCCURRENCE IN FEOSELECT) %DECREMENT=%ONHAND-1 CHANGE ONHAND(OCCURRENCE IN FEOSELECT)- TO %DECREMENT JUMP TO GETCASH END IF END FOR PRINT 'SELECTION DOES NOT EXIST TRY AGAIN' JUMP TO GETVAL END FOR * * IF CUSTOMER IS READY TO PROCEED WITH THE SALE, THEN * COMMIT THE TRANSACTION. IF NOT, THEN BACKOUT RECORD * UPDATED * GETCASH: %CASH=$READ('DID YOU GET CASH/CREDIT CARD FROM - CUSTOMER Y/N:') IF %CASH EQ 'Y' THEN COMMIT JUMP TO FINISH ELSE BACKOUT PRINT 'INVENTORY WAS NOT UPDATED ' PRINT 'PURCHASE STOPPED' JUMP TO DONE END IF FINISH: PRINT 'TRANSACTION COMPLETED' PRINT 'THANK YOU' DONE: *COMMENT END *

Design considerations for transaction backout files

This section identifies the factors to consider when designing an application that uses transaction backout files.

Transaction backout provides increased file logical consistency over the FIND share lock and FOR loop exclusive lock, and provides increased data sharing over the FIND AND RESERVE exclusive lock. However, effective use of the transaction backout facility depends on careful design and implementation.

Update requests

Requests that update transaction backout files cannot access non-transaction backout files in any way. This restriction ensures that all update units for a transaction backout file are logged correctly, can be backed out, and do not overlap with any update units that cannot be backed out.

Non-updating requests can access any type of file, and requests that update non-transaction backout files can read transaction backout files.

ON ATTENTION units

ON ATTENTION units should be used within requests to avoid inadvertently backing out an active update unit. If an ON ATTENTION unit is not specified and the user presses one of the ATTENTION identifier (AID) keys at the terminal or enters *CANCEL at a terminal I/O point, then the request is cancelled. The cancellation causes an automatic backout of the current update unit if the request updates transaction backout files.

CCATEMP space

The backout facility must have the necessary information to backout each active update unit in the Model 204 run. A log of compensating updates is built for each active unit on the system file, CCATEMP. When the unit ends or is backed out, the log for that particular unit is discarded.

To minimize the amount of CCATEMP space used, update units should be designed to contain only a few file updates. Units of a sizable amount can greatly increase the amount of CCATEMP space used by Model 204. Therefore, update units should be committed frequently to minimize the size of the backout log.

Logical inconsistency

Although transaction backout does increase the logical consistency of a file through the lock pending updates option, logical inconsistency can occur when an update unit is backed out. For example, logical inconsistency can arise when a unit involving DELETE RECORD is backed out because deleted records are not locked by the lock pending updates option.

Example

The following requests illustrate such a logical inconsistency:

User 1 BEGIN SMH: FIND ALL RECORDS FOR WHICH NAME = SMITH END FIND FOR EACH RECORD IN SMH DELETE RECORD END FOR JNS: FIND ALL RECORD FOR WHICH NAME = JONES END FIND FOR EACH RECORD IN JNS ADD TYPE = SPECIAL . . . . . . . . . . DEL: BACKOUT ALL: FIND ALL RECORDS END FIND FOR EACH RECORD IN ALL PRINT NAME AND TYPE END FOR END

User 2 BEGIN FD.RECS: FIND ALL RECORDS FOR WHICH NAME = SOLOBY OR - NAME = SMITH OR - NAME = SAUNDERS END FIND FOR EACH RECORD IN FD.RECS ADD TYPE = SPECIAL END FOR FD.SPEC: FIND ALL RECORDS FOR WHICH TYPE = SPECIAL END FIND PRT: FOR EACH RECORD IN FD.SPEC PRINT NAME AND TYPE END FOR END

User 1 deletes the set of records with NAME = SMITH. Although the update unit is not complete, the deleted set of records is not locked. Before user 1's unit completes, user 2 finds the set of records with NAME = either SOLOBY, SMITH, or SAUNDERS. There is no locking conflict because the deleted records are not locked. User 2 adds a field to the found set, prints a report, and ends.

User 1 then decides to backout the unit in progress. The deletion of the SMITH records is in the backed out unit and the SMITH records reappear on the file. However, because the SMITH records do not have the TYPE = SPECIAL field added by user 2, there is a logical inconsistency. The chances of this type of inconsistency can be reduced by keeping units short, especially when the units involve record deletion. If user 1 had a COMMIT statement after the DELETE RECORD loop, no inconsistency would arise unless the backout was automatically activated during that short piece of the user request. It also is likely that the records deleted by an application are meant to be deleted, and a logical inconsistency in a set of records intended for deletion is unimportant.

FILE RECORDS statement

Similar logical inconsistency can occur using the FILE RECORDS statement because FILE RECORDS does not lock any records. For the FILE RECORDS statement, a FIND statement can be used to lock the records to be updated in share mode, or FIND AND RESERVE can be used to lock the records in exclusive mode. If the FIND set is locked exclusively and not released until after the update unit containing the FILE RECORDS statement has ended, then logical inconsistency is prevented.

Terminal I/O points

Terminal I/O points should not be placed between the start of an update unit and the unit's end or backout. This precaution stems from the exclusive lock placed on updated records. If a response is required from a terminal operator either to complete or backout an update unit, there is a possibility that a set of records could be locked for an extended period of time.