|
|
|
|
This section explains some SNA information that you need to consider when writing SNAP-IX LUA applications.
This guide does not attempt to explain SNA concepts in detail. If you need specific information about SNA message flows, refer to the documentation listed in Related Publications, and to the documentation for the host application for which you are designing your SNAP-IX LUA application.
During initialization of the LU session, the host sends a BIND message to the SNAP-IX LUA application that contains information such as RU sizes to be used by the LU session. SNAP-IX returns this message to the LUA application on an RUI_READ verb. It is the responsibility of the LUA application to check that the parameters specified on the BIND are suitable. The application has the following options:
Accept the BIND as it is, by issuing an RUI_WRITE verb containing an OK response to the BIND. No data needs to be sent on the response.
Try to negotiate one or more BIND parameters (this is only permitted if the BIND is negotiable). To do this, the application issues an RUI_WRITE verb containing an OK response, but including the modified BIND as data.
Reject the BIND by issuing an RUI_WRITE verb containing a negative response, using an appropriate SNA sense code as data.
For more information about the RUI_WRITE verb, see LUA Verbs.
The validation of the BIND parameters, and ensuring that all messages sent are consistent with them, is the responsibility of the LUA application. However, the following two restrictions apply:
SNAP-IX rejects any RUI_WRITE verb that specifies an RU length greater than the size specified on the BIND.
SNAP-IX requires the BIND to specify that the secondary LU is the contention winner, and that error recovery is the responsibility of the contention loser.
SNA sense codes may be returned to an LUA application in the following cases:
When the host sends a negative response to a request from the LUA application, this includes an SNA sense code indicating the reason for the negative response. This is reported to the application on a subsequent RUI_READ verb, as follows:
The primary return code is LUA_OK.
The Request/Response Indicator, Response Type Indicator, and Sense Data Included Indicator are all set to 1, indicating a negative response that includes sense data.
The data returned by the RUI_READ verb is the SNA sense code.
When SNAP-IX receives data that is not valid from the host, it generally sends a negative response to the host and does not pass the data that is not valid to the LUA application. This is reported to the application on a subsequent RUI_READ or RUI_BID verb, as follows:
The primary return code is LUA_NEGATIVE_RSP.
The secondary return code is the SNA sense code sent to the host.
In some cases, SNAP-IX detects that data supplied by the host is not valid, but cannot determine the correct sense code to send. In this case, it passes the data that is not valid in an Exception Request (EXR) to the LUA application on an RUI_READ verb as follows:
The Request/Response Indicator is set to 0 (zero), indicating a request.
The Sense Data Included Indicator is set to 1, indicating that sense data is included (this indicator is normally used only for a request).
The message data is replaced by a suggested SNA sense code.
The application must then send a negative response to the message; it may use the sense code suggested by SNAP-IX, or may alter it.
SNAP-IX may send a sense code to the application to indicate that data supplied by the application was not valid. This is reported to the application on the RUI_WRITE verb that supplied the data, as follows:
The primary return code is LUA_UNSUCCESSFUL.
The secondary return code is the SNA sense code.
For a secondary return code that is not a sense code, the two most significant bytes of this value are always 0 (zero). For an SNA sense code, the two most significant bytes are nonzero; the first byte gives the sense code category, and the second identifies a particular sense code within that category. (The third and fourth bytes may contain additional information, or may be 0.)
If you need information about a returned sense code, refer to IBM's Systems Network Architecture: Formats. The sense codes are listed in numerical order by category.
Pacing is handled by the LUA interface; an LUA application does not need to control pacing, and should never set the Pacing Indicator flag.
If pacing is being used on data sent from the LUA application to the host (this is determined by the BIND), an RUI_WRITE verb may take some time to complete. This is because SNAP-IX has to wait for a pacing response from the host before it can send more data.
If an LUA application is used to transfer large quantities of data in one direction, either to the host or from the host (for example, a file transfer application), then the host configuration should specify that pacing is used in that direction; this is to ensure that the node receiving the data is not flooded with data and does not run out of data storage.
Segmentation of RUs is handled by the LUA interface. LUA always passes complete RUs to the application, and the application should pass complete RUs to LUA.
A host may send data to an LUA application with the BB (begin bracket) and RQE (request exception) options set but without the EB (end bracket) option (begin bracket and exception response but no end bracket). This combination of options is not strictly valid in SNA, but is used by some host applications.
In order to support these host applications, SNAP-IX modifies the host data to specify definite response rather than exception response before sending it to the application.
SNAP-IX keeps a record of requests received from the host in order to correlate any response sent by the application with the appropriate request. When the application sends a response, SNAP-IX correlates this with the data from the original request, and can then free the storage associated with it.
If the host specifies exception response only (a negative response can be sent but a positive response should not be sent), SNAP-IX must still keep a record of the request in case the application subsequently sends a negative response. If the application does not send a response, the storage associated with this request cannot be freed.
Because of this, SNAP-IX allows the LUA application to issue a positive response to an exception-response-only request from the host (this is known as a courtesy acknowledgment). The response is not sent to the host, but is used by SNAP-IX to clear the storage associated with the request.
When the host sends a chain of request units to an LUA application, the application may wait until the last RU in the chain is received before sending a response, or it may send a negative response to an RU that is not the last in the chain. If a negative response is sent mid-chain, SNAP-IX purges all subsequent RUs from this chain, and does not send them to the application.
When SNAP-IX receives the last RU in the chain, it indicates this to the application by setting the primary return code of an RUI_READ or RUI_BID verb to LUA_NEGATIVE_RSP with a 0 (zero) secondary return code.
The host may terminate the chain by sending a message such as
CANCELwhile in mid-chain. In this case, the
CANCELmessage is returned to the application on an RUI_READ verb, and the LUA_NEGATIVE_RSP return code (see Negative Responses and SNA Sense Codes) is not used.
|
|
|
 |
|