Synchronous and asynchronous lock requests

The DLM functions can be executed in two ways:

Firstly, the call can be synchronous. This means that control is only returned to the caller when the request has been allocated or an error condition detected. The information is returned in the return code.

Secondly, the call can be asynchronous. This means that control is returned to the caller when the request has been accepted by the DLM. The lock request is allocated later. To this end, the caller must specify an event method.

Two methods are possible for the asynchronous event method: contingency process or eventing.
It is possible for one user to use the synchronous method and another user an asynchronous method for the same lock and at the same time.

The following table shows which operands can be specified in the LKENQ macro and the LKCVT macro in order to use the desired event method.

Operands in the LKENQ and LKCVT macros

Event method		GRTEVTT	RELEVTT
Synchronous allocation		*SYNCH	*NO
		*SYNCH	*TUCONTI
		*SYNCH	*TUEVENT
Asynchronous allocation	Contingency	*TUCONTI	*TUCONTI
		*TUCONTI	*TUEVENT
	Eventing	*TUEVENT	*TUCONTI
		*TUEVENT	*TUEVENT

Support overview:

Macro	Synchronous	Asynchronous
LKENQ	x	x
LKCVT	x	x
LKDEQ	x	x
LKCAN	x	x
LKINF	x	-

• Events and event specification

  The DLM provides:

• the allocation event (GRANTID)

• the release event (RELID)

The allocation event terminates an asynchronous lock request either after the lock has been allocated or when an error situation has been detected.

The release event informs the lock holder that his own allocated lock is blocking incompatible lock requests from other users. The lock mode of the blocked request is transferred together with the event. The lock holder is now able to reduce his lock protection (LKCVT macro) or release his lock (LKDEQ macro).

If a lock holder releases the lock and the new lock holder blocks other lock requests, the release event (which is sent to a blocking lock request) is also generated for the new blocking lock request. The user must therefore take into account release events which may be sent immediately after the lock is allocated. It is also possible for a lock holder which is blocking other lock requests to receive more than one release event.

If an asynchronous DLM call times out, this causes a waiting-time timeout event.

If a lock is held for longer than the hold time specified for the lock, this causes a holdtime timeout event.

• Asynchronous events and USERPAR operand
  The asynchronous functions enable the USERPAR operand to be specified. The value which the user specified when calling the macro is returned in the concluding event of this lock request.

  The USERPAR value which was specified in the LKENQ macro is transferred together with the event when an allocation or release event for this lock (and this task) occurs.
  As of now, the USERPAR value transferred in a subsequent LKCVT macro is used by the DLM for eventing. Every subsequent allocation or release event is transferred together with this USERPAR value.

  The USERPAR value which was specified in the LKCAN or LKDEQ macro is used only for confirmation of the cancellation event or of the release event.

  For ease of use, the user should specify only one USERPAR value for all macros which relate to the same lock request.

  • Synchronous
    The user does not regain control until the lock request has been allocated, the waiting time has expired or an error condition has been detected. The
    corresponding information is provided in the return code.

• Contingency process
  A contingency ID can be specified for each of the events. The allocation event and the release event may specify different contingency processes. If one of the two events occurs, the corresponding contingency process is provided. If the release event occurs, the blocking lock mode is transferred to the contingency process.

  The contingency process must be generated with the ENACO macro. The returned contingency ID must be specified in every asynchronous call. The contingency process is provided under the control of the lock requester task.
  The contingency ID must be available for the DLM, as otherwise no event can be supplied.

  When the contingency process is started, it is sent information about the asynchronous call. This information consists of the event that caused
  thecontingency process to be provided. It is transferred to the contingency process via registers. Register 3 contains the event specification; register 4 contains the user-defined USERPAR values from the LKENQ, LKCVT or LKDEQ macro. The status of the asynchronous call is shown in the Lock Status Block which was specified in the DLM call.

  In order to use the contingency process it is necessary to specify two contingency IDs: one for the allocation event (GRANTID) and one for the release event (RELID). The ID can be the same in both cases. The decision as to which event is reported can be made with the help of the information transferred to the contingency process.

• Eventing
  It is advisable to specify the same event ID for both events. The event ID must be generated with the ENAEI macro. The returned EIID must be specified for every asynchronous call.
  The event ID must be available at the moment when the asynchronous request is allocated as otherwise no event is supplied.

  The postcode, which is transferred together with the event, contains the event specification (DLM event). The user-defined operand USERPAR is also transferred in the second word of the postcode. Information about the asynchronous request, if available, is also transferred to the Lock Status Block.

• (Eventing) and contingency process
  A combination of the two methods is possible. See the table “Operands in theLKENQ and LKCVT macros”.