Data Manipulation Language Statements › #KEEP—establishes long-term record locks

#KEEP—establishes long-term record locks

The #KEEP statement is used in DC/UCF pseudo-conversational transactions to establish long-term record locks and to monitor access to records between tasks. Long-term database locks can be shared or exclusive:

• Long-term shared locks allow other run units to access the locked record but prevent run units from updating the record as long as the lock is maintained.
• Long-term exclusive locks prevent other run units from accessing the locked record. However, run units executing on the logical terminal associated with a task that establishes a long-term exclusive lock are not restricted from accessing the locked record. Therefore, subsequent tasks in a transaction can access the locked record and complete the database processing required by the transaction.

If a record has been locked with a #KEEP request, restrictions may exist on the type of lock that can be placed on that record by other run units, based on existing locks and whether the requesting run unit is executing on the same logical terminal as the run unit that originally placed the lock on the record. The following table illustrates these restrictions.

Tasks can monitor database activity associated with a specified record during a pseudo-converse and, if desired, can place a long-term lock on the record being monitored. A subsequent task can then make inquiries about that database activity for the record and take the appropriate action.

The system maintains information on database activity using five-bit flags, each of which is either turned on (binary 1) or turned off (binary 0). This information is returned from the system to the low-order byte of register 0 as a numeric value. The bit assignments, the corresponding numeric value returned to the program, and a description of the associated database activity follows:

X'10'

The record has been physically deleted.

X'08'

The record has been logically deleted.

X'04'

The record's prefix has been modified, that is, a set operation (for example, @CONNECT or @DISCON) occurred involving the record.

X'02'

The record's data has been modified.

X'01'

The record has been obtained.

Any combination of these bits may be set. To determine the action or combination of actions that has occurred, you can compare the numeric value returned to the program in register 0 with an appropriate constant; for example:

• If the returned value is 0, no database activity occurred for the monitored record.
• If the returned value is 2, the data in the record was modified.
• If the returned value is 3, the record has been obtained and modified.
• If the returned value is 8 or greater, the record was deleted.

The maximum possible value is 31 (X'1F'), indicating that all the above actions occurred for the monitored record. The example of the #KEEP statement, shown later in this topic, illustrates a test for the value of the five bit flags returned by the system to the low-order byte of register 0.

You may prefer to monitor database activity across a pseudo-converse rather than to set long-term locks. Long-term locks can prevent access to a record by other run units for an undesirably long time if, during a pseudo-converse, the terminal operator fails to enter a response. Monitoring does not restrict access to database records, sets, or areas by other run units; however, it does enable a program to test a record for alterations made by other run units. When long-term locks are used, it may be desirable to release those locks at specified timeout intervals.

Note: For more information about the use of timeout intervals, see the System Generation Guide.