Chapter 14:  Simultaneous Update

ACCENT R’s Simultaneous Update provides powerful features to facilitate and control simultaneous data accessing by multiple users.  The power implicit in these features makes it critical that those who use Simultaneous Update have a thorough understanding of the full impact of each feature they implement, and that the needs of all users be given careful consideration.  An application that is put in place without adequate planning could have the effect of unnecessarily blocking users from records or DS's.

ACCENT R checks for DS records that are exact multiples of the OpenVMS memory page size (512 characters).  Such records are locked by itself.  Other locking methods can lock 2 or more blocks for records which cross block boundaries.

Users can design applications to take advantage of this new locking method.  Users could access only the record they are working on (without locking others out of records that are not being used).  This would provide more efficient table management.

There are three Data Accessing environments - only two of which allow for Simultaneous Update.  Before addressing the three environments, however, it is important to define the types of operations that are performed on DS's.  In this context, it is appropriate to categorize all operations into three categories:

These three types of operation are impacted differently by the three data access environments.

Two additional terms need to be briefly mentioned here:  open and access.  Within a queued environment, a DS must be opened before it can be queued.  Then it is accessed when data is actually retrieved from it.

The next several pages describe the three data access environments: default, Concurrent Queued, and Exclusive Queued.  These descriptions are followed by detailed discussions of all the ACCENT R features that are used in Simultaneous Update.

Clarification

The use of Simultaneous Update will provide satisfactory results in most applications.  However, if users attempt to read or write data blocks to DS's which are locked by other users, they will experience delays.  Record locking in simultaneous update applications should only be used if needed in the application.  Each lock ties up a block of records which prohibit other users from reading (GET) or inserting (CREATE) records in that block.  Use LOCK with GET statements only if updating records.

There are three data processing environments:

The first user who accesses a DS for updating will hold control of the DS.  Other users that are trying to update (or append) are blocked from the DS.  There is no queue set up to record the order of the other requests to update.  The other programs go into a “wait-and-try” mode until the first user is done.  The first program to “try” again after the DS is released will gain control.  Other users who are just reading with a GET are not affected by the update locking.  This is the default environment when no processing statements (explained below) are used.

This environment is created by:

1. establishing a control file for the DS.

2. using the ALLOWING clause in the RELATE statement of the Process Module (PM) which does the updating.

Example

RELATE INVOICE AS INV FOR ALLOWING others to UPDATE

The operation for “self” and “others” are GET (read), PUT (write-update), DELETE, APPEND (create-insert), UPDATE (all functions).

This environment allows multi-user input and update to the same DS.  A record queue is used to record update requests for the same record.  Access is granted after the record is released on a first-in first-out basis.  Users cannot read a record being updated or update a record that is already in the process of being updated.  A MULTIPLE clause in the GET statement can lock more than one record.

A LOCK statement allows for exclusive use of the DS during part of the PM.  A file queue is used to record access requests to a DS when LOCK is invoked.  When a DS is accessed, the PM will wait until all prior users are finished (while other PM’s that follow in the file queue are locked out) before processing data.  The lock affects all users, even if they are only trying to read records.  The lock can be released with a FREE statement.  If the FREE statement is missing, the lock will be released when the PM is finished.

This environment is created like Concurrent Queued:

1. establishing a control file for the DS.

2. using the ALLOWING clause in the RELATE statement of PM which does the updating.  The main difference is in the ALLOWING clause.

Example

RELATE INVOICE AS INV FOR self ALLOWING OTHERS TO WAIT

This environment allows for exclusive control of a DS for the duration of a PM.  The file queue and data processing are handled the same as with a LOCK statement (in a PM with no FREE statement) in the Concurrent Queued environment.

Default Data Access Environment

When none of ACCENT R’s Simultaneous Update features are in use, access to DS is governed by the default data access procedures of the system.  The first user who accesses a DS for update maintains update control of the DS, and blocks any other user who also wants to update it.  However, all other users who want to access the DS for input are allowed access.

While the first user keeps update control of the DS, any other user who wants to update the DS is simply refused access, but no record of the attempt to gain access is maintained.  If the second user, who wants to update is operating from within a program, the program goes into a "wait and try" cycle and keeps attempting to get control of the DS every five seconds.  If a third user comes along and wants to update the DS, they will also be refused access and his program goes into a "wait and try" cycle like the second user’s.  When the first user closes the DS, either the second or the third user could next get update access.  Since the system maintains no records of attempts to open the DS, no control is possible about who next gets update access.  If the third user’s program attempts to gain access before the second user’s does, the third user will get control and block the second user.  By the same token, a fourth and then a fifth user might come along and try to access the DS, and there is no way to predict the order in which they will succeed.

If a user attempts to access a DS so as to supersede it, he is prevented from accessing the DS until no other users are accessing it for update.  By the same token, once a supersede begins, no other user can access the DS for update until the supersede is completed and the DS is released.  However, a supersede can begin if another user has access to the DS for input, and input access is allowed during the supersede.

