In this section: |
The following facilities are available to protect transactions in case a system failure brings down the FOCUS Database Server:
Under SU, when FOCUS writes transactions for a single user on a FOCUS Database Server, it automatically writes pending transactions of all users on that server, even those users who did not request a checkpoint action. It then records this as a SAV action in the HLIPRINT file. FOCUS also writes the transactions of all users on the same server when a MODIFY or Maintain request submitted by one user finishes execution. This is recorded as a CLO action in the HLIPRINT file.
If the system fails while MODIFY or Maintain requests are executing, all transactions entered before FOCUS last wrote to the database (because of the Checkpoint facility or because a MODIFY or Maintain request finished execution) are saved in the database. All transactions entered after that may be lost and must be reentered. In MODIFY, you can use CHECK 1 to avoid this situation.
It is sometimes a good idea to log all transactions in a sequential file so that they may be re-entered if any are lost. To do this, add LOG or TYPE commands to the MODIFY or Maintain request. LOG commands are satisfactory for simple requests, while TYPE commands are better for complex Case Logic requests. For more information, see the Maintaining Databases manual.
You can also protect the integrity of the centrally controlled database itself with the Absolute File Integrity feature described in your FOCUS documentation. Absolute File Integrity is not needed for Maintain.
When FOCUS accepts transactions, it does not write the transactions to the database immediately. Rather, it collects them in a buffer. When the buffer is full, FOCUS writes them all to the database at the same time. This reduces the number of input/output operations that FOCUS must perform. However, if your z/OS system fails and brings down the server, the transactions collected in the buffer may be lost. You can instruct FOCUS to write more frequently to the database by using the Checkpoint facility, described in the Maintaining Databases manual.
The Checkpoint facility is activated with the MODIFY CHECK command that specifies how many transactions to accumulate in the buffer before writing them to the database. The following request writes transactions to the database in groups of 10:
MODIFY FILE EMPLOYEE PROMPT EMP_ID CURR_SAL MATCH EMP_ID ON NOMATCH REJECT ON MATCH UPDATE CURR_SAL CHECK 10 DATA
In this section: |
COMMIT and ROLLBACK are two MODIFY and Maintain subcommands. COMMIT gives you control over the content of database changes and ROLLBACK enables you to undo changes before they become permanent.
The COMMIT subcommand safeguards transactions in case of a system failure and provides greater control than the Checkpoint facility over which transactions are written to the database.
The MODIFY CHECK command only enables you to control the number of transactions that must occur before changes are written to the database. When using CHECK, you cannot change the Checkpoint setting once the request begins execution. Similarly, changes cannot be cancelled. For information on the CHECK command, see The Checkpoint Facility (MODIFY Only).
COMMIT enables you to make changes based on the content of the transactions as well as the number. Changes you do not want to make can be cancelled with ROLLBACK, unless a COMMIT has been issued for those changes. Should the system fail, either all or none of your transactions will be processed.
Maintain uses FOCURRENT to report the result of the latest COMMIT action. Maintain does not support the Checkpoint facility. Therefore, the only way to control a unit of work in Maintain is with the COMMIT and ROLLBACK subcommands.
Absolute File Integrity is required in order to use COMMIT and ROLLBACK in MODIFY. Absolute File Integrity for databases in SU is provided solely by the FOCUS Shadow Writing Facility. See your FOCUS documentation for information on Absolute File Integrity and the SET SHADOW command.
COMMIT and ROLLBACK each process a logical transaction. A logical transaction is a group of database changes in the MODIFY or Maintain environment that you want to treat as one. For example, you can handle multiple records displayed on a CRTFORM and then processed using the REPEAT command as a single transaction. A logical transaction is terminated by either COMMIT or ROLLBACK. COMMIT and ROLLBACK also can be used for single record processing.
When COMMIT ends a logical transaction, it writes all changes to the database. Once changes have been committed, they cannot be rolled back. COMMIT can be coded as a global subcommand or as part of MATCH or NEXT logic. The possible MATCH and NEXT commands are:
COMMIT ON MATCH COMMIT ON NOMATCH COMMIT ON MATCH/NOMATCH COMMIT ON NEXT COMMIT ON NONEXT COMMIT
When ROLLBACK terminates a logical transaction, it does not write changes to the database. The ROLLBACK subcommand cancels changes made since the last COMMIT. ROLLBACK cannot cancel changes once a COMMIT has been issued for them.
ROLLBACK can be coded as a global subcommand or as part of MATCH or NEXT logic. Possible MATCH and NEXT commands are:
ROLLBACK ON MATCH ROLLBACK ON NOMATCH ROLLBACK ON MATCH/NOMATCH ROLLBACK ON NEXT ROLLBACK ON NONEXT ROLLBACK
If the COMMIT fails for any reason (for example, system failure or lack of disk space), no changes are made to the database. In this way, COMMIT is an all or nothing feature that ensures database integrity.
The SU change/verify protocol operates on a logical transaction basis that may encompass a block of records. It relies on the optimistic assumption that two users rarely change the same records at the same time. In SU processing with COMMIT, the server keeps a table of soft locks that tracks which records have been requested by which users.
When a COMMIT is issued, the server checks this table for each record that you want to change to determine if another user changed a record between the time you retrieved it and the time you issued the COMMIT. If another user has issued a COMMIT against a record you intend to change, your changes are automatically rolled back.
For example, User A and User B execute a MODIFY or Maintain procedure against the EMPLOYEE database on a FOCUS Database Server. Each user matches on the same employee ID and performs a MATCH action as follows:
|
User A |
User B |
|---|---|
|
|
If User A issues a COMMIT before User B, User B's changes will be rolled back. If User B issues a COMMIT before User A, User A's changes will be rolled back.
Many applications contain transactions that are interdependent. For these applications, processing is successful only when several physical transactions are complete. The following application transfers funds from one bank account to another. Two components make up each logical transaction:
If either part of the logical transaction is not complete, no changes should be made to the database. Because the application has multiple users, it is essential that each account be involved in only one transfer transaction at a time.
The BANK file in this application is a FOCUS database on a FOCUS Database Server with the following Master File:
FILE = BANK, SUFFIX = FOC,$ SEGNAME = TOPSEG, SEGTYPE = S1,$ FIELD = ACCOUNT_NUM , ACCT , A8 ,$ FIELD = BALANCE , BAL , D12.2 ,$ FIELD = CUSTOMER , NAME , A40 ,$
The following MODIFY procedure shows how COMMIT and ROLLBACK can be used to ensure that a logical transaction is complete before it is written to the database. It also shows the use of FOCURRENT in SU COMMIT processing. Numbers to the left of the command lines refer to annotations following the example:
MODIFY FILE BANK
COMPUTE AMOUNT = ;
FROM_ACCOUNT/A8 = ;
TO_ACCOUNT/A8 = ;
1. CRTFORM
"FUND TRANSFER. ENTER ACCOUNT NUMBERS:"
" TO TRANSFER FROM == > <FROM_ACCOUNT"
" TO TRANSFER TO == > <TO_ACCOUNT"
" ENTER AMOUNT == > <AMOUNT"
2. PERFORM SUBTRACT
5. PERFORM ADD
7. COMMIT
8. IF FOCURRENT EQ 0 GOTO TOP;
TYPE "ACCOUNTS WERE IN USE. PLEASE TRY AGAIN."
GOTO TOP
2. CASE SUBTRACT
COMPUTE ACCOUNT_NUM = FROM_ACCOUNT;
MATCH ACCOUNT_NUM
3. ON NOMATCH ROLLBACK
ON NOMATCH REJECT
ON MATCH COMPUTE BALANCE = D.BALANCE - AMOUNT;
4. ON MATCH IF BALANCE LT 0 PERFORM REDO;
ON MATCH UPDATE BALANCE
ENDCASE
5. CASE ADD
COMPUTE ACCOUNT NUM = TO_ACCOUNT;
MATCH ACCOUNT NUM
6. ON NOMATCH ROLLBACK
ON NOMATCH REJECT
ON MATCH COMPUTE BALANCE = D.BALANCE + AMOUNT;
ON MATCH UPDATE BALANCE
ENDCASE
4. CASE REDO
TYPE "BALANCE WILL BE LESS THAN ZERO. TRY ANOTHER AMOUNT."
GOTO TOP
ENDCASE
DATA
ENDNote:
| Information Builders |