HP OpenVMS Systems Documentation

Content starts here

HP COBOL
DBMS Database Programming Manual


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.

6.3 The Owner and Member Test Condition

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.

6.4 Using IF EMPTY Instead of IF 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