HP OpenVMS Systems Documentation |
HP COBOL
|
Previous | Contents | Index |
However, the DBCS grants a no-read access lock if your run unit specifies a DML update verb, such as STORE, CONNECT, or MODIFY. Your run unit retains the lock on this record until the change is committed to the database by the DML COMMIT verb or the change is terminated or canceled by ROLLBACK.
The Run-Time System notifies the DBCS each time a run unit requests a
locked record, thus keeping track of which records are locked and who
is waiting for which records. This logging helps the DBCS determine
whether a conflict
exists, such as multiple run units requesting, but not being allowed,
to access or change the same record. For more information on record
locking, refer to the Oracle CODASYL DBMS documentation on database design
and programming.
6.2 COMMIT and ROLLBACK
When you are in CONCURRENT UPDATE mode, any changes made to a record lock the record and prevent its access by other run units. For example, if a program updates 200 customer records in one transaction, the 200 customer records are unavailable to other run units. To minimize lockout, use the COMMIT statement as often as possible.
The COMMIT statement makes permanent all changes made to the database, frees all locks, and nulls all currencies. It also establishes a quiet point for your run unit.
The RETAINING clause can be used with the COMMIT statement. COMMIT RETAINING does not empty keeplists; retains all currency indicators; does not release realm locks; demotes no-read locks to read-only locks; then releases locks for all records except those in currency indicators or keeplists and makes visible any changes made to the database.
To use COMMIT properly, you need to know about application systems. For example, you might want to execute a COMMIT each time you accomplish a logical unit of work. Or, if you were updating groups of interdependent records like those in Figure 6-1, you would execute a COMMIT only after updating a record group.
Figure 6-1 Using the COMMIT Statement
The ROLLBACK statement cancels all changes made to the database since the last executed READY statement and returns the database to its condition at the last quiet point. The DBCS performs an automatic ROLLBACK if your run unit ends without executing a COMMIT or if it ends abnormally.
In Example 6-1 an order-processing application totals all items ordered by a customer. If the order amount exceeds the credit limit, the program executes a ROLLBACK and cancels the transaction updates. Notice that the credit limit is tested for each ordered item, thus avoiding printing of an entire invoice prior to cancelling the order.
Example 6-1 ROLLBACK Statement |
---|
. . . READY-UPDATE. READY TEST_REALM CONCURRENT UPDATE. ************************** * FETCH CUSTOMER ROUTINE * ************************** . . . ******************************* * FETCH ORDERED ITEMS ROUTINE * ******************************* . . . CREDIT-LIMIT-CHECK. MULTIPLY ORDERED-QUANTITY BY UNIT-PRICE GIVING ORDER-AMOUNT. ADD ORDER-AMOUNT TO TOTAL-AMT. IF TOTAL-AMT IS GREATER THAN CUST-CREDIT-LIMIT ROLLBACK PERFORM CREDIT-LIMIT-EXCEEDED ELSE PERFORM PRINT-INVOICE-LINE. |
The FIND OWNER statement finds the owner of the current of set type, which may not be the same as the current of run unit. Thus, executing a FIND OWNER WITHIN set-name when the current of run unit record is not connected to the specified set returns the owner of the member that is current of set type.
Figure 6-2 shows occurrences of the RESPONSIBLE_FOR set type where employees are responsible for the design of certain parts.
Figure 6-2 Occurrences of the RESPONSIBLE_FOR Set Type
Example 6-2 uses the data in Figure 6-2 to perform an analysis of PART D, PART L, and the work of the engineer responsible for each part. The set retention class is optional.
Example 6-2 Owner and Member Test Condition |
---|
. . . 000130 MAIL-LINE ROUTINE. 000140 MOVE "PART D" TO PART_DESC. 000150 PERFORM FIND-PARTS. 000160 MOVE "PART L" TO PART_DESC. 000170 PERFORM FIND-PARTS. 000180 GO TO ALL-FINISHED. 000190 FIND-PARTS. 000200 FIND FIRST PART USING PART_DESC. 000210 IF PART-IS-MISSING 000220 PERFORM PART-MISSING. 000230 PERFORM PARTS-ANALYSIS. 000240 FIND OWNER WITHIN RESPONSIBLE_FOR. 000250 PERFORM WORKLOAD-ANALYSIS. 000250 DONE-ANALYSIS. 000260 EXIT. . . . |
When PART L becomes current of run unit, a FIND OWNER (statement 000240) finds PART D's owner, thus producing incorrect results. This is because a FIND OWNER WITHIN set-name uses the current of set type and PART L is not a member of any RESPONSIBLE_FOR set type occurrence. To prevent this error, statement 000240 should read:
IF RESPONSIBLE_FOR MEMBER FIND OWNER WITHIN RESPONSIBLE_FOR ELSE PERFORM PART-HAS-NO-OWNER. |
The OWNER test condition does not test whether the current record owns any member records. Rather, this condition tests if the current record participates as an owner record. If a record type is declared as the owner of a set type, an OWNER test for that record type will always be true. Therefore, referring to Figure 6-2, if EMP4 is the object of an IF RESPONSIBLE_FOR OWNER test, the result is true because EMP4 is an owner record, even though the set occurrence is empty.
To test if an owner record owns any members, use the EMPTY test condition. For example:
IF RESPONSIBLE_FOR IS EMPTY PERFORM EMPTY-ROUTINE ELSE ... |
Thus, if EMP4 is the object of an IF RESPONSIBLE_FOR IS EMPTY test, the
result is true because the set occurrence has no members.
6.5 Modifying Members of Sorted Sets
If the schema defines a set's order to be SORTED and you modify any data items specified in the ORDER IS clause of the schema, the record may change position within the set occurrence. If the record does change position, the set's currency changes to point to the member record's new position.
Figure 6-3 shows a set occurrence for SORT_SET where MEMBER-B's key (KEY 3) was changed to KEY 8. Before altering the record's key, the set currency pointed to MEMBER-B, and a FETCH NEXT MEMBER WITHIN SORT_SET fetched MEMBER-C. However, the modification to MEMBER-B's key repositions the record within the set occurrence. Now, a FETCH NEXT MEMBER WITHIN SORT_SET fetches the MEMBER-D record.
Figure 6-3 Modifying Members of Sorted Sets
When you change the contents of a data item specified in the ORDER IS SORTED clause and you do not want the set's currency to change, use the RETAINING clause with the MODIFY statement. Thus, MODIFY repositions the record and RETAINING keeps the currency indicator pointing at the position vacated by the record. Figure 6-4 shows how the following example retains currency for SORT_SET.
FETCH NEXT WITHIN SORT_SET. IF MEMBER_KEY = "KEY 3" MOVE "KEY 8" TO MEMBER_KEY MODIFY MEMBER_KEY RETAINING SORT_SET. |
Figure 6-4 After Modifying MEMBER_B and Using RETAINING
If MEMBER_B's key was changed to KEY 4, the record's position in the set occurrence would not change, and a FETCH NEXT WITHIN SORT_SET would fetch MEMBER_C.
Previous | Next | Contents | Index |