Wait For Response - Call-Level Interface Version 2

Wait For Response

Usage Notes

The Wait For Response field specifies whether or not DBCHCL is to retain control or return control to the application program in two situations:

1 When the application program has called DBCHCL for some function and DBCHCL cannot send a request to the Teradata Database to carry out that function because another request in the same session is active. DBCHCL is unable to initiate that function.

2 When the application program has called DBCHCL for the Fetch function and DBCHCL cannot provide access to a parcel or buffer, depending on the setting of Parcel Mode Fetch, because the re-stocking of the buffer is in progress. DBCHCL is unable to complete the Fetch function.

Language	Variable Name
COBOL:	DBCAREA-WAIT-FOR-RESP
C: DBCAREA.H:	wait_for_resp

Routine	Action Taken
DBCHINI:	writes
DBCHCL:	reads (CON; RSUP: IRQ; FET; REW; ERQ; ABT)

Used by	Action Taken
application program	writes

Wait For Response is initialized by DBCHINI to the default value.

If the value provided is not appropriate for the application, before calling DBCHCL, the application program may set:

Change Options to Y, and

Wait For Response to:

Y, if DBCHCL is not to return control until it is able to initiate or complete.

N, if DBCHCL is to return control as soon as the function’s request has been sent to the Teradata Database, in which case the application program must use some other method to detect when the function’s response arrives.

If Wait For Response is set to N and one of the two situations described above occurs, the following return codes are given:

EM_NOTIDLE (208) or EM_NODATA (211),

The application program may try again.

The first way to decide when it is reasonable to try again is to call DBCHWAT. When control is returned from DBCHWAT, try again. This method ties up less system resources while waiting.

Several tries may be necessary. Occasionally CLI may finish one operation it is doing and go on to another immediately. In that case, DBCHWAT will return control when one operation is over, but the application program’s next call to DBCHCL “doesn’t go through” because CLI has already started another operation. Allow for the possibility of multiple tries.

The second way to decide when it is reasonable to try again is to try again immediately, and keep trying until “the call gets through.”

Note: If one above situations occurs and Wait For Response is set to “N”, the original call to DBCHCL did not “take” at all. CLI is reporting “I was not able to do that; try again later.”

Note: Neither the Abort function nor the Disconnect function is affected by the setting of Wait For Response.

The Fetch, Rewind, End Request, and Abort functions read and use the value of Wait For Response, but do not store it.

By using Wait for Response during CLI logoff processing, applications can prevent CLI from waiting “forever” if the gateway does not respond to the logoff request.