Concurrent Queued Environment

The Concurrent Queued Environment allows multi-user input and update to the same DS and is only available through the use of PM's.

ACCENT R accomplishes concurrent data input and update by queuing users’ requests for access at two levels:  table level and record level.  At table and record levels, requests are granted on a first-in first-out basis.  Record-level queuing insures that a user does not read a record that is currently being updated.  It further insures that two users do not update the record at the same time.

Example

The Concurrent Queued Environment is established by specifying one or more operations in the ALLOWING clause of the RELATE statement.  This environment also requires that a Control File (CF) be established for the DS.

RELATE ds_name AS designator FOR clause ALLOWING clause

NOTES:  This is the most complex data access environment.  A user may specify, in precise detail, what operations their PM will perform on the DS, and the types of operations that are allowed for other users who concurrently want to access the same DS.  The operations for self are listed in the FOR clause of the RELATE statement, and those operations allowed by others are listed in the ALLOWING clause.  The operations that can be specified in both clauses are:  GET, PUT, DELETE, APPEND, and UPDATE.

Most applications need exclusive access to a given record only during the instant that it is being updated.  To accomplish this, a GET statement with the LOCKED option is used to retrieve a record while it is to be updated.  Exclusive data accessing is confined to the block of records that is being modified.  This approach lets many users access and update the DS at the same time.  This type of application is very common and is used by agencies for booking tickets, by universities for keeping track of class registration, by companies for updating inventories, and so on.

It is also possible to temporarily lock all the records in the DS during part of the PM execution, then free them for the rest of the PM.  This is done with the LOCK statement and the FREE statement.  This option is appropriate for applications that require immediate and exclusive access to a DS that is currently opened by many users.  For these applications, a PM should relate the DS FOR UPDATE ALLOWING UPDATE, and then use a LOCK statement within the PM.  Under this procedure, the PM accesses the DS, waits for a moment when no concurrent users are retrieving any records, then locks all the records for exclusive update while others wait.  An example of an application that would need immediate and exclusive access to the DS might be an immediate freeze on a certain group of products in the central inventory of a nationwide company.  This approach insures that data is kept current while the DS is opened by many users.

It is also possible to reserve more than one record at a time, allowing no other user to access any of the reserved records for either input or update until the user chooses to release them.  The ACCENT R features used for this are the MULTIPLE option on the GET statement, and a subsequent FREE statement.

Exclusive Queued Environment

In the third possible environment, a user may specify exclusive access to an entire DS for the duration of the PM, making all other users in the queue wait until the PM is finished before either input or update access is allowed.  When this environment is specified, the user’s request for the DS is queued with the others, but the PM is not allowed to access the DS until all programs that precede it in the queue have completed their processing and are done with the DS.

Example

This environment can only be established by specifying ALLOWING OTHERS TO WAIT in the RELATE statement.  It also requires the establishment of a CF.

RELATE ds_name AS designator FOR clause ALLOWING OTHERS TO WAIT

NOTES:  This approach is most suitable to applications that (1) do not require immediate access to the DS, and (2) require exclusive access to the entire DS for the duration of the PM.  An example of such an application might be the periodic updating of a DS that would result in alterations to field values in many records throughout the DS, such as a PM used once a month to process paychecks, credits, and debits on a company DS.  Such applications programs are usually run as a batch job, during after-office hours.

Impact Of Data Access Environments On One Another

Since different users can specify different environments and can attempt to exert different degrees of control on other users, the questions "Who controls whom?" and "Who has precedence?" become very important.

First of all, the whole concept of data access environments has relevance only when two or more users are attempting to use the same DS.  Users who are opening or accessing different DS's have no impact on one another.

All users of a single DS who request a queuing environment (or get queuing by default) are put in the same queue; in other words, there is only one queue for each DS, and all jobs, whether they request a Concurrent Queued or Exclusive Queued environment, are queued together.

Though all queued jobs are queued together, Concurrent and Exclusive jobs are mutually exclusive and cannot run together.

Once an Exclusive job gains control of the DS, it maintains exclusivity, and no other job can use the data set for either input or update until the Exclusive job is finished.

Jobs that would supersede the DS are not even queued.  If they are programs (not interactive processing), they go into a "wait and try" cycle and can gain control of the DS only when no queued user has the DS and there are no users queued.  Once the DS is in the control of a superseding job, all other jobs (except read-only in a default environment) are locked out, and a queue cannot even be established.  In this situation, even those jobs that specify queuing are forced into a "wait and try" cycle until the supersede is completed; then they are queued in the order in which they attempt to access the DS.

In the following pages the commands, statements, and system fields dealing with Simultaneous Update are documented as well as in their normal places in the manual.  In this way you can get a better overall idea or concept of what language elements are available for this feature, in one place.

ACCENT R Simultaneous Update Features

Table 14-1 summarizes the data access environments described above.  It shows which ACCENT R features are used to create each environment.

Table 14-1 Summary of Simultaneous Update Features & Data Access Environments