Steps for providing recovery for the latch manager

About this task

Before you begin: You must use this procedure to ensure recovery for the Latch_Obtain and Latch_Release functions. Not following this exact procedure can risk the loss of serialization during recovery.

In the Program mainline example, which follows this procedure, the mainline program performs the following tasks:

Procedure

  1. Issue the SETFRR macro to establish the recovery routine.
  2. Initialize:
    1. Initialize the latch_token to zeroes as a guide to knowing if the latch manager has potentially obtained the latch. The latch manager will place a latch token value into the area specified on the latch_token parameter by the caller of the Latch_Obtain service. However, unless the service returns, the recovery routine does not know if the latch was definitely obtained.
      Note: A nonzero latch token value does not necessarily indicate that the caller has definitely obtained the latch, it indicates that there is a potential for holding the latch.
    2. Initialize the updating_resource flag to null. This is the bit that indicates whether or not you definitely hold the latch and whether you started to potentially perform incomplete updates to the serialized data.
    3. Initialize the init_complete flag, which indicates whether the values set by the application are valid and can be trusted by the recovery routine. The init_complete flag must reside in storage that was initialized to zeroes before the program is called or before the recovery routine is established.
  3. Set the obtain_option field to ISGLOBT_SYNC (value of 1). If the latch manager cannot immediately grant ownership of the latch, the latch manager suspends the requestor, and returns control to the requestor when ownership of the latch is eventually granted.
    Note: The latch manager sets the latch token value prior to waiting for the latch to become available, so the token can be nonzero in recovery cases when the latch is not actually held.
  4. Call the Latch_Obtain service to obtain a latch. At this point, if recovery is entered due to an error in Latch_Obtain services, it is still uncertain if the latch is held.
  5. Turn the updating_resource flag "on" to indicate that the latch is now definitely held and that the program is about to update the resource associated with the obtained latch.
  6. Update the resource.
  7. Turn the updating_resource flag "off" to indicate that the resource update is complete and the Latch_Release service is about to be called. Once this flag is turned off, there is uncertainty about whether the latch is definitely held.
  8. Set the release_option field to ISGLREL_UNCOND (value of 0). If the original caller of Latch_Obtain no longer owns the latch, this value tells the system to abnormally end the caller of Latch_Release. The abend is desired because the resource was potentially updated without the proper serialization and consequently corrupted.
  9. Call the Latch_Release service to release the latch. The latch token should have the value that was returned from the obtain services. Note that the Latch_Release service does not reset the token to zero.