How SU Processes Transactions

Example: Sample FOCUS MODIFY Request Sample FOCUS Maintain Request

When you submit a transaction to modify a segment instance (with a MODIFY or Maintain request or an HLI program), SU follows a procedure called change verify protocol. If two or more users try to modify the same segment instance at the same time, the change verify protocol determines which transaction is accepted. The procedure is as follows:

1. You first identify the instance to be changed. In FOCUS, you do this with MATCH or NEXT statements within a MODIFY or Maintain request. In HLI, you do this with NEX or locate commands within your program.

2. Your source machine forwards the identified values to the sink machine, which uses the values to retrieve the correct instance.

3. The sink machine retrieves the original data file instance, holds one copy, and sends another to the source (userid) that requested the data.

4. Your MODIFY/Maintain request or HLI program indicates what changes are 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.

5. Your source machine sends the updated copy back to the sink machine.

6. The sink machine compares the copy of the instance that it saved with the instance stored in the data file to check whether the data file instance has since been updated by another user. At this point, two courses of action are possible:
   • If the copy and the current instance in the data file are the same, FOCUS changes the instance using the copy from the source machine.
   • If the original and the current instance in the data file are different, SU signals a conflict and rejects the source machine copy.

Notice that a source machine may work on separate, locally controlled databases.

Example: Sample FOCUS MODIFY Request

The following example of a FOCUS MODIFY request illustrates how change verify protocol works. 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 PROMPT GROSS
   ON MATCH UPDATE GROSS
DATA

When you execute this request, FOCUS prompts for an employee ID and pay date. You enter:

   EMP_ID   =
071382660
   PAY_DATE   =
820831
   GROSS   =
1050.35

The source machine forwards the employee ID value to the sink machine. The sink machine retrieves the instance with this ID and saves it. The sink machine also sends a copy to the source machine. After the source machine receives its copy, the source machine forwards the pay date to the sink machine, which retrieves this segment instance where PAY_DATE is 820831 and GROSS is 916.67.

The sink machine saves these values for itself. It also sends another copy to your source machine. The source machine then prompts you for a new GROSS value, to which you respond:

GROSS=
1050.35

The source machine then updates its copy of the instance with the new GROSS value, $1050.35.

The updated copy is then sent back to the sink machine. At this point, the sink machine needs to verify that another user, in the meantime, has not modified the database. When several users try to change an instance in a centrally controlled database at the same time, FOCUS accepts the first transaction submitted and rejects the others. The other users are not aware of the changes the first user made, and might not want to change the instance if they were. They can repeat their transactions later.

Assume, for this example, that another user has changed the database using the same MODIFY request. The sink machine compares the original value of 916.67 to the value currently in the database. Since another user has already changed the database value, these values do not match, your transaction is rejected, and an error message displays on your terminal. After receiving the error message, you can resubmit your transaction. Enter the same key values again for a fresh copy of the instance.

Example: Sample FOCUS Maintain Request

When using Maintain to write to databases controlled by a sink machine, your request can access only databases that reside on that sink. Consider the following example:

MAINTAIN FILE EMPLOYEE
FOR ALL NEXT EMP_ID PAY_DATE GROSS INTO EMPSTK
COMPUTE TROWS/I4 = EMPSTK.FOCCOUNT;
WINFORM SHOW EMPGRID
CASE UPD
FOR TROWS UPDATE SALINFO.GROSS FROM EMPSTK
ENDCASE

.

.

.

Processing Notes:

• The FOR ALL NEXT command retrieves all records from the database and places each instance of the path beginning with the EMPINFO, FUNDTRAN, PAYINFO, ADDRESS, and SALINFO segments into the EMPSTK stack.
• The WINFORM command displays the EMPGRID Winform. It shows the EMP_ID, PAY_DATE, and GROSS fields in a grid.
• Case UPD updates all the GROSS records that were placed in the EMPSTK stack.

Note: FOCUS provides two MODIFY and Maintain subcommands, COMMIT and ROLLBACK, which enable you to control when changes are made to the sink machine database. COMMIT and ROLLBACK are discussed in SU and the FOCUS Language.