The API employs one new method call-EDABROWSE-for use with both synchronous servers and Messaging Servers. Existing method calls perform similar methods in an asynchronous environment as they do in a synchronous environment. There are, however, slight differences in the use and behavior of these methods in a messaging context, which are fully described in Method Reference. Nevertheless, some of the information is summarized here to discuss method call usage under synchronous and asynchronous environments.
The method calls of the API comprise three major method groupings:
Imagine a server-based e-mail utility that, for purposes of exposition, we will call MSG. MSG would initiate an end-user session by calling EDAINIT and register with an asynchronous server by invoking EDACONNECT. Then, having initialized and registered, it would send and receive some messages. Finally, it would wrap things up by calling EDAXCONNECT and EDATERM. At every stage, MSG would need methods normally used by synchronous applications.
The following method calls:
EDARPC. EDARPC is similar to EDASQL in that application programs use it to build up database queries. In a messaging context, EDARPC is used to build the UOW; it does not transmit a message. To transmit the UOW, the application must issue an EDASQL method call with the execute parameter set to one (1). (The statement parameter can be null (0), if desired.)
EDAQUIT. EDAQUIT has limited usage in messaging applications. Since the application is not physically connected to a server at any time, there is no ability to quit a process the way a synchronous application can. EDAQUIT is used solely when processing an ALOB that has been received from a now disconnected server (see Processing Answer Set Large Objects). EDAQUIT is used to flush the current response message without going to end-of-set.
EDATEST. EDATEST, like EDAQUIT, is limited to ALOB processing and cannot be used to test a server connection to check if work has been completed and data or messages are available. It can be used to synchronize an EDABROWSE request.
The following method calls:
EDAINIT and EDATERM. All APIm applications must invoke EDAINIT before performing anything else and EDATERM before terminating.
EDAINFO. Calls to EDABROWSE produce result sets in much the same way as EDASQL calls in synchronous and asynchronous environments. A row in an instance of any of the EDABASE tables is the analog of a row in a result set coming from a server, and a column in an EDABASE table instance is the analog of a column attribute. After issuing an EDABROWSE, application programs can obtain information about the structure of any of the EDABASE tables by applying EDAINFO systematically to the SCB.
EDAINFO can also be used to process the metadata associated with response messages. After an EDASQL with the desired result set is issued and the execute parameter is set to 4, application programs use EDAINFO to obtain the metadata from the returned ALOB.
EDAFIELD, EDAFETCH, EDANEXT, and EDANULL. Application programs use EDAFIELD, EDAFETCH, EDANEXT, and EDANULL to access result set data and the contents and attributes of EDABASE tables returned using EDABROWSE.
EDAINSPECT. EDAINSPECT permits the caller to query the value of any of the internal APIm variables, including a new standard variable for messaging, EDA_VAR_ASYID (setting = 303), which contains the identifier of the most recent UOW emitted by an EDASQL call. This parameter is meaningful only if the caller has initiated and transmitted Units of Work during the same session.
EDAACCEPT. Application programs use EDAACCEPT to process messages in returned ALOBs when the msg_pending field in the SCB is non-zero.
EDAXCONNECT. To undo server connections and connections to "SELF," applications invoke EDAXCONNECT, referencing a connected SCB in the calling sequence.
| iWay Software |