When you submit a transaction that changes a segment with a MODIFY, a Maintain, or an HLI program, SU employs a procedure called change/verify protocol. If more than one user tries to change a segment instance at the same time, change/verify protocol determines which transaction is accepted. A description of how the change/verify protocol interacts with your requests for changes to database records follows:

1. Identify the database instance you wish to change. In FOCUS, do this with MATCH or NEXT statements in a MODIFY or Maintain request. In HLI, use HLI commands in your program. Your source machine forwards the identifying values to the FOCUS Database Server, which uses the values to retrieve the correct instance.
2. The FOCUS Database Server retrieves the original database instance and saves it, while sending a copy back to the source machine.
3. Your MODIFY or Maintain request or HLI program indicates changes to be made to the instance. Your source machine updates its copy of the instance with the new field values or marks the copy for deletion.
4. Your source machine sends the updated copy back to the FOCUS Database Server.
5. The FOCUS Database Server then checks to see that no other user changed the instance in the database by comparing the current value in the database to the value saved in step 2.

   If the current value matches the original value, no one has changed the instance, and FOCUS changes the instance in the database using the copy from your source machine.

   If the values differ, the FOCUS Database Server signals a conflict and rejects the source machine copy, because another user who requested the same instance at the same time has already changed it.

The following example illustrates change/verify protocol by tracing the execution of a FOCUS MODIFY request. The same concepts apply to HLI programs:

MODIFY FILE EMPLOYEE
PROMPT EMP_ID PAY_DATE
MATCH EMP_ID
  ON NOMATCH REJECT
  ON MATCH CONTINUE
MATCH PAY_DATE
  ON NOMATCH REJECT
  ON MATCH TYPE "CURRENT GROSS:<D.GROSS"
  ON MATCH PROMPT GROSS
  ON MATCH UPDATE GROSS
  ON MATCH TYPE "UPDATED!"
DATA

When you execute this procedure, you are prompted for an employee ID and pay date. Enter:

EMP_ID   = 071382660

PAY_DATE = 990831

The source machine forwards the employee ID value to the FOCUS Database Server, which retrieves the instance with this ID and saves it. It also makes a copy for the source machine. When the source machine receives its copy, it forwards the pay date to the FOCUS Database Server, which retrieves the segment instance with PAY_DATE = 990831 and GROSS = 916.67.

The FOCUS Database Server saves these values and sends a copy to your source machine, which then prompts you for a new GROSS value, to which you respond:

GROSS =  1050.35

Your machine updates its copy of the instance with the new GROSS value, 1050.35.

SU sends your new value to the FOCUS Database Server, which compares the current database value with the original value you retrieved (916.67). If another user already changed the value and they do not match, your transaction is rejected and SU signals a conflict.

When several users try to change the same instance in a centrally controlled database at the same time, FOCUS accepts only the first transaction, rejecting all others. Users can always repeat the transaction after they are made aware of the changes that were made by other users. By reentering the same key values, they will receive a fresh copy of the instance and can update that.

Change/verify protocol retains only the current transaction. When you rematch on the keys, the current transaction becomes the new match subject. For example, when you retrieve data in one MODIFY case and then update it in another, verification is only performed on the second MATCH operation. Similarly, only the last record retrieved in multi-record processing (through a HOLD in MODIFY or a FOR NEXT in MAINTAIN) is retained. The current position in the database changes with each record retrieval or update.