Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

USING "CONSISTENCY CHECK VALUE" AS OPTIMISTIC LOCKING VALUE FOR STAGING HOST PRODUCTION DATA AT CLIENT/SERVER FOR ACCESS BY...

IP.com Disclosure Number: IPCOM000013902D
Original Publication Date: 2001-Feb-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 1 page(s) / 45K

Publishing Venue

IBM

Abstract

Using "CONSISTENCY CHECK VALUE" as optimistic locking value for staging Host production data at Client/Server for access by IMS CSOBJECT Client/Server feature. By generating a Consistency Check Value (CCV) from the data within the IMS/ESA and/or DB2 data base, an optimistic lock value can be generated and stored in the CSobject Lock Table to provide a checking value that can be validated for a change request (ADD, DELETE, and UPDATE) to insure that the IMS and/or DB2 data has been transmitted to the Client /Server or has not been changed at the Host by a Host application. Since the data being sent to the Client/Server is used to create the CCV, the same data fields can be used to determine if the Host data has changed since it was staged at the Client/Server. The CCV value can be actual data fields, a time stamp that exists within the Host data, or a technique such as 32-bit (long) arithmetic to accumulate a sum, and then fold the resulting 16-bit value by adding any carry bits into the sum explicitly, and returning ones compliment of the result. When a Client/Server application makes a request to the Host, CSobject will pass the result to a user method at the Host. For a RETRIEVAL request, for an UPDATE lock, the user Host method will construct the CCV and pass it to CSobject on a send request. CSobject will store the CCV in the CSobject lock table. For a DELETE request, CSobject will pass the CCV to the Host application that was created on the RETRIEVAL request for CCV validation. The user Host application will reconstruct the CCV value from the current Host data and if the new CCV value and the CCV value passed on the DELETE are the same then the Host data has not changed and the Host data can be deleted. If the 2 CCVs do not match then the Host data has changed and the user method will need to decide whether or not to delete the Host data, or reject the CSobject DELETE request. For an UPDATE request, CSobject will pass the CCV to the Host application that was created on the RETRIEVAL request for CCV validation. The user Host application will reconstruct the CCV value form the current Host data and if the new CCV value and the CCV value passed on the UPDATE are the same then the Host data has not changed and the Host data can be updated, if the 2 CCVs do not match then the Host data has changed and the user method will need to decide whether or not to update the Host data, or reject the CSobject UPDATE request. For an ADD request, CSobject will pass the CCV to the Host application that was created on the RESERVE KEY request (APID) for CCV validation, which will not contain any data base data because the RESERVE KEY request will validate that the key requested is not being used, and the CCV will contain anything that the installation wishes to store, such as, a strin of "KEY AVAILABLE". The user Host method will determine if the object has been added by a Host application. If the data does not exit, the data can be added, if however, the data does exist, the requested data cannot be added and the method will have to determine if the data should be updated or reject the ADD request. 1

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 1

  USING "CONSISTENCY CHECK VALUE" AS OPTIMISTIC LOCKING VALUE FOR STAGING HOST PRODUCTION DATA AT CLIENT/SERVER FOR ACCESS BY...

    Using "CONSISTENCY CHECK VALUE" as optimistic locking value for staging Host production data at Client/Server for access by IMS CSOBJECT Client/Server feature.

By generating a Consistency Check Value (CCV) from the data within the IMS/ESA and/or DB2 data base, an optimistic lock value can be generated and stored in the CSobject Lock Table to provide a checking value that can be validated for a change request (ADD, DELETE, and UPDATE) to insure that the IMS and/or DB2 data has been transmitted to the Client /Server or has not been changed at the Host by a Host application. Since the data being sent to the Client/Server is used to create the CCV, the same data fields can be used to determine if the Host data has changed since it was staged at the Client/Server. The CCV value can be actual data fields, a time stamp that exists within the Host data, or a technique such as 32-bit (long) arithmetic to accumulate a sum, and then fold the resulting 16-bit value by adding any carry bits into the sum explicitly, and returning ones compliment of the result. When a Client/Server application makes a request to the Host, CSobject will pass the result to a user method at the Host. For a RETRIEVAL request, for an UPDATE lock, the user Host method will construct the CCV and pass it to CSobject on a send request. CSobject will store the CCV in the CSobject lock table. For a DELETE request, CSobject will pass the CCV to the Host application that was created on the RETRIEVAL request for CCV validation. The user Host applicatio...