Using the Version Number to Serialize Data Entry Operations

By adhering to a protocol of updating the version number when you update a cache entry's contents, you can avoid corrupting or deleting changes made to the entry by other users. For instance, you could establish the following procedure for updating data entries:

Read a data entry
Update its contents
Increment, decrement, or set the version number of the updated copy of the data entry
Write the changes back to the data entry using the VERSCOMP parameter to ensure that the data entry is updated only if its version number is still the same as when you read it or is less than or equal to a specified value.

Note that the use of VERSCOMP is needed to ensure that updates to the version number requested through the VERSUPDATE keyword are not processed multiple times as a result of XES internal request redrive logic. When VERSCOMP is requested along with VERSUPDATE to update the version number, then if the initial execution of the request succeeds, any subsequent internal redrive of the request will fail due to a version number miscompare, preventing multiple updates from occurring on the request. Conversely, if the initial execution of the request was unsuccessful, any subsequent internal redrive of the request will be able to execute successfully and update the version number only once.

In either of these cases, if the request is internally redriven and experiences a version number miscompare on the redrive, a return and reason code of IXLRSNCODESTATUSUNKNOWN will be returned. This reflects the fact that it is not known whether the observed version number miscompare:

Resulted from the version number update succeeding on the original issuance of the request (causing the miscompare on the redriven request), or
Was present all along, or
Resulted from a version number update made by another request.

When this return and reason code is returned, it is up to the user to determine whether or not the requested update has actually occurred, and take the appropriate recovery action.

If the version number comparison fails, the write request is not performed and you must start the update process again after re-reading the current data entry.